Armadilloが動作する仕組み

前章で実際にArmadilloを動かしてみて、Armadilloとはどのようなコンピューターなのか、大体のイメージが掴めたと思います。 この章では、Armadilloがどのようなソフトウェアで構成されていて、それらがどのように動いているのか、その仕組みを詳しく説明していきます。

6.1. ソフトウェア構成

Armadilloは、以下のソフトウェアによって動作します。

6.1.1. ブートローダー

ブートローダーは、電源投入後、最初に動作するソフトウェアです。 Armadillo-600シリーズ、Armadillo-X1ではU-bootブートローダー(以降、単にU-bootと記述します)を使用します。

U-bootは、二つの動作モードを持っています。 一つは、オートブートモードです。 オートブートモードでは、カーネルイメージをブートデバイス[36]から読み出し、メモリに展開してからカーネルに制御を移します。 この動作は、「ブートローダーが行う処理」で詳しく説明します。

もう一つの動作モードは保守モードで、コンソールにプロンプトを表示し、ユーザーが入力したコマンドに応じてU-Bootの環境変数の変更などを行えます。

6.1.2. Linuxカーネル

Linuxカーネルは、プロセス管理(スケジューリング)、時間管理、メモリ管理、デバイスドライバ、プロトコルスタック、ファイルシステムなどのOSとしてのコア機能を提供します。 Armadilloでは、標準のカーネルとして Linux を使用します。

Linuxカーネルの初期化処理については、「カーネルの初期化処理」で詳しく説明します。

6.1.3. ユーザーランド

ユーザーランドとは、アプリケーションプログラムやライブラリ、設定ファイル、データファイル、デバイスファイルなどLinuxシステムが動作する上で必要なカーネル以外のものをいいます。

[注記]カーネルとユーザーランドとのインターフェース

Linuxカーネルは、ユーザーランドで動作するプログラムとの唯一のAPI(Application Program Interface)として、システムコールを提供します。 ユーザーランドのプログラムは、必ずシステムコールを通してカーネルの機能を呼び出します。

Linuxシステムでは、ユーザーランドのファイルとディレクトリ[37]同士の位置関係を階層的な木構造として表現します。 ファイルとディレクトリの木構造をファイルシステムといいます。 また、木構造の最上位に位置するディレクトリをルートディレクトリといいます。 全てのファイルはルートディレクトリから辿ることができます。

ファイルシステムは、通常、ストレージデバイス[38]に書き込まれて使用されます。 ストレージデバイスをファイルシステムと関連付け、システムから使用できるようにすることを、「マウントする」といいます。 Linuxシステムでは、任意のディレクトリにデバイスをマウントすることができます。 特に、ルートディレクトリにマウントされたファイルシステムを、ルートファイルシステムといいます。

[注記]Windowsのファイルシステムとの違い

Windowsも階層的なファイル構造を持っていますが、Linuxシステムとは決定的な違いがあります。 それは、Linuxシステムのファイルシステムにはドライブという考え方がないことです。

Windowsでは複数のストレージデバイスがある場合、デバイスごとにドライブという形で区別し、別々の階層構造を持ちます。 一方で、Linuxシステムでは、複数のデバイスがある場合でも、ルートディレクトリから連なる一つの階層構造として表現します。 つまり、USBメモリを/mnt/usbディレクトリにマウントし、SDカードを/mnt/usb/sdディレクトリにマウントするといったことができます。 デバイスがどれだけ増えようとも、必ずルートディレクトリから辿ることができます。

Armadillo-600シリーズでは、ユーザーランドの標準ルートファイルシステムとして、Debian 9(stretch)を採用しています。

6.2. 起動の仕組み

本章では、標準状態のArmadilloに電源を投入してから、ログイン画面が表示されるまでの起動シーケンスを詳しく説明します。

大まかな起動の流れは、以下のようになります。

  1. ブートローダーが行う処理

    1. ブートローダが起動し最低限のハードウェア初期化を行う
    2. カーネルイメージをメモリにロードする
    3. ブートローダーを抜けて、カーネルに実行を移す
  2. カーネルの初期化処理

    1. カーネルが様々なコアやデバイスドライバの初期化処理をおこなう
    2. ルートファイルシステムをマウントする
    3. カーネルがユーザーランドのinitというアプリケーションプログラムを実行する
  3. ユーザーランドの初期化処理

    1. systemdがシステム初期化処理を実行する
    2. systemdがsystemd-logind.serviceを起動する
    3. systemdがserial-getty@ttymxc0.serviceを起動する
    4. systemd-logindがログイン画面を表示する

6.2.1. ブートローダーが行う処理

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


[ティップ]ジャンパのオープン、ショートとは
images/jumper_open.svg
「オープン」とはジャンパピンにジャンパソケットを接続していない状態です。
images/jumper_short.svg
「ショート」とはジャンパピンにジャンパソケットを接続している状態です。

起動したU-bootは、最低限のハードウェアの初期化を行った後、自分自身をメモリ(RAM)にコピーします。

その後の動作は、USBシリアル変換アダプタのスライドスイッチの設定によって決定されます。 スライドスイッチを、図6.1「スライドスイッチの設定」の 1 側に設定しておくと保守モード、2 側に設定しておくとオートブートモードとなります。

images/usb-serial-slide-switch.svg

図6.1 スライドスイッチの設定


images/callouts/1.svg
ブートローダーは保守モードになります。保守モードでは、ブートローダーのコマンドプロンプトが起動します。
images/callouts/2.svg
ブートローダーはオートブートモードになります。オートブートモードでは、ブートローダーのコマンドプロンプトが表示されず、OSを自動起動します。

6.2.1.1. 保守モード

スライドスイッチを、図6.1「スライドスイッチの設定」の 1 側に設定した状態で起動すると、U-Bootは保守モードとなります。 保守モードの場合、U-Bootは、コンソールにプロンプトを表示してコマンド入力待ち状態となります。 保守モードでは、U-Bootの環境変数の変更などを行うことができます。

boot コマンドを実行することで、U-Bootはカーネルを起動するための処理を開始します。

参考として、Armadillo-640 での 図6.2「U-boot保守モード時の表示」に保守モード起動時のシリアルコンソールへの表示を示します。

U-Boot 2018.03-at4 (Dec 26 2018 - 19:21:13 +0900)

CPU:   Freescale i.MX6ULL rev1.0 at 396 MHz
Reset cause: POR
I2C:   ready
DRAM:  512 MiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... OK
In:    serial
Out:   serial
Err:   serial
PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11
Net:   FEC
=>

図6.2 U-boot保守モード時の表示


6.2.1.2. オートブートモード

スライドスイッチを、図6.1「スライドスイッチの設定」の 2 側に設定した状態で起動すると、U-Bootはオートブートモードとなります。 これが通常運用での設定です。 オートブートモードの場合、U-Bootは、コマンド入力待ち状態になることなく、自動的にカーネルを起動するための処理を開始します。

6.2.1.3. Linuxカーネルのブート

次に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 2018.03-at4 (Dec 26 2018 - 19:21:13 +0900)  1

CPU:   Freescale i.MX6ULL rev1.0 at 396 MHz
Reset cause: POR
I2C:   ready
DRAM:  512 MiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... OK
In:    serial
Out:   serial
Err:   serial
PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11
Net:   FEC
Hit any key to stop autoboot:  0
6105312 bytes read in 194 ms (30 MiB/s)
27015 bytes read in 54 ms (488.3 KiB/s)
## Booting kernel from Legacy Image at 82000000 ...  2
   Image Name:   Linux-4.14-at11
   Image Type:   ARM Linux Kernel Image (uncompressed)

   Data Size:    6105248 Bytes = 5.8 MiB
   Load Address: 82000000
   Entry Point:  82000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 83000000  3
   Booting using the fdt blob at 0x83000000
   Loading Kernel Image ... OK
   Loading Device Tree to 9eefc000, end 9ef05986 ... OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0  4
[    0.000000] Linux version 4.14-at11 (atmark@atde7) (gcc version 6.3.0 2017051
6 (Debian 6.3.0-18)) #1 Tue Jan 29 10:11:05 JST 2019
[    0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c53c7d
[    0.000000] CPU: div instructions available: patching division code
:
:
:

図6.3 U-Bootオートブートモード時の表示


1

U-Bootはシリアルの初期化が完了すると自身のバージョンを表示します。

2

この行から数行に渡って、ロードされたカーネルの情報を表示されます。

3

この行から数行に渡って、ロードされたDevice Tree Blobの情報を表示します。

4

この行以降は、カーネルが表示しています。

6.2.2. カーネルの初期化処理

ブートローダーから実行を移されると、ようやくLinuxカーネルが動作を開始します。

Armadilloのカーネル起動ログの例として、Armadillo-640の起動ログを図6.4「Armadillo-640カーネルブートログ」に示します。

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.14-at11 (atmark@atde7) (gcc version 6.3.0 2017051
6 (Debian 6.3.0-18)) #1 Tue Jan 29 10:11:05 JST 2019
[    0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c53c7d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instructio
n cache
[    0.000000] OF: fdt: Machine model: Atmark Techno Armadillo-640
[    0.000000] Memory policy: Data cache writeback
[    0.000000] cma: Reserved 16 MiB at 0x9f000000
[    0.000000] CPU: All CPU(s) started in SVC mode.
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 129920  1
[    0.000000] Kernel command line: root=/dev/mmcblk0p2 rootwait  2
[    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Memory: 491980K/524288K available (5120K kernel code, 227K rwdata
, 1156K rodata, 3072K init, 230K bss, 15924K reserved, 16384K cma-reserved)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
[    0.000000]     vmalloc : 0xe0800000 - 0xff800000   ( 496 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
[    0.000000]       .text : 0xc0008000 - 0xc0600000   (6112 kB)
[    0.000000]       .init : 0xc0800000 - 0xc0b00000   (3072 kB)
[    0.000000]       .data : 0xc0b00000 - 0xc0b38e60   ( 228 kB)
[    0.000000]        .bss : 0xc0b3dac8 - 0xc0b77644   ( 231 kB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[    0.000000] Switching to timer-based delay loop, resolution 41ns  3
:
各デバイスやカーネル内部の初期化処理
:
[    2.194104] mmcblk0: mmc0:0001 Q2J55L 3.53 GiB
[    2.203781] mmcblk0boot0: mmc0:0001 Q2J55L partition 1 2.00 MiB
[    2.214910] mmcblk0boot1: mmc0:0001 Q2J55L partition 2 2.00 MiB
[    2.226019] mmcblk0gp0: mmc0:0001 Q2J55L partition 4 8.00 MiB
[    2.237064] mmcblk0gp1: mmc0:0001 Q2J55L partition 5 8.00 MiB
[    2.247819] mmcblk0gp2: mmc0:0001 Q2J55L partition 6 8.00 MiB
[    2.258427] mmcblk0gp3: mmc0:0001 Q2J55L partition 7 8.00 MiB
[    2.268840] mmcblk0rpmb: mmc0:0001 Q2J55L partition 3 4.00 MiB
[    2.285905]  mmcblk0: p1 p2 p3  4
[    2.296675] input: gpio-keys as /devices/soc0/gpio-keys/input/input0
[    2.308365] snvs_rtc 20cc000.snvs:snvs-rtc-lp: setting system clock to 1970-0
1-01 00:00:00 UTC (0)
[    2.326849] 5V: disabling
[    2.338196] Warning: unable to open an initial console.
[    2.353434] Freeing unused kernel memory: 3072K
[    2.510160] systemd-udevd[74]: starting version 215
[    2.529550] random: systemd-udevd: uninitialized urandom read (16 bytes read)
[    3.730124] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)  5
[    4.102740] systemd[1]: System time before build time, advancing clock.
[    4.132433] random: systemd: uninitialized urandom read (16 bytes read)
[    4.147338] random: systemd: uninitialized urandom read (16 bytes read)
[    4.166155] systemd[1]: systemd 232 running in system mode. (+PAM +AUDIT +SEL
INUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +
XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
[    4.200049] systemd[1]: Detected architecture arm.

Welcome to Debian GNU/Linux 9 (stretch)!

図6.4 Armadillo-640カーネルブートログ


1

ブートローダーから実行が移ると、カーネルはまず自身のバージョン、CPUアーキテクチャ、マシン名、メモリの状態などを表示します。

2

カーネルパラメータは、「root=/dev/mmcblk0p2 rootwait」が使用されています。

3

ここから、各デバイスやカーネル内部の初期化処理が始まります。

4

eMMCの第1から第3パーティションが認識されています。

5

eMMCの第2パーティションをマウントしています。

6.2.3. ユーザーランドの初期化処理

カーネルは、初期化処理が終えた後、 initramfs を一時的なルートファイルシステムとしてマウントし、initramfs 上のルートディレクトリにあるinitを実行します。

initramfsのinitは、procfs [39]や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[40] が設定されており、/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)と呼ばれるプログラム群[41]を実行します。 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 [a]を生成するジェネレータ

systemd-getty-generator

カーネルコンソールを使用する serial-getty@.service Unit [b]を自動的に生成するジェネレータ

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 [c]を起動時に、 /usr/sbin/halt をシャットダウン時に実行するようにするためジェネレータ

systemd-system-update-generator

/system-update が存在する場合に、起動プロセスを system-update.target に自動的にリダイレクトするジェネレータ

systemd-sysv-generator

SysV init のスクリプトをSystemd上で実行するための Unit を自動的に生成するジェネレータ

[a] 標準状態のArmadillo-640では、-.mount と opt-license.mountが生成されます。

[b] 標準状態のArmadillo-640では、serial-getty@ttymxc0.serviceが生成されます。

[c] 標準状態のArmadillo-640では、 rc-local.service が生成されます。


次に 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

6.3. ルートファイルシステムのディレクトリ構成

Linuxシステムでのディレクトリ構成には、デファクトスタンダード(事実上の標準)となっている構成があります。 それぞれのディレクトリに何を格納するかということも、慣習的に決まっています。 それぞれのディレクトリには特定の役割がありますので、それを理解することで、ファイルを探す場合にどのディレクトリを探せばよいか、また、ファイルを追加する場合にどのディレクトリに置けば適切かということが分かります。

[注記]ディレクトリ構成の標準規格

ディレクトリ構成の標準規格としてFHS(Filesystem Hierarchy Standard : ファイルシステム階層標準)があります。

すべてのLinuxシステムがこの標準に従っているわけではありませんが、特別な理由がない限り、FHSに従ったディレクトリ構成とするのが望ましいでしょう。

Armadillo-600シリーズのルートファイルシステムの主なディレクトリの構成は、以下のようになっています。

表6.4 ディレクトリ構成

ディレクトリ ディレクトリの内容

/

ルートディレクトリ、ルートファイルシステムのマウントポイント

/bin

基本的なユーザーコマンドの実行ファイル

/boot

起動に必要なファイル

/dev

デバイスファイル

/etc

設定ファイル

/home

ホームディレクトリ

/home/atmark

atmarkユーザーのホームディレクトリ

/lib

基本的なライブラリ

/media

CD-ROMやUSBメモリなどのリムーバブルメディアのマウントポイント

/mnt

一時的にマウントするファイルシステムのマウントポイント

/opt

サードパーティが提供する追加データ・アプリケーション

/opt/license

Armadilloのライセンス情報

/proc

procfsのマウントポイント(プロセス情報)

/root

rootユーザーのホームディレクトリ

/run

再起動後に保持されない揮発性のランタイムデータ

/sbin

基本的なシステム管理用コマンドの実行ファイル

/srv

システム上で運用されているサーバが使うデータを格納するディレクトリ

/sys

sysfsのマウントポイント(システム情報)

/tmp

一時的なファイル

/usr

ユーザー共有情報ファイル

/usr/bin

必須でないユーザーコマンドの実行ファイル

/usr/sbin

必須でないシステム管理者用コマンドの実行ファイル

/usr/lib

必須でないライブラリ

/var

頻繁に更新されるファイル

/var/log

ログが保存されるディレクトリ


6.3.1. 実行ファイル

アプリケーションの実行ファイルは、/bin、/usr/bin、/sbin、/usr/sbinディレクトリに置かれます。

これらのディレクトリ内にあるファイルが、シェルでコマンドを入力したときに検索されます。 そしてコマンドと同じファイル名のファイルがこれらのディレクトリに合った場合、そのファイルが実行されます。

6.3.2. ホームディレクトリ

ユーザーごとのホームディレクトリは/homeディレクトリに用意されています。

Armadillo-600シリーズでは、atmark ディレクトリがあります。 rootユーザーでログインした場合のホームディレクトリは、/rootディレクトリになります。

6.3.3. ライブラリ

ライブラリファイルは/libまたは/usr/libディレクトリに置かれます。 共有ライブラリを使用するプログラムを実行する場合は、これらのディレクトリ内に共有ライブラリを置いておく必要があります[42]

6.3.4. デバイスファイル

/devディレクトリには、デバイスファイルが置かれます。

デバイスファイルは、デバイスを仮想的にファイルとして表したものです。 デバイスファイルに対して操作を実行することにより、デバイスを制御することができます。

例として、Armadillo-640では、/dev/ttymxc2はCON3/CON4のシリアルインターフェースのシリアルデバイスをファイルとして表したものです。 /dev/ttymxc2に対してデータの読み書きをすることで、シリアルデバイスからデータを受信/送信することができます。

6.3.5. プロセス、システムの状態

/proc、/sysディレクトリ内のファイルを操作することで、プロセス、システムの状態を参照、変更することができます。

/procにはprocfs、/sysにはsysfsがマウントされています。 procfs、sysfsはカーネル内部のデータ構造にアクセスすることができる機能を提供する仮想的なファイルシステムです。

6.3.6. ログ

カーネルメッセージやアプリケーションの動作ログなどは/var/logディレクトリに保存します。

6.3.7. 設定ファイル

設定ファイルは、/etcに置かれます。



[36] 標準設定の場合は、eMMCメモリです。microSD/SDカードも指定可能です

[37] Windowsでのフォルダと同様の概念です。

[38] HDD(ハードディスクドライブ)やUSBメモリなど

[39] 仮想ファイルシステムと呼ばれるもので、カーネル内部の状態がファイル内容に動的に反映されます。

[40] 115200 というのはボーレートです。 console=ttymxc4,115200 は /dev/ttymxc4 をボーレート 115200 で使用する、という意味になります。

[41] Generatorsは Unitの動的生成やUnitファイルへのシンボリックリンクの生成を行います。

[42] LD_LIBRARY_PATH環境変数を指定することによって、これらのディレクトリ以外に共有ファイルを置くこともできます。