【转载】Linux 内核对设备树的处理

[Linux 基础] -- 第三课：Linux 内核对设备树的处理

原文地址：https://blog.csdn.net/u014674293/article/details/114833254

 

前言：

本文转自韦东山老师关于设备树的讲解，原文地址：第三课:linux内核对设备树的处理。

一、从源头分析 -- 内核 head.S 对 dtb 的简单处理

现在我们开始第一节，我们要从源头分析，uboot 将一些参数，设备树文件传递给内核，那么内核如何处理这些设备树文件呢？我们需要从内核的一个执行文件 head.S 开始分析。

1.1、r0，r1，r2 三个寄存器的设置

BootLoader 启动内核时，会设置 r0，r1，r2 三个寄存器：

• r0 一般设置为 0；
• r1 一般设置为 machine id（在使用设备树时该参数没有被使用）；
• r2 一般设置为 ATAGS 或 DTB 的开始地址；

这里的 machine id，是让内核知道是哪个 CPU，从而调用对应的初始化函数。以前没有使用设备树时，需要 BootLoader 传一个 machine id 给内核，现在使用设备树的话，这个参数就不需要设置了。

r2 要么是以前的 ATAGS 开始地址，要么是现在使用设备树后的 DTB 文件开始地址。

1.2、head.S 的内容

内核 head.S 所做工作如下：

1. __lookup_processor_type：使用汇编指令读取 CPU ID，根据该 ID 找到对应的 proc_info_list 结构体（里面含有这类 CPU 的初始化函数、信息）；
2. __vet_atags：判断是否存在可用的 ATAGS 或 DTB；
3. __create_pag_tables：创建页表，即创建虚拟地址和物理地址的映射关系；
4. __enable_mmu：使能 MMU，以后就要使用虚拟地址了；
5. __mmap_switched：上述函数里将会调用 __mmap_swtiched；
6. 把 BootLoader 传入的 r2 参数，保存到变量 __atags_pointer 中；
7. 调用 C 函数 start_kernel；

最终效果：

head.S 和 head-common.S 最终效果：

• 把 BootLoader 传来的 r1 值，赋给了 C 变量：__machine_arch_type；

• 把 BootLoader 传来的 r2 值，

Uboot 先把设备树文件读到内存，在启动内核时把设备树的地址写到r2寄存器中。

二、对设备树中平台信息的处理（选择 machine_desc）

这节讲解内核对设备树中平台设备信息是如何处理的。

2.1、内核是如何选择对应的 machine_desc ？

前面讲解到，一个编译成 uImage 的内核镜像文件，可以支持多个单板，这里假设支持 smdk2410、smdk2440、jz2440（其中 smdk2410、smdk2440 是厂家的公板，国内的厂家参考公板设计出了自己的板子，比如 jz2440）。

这些板子的配置稍有不同，需要做一些单独的初始化，在内核里面，对于这些单板，都构造了一个 machine_desc 结构体，里面有 .init 和 .nr。

对于 JZ2440，它源自 smdk2440，内核没有它的单独文件，它使用 smdk2440 的相关文件，代码。

在上一节视频里面我们说过，以前 uboot 使用 ATAGS 给内核传参数时，它会传入一个机器 ID，内核会使用这个机器 ID 找到最合适的 machine_desc。即机器 ID 与 machine_desc 里面的 .nr 比较，相等就表示找到了对应的 machine_desc。

当我们的 uboot 不使用 ATAGS 传递参数，而使用 DTB 文件时，那么这时内核是如何选择对应的 machine_desc 呢？

在设备树文件的根节点里，有如下两行：

1.  
   model = "SMDK2440"
2.  
   compatible = "samsung,smdk2440","samsung,smdk2410","samsung,smdk24xx";

这里的 compatible 属性声明想要什么 machine_desc，属性值可以是一系列字符串，依次与 machine_desc 匹配。

内核最好支持 samsung,smdk2440 ，如果不支持，再尝试是否支持 samsung,smdk2410，再不支持，最后尝试 sasung,smdk24xx。

总结一下：

• 设备树根节点的 compatible 属性列出了一系列的字符串，表示它兼容的单板名，从“最兼容”到次之；

• 内核中有多个 machine_desc，其中有 dt_compat 成员，它指向一个字符串数组，里面表示该 machine_desc 支持哪些单板；

• 使用 compatible 属性的值，跟每一个 “machine_desc.dt_compat” 比较，成绩为 “吻合的 compatible 属性值的位置”，成绩越低越匹配，对应的 machine_desc 即被选中。

2.2、start_kernel 的调用过程

上节视频里，head.S 会把 DTB 的位置保存在 变量 __atags_pointer 里，最后调用 start_kernel。

start_kernel 的调用过程如下：

1.  
   start_kernel // init/main.c
2.  
   setup_arch(&command_line); // arch/arm/kernel/setup.c
3.  
   mdesc = setup_machine_fdt(__atags_pointer); // arch/arm/kernel/devtree.c
4.  
   early_init_dt_verify(phys_to_virt(dt_phys) // 判断是否有效的dtb, drivers/of/ftd.c
5.  
   initial_boot_params = params;
6.  
   mdesc = of_flat_dt_match_machine(mdesc_best, arch_get_next_mach); // 找到最匹配的machine_desc, drivers/of/ftd.c
7.  
   while ((data = get_next_compat(&compat))) {
8.  
   score = of_flat_dt_match(dt_root, compat);
9.  
   if (score > 0 && score < best_score) {
10.  
    best_data = data;
11.  
    best_score = score;
12.  
    }
13.  
    }
14.  
     
15.  
    machine_desc = mdesc;

三、对设备数中运行时配置信息的处理

设备树只是起一个信息传递的作用，对这些信息配置的处理，也比较简单，即从设备树的 DTB 文件中，把这些信息提取出来赋给内核中的某个变量即可。

函数调用过程如下：

1.  
   start_kernel // init/main.c
2.  
   setup_arch(&command_line); // arch/arm/kernel/setup.c
3.  
   mdesc = setup_machine_fdt(__atags_pointer); // arch/arm/kernel/devtree.c
4.  
   early_init_dt_scan_nodes(); // drivers/of/ftd.c
5.  
   /* Retrieve various information from the /chosen node */
6.  
   of_scan_flat_dt(early_init_dt_scan_chosen, boot_command_line);
7.  
    
8.  
   /* Initialize {size,address}-cells info */
9.  
   of_scan_flat_dt(early_init_dt_scan_root, NULL);
10.  
     
11.  
    /* Setup memory, calling early_init_dt_add_memory_arch */
12.  
    of_scan_flat_dt(early_init_dt_scan_memory, NULL);

里面主要对三种类型的信息进行处理，分别是：/chosen 节点中 bootags 属性，根节点的 #address-cells 和 #size-cells 属性， /memory 中的 reg 属性。

1. /chosen 节点中 bootargs 属性就是内核启动的命令行参数，它里面可以指定根文件系统在哪里，第一个运行的应用程序是哪一个，指定内核的打印信息从哪个设备里打印出来；

2. /memory 中的 reg 属性指定了不同板子内存的大小和起始地址；

3. 根节点的 #address-cells 和 #size-cells 属性指定属性参数的位数，比如指定前面 memroy 中的 reg 属性的地址是 32 位还是 64 位，大小是用一个 32 位表示，还是两个 32 位表示。

总结：

• /chosen 节点中 bootargs 属性的值，存入全局变量：boot_command_line；
• 确定根节点的这2个属性的值：#address-cells,#size-cells，存入全局变量：dt_root_addr_cells，dt_root_size_cells；
• 解析 /memory 中的 reg 属性，提取出 “base,size”，最终调用 memblock_add(base, size)。

四、dtb 转换为 device_node（unflatten）

在讲解之前，我们先想一个问题，我们的 uboot 把设备树 DTB 文件随便放到内存的某一个地方就可以使用，为什么内核运行中，他不会去覆盖 DTB 所占用的那块内存呢？

在前面我们讲解设备树格式时，我们知道，在设备树文件中，可以使用 /memreserve/ 指定一块内存，这块内存就是保留的内存，内核不会占用它。即使你没有指定这块内存，当我们内核启动时，它也会把设备数所占用区域保留下来。

如下就是函数调用过程：

1.  
   start_kernel // init/main.c
2.  
   setup_arch(&command_line); // arch/arm/kernel/setup.c
3.  
   arm_memblock_init(mdesc); // arch/arm/kernel/setup.c
4.  
   early_init_fdt_reserve_self();
5.  
   /* Reserve the dtb region */
6.  
   // 把DTB所占区域保留下来, 即调用: memblock_reserve
7.  
   early_init_dt_reserve_memory_arch(__pa(initial_boot_params),
8.  
   fdt_totalsize(initial_boot_params),
9.  
   0);
10.  
    early_init_fdt_scan_reserved_mem(); // 根据dtb中的memreserve信息, 调用memblock_reserve
11.  
     
12.  
    unflatten_device_tree(); // arch/arm/kernel/setup.c
13.  
    __unflatten_device_tree(initial_boot_params, NULL, &of_root,
14.  
    early_init_dt_alloc_memory_arch, false); // drivers/of/fdt.c
15.  
     
16.  
    /* First pass, scan for size */
17.  
    size = unflatten_dt_nodes(blob, NULL, dad, NULL);
18.  
     
19.  
    /* Allocate memory for the expanded device tree */
20.  
    mem = dt_alloc(size + 4, __alignof__(struct device_node));
21.  
     
22.  
    /* Second pass, do actual unflattening */
23.  
    unflatten_dt_nodes(blob, mem, dad, mynodes);
24.  
    populate_node
25.  
    np = unflatten_dt_alloc(mem, sizeof(struct device_node) + allocl,
26.  
    __alignof__(struct device_node));
27.  
     
28.  
    np->full_name = fn = ((char *)np) + sizeof(*np);
29.  
     
30.  
    populate_properties
31.  
    pp = unflatten_dt_alloc(mem, sizeof(struct property),
32.  
    __alignof__(struct property));
33.  
     
34.  
    pp->name = (char *)pname;
35.  
    pp->length = sz;
36.  
    pp->value = (__be32 *)val;

可以看到，先把 dtb 中的 memreserve 信息告诉内核，把这块内存区域保留下来，不占用它。

然后将扁平结构的设备树提取出来，构造成一个树，这里涉及两个结构体：device_node 结构体和 property 结构体。弄清楚这两个结构体就大概明白这节视频的主要内容了。

在 dts 文件里，每个大括号 {  } 代表一个节点，比如根节点里有个大括号，对应一个 device_node 结构体；memory 也有一个大括号，也对应一个 device_node 结构体。

节点里面有各种属性，也可能里面还有子节点，所以它们还有一些父子关系。

根节点下的 memory、chosen、led 等节点是并列关系，兄弟关系。

对于父子关系、兄弟关系，在 device_node 结构体的定义如下：

1.  
   struct device_node {
2.  
   const char *name; // 来自节点中的name属性, 如果没有该属性, 则设为"NULL"
3.  
   const char *type; // 来自节点中的device_type属性, 如果没有该属性, 则设为"NULL"
4.  
   phandle phandle;
5.  
   const char *full_name; // 节点的名字, node-name[@unit-address]
6.  
   struct fwnode_handle fwnode;
7.  
   struct property *properties; // 节点的属性
8.  
   struct property *deadprops; /* removed properties */
9.  
   struct device_node *parent; // 节点的父亲
10.  
    struct device_node *child; // 节点的孩子(子节点)
11.  
    struct device_node *sibling; // 节点的兄弟(同级节点)
12.  
    #if defined(CONFIG_OF_KOBJ)
13.  
    struct kobject kobj;
14.  
    #endif
15.  
    unsigned long _flags;
16.  
    void *data;
17.  
    #if defined(CONFIG_SPARC)
18.  
    const char *path_component_name;
19.  
    unsigned int unique_id;
20.  
    struct of_irq_controller *irq_trans;
21.  
    #endif
22.  
    };

device_node 结构体表示一个节点，property 结构体表示节点的具体属性。

property 结构体的定义如下：

1.  
   struct property {
2.  
   char *name; // 属性名字, 指向dtb文件中的字符串
3.  
   int length; // 属性值的长度
4.  
   void *value; // 属性值, 指向dtb文件中value所在位置, 数据仍以big endian存储
5.  
   struct property *next;
6.  
   #if defined(CONFIG_OF_DYNAMIC) || defined(CONFIG_SPARC)
7.  
   unsigned long _flags;
8.  
   #endif
9.  
   #if defined(CONFIG_OF_PROMTREE)
10.  
    unsigned int unique_id;
11.  
    #endif
12.  
    #if defined(CONFIG_OF_KOBJ)
13.  
    struct bin_attribute attr;
14.  
    #endif
15.  
    };
16.  
     

两个结构体与 dts 内容的相对关系如下：

具体的代码分析，参考视频内容。

五、device_node 转换为 platform_device

内核如何把 device_node 转换成 platform_device。

两个问题:

5.1、哪些 device_node 可以转换为 platform_device

1.  
   / {
2.  
   model = "SMDK24440";
3.  
   compatible = "samsung,smdk2440";
4.  
    
5.  
   #address-cells = <1>;
6.  
   #size-cells = <1>;
7.  
   //内存设备不会
8.  
   memory@30000000 {
9.  
   device_type = "memory";
10.  
    reg = <0x30000000 0x4000000>;
11.  
    };
12.  
    /*
13.  
    cpus {
14.  
    cpu {
15.  
    compatible = "arm,arm926ej-s";
16.  
    };
17.  
    };
18.  
    */ //只是设置一些启动信息
19.  
    chosen {
20.  
    bootargs = "noinitrd root=/dev/mtdblock4 rw init=/linuxrc console=ttySAC0,115200";
21.  
    };
22.  
     
23.  
    /*只有这个led设备才对转换成platfrom_device */
24.  
    led {
25.  
    compatible = "jz2440_led";
26.  
    reg = <S3C2410_GPF(5) 1>;
27.  
    };
28.  
    /************************************/
29.  
    };

内核函数 of_platform_default_populate_init，遍历 device_node 树，生成 paltform_device；

并非所有的device_node 都会转换为 platform_device 只有以下的 device_node 会转换：

• 该节点必须含有 compatible 属性；
• 根节点的子节点（节点必须含有 compatible 属性）；
• 含有特殊 compatible 属性的节点的子节点（子节点必须含有 compatible 属性）：这些特殊的 compatible 属性为："simple-bus"，"simple-mfd"，"isa"，"arm,amba-bus"。

根节点是例外的，生成 platform_device 时，即使有 compatible 属性也不会处理。

举例：

cpu 可以访问很多外设，spi 控制器，i2c 控制器，led。

如何在设备树中描述这些硬件？

比如以下的节点，/mytest 会被转换为 platform_device，因为它兼容 "simple-bus" ，它的子节点 /mytest/mytest@0 也会被转换为 platform_device；

/i2c 节点一般表示 i2c 控制器，它会被转换为 platform_device，在内核中有对应的 platform_driver；/i2c/at24c02 节点不会被转换为 platform_device，它被如何处理完全由父节点的 platform_driver 决定，一般是被创建为一个 i2c_client。

类似的也有 /spi 节点，它一般也是用来表示 SPI 控制器，它会被转换为 platform_device，在内核中有对应的 platform_driver；/spi/flash@0 节点不会被转换为 platform_device，它被如何处理完全由父节点的 platform_driver 决定，一般是被创建为一个 spi_device。

1.  
   / {
2.  
   mytest {
3.  
   compatile = "mytest", "simple-bus";
4.  
   mytest@0 {
5.  
   compatile = "mytest_0";
6.  
   };
7.  
   };
8.  
    
9.  
   i2c {
10.  
    compatile = "samsung,i2c";
11.  
    at24c02 {
12.  
    compatile = "at24c02";
13.  
    };
14.  
    };
15.  
     
16.  
    spi {
17.  
    compatile = "samsung,spi";
18.  
    flash@0 {
19.  
    compatible = "winbond,w25q32dw";
20.  
    spi-max-frequency = <25000000>;
21.  
    reg = <0>;
22.  
    };
23.  
    };
24.  
    };

5.2、怎么转换

函数调用过程：

a、入口函数 of_platform_default_populate_init（drivers/of/platform.c） 被调用的过程：

里面有段属性，编译内核段属性的变量会被集中放在一起。

vim arch/arm/kernel/vmlinux.lds

1.  
   start_kernel // init/main.c
2.  
   rest_init();
3.  
   pid = kernel_thread(kernel_init, NULL, CLONE_FS);
4.  
   kernel_init
5.  
   kernel_init_freeable();
6.  
   do_basic_setup();
7.  
   do_initcalls();
8.  
   for (level = 0; level < ARRAY_SIZE(initcall_levels) - 1; level++)
9.  
   do_initcall_level(level); // 比如 do_initcall_level(3)
10.  
    for (fn = initcall_levels[3]; fn < initcall_levels[3+1]; fn++)
11.  
    do_one_initcall(initcall_from_entry(fn)); // 就是调用"arch_initcall_sync(fn)"中定义的fn函数

b、of_platform_default_populate_init（drivers/of/platform.c）生成 platform_device 的过程：

遍历 device 树：

1.  
   of_platform_default_populate_init
2.  
   of_platform_default_populate(NULL, NULL, NULL);
3.  
   of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL)
4.  
   for_each_child_of_node(root, child) {
5.  
   rc = of_platform_bus_create(child, matches, lookup, parent, true); // 调用过程看下面
6.  
   dev = of_device_alloc(np, bus_id, parent); // 根据device_node节点的属性设置platform_device的resource
7.  
   if (rc) {
8.  
   of_node_put(child);
9.  
   break;
10.  
    }
11.  
    }
12.  
     

c、of_platform_bus_create(bus, matches, ...) 的调用过程（处理 bus 节点生成 platform_device，并决定是否处理它的子节点）：

1.  
   dev = of_platform_device_create_pdata(bus, bus_id, platform_data, parent); // 生成bus节点的platform_device结构体
2.  
   if (!dev || !of_match_node(matches, bus)) // 如果bus节点的compatile属性不吻合matches成表, 就不处理它的子节点
3.  
   return 0;
4.  
    
5.  
   for_each_child_of_node(bus, child) { // 取出每一个子节点
6.  
   pr_debug(" create child: %pOF\n", child);
7.  
   rc = of_platform_bus_create(child, matches, lookup, &dev->dev, strict); // 处理它的子节点, of_platform_bus_create是一个递归调用
8.  
   if (rc) {
9.  
   of_node_put(child);
10.  
    break;
11.  
    }
12.  
    }

d、I2C 总线节点的处理过程：

/i2c 节点一般表示 i2c 控制器，它会被转换为 platform_device，在内核中有对应的 platform_driver；platform_drvier 的 probe 函数中会调用 i2c_add_numbered_adapter：

1.  
   i2c_add_numbered_adapter // drivers/i2c/i2c-core-base.c
2.  
   __i2c_add_numbered_adapter
3.  
   i2c_register_adapter
4.  
   of_i2c_register_devices(adap); // drivers/i2c/i2c-core-of.c
5.  
   for_each_available_child_of_node(bus, node) {
6.  
   client = of_i2c_register_device(adap, node);
7.  
   client = i2c_new_device(adap, &info); // 设备树中的i2c子节点被转换为i2c_client

总结：dtb -> device_node -> platform_device

六、platform_device 跟 platform_driver 的匹配

drivers/base/platform.c：

a、注册 platform_driver 的过程：

1.  
   platform_driver_register
2.  
   __platform_driver_register
3.  
   drv->driver.probe = platform_drv_probe;
4.  
   driver_register
5.  
   bus_add_driver
6.  
   klist_add_tail(&priv->knode_bus, &bus->p->klist_drivers); // 把 platform_driver 放入 platform_bus_type 的driver链表中
7.  
   driver_attach
8.  
   bus_for_each_dev(drv->bus, NULL, drv, __driver_attach); // 对于plarform_bus_type下的每一个设备, 调用__driver_attach
9.  
   __driver_attach
10.  
    ret = driver_match_device(drv, dev); // 判断dev和drv是否匹配成功
11.  
    return drv->bus->match ? drv->bus->match(dev, drv) : 1; // 调用 platform_bus_type.match
12.  
    driver_probe_device(drv, dev);
13.  
    really_probe
14.  
    drv->probe // platform_drv_probe
15.  
    platform_drv_probe
16.  
    struct platform_driver *drv = to_platform_driver(_dev->driver);
17.  
    drv->probe

b、注册 platform_device 的过程：

1.  
   platform_device_register
2.  
   platform_device_add
3.  
   device_add
4.  
   bus_add_device
5.  
   klist_add_tail(&dev->p->knode_bus, &bus->p->klist_devices); // 把 platform_device 放入 platform_bus_type的device链表中
6.  
   bus_probe_device(dev);
7.  
   device_initial_probe
8.  
   __device_attach
9.  
   ret = bus_for_each_drv(dev->bus, NULL, &data, __device_attach_driver); // // 对于plarform_bus_type下的每一个driver, 调用 __device_attach_driver
10.  
    __device_attach_driver
11.  
    ret = driver_match_device(drv, dev);
12.  
    return drv->bus->match ? drv->bus->match(dev, drv) : 1; // 调用platform_bus_type.match
13.  
    driver_probe_device

匹配函数是 platform_bus_type.match，即 platform_match，匹配过程按优先顺序罗列如下：

• 比较 platform_dev.driver_override 和 platform_driver.drv(.driver)->name;
• 比较 platform_dev.dev.of_node 的 compatible 属性和 platform_driver.drv(.driver)->of_match_table；
• 比较 platform_dev.name 和 platform_driver.id_table；
• 比较 platform_dev.name 和 platform_driver.drv(.driver)->name；

有一个成功，即匹配成功！

七、内核中设备树的操作函数

include/linux/ 目录下有很多 of 开头的头文件：

7.1、处理 DTB

of_fdt.h    //dtb 文件的相关操作函数，我们一般用不到，因为 dtb 文件在内核中已经被转换为 device_node 树（它更易于使用）

7.2、处理 device_node

1.  
   of.h // 提供设备树的一般处理函数, 比如 of_property_read_u32(读取某个属性的u32值), *of_get_child_count(获取某个device_node的子节点数)
2.  
   of_address.h // 地址相关的函数, 比如 of_get_address(获得reg属性中的addr, size值)
3.  
   of_match_device(从matches数组中取出与当前设备最匹配的一项)
4.  
   of_dma.h // 设备树中DMA相关属性的函数
5.  
   of_gpio.h // GPIO相关的函数
6.  
   of_graph.h // GPU相关驱动中用到的函数, 从设备树中获得GPU信息
7.  
   of_iommu.h // 很少用到
8.  
   of_irq.h // 中断相关的函数
9.  
   of_mdio.h // MDIO (Ethernet PHY) API
10.  
    of_net.h // OF helpers for network devices.
11.  
    of_pci.h // PCI相关函数
12.  
    of_pdt.h // 很少用到
13.  
    of_reserved_mem.h // reserved_mem的相关函数

以中断相关的作为例子，一个设备可以发出中断，必须包含中断号和中断触发方式。

官方设备树规格树里面的设备示例：

1.  
   soc {
2.  
   #address-cells = <1>;
3.  
   #size-cells = <1>;
4.  
   serial {
5.  
   compatible = "ns16550";
6.  
   reg = <0x4600 0x100>;
7.  
   clock-frequency = <0>;
8.  
   interrupts = <0xA 0x8>;
9.  
   interrupt-parent = <&ipic>;
10.  
    };
11.  
    };

里面的属性里面有中断值。

通过：

int of_irq_parse_one(struct device_node *device, int index, struct of_phandle_args *out_irq);

解析某一对值，或者我们可以解析原始数据。

int of_irq_parse_raw(const __be32 *addr, struct of_phandle_args *out_irq);

addr 就指向了某一对值，把里面的中断号触发方式解析出来，保存在 of_phandle_args 结构体中。

7.3、处理 platform_device

of_platform.h    //把 device_node 转换为 platform_device 时用到的函数

1.  
   /* Platform drivers register/unregister */
2.  
   extern struct platform_device *of_device_alloc(struct device_node *np, const char *bus_id, struct device *parent);

文件涉及的函数在 device_node->platform_device 中大量使用。

1.  
   // 比如of_device_alloc(根据device_node分配设置platform_device),
2.  
   // of_find_device_by_node (根据device_node查找到platform_device),
3.  
   // of_platform_bus_probe (处理device_node及它的子节点)
4.  
   of_device.h // 设备相关的函数, 比如 of_match_device
5.  
   可以通过of_match_device找出哪一项最匹配

of 文件分为三类：

• 处理 DTB；
• 处理 device_node；
• 处理 platform_device 设备相关信息；

八、在根文件系统中查看设备树（有助于调试）

8.1、/sys/firmware/fdt

查看原始 dtb 文件：

hexdump -C /sys/firmware/fdt

8.2、/sys/firmware/devicetree

以目录结构呈现的 dtb 文件，根节点对应 base 目录，每一个节点对应一个目录，每一个属性对应一个文件，比如查看 #address-cells 的16进制：

hexdump -C "#address-cells"

查看 compatible：

cat compatible

如果你在设备树设备节点中设置一个错误的中断属性，那么就导致 led 对应的平台设备节点没办法创建。

8.3、/sys/device/platform

系统中所有的 platform_device，有来自设备树的，也有来自 .c 文件中注册的。

对于来自设备树的 platform_device，可以进入 /sys/devices/platform/<设备名>/of_node 查看它的设备树属性

8.4、/proc/device-tree

链接文件，指向 /sys/firmware/devicetree/base。