Armadilloシリーズは、汎用CPUボードという性格上、ユーザーが書き換え可能なフラッシュメモリを搭載しています。
そして、フラッシュメモリの内容を消去されてしまっても復旧できるようにするため、
microSDカードのような外部のデバイスからもブートローダーを起動できるように設計されています。
Armadillo-640では、ジャンパの設定を変更することで、
microSDカードとeMMCのどちらからブートローダーを起動するのか選択できます。
Armadillo-X1では、SD スロット拡張ボードのスライドスイッチの設定を変更することで、
SDカードとSPIフラッシュメモリのどちらからブートローダーを起動するのか選択できます。
表6.1 ジャンパの設定と起動デバイス(Armadillo-640向け)
JP1 | JP2 | 起動デバイス |
---|
オープン | ショート | eMMC |
ショート | ショート | microSD |
表6.2 スライドスイッチの設定と起動デバイス(Armadillo-X1向け)
SW1 | 起動デバイス |
---|
[→ NORMAL] | SPIフラッシュメモリ |
[→ SD BOOT] | SD |
| ジャンパのオープン、ショートとは |
---|
-
-
「オープン」とはジャンパピンにジャンパソケットを接続していない状態です。
-
-
「ショート」とはジャンパピンにジャンパソケットを接続している状態です。
|
起動したU-bootは、最低限のハードウェアの初期化を行った後、自分自身をメモリ(RAM)にコピーします。
その後の動作は、USBシリアル変換アダプタのスライドスイッチの設定によって決定されます。
スライドスイッチを、図6.1「スライドスイッチの設定」の 1 側に設定しておくと保守モード、2 側に設定しておくとオートブートモードとなります。
-
-
ブートローダーは保守モードになります。保守モードでは、ブートローダーのコマンドプロンプトが起動します。
-
-
ブートローダーはオートブートモードになります。オートブートモードでは、ブートローダーのコマンドプロンプトが表示されず、OSを自動起動します。
スライドスイッチを、図6.1「スライドスイッチの設定」の 1 側に設定した状態で起動すると、U-Bootは保守モードとなります。
保守モードの場合、U-Bootは、コンソールにプロンプトを表示してコマンド入力待ち状態となります。
保守モードでは、U-Bootの環境変数の変更などを行うことができます。
boot コマンドを実行することで、U-Bootはカーネルを起動するための処理を開始します。
参考として、Armadillo-640 での
図6.2「U-boot保守モード時の表示」に保守モード起動時のシリアルコンソールへの表示を示します。
スライドスイッチを、図6.1「スライドスイッチの設定」の 2 側に設定した状態で起動すると、U-Bootはオートブートモードとなります。
これが通常運用での設定です。
オートブートモードの場合、U-Bootは、コマンド入力待ち状態になることなく、自動的にカーネルを起動するための処理を開始します。
次にU-Bootは、環境変数で設定されたストレージデバイスからLinuxカーネルイメージとDTB(Device Tree Blob)をメモリにロードします。
| |
---|
Device Treeは、ハードウェア情報を記述したデータ構造体です。
ハードウェアの差分をDevice Treeに記述することによって、1つのLinuxカーネルイメージを複数のハードウェアで利用することができるようになります。 DTB(Device Tree Blob)は、Device Tree Source(Device Treeを記述したソースファイル)をビルドして生成されるバイナリファイルです。 |
その後、ブートローダーを抜け、カーネルの開始番地へ実行を移します。
この一連の処理を、Linuxカーネルをブートすると表現します。
参考として、Armadillo-640 での
U-BootがLinuxカーネルをブートするときの、コンソールへの出力を図6.3「U-Bootオートブートモード時の表示」に示します。
|
U-Bootはシリアルの初期化が完了すると自身のバージョンを表示します。
|
|
この行から数行に渡って、ロードされたカーネルの情報を表示されます。
|
|
この行から数行に渡って、ロードされたDevice Tree Blobの情報を表示します。
|
|
この行以降は、カーネルが表示しています。
|
ブートローダーから実行を移されると、ようやくLinuxカーネルが動作を開始します。
Armadilloのカーネル起動ログの例として、Armadillo-640の起動ログを図6.4「Armadillo-640カーネルブートログ」に示します。
|
ブートローダーから実行が移ると、カーネルはまず自身のバージョン、CPUアーキテクチャ、マシン名、メモリの状態などを表示します。
|
|
カーネルパラメータは、「root=/dev/mmcblk0p2 rootwait」が使用されています。
|
|
ここから、各デバイスやカーネル内部の初期化処理が始まります。
|
|
eMMCの第1から第3パーティションが認識されています。
|
|
eMMCの第2パーティションをマウントしています。
|
カーネルは、初期化処理が終えた後、 initramfs を一時的なルートファイルシステムとしてマウントし、initramfs 上のルートディレクトリにあるinitを実行します。
initramfsのinitは、procfs []やsysfsのマウントや、systemd-udevd の起動などを行います。
その後、/dev/mmcblk0p2(eMMCの第2パーティション)を本当のルートファイルシステムとしてマウントし、/sbin/init を実行します。
このマウントされるデバイスは、カーネルパラメータの root に指定されています。Armadillo-640では/dev/mmcblk0p2ですが、Armadillo-X1では/dev/mmcblk2p2となります。
systemd を使用するユーザーランドでは、/sbin/initは/lib/systemd/systemdへのシンボリックリンクとなっており、実際にはsystemdというアプリケーションプログラムが実行されます。
起動時の処理状況を表示するシステムコンソールには、/dev/console を使用します。
/dev/consoleの実体は、Device Treeの/chosen/stdout-pathで指定したデバイスがデフォルトとして使用されます。
このデバイスは、カーネルパラメータのconsoleオプションを指定することで変更することができます。
図6.4「Armadillo-640カーネルブートログ」で示したように、Armadillo-640では標準ではconsoleが指定されていません。
Armadillo-640の標準イメージでは、/chosen/stdout-pathに UART1 (/dev/ttymxc0) が指定されているため、/dev/ttymxc0 がシステムコンソールとして使われます。
一方、Armadillo-X1では、デフォルトで console=ttymxc4,115200[]
が設定されており、/dev/ttymxc4 がシステムコンソールとして使われます。
| Systemdの概要 |
---|
SystemdとはLinuxのシステム管理デーモンの一つです。
高速なシステム起動/終了や設定ファイルによるシステム管理の共通化、柔軟なプロセス起動を行うことができます。 Linuxの起動を行う処理は今までSysVinitが広く用いられてきました。
しかし、並列処理ができない事や、タイマー起動やプロセス起動を行う事ができず、柔軟な起動を行うことができないという問題を抱えていました。
この問題を解決するためにSystemdが登場し、多くのLinuxディストリビューションで採用されるようになりました。 Debian GNU/Linuxでは、Debian 8.0 コードネーム: jessieから、デフォルトのシステム管理デーモンにSystemdが使われています。 Systemdでは、プロセスの起動やファイルシステムのマウントなどの処理を "Unit" という単位で管理します。
あるUnitが起動した後に起動する、あるUnitと同時に起動する、など細かな制御が可能です。 |
Systemdはまず、Systemd unit generators(もしくは単にGenerators)と呼ばれるプログラム群[]を実行します。
Armadillo-640ではこれらのプログラムは /lib/systemd/system-generators ディレクトリに配置されています。
表6.3 Systemd unit generators
名称 | 説明 |
---|
systemd-cryptsetup-generator
| /etc/crypttab を元に Unit を生成するジェネレータ
|
systemd-debug-generator
| ランタイムデバッグシェルを有効にし、起動時に特定のユニットをマスクするためのジェネレータ |
systemd-fstab-generator
| /etc/fstab を元に Unit []を生成するジェネレータ
|
systemd-getty-generator
| カーネルコンソールを使用する serial-getty@.service Unit []を自動的に生成するジェネレータ |
systemd-gpt-auto-generator
| GPTパーティションタイプのGUIDに基づいて、ルートパーティション、 /home パーティション、および /srv パーティションを自動的に検出してマウントし、スワップパーティションを検出して有効にするジェネレータ |
systemd-hibernate-resume-generator
| カーネルパラメータ resume= の値に従って systemd-hibernate-resume@.service Unit を生成するジェネレータ |
systemd-rc-local-generator
| /etc/rc.local []を起動時に、 /usr/sbin/halt をシャットダウン時に実行するようにするためジェネレータ
|
systemd-system-update-generator
| /system-update が存在する場合に、起動プロセスを system-update.target に自動的にリダイレクトするジェネレータ
|
systemd-sysv-generator
| SysV init のスクリプトをSystemd上で実行するための Unit を自動的に生成するジェネレータ |
次に Systemd は、すべてのUnitファイルを読み込み、各Unitの依存関係にしたがって各起動処理を行います。
この時に、serial-getty@ttymxc0.service および systemd-logind.service が起動され、systemd-logind によってログイン画面が表示されます。
| |
---|
Systemd が起動した Unit の順番は systemd-analyze コマンドで調べることができます。 次のように systemd-analyze に plot 引数を付けて実行すると、各Unitの起動順序、起動時間などがわかる画像ファイル(SVG形式)が生成されます。 [armadillo ~]# systemd-analyze plot > /home/atmark/systemd-analyze.prot.svg この画像ファイルをATDEで表示するには eog コマンドを実行します。
なお、SVG形式の画像ファイルはFirefox などのWebブラウザでも表示することができます。 [ATDE ~]$ eog systemd-analyze.prot.svg |