📚 课程目录第3章设备树文件类型与结构

3、设备树文件类型与结构：DTS、DTSI、DTB、DTC工具的作用与相互转换关系

设备树（Device Tree）是嵌入式Linux系统中描述硬件资源的核心机制，它通过一种与操作系统无关的数据结构，将CPU厂商的板级硬件细节（如内存基址、外设寄存器地址、中断号、时钟频率等）从内核源码中剥离出来。在实际开发中，我们经常接触以不同扩展名存在的设备树文件：.dts、.dtsi、.dtb，以及负责编译和反编译的DTC工具。理解这四者之间的角色定位与转换链路，是进行设备树移植、调试和驱动开发的第一道门槛。本章将系统拆解这些文件类型的语法特征、组织逻辑、编译流程，并通过一个完整的实战案例展示从源码到二进制再到反编译验证的全过程。

上图清晰地展示了设备树文件在开发流程中的核心转换链路。下面我们将从每个文件类型的本质出发，深入剖析其语法结构、组织原则以及在实际工程中的操作要点。

3.1 核心原理：四种文件类型的角色定义

DTS（Device Tree Source）是设备树的源文件，采用文本格式，描述一块具体开发板的硬件资源。它通常以/作为根节点，内部包含若干子节点，每个节点对应一个硬件设备或总线接口。例如，一个简单的DTS文件可能包含以下内容：

/ {
    model = "TI AM335x BeagleBone Black";
    compatible = "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx";
    memory@80000000 {
        device_type = "memory";
        reg = <0x80000000 0x10000000>;  /* 512MB RAM */
    };
    leds {
        compatible = "gpio-leds";
        led0 {
            label = "beaglebone:green:usr0";
            gpios = <&gpio1 21 GPIO_ACTIVE_HIGH>;
        };
    };
};

DTSI（Device Tree Source Include）是设备树的公共头文件，通常用于描述SoC（片上系统）级别的通用硬件信息，如CPU核心、中断控制器、时钟控制器、串口、I2C控制器等。DTSI文件通过#include指令被DTS文件引用，实现代码复用。例如，am33xx.dtsi定义了AM335x SoC的所有内置外设节点，而具体的板级DTS文件只需包含它并修改或添加板级特有属性。

DTB（Device Tree Blob）是设备树的二进制格式，由DTC工具将DTS/DTSI编译生成。DTB是Bootloader（如U-Boot）加载并传递给Linux内核的最终格式。内核启动早期阶段，通过解析DTB来获取内存布局、外设地址、中断配置等关键信息，从而完成设备驱动的初始化。

DTC（Device Tree Compiler）是设备树编译工具，其作用类似于C语言中的GCC。DTC不仅支持将DTS编译为DTB，还支持将DTB反编译为DTS，极大方便了调试和逆向分析。在Linux内核源码的scripts/dtc/目录下，DTC工具会随内核编译过程自动生成。

关键理解：DTSI是“库”，DTS是“应用”。DTSI定义SoC的通用能力，DTS定义具体板卡的个性化配置。这种分离设计使得同一颗SoC可以衍生出数十种不同板卡，而无需重复编写SoC级代码。

3.2 判断方法与操作流程：从源码到二进制

在实际开发中，我们通常需要完成以下操作流程。首先，确认内核源码中设备树文件的存放路径：arch/arm/boot/dts/（ARM架构）或arch/arm64/boot/dts/（ARM64架构）。其次，识别当前平台对应的DTSI文件，例如对于i.MX8M Plus平台，其SoC级定义位于arch/arm64/boot/dts/freescale/imx8mp.dtsi，而板级文件可能是imx8mp-evk.dts。

编译设备树有两种常用方式：

内核编译系统：在Linux内核根目录执行make dtbs，系统会根据arch/arm/boot/dts/Makefile中的规则自动编译所有DTS文件。例如，make imx8mp-evk.dtb会单独编译该板卡。
手动DTC命令：适用于快速验证或独立编译场景。基本命令格式为：

# 编译：DTS + DTSI → DTB
dtc -I dts -O dtb -o myboard.dtb myboard.dts

# 反编译：DTB → DTS
dtc -I dtb -O dts -o decompiled.dts myboard.dtb

# 带预处理编译（支持#include和宏定义）
cpp -nostdinc -I <内核dts目录> -undef -D__DTS__ -x assembler-with-cpp myboard.dts | dtc -I dts -O dtb -o myboard.dtb -

值得注意的是，手动编译时如果DTS文件中包含#include指令，必须先用C预处理器（cpp）展开，否则DTC会报语法错误。内核的编译系统会自动处理这一步骤，而手动操作时需要显式调用cpp。

操作场景	推荐方式	关键参数/命令
内核源码树内编译	make dtbs	ARCH=arm64 make imx8mp-evk.dtb
独立DTS文件快速验证	dtc + cpp	cpp -nostdinc -I ... \| dtc -I dts -O dtb
DTB反编译查看	dtc -I dtb -O dts	dtc -I dtb -O dts -o out.dts boot.dtb
检查DTB与内核兼容性	fdtdump	fdtdump boot.dtb \| head -50

3.3 案例拆解：基于i.MX8M Plus的板级设备树移植

我们以一个实际项目为例：某工业控制板卡基于NXP i.MX8M Plus处理器，需要新增一个SPI接口的ADC芯片（如ADS131M04），并配置对应的GPIO中断。初始现象是：内核启动后，/dev/spidev0.0节点不存在，SPI总线无法识别。

分析过程：首先，检查板级DTS文件imx8mp-evk.dts中是否已包含SPI控制器节点。通过搜索ecspi1关键字，发现该节点在SoC级文件imx8mp.dtsi中已定义，但状态为disabled。板级DTS需要将其使能并配置片选引脚。

操作步骤：

/* 在imx8mp-evk.dts中追加 */
&ecspi1 {
    status = "okay";
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_ecspi1>;
    cs-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>;
    
    adc@0 {
        compatible = "ti,ads131m04";
        reg = <0>;  /* 片选0 */
        spi-max-frequency = <1000000>;
        interrupts-extended = <&gpio1 13 IRQ_TYPE_EDGE_FALLING>;
        vref-supply = <&reg_3v3>;
    };
};

/* 在iomuxc节点中追加引脚配置 */
&iomuxc {
    pinctrl_ecspi1: ecspi1grp {
        fsl,pins = <
            MX8MP_IOMUXC_ECSPI1_SCLK__ECSPI1_SCLK  0x82
            MX8MP_IOMUXC_ECSPI1_MOSI__ECSPI1_MOSI  0x82
            MX8MP_IOMUXC_ECSPI1_MISO__ECSPI1_MISO  0x82
            MX8MP_IOMUXC_GPIO1_IO13__GPIO1_IO13    0x140
        >;
    };
};

编译与验证：执行make imx8mp-evk.dtb，将生成的DTB拷贝至开发板启动分区。重启后，通过ls /dev/spidev*确认设备节点出现。进一步使用i2c-tools或spidev_test工具读取ADC寄存器值，验证通信正常。

结果对比：修改前，ecspi1节点状态为disabled，内核不会创建SPI控制器；修改后，控制器被使能，且子节点ADC被正确枚举。整个过程中，我们仅修改了DTS文件，未改动任何内核C代码，这充分体现了设备树“配置与代码分离”的设计优势。

风险提示：在修改引脚复用（IOMUX）时，务必确认该引脚未被其他外设占用。例如，GPIO1_IO13可能同时被用作CAN或PWM功能，若发生冲突，会导致两个设备均无法正常工作。建议使用cat /sys/kernel/debug/pinctrl/pinctrl-handles查看当前引脚占用情况。

3.4 常见误区与总结复盘

在设备树文件的使用过程中，工程师常犯以下错误：

混淆DTS与DTSI的边界：将板级特有信息（如LED GPIO、按键定义）写入DTSI，导致多个板卡共用时产生冲突。正确做法是DTSI只放SoC级通用内容。
忽略预处理器依赖：手动编译DTS时未使用cpp展开#include，导致编译失败。内核编译系统自动处理了此步骤，但独立编译时必须手动添加。
DTB版本不匹配：使用旧版DTC编译新语法（如interrupt-extended）可能导致警告或错误。建议使用内核自带的DTC工具。
反编译结果不可直接用于编译：DTB反编译得到的DTS会丢失注释、宏定义和原始格式，仅适合调试参考，不应作为维护基线。

总结复盘：设备树文件类型的设计体现了软件工程中的“分层复用”思想。DTSI作为SoC抽象层，DTS作为板卡具体层，DTC作为编译桥梁，DTB作为运行时产物。掌握这四者的关系，不仅能够高效完成板卡适配，还能在遇到启动异常时快速定位是设备树问题还是驱动问题。建议开发者在项目初期就建立规范的设备树文件管理习惯，将公共部分提取为DTSI，板级差异保留在DTS中，并定期使用dtc -I dtb -O dts对生成的DTB进行反编译审查，确保实际加载的硬件配置与设计意图一致。