4. DTB在启动流程中的位置：DTB在启动链中的传递路径、从Bootloader到内核的交接点
设备树二进制（DTB）并非凭空出现在内核内存中，它遵循一条明确的硬件初始化链，从片上ROM逐级传递至最终的操作系统内核。理解DTB在启动流程中的位置，是诊断设备枚举失败、内存映射错误以及外设驱动加载异常的关键前提。
4.1 启动链中的DTB传递全景
典型的ARMv8/AArch64或RISC-V平台启动链包含四个主要阶段，DTB在每个阶段扮演不同角色：
| 启动阶段 | 执行者 | DTB角色 | 存储位置 |
|---|---|---|---|
| Stage 1 (ROM) | 片上BootROM | 无DTB，仅加载下一级镜像 | 内部ROM / eFuse |
| Stage 2 (SPL/MLO) | 二级程序加载器 | 可选：读取固定偏移的DTB片段，初始化DRAM | SRAM / 片上内存 |
| Stage 3 (Bootloader) | U-Boot / TF-A / EDK II | 核心：加载完整DTB，进行平台修补，传递给内核 | DRAM (通常位于低地址区域) |
| Stage 4 (Kernel) | Linux内核 (head.S / setup_arch) | 解析DTB，创建struct device_node树 | 内核线性映射区 |
关键交接点： Bootloader在跳转到内核入口点之前，必须将DTB的物理地址通过特定寄存器传递给内核。对于ARM64，该寄存器为
x0；对于RISC-V，为a1。内核在最早期的汇编代码中立即保存该地址，随后在C语言初始化阶段进行解析。
4.2 从Bootloader到内核的交接点：寄存器约定
Bootloader与内核之间关于DTB传递的约定是二进制接口（ABI）的一部分，违反该约定将导致内核无法找到设备树，进而触发panic或回退到空设备树。以下是主流架构的传递规范：
- ARM32 (arch/arm/)：寄存器
r2必须包含DTB物理地址。内核通过__vet_atags检查该地址的有效性。 - ARM64 (arch/arm64/)：寄存器
x0传递DTB地址。内核在head.S的preserve_boot_args中保存x0到boot_args[0]。 - RISC-V (arch/riscv/)：寄存器
a1传递DTB地址。内核在head.S中将其存入s1寄存器，随后传递给setup_arch。 - x86 (arch/x86/)：不使用寄存器传递。Bootloader（如GRUB）通过
boot_params结构中的hdr.setup_data链表传递DTB。
调试技巧： 如果内核启动时出现
“No FDT found”或“OF: fdt: not found”错误，首先检查Bootloader是否在正确的寄存器中设置了DTB地址。使用JTAG或早期串口打印Bootloader的寄存器状态是定位此类问题的有效手段。
4.3 DTB传递路径的SVG架构图
下图展示了从Bootloader加载DTB到内核完成解析的完整数据流与寄存器交接点：
4.4 Bootloader侧的DTB加载与修补流程
以U-Boot为例，DTB在Bootloader阶段的处理包含以下标准步骤：
- 定位DTB源：从FAT/EXT4分区、TFTP服务器或SPI Flash中读取
.dtb文件。 - 加载到DRAM：使用
load命令或bootm流程将DTB放入预定义地址（如0x88000000）。 - 平台修补：调用
fdt_fixup_memory()添加实际检测到的DRAM大小和Bank信息；调用fdt_fixup_ethernet()设置MAC地址。 - 设置启动参数：将DTB地址写入
bootm_fdt_addr变量，或直接通过booti/bootm命令传递。 - 跳转内核：执行
booti $kernel_addr $ramdisk_addr $fdt_addr，其中第三个参数即为DTB地址。
常见陷阱： 如果Bootloader在修补DTB时修改了
/memory节点但未更新reg属性的长度（#address-cells和#size-cells），内核解析时将读取错误的物理内存范围，导致部分DRAM不可用。务必使用fdt addr和fdt list命令验证修补后的DTB内容。
4.5 内核侧的DTB接收与解析入口
内核在接收到DTB地址后，经历以下关键解析阶段：
| 阶段 | 函数/位置 | 操作 | 输出 |
|---|---|---|---|
| 1. 保存参数 | arch/arm64/kernel/head.S |
将x0存入boot_args[0] |
全局变量保存DTB物理地址 |
| 2. 早期扫描 | early_init_dt_scan() |
验证FDT魔数，扫描chosen/memory节点 | 初始化内存块、命令行参数 |
| 3. 展开设备树 | unflatten_device_tree() |
将扁平DTB转换为struct device_node树 | 全局of_root指针 |
| 4. 平台填充 | of_platform_populate() |
遍历device_node树，创建platform_device | 设备模型中的设备实例 |
4.6 多阶段Bootloader中的DTB接力
在启用Trusted Firmware-A（TF-A）或U-Boot SPL的系统中，DTB可能经历多次传递：
- SPL阶段：SPL可能加载一个最小DTB（
u-boot.dtb），仅包含DRAM初始化所需信息。该DTB通常嵌入在SPL二进制中。 - TF-A阶段：TF-A（BL31）通常不直接处理DTB，但可能通过
ARM_LINUX_KERNEL_AS_BL33配置将DTB地址传递给下一阶段。 - U-Boot proper阶段：U-Boot从存储介质加载完整的
board.dtb，进行最终修补，然后传递给内核。
性能考量： 每次DTB传递都涉及内存拷贝或地址重映射。在SPL到U-Boot proper的切换中，如果DTB位于SPL可访问的SRAM区域，U-Boot proper可能无法直接访问该地址（因MMU配置变化）。此时U-Boot必须将DTB重新拷贝到DRAM中可访问的区域，这会引入约数十微秒的延迟。
4.7 调试DTB传递的实用方法
当DTB传递出现问题时，以下方法可快速定位故障点：
- Bootloader侧验证：在U-Boot命令行执行
fdt addr $fdt_addr，然后fdt list查看DTB内容是否完整。 - 内核早期打印：启用
CONFIG_DEBUG_LL和earlyprintk，观察内核是否打印“Machine model: ...”。如果未打印，说明DTB地址未被正确接收。 - QEMU仿真验证：使用
qemu-system-aarch64 -machine virt -kernel Image -dtb board.dtb -append "console=ttyAMA0"，通过-dtb参数直接传递DTB，排除Bootloader干扰。 - 内存转储：在Bootloader中执行
md.b $fdt_addr 100，检查DTB头部魔数（d00dfeed大端）是否正确。
理解DTB在启动链中的精确位置和传递机制，使开发者能够在系统无法启动时快速区分是Bootloader未正确加载DTB、修补错误，还是内核解析逻辑出现问题。这是嵌入式Linux启动调试中最核心的技能之一。