很多人第一次看嵌入式 Linux 启动链，都会被一种很强的割裂感卡住。
明明前面在 U-Boot 里敲的是 setenv bootargs ...，到了内核里却变成了：
内存大小
串口节点
中断控制器
/chosen/bootargs
stdout-path
更常见的是，明明改了 dts、重新编译了 dtb，结果内核读到的参数还是旧的。
一句话先讲明白。
设备树不是内核自己去找出来的，而是 bootloader 先把 dtb 准备好，再把它的地址交给内核；而 /chosen/bootargs 往往也是 bootloader 在启动内核前写进去的。
所以关键从来不是 dtb 文件存在哪。
关键是启动交接时，谁把哪份 dtb 传给了内核，以及启动前有没有改过它。
第一，设备树本质上是什么
设备树本质上是一份硬件描述数据。
它告诉内核：板子上有哪些硬件，内存在哪里，串口是谁，中断控制器是谁，设备挂在哪条总线上，以及某些关键启动参数放在哪。
也就是说，内核启动时并不是天然知道这块板子长什么样。
它需要别人把这份“硬件说明书”交给它。
这份说明书，在 ARM 和很多嵌入式平台里，通常就是 dtb。
设备树不是给 U-Boot 看的主配置文件，它更像给 Linux 内核看的硬件说明书。
第二，设备树是谁传给内核的
在大多数嵌入式 Linux 启动场景里，真正把设备树传给内核的，是 U-Boot。
常见流程很简单：U-Boot 先把 dtb 从存储介质读到内存，必要时做一些修改，最后在执行 booti、bootm、bootz时，把 dtb 地址一并交给内核。
所以内核并不是自己去某个分区、某个文件系统里找 dtb 文件。
它拿到的是 bootloader 已经准备好、并放到内存里的那一份设备树。
这点非常关键。
因为很多人排查设备树问题时，只盯着磁盘上的 dtb 文件，却忽略了真正传给内核的，可能已经不是那份原始文件了。
第三，为什么传给内核的 dtb 往往不是原封不动的
因为 U-Boot 在启动前，常常会改它。
最典型的就是 /chosen 节点。
很多平台在启动 Linux 前，U-Boot 会往 dtb 里补一些运行时信息，比如 bootargs、stdout-path、initrd 起止地址、某些内存保留信息，以及板级运行时修正内容。
这意味着，编译出来的 dtb 只是一个基础模板，真正进内核前，它可能已经被 U-Boot patch 过了。
所以如果你看到内核里的某些设备树内容和源码里的 dts 不完全一样，先不要急着怀疑编译错误。
很有可能是 U-Boot 在交接前动态改过。
一个经典例子就是 memory 节点。
你在 dts 里可能写的是 1GB，但如果 bdinfo 里看到的内存大小和 dtb 里写的不一样，或者内核实际识别出来的内存大小又变了，也不用惊讶。
很多平台上，U-Boot 会根据自己的内存探测结果或板级修正，动态修改 dtb 里的 memory 节点。
所以真实链条往往是：U-Boot 先探测内存，再覆盖 dtb 里的 memory，最后内核再从这份 dtb 里读到内存大小。
第四，/chosen 节点到底是什么
如果你看过设备树源码，大概率见过这样的内容：
dts/chosen { bootargs = "..."; stdout-path = "...";};
很多人第一次看会以为 /chosen 是某个硬件节点。
其实不是。
/chosen 更像一个启动交接专用节点。
它不是在描述某个外设，而是在告诉内核一些和“这次启动怎么接着往下走”相关的信息，比如 bootargs、stdout-path、initrd 地址，以及某些启动期附加信息。
简单说，设备树里大部分节点是在描述硬件，/chosen 更像是在描述启动上下文。
第五，/chosen/bootargs 到底是怎么进去的
这是最常见、也最容易混的问题。
很多人看到 /chosen/bootargs 会问：这到底是写在 dts 里的，还是 U-Boot 的环境变量塞进去的？
答案是：
两种情况都可能，但现场最常见的是 U-Boot 在启动前把环境变量里的 bootargs 写进 /chosen/bootargs。
常见路径通常是这样：
1. 你在 U-Boot 里有一个环境变量 bootargs。
2. 这个字符串里写着 console=... root=... rootwait earlycon ...。
3. U-Boot 在启动前把它写进 dtb 的 /chosen/bootargs。
4. 内核启动时从 dtb 里读到它。
所以很多人表面上是在改 U-Boot 环境变量，实际最终效果是改了传给内核的设备树里的 /chosen/bootargs。
这就是为什么你会感觉，明明是在 U-Boot 里 setenv bootargs，结果内核那边看到的是 /chosen/bootargs。
如果再往底层看一步，这个过程通常会发生在 U-Boot 启动 Linux 之前：
所以你在内核里看到的 /chosen/bootargs，本质上往往已经是 U-Boot 运行时环境变量的一份快照。
第六，为什么 dts 里有时也能看到 bootargs
因为设备树源码里本来也可以写死：
/chosen { bootargs = "console=ttyS0,115200 root=/dev/mmcblk0p2 rw";};
这种做法不是不行，但在实际产品和调试里通常不够灵活。
因为启动参数经常会变：根文件系统位置会变，console 会变，可能要临时加 earlycon，启动介质也可能会换。
所以更常见的做法是：dts 里可以有默认值，但启动时由 U-Boot 用环境变量覆盖或更新。
也就是说，源码里的 bootargs 更像默认模板，真正生效的往往是 bootloader 改过后的结果。
第七，内核到底从哪里读取启动参数
很多人会把这几个来源混在一起：
U-Boot 环境变量 bootargs、
设备树里的 /chosen/bootargs、
以及最后看到的内核命令行。
其实把链条串起来就不难了：
所以内核真正接手时，常见直接来源通常是 dtb 里的 /chosen/bootargs。
而 U-Boot 环境变量，更多是它的上游来源。
一句更好记的话就是：
U-Boot 的 bootargs是“准备参数”，
/chosen/bootargs 是“交给内核的参数”。
第八，为什么这条链这么重要
因为很多启动问题，表面上看像内核问题，本质上其实是设备树交接问题。
最典型的现象就是：
这时候如果你只盯着内核镜像、rootfs 或某个驱动，很容易走偏。
因为真正该先确认的是：
U-Boot 到底加载了哪份 dtb，启动前有没有改/chosen，内核最终拿到的 bootargs 到底是什么。
很多“内核为什么这样启动”的问题，根子其实不在内核，而在 bootloader 交给它的设备树。
第九，工程上最该怎么记这件事
最稳的理解方式，不是把 dtb 看成一个静态文件，而是把它看成 bootloader 交给内核的一份启动期硬件描述和参数载体。
这里面最关键的两层要分开：
设备树主体节点主要描述硬件，
/chosen节点主要描述启动交接信息。
只要这个边界清楚，很多问题马上就顺了：
为什么 dts 里没改，内核看到的却变了；
为什么 setenv bootargs 会影响内核命令行；
为什么串口输出问题常常要回头看 dtb 和 /chosen；
为什么 rootfs 问题有时也要回头看设备树传参。
最后把它压成两句话就够了。
Linux 启动时使用的设备树，通常是 U-Boot 先加载到内存，再在启动前把 bootargs等运行时信息写入 /chosen节点，最后把这份 dtb 的地址连同内核一起交给 Linux。
所以内核拿到的设备树，往往不是静态文件本身，而是 bootloader 处理后的结果。
怎么一句话记住
dtb 是 U-Boot 传给内核的，
/chosen/bootargs往往也是 U-Boot 写进去的。
所以下次当你遇到这些现象时，不要第一时间去怀疑内核或驱动：
更稳的判断方式只有一条：当你在内核里看到设备树内容时，先默认那是 U-Boot 加工后的“最终交付物”，而不是源码里的“原材料”。
10个月宝宝每天需要喝多少奶粉？