高通平台Android源码分析之Linux内核设备树
2016年04月22日 00:39:55 yangchangwen83 阅读数：3929
转载自 http://huaqianlee.me/2015/08/19/Android/高通平台Android源码分析之Linux内核设备树-DT-Device-Tree-dts文件/
刚开始接触Android源码的时候，发现在kernel里面多了一种dts文件，因为当初自学Linux时和在第一家公司做物联网模型时都是用的比较老的内核，内核代码还比较混乱，没有采用dts这种方便简洁的格式。后面才知道这是因为Linus的一句”this whole arm thing is a fucking pain in ass“促进改革的，记得Linux早期代码里面板级细节都是在C文件中描述的，代码就显得十分臃肿和混乱。如此优化之后就显得简洁多了，并且也更易于学习、移植。
今天准备专门来分析一下内核设备树，主要按照如下三个方向来分析：
- Device Tree组成及用法；
- DTS文件解析常用api介绍；
- DTS文件的编译；
- 高通Android源码中dts文件引用流程；
Device Tree由一系列node（节点）和property（属性）组成，节点本身可包含更多的子节点。属性是成对出现的name-value键值对。在device tree中主要描述如下信息：
- CPU的数量及类别
- 内存基地址和size
- 总线和桥
- 外设连接
- 中断
- GPIO
- CLOCK
Device Tree在内核的作用有点类似于描述出PCB上的CPU、内存、总线、设备及IRQ GPIO等组成的tree结构。然后经由bootloader传递给内核，内核再根据此设备树解析出需要的i2c、spi等设备，然后将内存、IRQ、GPIO等资源绑定到相应的设备。
lk中通过tag传递到kernel，文件路径：bootable/bootloader/lk/app/aboot/aboot.c，由DEVICE_TREE宏开关控制
DTS(device tree source)
dts文件是一种ASCII文本格式的device tree描述文件，其结构明了，第一次看到都能大概猜出其描述意图。在内核中arm部分，基本上一个.dts文件对应一个arm的machine，一般位于kernel/arch/arm/boot/dts。由于一个soc可能对应多个machine，
所以一般讲多个machine通用的部分提炼为一个.dsti文件，有点类似于头文件的作用，引用方式也类似：#include “xxx.dtsi”，dtsi文件也可以相互引用。
dts中的基本元素为节点和属性，节点可以包含属性和子节点，属性为name-value键值对，如下：
1
| / { node1 { a-string-property = "A string"; // 值为字符串 a-string-list-property = "first string", "second string";// 值为字符数组 a-byte-data-property = [0x01 0x23 0x34 0x56]; // 值为二进制 child-node1 { first-child-property; second-child-property = <1>; a-string-property = "Hello, world"; }; child-node2 { }; }; node2 { an-empty-property; // 值为kog /* each number (cell) is a uint32 */ a-cell-property = <1 2 3 4>; // cells（由uint32组成） child-node1 { }; }; };
|
上述dt并没有什么真实用途，没有描述任何东西。不过展示了dt的结构：
- 一个根节点：”/“；
- 一对子节点：”node1”和”node2”；
- 子节点的子节点：”child-node”；
- 属性定义： 属性值可以为空、字符串、cells(整数组成)、数组及二进制等任意字节流；
属性中常用的字节流如下：
1 2 3 4 5 6 7 8 9 10
| # 字符串，用双引号引用： string-property = "A string"; #cells(32 bits)，用尖括号引用分隔开的32bit无符号整数： cell-property = <0xbeef 123 0xabcd1234>； # 二进制数据，用方括号引用： binary-property = [0x01 0x23 0x45 0x67]; # 通过逗号链接不同数据： mixed-property = "a string", [0x01 0x23 0x45 0x67], <0x12345678>; # 通过逗号创建字符串数组： string-list = "red fish", "blue fish";
|
Sample Machine
理解设备树怎么被用的最好办法，就是做一遍，接下来就通过一步一步构建描述一个简单machine的device tree来理解设备树。假设machine的硬件配置如下：
- 一个32bit的ARM CPU
- 处理器的local bus的内存映射分布了串口、spi总线控制器、i2c控制器、中断控制器和外部总线桥
- 256MB的SDRAM，基地址为0
- 2个串口基地址为：0x101f1000 和 0x101f2000
- GPIO控制器，基地址为0x101f3000
- spi控制器，基地址为0x10170000,从属设备：
- MMC slot with ss pin attached to GPIO #1 (不能很好理解其意思，所以就不胡乱翻译了)
- External bus桥，从属设备：
- smc smc91111 Ethernet设备，基地址为0x10100000
- i2c控制器，基地址为0x10160000，从属设备：
- Maxim DS1338时钟芯片，从设备I2C地址 1101000(0x58)
- 64MB Nor flash,基地址为0x30000000
首先，为machine创建一个框架结构，一个有效设备树的最简单的结构，如下：
1
| / { compatible = "acme,coyotes-revenge"; };
|
compatible指定系统的名字，格式： compatible = “< manufacturer>,< model>”（制造商，型号）。它非常重要，用来精确指定设备，并通过包含manufacurer(制造商)名字来避免冲突。因为操作系统通过compatible的值来决定machine怎么运行，所以使用正确的值是非常重要的。
理论上来说，compatible是操作系统所有数据标示machine的唯一标示符，os将通过顶层compatible寻找相应的值。
CPUs
第二步，描述CPU的”cpus”节点，其包含每一个CPU描述信息的子节点，在这个例子中，CPU为一个双核的arm cortex A9处理器，所以其描述如下：
1
| / { compatible = "acme,coyotes-revenge"; cpus { cpu@0 { compatible = "arm,cortex-a9"; // 格式同顶层节点，<manufacturer>,<model> }; cpu@1 { compatible = "arm,cortex-a9"; }; }; };
|
每一个节点必须有一个节点名，格式： < name>[@< unit-address>]。
- < name>：为最长31个字符的ascii字符串，一般用其代表的设备类型命名，ie. 一个3com Ethernet adapter的节点名：ethernet，不用3com509。
- unit-address： 描述设备的地址，一般情况下，其提供访问设备的基地址，节点的reg property也用此参数，见下文。
同层次兄弟节点的节点名必须是独一无二的，不过多个节点可以使用一样的通用name，只要地址不同就可以了。ie. serial@101f1000 & serial@101f2000
Devices
每一个device在系统中由一个设备树节点描述，所以接下来，第三步是为设备填充树的节点。不过，现在我为新节点创建一个空节点，直到我们知道地址范围和如何处理irqs请求之后再填写相应内容。如下：
1
| / { compatible = "acme,coyotes-revenge"; cpus { cpu@0 { compatible = "arm,cortex-a9"; }; cpu@1 { compatible = "arm,cortex-a9"; }; }; serial@101F0000 { compatible = "arm,pl011"; }; serial@101F2000 { compatible = "arm,pl011"; }; gpio@101F3000 { compatible = "arm,pl061"; }; interrupt-controller@10140000 { compatible = "arm,pl190"; }; spi@10115000 { compatible = "arm,pl022"; }; external-bus { ethernet@0,0 { compatible = "smc,smc91c111"; }; i2c@1,0 { compatible = "acme,a1234-i2c-bus"; rtc@58 { compatible = "maxim,ds1338"; }; }; flash@2,0 { compatible = "samsung,k8f1315ebm", "cfi-flash"; }; }; };
|
在此tree中，在系统中为每一个device增加了节点，其层次结构反应了系统中的连接情况。ie. extern bus上的的设备憋创建为external bus节点的子节点，i2c设备被创建为i2c总线控制器的子节点。简单来说，tree中的层次结构代表了系统中的CPU视图。
目前，这个tree是无效的，因为它没有设备之间的连接信息，接下来再添加这些信息。
在这个tree中有几点需要注意：
- 每个设备节点都有一个compatible属性
- flash节点的compatible属性有两个字符串值。
- 如前所述，节点名反映设备类型，而非详细型号。
compatible详解
设备树中每个节点都需要有compatible属性，compatible属性决定每一个设备驱动绑定哪一个设备。如上所介绍，compatible是一个字符串序列，第一个字符串指定精确设备，第二字符串指定兼容设备。
例如：Freescale MPC8349片上有一个根据国家半导体ns16550接口实现的串行设备，定义为：compatible = “fsl,mpc8349-uart”, “ns16550”. 第一个字符串指定精确设备，第二个指定国家半导体16550 uart兼容设备。
ns16550没有制造商前缀（manufacturer）纯属历史原因，所有的compatible值应该带有制造商前缀。
这种做法允许将存在的设备驱动绑定到一类更新的设备，并且仍然能识别到精确的设备。
警告：不要使用通配符赋值，如：”fsl,mpc83xx-uart”等。为了兼容后续设备，一般会选择一个特定实现，如上的：”ns16550”。
关于设备寻址，设备树中通过如下属性encode地址信息：
1 2 3 4 5
| reg ：每个可寻址的设备有一个reg cells. 格式：reg = <address1 length1 [address2 length2] [address3 length3] ... > // 因为地址和地址长度是变量，所以父节点中定义#address-cells和#size-cells两个属性，声明每个域里会用到多少cell #address-cells #size-cells
|
CPUѰַ
CPU节点寻址是寻址里面最简单的，每个CPU被一个独一无二的ID标记，没有size与CPU ids关联。如下：
1
| cpus { #address-cells = <1>; #size-cells = <0>; // 此两个属性表明子节点reg 值为一个没有size的uint32地址 cpu@0 { compatible = "arm,cortex-a9"; reg = <0>; // 值与节点名的unit-address相同 }; cpu@1 { compatible = "arm,cortex-a9"; reg = <1>; }; };
|
如果一个节点有reg属性，则节点名必须包含unit-address，并且取reg属性的第一个address值。
与cpu中只有address值不同，有内存映像地址的设备还需分配地址范围值，每个子节点reg元素定义地址长度值的数量由父节点的#size-cells指定。如下：
1
| / { #address-cells = <1>; // 值为 1 cell(32bits) #size-cells = <1>; // 每个长度值为 1 cell // 如果是64 bit machines， 则以上两值为2 ... serial@101f0000 { compatible = "arm,pl011"; reg = <0x101f0000 0x1000 >; // 第一个参数为基地址，第二个参数为地址长度，此处表示serial的内存地址范围：0x101f0000~0x101f0fff }; serial@101f2000 { compatible = "arm,pl011"; reg = <0x101f2000 0x1000 >; }; gpio@101f3000 { compatible = "arm,pl061"; reg = <0x101f3000 0x1000 0x101f4000 0x0010>; // GPIO设备被分配到两个地址范围 }; interrupt-controller@10140000 { compatible = "arm,pl190"; reg = <0x10140000 0x1000 >; }; spi@10115000 { compatible = "arm,pl022"; reg = <0x10115000 0x1000 >; }; ... };
|
当然，并不是所有设备都直接和cpu相连，也有一些设备通过挂载到一条总线上和cpu相连。对于挂接到总线的设备，每个父节点为子节点定义地址域，如下：
1
| external-bus { //父节点 #address-cells = <2> // 子节点有2 cells基地址值，一个用于指定chip number，一个用于指定选中芯片基地址的偏移量 #size-cells = <1>; // 子节点有1 cell 地址长度 ethernet@0,0 { compatible = "smc,smc91c111"; reg = <0 0 0x1000>; }; i2c@1,0 { compatible = "acme,a1234-i2c-bus"; reg = <1 0 0x1000>; rtc@58 { compatible = "maxim,ds1338"; }; }; flash@2,0 { compatible = "samsung,k8f1315ebm", "cfi-flash"; reg = <2 0 0x4000000>; }; };
|
由于地址域被节点和其子节点一起定义，所以父节点可以为总线定义任何寻址方式。除了直接父亲以外的所有节点和子节点都不用关心本地的寻址域，不用关心地址从哪映射到哪。
如不明白，请继续往下看，相信接下来的部分会帮你解惑
无内存映像的设备没有直接访问cpu的权限，父设备的驱动将间接访问cpu，其cpu一样reg属性会有一个地址值，但没有地址长度或范围，如下：
1
| i2c@1,0 { compatible = "acme,a1234-i2c-bus"; #address-cells = <1>; #size-cells = <0>; reg = <1 0 0x1000>; rtc@58 { compatible = "maxim,ds1338"; reg = <58>; }; };
|
前面讲了怎么给设备分配本地地址，但没有说明怎么映射到cpu能直接访问的地址。接下来就详细分析一下这一部分：
根节点描述cpu地址空间视图，根节点的子节点不需要做任何显性的映射直接使用cpu的地址域。比如：serial@101f0000直接分配到地址0x101f0000.
而不是根节点的直接孩子的节点不使用cpu的地址域，为了能将其映射到cpu的内存地址，设备树就得对其地址进行转换，ranges属性就是用来实现这个目的的，加入ranges属性后如下：
1
| / { compatible = "acme,coyotes-revenge"; #address-cells = <1>; #size-cells = <1>; ... external-bus { #address-cells = <2> #size-cells = <1>; ranges = <0 0 0x10100000 0x10000 // Chipselect 0, Ethernet 1 0 0x10160000 0x10000 // Chipselect 1, i2c controller 2 0 0x30000000 0x10000000>; // Chipselect 2, NOR Flash，此处参考文章地址空间大小少一个0，但我觉得不对，所以自己做了修改，下同，就不再说明 // 相信大家直接通过这个列表就能知道地址怎么转换的了，如下： 1. 偏移量为0的Chipselect0映射到0x10100000~0x1010ffff 2. 偏移量为0的Chipselect1映射到0x10160000~0x1016ffff 3. 偏移量为0的Chipselect2映射到0x30000000~0x3fffffff （此处参考文章写的0x10000000，但我觉得应该是0x3fffffff，原地址见博文最后引用） ethernet@0,0 { compatible = "smc,smc91c111"; reg = <0 0 0x1000>; }; // i2c总线节点没有ranges参数，因为i2c总线上的设备不需映射到cpu地址域，cpu直接通过i2c就能访问i2c设备 i2c@1,0 { compatible = "acme,a1234-i2c-bus"; #address-cells = <1>; #size-cells = <0>; reg = <1 0 0x1000>; rtc@58 { compatible = "maxim,ds1338"; reg = <58>; }; }; flash@2,0 { compatible = "samsung,k8f1315ebm", "cfi-flash"; reg = <2 0 0x10000000>; // 此处参考文章写的0x4000000， 但我觉得为0x10000000 - 256MB }; }; };
|
ranges参数的值是一个地址转换列表，每一个条目由如下几部分组成：
- 子节点地址：由子节点的#address-cells值决定
- 父节点地址：由父节点的#address-cells值决定
- 子节点地址空间的大小 ：由子节点的#size-cells值决定
如果ranges参数为空，则表示子节点地址和父节点地址1:1映射。你可能会有疑问，既然1:1映射，为什么还要通过地址转换来获得地址空间。一些总线（比如PCI）有完全不同的地址空间细节需要暴露给操作系统。其他带DMA的设备需要知道设备在总线上的真实地址。有时设备需要组合在一起去共享相同的可编程物理地址映射。是否需要通过1:1映射依赖于操作系统和硬件设计的很多信息。
缺乏ranges参数意味着，一个设备只能被其父节点访问而不能被cpu直接访问。
中断信号可以来自machine的任何设备，中断信号在设备树中被描述为节点之间的links。主要有如下4中属性：
- interrupt-controller：一个空属性，定义节点为中断控制器；
- #interrupt-cells：表明连接此中断控制器的interrupts属性cell大小（类似于#address-cells和#size-cells）；
- interrupt-parent：指定节点设备所依附的中断控制器的phandle，若没有此参数，则从父节点继承；
- interrupts：中断说明符列表，节点通过此方法指定中断号、触发方式等；
一个中断说明符描述指定中断输入设备的相关信息，由#interrupt-cells指定中断说明符cell数量。设备可能一个或多个中断源。一个中断设备的说明符完全取决于绑定的中断控制器设备。 定义一个中断源需要多少cells由中断控制器决定。加入中断相关属性后如下：
1
| / { compatible = "acme,coyotes-revenge"; #address-cells = <1>; #size-cells = <1>; interrupt-parent = <&intc>; // intc->interrupt-controller，作为系统默认的interrupt-parent属性，子节点重写则覆盖 cpus { #address-cells = <1>; #size-cells = <0>; cpu@0 { compatible = "arm,cortex-a9"; reg = <0>; }; cpu@1 { compatible = "arm,cortex-a9"; reg = <1>; }; }; serial@101f0000 { compatible = "arm,pl011"; reg = <0x101f0000 0x1000 >; interrupts = < 1 0 >; // 指定中断源 }; serial@101f2000 { compatible = "arm,pl011"; reg = <0x101f2000 0x1000 >; interrupts = < 2 0 >; }; gpio@101f3000 { compatible = "arm,pl061"; reg = <0x101f3000 0x1000 0x101f4000 0x0010>; interrupts = < 3 0 >; }; intc: interrupt-controller@10140000 { // 中断控制器 compatible = "arm,pl190"; reg = <0x10140000 0x1000 >; interrupt-controller; #interrupt-cells = <2>; // 中断说明符有2 cells，此例中cell 1表示中断号，cell 2 表示触发方式 }; spi@10115000 { compatible = "arm,pl022"; reg = <0x10115000 0x1000 >; interrupts = < 4 0 >; // 注：设备还可以使用多个中断号，假如此spi使用两个，则：interrupts = <0 4 0>, <1 5 0>; }; external-bus { #address-cells = <2> #size-cells = <1>; ranges = <0 0 0x10100000 0x10000 // Chipselect 0, Ethernet 1 0 0x10160000 0x10000 // Chipselect 1, i2c controller 2 0 0x30000000 0x10000000>; // Chipselect 2, NOR Flash ethernet@0,0 { compatible = "smc,smc91c111"; reg = <0 0 0x1000>; interrupts = < 5 2 >; }; i2c@1,0 { compatible = "acme,a1234-i2c-bus"; #address-cells = <1>; #size-cells = <0>; reg = <1 0 0x1000>; interrupts = < 6 2 >; rtc@58 { compatible = "maxim,ds1338"; reg = <58>; interrupts = < 7 3 >; }; }; flash@2,0 { compatible = "samsung,k8f1315ebm", "cfi-flash"; reg = <2 0 0x10000000>; }; }; };
|
另， 关于cell含义在内核中的相关文档有详细描述，比如arm gic 中断：
1
| # Documentation/devicetree/bindings/arm/gic.txt The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI interrupts. The 2nd cell contains the interrupt number for the interrupt type. SPI interrupts are in the range [0-987]. PPI interrupts are in the range [0-15]. The 3rd cell is the flags, encoded as follows: bits[3:0] trigger type and level flags. 1 = low-to-high edge triggered 2 = high-to-low edge triggered 4 = active high level-sensitive 8 = active low level-sensitive bits[15:8] PPI interrupt cpu mask. Each bit corresponds to each of the 8 possible cpus attached to the GIC. A bit set to '1' indicated the interrupt is wired to that CPU. Only valid for PPI interrupts.
|
除了上面讲的常用属性，任意需要的属性和子节点都可以被加入到设备树，不过新device-specific属性应将制造商名作为前缀命名，以避免与标准的属性冲突；
其实还有一些要求，不过主要针对内核开发者的，而我还没有那个水平，就没详细看了
aliases节点
一个specific节点通常以完全路径的形式引用，如：/external-bus/ethernet@0,0 ， 但是这样太复杂了，不利于阅读。所以通常会用以一个短的别名命名的aliases节点去指定设备的完全路径，如下：
1
| aliases { ethernet0 = ð0; serial0 = &serial0; };
|
注：property = &Label 不同于如上中断phandle引用的phandle = <&Lable>
chosen节点
chosen节点不指明真实的设备，其为硬件和操作系统数据传输服务，如：启动参数。通常chosen节点在dts源文件中写为空，在启动时再填充，在例中增加如下：
1
| chosen { bootargs = "root=/dev/nfs rw nfsroot=192.168.1.1 console=ttyS0,115200"; };
|
DTC (device tree compiler)
DTC将.dts编译为.dtb的工具。DTC的源代码位于内核的scripts/dtc目录，在Linux内核使能了Device Tree的情况下，编译内核的时候主机工具dtc会被编译出来，对应scripts/dtc/Makefile中的“hostprogs-y := dtc”。
在Linux内核的arch/arm/boot/dts/Makefile中，描述了当某种SoC被选中后，哪些.dtb文件会被编译出来，如与VEXPRESS对应的.dtb包括：
1 2 3 4 5
| dtb-$(CONFIG_ARCH_VEXPRESS) += vexpress-v2p-ca5s.dtb \ vexpress-v2p-ca9.dtb \ vexpress-v2p-ca15-tc1.dtb \ vexpress-v2p-ca15_a7.dtb \ xenvm-4.2.dtb
|
在Linux下，我们可以通过make dtbs命令单独编译Device Tree文件。因为arch/arm/Makefile中含有一个dtbs编译target，如下：
1 2 3 4
| # Build the DT binary blobs if we have OF configured ifeq ($(CONFIG_USE_OF),y) KBUILD_DTBS := dtbs endif
|
Device Tree Blob (dtb)
dtb是dts被DTC编译后生成的二进制格式Device Tree描述，可由Linux内核解析。系统设计时通常会单独留下一个很小的flash空间存放.dtb文件，bootloader在引导kernel的过程中，会先读取该.dtb到内存。
Binding
对于Device Tree中的结点和属性具体是如何来描述设备的硬件细节的，内核里有相应的文档，位于：Documentation/devicetree/bindings目录，其下又分为很多子目录。
注：此部分基本完全摘自参考文档
在Linux的BSP和驱动代码中，解析dts的API通常被以“of_”作为前缀，它们的实现代码位于内核的drivers/of目录。接下来就介绍一下常用的API。
int of_device_is_compatible(const struct device_node device,const char compat);
判断设备结点的compatible 属性是否包含compat指定的字符串。当一个驱动支持2个或多个设备的时候，这些不同.dts文件中设备的compatible 属性都会进入驱动 OF匹配表。因此驱动可以透过Bootloader传递给内核的Device Tree中的真正结点的compatible 属性以确定究竟是哪一种设备，从而根据不同的设备类型进行不同的处理。如drivers/pinctrl/pinctrl-sirf.c即兼容于”sirf,prima2-pinctrl”，又兼容于”sirf,prima2-pinctrl”，在驱动中就有相应分支处理：
1 2 3 4
| if (of_device_is_compatible(np, "sirf,marco-pinctrl")) is_marco = 1; struct device_node *of_find_compatible_node(struct device_node *from, const char *type, const char *compatible);
|
根据compatible属性，获得设备结点。遍历Device Tree中所有的设备结点，看看哪个结点的类型、compatible属性与本函数的输入参数匹配，大多数情况下，from、type为NULL。
int of_property_read_u8_array(const struct device_node np, const char propname, u8 out_values, size_t sz);
int of_property_read_u16_array(const struct device_node np, const char propname, u16 out_values, size_t sz);
int of_property_read_u32_array(const struct device_node np, const char propname, u32 out_values, size_t sz);
int of_property_read_u64(const struct device_node np, const char propname, u64 out_value);
读取设备结点np的属性名为propname，类型为8、16、32、64位整型数组的属性。对于32位处理器来讲，最常用的是of_property_read_u32_array()。如在arch/arm/mm/cache-l2x0.c中，透过如下语句读取L2 cache的”arm,data-latency”属性：
1 2
| of_property_read_u32_array(np, "arm,data-latency", data, ARRAY_SIZE(data));
|
在arch/arm/boot/dts/vexpress-v2p-ca9.dts中，含有”arm,data-latency”属性的L2 cache结点如下：
1 2 3 4 5 6 7 8
| L2: cache-controller@1e00a000 { compatible = "arm,pl310-cache"; reg = <0x1e00a000 0x1000>; interrupts = <0 43 4>; cache-level = <2>; arm,data-latency = <1 1 1>; arm,tag-latency = <1 1 1>; }
|
有些情况下，整形属性的长度可能为1，于是内核为了方便调用者，又在上述API的基础上封装出了更加简单的读单一整形属性的API，它们为int of_property_read_u8()、of_property_read_u16()等，实现于include/linux/of.h：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
| static inline int of_property_read_u8(const struct device_node *np, const char *propname, u8 *out_value) { return of_property_read_u8_array(np, propname, out_value, 1); } static inline int of_property_read_u16(const struct device_node *np, const char *propname, u16 *out_value) { return of_property_read_u16_array(np, propname, out_value, 1); } static inline int of_property_read_u32(const struct device_node *np, const char *propname, u32 *out_value) { return of_property_read_u32_array(np, propname, out_value, 1); }
|
int of_property_read_string(struct device_node np, const char propname, const char out_string);
int of_property_read_string_index(struct device_node np, const char propname, int index, const char output);
前者读取字符串属性，后者读取字符串数组属性中的第index个字符串。如drivers/clk/clk.c中的of_clk_get_parent_name()透过of_property_read_string_index()遍历clkspec结点的所有”clock-output-names”字符串数组属性。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
| const char *of_clk_get_parent_name(struct device_node *np, int index) { struct of_phandle_args clkspec; const char *clk_name; int rc; if (index < 0) return NULL; rc = of_parse_phandle_with_args(np, "clocks", "#clock-cells", index, &clkspec); if (rc) return NULL; if (of_property_read_string_index(clkspec.np, "clock-output-names", clkspec.args_count ? clkspec.args[0] : 0, &clk_name) < 0) clk_name = clkspec.np->name; of_node_put(clkspec.np); return clk_name; } EXPORT_SYMBOL_GPL(of_clk_get_parent_name);
|
static inline bool of_property_read_bool(const struct device_node np, const char propname);
如果设备结点np含有propname属性，则返回true，否则返回false。一般用于检查空属性是否存在。
void __iomem of_iomap(struct device_node node, int index);
通过设备结点直接进行设备内存区间的 ioremap()，index是内存段的索引。若设备结点的reg属性有多段，可通过index标示要ioremap的是哪一段，只有1段的情况，index为0。采用Device Tree后，大量的设备驱动通过of_iomap()进行映射，而不再通过传统的ioremap。
unsigned int irq_of_parse_and_map(struct device_node *dev, int index);
透过Device Tree或者设备的中断号，实际上是从.dts中的interrupts属性解析出中断号。若设备使用了多个中断，index指定中断的索引号。
还有一些OF API，这里不一一列举，具体可参考include/linux/of.h头文件。
AndroidBoard.mk
Android编译过程（如想了解更多可参考：Android编译过程详解）中会解析到device\qcom\msm8916_32\AndroidBoard.mk，此文件中选择了kernel的默认配置文件，如下：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
| # device\qcom\msm8916_32\AndroidBoard.mk #---------------------------------------------------------------------- # Compile (L)ittle (K)ernel bootloader and the nandwrite utility #---------------------------------------------------------------------- ifneq ($(strip $(TARGET_NO_BOOTLOADER)),true) # Compile include bootable/bootloader/lk/AndroidBoot.mk $(INSTALLED_BOOTLOADER_MODULE): $(TARGET_EMMC_BOOTLOADER) | $(ACP) $(transform-prebuilt-to-target) $(BUILT_TARGET_FILES_PACKAGE): $(INSTALLED_BOOTLOADER_MODULE) droidcore: $(INSTALLED_BOOTLOADER_MODULE) endif #---------------------------------------------------------------------- # Compile Linux Kernel #---------------------------------------------------------------------- ifeq ($(KERNEL_DEFCONFIG),) KERNEL_DEFCONFIG := msm8916_defconfig //选择msm8916_defconfig文件为默认配置文件 endif include kernel/AndroidKernel.mk $(INSTALLED_KERNEL_TARGET): $(TARGET_PREBUILT_KERNEL) | $(ACP) $(transform-prebuilt-to-target)
|
msm8916_defconfig
此文件中主要是一些编译开关，包括dts文件的编译开关，如下：
1 2 3 4 5
| # kernel\arch\arm\configs\msm8916_defconfig ... CONFIG_ARCH_MSM=y CONFIG_ARCH_MSM8916=y // dts文件的编译开关，当然也在其他地方用到，如加载板级文件：obj-$(CONFIG_ARCH_MSM8916) += board-8916.o ...
|
Makefile
dts文件目录的mk文件决定需要加载哪些dts文件，这些文件最终打包到dt.img，再经由mkbootimg工具和其他镜像一起打包到boot.img。关键源码如下：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
| # kernel\arch\arm\boot\dts\qcom\Makefile ... // 我们的代码针对每一个项目新建了一个dts文件，然后通过此文件去include了相关dts文件，所以下面都被屏蔽掉了 dtb-$(CONFIG_ARCH_MSM8916) += msm8916-qrd-skuh-$(OEM_PROJECT_NAME).dtb #msm8916-sim.dtb #msm8916-rumi.dtb #msm8916-cdp.dtb #msm8916-cdp-smb1360.dtb #msm8916-mtp.dtb #msm8916-512mb-mtp.dtb #msm8916-mtp-smb1360.dtb #msm8916-512mb-mtp-smb1360.dtb #msm8916-512mb-qrd-skui.dtb #msm8916-qrd-skuh.dtb #msm8916-qrd-skuhf.dtb #msm8916-qrd-skui.dtb #msm8916-512mb-qrd-skuh.dtb #msm8939-sim.dtb #msm8939-rumi.dtb #msm8939-qrd-skuk.dtb #msm8939-cdp.dtb #msm8939-cdp-smb1360.dtb #msm8939-mtp.dtb #msm8939-mtp-smb1360.dtb ...
|
msm8916-cdp.dts文件中定义平台信息，如下：
1
| # kernel\arch\arm\boot\dts\qcom\msm8916-cdp.dts #include "msm8916-cdp.dtsi" #include "msm8916-memory.dtsi" / { model = "Qualcomm Technologies, Inc. MSM 8916 CDP"; compatible = "qcom,msm8916-cdp", "qcom,msm8916", "qcom,cdp"; qcom,board-id = <1 0>; }; ...
|
不过我们在每个项目的dts文件中重新定义了平台信息，如下：
1
| # kernel\arch\arm\boot\dts\qcom\msm8916-qrd-skuh-$(OEM_PROJECT_NAME).dts #include "msm8916-qrd-skuh.dtsi" #include "msm8916-memory.dtsi" / { model = "Qualcomm Technologies, Inc. MSM 8916 QRD SKUH changcheng l783"; compatible = "qcom,msm8916-qrd-skuh", "qcom,msm8916-qrd", "qcom,msm8916", "qcom,qrd"; qcom,board-id = <0x1000b 0> , <0x1000b 4>; }; ...
|
Reference
我的这篇博文只是写了一些基本的东西，主要参考下面这些文档，并且很多内容直接翻译自下面的文档，如果想了解更多请查阅如下引用文档：
kernel\Documentation\devicetree：源码中的文档，很有参考价值，其实需要的基本能在里面找到，我已上传至百度云，可以click下载查看
http://devicetree.org/Device_Tree_Usage ：很多内容译自此处
Power_ePAPR_APPROVED_v1.0.pdf：进阶文档，因为官网总是不能成功访问，所以在我百度网盘存了一份，分享给大家
http://blog.csdn.net/21cnbao/article/details/8457546
