审查AI辅助设备树修改：从启动日志到真实外设

作者LIU, ZHUOHUI

AI辅助生成的设备树修改，本质上是一份硬件描述建议。编译成功，只能说明源文件能够转换；它并不能证明引导程序加载了该设备树、正确驱动已经绑定，或外设行为正常。审查必须把生成的差异补丁与板卡原理图、运行中的内核和可观察的外设事务联系起来。

以下TMP102示例采用假设板卡及专门构造的生成式代码片段。本文不声称执行过AI工具、启动过板卡或测量过传感器。修正片段有意保持不完整，不能直接用作板级描述。

1. 向起草助手提供板卡证据

提供确切的板卡与装配版本、SoC、内核提交、厂商补丁、现有DTS/DTSI包含链及引导程序选择设备树的机制。附上展示总线、地址绑定位、电源轨、上拉电阻和可选中断的原理图页面。同时提供实际构建的内核树中的绑定与驱动。上游文档可以指导审查，但厂商内核可能有所不同。

本教学示例假定：原理图将TMP102连接到标为i2c2的控制器，七位地址配置为0x48，传感器连接到一个已命名的电源，ALERT未连接；经审查选定的初始总线速率为100 kHz。这些都是明确的场景输入，并非根据任何现有欧蓓特板卡推断出的属性。

要求只对板级文件作最小修改，解释每个新增属性，并提供依赖清单与验证计划。禁止臆造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是七位地址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";
    };
};

该片段遵循所述场景：七位地址、明确选定的初始总线速率、电源引用，以及不添加虚构中断。pinctrl与稳压器标签代表现有、已审查的板级定义。使用前，应确认它们的电气电压、使用归属、使能极性和上电顺序。如果这些定义不存在，新增定义需要另一项有硬件依据的修改。

实际修正也可能比这个片段更小。如果现有板级包含文件已经提供了正确的pinctrl状态或clock-frequency，保留原设置可能更合适。避免为了启用一个传感器，就接受AI生成的无关控制器重组、共享电源修改或新overlay结构。范围集中的差异补丁更容易建立因果关系。

4. 先验证选定内核，再验证选定启动产物

在实际内核树中执行schema验证。内核的绑定验证指南区分了用于schema的dt_binding_check和用于设备树的dtbs_check，并指出dtbs_check可能跳过无效schema。如果修改了绑定，也应验证绑定。保留完整日志，并区分新增失败与既有问题。

# 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.

这些命令是建议步骤，不是执行记录。请将架构与工具链占位符替换为项目实际值。按schema筛选的检查有助于审查，但不能验证板级设备树中的所有相互影响。之后仍应执行项目更全面的设备树检查与构建要求。保留启用控制器和传感器驱动的内核配置。

记录构建的DTB文件名与哈希值、镜像打包步骤、引导程序配置和部署存储位置。在目标机上，检查运行中设备树的相关属性。不要认为源文件名就能证明实际启动内容；如果引导程序合理地修改了属性，也不要要求运行中设备树具有完全相同的哈希。应说明预期修改，并比较真正重要的硬件节点。

5. 用启动日志定位失败层级

先采集完整串口启动日志，再进行筛选。确认内核身份、板卡身份、控制器注册、驱动是否可用，以及是否存在稳压器或pinctrl错误。延迟探测可能意味着依赖资源尚未就绪，并不自动说明compatible字符串错误。内核驱动模型文档介绍了所需资源不可用时的延迟探测。

不要要求某条固定的成功消息：正常驱动也可能不输出日志。检查相关设备与驱动的绑定，通过名称和设备关系找到对应的hwmon实例。适配器与hwmon的数字索引都可能变化。TMP102驱动文档列出了温度输入及其他导出属性。解释数值之前，应通过适用的接口文档确认单位。

6. 验证真实外设，包括异常行为

  • 身份与路径：证明运行节点、物理总线和已绑定驱动对应预期传感器。sysfs中出现一个目录，并不足以证明能够提供有用测量。
  • 受控输入：在稳定条件下，使用合适的独立参考比较读数，再施加安全、受控的温度变化。测试前，根据项目要求和传感器规格定义容差与稳定时间。
  • 电气行为：若通信失败，使用合适设备检查供电电压、适用时的复位或使能行为，以及总线波形。逻辑采集应确认地址、ACK行为和时序，但单凭这些不能证明测量精度。
  • 生命周期：计划重复冷启动、热重启及支持的休眠恢复循环，记录传感器是否稳定被发现，以及是否在约定时间内恢复。
  • 故障处理：在安全测试夹具上模拟电源不可用或传感器缺失。验收应要求可见错误与恢复策略，不能把缓存中看似合理的旧值作为新数据呈现。

避免在未知硬件上随意扫描总线，也不要通过原始I2C事务与已绑定的内核驱动争用设备。应使用既定驱动接口和受控诊断流程。在启动实验之前，保留基线DTB，并准备有文档说明的恢复路径。

7. 最终审查应包含什么

交付小范围DTS差异补丁、原理图与属性映射、确切构建输入、验证日志、部署身份、完整启动日志和外设测试证据。在实际执行前，应把所有建议测试标为待执行。两份AI初稿意见一致，不能替代接线或运行证据。

欧蓓特固件与BSP诊断服务与这一板级联调流程相关。RK3566嵌入式终端项目提供相关BSP和外设集成背景，但不能证明本假设TMP102补丁曾用于该项目。

类似文章