嵌入式设备树调试：除了U-Boot，内核启动早期如何动态修改DTB？

嵌入式设备树调试：内核启动早期动态修改DTB的进阶实践

在嵌入式系统开发中，设备树（Device Tree）作为硬件描述的标准方式，已经成为Linux内核不可或缺的组成部分。传统上，开发者习惯于在U-Boot阶段完成设备树的修改，但随着系统复杂度的提升，有时我们需要在内核启动的早期阶段对设备树进行动态调整。这种需求可能源于硬件识别延迟、运行时配置发现，或是需要根据实际检测到的硬件特性动态启用/禁用某些功能。

1. 内核早期启动阶段的DTB处理机制

当Linux内核开始执行时，设备树二进制文件（DTB）已经由bootloader加载到内存中。内核的启动流程中，有几个关键节点涉及设备树的处理：

start_kernel() -> setup_arch() -> setup_machine_fdt()

在setup_machine_fdt()函数中，内核主要完成以下工作：

1. 验证DTB的魔数和版本
2. 将物理地址映射为内核可访问的虚拟地址（dt_virt）
3. 解析/chosen节点获取启动参数
4. 处理内存保留区域（/memreserve/）

这个阶段特别适合进行动态修改，因为：

• 基本内存管理已经初始化
• 设备树尚未被各个子系统解析
• 可以访问到完整的启动参数和环境变量

注意：此时修改DTB必须确保不触发内存越界，且要预留足够的空间给后续可能添加的属性。

2. 动态修改DTB的核心技术实现

要在内核早期阶段安全地修改DTB，我们需要解决几个关键技术问题：

2.1 虚拟地址空间的获取

在setup_machine_fdt()阶段，内核已经通过fixmap_remap_fdt()将DTB物理地址映射到虚拟地址空间：

void *dt_virt = fixmap_remap_fdt(dt_phys, &size, PAGE_KERNEL);

这个dt_virt指针就是我们修改DTB的基础。需要注意的是，在ARM64架构中，这个映射是临时性的，后续会被重新映射为只读。

2.2 修改接口的封装

我们可以借鉴U-Boot中的do_fixup_by_path思路，在内核中实现类似的接口：

int fdt_find_and_setprop(void *fdt, const char *node, const char *prop, const void *val, int len, int create) { int nodeoff = fdt_path_offset(fdt, node); if (nodeoff < 0) return nodeoff; if ((!create) && (fdt_get_property(fdt, nodeoff, prop, NULL) == NULL)) return 0; return fdt_setprop(fdt, nodeoff, prop, val, len); }

2.3 内存空间的考量

动态修改DTB时，必须确保：

1. 修改后的DTB不超过原始大小（除非预留了额外空间）
2. 不覆盖/memreserve/区域
3. 保持所有结构体对齐

可以通过以下方式检查空间：

3. 实战：根据硬件ID动态配置设备

假设我们需要根据检测到的硬件版本动态配置PCIe控制器，以下是实现步骤：

3.1 硬件识别

首先通过早期可用的外设（如GPIO或I2C）读取硬件ID：

static int get_hardware_version(void) { /* 实际实现可能通过GPIO或I2C读取硬件信息 */ return 2; /* 示例返回值 */ }

3.2 动态修改DTB

在setup_machine_fdt()之后添加修改逻辑：

int dtb_dynamic_fixup(void *fdt) { int version = get_hardware_version(); switch(version) { case 1: do_fixup_by_path(fdt, "/pcie@fe190000", "max-link-speed", &(u32){1}, sizeof(u32), 1); break; case 2: do_fixup_by_path(fdt, "/pcie@fe190000", "max-link-speed", &(u32){2}, sizeof(u32), 1); fdt_appendprop_string(fdt, "/", "compatible", "custom-board-v2"); break; } return 0; }

3.3 集成到启动流程

将修改函数插入到内核启动流程中：

--- a/arch/arm64/kernel/setup.c +++ b/arch/arm64/kernel/setup.c @@ -202,6 +202,9 @@ static void __init setup_machine_fdt(phys_addr_t dt_phys) while (true) cpu_relax(); + if (dt_virt && !dtb_dynamic_fixup(dt_virt)) + pr_info("DTB dynamic fixup applied\n"); + /* Early fixups are done, map the FDT as read-only now */ fixmap_remap_fdt(dt_phys, &size, PAGE_KERNEL_RO);

4. 风险控制与最佳实践

在内核早期阶段修改DTB存在一定风险，需要特别注意以下方面：

4.1 内存安全

• 预留空间检查：确保DTB有足够的剩余空间容纳新增属性
• 内存保留区：不得修改/memreserve/区域，否则可能导致内存冲突
• 对齐要求：所有修改必须保持4字节对齐

4.2 时序考虑

修改DTB的最佳时机是在：

1. setup_machine_fdt()完成基本验证后
2. 任何子系统开始解析DTB前
3. 确保必要的硬件初始化已经完成

4.3 调试技巧

当修改不生效时，可以：

1. 通过fdt_print()检查修改是否成功
2. 在内核命令行添加earlycon查看早期打印
3. 检查dt_virt是否有效
4. 确认没有触发内核的FDT_ERR_NOSPACE错误

5. 高级应用场景

动态DTB修改技术在以下场景中特别有价值：

5.1 硬件变体支持

同一PCB设计可能因成本或供应问题使用不同芯片型号。通过运行时检测自动配置正确的驱动参数：

void configure_ethernet(void *fdt) { if (detect_phy_type() == PHY_REALTEK) { do_fixup_by_path(fdt, "/ethernet@fe1b0000", "phy-mode", "rgmii", 6, 1); } else { do_fixup_by_path(fdt, "/ethernet@fe1b0000", "phy-mode", "rmii", 5, 1); } }

5.2 安全启动配置

根据安全芯片的存在与否动态调整加密相关设置：

void security_config(void *fdt) { if (check_hardware_security()) { do_fixup_by_path_u32(fdt, "/security", "trustzone-enabled", 1, 1); do_fixup_by_path_u32(fdt, "/crypto", "hardware-accelerated", 1, 1); } }

5.3 生产测试模式

在生产测试阶段临时启用额外的调试接口：

void production_test_config(void *fdt) { if (is_production_test()) { do_fixup_by_path(fdt, "/debug@ff660000", "status", "okay", 5, 1); do_fixup_by_path_u32(fdt, "/debug@ff660000", "test-points", 0x1234, 1); } }

在实际项目中，我们曾遇到一个典型案例：某工控设备需要支持两种不同的显示接口（LVDS和eDP），但只能在硬件初始化后才能确定实际使用的接口类型。通过在setup_machine_fdt阶段读取GPIO状态动态修改DTB，我们成功实现了单一固件自动适配两种硬件配置，省去了维护不同固件版本的麻烦。这种技术特别适合硬件迭代频繁或需要支持多种配置的场景。