高通平台Android源码分析之Linux内核设备树(DT - Device Tree)
刚开始接触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组成及用法
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中的基本元素
dts中的基本元素为节点和属性，节点可以包含属性和子节点，属性为name-value键值对，如下：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
/ {
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 2 3 |
/ {
compatible = "acme,coyotes-revenge";
};
|
compatible指定系统的名字，格式： compatible = “< manufacturer>,< model>”（制造商，型号）。它非常重要，用来精确指定设备，并通过包含manufacurer(制造商)名字来避免冲突。因为操作系统通过compatible的值来决定machine怎么运行，所以使用正确的值是非常重要的。
理论上来说，compatible是操作系统所有数据标示machine的唯一标示符，os将通过顶层compatible寻找相应的值。
###CPUs
第二步，描述CPU的”cpus”节点，其包含每一个CPU描述信息的子节点，在这个例子中，CPU为一个双核的arm cortex A9处理器，所以其描述如下：
1 2 3 4 5 6 7 8 9 10 11 12 |
/ {
compatible = "acme,coyotes-revenge";
cpus {
cpu@0 {
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 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 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 |
/ {
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 = |
#####CPU寻址
CPU节点寻址是寻址里面最简单的，每个CPU被一个独一无二的ID标记，没有size与CPU ids关联。如下：
1 2 3 4 5 6 7 8 9 10 11 12 |
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 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 29 30 31 32 33 34 35 36 |
/ {
#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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
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 2 3 4 5 6 7 8 9 10 |
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 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 29 30 31 32 33 34 35 36 37 38 39 40 41 |
/ {
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 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 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 |
/ {
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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
# 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 2 3 4 |
aliases {
ethernet0 = ð0;
serial0 = &serial0;
};
|
注：property = &Label 不同于如上中断phandle引用的phandle = <&Lable>
####chosen节点
chosen节点不指明真实的设备，其为硬件和操作系统数据传输服务，如：启动参数。通常chosen节点在dts源文件中写为空，在启动时再填充，在例中增加如下：
1 2 3 |
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目录，其下又分为很多子目录。
##dts解析API
注：此部分基本完全摘自参考文档
在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头文件。
##高通Android源码中dts文件
###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 ... |
###dts中的platform info
msm8916-cdp.dts文件中定义平台信息，如下：
1 2 3 4 5 6 7 8 9 10 |
# 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 2 3 4 5 6 7 8 9 10 |
# 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>;
};
... |