标签:
作者: 彭东林
QQ:405728433
开发板:tiny4412ADK + S700 + 4GB Flash
要移植的内核版本:Linux-4.4.0 (支持device tree)
u-boot版本:友善之臂自带的 U-Boot 2010.12 (为支持uImage启动,做了少许改动)
busybox版本:busybox 1.25
交叉编译工具链: arm-none-linux-gnueabi-gcc
(gcc version 4.8.3 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-29))
在Linux引入设备树之后,将原来写在代码中的大量的硬件信息全部移到了设备树中,然后在Linux启动的时候会解析设备树,利用解析到的硬件信息构造device,然后注册到相应的bus上,如果有对应的driver,则会调用driver的probe函数。那么这个过程是怎么进行的?Linux系统有各种device,如对于platform子系统来说有platform_device、对于I2C子系统有i2c_client、对于SPI子系统来说有spi_device,那么这些device是怎么跟设备树关联起来的呢?
在分析的过程中参考了下面的几篇博文:
http://www.wowotech.net/device_model/dt-code-analysis.html
http://www.wowotech.net/comm/i2c_overview.html
http://www.wowotech.net/comm/i2c_provider.html
这几篇博文讲的非常好,下面一篇是之前总结的:
http://www.cnblogs.com/pengdonglin137/p/4495056.html
解析过程大致有如下几个阶段:
start_kernel
---> setup_arch
---> unflatten_device_tree
在u-boot引导内核的时候,会将设备树在物理内存中的物理起始地址(存放在寄存器r2中)传递给Linux内核,然后Linux内核在函数unflatten_device_tree中会解析设备树镜像,并利用扫描到的信息创建由device node构成的链表,全局变量of_root指向链表的根节点,设备树的每个节点都会有一个struct device_node与之对应。
start_kernel
---> rest_init
---> kernel_init
---> kernel_init_freeable
---> do_basic_setup
---> do_initcalls
在do_initcalls函数中,kernel会依次执行各个initcall函数,在这个过程中,会调用 customize_machine,具体如下:
static int __init customize_machine(void)
{
/*
* customizes platform devices, or adds new ones
* On DT based machines, we fall back to populating the
* machine from the device tree, if no callback is provided,
* otherwise we would always need an init_machine callback.
*/
of_iommu_init();
if (machine_desc->init_machine)
machine_desc->init_machine();
#ifdef CONFIG_OF
else
of_platform_populate(NULL, of_default_bus_match_table,
NULL, NULL);
#endif
return 0;
}
arch_initcall(customize_machine);
这样就可调用到exynos_dt_machine_init:
static void __init exynos_dt_machine_init(void)
{
......
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
在of_platform_populate中会调用of_platform_bus_create ---> of_platform_device_create_pdata,完成platform_device的注册。那么Linux系统是怎么知道哪些device node要注册为platform_device,哪些是用于i2c_client,哪些是用于spi_device?不知道你有没有注意到调用of_platform_populate的时候给它传递了一个参数of_default_bus_match_table,它的定义如下:
const struct of_device_id of_default_bus_match_table[] = {
{ .compatible = "simple-bus", },
{ .compatible = "simple-mfd", },
#ifdef CONFIG_ARM_AMBA
{ .compatible = "arm,amba-bus", },
#endif /* CONFIG_ARM_AMBA */
{} /* Empty terminated list */
};
是这个意思:如果某个device node的compatible的值与数组of_default_bus_match_table中的任意一个元素的compatible值相等(但是对于compatible是arm,primecell有些特殊,它是单独处理的),那么这个device node的child指向的device node(device_node的child指向的是这个device node的子节点,也是一个链表)仍旧会被注册为platform_device。
of_platform_populate:
1: int of_platform_populate(struct device_node *root,
2: const struct of_device_id *matches,
3: const struct of_dev_auxdata *lookup,
4: struct device *parent)
5: {
6: struct device_node *child;
7: int rc = 0;
8:
9: root = root ? of_node_get(root) : of_find_node_by_path("/"); // 找到root device node
10: if (!root)
11: return -EINVAL;
12:
13: for_each_child_of_node(root, child) { // 遍历root device node的child device node
14: rc = of_platform_bus_create(child, matches, lookup, parent, true);
15: if (rc) {
16: of_node_put(child);
17: break;
18: }
19: }
20: of_node_set_flag(root, OF_POPULATED_BUS);
21:
22: of_node_put(root);
23: return rc;
24: }
of_platform_bus_create :
1: static int of_platform_bus_create(struct device_node *bus,
2: const struct of_device_id *matches,
3: const struct of_dev_auxdata *lookup,
4: struct device *parent, bool strict)
5: {
6: const struct of_dev_auxdata *auxdata;
7: struct device_node *child;
8: struct platform_device *dev;
9: const char *bus_id = NULL;
10: void *platform_data = NULL;
11: int rc = 0;
12:
13: /* Make sure it has a compatible property */
14: if (strict && (!of_get_property(bus, "compatible", NULL))) {
15: pr_debug("%s() - skipping %s, no compatible prop\n",
16: __func__, bus->full_name);
17: return 0;
18: }
19:
20: auxdata = of_dev_lookup(lookup, bus); // tiny4412给lookup传递的是NULL
21: if (auxdata) {
22: bus_id = auxdata->name;
23: platform_data = auxdata->platform_data;
24: }
25:
26: if (of_device_is_compatible(bus, "arm,primecell")) {
27: /*
28: * Don‘t return an error here to keep compatibility with older
29: * device tree files.
30: */
31: of_amba_device_create(bus, bus_id, platform_data, parent);
32: return 0;
33: }
34:
35: dev = of_platform_device_create_pdata(bus, bus_id, platform_data, parent); // 根据device node创建 platform_device并注册
36: if (!dev || !of_match_node(matches, bus)) // 判断是不是需要继续遍历这个device node下的child device node
37: return 0;
38:
39: for_each_child_of_node(bus, child) { // 遍历这个device node下的child device node,将child device node也注册为platform_device
40: pr_debug(" create child: %s\n", child->full_name);
41: rc = of_platform_bus_create(child, matches, lookup, &dev->dev, strict);
42: if (rc) {
43: of_node_put(child);
44: break;
45: }
46: }
47: of_node_set_flag(bus, OF_POPULATED_BUS);
48: return rc;
49: }
下面说一下i2c_client是如何注册的。先看下面一张图:
下面是从http://www.wowotech.net/comm/i2c_overview.html摘抄的一段话:
1)platform bus(/sys/bus/platform)是驱动工程师常见的bus,用于挂载和CPU通过系统总线连接的各类外设。在I2C framework中,I2C控制器直接从属于platform bus,我们在linux kernel中常说的I2C driver,都是指I2C controller driver,都是以platform driver的形式存在,当然,对应的控制器是platform device。
2)与此同时,kernel抽象出I2C bus(/sys/bus/i2c),用于挂载和I2C controller通过I2C总线连接的各个I2C slave device。
3)比较特殊的地方是,I2C core使用一个虚拟实体----I2C adapter,抽象I2C controller有关的功能(主要是数据的收发),I2C adapter也挂载在I2C bus上。
4)I2C adapter和I2C slave device都挂载在I2C bus上,就可以方便的进行Master(I2C adapter)和Slave之间的匹配操作,并通过I2C core提供的统一接口,访问I2C salve device,进行数据的收发。
我们知道,i2c控制器在i2c驱动模型中被抽象为i2c_adapter,但是i2c控制器驱动实际上是在platform_bus上,所以i2c控制器对应的是platform_device,因此会在上面调用of_platform_populate时注册,然后i2c控制器驱动的probe函数会被调用。如果以tiny4412开发板为例分析,在drivers/i2c/busses/i2c-s3c2410.c的probe函数中调用注册adapter的函数:i2c_add_numbered_adapter ---> i2c_add_adapter ---> i2c_register_adapter ---> of_i2c_register_devices,在函数of_i2c_register_devices中会遍历这个adapter对应的device node的child device node,这些child device node对应的就是挂载i2c bus上的板级外设的硬件信息,如 MMA7660。然后调用of_i2c_register_device,根据每个child device node的信息构造i2c_board_info,并调用i2c_new_device,在i2c_new_device中会创建并注册i2c_client,注册i2c_client的时候如果找到了对应的设备驱动程序(如 MMA7660的驱动程序),设备驱动程序的probe函数就会被调动。
由于SPI驱动模型跟I2C类似,spi_device的注册过程也跟i2c_client的很类似。spi控制器在spi子系统中被抽象为spi_master,spi控制器的驱动程序实际上也在platform_bus上,当调用of_platform_populate注册到对应的platform_device的时候,spi控制器驱动程序的probe函数会被执行,在probe函数中会想spi子系统注册spi_master。我们以以tiny4412分析为例,在drivers/spi/spi-s3c64xx.c的s3c64xx_spi_probe函数中调用devm_spi_register_master ---> spi_register_master ---> of_register_spi_devices 在of_register_spi_devices中会遍历与这个spi_master对应的device node的child device node,这些child device node就是挂在spi bus上的板级外设,如spi接口的存储器等等。然后调用of_register_spi_device,根据每个child device node的信息创建spi_device,并调用spi_add_device完成注册,注册spi_device的时候如果找到了对应的设备驱动程序(如 SPI接口的存储器的驱动程序),设备驱动程序的probe函数就会被调动。
在Linux系统起来后,会将解析完成的设备树导出到用户空间。
这个目录下的目录和文件是根据device node的结构组织的,顶层目录是root device node,其他的子目录是root device node 的 child device node,同时子目录又可以再嵌套子目录,以此表示这些device node的父子关系。
[root@tiny4412 root]# cd /proc/device-tree/
[root@tiny4412 base]# ls
#address-cells pinctrl@106E0000
#size-cells pinctrl@11000000
adc@126C0000 pinctrl@11400000
aliases pmu
amba ppmu_acp@10ae0000
backlight ppmu_camif@11ac0000
cam-power-domain@10023C00 ppmu_cpu@106c0000
camera ppmu_dmc0@106a0000
chipid@10000000 ppmu_dmc1@106b0000
chosen ppmu_g3d@12630000
clock-controller@03810000 ppmu_g3d@13220000
clock-controller@10030000 ppmu_image@12aa0000
codec@13400000 ppmu_lcd0@11e40000
compatible ppmu_leftbus0@116a0000
cpus ppmu_mfc_left@13660000
dsi@11C80000 ppmu_mfc_right@13670000
ehci@12580000 ppmu_rightbus@112a0000
exynos-usbphy@125B0000 ppmu_tv@12e40000
fimd@11c00000 pwm@139D0000
fixed-rate-clocks regulators
g2d@10800000 rtc@10070000
g3d-power-domain@10023C60 sdhci@12510000
gps-alive-power-domain@10023D00 sdhci@12520000
gps-power-domain@10023CE0 sdhci@12530000
hdmi@12D00000 sdhci@12540000
hsotg@12480000 serial@13800000
i2c-gpio-0 serial@13810000
i2c@13860000 serial@13820000
i2c@13870000 serial@13830000
i2c@13880000 spi@13920000
......
可以看看上一篇博文中的用软件I2C控制MMA7660的设备树的结构:
[root@tiny4412 base]# cd i2c-gpio-0
[root@tiny4412 i2c-gpio-0]# ls
#address-cells compatible i2c-gpio,delay-us name
#size-cells gpios mma7660@4c status
[root@tiny4412 i2c-gpio-0]# cd mma7660@4c/
[root@tiny4412 mma7660@4c]# ls
compatible interrupt-parent poll_interval
input_flat interrupts reg
input_fuzz name status
[root@tiny4412 mma7660@4c]#
可以看到,mma7660@4c确实是i2c-gpio-0的子目录,而且我们也知道mma7660对应的device node确实是i2c-gpio-0对应的device node的child device node。
可以看看platform device的注册情况:
[root@tiny4412 root]# cd /sys/bus/platform/
[root@tiny4412 platform]# ls
devices drivers_autoprobe uevent
drivers drivers_probe
[root@tiny4412 platform]# cd devices/
[root@tiny4412 devices]# ls
10000000.chipid 12530000.sdhci
10010000.syscon 12550000.mmc
10020000.system-controller 12580000.ehci
10023c00.cam-power-domain 12590000.ohci
10023c20.tv-power-domain 125b0000.exynos-usbphy
10023c40.mfc-power-domain 12a30000.sysmmu
10023c60.g3d-power-domain 12e20000.sysmmu
10023c80.lcd0-power-domain 13620000.sysmmu
10023ca0.isp-power-domain 13630000.sysmmu
10023ce0.gps-power-domain 13800000.serial
10023d00.gps-alive-power-domain 13810000.serial
10030000.clock-controller 13820000.serial
10050000.mct 13830000.serial
10070000.rtc 139d0000.pwm
10440000.interrupt-controller 2020000.sysram
10490000.interrupt-controller 3810000.clock-controller
10502000.l2-cache-controller 3860000.pinctrl
106e0000.pinctrl alarmtimer
10a40000.sysmmu amba
11000000.pinctrl backlight
11400000.pinctrl cpufreq-dt
11840000.jpeg-codec exynos-drm
11a20000.sysmmu i2c-gpio-0
11a30000.sysmmu leds
11a40000.sysmmu opp_table0
11a50000.sysmmu pmu
11a60000.sysmmu reg-dummy
11e20000.sysmmu regulators
12260000.sysmmu regulators:regulator@0
12270000.sysmmu regulatory.0
122a0000.sysmmu serial8250
122b0000.sysmmu snd-soc-dummy
123b0000.sysmmu usb-hub
123c0000.sysmmu video-phy@10020710
12480000.hsotg
可以看到,在设备树中:
regulators {
compatible = "simple-bus";
#address-cells = <0x1>;
#size-cells = <0x0>;
regulator@0 {
compatible = "regulator-fixed";
reg = <0x0>;
regulator-name = "VMEM_VDD_2.8V";
regulator-min-microvolt = <0x2ab980>;
regulator-max-microvolt = <0x2ab980>;
linux,phandle = <0x19>;
phandle = <0x19>;
};
};
regulator@0虽然是regulator的child device node,但是在/proc/device-tree中却看不到(用于呈现device node的父子关系),但是在/sys/bus/platform/devices/下却可以看得到。
在/sys/firmware下也可以看到devicetree的导出信息:
[root@tiny4412 root]# cd /sys/firmware/
[root@tiny4412 firmware]# ls -F
devicetree/ fdt
其中fdt是一个二进制文件,其中是完整的设备树镜像,可以用hexdump看看:
[root@tiny4412 root]# hexdump -C /sys/firmware/fdt | head -n 100
00000000 d0 0d fe ed 00 00 dc 2d 00 00 00 48 00 00 a3 ec |.......-...H....|
00000010 00 00 00 28 00 00 00 11 00 00 00 10 00 00 00 00 |...(............|
00000020 00 00 08 ad 00 00 a3 a4 00 00 00 00 43 a7 f0 00 |............C...|
00000030 00 00 00 00 00 27 bb 09 00 00 00 00 00 00 00 00 |.....‘..........|
00000040 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 |................|
00000050 00 00 00 03 00 00 00 04 00 00 00 00 00 00 00 01 |................|
00000060 00 00 00 03 00 00 00 04 00 00 00 0f 00 00 00 01 |................|
00000070 00 00 00 03 00 00 00 04 00 00 00 1b 00 00 00 01 |................|
00000080 00 00 00 03 00 00 00 38 00 00 00 2c 66 72 69 65 |.......8...,frie|
00000090 6e 64 6c 79 61 72 6d 2c 74 69 6e 79 34 34 31 32 |ndlyarm,tiny4412|
000000a0 00 73 61 6d 73 75 6e 67 2c 65 78 79 6e 6f 73 34 |.samsung,exynos4|
000000b0 34 31 32 00 73 61 6d 73 75 6e 67 2c 65 78 79 6e |412.samsung,exyn|
000000c0 6f 73 34 00 00 00 00 03 00 00 00 2f 00 00 00 37 |os4......../...7|
000000d0 46 72 69 65 6e 64 6c 79 41 52 4d 20 54 49 4e 59 |FriendlyARM TINY|
000000e0 34 34 31 32 20 62 6f 61 72 64 20 62 61 73 65 64 |4412 board based|
000000f0 20 6f 6e 20 45 78 79 6e 6f 73 34 34 31 32 00 00 | on Exynos4412..|
00000100 00 00 00 01 63 68 6f 73 65 6e 00 00 00 00 00 03 |....chosen......|
00000110 00 00 00 04 00 00 08 9c 43 cf ab 08 00 00 00 03 |........C.......|
00000120 00 00 00 04 00 00 08 89 43 a7 f0 00 00 00 00 03 |........C.......|
00000130 00 00 00 11 00 00 00 3d 2f 73 65 72 69 61 6c 40 |.......=/serial@|
可以看到开头的四个字节正好是d00dfeed,这个文件跟原始的设备树文件还是有些不同的,如chosen节点和memory节点。因为在用u-boot引导的时候,u-boot根据当前的环境对设备树镜像内容进行修改,下面是不同的地方:
我dump的方法是将fdt的内容用上面的命令重定向到一个文件中(hexdump –C /sys/firmware/fdt > /mnt/fdt.txt),然后通过U盘拷贝到电脑上,赋值其中的信息利用winhex文件创建一个二进制文件。用fdtdump工具(fdtdump dtb文件)将dtb的文件信息导出到一个文本文件中,然后再做比较。
在/sys/firmware/devicetree/base/下是以device node的父子关系创建的文件和目录,其实会发现,/proc/device-tree是一个软连接,指向的就是/sys/firmware/devicetree/base/:
[root@tiny4412 root]# ls /proc/device-tree -l
lrwxrwxrwx 1 0 0 29 Jan 1 06:11 /proc/device-tree -> /sys/firmware/devicetree/base
[root@tiny4412 root]#
那么/sys/firmware/fdt以及/sys/firmware/devicetree是在什么地方创建的呢?
/sys/firmware/devicetree的创建:
start_kernel
---> rest_init
---> kernel_init
---> kernel_init_freeable
---> do_basic_setup
---> driver_init
---> of_core_init
在of_core_init函数中(drivers/of/base.c):
void __init of_core_init(void) { struct device_node *np; /* Create the kset, and register existing nodes */ mutex_lock(&of_mutex); of_kset = kset_create_and_add("devicetree", NULL, firmware_kobj); if (!of_kset) { mutex_unlock(&of_mutex); pr_err("devicetree: failed to register existing nodes\n"); return; } for_each_of_allnodes(np) __of_attach_node_sysfs(np); mutex_unlock(&of_mutex); /* Symlink in /proc as required by userspace ABI */ if (of_root) proc_symlink("device-tree", NULL, "/sys/firmware/devicetree/base"); }
/sys/firmware/fdt的创建(drivers/of/fdt.c):
#ifdef CONFIG_SYSFS static ssize_t of_fdt_raw_read(struct file *filp, struct kobject *kobj, struct bin_attribute *bin_attr, char *buf, loff_t off, size_t count) { memcpy(buf, initial_boot_params + off, count); return count; } static int __init of_fdt_raw_init(void) { static struct bin_attribute of_fdt_raw_attr = __BIN_ATTR(fdt, S_IRUSR, of_fdt_raw_read, NULL, 0); if (!initial_boot_params) return 0; if (of_fdt_crc32 != crc32_be(~0, initial_boot_params, fdt_totalsize(initial_boot_params))) { pr_warn("fdt: not creating ‘/sys/firmware/fdt‘: CRC check failed\n"); return 0; } of_fdt_raw_attr.size = fdt_totalsize(initial_boot_params); return sysfs_create_bin_file(firmware_kobj, &of_fdt_raw_attr); } late_initcall(of_fdt_raw_init);
下面测试一下根据parent device node的compatible的不同,系统会把不同的device node注册为不同的device。
修改arch/arm/boot/dts/exynos4412-tiny4412.dts:
1: diff --git a/arch/arm/boot/dts/exynos4412-tiny4412.dts b/arch/arm/boot/dts/exynos4412-tiny4412.dts
2: index 579a507..ae29aa8 100644
3: --- a/arch/arm/boot/dts/exynos4412-tiny4412.dts
4: +++ b/arch/arm/boot/dts/exynos4412-tiny4412.dts
5: @@ -129,6 +129,30 @@
6: };
7: };
8: #endif
9: +
10: + demo_parent0 {
11: + compatible = "simple-bus";
12: +
13: + child0{
14: + compatible = "child0";
15: + };
16: +
17: + child1{
18: + compatible = "child1";
19: + };
20: + };
21: +
22: + demo_parent1 {
23: + compatible = "demo_parent1";
24: +
25: + child3{
26: + compatible = "child3";
27: + };
28: +
29: + child4{
30: + compatible = "child4";
31: + };
32: + };
33: };
34:
35: &rtc {
其中第11行表示demo_parent0对应的device node将来会在of_platform_populate时递归其下面的child device node。compatible = "simple-bus";来自of_default_bus_match_table:
1:
2: const struct of_device_id of_default_bus_match_table[] = {
3: { .compatible = "simple-bus", },
4: { .compatible = "simple-mfd", },
5: #ifdef CONFIG_ARM_AMBA
6: { .compatible = "arm,amba-bus", },
7: #endif /* CONFIG_ARM_AMBA */
8: {} /* Empty terminated list */
9: };
重新编译设备树(make dtbs),启动内核可以发现:
在/proc/device-tree/下:
1: [root@tiny4412 root]# cd /proc/device-tree/
2: [root@tiny4412 base]# ls
3: ......
4: demo_parent0 ppmu_mfc_left@13660000
5: demo_parent1 ppmu_mfc_right@13670000
6: ......
7: [root@tiny4412 base]# ls -R demo_parent*
8: demo_parent0:
9: child0 child1 compatible name
10:
11: demo_parent0/child0:
12: compatible name
13:
14: demo_parent0/child1:
15: compatible name
16:
17: demo_parent1:
18: child3 child4 compatible name
19:
20: demo_parent1/child3:
21: compatible name
22:
23: demo_parent1/child4:
24: compatible name
在/sys/bus/platform/devices/下:
1: [root@tiny4412 root]# cd /sys/bus/platform/devices/
2: [root@tiny4412 devices]# ls
3: ......
4: 11000000.pinctrl demo_parent0
5: 11400000.pinctrl demo_parent0:child0
6: 11840000.jpeg-codec demo_parent0:child1
7: 11a20000.sysmmu demo_parent1
8: 11a30000.sysmmu exynos-drm
9: ......
可以看到demo_parent0、child0和child1都被注册为了platform_device,demo_parent1也被注册为了platform_device而child3和child4却没有。child3和child4的具体被注册为什么设备需要由demo_parent1对应的platform_device的驱动程序决定。
未完待续……
基于tiny4412的Linux内核移植 -- 设备树的展开
标签:
原文地址:http://www.cnblogs.com/pengdonglin137/p/5248114.html