(1)设备树dts文件格式讲解参考博客:《linux设备树dts文件详解》;
(2)本文对设备树的讲解是基于hi3516dv300芯片的uboot和kernel源码进行详解,uboot版本是2016.11,内核版本是4.9.37;
(3)在dv300芯片用的uboot和内核中,uboot启动内核传参是传统tag方式,内核是采用的设备树技术,镜像构成是zImage+dtb;
int do_bootm_linux(int flag, int argc, char * const argv[],
bootm_headers_t *images)
{
/* No need for those on ARM */
if (flag & BOOTM_STATE_OS_BD_T || flag & BOOTM_STATE_OS_CMDLINE)
return -1;
if (flag & BOOTM_STATE_OS_PREP) {
boot_prep_linux(images);
return 0;
}
if (flag & (BOOTM_STATE_OS_GO | BOOTM_STATE_OS_FAKE_GO)) {
boot_jump_linux(images, flag);
return 0;
}
//处理tag或者fdt
boot_prep_linux(images);
//跳转执行内核
boot_jump_linux(images, flag);
return 0;
}
(1)do_bootm_linux()函数是uboot启动内核的最终阶段。到此函数为止,已经将内核重定位到内存,并且解析出内核镜像的头信息;
(2)do_bootm_linux()函数主要功能就是找到machId和内核启动参数,然后调用内核入口把机器码和tag/dtb地址传给内核;
(3)在dv300芯片采用的uboot中,uboot传的是tag;
static void boot_jump_linux(bootm_headers_t *images, int flag)
{
//通过全局变量gd获取的机器码,这是通过配置文件指定的
unsigned long machid = gd->bd->bi_arch_number;
char *s;
//启动内核的函数指针类型
void (*kernel_entry)(int zero, int arch, uint params);
unsigned long r2;
int fake = (flag & BOOTM_STATE_OS_FAKE_GO);
//得到内核的入口地址
kernel_entry = (void (*)(int, int, uint))images->ep;
//判断环境变量里是否有指定machid,环境变量的优先级高于代码指定machid的优先级
s = getenv("machid");
if (s) {
if (strict_strtoul(s, 16, &machid) < 0) {
debug("strict_strtoul failed!\n");
return;
}
printf("Using machid 0x%lx from environment\n", machid);
}
debug("## Transferring control to Linux (at address %08lx)" \
"...\n", (ulong) kernel_entry);
bootstage_mark(BOOTSTAGE_ID_RUN_OS);
announce_and_cleanup(fake);
//判断当前uboot给内核传参是采用设备树还是传统的tag
if (IMAGE_ENABLE_OF_LIBFDT && images->ft_len)
r2 = (unsigned long)images->ft_addr; //采用设备树,r2寄存器的值是dtb的地址
else
r2 = gd->bd->bi_boot_params; //传统tag,r2寄存器的值是tag的地址
if (!fake) {
#ifdef CONFIG_ARMV7_NONSEC
if (armv7_boot_nonsec()) {
armv7_init_nonsec();
secure_ram_addr(_do_nonsec_entry)(kernel_entry,
0, machid, r2);
} else
#endif
//启动内核:(0,机器码,dtb/tag)
kernel_entry(0, machid, r2);
}
}
(1)boot_jump_linux()函数是uboot启动内核的最后一个函数,主要功能就是根据内核镜像头找到内核入口地址,然后启动内核;
(2)重点:uboot启动内核的时,r0寄存器的值是0,r1寄存器的值是机器码,r2寄存器的值是tag的启动地址或者是dtb;(在dv300芯片的uboot采用的tag传参)
start:
//定义了一些变量,这些符号都可以在链接脚本找到
.word _magic_sig @ Magic numbers to help the loader
.word _magic_start @ absolute load/run zImage address
.word _magic_end @ zImage end address
.word 0x04030201 @ endianness flag
#ifdef CONFIG_ARM_APPENDED_DTB
/* 对到此阶段各个寄存器里保存值的含义做了说明
* r0 = delta
* r2 = BSS start
* r3 = BSS end
* r4 = final kernel address (possibly with LSB set)
* r5 = appended dtb size (still unknown)
* r6 = _edata zImage结束地址,也就是dtb的起始地址
* r7 = architecture ID
* r8 = atags/device tree pointer
* r9 = size of decompressed image
* r10 = end of this image, including bss/stack/malloc space if non XIP
* r11 = GOT start
* r12 = GOT end
* sp = stack pointer
*
* if there are device trees (dtb) appended to zImage, advance r10 so that the
* dtb data will get relocated along with the kernel if necessary.
*/
ldr lr, [r6, #0] //读取dtb的最开始的4个字节,里面是dtb格式的特殊头(是一个魔数)
//区分内核当前是大端模式还是小端模式
#ifndef __ARMEB__
ldr r1, =0xedfe0dd0 @ sig is 0xd00dfeed big endian
#else
ldr r1, =0xd00dfeed
#endif
cmp lr, r1 //比较dtb的头4个字节是否是对应的魔术,如果不是则代表不是dtb格式文件
bne dtb_check_done @ not found
#ifdef CONFIG_ARM_ATAG_DTB_COMPAT
/*
* OK... Let's do some funky business here.
* If we do have a DTB appended to zImage, and we do have
* an ATAG list around, we want the later to be translated
* and folded into the former here. No GOT fixup has occurred
* yet, but none of the code we're about to call uses any
* global variable.
*/
/* Get the initial DTB size */
ldr r5, [r6, #4] //读取dtb的第四到第八字节到r5寄存器,这4个字节标明dtb的大小
stmfd sp!, {r0-r3, ip, lr}
mov r0, r8 //tag地址
mov r1, r6 //_edata,内核镜像的结束地址,也是dtb的开始地址
mov r2, r5 //appended dtb size,dtb的大小
bl atags_to_fdt //解析uboot传过来的tag并生成相应的dtb节点
······
ldmfd sp!, {r0-r3, ip, lr}
sub sp, sp, r5
#endif
mov r8, r6 @ use the appended device tree
/* Get the current DTB size */
ldr r5, [r6, #4]
dtb_check_done:
#endif
/*
* The C runtime environment should now be setup sufficiently.
* Set up some pointers, and start decompressing.
* r4 = kernel execution address
* r7 = architecture ID
* r8 = atags pointer
*/
mov r0, r4 //内核解压后存放的地址
mov r1, sp @ malloc space above stack
add r2, sp, #0x10000 @ 64k max
mov r3, r7 //architecture ID:机器码
bl decompress_kernel //执行解压zImage为elf格式的可执行kernel镜像
bl cache_clean_flush
bl cache_off
mov r1, r7 @ restore architecture number
mov r2, r8 @ restore atags pointer
b __enter_kernel //调用解压后的内核
__enter_kernel:
mov r0, #0 @ must be 0
ARM( mov pc, r4 ) @ call kernel 解压内核时已经把解压地址保存到r4寄存器中
M_CLASS( add r4, r4, #1 ) @ enter in Thumb mode for M class
THUMB( bx r4 ) @ entry point is always ARM for A/R classes
(1)这个宏标明dtb是接续在zImage镜像后面的,整个内核烧录镜像构成如上图;
(2)zImage就是平时的zImage镜像,不同之处就是zImage镜像后面接续了二进制dtb数据;
(3)在arch/arm/boot/目录下会产生两个镜像,分别是zImage和zImage-dtb,用比对软件可以分析得到zImage-dtb就是比zImage尾部多了dtb数据;
(1)前面说过,dv300芯片的uboot采用的传统的tag传参方式并没有用设备树技术,但是内核是用的设备树,dtb镜像是接续在zImage镜像后面的;
(2)内核启动需要的信息都来自dtb文件,包括启动参数、内存信息、设备信息等,但是dts文件没有配置启动参数、内存信息等,在启动节点需要先将uboot的tag传参里内核启动信息、内存信息等,从tag格式转换成dtb格式;
(3)tag结构体转换成dtb格式,具体工作在函数atags_to_fdt()里进行;
stmfd sp!, {r0-r3, ip, lr} //将r0-r3、ip、lr寄存器保存到栈中
mov r0, r8 //tag地址
mov r1, r6 //_edata,内核镜像的结束地址,也是dtb的开始地址
mov r2, r5 //appended dtb size,dtb的大小
bl atags_to_fdt //解析uboot传过来的tag并生成相应的dtb节点
int atags_to_fdt(void *atag_list, void *fdt, int total_space);
传参 | 含义 |
---|---|
atag_list | uboot传递的tag参数链表的地址 |
fdt | dtb数据所在地址 |
total_space | dtb数据的总大小 |
(1)atags_to_fdt()函数是被汇编语句调用,其中汇编调用C语言函数传参是通过寄存器,将需要传递的参数保存到寄存器中,其中传递的三个参数分别保存到r0、r1、r2寄存器;
(2)因为r0、r1、r2寄存器会被调用C语言函数时占用,所以提前将寄存器的值备份到栈中,后面从栈里回复寄存器的值;
(1)首先判断tag参数链表地址处是否已经是dtb数据,tag参数地址就是uboot启动内核时传递的r2寄存器的值,可能是tag参数也可能是dtb数据,这里判断头4个字节是不是dtb格式文件的魔数(FDT_MAGIC)即可;
(2)判断tag是不是合法的,也就是tag链表第一个tag是不是ATAG_CORE类型;
(3)调用fdt_open_into()函数打开dtb格式的数据,dtb格式本质是二进制数据,具体是何种格式没去研究过,但是内核已经提供了相关函数,我们只需要按照函数传参要求调用即可;
(4)遍历tag参数,如果是有必要的tag参数就解析并合入到dtb数据中,比较典型的就是解析bootargs成chosen节点的属性;
(5)tag转换成dtb也是调用内核提供的函数,setprop_xxx()函数族,里面有很多setprop开头的函数,专门用于tag转dtb,根据不同类型的tag调用不同的函数;
(6)最终效果就是原始的dtb数据中,对应的节点、属性会被tag参数中的值替换掉,具体如何替换并不用关心,能看懂内核提供的setprop_xxx()函数族传参即可;
(1)zImage是压缩的镜像,这里讲解的是未压缩的头部分如何解压缩内核镜像,以及对dtb的前期处理;
(2)涉及源文件目录:arch/arm/boot/compressed/;
参考博客:《内核的解压缩过程详解》;
(1)链接脚本:arch/arm/kernel/vmlinux.lds;
(2)主要汇编文件:arch/arm/kernel/head.S;
(3)汇编程序的入口:ENTRY(stext),分析链接脚本可以知道;
__INIT
__mmap_switched:
adr r3, __mmap_switched_data
//将r4*-r7寄存器的值保存到__data_loc到_end变量中
ldmia r3!, {r4, r5, r6, r7}
cmp r4, r5 @ Copy data segment if needed
1: cmpne r5, r6
ldrne fp, [r4], #4
strne fp, [r5], #4
bne 1b
mov fp, #0 @ Clear BSS (and zero fp)
1: cmp r6, r7
strcc fp, [r6],#4
bcc 1b
//将r4*-r7寄存器的值保存到processor_id到init_thread_union变量中
//下面ARM态和THUMB态语句的效果是一样的
ARM( ldmia r3, {r4, r5, r6, r7, sp}) //如果CPU处于ARM态就执行该语句
THUMB( ldmia r3, {r4, r5, r6, r7} ) //如果CPU处于THUMB态就执行该语句
THUMB( ldr sp, [r3, #16] )
str r9, [r4] @ Save processor ID
str r1, [r5] @ Save machine type
str r2, [r6] @ Save atags pointer
cmp r7, #0
strne r0, [r7] @ Save control register values
b start_kernel //跳转执行start_kernel函数,开始C语言阶段
ENDPROC(__mmap_switched)
.align 2
.type __mmap_switched_data, %object
__mmap_switched_data:
.long __data_loc @ r4
.long _sdata @ r5
.long __bss_start @ r6
.long _end @ r7
.long processor_id @ r4:该变量的值来自于r4寄存器,是CPU的ID
.long __machine_arch_type @ r5:该变量的值来自于r4寄存器,是机器码
.long __atags_pointer @ r6:该变量的值来自于r6寄存器,是tag或者dtb的地址
#ifdef CONFIG_CPU_CP15
.long cr_alignment @ r7
#else
.long 0 @ r7
#endif
.long init_thread_union + THREAD_START_SP @ sp
.size __mmap_switched_data, . - __mmap_switched_data
(1)在汇编阶段对dtb没有做特别的处理,就检验了dtb的合法性,这里分析一些重要的全局变量,全局变量在汇编阶段定义并赋值,后面C语言阶段会使用到;
(2)__mmap_switched_data标号就相当于汇编定义了一个数组,成员变量包含__data_loc到init_thread_union;
(3)在上面的汇编代码中,在解析过程中将寄存器的值写到对应全局变量中;
(4)上面和设备树关系较紧密的是__atags_pointer变量,其实在这里已经是dtb数据的地址,因为在前面已经将uboot传递的tag转换成了dtb数据;
start_kernel
setup_arch
setup_machine_fdt //解析dtb数据,得到匹配的struct machine_desc结构体,这是用来描述板级配置的
early_init_dt_verify //校验dtb数据
of_flat_dt_match_machine //匹配最符合的struct machine_desc结构体
get_next_compat(arch_get_next_mach) //读取编译进内核的struct machine_desc结构体的dt_compat属性
of_flat_dt_match //将struct machine_desc结构体的dt_compat属性和根节点的"compatible"属性进行匹配,匹配度越好返回的分数越小
early_init_dt_scan_nodes //从dtb数据中解析出一些关键的信息来引导内核启动
of_scan_flat_dt //遍历dtb的所有节点,并调用回调函数it解析节点
unflatten_device_tree //将dtb数据节点解析成struct device_node结构体,根节点保存到of_root变量
//将dtb数据解析成struct device_node结构体数据
of_platform_default_populate_init //将struct device_node结构体转换成总线上的device,比如转换成struct amba_device(amba总线)、struct platform_device(platform总线)
of_have_populated_dt //判断节点是否已经被转换
of_platform_default_populate //
of_platform_populate //将该节点以及子节点都转换成总线上的device
for_each_child_of_node //遍历节点的每一个子节点
of_platform_bus_create //为节点创建对应的总线设备
of_get_property //判断节点是否有"compatible"属性,因为是根据这个属性来判断是创建哪种总线的device
of_device_is_compatible //"compatible"属性是否匹配上amba总线
of_amba_device_create //匹配上则创建amab总线的device,实例化一个struct amba_device结构体并注册到amba总线
of_platform_device_create_pdata //如果匹配不是amba总线,则创建platform总线的设备
of_device_alloc //读取device_node节点信息,实例化一个platform_device结构体
of_device_add //将platform_device结构体注册到platform总线
for_each_child_of_node //遍历节点的子节点
of_platform_bus_create //对每个子节点都创建对应总线device,这里是递归调用
参考博客:《设备树(dtb数据)匹配struct machine_desc结构体》;
参考博客:《从设备树(dtb格式数据)中解析出bootargs》;
参考博客:《设备树——dtb格式到struct device node结构体的转换》;
参考博客:《device node结构体转换成platform_device结构体》;
~ # ls /proc/device-tree/
#address-cells interrupt-controller@10300000
#size-cells media
aliases memory
chosen model
clock@12010000 name
compatible soc
cpus syscounter
~ #
~ # cat /proc/device-tree/model
Hisilicon HI3516DV300 DEMO Board
~ #
~ # cat /proc/device-tree/compatible
hisilicon,hi3516dv300
~ #
~ # ls /proc/device-tree/chosen/
bootargs name
~ #
~ # cat /proc/device-tree/chosen/bootargs
mem=512M console=ttyAMA0,115200 root=/dev/mmcblk0p3 rootfstype=ext4 rw rootwait blkdevparts=mmcblk0:5M(boot),10M(kernel),200M(rootfs),200M(userdata),-(user)
~ #
~ # cat /proc/device-tree/chosen/name
chosen
~ #
命令 | 作用 |
---|---|
ls /proc/device-tree/ | 查看设备树的所有节点 |
cat /proc/device-tree/model | 查看根节点的model属性 |
cat /proc/device-tree/compatible | 查看根节点的compatible属性 |
ls /proc/device-tree/chosen/ | 查看chosen节点下的所有属性 |
cat /proc/device-tree/chosen/bootargs | 查看chosen节点的bootargs属性 |
cat /proc/device-tree/chosen/name | 查看chosen节点的名字 |