1. 设备树起源：为什么需要设备树？从板级文件到设备树的演进历史

1.1 嵌入式Linux早期的“板级文件”时代

在Linux内核引入设备树（Device Tree）之前，嵌入式Linux开发者依赖一种被称为“板级文件”（Board File）的机制来描述硬件。每个开发板或平台都需要在Linux内核源码的 arch/arm/ 目录下编写一个或多个 .c 文件，其中硬编码了该板卡的所有硬件资源信息：内存基址、中断号、GPIO映射、时钟频率、外设寄存器地址等。

这种模式在早期嵌入式设备种类较少、硬件相对简单时尚可接受。但随着ARM架构的爆发式增长，板级文件模式逐渐暴露出严重问题。

1.2 板级文件 vs 设备树：核心差异对比

1.3 演进历史：从混乱到统一

设备树的引入并非一蹴而就，而是经历了多个关键里程碑。以下时间线展示了嵌入式Linux硬件描述方式的演进路径：

1. 2005年以前： PowerPC架构率先使用设备树（源于Open Firmware），但ARM社区仍坚持板级文件模式。
2. 2005-2010年： ARM设备数量激增，板级文件数量突破数百个，内核维护者开始呼吁改革。
3. 2011年： Linux 3.0 发布，ARM架构开始实验性引入设备树支持，但尚未全面推广。
4. 2012年： Linux 3.4-3.7 期间，ARM社区加速设备树迁移，大量板级文件被标记为“deprecated”。
5. 2014年： Linux 3.16 发布，ARM架构中设备树成为默认硬件描述方式，板级文件基本退出历史舞台。
6. 2015年至今： 设备树成为RISC-V、ARM64、x86（部分场景）等架构的通用硬件描述标准。

1.4 设备树的核心设计思想

设备树的设计哲学可以概括为：“硬件描述与驱动代码分离”。它将硬件资源信息从内核源码中剥离出来，形成一份独立的数据结构，由Bootloader在启动时传递给内核。

设备树文件（.dts）经过编译生成二进制设备树（.dtb），内核在启动时解析.dtb，动态构建硬件设备模型，并匹配对应的驱动程序。这一机制带来了以下关键优势：

• 二进制兼容性： 同一内核镜像可以运行在不同硬件平台上，只需更换.dtb文件。
• 驱动复用： 驱动代码不再依赖具体板卡，而是通过设备树中的“compatible”属性进行匹配。
• 社区协作： 硬件厂商只需提供.dts文件，无需修改内核主线，降低了贡献门槛。
• 启动灵活性： Bootloader（如U-Boot）可以在启动时动态修改设备树（如调整内存大小、禁用外设）。

1.5 设备树工作流程概览

下图展示了从设备树源文件到内核驱动匹配的完整工作流程：

1.6 设备树带来的变革：一个实际案例

假设我们需要为一个新的开发板添加UART串口支持。在板级文件时代，开发者需要：

1. 在 arch/arm/mach-xxx/ 下创建板级文件，定义UART的寄存器基址、中断号、时钟ID。
2. 调用 platform_device_register() 注册设备。
3. 修改 Kconfig 和 Makefile，确保新文件被编译进内核。
4. 重新编译整个内核，烧录到开发板。

而在设备树时代，只需在.dts文件中添加以下节点：

/* 设备树节点：描述UART外设 */
uart0: serial@10000000 {
    compatible = "vendor,uart-ip";
    reg = <0x10000000 0x1000>;
    interrupts = <0 33 4>;
    clocks = <&uart_clk>;
    status = "okay";
};

内核驱动通过 of_match_table 匹配 compatible 属性，自动获取寄存器地址、中断号和时钟信息，无需任何内核源码修改。

1.7 本章小结

设备树的诞生是嵌入式Linux发展史上的重要转折点。它解决了板级文件时代硬件描述与内核代码高度耦合的顽疾，使得Linux内核能够以更优雅、更可维护的方式支持海量嵌入式设备。理解设备树的起源和设计思想，是掌握后续.dts编写和驱动适配的基础。