设备树入门：DTS / DTC / DTB 关系与核心作用

设备树入门DTS / DTC / DTB 关系与核心作用作者黒漂技术佬 | 系列Linux内核配置与移植引言如果你是从单片机STM32、ESP32转到嵌入式 Linux 的第一次看到设备树Device Tree可能会觉得这是一门玄学——一个文本文件写着一些奇怪的语法编译成一个二进制文件传给内核硬件就能工作了。没有寄存器地址没有#define甚至没有一个main函数凭啥本文就从零讲清楚设备树是什么、为什么要有它、以及 DTS / DTC / DTB 三兄弟是怎么配合工作的。一、为什么需要设备树1.1 没有设备树之前——板级代码的噩梦在设备树出现之前Linux 2.6 时代ARM 平台的硬件信息是硬编码在内核arch/arm/mach-xxx/中的。每增加一块新板子就得写几百上千行板级支持代码// arch/arm/mach-xxx/board-xxx.c —— 老时代的做法staticstructresourceuart_resources[]{[0]{.start0x40002000,// 寄存器基地址写死在代码里.end0x40002FFF,.flagsIORESOURCE_MEM,},// ... 几十行平台设备定义};staticstructplatform_deviceuart_device{.nameserial8250,.id0,.num_resourcesARRAY_SIZE(uart_resources),.resourceuart_resources,};这种方式的痛点内核臃肿每种板子一套代码ARM 内核中板级代码一度达到数十万行不通用换个外设就得改内核、重新编译——哪怕只换了 GPIO 引脚难维护硬件信息散落在 C 代码中和驱动逻辑混在一起Linus 本人对此非常不满2011 年曾在邮件列表里怒斥 ARM 社区的板级代码是一坨垃圾原文更劲爆。此后 ARM 社区全面转向设备树。1.2 设备树的解决思路核心思想把硬件描述从内核代码中分离出来。[老时代] 内核代码 驱动逻辑 硬件信息 → 改了硬件就得改内核 [设备树时代] 内核代码 驱动逻辑 → 不变 DTB文件 硬件信息 → 随板子变化设备树本质上是一棵描述硬件的树状数据结构它告诉内核有哪些外设UART、GPIO、I2C、SPI 等这些外设的寄存器地址是多少用哪个引脚、哪个中断号和哪个驱动绑定二、DTS / DTC / DTB 三兄弟关系设备树涉及到三种文件/工具新手最容易混淆的就是它们之间的关系DTS源文件 DTC编译器 DTB二进制 ↓ ↓ ↓ .dts / .dtsi ────→ dtc ──────→ .dtb (文本格式) (编译工具) (二进制) (人读写) (软件) (内核读取)名词全称格式谁用说明DTSDevice Tree Source文本开发者编写类似 C 源码描述硬件配置DTSIDevice Tree Source Include文本被 DTS include类似 C 头文件SoC 级公共描述DTCDevice Tree Compiler可执行工具编译过程自动调用将 DTS/DTSI 编译成 DTBDTBDevice Tree Blob二进制U-Boot 加载给内核内核运行时解析的实际文件转换命令# 从 DTS 编译 DTB通常 make dtbs 自动完成scripts/dtc/dtc-Idts-Odtb-ooutput.dtb input.dts# 从 DTB 反编译回 DTS调试用scripts/dtc/dtc-Idtb-Odts-ooutput.dts input.dtb三、DTS 文件结构初探打开一个典型的.dts文件以versatile-pb.dts为例/dts-v1/; #include versatile-ab.dts / { model ARM Versatile PB; compatible arm,versatile-pb; memory { reg 0x00000000 0x08000000; /* 128MB RAM */ }; chosen { bootargs consolettyAMA0,115200; }; /* 引用 AB 文件中定义的节点并追加属性 */ amba { uart101f1000 { status okay; }; }; };DTS 的树状结构用树形图表达/ (根节点) ├── model ARM Versatile PB ├── compatible arm,versatile-pb ├── memory0 │ └── reg 0x00000000 0x08000000 ├── chosen │ └── bootargs consolettyAMA0,115200 └── amba (引用节点) └── uart101f1000 └── status okayDTS 的层叠复用机制.dts .dtsiSoC级 dtsi (xxx-soc.dtsi) ← 定义芯片所有外设 ↓ #include 板级 dts (xxx-board.dts) ← 使能需要的设备 修改引脚.dtsi是硅片厂商提供的描述芯片本身有哪些硬件资源不管你是否使用。.dts是板级开发者写的决定哪些设备启用、引脚怎么接。四、设备树编译过程内核编译时设备树编译是自动触发的makeARCHarmCROSS_COMPILEarm-linux-gnueabihf- dtbs编译流程.dts 源文件 │ ├── C预处理器 (#include / #define) │ ├── dtc 编译器 │ ├── 语法检查 │ ├── 语义检查 (compatible 字符串规范性等) │ └── 输出平坦设备树 (Flattened Device Tree) │ └── .dtb 二进制文件dtc 源码就在内核里scripts/dtc/目录。执行make scripts会先编译 dtc然后再用 dtc 编译设备树。五、设备树如何被内核使用启动流程中的设备树链路U-Boot │ ├── 将 zImage 加载到内存 ├── 将 .dtb 加载到内存 ├── 设置寄存器 r2 dtb 地址 (ARM32 传参约定) └── 跳转到 zImage 入口 │ ├── 自解压代码 ├── 内核初始化() ├── setup_arch() │ └── 解析 DTB → 生成 platform_device │ ├── 各驱动 probe() │ └── 匹配 compatible 字符串 │ └── 读取 reg/interrupts/gpios 等属性 │ └── 硬件开始工作关键点DTB 在启动时由 Bootloader 传给内核内核解析后生成platform_device结构驱动通过compatible字符串匹配这个过程是完全自动的你不需要写一行 C 代码来描述硬件六、设备树 vs 传统板级代码对比对比维度传统板级代码设备树硬件描述位置内核 C 代码中独立的 .dts 文件修改后是否需要重编内核是只需要重编 DTB同一内核支持多板卡需要重新编译换 DTB 即可代码可读性差C和宏混一起好树状结构直观厂商BSP交付方式内核补丁.dtsi 文件社区认可度已被抛弃当前唯一标准总结设备树的核心思想就是硬件描述与内核代码解耦。DTS 是你写的硬件说明书文本DTC 是翻译官工具DTB 是翻译后的精简版说明书二进制最终由 Bootloader 交到内核手里。理解了这个三件套的分工后面学习节点编写就水到渠成了。