この記事の前提
- C-5の「Boot ROMからアプリまで」の6段階を使います
- UARTの基礎とターミナル操作はA-2 シリアルコンソール編で扱っています
- 掲載ログは読み方を説明するための抜粋例です。特定ボードで採取した実測ログではありません
はじめに
前回（C-5）では、ブートを役割ごとの段階に分けました。今回はシリアルコンソールへ出るログから、どの段階まで進んだかを読み取る方法を扱います。
ブートログで大切なのは、全文を一行ずつ理解することではありません。まず境界となる行を探し、正常時との差分から調査範囲を絞ります。
接続前に確認すること
USB-UART変換器は、FT232R、CP210xなどの3.3V UART信号へ対応した製品を使います。同じチップ名でもモジュールの回路やジャンパー仕様が異なるため、製品資料でTX出力電圧を確認してください。
| 項目 | 設定・接続 |
|---|---|
| 信号電圧 | 3.3V UART。RS-232電圧の変換器は直接接続しない |
| 結線 | 変換器TX→ボードRX、変換器RX→ボードTX、GND→GND |
| Raspberry Pi 40ピン | GPIO14／物理8番、GPIO15／物理10番、GND／物理6番など |
| 通信設定 | まず115200bps、8bit、パリティなし、1stop、フロー制御なしを確認 |
| ログ | ボードへ電源を入れる前からファイル保存を開始する |
通常、ブートログの受信だけならVCC線は接続しません。ボードは正規の電源入力から給電し、USB-UART変換器とはTX、RX、GNDの3本を接続します。変換器からボードへ給電すると、逆流や電源容量不足など別の問題を作る可能性があります。
「3.3V／5V」ジャンパーが、信号電圧ではなくVCC端子の出力だけを切り替える製品もあります。ジャンパー表示だけで判断しないでください。
Raspberry Piでシリアルコンソールを有効にする
Raspberry Piでは、UARTハードウェアの有効化と、Linuxのシリアルコンソール設定は別です。最も安全なのはraspi-configで設定する方法です。
sudo raspi-config
Interface OptionsのSerial Portで、次を選びます。
- シリアル経由のログインシェルを有効にする
- シリアルポートのハードウェアを有効にする
- 再起動する
手動で確認する場合は、次の3点を分けて見ます。
-
/boot/firmware/config.txtのenable_uart=1 -
/boot/firmware/cmdline.txtにあるconsole=serial0,115200などのカーネル引数 -
serial-getty@serial0.serviceなど、ログインプロンプトを出すgetty
OS世代やイメージによってファイル位置と初期設定は異なります。cmdline.txtは原則1行なので、改行を追加せず既存行へ引数を加えます。
UARTの構成もモデルごとに異なります。Pi 4系にはPL011とmini UARTがあり、Pi 5系にはmini UARTがなく、RP1経由のPL011系UARTと専用デバッグUARTコネクタという構成です。Bluetoothとの割り当て変更が必要な場合だけdtoverlay=disable-btなどを検討します。まず/dev/serial0がどのUARTを指しているかを確認し、過去記事の設定をそのまま適用しないことが大切です。
最新のモデル別構成とearlycon指定は、Raspberry Pi公式UART資料で確認できます。
Orange PiやほかのSBCも、シリアルコンソールの有効／無効、UART番号、ピン、ボーレートはイメージとBSP次第です。「Armbianだから必ず有効」とは決めつけず、対象ボードの資料とカーネルコマンドラインを確認します。
正常ログから境界を拾う
次はAllwinner系ボードとU-Bootで見られる形式を簡略化した説明用ログです。バージョン、文言、順序はBSPによって変わります。
U-Boot SPL 20xx.xx (...)
DRAM: 512 MiB
Trying to boot from MMC1
U-Boot 20xx.xx (...)
Loading Environment from FAT... OK
Hit any key to stop autoboot: 0
Found U-Boot script /boot.scr
Retrieving file: /Image
Retrieving file: /sun8i-h3-example-board.dtb
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 6.x.x (...)
[ 1.234567] mmc0: new high speed SDHC card
[ 2.345678] VFS: Mounted root (ext4 filesystem) readonly
[ 2.456789] Run /sbin/init as init process
...
Welcome to Linux
example-board login:
すべての行を暗記する必要はありません。次の境界を探します。
| 境界の例 | そこまでに分かること |
|---|---|
U-Boot SPL |
Boot ROMが次段を読み込み、UART出力可能な地点まで進んだ |
DRAM: ... |
DRAMを利用でき、容量を報告できる段階へ進んだ |
U-Boot 20xx.xx |
U-Boot properへ制御が移った |
Starting kernel ... |
ブートローダーがカーネルへ制御を渡した |
Booting Linux on ... |
カーネルのコンソール出力を確認できた |
VFS: Mounted root ... |
rootfsのマウントに成功した |
Run /sbin/init ... |
PID 1の起動へ進んだ |
login: |
gettyまで起動した。製品アプリの正常性とは別 |
login:が出たことはLinuxユーザーランドが動いた証拠ですが、製品アプリが正常とは限りません。反対に、ログインを無効化した製品では正常でもlogin:は出ません。
症状別に最初の確認点を決める
1文字も出ない
最初に、UART側を切り分けます。
- GND共有、TX／RXの交差、3.3V信号、ボーレートを確認する
- ボード資料でUARTピンとpinmuxを確認する
- 正常な3.3V UART機器やループバックで変換器を確認する
- UARTコンソールが有効になる段階と出力先を確認する
無表示だけでBoot ROM停止とは断定できません。UARTが未設定、別ポートへ出力、セキュア設定で無効、正常起動後にコンソール無効という可能性もあります。LED、HDMI診断、ネットワーク応答、消費電流も組み合わせます。
SPL／FSBL付近で止まる
初期化または次段ロードを疑います。既製ボードなら、イメージの対応モデル、基板リビジョン、ブートメディアを確認します。SoCから設計した基板では、DRAM、クロック、電源シーケンスも調査対象です。
U-Bootまでは動くがカーネルを開始できない
U-Bootシェルを使える構成なら、環境変数、ストレージ認識、ファイル名、ロードアドレスを確認します。
printenv
printenv bootargs
ls mmc 0:1 /などのファイル確認コマンドは、U-Bootのビルド設定やファイルシステム対応によって利用可否が異なります。
Starting kernel ...の後で沈黙する
カーネルが止まった場合と、コンソール設定が切り替わった場合を分けます。
-
console=のデバイス名とボーレート - DTBのUARTノードとpinmux
- カーネルに対象UARTドライバが入っているか
- プラットフォームに合う
earlycon設定
earlyconのアドレスやドライバ名はSoC固有です。別モデルの値をコピーすると、起動を妨げる場合もあります。
VFS: Unable to mount root fsが出る
root=、パーティション、ストレージ／ファイルシステムドライバ、initramfs、rootfsの破損を確認します。PARTUUID=を使う構成では、複製やパーティション再作成による値の変化にも注意します。
PID 1以降で失敗する
カーネルブートではなくサービス層の問題です。ログインできる場合は、次から確認します。
systemctl --failed
journalctl -b
基準ログを資産にする
正常ログには、次の情報を一緒に残します。
- ボード名と基板リビジョン
- OS／BSP、ブートローダー、カーネルの版
- イメージのハッシュまたはビルド番号
- UARTポートと通信設定
- 取得日時と電源条件
異常ログとdiffを取れば、消えた初期化、変わった容量、タイムアウトの追加などが見つけやすくなります。ログにMACアドレス、シリアル番号、SSIDなどが含まれる場合は、社外共有前に匿名化します。
現在のシリアル設定を確認する
起動済みLinuxで次を実行し、実際のコンソール指定を確認してください。
cat /proc/cmdline
readlink -f /dev/serial0 2>/dev/null || true
systemctl status serial-getty@serial0.service --no-pager
コマンドやデバイス名はディストリビューションによって異なります。存在しない場合も、それ自体が構成を知る手がかりです。
まとめと次回
- USB-UARTは3.3V信号とGNDを確認し、通常はTX／RX／GNDの3線で接続する
- 正常ログから、SPL、U-Boot、kernel、rootfs、PID 1の境界を拾う
- 無表示を停止と決めつけず、コンソール設定と別の観測手段を確認する
- 基準ログにはハード、BSP、設定、取得条件を添えて保存する
ログに登場する.dtbは、基板の構成をカーネルへ伝えます。次回C-7では、このDevice Treeを読み解きます。