设备树的传递及kernel 对设备树的解析
当 u-boot 将设备树加载到内存指定位置后，arm 内核的 soc 以通用寄存器 r2 来传递 dtb 在内存中的地址。kernel 获取到该地址后对 dtb 文件做进一步的处理。
设备树的传递
当使用 bootm 加载 kernel 镜像时（bootz 是对 bootm 的一种封装以及功能扩展，实质一样）。u-boot 跳转到 kernel 的入口函数是 boot_jump_linux
这个函数的 c 文件在 arch/arm/lib 下，说明设备树的传递的方式是与 soc 架构相关的。不同的 soc 在 bring-up 时，这个函数格外重要，这是 u-boot 与 kernel 之间衔接、交互信息的一个关键 api。u-boot 的这个函数执行结束后，将 cpu 的控制权完整的交给 kernel。
/* subcommand： go */static void boot_jump_linux（bootm_headers_t *images， int flag）
{
。。。
debug（“## transferring control to linux （at address %08lx）”
“。。。
”， （ulong） kernel_entry）;
bootstage_mark（bootstage_id_run_os）;
announce_and_cleanup（fake）;
if （image_enable_of_libfdt && images-》ft_len）
r2 = （unsigned long）images-》ft_addr;
else
r2 = gd-》bd-》bi_boot_params;
。。。
}
r2 作为存放设备树地址的寄存器，其取值有两种方式，分别是例化 bootm_header_t 这个数据结构的 ft_addr，以及利用 u-boot 的板级启动参数作为设备树的地址。
bootm_header_t 方式
数据结构 bootm_header_t 的定义如下，供各种内核的 soc 使用，每家厂商根据自己 cpu 的特点对各个成员进行不同的例化。
/*
* legacy and fit format headers used by do_bootm（） and do_bootm_《os》（）
* routines.
*/typedef struct bootm_headers {
。。。
char *ft_addr; /* flat dev tree address */
ulong ft_len; /* length of flat device tree */
。。。
} bootm_headers_t;
用 bootm_header_t 的方式，u-boot 需支持设备树以及文件非空。
ft_len 以及 ft_addr 属于 bootm_header_t，在 u-boot 解析镜像文件时，实例化这两个成员。函数调用栈如下：
do_bootz（struct cmd_tbl *cmdtp， int flag， int argc， char *const argv［］）
-bootz_start（）
--bootm_find_images（int flag， int argc， char *const argv［］， ulong start，ulong size）
---boot_get_fdt（flag， argc， argv， ih_arch_default， &images，&images.ft_addr， &images.ft_len）;
u-boot-v2021.04/common/image-fdt.c
gd-》bd-》bi_boot_params 方式
这种属于比较古老的一种方式了，目前基本不会采用。bi_boot_params 是一个存放内核启动参数的地址，通常是在板级初始化中进行指定。
代码执行到此处，r2 是否为预期的值，一是可以通过打印的方式、再有使用调试工具连上去确认。
kernel 对设备树的解析
解析分两个阶段，第一阶段进行校验以及启动参数的再调整；第二阶段完成设备树的解压，也就是将设备树由 fdt 变成 edt，创建 device_node。
第一阶段
kernel 启动日志中与设备树相关的第一条打印如下，也就是打印出当前硬件设备的模型名，“of： fdt： machine model： v2p-ca9”
booting linux on physical cpu 0x0
linux version 5.4.124 （qemu@qemu） （gcc version 6.5.0 （linaro gcc 6.5-2018.12）） #3 smp fri jun 25 1502 cst 2021
cpu： armv7 processor ［410fc090］ revision 0 （armv7）， cr=10c5387d
cpu： pipt / vipt nonaliasing data cache， vipt nonaliasing instruction cache
of： fdt： machine model： v2p-ca9
这个模型名是在设备树文件的头部定义的，定义当前设备的总体名称。
// spdx-license-identifier： gpl-2.0/*
* arm ltd. versatile express
*
* coretile express a9x4
* cortex-a9 mpcore （v2p-ca9）
*
* hbi-0191b
*/
/dts-v1/;
#include “vexpress-v2m.dtsi”
/ {
model = “v2p-ca9”;
。。。
}
但这并不是 kernel 对设备树第一次进行处理的地方。在此之前已有其他的操作。函数调用栈如下：
setup_arch（char **cmdline_p） arch/arm/kernel/setup.c
atags_vaddr = fdt_virt_base（__atags_pointer）;
setup_machine_fdt（void *dt_virt） arch/arm/kernel/devtree.c
early_init_dt_verify（）
of_flat_dt_match_machine（） drivers/of/fdt.c
early_init_dt_scan_nodes（）;
__machine_arch_type = mdesc-》nr;
第 2 行、__atags_pointer 是 dtb 在内存中的地址，这个地址在汇编阶段（若镜像为 zimage，那么在解压缩阶段就完成了）便获取到了。由于执行到 setup_arch 时 mmu 已经使能并且 4k 的段页表也已经完成了映射，而 u-boot 传递给 kernel 的设备树 fdt 地址属于物理地址，因此需要将物理地址转换成虚拟地址。
head-common.s
.align 2
.type __mmap_switched_data， %object
__mmap_switched_data：
#ifdef config_xip_kernel#ifndef config_xip_deflated_data
.long _sdata @ r0
.long __data_loc @ r1
.long _edata_loc @ r2
#endif
.long __bss_stop @ sp （temporary stack in .bss）
#endif
.long __bss_start @ r0
.long __bss_stop @ r1
.long init_thread_union + thread_start_sp @ sp
.long processor_id @ r0
.long __machine_arch_type @ r1
.long __atags_pointer @ r2
第一阶段对设备树的配置主要包括：
a 对 dtb 文件进行 crc32 校验，检测设备树文件是否合法 early_init_dt_verify（）
b early_init_dt_scan_nodes（）
/* retrieve various information from the /chosen node */
of_scan_flat_dt（early_init_dt_scan_chosen， boot_command_line）;
/* initialize {size，address}-cells info */
of_scan_flat_dt（early_init_dt_scan_root， null）;
/* setup memory， calling early_init_dt_add_memory_arch */
of_scan_flat_dt（early_init_dt_scan_memory， null）;
c 更新__machine_arch_type
d 更新 chosen
上面这个 chosen 信息可以在 kernel 起来后再次查看做了哪些修改。
第二阶段
第二阶段单纯的是将设备树 abi 文件进行解压缩，由 fdt 变成 edt，生成相应的 device_node 结点。这个阶段的函数调用栈如下：
unflatten_device_tree（）;
*__unflatten_device_tree（）
/* first pass， scan for size */
size = unflatten_dt_nodes（blob， null， dad， null）;
/* second pass， do actual unflattening */
unflatten_dt_nodes（blob， mem， dad， mynodes）;
unflatten_dt_nodes（）
populate_node（）
device_nodes 结点如下：
device_node 创建完成后，kernel 创建 platform_device 时依据这个阶段完成的工作情况进行对应的设备注册，供驱动代码使用。
兼容AD2S1205，基于RDC SC2121的旋变位置解码系统方案
浅谈中国航天运载火箭发动机取得新进展及规划
LSI展示面向Windows Server的HA－DAS解决方案
理想的区块链技术是怎么样现实有事怎么样的
TMC5160智能步进驱控芯片外置MOSFETs带有StealthChop、SpreadCycle静音防抖动技术
设备树的传递及kernel 对设备树的解析
天津医院采用VR沙盘游戏心理疗法用于心理治疗
C8051F120与RS422息线的时钟同步技术
动力电池市场的国际化竞逐，正在向上游结构件领域蔓延
与动物对话不再是科幻？跨物种翻译技术正在来袭！
科学家发明法拉第织物，可阻挡所有电磁波
UVC在一定条件下也可以用于杀菌高浓度果酱
蒲公英工业4G路由器助力自动终端数据高效收集
如何采用PIC单片机更新LCD数据
基站电源电池是否有修复价值？
大众对标特斯拉：工厂升级，10 小时造一辆车
智能人脸识别一体机的介绍及其应用
浅谈PCB设计的通孔、盲孔、埋孔
视频监控系统应用越来越广泛，不断助力安防行业增长
输电线路线夹测温装置的功能特点及技术参数
设备树的传递
当使用 bootm 加载 kernel 镜像时（bootz 是对 bootm 的一种封装以及功能扩展，实质一样）。u-boot 跳转到 kernel 的入口函数是 boot_jump_linux
这个函数的 c 文件在 arch/arm/lib 下，说明设备树的传递的方式是与 soc 架构相关的。不同的 soc 在 bring-up 时，这个函数格外重要，这是 u-boot 与 kernel 之间衔接、交互信息的一个关键 api。u-boot 的这个函数执行结束后，将 cpu 的控制权完整的交给 kernel。
/* subcommand： go */static void boot_jump_linux（bootm_headers_t *images， int flag）
{
。。。
debug（“## transferring control to linux （at address %08lx）”
“。。。
”， （ulong） kernel_entry）;
bootstage_mark（bootstage_id_run_os）;
announce_and_cleanup（fake）;
if （image_enable_of_libfdt && images-》ft_len）
r2 = （unsigned long）images-》ft_addr;
else
r2 = gd-》bd-》bi_boot_params;
。。。
}
r2 作为存放设备树地址的寄存器，其取值有两种方式，分别是例化 bootm_header_t 这个数据结构的 ft_addr，以及利用 u-boot 的板级启动参数作为设备树的地址。
bootm_header_t 方式
数据结构 bootm_header_t 的定义如下，供各种内核的 soc 使用，每家厂商根据自己 cpu 的特点对各个成员进行不同的例化。
/*
* legacy and fit format headers used by do_bootm（） and do_bootm_《os》（）
* routines.
*/typedef struct bootm_headers {
。。。
char *ft_addr; /* flat dev tree address */
ulong ft_len; /* length of flat device tree */
。。。
} bootm_headers_t;
用 bootm_header_t 的方式，u-boot 需支持设备树以及文件非空。
ft_len 以及 ft_addr 属于 bootm_header_t，在 u-boot 解析镜像文件时，实例化这两个成员。函数调用栈如下：
do_bootz（struct cmd_tbl *cmdtp， int flag， int argc， char *const argv［］）
-bootz_start（）
--bootm_find_images（int flag， int argc， char *const argv［］， ulong start，ulong size）
---boot_get_fdt（flag， argc， argv， ih_arch_default， &images，&images.ft_addr， &images.ft_len）;
u-boot-v2021.04/common/image-fdt.c
gd-》bd-》bi_boot_params 方式
这种属于比较古老的一种方式了，目前基本不会采用。bi_boot_params 是一个存放内核启动参数的地址，通常是在板级初始化中进行指定。
代码执行到此处，r2 是否为预期的值，一是可以通过打印的方式、再有使用调试工具连上去确认。
kernel 对设备树的解析
解析分两个阶段，第一阶段进行校验以及启动参数的再调整；第二阶段完成设备树的解压，也就是将设备树由 fdt 变成 edt，创建 device_node。
第一阶段
kernel 启动日志中与设备树相关的第一条打印如下，也就是打印出当前硬件设备的模型名，“of： fdt： machine model： v2p-ca9”
booting linux on physical cpu 0x0
linux version 5.4.124 （qemu@qemu） （gcc version 6.5.0 （linaro gcc 6.5-2018.12）） #3 smp fri jun 25 1502 cst 2021
cpu： armv7 processor ［410fc090］ revision 0 （armv7）， cr=10c5387d
cpu： pipt / vipt nonaliasing data cache， vipt nonaliasing instruction cache
of： fdt： machine model： v2p-ca9
这个模型名是在设备树文件的头部定义的，定义当前设备的总体名称。
// spdx-license-identifier： gpl-2.0/*
* arm ltd. versatile express
*
* coretile express a9x4
* cortex-a9 mpcore （v2p-ca9）
*
* hbi-0191b
*/
/dts-v1/;
#include “vexpress-v2m.dtsi”
/ {
model = “v2p-ca9”;
。。。
}
但这并不是 kernel 对设备树第一次进行处理的地方。在此之前已有其他的操作。函数调用栈如下：
setup_arch（char **cmdline_p） arch/arm/kernel/setup.c
atags_vaddr = fdt_virt_base（__atags_pointer）;
setup_machine_fdt（void *dt_virt） arch/arm/kernel/devtree.c
early_init_dt_verify（）
of_flat_dt_match_machine（） drivers/of/fdt.c
early_init_dt_scan_nodes（）;
__machine_arch_type = mdesc-》nr;
第 2 行、__atags_pointer 是 dtb 在内存中的地址，这个地址在汇编阶段（若镜像为 zimage，那么在解压缩阶段就完成了）便获取到了。由于执行到 setup_arch 时 mmu 已经使能并且 4k 的段页表也已经完成了映射，而 u-boot 传递给 kernel 的设备树 fdt 地址属于物理地址，因此需要将物理地址转换成虚拟地址。
head-common.s
.align 2
.type __mmap_switched_data， %object
__mmap_switched_data：
#ifdef config_xip_kernel#ifndef config_xip_deflated_data
.long _sdata @ r0
.long __data_loc @ r1
.long _edata_loc @ r2
#endif
.long __bss_stop @ sp （temporary stack in .bss）
#endif
.long __bss_start @ r0
.long __bss_stop @ r1
.long init_thread_union + thread_start_sp @ sp
.long processor_id @ r0
.long __machine_arch_type @ r1
.long __atags_pointer @ r2
第一阶段对设备树的配置主要包括：
a 对 dtb 文件进行 crc32 校验，检测设备树文件是否合法 early_init_dt_verify（）
b early_init_dt_scan_nodes（）
/* retrieve various information from the /chosen node */
of_scan_flat_dt（early_init_dt_scan_chosen， boot_command_line）;
/* initialize {size，address}-cells info */
of_scan_flat_dt（early_init_dt_scan_root， null）;
/* setup memory， calling early_init_dt_add_memory_arch */
of_scan_flat_dt（early_init_dt_scan_memory， null）;
c 更新__machine_arch_type
d 更新 chosen
上面这个 chosen 信息可以在 kernel 起来后再次查看做了哪些修改。
第二阶段
第二阶段单纯的是将设备树 abi 文件进行解压缩，由 fdt 变成 edt，生成相应的 device_node 结点。这个阶段的函数调用栈如下：
unflatten_device_tree（）;
*__unflatten_device_tree（）
/* first pass， scan for size */
size = unflatten_dt_nodes（blob， null， dad， null）;
/* second pass， do actual unflattening */
unflatten_dt_nodes（blob， mem， dad， mynodes）;
unflatten_dt_nodes（）
populate_node（）
device_nodes 结点如下：
device_node 创建完成后，kernel 创建 platform_device 时依据这个阶段完成的工作情况进行对应的设备注册，供驱动代码使用。
兼容AD2S1205，基于RDC SC2121的旋变位置解码系统方案
浅谈中国航天运载火箭发动机取得新进展及规划
LSI展示面向Windows Server的HA－DAS解决方案
理想的区块链技术是怎么样现实有事怎么样的
TMC5160智能步进驱控芯片外置MOSFETs带有StealthChop、SpreadCycle静音防抖动技术
设备树的传递及kernel 对设备树的解析
天津医院采用VR沙盘游戏心理疗法用于心理治疗
C8051F120与RS422息线的时钟同步技术
动力电池市场的国际化竞逐，正在向上游结构件领域蔓延
与动物对话不再是科幻？跨物种翻译技术正在来袭！
科学家发明法拉第织物，可阻挡所有电磁波
UVC在一定条件下也可以用于杀菌高浓度果酱
蒲公英工业4G路由器助力自动终端数据高效收集
如何采用PIC单片机更新LCD数据
基站电源电池是否有修复价值？
大众对标特斯拉：工厂升级，10 小时造一辆车
智能人脸识别一体机的介绍及其应用
浅谈PCB设计的通孔、盲孔、埋孔
视频监控系统应用越来越广泛，不断助力安防行业增长
输电线路线夹测温装置的功能特点及技术参数