Embedded Linuxラボの構築に高価な機器は必要ありません。まずハードウェアなしでQEMUから始め、次にドキュメントが充実したボードと3.3V USB-to-serialアダプターを追加し、さらにロジックアナライザーを加え、実際に問題が発生した場合にのみJTAGデバッガーを導入します。各段階で具体的な実践スキルが身につき、この順序で投資することで、買い物ではなく学習に集中できます。
Embedded Linuxを学びたい人の多くは、最初の1ヶ月を何を買うかの決定に費やします。これは最初の質問として誤りです。良いEmbedded Linuxラボとは、ボードの起動、シリアルコンソールへの接続、周辺機器の立ち上げ、トラブルシューティングといった分野のコアタスクを練習できる、小規模で意図的なツールセットです。価値は所有するハードウェアではなく、実行できるタスクにあります。本チュートリアルでは、4段階で最も安価な順にラボを構築し、各段階で習得できるスキルを明記します。
Embedded Linuxラボが重要な理由
ドキュメントを読むだけでは、シリアルケーブルを接続して何も表示されず、ボーレート、配線、カーネルがコンソールまで到達していないのかを判断しなければならない状況で何をすべきかを教えてくれません。Embedded Linuxラボは、自分の時間でそのようなミスを繰り返し、実際の再現可能な練習を積む場所を提供します。以下で示す各段階は今週中にセットアップ可能で、それぞれ「このボードを起動した、コンソールは無音だった、ここまで追跡した」と具体的に言える状態にします。
必要なもの
本チュートリアルはLinuxホストを前提としています。UbuntuまたはDebianを例に示します。Windowsの場合はWSL2を使用し、その中で同じコマンドを実行してください。開始前にホストツールを一度インストールします：
[email protected]:~$ sudo apt update
[email protected]:~$ sudo apt install build-essential git bc libncurses-dev qemu-system-arm picocom i2c-tools
Enter fullscreen mode Exit fullscreen mode
この一式で以下のすべての段階をカバーします：build-essential、git、bc、libncurses-devはBuildrootのビルドとmake menuconfig用、qemu-system-armはStage 1用、picocomはStage 2のシリアルコンソール用、i2c-toolsはStage 3用です。
Stage 1: 何も買う前にQEMUから始める
最も安価なボードは「ボードなし」です。QEMUはノートPC上で完全なARMまたはARM64 Linuxシステムを起動できるため、ビルドとブートのワークフローを無料で学べます。最初の数週間はここに費やすべきです。BuildrootはQEMUマシンをターゲットにした既製の設定を用意しています。Linuxホスト上で：
[email protected]:~$ git clone https://git.buildroot.net/buildroot
[email protected]:~$ cd buildroot
[email protected]:~$ make list-defconfigs | grep qemu
[email protected]:~$ make qemu_aarch64_virt_defconfig
[email protected]:~$ make menuconfig
[email protected]:~$ make
Enter fullscreen mode Exit fullscreen mode
make menuconfigのステップでは、最初はデフォルトを受け入れます。これは後でオプションを変更するためのものであり、今すぐ編集する必要はありません。ビルドが完了すると、カーネルイメージとルートファイルシステムが生成されます。最も簡単な起動方法は、Buildrootが出力ディレクトリに書き込む即実行可能なstart-qemu.shスクリプトです：
[email protected]:~$ ./output/images/start-qemu.sh
Enter fullscreen mode Exit fullscreen mode
完全なコマンドを確認したい場合は、以下の直接呼び出しと同等です：
[email protected]:~$ qemu-system-aarch64 -M virt -cpu cortex-a53 -nographic -kernel output/images/Image -append "rootwait root=/dev/vda console=ttyAMA0" -drive file=output/images/rootfs.ext4,if=virtio,format=raw
Enter fullscreen mode Exit fullscreen mode
-nographicのQEMUセッションを終了するには、Ctrl-Aを押してからxを押します。これだけで、カーネル設定、設定変更後の再ビルド、ターゲット向けのクロスコンパイルを練習できます。ここで身につけるスキル — クロスコンパイル、カーネル設定、ルートファイルシステムの組み立て — は、BSP（Board Support Package）業務に必要なものと同じです。QEMUが教えられないのは実際のハードウェア動作のみで、それはStage 2で扱います。
試してみる → お金を使わずにBuildrootイメージをQEMUでビルド・起動し、パッケージを1つ追加して再ビルドしてみてください。記憶だけで実行できれば、実機ボードの準備ができています。
Stage 2: 最初のボードとシリアルコンソール
ハードウェアに移行する際は、速度よりもドキュメントとメインラインサポートを優先してください。完全なテクニカルリファレンスマニュアルとアップストリームカーネルを持つボードは、ブートプロセスが一部非公開の高速ボードよりもクリーンなワークフローを教えてくれます。
BeagleBone Blackは有力な最初の選択肢です：Texas Instruments AM335x SoC（シングルコア Cortex-A8）、メインラインカーネルとU-Bootでサポートされ、回路図までドキュメント化されています。Raspberry Pi 4または5も動作しコミュニティが大きいですが、ARMコアが動作する前に独自のVideoCoreファームウェア段階から始まるため、標準的なEmbeddedブートフローについてはあまり学べません。どちらも問題ありません。それぞれが何を教えているかを理解してください。
ボードの次に最も重要なツールは3.3V USB-to-TTLシリアルアダプターです。これでデバッグコンソール — ネットワークが存在する前にU-Bootやカーネルが出力する情報 — に到達できます。FT232R、CP2102、PL2303チップを搭載した安価なアダプターで十分です。必ず3.3Vアダプターを使用してください：5VアダプターはボードのUARTピンを損傷する可能性があります。
ボードのデバッグ用シリアルヘッダー（BeagleBone Blackでは6ピンJ1ヘッダー）に3本の線を接続し、TX/RXをクロス接続します：アダプターTX → ボードRX、アダプターRX → ボードTX、GND → GND。アダプターのVccまたは5Vピンは接続しないでください — ボードは自己給電です。その後、ターミナルを開きます：
[email protected]:~$ picocom -b 115200 /dev/ttyUSB0
Enter fullscreen mode Exit fullscreen mode
権限エラーで失敗した場合は、ユーザーがdialoutグループに所属していません。一度追加して再ログインしてください：
[email protected]:~$ sudo usermod -aG dialout $USER
Enter fullscreen mode Exit fullscreen mode
デバッグコンソールは115200ボー、8データビット、パリティなし、1ストップビット（8N1）で動作します。minicomやscreen /dev/ttyUSB0 115200でも同じ作業が可能です。一部のアダプターは/dev/ttyUSB0ではなく/dev/ttyACM0として表示されます。初めてボードに電源を入れてU-Bootの出力が表示された時点で、理論から実践的なEmbedded作業に移行したことになります。
試してみる → 実機ボードでシリアルコンソールを取得し、U-Bootのカウントダウン中に割り込んでください。U-Bootプロンプトで停止し、環境変数を読み取る方法を学ぶことは、すべてのプロジェクトで役立つスキルです。
Stage 3: 実際の周辺機器との通信
ボードが起動したら、次のスキルはデバイスを接続し、Linuxから制御することです。I2Cバス上の安価なセンサーブレークアウトボード（TMP102温度センサーなど）で十分です。まず、カーネルが公開しているI2Cバスを一覧表示し、正しいバス番号を使用します（番号は必ずしもヘッダーラベルと一致しません）：
[email protected]:~$ sudo i2cdetect -l
i2c-1 i2c OMAP I2C adapter I2C adapter
Enter fullscreen mode Exit fullscreen mode
次に、そのバスをスキャンしてデバイスを探します。I2Cデバイスノードはデフォルトでworld-accessibleではないため、sudoを使用します：
[email protected]:~$ sudo i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
...
40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- --
Enter fullscreen mode Exit fullscreen mode
アドレスが表示された場合（ここでは0x48）、デバイスが正しく配線・給電されていることがわかります。スキャン結果がダッシュのみの場合は、配線が誤っているかバスが有効化されていない可能性があります — 多くのボードでは、I2Cコントローラーとそのピンはデバイスツリーで有効化する必要があります。
次に、デバイスツリーを通じてデバイスをカーネルに記述し、ドライバーが要求できるようにします。必須部分はI2Cコントローラーの子ノードで、デバイスのcompatible文字列とバスアドレスをregで指定します。デバイスツリーオーバーレイとして以下のように記述します：
&i2c1 {
status = "okay";
tmp102@48 {
compatible = "ti,tmp102";
reg = <0x48>;
};
};
Enter fullscreen mode Exit fullscreen mode
オーバーレイのコンパイルとロードはボード固有であり、独自に学ぶ価値がありますが、効果はどこでも同じです：一致するドライバーがバインドされると、デバイスがsysfsにバスとアドレスで表示されます：
[email protected]:~$ ls /sys/bus/i2c/devices/
1-0048 i2c-1
Enter fullscreen mode Exit fullscreen mode
これは非常に低コスト — 数個のセンサーモジュールとジャンパーワイヤー — ですが、ここでデバイスツリーとドライバーのスキルが実践的になります。デバイスをデバイスツリーに追加し、カーネルがドライバーをバインドする様子を観察することは、まさにボード立ち上げ作業そのものです。
Stage 4: ロジックアナライザーとJTAGデバッガー
最後の2つのツールは、コンソールでは原因がわからない問題が発生した場合に使用します。必要になるまで購入せず、問題が発生した時点で購入してください。
低コストのUSBロジックアナライザーは、I2C、SPI、UARTライン上の実際の信号を観察できます。オープンソースのsigrokプロジェクトとそのフロントエンドPulseViewは、多くの安価なアナライザーを駆動し、プロトコルをデコードできます。センサーが意味不明な値を返す場合、アナライザーはバスが期待通りのビットを生成しているかどうかを示し、推測を測定に変えます。
JTAGまたはSWDデバッガーは最後に導入します。OpenOCDとFTDIベースのプローブまたはJ-Link — または独自のGDBサーバーを内蔵しOpenOCDを必要としないBlack Magic Probe — を使用することで、プロセッサを停止させ、低レベルコードをステップ実行できます。これは主に、コンソールが有効になる前のブートローダーやカーネル起動直後のデバッグに役立ちます。初心者が最初の数ヶ月で必要とすることは稀なので、初期購入にはすべきではありません。
基本的なデジタルマルチメーターは作業台に常備する価値があります：電圧レールや導通を確認することで、「反応しない」ボードの原因をソフトウェアツールより迅速に特定できることが多いです。これらのツールがサポートする完全なボード立ち上げとドライバーワークフローを深く学びたい場合は、Embedded Linux Mastery Trackがその核心です。
試してみる → 初日からロジックアナライザーやJTAGプローブを購入しないでください。実際にバグが発生し、それらが必要だと感じた時点で追加してください — 必要に迫られてからの方が、ツールの理解が深まります。
主要なポイント
- 無料： すでに所有しているPC上のQEMUとBuildrootで、投資前に完全なビルド＆ブートワークフローを学べます。
- 低コスト： 最初の購入は、ドキュメントが充実しメインラインサポートされたボードと3.3V USB-to-serialアダプター — デバッグコンソール（115200 8N1）はすべてのプロジェクトで使用するツールです。
- 低コスト： 数個のセンサーブレークアウトボードとジャンパーワイヤーで、デバイスツリーとドライバーの知識を実践スキルに変換できます。
- 必要になったら購入： ロジックアナライザー、そして後でJTAGまたはSWDプローブは、バグが発生し必要だと感じた時点で追加します。
- 各購入は学習したいタスクに基づいて決定し、基本的なマルチメーターは常に役立ちます。
よくある質問
Embedded Linuxの学習開始にハードウェアの購入は必要ですか？
不要です。QEMUはPC上で完全なARMまたはARM64 Linuxシステムを起動でき、BuildrootはQEMU向けの既製設定を提供しているため、ハードウェアなしでクロスコンパイル、カーネル設定、ルートファイルシステム構築を学べます。
最初にどのボードを購入すべきですか？
速度よりもドキュメントとメインラインサポートを優先してください。BeagleBone Blackのような完全にドキュメント化されメインラインサポートされたボードは、独自ファームウェアからブートプロセスが始まるRaspberry Piよりもクリーンなワークフローを教えてくれます。どちらも動作します。学びたい内容に適したドキュメントが充実したものを選んでください。
ボードの次に最も重要なツールは何ですか？
3.3V USB-to-TTLシリアルアダプターです。ネットワークが存在する前にU-Bootやカーネルが出力するデバッグコンソールに到達できます。ボードを損傷しないよう、5Vではなく3.3Vアダプターを使用してください。
初心者にJTAGデバッガーは必要ですか？
不要です。JTAGまたはSWDデバッガーは主にブートローダーや起動直後のデバッグに役立ち、最後の購入にすべきです。シリアルコンソールでは説明できない問題が発生した時点で追加してください。
参考文献
- Buildrootユーザーマニュアル — defconfig、QEMUターゲット、パッケージの追加。
- Buildroot qemu_aarch64_virt_defconfig — 上記で使用した正確な設定。
- BeagleBone Blackドキュメント — リファレンスマニュアル、ヘッダー、シリアルデバッグ。
- sigrok / PulseView — オープンソースロジックアナライザーソフトウェアとプロトコルデコーダー。
- OpenOCDドキュメント — 一般的なプローブを使用したJTAG/SWDデバッグ。
Originally published on TECH VEDA.
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.