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

hi3519av100改用传参设备树方式启动 来自远方 2024-01-10 14:28:54 722

文章目录

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

Setup the kernel tagged list

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.dtbtest-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)开始,后面接u320x0值。

fdtdump出来的文件可以看到:

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

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

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

/node@0a-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@0a-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@0a-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,phandlephandle,并赋予不同的值:

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_sizezImage-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_startzi_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在启动内核时会将生成uImagemkimage加的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的过程中解析设备树的内容,完成启动过程。

声明:本文内容由易百纳平台入驻作者撰写,文章观点仅代表作者本人,不代表易百纳立场。如有内容侵权或者其他问题,请联系本站进行删除。
红包 点赞 收藏 评论 打赏
评论
0个
内容存在敏感词
手气红包
    易百纳技术社区暂无数据
相关专栏
置顶时间设置
结束时间
删除原因
  • 广告/SPAM
  • 恶意灌水
  • 违规内容
  • 文不对题
  • 重复发帖
打赏作者
易百纳技术社区
来自远方
您的支持将鼓励我继续创作!
打赏金额:
¥1易百纳技术社区
¥5易百纳技术社区
¥10易百纳技术社区
¥50易百纳技术社区
¥100易百纳技术社区
支付方式:
微信支付
支付宝支付
易百纳技术社区微信支付
易百纳技术社区
打赏成功!

感谢您的打赏,如若您也想被打赏,可前往 发表专栏 哦~

举报反馈

举报类型

  • 内容涉黄/赌/毒
  • 内容侵权/抄袭
  • 政治相关
  • 涉嫌广告
  • 侮辱谩骂
  • 其他

详细说明

审核成功

发布时间设置
发布时间:
是否关联周任务-专栏模块

审核失败

失败原因
备注
拼手气红包 红包规则
祝福语
恭喜发财,大吉大利!
红包金额
红包最小金额不能低于5元
红包数量
红包数量范围10~50个
余额支付
当前余额:
可前往问答、专栏板块获取收益 去获取
取 消 确 定

小包子的红包

恭喜发财,大吉大利

已领取20/40,共1.6元 红包规则

    易百纳技术社区