hi3519av100改用传参设备树方式启动

`linux`内核启动需求的`Setup boot data`时可以通过两种方式:

1. Setup the kernel tagged list
2. Setup the device tree

linux-4.9.37/Documentation/arm/Booting

hi3519av100设备原有的启动内核的方式是第一种ATAGS的方式，由于目前hi3519av100和hi3559av100的u-boot和kernel源码都是共用的，且设备树比较方便兼容不同的板子，所有打算将hi3519av100用第二种设备树的方式来启动内核。

问:

• 设备树是什么?
• 设备树如何获得? 存放在哪里?
• u-boot如何获得设备树?
• 如何将设备树传递给内核并启动?

## 设备树介绍

可以参考 蜗窝科技 的相关博文：（非广告，没收钱）

Device Tree（一）：背景介绍

Device Tree（二）：基本概念

Device Tree（三）：代码分析

Device Tree（四）：文件结构解析

使用简单的测试设备树进行分析

涉及文件：

• 源设备树文件test.dts
• 编译出来的二进制文件test.dtb
• 反编译出来的设备树文件test-re.dts
• fdtdump打印出来的test.dump

涉及命令：

• dtc : 进行设备树的编译与反编译
• fdtdump : 打印解析过程
• hexdump : 打印二进制数据

编译与反编译

test.dts:

/dts-v1/;

/ {
	node@0 {
		a-string-property = "A sttring";
		a-string-list-property = "first string", "second string";
		a-byte-data-property = [01 23 45 67 89 AB];
		
		child-node@0 {
			first-child-property;
			second-child-property = <1>;
			a-reference-to-something = <&node1>;
		};
	};
	node1: node@1 {
		an-empty-property;
		a-string-property = "A new sttring";
		a-cell-property = <1 2 3 4>;
		a-reference-to-something = <&node2>;
		child-node@0 {
		};
	};
	
	node2: node@2 {
	};
};

编译成test.dtb：

dtc -I dts -O dtb -o test.dtb test.dts

反汇编test.dtb为test-re.dts文件：

dtc -I dtb -O dts -o test-re.dts test.dtb

test-re.dts文件内容：

/dts-v1/;

/ {

	node@0 {
		a-string-property = "A sttring";
		a-string-list-property = "first string", "second string";
		a-byte-data-property = [01 23 45 67 89 ab];

		child-node@0 {
			first-child-property;
			second-child-property = <0x1>;
			a-reference-to-something = <0x1>;
		};
	};

	node@1 {
		an-empty-property;
		a-string-property = "A new sttring";
		a-cell-property = <0x1 0x2 0x3 0x4>;
		a-reference-to-something = <0x2>;
		linux,phandle = <0x1>;
		phandle = <0x1>;

		child-node@0 {
		};
	};

	node@2 {
		linux,phandle = <0x2>;
		phandle = <0x2>;
	};
};

可以看到上面源dts文件与反编译出来的dts文件还是存在差异的：

同时发现当使用[]括号对4个binary data数据进行属性赋值时，反编译出来是一个u32类型的值，使用其他值的时候还是会反编译成[]的binary data。（看文章后面的图）

使用fdtdump打印test.dtb：

fdtdump -ds test.dtb > test.dump

可以参照上面的test.dump与编译出来的test.dtb文件进行对比：

fdt_header头的结构体如下所示：

struct fdt_header {
    
	fdt32_t magic;			 /* magic word FDT_MAGIC */
	fdt32_t totalsize;		 /* total size of DT block */
	fdt32_t off_dt_struct;		 /* offset to structure */
	fdt32_t off_dt_strings;		 /* offset to strings */
	fdt32_t off_mem_rsvmap;		 /* offset to memory reserve map */
	fdt32_t version;		 /* format version */
	fdt32_t last_comp_version;	 /* last compatible version */

	/* version 2 fields below */
	fdt32_t boot_cpuid_phys;	 /* Which physical CPU id we're
					    booting on */
	/* version 3 fields below */
	fdt32_t size_dt_strings;	 /* size of the strings block */

	/* version 17 fields below */
	fdt32_t size_dt_struct;		 /* size of the structure block */
};

struct fdt_reserve_entry {
    
	fdt64_t address;
	fdt64_t size;
};

struct fdt_node_header {
    
	fdt32_t tag;
	char name[];
};

struct fdt_property {
    
	fdt32_t tag;
	fdt32_t len;
	fdt32_t nameoff;
	char data[];
};

#define FDT_MAGIC	0xd00dfeed	/* 4: version, 4: total size */
#define FDT_TAGSIZE	sizeof(fdt32_t)

#define FDT_BEGIN_NODE	0x1		/* Start node: full name */
#define FDT_END_NODE	0x2		/* End node */
#define FDT_PROP	0x3		/* Property: name off,
					   size, content */
#define FDT_NOP		0x4		/* nop */
#define FDT_END		0x9

#define FDT_V1_SIZE	(7*sizeof(fdt32_t))
#define FDT_V2_SIZE	(FDT_V1_SIZE + sizeof(fdt32_t))
#define FDT_V3_SIZE	(FDT_V2_SIZE + sizeof(fdt32_t))
#define FDT_V16_SIZE	FDT_V3_SIZE
#define FDT_V17_SIZE	(FDT_V16_SIZE + sizeof(fdt32_t))

二进制文件中以FDT_BEGIN_NODE (0x1)表示一个节点的开始，FDT_END_NODE (0x2)表示一个节点的结束，节点以struct fdt_node_header描述；以FDT_PROP (0x3)表示一个节点下的属性，属性以结构体struct fdt_property描述。

fdtdump出来的内容：

/dts-v1/;
// magic:		0xd00dfeed
// totalsize:		0x26e (622)
// off_dt_struct:	0x38
// off_dt_strings:	0x1bc
// off_mem_rsvmap:	0x28
// version:		17
// last_comp_version:	16
// boot_cpuid_phys:	0x0
// size_dt_strings:	0xb2
// size_dt_struct:	0x184

与编译出来的dtb进行对比：

off_dt_struct表明设备树的结构在dtb中的偏移位置，这里是从0x38开始，大小是size_dt_struct，即0x184字节。off_dt_strings是属性名字字符串表在dtb中开始的位置，大小是size_dt_strings，这里是0xb2字节。

那么从0x38开始，就是根节点/开始的位置。

根节点/：以FDT_BEGIN_NODE (0x1)开始，后面接u32的0x0值。

从fdtdump出来的文件可以看到：

// 0038: tag: 0x00000001 (FDT_BEGIN_NODE)
/ {

/node@0节点：以FDT_BEGIN_NODE (0x1)开始，后面接node@0的ASCII码，并补全至4字节对齐。

// 0040: tag: 0x00000001 (FDT_BEGIN_NODE)
    node@0 {

/node@0的a-string-property属性：以FDT_PROP (0x3)开始，属性值长度为0x9，属性名字偏移为0x0，接下来是属性的值"A string"（长度为8）。（长度会是字符串长度+1，即加0x00的字符串结束符。并且以4字节向上对齐。）（属性的名字存在size_dt_strings里面，根据off_dt_strings的地址0x1bc加上偏移0x0，就可以得到属性名字"a-string-property"。后面就不再赘述。）

// 004c: tag: 0x00000003 (FDT_PROP)
// 01bc: string: a-string-property
// 0058: value
        a-string-property = "A string";

/node@0的a-string-list-property属性：属性值长度为0x1B，属性名字偏移为0x12，接下来是属性的值"first string second string"（长度为0x1A）。（dtc编译与反编译过程中是如何区分是普通字符串还是字符串列表的？）

// 0064: tag: 0x00000003 (FDT_PROP)
// 01ce: string: a-string-list-property
// 0070: value
        a-string-list-property = "first string", "second string";

/node@0的a-byte-data-property属性：属性值长度为0x6，属性名字偏移为0x29，接下来是属性的值：[01 23 45 67 89 AB]，然后4字节向上对齐。

// 008c: tag: 0x00000003 (FDT_PROP)
// 01e5: string: a-byte-data-property
// 0098: value
        a-byte-data-property = [01 23 45 67 ffffff89 ffffffab];

实际dts文件：

a-byte-data-property = [01 23 45 67 89 AB];

反编译出来的dts文件：

a-byte-data-property = [01 23 45 67 89 ab];

/node@0/child-node@0下的first-child-property属性：属性值长度为0x0，属性名字偏移为0x3E，即"first-child-property"。

// 00b4: tag: 0x00000003 (FDT_PROP)
// 01fa: string: first-child-property
// 00c0: value
            first-child-property;

// 00c0: tag: 0x00000003 (FDT_PROP)
// 020f: string: second-child-property
// 00cc: value
            second-child-property = <0x00000001>;

// 00d0: tag: 0x00000003 (FDT_PROP)
// 0225: string: a-reference-to-something
// 00dc: value
            a-reference-to-something = <0x00000001>;

实际dts文件：

a-reference-to-something = <&node1>;

反编译出来的dts文件：

linux,phandle = <0x1>;
phandle = <0x1>;

这个属性的名字跟/node@0里面的属性的名字相同，所有属性名字的偏移通用指向了0x41：（达到了属性名的服用，节省部分空间。）

fdtdump出来的有错误：

// 011c: tag: 0x00000003 (FDT_PROP)
// 0250: string: a-cell-property
// 0128: value
        a-cell-property = <0x00000001 0x00000003 0x00000003 0x00000003>;

实际dts文件：

a-cell-property = <1 2 3 4>;

反编译出来的dts文件：

a-cell-property = <0x1 0x2 0x3 0x4>;

// 0138: tag: 0x00000003 (FDT_PROP)
// 0225: string: a-reference-to-something
// 0144: value
        a-reference-to-something = <0x00000002>;

实际dts文件：

a-reference-to-something = <&node2>;

反编译出来的dts文件：

a-reference-to-something = <0x2>;

被引用的节点会生成linux,phandle和phandle，并赋予不同的值：

linux,phandle = <0x1>;
phandle = <0x1>;

linux,phandle = <0x2>;
phandle = <0x2>;

从上面的分析可以知道，整个dtb文件的结构大概如下所示：

## 设备树存放位置

查看hi3519av100的内核编译过程，可以看到dtb文件实际通过cat命令是打到了zImage的后面形成zImage-dtb：

u-boot获取设备树内容

虽然说dtb放在zImage的后面，zImage-dtb镜像最后生成uImage，但uImage的头实际是记录的ih_size是zImage-dtb的大小，而不是zImage的大小，所有要怎么从uImage里面获得dtb的内容呢？

typedef struct image_header {
    
	__be32		ih_magic;	/* Image Header Magic Number	*/
	__be32		ih_hcrc;	/* Image Header CRC Checksum	*/
	__be32		ih_time;	/* Image Creation Timestamp	*/
	__be32		ih_size;	/* Image Data Size		*/
	__be32		ih_load;	/* Data	 Load  Address		*/
	__be32		ih_ep;		/* Entry Point Address		*/
	__be32		ih_dcrc;	/* Image Data CRC Checksum	*/
	uint8_t		ih_os;		/* Operating System		*/
	uint8_t		ih_arch;	/* CPU architecture		*/
	uint8_t		ih_type;	/* Image Type			*/
	uint8_t		ih_comp;	/* Compression Type		*/
	uint8_t		ih_name[IH_NMLEN];	/* Image Name		*/
} image_header_t;

从uImage的生成过程来看，其实中间那个zImage是很重要的，查询相关资料发现，zImage也有一个自己的头，在u-boot下的arch/arm/lib/zimage.c里：

#define	LINUX_ARM_ZIMAGE_MAGIC	0x016f2818

struct arm_z_header {
    
	uint32_t	code[9];
	uint32_t	zi_magic;
	uint32_t	zi_start;
	uint32_t	zi_end;
} __attribute__ ((__packed__));

查看一下生成过程的zImage镜像：

既然知道了这个arm_z_header，并且头里面记录了zi_start和zi_end，对于zImage，那么zi_end - zi_start自然就是zImage的大小了。

再看一下内核的arch/arm/boot/compressed/head.S里面有一个奇怪的标记0x04030201：

start:
		.type	start,#function
		.rept	7
		__nop
		.endr
   ARM(		mov	r0, r0		)
   ARM(		b	1f		)
 THUMB(		badr	r12, 1f		)
 THUMB(		bx	r12		)

		.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

再对比一下uImage的前面部分：

首先，u-boot在启动内核时会将生成uImage时mkimage加的64字节头去掉，去掉了之后就剩下普通的zImage-dtb了。紧接着是zImage的头，共48字节，接下来是生成zImaeg时上面那个奇怪的标记endianness flag，和代码也有对应，镜像位置也对应。基本上就可以获取到在uImage里面的dtb文件了。

去掉了uImage的64字节头后，启动内核的起始内核位置实际是zImage在内存中的起始位置，假设为addr，使用地址addr+0x2C获得zi_end，addr+0x28获得zi_start，由于zi_start都是0，那么zi_end就是zImage的长度了。addr+0x30加就是endianness flag的标记位了。

且知道dtb就在zImage后面，那么使用偏移addr+zi_start就可以获得dtb的头了。

#define FDT_SIZE_OFFSET 	(0x1)		// 0x4
#define IMAGE_FDT_OFFSET 	(0xb)		// 0x2C
#define IMAGE_FLAG_OFFSET 	(0xc)		// 0x30
#define IMAGE_FLAG 			(0x04030201)

当使用4字节长度的指针时，IMAGE_FLAG_OFFSET偏移是endianness flag标记，然后IMAGE_FDT_OFFSET偏移是zi_end（当zi_start是0时表示zImage长度，也就是dtb开始的位置了。）

if (head[IMAGE_FLAG_OFFSET] != IMAGE_FLAG)
...
fdt_head = (ulong *)(image_start+head[IMAGE_FDT_OFFSET]);

好，齐活了。

u-boot传递设备树内容

获取到设备树后，u-boot会在boot_jump_linux函数中将r2寄存器设置为设备树的地址（relocate之后的地址）， 这里就将设备树传递给内核了。内核在setup_arch->setup_machine_fdt的过程中解析设备树的内容，完成启动过程。
x2C
#define IMAGE_FLAG_OFFSET (0xc) // 0x30
#define IMAGE_FLAG (0x04030201)

当使用`4`字节长度的指针时，`IMAGE_FLAG_OFFSET`偏移是`endianness flag`标记，然后`IMAGE_FDT_OFFSET`偏移是`zi_end`（当`zi_start`是`0`时表示`zImage`长度，也就是`dtb`开始的位置了。）

```c
if (head[IMAGE_FLAG_OFFSET] != IMAGE_FLAG)
...
fdt_head = (ulong *)(image_start+head[IMAGE_FDT_OFFSET]);

好，齐活了。

u-boot传递设备树内容

获取到设备树后，u-boot会在boot_jump_linux函数中将r2寄存器设置为设备树的地址（relocate之后的地址）， 这里就将设备树传递给内核了。内核在setup_arch->setup_machine_fdt的过程中解析设备树的内容，完成启动过程。