现代 U-Boot 如何使用设备树？读取、修改、传递与消费四站详解

产物编出来了，谁来接手？

上一节咱们把 mini.dts 编成了 293 字节的产物，你也亲眼见过它开头的 d00d feed。现在把它放回真实的启动现场：这块产物躺在启动介质的某个角落里，板子上了电，它自己是不会走到内核面前的。

你想想，内核刚醒的时候，连板上的硬件家底都没数过，早期的文件系统也没挂上，更别提自己到存储里翻文件了。所以中间必须有软件替它代劳。

板子上了电，头一个跑起来的软件叫引导器（bootloader）。咱们自由软件世界里最常见的实现就是 U-Boot。它的活儿是把硬件初始化到够用的程度，把内核镜像从存储搬进了内存，接着把设备树产物也搬了进来，最后跳进内核的入口。咱们下面就沿着启动的全程走一遍，看看编译好的产物是怎么一路走到内核手里的。

咱们把全程分成四站来认。引导器把产物 读取 进了内存，再把启动现场才知道的事实 修改 进产物，然后按约定把产物在内存里的地址 传递 给内核，最后的 消费 轮到内核解析产物、按描述干活。前三站都握在引导器手里，只有到了消费这一步才轮到 Linux，咱们挨站走过。

U-Boot 在中间做了什么

内核镜像和设备树产物在存储里是两个不同的文件，U-Boot 会按启动的配置把两个都读进内存，咱们把这一步叫 读取。它至少要认得产物的头部，认出了头部才知道这是一棵设备树，也才摸得清它有多大、被放在内存的哪里。U-Boot 还有一套自己的 fdt 命令，启动过程中你能在命令行里列出节点、查看属性，这说明它内部是真有一套解析代码在干活的。解析代码长什么样是第三卷的主场，你现在只要知道引导器是真的在读，这个印象就够用了。

轮到 修改 了。这是最容易被忽略的一段，也是咱们回收“设备树长什么样”那篇埋下伏笔的地方。那篇咱们说过，chosen 节点代表的不是真实设备，它记录的是“固件在启动时选择或指定的参数”。当时留了个悬念：到底是谁记录？现在答案揭晓了——U-Boot 在跳进内核之前会把启动现场才确定的事实写进产物里：

• 你敲的内核命令行（比如指定控制台的 console=...）会被写进 chosen 节点的 bootargs 属性，内核醒来之后读的就是这里。
• 如果用上了内存文件盘（initrd，也就是把文件系统镜像装进内存再交给内核的方案），它的起止地址同样写进 chosen。
• 内存的真实大小要等启动时才量得出来，产物里的 memory 节点会被按实修正。

编译时写好的描述是静态的，启动现场的事实是动态的。咱们在修改阶段做的，就是把这些动态的事实补进静态的描述。这一段其实也是“描述与使用分离”的又一处体现：描述负责编译时就能确定的部分，剩下的由引导器在现场补齐。

产物进了内存，可内核要到哪里找它？接下来就是 传递 了，讲的是把地址交出去的约定。不同的处理器架构和启动方式，约定了不同的交接位置。常见的 ARM 启动路径上，引导器把产物的内存地址放进双方说好的寄存器，跟着就跳进了内核入口，内核从那里把地址取走就是了。具体是哪个寄存器的问题，你现在不用记，只要抓住传递的本质：把地址放在双方约好的地方，再把控制权交出去就行。到了第三卷，这两步会有各自的整篇，源码是锁定版本逐条走读的，咱们在本节只认角色不追代码。

U-Boot 自己还有一棵树

讲到这你可能觉得 U-Boot 是在为 Linux 打工，其实它自己也是设备树的正经用户。它要打的启动日志走哪块串口控制台，要读的内核镜像藏在哪块存储控制器里，这些它都写在自己的一棵树里，启动的时候照着描述干活。

消费的路子跟 Linux 是同一个：U-Boot 里的每个驱动都带着一张 compatible 匹配表，启动的时候拿树里的节点逐个对表，节点对上了，这块硬件就交给这个驱动去初始化。咱们在讲 读取 的时候见过的 fdt 命令，摸的就是这同一套底子。所以回头看四站：交给 Linux 的那棵，U-Boot 管的是前三站；它自己的这棵，四站从头到尾全归它包了，连消费都算它自己的。

于是启动现场就有了两棵树：一棵服务 U-Boot 自己，一棵是要交给 Linux 的。两棵的职责并不相同，U-Boot 对交给 Linux 那棵做的修改，并不是在配置它自己的家底。你可别把 U-Boot 修改产物里的 memory 节点这件事，理解成它把自己的内存配置给改了——它改的是要移交出去的描述。这两棵树在第三卷开头的那几篇里会分清，咱们到时候追踪同一个节点在两处的不同命运，现在留个印象就够了。

U-Boot 不是必经之路，QEMU 直接启动是另一条路

咱们照例把话说准。U-Boot 到 Linux 是真实开发板上最常见的启动路线，也是本课程主线要研究的路线。但后面做实验的时候，你会见到另一条：QEMU(一个虚拟机)可以直接把内核和设备树装进虚拟机的内存来启动，引导器压根就没出场。两条路线各有各的实验价值，咱们两条都认。

所以“描述产物必经 U-Boot”这类说法，咱们不能把它说满。准确的说法是这样的：引导器在场的时候，读取、修改、传递就都是它的活；引导器缺席了，这三件事就由加载方一并做完了。阶段本身倒是不会消失，只是换了执行的人。

导读到这里就收尾了。第一卷的活很具体，咱们从改一行 DTS 入手，把设备树真正地用起来。

延伸阅读

本节讲的是角色和路线，给你备的出处都在两边的官方文档里：

• U-Boot: Devicetree Control —— U-Boot 官方说明它自己如何使用设备树来管理自身的配置，对应“U-Boot 自己的那棵树”。
• Linux: Devicetree Usage Model —— 内核官方讲设备树的使用模型，“消费”阶段的权威叙述在这里。
• U-Boot: fdt 命令 —— 在 U-Boot 命令行里直接查看和修改设备树的命令手册，读取和修改两个阶段的上手入口就在这里。

引导器跟内核交接的细节，要等第三卷在锁定的版本上核对过了，咱们才把它写进章节。