1. 课程导入

在嵌入式Linux开发中，设备树（Device Tree）早已不是“可选项”，而是ARM、RISC-V、PowerPC等架构上描述硬件拓扑的标准机制。传统做法是把板级硬件信息一次性写进.dts源文件，编译成.dtb后由Bootloader在启动时交给内核。这种方式在硬件固定、产品形态单一的场景下足够可靠，但一旦遇到“同一块核心板配不同底板”“量产设备需要现场切换外设”“调试阶段频繁更换传感器模块”等需求，静态设备树就显得笨重：每次改动都要重新编译、烧录、重启，开发迭代成本极高。

设备树动态Overlay（Device Tree Overlay，简称DTO）正是为解决这一矛盾而生的机制。它允许在系统运行时，把一段描述“增量硬件信息”的.dtbo文件叠加到当前生效的设备树上，动态创建、修改或删除节点与属性，并触发相应驱动重新匹配。换句话说，Overlay让设备树从“编译期静态配置”变成了“运行期可插拔配置”。本课程的目标，就是带你从零建立一套可落地、可复用的Linux设备树动态Overlay工程能力。

一、学习目标：从“看懂”到“能交付”

本课程的学习目标分为四个层次，层层递进：

• 概念层：理解设备树、Overlay、fragment、target、phandle、__overlay__等核心概念，能说清Overlay与静态DTB的本质区别。
• 操作层：熟练使用dtc、fdtoverlay、libfdt、configfs等工具，完成.dtbo的编译、合并、加载与卸载。
• 工程层：能设计多板卡、多外设的Overlay目录结构，编写Makefile，管理版本与依赖，形成可维护的工程仓库。
• 排障层：能通过/proc/device-tree、/sys/firmware/devicetree、dmesg、of_overlay日志定位Overlay加载失败、节点冲突、驱动未匹配等问题。

二、核心价值：为什么值得投入学习

Overlay的价值可以从三个视角来看。对硬件工程师而言，它让底板改版不再牵动核心板固件；对驱动工程师而言，它让驱动验证可以脱离完整烧录流程，直接在运行系统上插拔设备树片段；对产品与运维而言，它让同一套系统镜像通过加载不同Overlay适配不同SKU，显著降低库存与维护成本。

更关键的是，Overlay与Linux内核的configfs接口结合后，形成了一条标准化的用户态控制路径。你不需要重新编译内核，也不需要重启，就能完成硬件描述的动态变更。这种能力在工业网关、边缘计算盒子、车载终端、机器人控制器等“一板多配”的场景中，几乎是刚需。

三、整体知识框架

本课程的知识框架可以概括为“一条主线、两大接口、三层验证”。一条主线是“Overlay从源码到生效的完整生命周期”；两大接口是内核侧的of_overlay子系统和用户侧的configfs；三层验证是语法验证（dtc编译）、结构验证（fdt节点树）、功能验证（驱动probe与设备节点）。下图展示了这一框架的整体关系。

四、实战路线图与典型场景

课程后续将沿着“环境准备 → 语法基础 → 编译工具 → configfs加载 → 驱动协同 → 工程化封装 → 排障复盘”的路线推进。每个阶段都配有可运行的命令与真实板卡场景。下面这张清单概括了从零到交付的关键动作：

五、常见误区与复盘提示

下面是一段最小的Overlay示例，后续章节会逐行拆解。你可以先感受它的结构：

/dts-v1/;
/plugin/;

/ {
    fragment@0 {
        target = <&i2c1>;
        __overlay__ {
            status = "okay";
            #address-cells = <1>;
            #size-cells = <0>;

            sensor@48 {
                compatible = "ti,tmp102";
                reg = <0x48>;
            };
        };
    };
};

这段代码描述的是：在运行时把I2C1控制器打开，并在其下挂一个地址为0x48的TMP102温度传感器。编译成.dtbo后，通过configfs写入，内核会解析fragment、定位target、合并节点，并触发i2c驱动去匹配ti,tmp102。整个过程无需重启，也无需重新烧录根文件系统。

本课程的核心，就是把这看似简单的十几行代码，扩展成一套能应对多板卡、多外设、多版本、可回滚、可验证的工程体系。接下来，我们将从设备树与Overlay的基本概念开始，逐步搭建你的动态Overlay工程能力。