AI支援デバイスツリー変更のレビュー：起動ログから実際のペリフェラルまで

ByLIU, ZHUOHUI

AI支援によるデバイスツリー変更は、ハードウェア記述の提案です。コンパイル成功はソースを変換できたことを示すだけで、ブートローダがそのツリーを読み込んだこと、正しいドライバが結び付いたこと、ペリフェラルが正しく動作することは証明しません。生成差分を、基板回路図、実行中カーネル、観測可能なペリフェラルトランザクションへ結び付けてレビューする必要があります。

以下のTMP102例では、仮想の基板と説明用に構成した生成コード風の断片を使います。AIツールの実行、基板起動、センサ測定の実績は主張しません。修正断片は意図的に不完全で、そのまま使える基板記述ではありません。

1. 基板の根拠資料を起草アシスタントへ渡す

正確な基板版と実装版、SoC、カーネルコミット、ベンダーパッチ、既存DTS/DTSIのインクルード構造、ブートローダの選択方法を提供します。バス、アドレス設定、電源、プルアップ、任意の割り込みが分かる回路図を添えます。実際にビルドするカーネルツリーのバインディングとドライバも提供してください。上流文書は参考になりますが、ベンダーカーネルは異なる可能性があります。

教材の前提として、TMP102はi2c2とラベル付けされたコントローラに接続され、7ビットアドレスは0x48、名前付き電源へ接続され、ALERTは未接続とします。レビューした初期バス速度は100 kHzです。これらは明示的なシナリオ入力であり、既存Obeita基板から推定した属性ではありません。

基板ファイルへの最小パッチ、追加する各プロパティの説明、依存関係一覧、検証計画を求めます。pinctrlグループ、GPIO番号、compatible文字列の創作は禁止します。インクルードされるSoCツリーにコントローラのクロックやリセットが定義済みなら、無関係な例から重複コピーせず、その構成を維持させます。

回路図とカーネルバインディングから配置DTB、実行中ツリー、ペリフェラル測定へつながる証拠の連鎖。
各確認段階が答える問いは異なります。ビルド成功は電気的動作を証明しません。

2. もっともらしい草案が誤っている理由を特定する

/* Deliberately flawed draft for an illustrative board. */
&i2c2 {
    status = "okay";
    clock-frequency = <1000000>;
    sensor@90 {
        compatible = "ti,tmp102";
        reg = <0x90>;
        interrupt-parent = <&gpio1>;
        interrupts = <7 2>;
    };
};

アドレスは典型的な表現の誤りです。0x90は7ビットアドレス0x48に対する書き込みアドレスバイトですが、子ノードのregにはバスバインディングが要求する表現を使う必要があります。データシートのトランザクションバイトをノードへコピーすると、別のアドレスを記述してしまいます。ユニットアドレスとregが一致していても、それだけでは弱い証拠です。

提供されたプロジェクト入力は1 MHzのバス速度を裏付けていません。ALERTが未接続なのに、割り込みプロパティは推測されています。数値の割り込みフラグは意味を隠し、別の割り込みコントローラのバインディングに属する可能性もあります。pinctrlや電源情報の欠落も重要になり得ますが、別の場所から正しく継承する基板もあります。あるプロパティが常に必須だと判断する前に、インクルード構造を確認します。

上流TMP102バインディングは、compatible、reg、任意の割り込み、label、vcc-supplyの具体的な根拠を提供しますが、この基板の配線は教えてくれません。この区別によって、構文の整ったAI回答が架空の回路図へ変わるのを防げます。

3. 最小限の修正断片を確認する

/* Partial teaching patch. Labels must exist in the board tree. */
&i2c2 {
    pinctrl-names = "default";
    pinctrl-0 = <&i2c2_board_pins>;
    clock-frequency = <100000>;
    status = "okay";

    temperature-sensor@48 {
        compatible = "ti,tmp102";
        reg = <0x48>;
        vcc-supply = <&sensor_vcc>;
        label = "board-ambient";
    };
};

この断片は、7ビットアドレス、意図的に選んだ初期速度、電源参照、架空の割り込みを追加しないという前提に従っています。pinctrlとレギュレータのラベルは、既存のレビュー済み基板定義を表す仮置きです。使用前に電圧、使用主体、イネーブル極性、シーケンスを確認します。定義が存在しない場合、その追加にはハードウェアの根拠を伴う別の変更が必要です。

修正はこの断片より小さくても構いません。既存の基板インクルードが正しいpinctrl状態やclock-frequencyを提供するなら、維持した方がよい場合があります。1つのセンサを有効にするためだけに、無関係なコントローラを再編し、共有電源を変え、overlayを導入するAI生成の整理変更を避けます。範囲の狭い差分ほど因果関係を確認しやすくなります。

4. 選定カーネルを検証し、次に起動成果物を確認する

実際のカーネルツリーでスキーマ検証を実行します。カーネルのバインディング検証ガイドは、スキーマ用dt_binding_checkとデバイスツリー用dtbs_checkを区別し、dtbs_checkが無効なスキーマをスキップする場合があると説明しています。バインディングを変えた場合は、それも検証します。完全なログを残し、新規失敗と既存問題を分けてください。

# Proposed checks in the exact configured kernel source tree:
make ARCH=<target-arch> CROSS_COMPILE=<tool-prefix> dtbs_check   DT_SCHEMA_FILES=hwmon/ti,tmp102.yaml

# On a target that exposes its live tree, with appropriate access:
dtc -I fs -O dts /sys/firmware/devicetree/base > running.dts
# Review the actual controller path, compatible, reg and supply.
# Discover the matching hwmon device; do not assume hwmon0.

コマンドは提案する手順であり、実行記録ではありません。アーキテクチャとツールチェーンの仮置きをプロジェクト値へ置き換えます。特定スキーマに限定した検証はレビューに有用ですが、基板ツリーの全相互作用を検証するものではありません。その後、プロジェクトのより広いDT検査とビルド要件を実施します。コントローラとセンサのドライバを有効にするカーネル設定も保持します。

生成DTBのファイル名とハッシュ、イメージへの組み込み手順、ブートローダ設定、配置先を記録します。ターゲットで実行中ツリーの関連プロパティを調べます。ソース名だけで起動内容を証明できると考えてはいけません。ブートローダが正当にプロパティを変える場合、実行中ツリーに同一ハッシュを求めるのも誤りです。想定変更を説明し、重要なハードウェアノードを比較します。

5. 起動ログで失敗している層を特定する

フィルタする前に完全なシリアル起動ログを取得します。カーネルと基板の識別情報、コントローラ登録、ドライバの有無、レギュレータやpinctrlのエラーを確認します。遅延probeは依存リソースが未準備であることを示す場合があり、直ちにcompatibleの誤りを意味しません。カーネルのドライバモデル文書は、必要なリソースが使えない場合の遅延probeを説明しています。

特定の成功メッセージを必須にしないでください。正常なドライバが何も出力しない場合もあります。デバイスとドライバの対応を調べ、名前とデバイス関係から正しいhwmonインスタンスを特定します。アダプタやhwmonの番号は変わり得ます。TMP102ドライバ文書には温度入力とその他の公開属性が示されています。数値を解釈する前に、適用されるインターフェース文書で単位を確認します。

6. 異常時を含め、実ペリフェラルを検証する

  • 識別と経路：実行中ノード、物理バス、結び付いたドライバが意図したセンサを指すことを示します。sysfsにディレクトリがあるだけでは、有用な測定の証拠として不十分です。
  • 制御した入力：安定条件で適切な独立基準と読値を比較し、安全で制御された温度変化を与えます。試験前にプロジェクト要件とセンサ仕様から許容差と安定時間を定めます。
  • 電気的動作：通信できない場合は適切な機器で電源電圧、該当するリセットやイネーブル動作、バス波形を確認します。ロジックキャプチャでアドレス、ACK、タイミングを確認しますが、それだけで測定精度は証明できません。
  • ライフサイクル：コールドブート、ウォームリブート、対応するサスペンド／レジュームの反復を計画します。センサが一貫して検出され、合意時間内に復帰するか記録します。
  • 異常処理：安全な治具で電源喪失やセンサ不在を模擬します。受入では、妥当そうなキャッシュ値を新しいデータとして出すのではなく、見えるエラーと復旧方針を要求します。

未知のハードウェアで無差別にバスをスキャンせず、結び付いたカーネルドライバと競合する生I2Cトランザクションも避けます。既定のドライバインターフェースと制御された診断手順を使ってください。起動実験の前に基準DTBと文書化した復旧経路を用意します。

7. 最終レビューに含めるもの

小さなDTS差分、回路図とプロパティの対応、正確なビルド入力、検証ログ、配置物の識別情報、完全な起動ログ、ペリフェラル試験証拠を納品します。提案試験は実行されるまで未実施と明記します。2つのAI草案の一致は、配線や動作の証拠の代わりにはなりません。

Obeitaのファームウェア／BSP診断サービスは、この立ち上げ工程に関連します。RK3566組み込み端末プロジェクトは関連BSPとペリフェラル統合の背景を提供しますが、この仮想TMP102パッチがそのプロジェクトに含まれた証拠ではありません。

類似投稿