カスタムLinux基板の立ち上げ：電源からアプリケーションまで

ByLIU, ZHUOHUI

カスタムLinux基板は、ログイン画面が出ただけでは立ち上げ完了ではありません。正しい電源・リセットから、検証済み起動イメージ、動く周辺ドライバー、想定故障から復帰できるアプリケーションまで、再現可能な連鎖が必要です。

本稿はDevice Treeを使う組み込みLinux基板、特にARM・AArch64向けの段階的立ち上げ案です。具体的な順序はSoCのROM、電源管理IC、DDR初期化パッケージ、メーカーBSPで決まります。以下は提案する技術確認であり、特定製品の実測結果ではありません。

1. 証拠と復旧経路を準備する

通電前に、回路図、実装版、代替部品、電源系統、DDR配線構成、起動ストラップ、端子配置を集めます。配置が電気的に同等だと仮定せず、実装基板をリファレンスと照合します。組み立て後もアクセスできるデバッグ端子を確認します。

適切な電流制限電源、定格の合う測定器、確認済みシリアルアダプター、メーカーの復旧手段を用意します。TTL UARTは基板の電圧域に合わせ、RS232アダプターとは区別します。管理できない負荷を外し、USBやデバッグ端子からの意図しない給電を確認します。

基板番号、ハードウェア版、イメージハッシュごとに記録します。通電開始からシリアル出力を保存し、ジャンパー設定、完全なコールドスタートかソフトウェア再起動かも記載します。保持された周辺状態を初期化成功と誤認しないためです。

Linux基板立ち上げの6段階：電源・リセット、ROM・ローダー、DDR・記憶装置、カーネル・DTB、ルートファイルシステム、アプリケーション・復旧。
段階確認の例。前段の証拠と復旧可能な失敗経路を確認してから次へ進みます。

2. 電源、リセット、クロックを確立する

通電前にハードウェア担当の手順で抵抗と明らかな実装不良を確認します。通電後は採用部品の仕様に対して電圧と順序を測定します。電源安定・クロック準備とリセット解除の関係を波形で捉えます。テスターの数値だけでは起動順序や短い過渡変動は確認できません。

電流が想定外なら反復起動せず停止して調べます。シリアルが無出力なら、電圧、ピン多重化、速度、起動元を確認します。ROM自体が表示しない場合もあります。文書化された復旧モードの認識などを使い、ROMが動かないのかUARTが静かなだけかを分けます。

任意のソフトウェア遅延で電気問題を隠さないでください。遅延は切り分けに使えても、最終要件では本当の依存関係と許容時間を示すべきです。

3. 最初のローダー、DDR、起動ストレージを確認する

起動チェーンの全実行段階を特定します。ROMからSPL、メーカーDDR初期化、安全ファームウェア、U-Bootへ進む構成などがあります。版と格納オフセットを記録します。Linux障害に見えて、別のDDRトレーニング部品をイメージへ組み込んだことが原因の場合もあります。

アプリケーション負荷の前に、メーカーのDDR検証と安全なメモリーテストを実施します。実行中ローダー、予約ファームウェア、診断バッファーを破壊的に試験しないでください。合意条件でコールドスタートを反復します。ウォーム起動成功は冷状態のDDR初期化を証明しません。

eMMC、SDなどでは認識、容量、バス設定、パーティションを確認します。文書化した非破壊的方法で読み戻しと書き込みイメージを比較します。高速時だけ失敗するなら、恒久的な低速化を解決とする前に、信号品質、電圧切替、タイミング、ドライバーを調べます。

4. 正しいハードウェア記述をLinuxへ渡す

Device Treeは構成と資源を記述するもので、欠けたドライバーを生成したり配線を修理したりはしません。クロック、レギュレーター、リセット、割り込み線、端子設定を実装基板と一致させます。LinuxのDevice Tree利用モデルは識別、実行時設定、デバイス生成での役割を説明しています。

カーネル、DTB、モジュール、ファームウェアを一つの版管理された組として扱います。参考基板のDTBでも起動できる一方、電源や割り込みが誤っている場合があります。対象ソースツリーのスキーマで検証します。バインディング文書はスキーマ自体とDTデータの検査を区別しています。

# Run in the configured kernel source tree with its required tooling.
make dt_binding_check
make dtbs_check

これらは構造・バインディング問題を検出しますが、実配線との一致までは保証しません。メーカーのカーネルには古いスキーマや未文書化拡張があり得ます。意味を理解せず警告を消さず、差を記録します。

AArch64では、イメージ配置、Device Tree、プロセッサー状態にも起動引き渡し条件があります。他基板のロードアドレスをコピーせず、対象カーネルのAArch64起動規約を参照します。

5. カーネルとルートファイルシステムの準備を分ける

カーネルは開始するのにルートをマウントできない場合は、ルート識別子、ストレージドライバー、ファイルシステム対応、initramfsの前提を調べます。ルート内にだけ存在するモジュールは、前段のユーザー空間で読み込まれない限り、そのルートのマウントには使えません。最後のpanicだけでなく最初のエラーを保存します。

ユーザー空間開始後は、想定init、書き込み場所、デバイス権限、時刻初期化、サービス依存を確認します。稼働中のカーネル、モジュール、アプリケーションをリリース一覧と照合します。SSHログインだけでストレージ、ネットワーク、周辺機器の全要件達成とは判断しません。

6. 周辺経路を一つずつ立ち上げる

コネクター表示とLinux名、ドライバー名、用途を結ぶ表を作ります。各機器で認識、基本動作、想定負荷、対応する切断動作、再起動を試験します。画面にはパネルタイミングとバックライト、タッチには独自の割り込み・座標確認が必要で、一方の成功は他方の検証にはなりません。

probe失敗時は最初の依存エラーを確認します。電源、クロック、リセット、ファームウェア不足が後段でドライバー不良に見えることがあります。全ログではなく対象を絞ります。対応設定があればLinux dynamic debugでモジュール、ファイル、関数単位の出力箇所を選べます。

7. アプリケーション納品前に復旧を試験する

  • 任意周辺機器を意図的に不在にし、必須サービスが定義した準備状態になるか確認します。
  • 動作中に試験ネットワークを切り、有限の再試行と二重コマンドなしの復帰を確認します。
  • 管理された試験パーティションで容量不足を発生させ、ログがアプリケーション必須領域を使い尽くさないか確認します。
  • 復旧可能なベンチ機で、唯一の復旧経路を消さずに更新中断・破損イメージを試験します。
  • コールドブート、ウォームリブート、必要な休眠復帰を繰り返し、条件と失敗を記録します。

ramoopsで故障を保存するなら、適切なメモリーを予約し、対象リセットで保持されるか確認します。電源断時の保存保証ではありません。ramoops文書を参照し、採取できた内容と未試験範囲を示します。

基板立ち上げの具体的な範囲

ObeitaのRK3566組み込み端末・BSP適合プロジェクト構成は、特定パネルとFPC周辺機器を扱い、引き出し済みインターフェースと改板が必要なものを明確に分けています。SoCの全機能が実装製品で使えると想定せず、この境界で計画します。

ファームウェア・BSP診断には、基板版、回路図、完全なコールド起動ログ、イメージ一覧、最初に失敗する段階を用意してください。「Linuxが動かない」より、明確な段階境界が有用です。

類似投稿