驱动开发中设备树的解析流程：系统学习

从零剖析设备树：驱动开发者的实战指南

你有没有遇到过这样的场景？换了一块开发板，内核镜像一模一样，但外设却能自动识别、驱动正常加载——甚至连I2C传感器都不用手动注册。这背后，正是设备树在默默起作用。

对于嵌入式Linux开发者而言，设备树早已不是“可选项”，而是贯穿系统启动、驱动匹配、资源获取的核心机制。尤其当你需要移植驱动、调试probe失败、或者添加一个新外设时，绕不开的问题就是：“我的节点写对了吗？”“为什么没进probe？”“reg地址映射错了？”

本文不堆术语、不抄手册，带你以一名一线驱动工程师的视角，从实际问题出发，层层拆解设备树的解析流程。我们将一起走过从Bootloader传参到内核展开节点、再到驱动成功绑定的完整路径，并穿插大量实战经验与避坑提示，让你真正掌握这个“看不见却无处不在”的关键技术。

为什么我们需要设备树？

早年的嵌入式系统中，硬件信息是硬编码在内核里的。比如某款ARM9平台，GPIO控制器的地址直接写死在arch/arm/mach-xxx/目录下。这种做法在单一板型时代尚可接受，但随着SoC被广泛用于不同产品，维护成本急剧上升。

举个真实案例：一家公司基于同一颗i.MX6ULL芯片做了三款产品——工业网关、智能家居主控、便携式采集仪。如果每款都单独维护一套内核代码，光是I/O配置差异就足以让团队崩溃。

于是，设备树来了。

它把“这块板子有哪些设备、它们在哪、怎么连”这些信息，从代码里剥离出来，变成一个独立的二进制文件（.dtb），由Bootloader在启动时交给内核。这样一来：

• 同一个内核镜像，可以跑在不同硬件上；
• 增加一个SPI Flash？改DTS就行，不用重编译内核；
• 驱动也不用关心具体地址，只管去设备树里“问”就行了。

换句话说，设备树的本质是一张硬件地图，而驱动则是拿着这张地图去找资源的旅人。

DTS 到 DTB：一次“编译打包”的旅程

我们先来看一段典型的设备树源码（DTS）：

&i2c1 { status = "okay"; bme280@76 { compatible = "bosch,bme280"; reg = <0x76>; interrupt-parent = <&gpio1>; interrupts = <13 IRQ_TYPE_LEVEL_HIGH>; vdd-supply = <&reg_3v3>; }; };

这段代码描述了一个接在I2C1总线上的温湿度传感器。别看它像个配置文件，其实它要经历和C代码类似的“构建流程”：

1. 编写.dts文件：根据原理图填写外设信息。
2. 包含.dtsi公共头：SoC级定义（如CPU、内存、主控）通常放在.dtsi中复用。
3. 使用dtc编译：Device Tree Compiler 将文本转换为扁平化二进制格式（FDT）。
4. 生成.dtb文件：最终产物是一个紧凑的二进制 blob，没有换行、注释或空格。

整个过程可以用一条命令概括：

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

生成的.dtb会被U-Boot之类的引导程序加载到内存，并通过特定寄存器（ARM32是r2，ARM64是x0）告诉内核：“嘿，硬件描述在这儿。”

💡小知识：设备树最初来自PowerPC的Open Firmware标准，后来被ARM社区采纳并推广。如今不仅是ARM，RISC-V、MIPS甚至部分x86嵌入式平台也在用。

内核如何“读懂”设备树？

当内核开始执行start_kernel()，第一步就是搞清楚自己跑在哪块板子上。这时候，setup_arch()登场了。

关键入口：setup_machine_fdt()

在ARM架构中，这个函数位于arch/arm/kernel/setup.c，它是设备树解析的起点：

void __init setup_arch(char **cmdline_p) { ... if (secondary_cpu_has_fpu()) elf_hwcap |= HWCAP_VFP; // 核心调用！ setup_machine_fdt(__atags_pointer); }

这里的__atags_pointer实际上指向DTB在内存中的起始地址。如果你在U-Boot里看到fdt addr <addr>这类命令，就是在设置这个位置。

一旦进入setup_machine_fdt()，两件大事发生：

1. 匹配 machine description
   内核会遍历所有已注册的machine_desc结构体，通过比较.dt_compat字段与设备树根节点的compatible属性来确定当前平台。

2. 展开设备树结构
   调用unflatten_device_tree()，将扁平的DTB反序列化为内核可用的struct device_node树状结构。

深入unflatten_device_tree

这个函数才是真正“化简为繁”的关键。它会做以下几件事：

• 解析/memory节点，建立内存布局；
• 遍历所有节点，创建对应的device_node对象；
• 构建父子关系链表（child/sibling）；
• 提取属性并组织成property链表；
• 处理引用（phandle）和标签（label），例如&i2c1实际指向哪个节点。

最终结果是：原本躺在内存里的一个二进制块，变成了内核可以直接遍历访问的运行时数据结构。

你可以把它想象成——把一份压缩包解压成了完整的文件夹结构。

struct device_node：内核眼中的设备树

要想理解驱动怎么拿资源，就得先认识这个结构体。它是内核表示设备树节点的核心类型，定义在<linux/of.h>中：

struct device_node { const char *name; // 节点名，如 "i2c" const char *type; // 类型（遗留字段） phandle phandle; // 数字句柄，用于跨节点引用 const char *full_name; // 完整路径，如 "/soc/i2c@40004000" struct property *properties;// 属性链表头 struct device_node *parent; struct device_node *child; struct device_node *sibling; };

所有节点通过指针连接成一棵树。比如上面那个BME280的例子，在内存中会长这样：

i2c@40004000 | bme280@76

其中bme280@76->parent指向 I2C 控制器节点，而它的properties链表则包含了compatible、reg、interrupts等属性。

🛠️调试技巧：想查看当前系统的设备树结构？进shell后运行：

bash cat /proc/device-tree/

或者更直观地：

bash ls -l /sys/firmware/devicetree/base/

你会发现每个节点都对应一个目录，属性就是里面的文件。这是内核导出的只读视图，非常适合排查“我写的属性到底生效没”。

驱动怎么找到自己的“家”？

设备树解析完成只是第一步。真正的重头戏是：平台总线如何根据设备树创建设备，并匹配到正确的驱动。

这一切的关键，就在compatible字段。

匹配基石：compatible属性

回到之前的例子：

bme280@76 { compatible = "bosch,bme280"; reg = <0x76>; };

当内核初始化 platform bus 时，会扫描所有未绑定的设备树节点。只要发现某个节点有compatible属性，就会尝试创建一个platform_device，并将其.of_node指针指向对应的device_node。

然后开始匹配：

static const struct of_device_id my_driver_of_match[] = { { .compatible = "bosch,bme280", }, { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, my_driver_of_match); static struct platform_driver my_driver = { .probe = my_driver_probe, .driver = { .name = "my-driver", .of_match_table = my_driver_of_match, }, };

匹配逻辑很简单：字符串完全一致即可。一旦命中，内核就会调用.probe函数，并把platform_device传进去。

⚠️ 注意事项：

• 必须加上MODULE_DEVICE_TABLE(of, ...)，否则模块无法被depmod识别；
• 匹配顺序是从上往下，第一个成功即停止；
• 支持多条目兼容，比如同时支持"vendor,dev-v1"和"vendor,dev-v2"。

如何安全获取资源？常用API实战

probe函数一进来，第一件事通常是申请资源。设备树已经把一切准备好，你只需要“伸手要”。

1. 内存映射：platform_get_resource()+devm_ioremap_resource()

res = platform_get_resource(pdev, IORESOURCE_MEM, 0); base = devm_ioremap_resource(&pdev->dev, res); if (IS_ERR(base)) return PTR_ERR(base);

这里IORESOURCE_MEM表示要的是reg地址，索引0是第一个条目。假设DTS里写了：

reg = <0x40004000 0x1000>;

那res->start就是0x40004000，长度是0x1000，iounmap之后就能访问寄存器了。

2. 中断号获取：platform_get_irq()

irq = platform_get_irq(pdev, 0); if (irq < 0) return irq;

对应设备树中的interrupts = <...>;。注意返回值可能为负（表示错误或未定义），务必判断！

3. 自定义属性读取：of_property_read_*()

有些参数不适合走标准字段，比如阈值、延迟时间等，可以用自定义属性：

mydev: my-device@12345678 { compatible = "vendor,mydev"; reg = <0x12345678 0x100>; threshold = <100>; sample-rate = <10>; };

驱动中读取：

u32 threshold; int ret = of_property_read_u32(np, "threshold", &threshold); if (ret == 0) { dev_info(dev, "采样阈值：%u\n", threshold); } else { dev_info(dev, "未配置threshold，使用默认值\n"); }

这类函数还有：
-of_property_read_string()
-of_property_read_u32_array()
-of_parse_phandle()—— 用于获取其他节点引用

常见“踩坑”点与应对策略

再熟练的开发者也会被设备树绊倒。以下是我在项目中总结的高频问题及解决方案。

❌ 问题1：明明写了 compatible，为啥没进 probe？

检查清单：

• 是否注册了platform_driver？忘记platform_driver_register()很常见。
• of_match_table是否赋值给了.driver.of_match_table？
• 设备节点status = "okay";了吗？默认可能是"disabled"。
• DTS是否正确 include？有时误删了#include "xxx.dtsi"。
• 编译时是否真的包含了你的.dts？检查Makefile或Kbuild。

🔍 排查建议：打开CONFIG_OF_DYNAMIC并启用debugfs，然后查看：

bash mount -t debugfs none /sys/kernel/debug cat /sys/kernel/debug/of-dynamic-status

❌ 问题2：reg 地址错位，ioremap失败

原因往往出在#address-cells和#size-cells不匹配。

例如：

soc { #address-cells = <1>; #size-cells = <1>; mydev@1000 { reg = <0x1000 0x100>; // 正确 }; };

但如果父节点是<2><2>，你还写四个32位数就不行了：

#address-cells = <2>; #size-cells = <2>; reg = <0x0 0x10000000 0x0 0x1000>; // 高低各32位拼成64位地址

✅ 经验法则：永远去看父节点的 cells 定义！别猜。

❌ 问题3：GPIO 引脚读不出来

常见于命名GPIO组：

leds { compatible = "gpio-leds"; red-led { gpios = <&gpio1 12 GPIO_ACTIVE_LOW>; }; };

要用专用API读取：

struct gpio_desc *desc; desc = gpiod_get(&pdev->dev, "red", GPIOD_OUT_LOW); if (IS_ERR(desc)) { // 处理错误 }

或者用老式接口：

int gpio = of_get_named_gpio(np, "gpios", 0); if (!gpio_is_valid(gpio)) { dev_err(dev, "无效GPIO\n"); return -EINVAL; }

高阶玩法：设备树覆盖（Overlay）

传统设备树是静态的——编译好就不能改。但在一些可扩展系统中（如BeagleBone的cape模块），我们需要动态加载外设描述。

这就是设备树覆盖（Device Tree Overlay）的用武之地。

它允许你在系统运行时，向主设备树“打补丁”，添加新的节点或修改现有属性。

使用步骤如下：

1. 启用内核选项：CONFIG_OF_OVERLAY=y
2. 编写.dts覆盖文件（fragment形式）
3. 编译为.dtbo
4. 拷贝到/lib/firmware/
5. 写入/sys/kernel/config/device-tree/overlays/

虽然目前主要用于特定平台，但随着模块化硬件兴起，overlay的价值正在凸显。

📌 使用建议：仅用于非关键路径设备；注意并发访问保护；避免频繁加载卸载导致内存碎片。

回顾与延伸：你真的掌握了设备树吗？

让我们快速回顾几个核心要点：

• 设备树不是驱动，但它决定了驱动能不能运行；
• DTS → DTB → unflatten → device_node → platform_device → probe，这条链路必须畅通；
• compatible是匹配的灵魂，写错一个字母都会导致失败；
• 所有资源获取都应优先使用OF API，而不是硬编码；
• 调试时善用/proc/device-tree和of_print_phandle()等工具。

更重要的是，你要学会逆向思考：当probe没进来，不要急着改驱动，先问自己：

• 我的节点出现在设备树里了吗？
• status是okay吗？
• compatible拼写对吗？
• 父节点是不是没enable？
• reg地址是不是和其他设备冲突？

这些问题的答案，往往藏在那一行行看似枯燥的DTS代码中。

如果你正在开发一款新产品，或是接手一个陌生平台，不妨现在就打开它的.dts文件，试着回答这几个问题：

1. 这个I2C控制器的基地址是多少？
2. 这个中断连到了哪个GPIO？
3. 它依赖的电源是由哪个regulator提供的？

当你能仅凭设备树就说清硬件连接时，你就不再是一个只会调API的码农，而是一名真正懂系统的驱动工程师。

欢迎在评论区分享你的设备树调试故事，或者提出你一直没搞明白的问题。我们一起拆解，直到彻底弄懂为止。