U-Boot移植の受け入れ：起動媒体、環境変数、復旧

U-Boot移植は、プロンプトが動くだけでなく、起動と復旧の仕組みとして受け入れるべきです。意図した媒体を選び、正しいソフトウェア一式を読み込み、不正な永続状態を処理し、主イメージが起動しないときの文書化された復旧方法を備える必要があります。

本チェックリストは、組み込みLinuxの起動チェーンでU-Bootを使う製品向けです。コマンド、保存先、初段ローダー、安全機能は版と基板設定で異なります。例は受け入れ設計であり、特定のObeita基板の合格実績ではありません。

1. 移植に含むものを明確にする

SoC ROM、SPLまたはメーカー初段ローダー、DDR初期化、信頼されたファームウェア、U-Boot本体、Linuxへの引き渡しを列挙します。各要素の担当と版を定めます。専用DDRバイナリーが必要なら、許可された配布方法と対応する正確なメモリー構成を示します。

対応する基板版と起動媒体を定義します。「eMMCとSD対応」だけでは、SDが開発専用、自動代替、許可された現場復旧のどれか分かりません。ストラップ、着脱媒体、設定の相互作用を書き、ROMの媒体選択とU-Bootのカーネル・bootflow選択を区別します。

セキュアブート、署名更新、ロールバック防止、コンソール制限を含むか合意します。これらは全体設計が必要で、ビルドオプションだけで信頼チェーンが完成するわけではありません。

2. 競合する入力で媒体方針を試験する

各媒体のコントローラー識別子、番号、パーティション、イメージ位置、ファイルシステムを記録し、実際の認識機器を起動ログに残します。U-Boot番号とLinux名が常に一対一とは限りません。

通常媒体のみ、復旧媒体のみ、両方あり、どちらにも正常アプリケーションなしを試験します。優先度確認には見分けられる二つのビルドを使います。同一表示では誤った媒体から起動しても成功に見えます。コールドブートとウォームリセットの双方で確認します。

Standard Bootを使う場合は、有効な機器、方式、探索方針を記載します。設定可能な枠組みであり、すべてのビルドが全媒体・形式に対応する保証ではありません。対象版のU-Boot Standard Boot文書を参照します。

対象ビルドにあれば、次の読み取りコマンドを一覧取得に使えます。機器選択や詳しいストレージ調査は基板固有です。

version
bdinfo
printenv bootcmd bootargs bootdelay
mmc list

出力をリリース記録に保存します。他基板の消去、書き込み、環境初期化コマンドをコピーしないでください。誤った位置への操作で唯一の起動可能コピーを失う恐れがあります。

3. 環境変数を管理されたインターフェースにする

永続環境の場所、容量、冗長性、消去単位、パーティション配置との関係を記載します。組み込み既定値、現在値、不揮発メモリーへ保存済みの値を分けます。U-Bootではメモリー内変更と保存は別操作です。環境変数文書を参照してください。

起動方針、開発用設定、個体識別に分類します。工場初期化で固有ID、校正、製造設定を誤って複製・削除してはいけません。現場担当が変更できる項目と、非対応値の拒否・復旧を定義します。

復旧可能な試験機で、環境なし、整合性異常、環境更新中断を試します。どの既定値・冗長コピーを選ぶか、作業者がどう識別するかを期待結果にします。保存先と更新順序が想定電源断を扱える場合にだけ冗長化は有効です。

古い正常環境からの移行も試験します。新バイナリーが旧起動コマンドを読み続け、新既定値を迂回することがあります。U-Boot再書き込みで永続値も初期化されると仮定せず、環境スキーマや移行方針をリリース手順に含めます。

4. Linuxへの引き渡し全体を検証する

カーネル、Device Tree、任意のinitramfs、ルートファイルシステムの識別を一体管理します。ロード領域相互、予約ファームウェア、解凍領域が重複しないことを確認します。小さい開発用だけでなく、許容最大イメージで繰り返します。

最終カーネル引数が正しいルートとコンソールを選び、基板識別とメモリー情報が正しく渡るか確認します。成功は製品定義のアプリケーション準備状態までです。初期カーネル表示だけではファイルシステムやアプリケーションを検証できません。

署名設計ではベンチ復旧計画の下で、正規署名イメージと保護内容を改変したものを試験します。U-Boot Verified Boot文書は信頼チェーン内の署名検証を説明します。チェックサムは偶発破損の検出であり認証の代用ではなく、署名だけでは旧版への巻き戻し防止にもなりません。

5. 失敗回数と意味のある成功判定を定義する

試行カウンターは保存先とリセット動作に合わせます。増分対象、永続化、クリア時点を決めます。Boot Count文書は上限と代替起動、実装依存の保存を説明します。変数名だけで機能を推測せず、実ビルドで確認します。

必要なヘルスチェックの成功後にだけ更新試行状態を解除します。init起動時では、制御アプリケーションが機器を開けなくても正常判定され得ます。逆に外部サーバー必須の判定は、ローカルでは正常な機器を誤って戻す場合があります。製品要件から成功境界を決め、ローカル準備と任意のネット接続を分けます。

正常な別スロット、専用復旧イメージ、明確な保守経路など、有限の方針を選びます。証拠を失い、保存装置を摩耗させるだけで復帰しない無限再起動を避けます。

6. 明示的な故障マトリクスを実行する

• カーネルなし：識別可能な理由を報告し、合意した代替経路へ移ります。
• 誤った・破損したDTB：設計が検証対応なら非互換な組を拒否し、そうでなければ復旧可能な失敗経路に入ります。
• ルート使用不能：カーネル開始だけで更新成功にしません。
• 更新中断：合意した各中断点で、正常イメージか復旧方法が残ります。
• ネットワーク不在：開発ネット起動と製品フォールバックに時間制限があります。
• 復旧操作：権限のある作業者が最終筐体・配線状態で実行できます。

全媒体喪失が明示的な対象で、外部復旧を実証済みでなければ、全冗長コピーを同時に上書きしません。台数、中断位置、結果を記載します。選択した試験への合格は任意の電源断への耐性証明ではありません。

7. 基板を復旧できる情報を納品する

ソース版、defconfig、パッチ、ビルドツール、完成イメージとハッシュ、保存配置、環境方針、試験証拠、段階的復旧説明を含めます。物理アクセス、メーカー工具、別管理の署名サービスが必要な段階を明示します。秘密署名鍵を通常のリリースアーカイブへ入れてはいけません。

ObeitaのRK3528 Linuxネットワークゲートウェイ構成は、復旧アクセスと電源・OTGの分離を説明します。関連範囲の例であり、本稿の全U-Boot機能実装を意味しません。ファームウェア・BSP診断のレビューには、起動ログ、保存配置、復旧手順を準備してください。