设备树与传统板级文件对比：一文说清差异

一次编译，到处运行：设备树如何重塑嵌入式Linux开发

你有没有遇到过这样的场景？团队里刚拿到一块新板子，还没开始写应用逻辑，就要先折腾内核配置、修改平台代码、重新编译整个镜像——只为了让系统识别一个新增的I2C传感器。更糟的是，如果公司同时维护多个硬件变种，每个版本都得保留一套独立的内核分支，合并补丁时冲突频发，发布流程复杂到令人抓狂。

这正是十年前嵌入式开发者的真实写照。而今天，这一切已经被一种看似“冷门”却极其关键的技术悄然改变：设备树（Device Tree）。

它不是什么炫酷的新框架，也不是运行时引擎，但它却是现代嵌入式Linux能实现“通用内核 + 多平台适配”的核心支柱。要理解它的价值，我们必须回到那个“每块板子都要专属内核”的时代——也就是传统板级支持包（BSP）统治的年代。

从硬编码到数据驱动：一场静默的革命

在早期ARM Linux中，硬件信息是直接写死在C代码里的。比如你要初始化一个UART控制器，就得在mach-s3c24xx目录下写一段类似这样的代码：

static struct resource s3c_uart0_resource[] = { [0] = DEFINE_RES_MEM(0x50000000, 0x100), [1] = DEFINE_RES_IRQ(IRQ_EINT0), };

然后通过platform_device注册进系统，再用MACHINE_START宏声明这是哪块板子。听起来很熟悉？没错，这就是经典的BSP模式。

问题在于：这种模式把硬件细节和操作系统逻辑紧紧绑在一起。哪怕只是改了个GPIO引脚，你也得重新编译内核。更别说同一颗SoC用在不同产品上时，厂商不得不维护几十个几乎相同的C文件，最终导致内核主线臃肿不堪。

于是社区开始思考：能不能把“描述硬件”这件事，从代码里剥离出来？

答案就是设备树。

设备树的本质：给硬件写一份结构化简历

你可以把设备树想象成一张硬件的标准化简历。它不包含任何执行逻辑，只回答一个问题：“我是谁？我有哪些资源？”

这份简历以.dts（Device Tree Source）文件形式存在，经过编译后变成二进制的.dtb（Device Tree Blob），由U-Boot这类引导程序加载并传递给内核。内核启动初期会解析这份“简历”，然后根据其中的信息去匹配相应的驱动。

举个例子，同样是配置STM32的USART2，使用设备树后变成了这样：

usart2: serial@4000e000 { compatible = "st,stm32-usart"; reg = <0x4000e000 0x400>; interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>; clocks = <&rcc USART2_K>; status = "disabled"; };

注意这里的compatible字段——它是整套机制的“钥匙”。当内核扫描所有驱动时，会查找哪个驱动的of_match_table包含"st,stm32-usart"，一旦命中，就调用其.probe()函数完成初始化。

这意味着：同一个内核镜像，只要换一个DTB文件，就能跑在完全不同的硬件上。不需要改代码，不需要重编译，甚至不需要重启——只要你支持动态overlay。

解耦的艺术：为什么设备树成了事实标准？

我们不妨做个对比。假设你现在要为三款外观不同但主控相同的工业网关开发系统。

如果你还用传统BSP方式：

得维护三个不同的机器ID；
每次新增一个SPI Flash或CAN接口，都要修改C文件；
内核镜像无法共用，CI/CD流水线要跑三遍；
厂商提交补丁困难，主线拒绝合并“私有板级代码”。

结果是什么？内核仓库膨胀，安全更新滞后，小厂难以跟进主流生态。

而采用设备树之后：

只需一个通用内核；
三款硬件对应三个.dtb文件；
新增外设只需修改DTS，甚至可通过overlay热加载；
所有变更都可以通过版本控制系统清晰追踪；
厂商无需向主线提交大量C代码，只需提供设备树片段即可完成适配。

这不仅仅是便利性的提升，更是工程范式的转变：从“改代码适配硬件”转向“写描述适配系统”。

核心机制拆解：设备树是如何工作的？

设备树的工作流程贯穿整个启动链，但它真正的魔法发生在内核初始化阶段。

第一步：构建树形结构

设备树源文件（.dts）通常分为两部分：
-.dtsi：SoC级别的公共定义（如CPU、内存控制器、主外设）；
-.dts：板级特异性内容（如外接芯片、引脚复用、电源管理）；

通过#include引入共享部分，实现模块化复用。例如：

#include "stm32mp157c.dtsi" &usart2 { pinctrl-names = "default"; pinctrl-0 = <&usart2_pins_a>; status = "okay"; };

这里&usart2是对.dtsi中已定义节点的引用，仅启用并配置其引脚控制。干净、清晰、无重复。

第二步：编译与加载

使用dtc工具将.dts编译为.dtb：

dtc -I dts -O dtb -o board.dtb board.dts

U-Boot 启动时将其加载到内存，并通过寄存器将地址传给内核（通常是r2寄存器，ARM32架构下）。内核随后调用unflatten_device_tree()解析该Blob，构建出内部的struct device_node链表结构。

第三步：驱动绑定

这才是最关键的一步。内核中的平台驱动必须声明自己的兼容性列表：

static const struct of_device_id stm32_usart_of_match[] = { { .compatible = "st,stm32-usart" }, { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, stm32_usart_of_match);

当总线进行设备-驱动匹配时，就会比对设备树节点的compatible属性与驱动表项。一旦成功，便触发.probe()回调，完成资源映射、中断申请、DMA配置等一系列操作。

整个过程完全自动化，无需人工干预。

实战案例：让一块音频HAT自动生效

来看一个真实应用场景：Raspberry Pi上的HAT（Hardware Attached on Top）模块。

当你插入一块带SGTL5000 Codec的音频扩展板时，系统是如何知道该怎么配置的？

答案是设备树overlay。

HAT本身有一个EEPROM，存储了它的设备树片段（.dtbo）。系统启动后，U-Boot或内核会读取这个信息，并动态加载对应的overlay文件。该文件可能包含如下内容：

/dts-v1/; /plugin/; / { compatible = "brcm,bcm2835"; fragment@0 { target = <&i2c1>; __overlay__ { #address-cells = <1>; #size-cells = <0>; sgtl5000: codec@0a { compatible = "fsl,sgtl5000"; reg = <0x0a>; VDDA-supply = <&vcc_3v3>; }; }; }; fragment@1 { target-path = "/"; __overlay__ { sound { compatible = "simple-audio-card"; simple-audio-card,name = "AudioHAT"; simple-audio-card,cpu = <&sai1>; simple-audio-card,codec = <&sgtl5000>; }; }; }; };

加载后，系统立刻识别出新的音频设备，并通过ASoC框架自动建立连接。用户执行aplay -l就能看到新声卡，全程无需手动配置。

这就是现代嵌入式系统的“即插即用”能力背后的核心支撑。

工程实践建议：怎么写好设备树？

尽管设备树极大简化了开发，但如果使用不当，依然会埋下隐患。以下是几个来自一线的经验之谈：

✅ 正确划分`.dts`与`.dtsi`

SoC级定义放.dtsi：CPU、主控IP、默认时钟树；
板级定制放.dts：外设连接、引脚复用、电源策略；
避免在一个文件中混杂两者，否则后期移植成本陡增。

✅ 合理使用`compatible`属性

格式推荐为“厂商,型号”，例如：

compatible = "ti,ina219"; // ✔️ 好 compatible = "power-monitor"; // ❌ 差，太模糊

确保与驱动中的of_match_table完全一致，否则匹配失败。

✅ 不要过度配置

有些参数其实可以在驱动中智能推导。比如：

clocks = <&rcc USART2_K>; // ✔️ 必须指定 dma-names = "tx", "rx"; // ✔️ 明确用途 dmas = <&dmamux1 3 0x400>, <&dmamux1 2 0x400>; // ⚠️ 能否省略？

如果不是特殊需求，尽量依赖驱动默认行为，减少耦合。

✅ 善用调试工具

运行时可以通过/proc/device-tree查看实际加载的设备树结构：

ls /proc/device-tree/serial@ cat /proc/device-tree/serial@4000e000/compatible

也可启用CONFIG_OF_DEBUG获取更多解析日志，快速定位节点未匹配等问题。

✅ 关注安全性

生产环境中应考虑对DTB进行签名验证，防止恶意篡改引发硬件损坏或权限越界。U-Boot支持FIT image结合PKI机制，可实现安全加载。

结语：设备树不只是技术，更是一种思维方式

回望过去十年，设备树之所以能在ARM生态中迅速普及，并非因为它有多复杂，而是因为它做对了一件事：把不该由内核决定的事交还给了硬件描述。

它推动了Linux内核的主线化进程，使得TI、NXP、ST等厂商能够将板级支持统一纳入主线，大幅提升了长期维护性和安全性。如今，无论是工业控制器、智能家居网关，还是边缘AI盒子，几乎清一色采用设备树作为硬件描述标准。

更重要的是，它改变了工程师的思维模式：
以前我们问：“怎么改内核让它支持这块板？”
现在我们问：“怎么写DTB让它被内核自动识别？”

这种从“侵入式修改”到“声明式描述”的转变，正是现代软件工程走向模块化、可维护、可持续发展的缩影。

未来，随着RISC-V等新兴架构的发展，设备树也正在成为跨架构硬件抽象的重要候选方案。也许有一天，“写设备树”会像“写Makefile”一样，成为每一位嵌入式开发者的基本功。