在线课堂：https://www.100ask.net/index（课程观看） 论 坛：http://bbs.100ask.net/（学术答疑） 开 发 板：https://100ask.taobao.com/ （淘宝） https://weidongshan.tmall.com/(天猫) 交流群一：QQ群：869222007（鸿蒙开发/Linux/嵌入式/驱动/资料下载） 交流群二：QQ群：536785813（单片机-嵌入式） 公 众 号：百问科技
版本日期作者说明V12020韦东山技术文档这一课是设备树中最重要的一课。 前面我们从内核文档了解到，对于设备树，它里面描述的信息可以分为这三部分： Linux uses DT data for three major purposes:
- platform identification,
- runtime configuration, and
- device population. 事实上，内核对设备树的处理，也会分为与其对应的三部分： 对于
platform identification，将在第02节_对设备树中平台信息的处理(选择machine_desc)进行分析； 对于runtime configuration，将在第03节_对设备树中运行时配置信息的处理进行分析； 对于device population，将在第04-06节进行分析；
现在我们开始第一节，我们要从源头分析，uboot将一些参数，设备树文件传给内核，那么内核如何处理这些设备树文件呢？ 我们需要从内核的第一个执行文件head.S开始分析。
bootloader启动内核时,会设置r0,r1,r2三个寄存器,
r0一般设置为0； r1一般设置为machine id (在使用设备树时该参数没有被使用)； r2一般设置ATAGS或DTB的开始地址；
这里的machine id，是让内核知道是哪个CPU，从而调用对应的初始化函数。 以前没有使用设备树时，需要bootloader传一个machine id给内核，现在使用设备树的话，这个参数就不需要设置了。 r2要么是以前的ATAGS开始地址，要么是现在使用设备树后的DTB文件开始地址。 对于ATAGS传参方法, 可以参考我们的"毕业班视频-自己写bootloader" 从www.100ask.net下载页面打开百度网盘, 打开如下目录: 100ask分享的所有文件 006_u-boot_内核_根文件系统(新1期_2期间的衔接) 视频 第002课_从0写bootloader_更深刻理解bootloader
head.S的内容内核head.S所做工作如下： a. __lookup_processor_type : 使用汇编指令读取CPU ID, 根据该ID找到对应的proc_info_list结构体(里面含有这类CPU的初始化函数、信息) b. __vet_atags : 判断是否存在可用的ATAGS或DTB c. __create_page_tables : 创建页表, 即创建虚拟地址和物理地址的映射关系 d. __enable_mmu : 使能MMU, 以后就要使用虚拟地址了 e. __mmap_switched : 上述函数里将会调用__mmap_switched f. 把bootloader传入的r2参数, 保存到变量__atags_pointer中 g. 调用C函数start_kernel
##最终效果 head.S和head-common.S最终效果： 把bootloader传来的r1值, 赋给了C变量: __machine_arch_type 把bootloader传来的r2值,
第02节_对设备树中平台信息的处理(选择machine_desc)这节讲解内核对设备树中平台设备信息是如何处理的。
内核是如何选择对应的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呢？ 在设备树文件的根节点里，有如下两行：
model = "SMDK24440";
compatible = "samsung,smdk2440"，"samsung,smdk24140"，"samsung,smdk24xx";
这里的compatible属性声明想要什么machine_desc，属性值可以是一系列字符串，依次与machine_desc匹配。 内核最好支持samsung,smdk2440，如果不支持，再尝试是否支持samsung,smdk24140，再不支持，最后尝试samsung,smdk24xx 0 && score full_name = fn = ((char *)np) + sizeof(*np);
populate_properties
pp = unflatten_dt_alloc(mem, sizeof(struct property),
__alignof__(struct property));
pp->name = (char *)pname;
pp->length = sz;
pp->value = (__be32 *)val;
可以看到，先把dtb中的memreserve信息告诉内核，把这块内存区域保留下来，不占用它。
然后将扁平结构的设备树提取出来，构造成一个树，这里涉及两个结构体：device_node结构体和property结构体。弄清楚这两个结构体就大概明白这节视频的主要内容了。
在dts文件里，每个大括号{ }代表一个节点，比如根节点里有个大括号，对应一个device_node结构体；memory也有一个大括号，也对应一个device_node结构体。 节点里面有各种属性，也可能里面还有子节点，所以它们还有一些父子关系。 根节点下的memory、chosen、led等节点是并列关系，兄弟关系。 对于父子关系、兄弟关系，在device_node结构体里面肯定有成员来描述这些关系。
打开include/linux/Of.h可以看到device_node结构体的定义如下： struct device_node { const char *name; // 来自节点中的name属性, 如果没有该属性, 则设为"NULL" const char *type; // 来自节点中的device_type属性, 如果没有该属性, 则设为"NULL" phandle phandle; const char *full_name; // 节点的名字, node-name[@unit-address] struct fwnode_handle fwnode;
struct property *properties; // 节点的属性
struct property *deadprops; /* removed properties */
struct device_node *parent; // 节点的父亲
struct device_node *child; // 节点的孩子(子节点)
struct device_node *sibling; // 节点的兄弟(同级节点)
#if defined(CONFIG_OF_KOBJ)
struct kobject kobj;
#endif
unsigned long _flags;
void *data;
#if defined(CONFIG_SPARC)
const char *path_component_name;
unsigned int unique_id;
struct of_irq_controller *irq_trans;
#endif
};
device_node结构体表示一个节点，property结构体表示节点的具体属性。
properties结构体的定义如下：
```c
struct property {
char *name; // 属性名字, 指向dtb文件中的字符串
int length; // 属性值的长度
void *value; // 属性值, 指向dtb文件中value所在位置, 数据仍以big endian存储
struct property *next;
#if defined(CONFIG_OF_DYNAMIC) || defined(CONFIG_SPARC)
unsigned long _flags;
#endif
#if defined(CONFIG_OF_PROMTREE)
unsigned int unique_id;
#endif
#if defined(CONFIG_OF_KOBJ)
struct bin_attribute attr;
#endif
};
两个结构体与dts内容的对于关系如下：
具体的代码分析，参考视频内容。
第05节_device_node转换为platform_device内核如何把device_node转换成platfrom_device
两个问题a.那些device_node可以转换为platform_device
/ {
model = "SMDK24440";
compatible = "samsung,smdk2440";
#address-cells = ;
#size-cells = ;
//内存设备不会
memory@30000000 {
device_type = "memory";
reg = ;
};
/*
cpus {
cpu {
compatible = "arm,arm926ej-s";
};
};
*/ //只是设置一些启动信息
chosen {
bootargs = "noinitrd root=/dev/mtdblock4 rw init=/linuxrc console=ttySAC0,115200";
};
/*只有这个led设备才对转换成platfrom_device */
led {
compatible = "jz2440_led";
reg = ;
};
/************************************/
};
- a. 内核函数of_platform_default_populate_init, 遍历device_node树, 生成platform_device
- b. 并非所有的device_node都会转换为platform_device只有以下的device_node会转换:
-
- b.1 该节点必须含有compatible属性
-
- b.2 根节点的子节点(节点必须含有compatible属性)
-
- b.3 含有特殊compatible属性的节点的子节点(子节点必须含有compatible属性): 这些特殊的compatilbe属性为:
“simple-bus”,“simple-mfd”,“isa”,"arm,amba-bus "
- b.3 含有特殊compatible属性的节点的子节点(子节点必须含有compatible属性): 这些特殊的compatilbe属性为:
根节点是例外的，生成platfrom_device时，即使有compatible属性也不会处理
举例 cpu可以访问很多外设，spi控制器 I2c控制器，led
如何在设备树中描述这些硬件？ b.4 示例: 比如以下的节点, /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。
/ {
mytest {
compatile = "mytest", "simple-bus";
mytest@0 {
compatile = "mytest_0";
};
};
i2c {
compatile = "samsung,i2c";
at24c02 {
compatile = "at24c02";
};
};
spi {
compatile = "samsung,spi";
flash@0 {
compatible = "winbond,w25q32dw";
spi-max-frequency = ;
reg = ;
};
};
};
b.怎么转换 函数调用过程: a. 入口函数 of_platform_default_populate_init (drivers/of/platform.c) 被调用到过程:
里面有段属性，编译内核段属性的变量会被集中放在一起 vim arch/arm/kernel/vmlinux.lds
start_kernel // init/main.c
rest_init();
pid = kernel_thread(kernel_init, NULL, CLONE_FS);
kernel_init
kernel_init_freeable();
do_basic_setup();
do_initcalls();
for (level = 0; level driver.probe = platform_drv_probe;
driver_register
bus_add_driver
klist_add_tail(&priv->knode_bus, &bus->p->klist_drivers); // 把 platform_driver 放入 platform_bus_type 的driver链表中
driver_attach
bus_for_each_dev(drv->bus, NULL, drv, __driver_attach); // 对于plarform_bus_type下的每一个设备, 调用__driver_attach
__driver_attach
ret = driver_match_device(drv, dev); // 判断dev和drv是否匹配成功
return drv->bus->match ? drv->bus->match(dev, drv) : 1; // 调用 platform_bus_type.match
driver_probe_device(drv, dev);
really_probe
drv->probe // platform_drv_probe
platform_drv_probe
struct platform_driver *drv = to_platform_driver(_dev->driver);
drv->probe
b. 注册 platform_device 的过程:
platform_device_register
platform_device_add
device_add
bus_add_device
klist_add_tail(&dev->p->knode_bus, &bus->p->klist_devices); // 把 platform_device 放入 platform_bus_type的device链表中
bus_probe_device(dev);
device_initial_probe
__device_attach
ret = bus_for_each_drv(dev->bus, NULL, &data, __device_attach_driver); // // 对于plarform_bus_type下的每一个driver, 调用 __device_attach_driver
__device_attach_driver
ret = driver_match_device(drv, dev);
return drv->bus->match ? drv->bus->match(dev, drv) : 1; // 调用platform_bus_type.match
driver_probe_device
匹配函数是platform_bus_type.match, 即platform_match, 匹配过程按优先顺序罗列如下:
- 比较 platform_dev.driver_override 和 platform_driver.drv->name
- 比较 platform_dev.dev.of_node的compatible属性 和 platform_driver.drv->of_match_table
- 比较 platform_dev.name 和 platform_driver.id_table
- 比较 platform_dev.name 和 platform_driver.drv->name 有一个成功, 即匹配成功
include/linux/目录下有很多of开头的头文件: dtb -> device_node -> platform_device a. 处理DTB of_fdt.h // dtb文件的相关操作函数, 我们一般用不到, 因为dtb文件在内核中已经被转换为device_node树(它更易于使用) b. 处理device_node
of.h // 提供设备树的一般处理函数, 比如 of_property_read_u32(读取某个属性的u32值), *of_get_child_count(获取某个device_node的子节点数)
of_address.h // 地址相关的函数, 比如 of_get_address(获得reg属性中的addr, size值)
of_match_device(从matches数组中取出与当前设备最匹配的一项)
of_dma.h // 设备树中DMA相关属性的函数
of_gpio.h // GPIO相关的函数
of_graph.h // GPU相关驱动中用到的函数, 从设备树中获得GPU信息
of_iommu.h // 很少用到
of_irq.h // 中断相关的函数
of_mdio.h // MDIO (Ethernet PHY) API
of_net.h // OF helpers for network devices.
of_pci.h // PCI相关函数
of_pdt.h // 很少用到
of_reserved_mem.h // reserved_mem的相关函数
以中断相关的作为例子 一个设备可以发出中断，必须包含中断号和中断触发方式
官方设备树规格书里面的设备示例
soc {
#address-cells = ;
#size-cells = ;
serial {
compatible = "ns16550";
reg = ;
clock-frequency = ;
interrupts = ;
interrupt-parent = ;
};
};
里面的属性里面有中断值
通过
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结构体中
c. 处理 platform_device of_platform.h // 把device_node转换为platform_device时用到的函数,
/* Platform drivers register/unregister */
extern struct platform_device *of_device_alloc(struct device_node *np,
const char *bus_id,
struct device *parent);
文件涉及的函数在 device_node -> platform_device 中大量使用
// 比如of_device_alloc(根据device_node分配设置platform_device),
// of_find_device_by_node (根据device_node查找到platform_device),
// of_platform_bus_probe (处理device_node及它的子节点)
of_device.h // 设备相关的函数, 比如 of_match_device
可以通过of_match_device找出哪一项最匹配，
of文件分为三类
- 处理DTB
- 处理device_node
- 处理 platform_device 设备相关信息
a. /sys/firmware/fdt // 查看原始dtb文件 hexdump -C /sys/firmware/fdt b. /sys/firmware/devicetree // 以目录结构程现的dtb文件, 根节点对应base目录, 每一个节点对应一个目录, 每一个属性对应一个文件 比如查看 #address-cells 的16进制 hexdump -C “#address-cells” 查看compatible
cat compatible
如果你在设备树设备节点中设置一个错误的中断属性，那么就导致led对应的平台设备节点没办法创建 c. /sys/devices/platform // 系统中所有的platform_device, 有来自设备树的, 也有来有.c文件中注册的 对于来自设备树的platform_device, 可以进入 /sys/devices/platform//of_node 查看它的设备树属性 d. /proc/device-tree 是链接文件, 指向 /sys/firmware/devicetree/base
朋友您好，上面的内容过瘾不？如果还想了解更多可以去淘宝搜索"设备树" 进入"韦东山老师个人店"购买设备树视频，29节只要69元，超级划算！
