Linux设备树的传递以及Kernel中对设备树的解析

时间：2022-01-23 17:59:30

Linux设备树的传递以及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。

  1. /* Subcommand: GO */  
  2. static void boot_jump_linux(bootm_headers_t *images, int flag)  
  3. {  
  4. ...  
  5.   debug("## Transferring control to Linux (at address %08lx)" \  
  6.     "...\n", (ulong) kernel_entry);  
  7.   bootstage_mark(BOOTSTAGE_ID_RUN_OS);  
  8.   announce_and_cleanup(fake);  
  9.   if (IMAGE_ENABLE_OF_LIBFDT && images->ft_len)  
  10.     r2 = (unsigned long)images->ft_addr;  
  11.   else  
  12.     r2 = gd->bd->bi_boot_params;  
  13. ...  
  14. } 

r2 作为存放设备树地址的寄存器，其取值有两种方式，分别是例化 bootm_header_t 这个数据结构的 ft_addr，以及利用 U-Boot 的板级启动参数作为设备树的地址。

bootm_header_t 方式

数据结构 bootm_header_t 的定义如下，供各种内核的 SoC 使用，每家厂商根据自己 CPU 的特点对各个成员进行不同的例化。

  1. /*  
  2.  * Legacy and FIT format headers used by do_bootm() and do_bootm_<os>()  
  3.  * routines.  
  4.  */  
  5. typedef struct bootm_headers {  
  6.   ...  
  7.   char    *ft_addr;  /* flat dev tree address */  
  8.   ulong    ft_len;    /* length of flat device tree */  
  9.   ...  
  10. } bootm_headers_t; 

用 bootm_header_t 的方式，U-Boot 需支持设备树以及文件非空。

Linux设备树的传递以及Kernel中对设备树的解析

ft_len 以及 ft_addr 属于 bootm_header_t，在 U-Boot 解析镜像文件时，实例化这两个成员。函数调用栈如下：

  1. do_bootz(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])  
  2. -bootz_start() 
  3. --bootm_find_images(int flag, int argc, char *const argv[], ulong start,ulong size)  
  4. ---boot_get_fdt(flag, argc, argv, IH_ARCH_DEFAULT, &images,&images.ft_addr, &images.ft_len);  
  5.    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" 。

  1. Booting Linux on physical CPU 0x0  
  2. Linux version 5.4.124 (qemu@qemu) (gcc version 6.5.0 (Linaro GCC 6.5-2018.12)) #3 SMP Fri Jun 25 15:26:02 CST 2021  
  3. CPU: ARMv7 Processor [410fc090] revision 0 (ARMv7), cr=10c5387d  
  4. CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache  
  5. OF: fdt: Machine model: V2P-CA9 

这个模型名是在设备树文件的头部定义的，定义当前设备的总体名称。

  1. // SPDX-License-Identifier: GPL-2.0  
  2. /*  
  3.  * ARM Ltd. Versatile Express  
  4.  *  
  5.  * CoreTile Express A9x4  
  6.  * Cortex-A9 MPCore (V2P-CA9)  
  7.  *  
  8.  * HBI-0191B  
  9.  */  
  10. /dts-v1/; 
  11. #include "vexpress-v2m.dtsi"  
  12. / {  
  13.   model = "V2P-CA9";  
  14.   ...  
  15.   } 

但这并不是 kernel 对设备树第一次进行处理的地方。在此之前已有其他的操作。函数调用栈如下：

  1. setup_arch(char **cmdline_p) arch/arm/kernel/setup.c 
  2.     atags_vaddr = FDT_VIRT_BASE(__atags_pointer);   
  3.     setup_machine_fdt(void *dt_virt) arch/arm/kernel/devtree.c  
  4.         early_init_dt_verify()  
  5.         of_flat_dt_match_machine()  drivers/of/fdt.c  
  6.         early_init_dt_scan_nodes();  
  7.         __machine_arch_type = mdesc->nr; 

第 2 行、__atags_pointer 是 dtb 在内存中的地址，这个地址在汇编阶段（若镜像为 zImage，那么在解压缩阶段就完成了）便获取到了。由于执行到 setup_arch 时 mmu 已经使能并且 4K 的段页表也已经完成了映射，而 U-Boot 传递给 kernel 的设备树 fdt 地址属于物理地址，因此需要将物理地址转换成虚拟地址。

  1.   head-common.S  
  2.   .align  2  
  3.   .type  __mmap_switched_data, %object  
  4. __mmap_switched_data:  
  5. #ifdef CONFIG_XIP_KERNEL  
  6. #ifndef CONFIG_XIP_DEFLATED_DATA  
  7.   .long  _sdata        @ r0  
  8.   .long  __data_loc      @ r1  
  9.   .long  _edata_loc      @ r2  
  10. #endif 
  11.   .long  __bss_stop      @ sp (temporary stack in .bss)  
  12. #endif  
  13.   .long  __bss_start      @ r0  
  14.   .long  __bss_stop      @ r1  
  15.   .long  init_thread_union + THREAD_START_SP @ sp  
  16.   .long  processor_id      @ r0  
  17.   .long  __machine_arch_type    @ r1  
  18.   .long  __atags_pointer      @ r2 

第一阶段对设备树的配置主要包括：

A 对 dtb 文件进行 crc32 校验，检测设备树文件是否合法 early_init_dt_verify()

  1. B early_init_dt_scan_nodes()  
  2.         /* Retrieve various information from the /chosen node */  
  3.         of_scan_flat_dt(early_init_dt_scan_chosen, boot_command_line);  
  4.         /* Initialize {size,address}-cells info */  
  5.         of_scan_flat_dt(early_init_dt_scan_root, NULL);  
  6.         /* Setup memory, calling early_init_dt_add_memory_arch */  
  7.         of_scan_flat_dt(early_init_dt_scan_memory, NULL);  
  8. C 更新__machine_arch_type  
  9. D 更新 chosen 

上面这个 chosen 信息可以在 kernel 起来后再次查看做了哪些修改。

第二阶段

第二阶段单纯的是将设备树 ABI 文件进行解压缩，由 FDT 变成 EDT，生成相应的 device_node 结点。这个阶段的函数调用栈如下：

  1. unflatten_device_tree();  
  2.     *__unflatten_device_tree()  
  3.         /* First pass, scan for size */  
  4.         size = unflatten_dt_nodes(blob, NULL, dad, NULL);       
  5.          /* Second pass, do actual unflattening */  
  6.         unflatten_dt_nodes(blob, mem, dad, mynodes);  
  7.             unflatten_dt_nodes()  
  8.                 populate_node() 

device_nodes 结点如下：

Linux设备树的传递以及Kernel中对设备树的解析

device_node 创建完成后，kernel 创建 platform_device 时依据这个阶段完成的工作情况进行对应的设备注册，供驱动代码使用。

原文链接：https://mp.weixin.qq.com/s/PPOcZa-hr-iotGsec1O60w

标签：

相关文章