dtb 数据解析

内核启动阶段获得 dtb 位置指针

以 arm64 为例,内核启动如下:

1
2
3
4
5
6
7
8
9
10
11
__HEAD
_head:

#ifdef CONFIG_EFI
add x13, x18, #0x16
b stext
#else
b stext // branch to kernel start, magic
.long 0 // reserved
#endif
...

在开启 UEFI 支持时,add x13, x18, #0x16 这个 code 实际上是为了满足 EFI 格式的”MZ”头。如果使用 UEFI 来启动 kernel, 会识别出来并走 UEFI 启动的流程,如果是普通的启动过程如使用 uboot 的 booti 进行引导,那么第一条指令就是一条 dummy 指令,第二条就跳转到 stext 运行了。

x0 寄存器保存的是 dtb 里 blob 块的物理地址,x0 寄存器内容由 uboot 设置,uboot 将 dtb 地址传递给内核,跳转到 stext,如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
ENTRY(stext)
bl preserve_boot_args
bl el2_setup // Drop to EL1, w0=cpu_boot_mode
adrp x23, __PHYS_OFFSET
and x23, x23, MIN_KIMG_ALIGN - 1 // KASLR offset, defaults to 0
bl set_cpu_boot_mode_flag
bl __create_page_tables
bl __cpu_setup // initialise processor
b __primary_switch
ENDPROC(stext)
...
preserve_boot_args:
mov x21, x0 // x21=FDT

adr_l x0, boot_args // record the contents of
stp x21, x1, [x0] // x0 .. x3 at kernel entry
stp x2, x3, [x0, #16]

dmb sy // needed before dc ivac with
// MMU off

add x1, x0, #0x20 // 4 x 8 bytes
b __inval_cache_range // tail call
ENDPROC(preserve_boot_args)

arm64 linux 寄存器规定如下:

x0 = physical address of device tree blob (dtb) in system RAM.
x1 = 0 (reserved for future use)
x2 = 0 (reserved for future use)
x3 = 0 (reserved for future use)

将 dtb 的物理地址保存在 x21 寄存器中。 __inval_cache_range 这个函数用来 invalidate 指定区域的 cache。如果指定内存区域有跨越 cacheline, 那么对两边跨越了 cacheline 的地址使用的 clean + invalidate, 对于中间区域可以直接 invalidate 不用写回内存,从而加快 invalidate 速度。

调用__primary_switch 如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
__primary_switch:

bl __enable_mmu
#ifdef CONFIG_RELOCATABLE
bl __relocate_kernel
#ifdef CONFIG_RANDOMIZE_BASE
ldr x8, =__primary_switched
adrp x0, __PHYS_OFFSET
blr x8
...
bl __relocate_kernel
#endif
ldr x8, =__primary_switched
adrp x0, __PHYS_OFFSET
br x8
ENDPROC(__primary_switch)

调用__primary_switched 函数:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
__primary_switched:
adrp x4, init_thread_union
add sp, x4, #THREAD_SIZE
msr sp_el0, x4 // Save thread_info

adr_l x8, vectors // load VBAR_EL1 with virtual
msr vbar_el1, x8 // vector table address
isb

stp xzr, x30, [sp, #-16]!
mov x29, sp

str_l x21, __fdt_pointer, x5 // Save FDT pointer
...
b start_kernel
ENDPROC(__primary_switched)

通过 str_l x21, __fdt_pointer, x5 这句将 dtb 的地址保存在__fdt_pointer 指针里,以便后续内核可以找到 dtb 并解析设备树文件。

关于 linux 启动过程可以参考下图:原图

dtb 解析过程

start_kernel 阶段会处理 dtb 文件生成 device_node 结构体以及他们之间的组织关系。整体的调用逻辑如下:原图

下面以一个简单的设备树为例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
/ {
leds {
act {
gpios = <&gpio 42 GPIO_ACTIVE_HIGH>;
};

pwr {
label = "PWR";
gpios = <&expgpio 2 GPIO_ACTIVE_LOW>;
default-state = "keep";
linux,default-trigger = "default-on";
};
};

wifi_pwrseq: wifi-pwrseq {
compatible = "mmc-pwrseq-simple";
reset-gpios = <&expgpio 1 GPIO_ACTIVE_LOW>;
};

};

该设备树经过 populate_node() 解析处理后,结构体关系如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
- /节点:
- parent:NULL
- sibling:NULL
- child:wifi_pwrseq
- led 节点:
- parent:/
- sibling:NULL
- child:pwr
- act 节点:
- parent:led
- sibling:NULL
- child:NULL
- pwr 节点:
- parent:led
- sibling:act
- child:NULL
- wifi_pwrseq 节点:
- parent:/
- sibling:led
- child:NULL

device_node 与 device 绑定

kernel 会为设备树 root 节点下所有带'compatible' 属性的节点都分配并注册一个 platform_device;另外,如果某节点的'compatible' 符合某些 matches 条件,则会为该节点下所有带'compatible' 属性的子节点(child)也分配并注册一个 platform_device。 整体调用流程如下图所示:原图

至此,为所有设备树中所有符合条件的 node 都创建了 platform_device 结构体,node 下描述的资源也解析到了 platform_device 中,并通过 dev 成员将该 node 描述的设备加入了统一设备模型。

 补充:标签是标记节点的方法,可以用唯一的名称来标识节点,在 dt 编译器编译过程中,dt 编译器将该名称转换为唯一的 32 位值,之后可以使用标签引用节点,因为标签对于节点是唯一的。phandle 是与节点相关联的 32 位值,用于唯一标识该节点,以便可以从另一个节点属性引用该节点。为了在查找节点时不遍历整个树,引入别名的概念,在 dt 中,别名可以看作是节点的快速查找表,即一个节点的索引

参考文献

https://zhuanlan.zhihu.com/p/141623370
https://zhuanlan.zhihu.com/p/143092868
http://gngshn.github.io/
http://www.wowotech.net/sort/device_model
《Linux 设备驱动开发》