服务器评测
概述
设备树(Device tree)是一套用来描述硬件属相的规则。ARM Linux采用设备树机制源于2011年3月份Linux创始人Linus Torvalds发的一封邮件，在这封邮件中他提倡ARM平台应该参考其他平台如PowerPC的设备树机制描述硬件。因为在此之前，ARM平台还是采用旧的机制，在kernel/arch/arm/plat-xxx目录和kernel/arch/arm/mach-xxx目录下用代码描述硬件，如注册platform设备，声明设备的resource等。因为这些代码都是用来描述芯片平台及板级差异的，所以对于内核来讲都是垃圾代码。因为嵌入式平台中很多公司的芯片采用的都是ARM架构，随着Android的成功，这些代码越来越多。据说常见的平台如s3c2410板级目录下边的代码有数万行，难怪Linux Torvalds会说“this whole ARM thing is a fucking pain in the ass”。
内核中关于设备树的文档位于kernel/Documentation/devicetree/目录。设备树是Power.org组织定义的一套规范，规范文档可以在官网上找到，目前最新的版本是https://www.power.org/documentation/epapr-version-1-1/。内核中设备树相关的函数都是以of开头的，我推测原因是设备树机制是源于IEEE 1275 Open Firmware standard规范的，相关的代码都是继承下来的。如果想快速了解下设备树怎么用，可以参考http://devicetree.org/Device_Tree_Usage。
设备树是从软件使用的角度描述硬件的，不是从硬件设计的角度描述的。我们在写设备树时没有必要按照硬件逻辑生搬硬套，也不要指望通过阅读设备树弄清楚硬件是如何设计的。对于软件可以自动识别的硬件，如USB设备，PCI设备，也是没有必要通过设备树描述的。
我个人觉得规范内容是可以分为两个层次的。第一层是关于设备树组织形式的，如设备树结构，节点名字的构成等，第一个层次是基础，是理解第二个层次的前提。第二层是关于设备树内容的，如多核CPU怎样描述，一个具体的设备如何描述。第二层可以看成是第一层的具体应用。相对来说第二层内容更多，更具体，根据描述的内容不同，定义规范的方式也有差别，比如关于CPU，内存，中断这些基础的内容，是在epapr中说明的，而关于外设的规范是在专门的地方说明的。
DTS(Device tree syntax，另一种说法是Device tree source)是设备树源文件，为了方便阅读及修改，采用文本格式。DTC(Device tree compiler)是一个小工具，负责将DTS转换成DTB(Device tree blob)。DTB是DTS的二进制形式，供机器使用。使用中，我们首先根据硬件修改DTS文件，然后在编译的时候通过DTC工具将DTS文件转换成DTB文件，然后将DTB文件烧写到机器上(如emmc，磁盘等存储介质)。系统启动时，fastboot(或者类似的启动程序，如Uboot)在启动内核前将DTB文件读到内存中，跳转到内核执行的同时将DTB起始地址传给内核。内核通过起始地址就可以根据DTB的结构解析整个设备树。说设备树的规范可以分成两个层次，是针对DTS的，关于DTB的结构不在此范围内。DTB仅仅是为了方便机器使用而对DTS的转换而已(也可以说DTS仅是为了方便人类使用而对DTB的一种描述)。
设备树首先是一个树形结构，并且是一棵树。除了根节点外其他子节点都有唯一的父节点，节点下可以有子节点和属性(子节点可以看成是树枝，属性可以看成是叶子)。属性由名字和值组成(名字是必须的，但是值不是必须的，如果只要根据是否存在这个属性就可以表示我们想要的功能，那么可以不需要有值)。
下边是我们从内核代码中截取的一个DTS片段。“/”表示根节点。“model = “Newflow AM335x NanoBone””是根节点下边的属性。“cpus”是根节点的一个子节点。“cpu0-supply = <&dcdc2_reg>”是“cpu@0”子节点下的属性。节点下的属性用来表示节点的特性，子节点和父节点具有一定的从属关系。真实的硬件不可能是这样规则的树形结构，所以设备树仅是软件开发人员为了描述硬件而做的一个近似表示而已，连抽象都算不上。
/ {
model = “Newflow AM335x NanoBone”;
compatible = “ti,am33xx”;
cpus {
cpu@0 {
cpu0-supply = <&dcdc2_reg>;
};
};
memory {
device_type = “memory”;
reg = <0x80000000 0x10000000>; /* 256 MB */
};
leds {
compatible = “gpio-leds”;
led@0 {
label = “nanobone:green:usr1”;
gpios = <&gpio1 5 0>;
default-state = “off”;
};
};
};
更多详情见请继续阅读下一页的精彩内容： http://www.linuxidc.com/Linux/2016-01/127337p2.htm
节点(node)的表示
首先说节点的表示方法，除了根节点只用一个斜杠“/”表示外，其他节点的表示形式如“node-name@unit-address”。@前边是节点名字，后边是节点地址。
节点名字的长度范围是1到31，可以使用的字符在ePAPR规范中有说明，包括：
0-9 数字
a-z 小写字母
A-Z 大写字母
, 逗号
. 句点(英)
_ 下划线
+ 加号
– 破折号(英)
规范要求节点名字应该以字母开头，虽然允许后边的位置使用非字母的字符，但实际情况我们实在没必要使用其他字符，一般情况全部用字母表示就够了。特别是规范建议在起名字时采用通用的名字而不是专有的名字，比如对于网卡，使用ethernet表示就可以了，可以通过地址区分不同的网卡，网卡的区别可以通过节点下的属性区分。还有就是关于目前存在的设备基本上都已经有被广泛接受的名字了，我们完全没必要在此标新立异，比如下边规范中列举的节点名字(经常写驱动的人基本一眼就能猜出是哪种设备)：
atm
cache-controller
compact-flash
can
cpu
crypto
disk
display
dma-controller
ethernet
ethernet-phy
fdc
flash
gpio
i2c
ide
interrupt-controller
isa
keyboard
mdio
memory
memory-controller
mouse
nvram
parallel
pc-card
pci
pcie
rtc
sata
scsi
serial
sound
spi
timer
usb
vme
watchdog
节点地址是用来区别同名节点的，不是软件意义上的地址，但是有些情况可以用软件地址作为这个地址。比如两个I2C控制器的名字可以都是i2c，然后用控制器寄存器首地址作为这个节点地址。对于cpu，因为它是没有寄存器地址的，就可以用核的号码作为地址，对于8核处理器，地址可以从0到7。ePAPR规范中关于节点地址的描述不太好理解，原文是“The unit-address component of the name is specific to the bus type on which the node sits”。其实我觉得这句话说的也不太准确，因为并不是所有节点表示的硬件都位于某个总线上，比如内存，cpu。设备树是软件对硬件的一种近似表示，软件需要他怎么表示，他就怎么表示。对于cpu，软件需要序号，那么地址就用序号，对于i2c控制器，软件需要寄存器首地址，那么就用地址。除此之外规范还要求，如果节点有地址，那么节点下边必须有一个叫reg的属性，并且该地址必须和reg的属性的第一个地址相同。如果节点没有reg属性，那么节点地址及前边的@必须都不能有。关于属性和值我们还没开始介绍，这里插一句，其实reg就是register的缩写，这个属性主要用来表示控制器寄存器首地址的。我觉得规范中这一条不是非常有必要，因为有些设备只要有一个地址就够了，那么放在节点地址中就够了，完全没必要非得再加个reg属性。在这一段的最后一句，规范来了句“The binding for a particular bus may specify additional, more specific requirements for the format of reg and the unit-address.”，我觉得这句话的意思和“设备树是软件对硬件的一种近似表示，软件需要他怎么表示，他就怎么表示”差不多，没有什么玄的。
节点路径也比较容易理解，从根节点到每个节点都可以形成一个路径，如第一节的例子/cpus/cpu@0，通过这个可以唯一的表示cpu@0这个节点。因为cpu@0在cpus下边是唯一的，但是在整个设备树可能不是唯一的，只有用全路径表示才能毫无异议的确认是哪个节点。如果省略了节点地址也不会产生歧义，那么可以省略不写。就像编程中的括号一样，个人觉得这个没必要省。
除了名字和地址外，节点前边还可以有一个标签(label)，这个标签不是必须的，一般只有在别个地方需要引用这个节点时才会用标签标示这个节点，因为如果用全路径太繁琐了。如“i2c_1: i2c@12C70000”中的i2c_1就是一个标签。
属性(property)
device_type = “memory”就是一个属性，等号前边是属性，后边是值。节点是一个逻辑上相对独立的实体，属性是用来描述节点特性的，根据需要一个节点由0个，1个或多个属性表示节点的特性。一个属性由名字和值两部分组成。
和节点的名字类似，规范要求属性名字由1到31个字符组成。和节点名字字符的种类有些区别，不允许有大写字母，增加了问号和井号两个字符。不清楚为什么没有和节点名字完全保持一致，井号对于初学者容易误解，以为是注释。
0-9 数字
a-z 小写字母
, 逗号
. 句点(英)
_ 下划线
+ 加号
– 破折号(英)
? 问号
# 井号
为了容易区分以及避免重复，标准未定义的属性名字应该用公司或组织名称开头，比如：
fsl,channel-fifo-len
ibm,ppc-interrupt-server#s
linux,network-index
属性的值在内存中由0个或多个字节存储。标准定义的基本类型包括：空，u32，u64，字符串，<prop-encoded-array>，字符数组6种。空前边我们已经提到，当不需要值就可以表示节点的特性时，属性的值可以为空。u32,u64,字符串，字符数组和c语言的定义没有区别，注意的是规范要求都是大端表示，字符串也是以0x00结尾。<prop-encoded-array>是一个结构体数组，数组的元素具体是什么根据属性的定义确定，后边我们讲到具体的属性时会详细说明。规范中还有一个类型的属性值，叫<phandle>，这个类型的属性在内存中存储时本质上是u32。
规范预定义了一些标准的属性。“compatible”，“model”,”device_type”都是用来表示节点基本信息的。
“compatible”属性是用来匹配驱动的，他的类型是字符串数组，每个字符串表示一种设备的类型，从具体到一般。举个例子就比较清楚了，比如某个串口控制器节点的属性”compatible = “fsl,mpc8641-uart”, “ns16550″“。第一个字符串“fsl,mpc8641-uart”前边部分是厂商(推测是frescale),后边部分是控制器具体型号，这个形式也是规范建议的标准写法。第二个字符串ns16550表示一类符合同一标准的串口控制器，比第一个字符串表示的范围更大。内核匹配驱动时首先看是否有匹配第一个字符串的驱动，如果没有的话再匹配第二个（如果有更多的，依次类推，所以优先匹配前边的）。
“model”属性用来表示设备的型号，用字符串表示，不像”compatible”用多个字符串，只需一个就够了。”device_type”属性用来表示设备类型，用字符串表示。
“#address-cells”,”#size-cells”,”reg”,”ranges”,”dma-ranges”属性都是和地址有关的。
不同的平台，不同的总线，地址位长度可能不同，有32位地址，有64位地址，为了适应这个，规范规定一个32位的长度为一个cell。”#address-cells”属性用来表示总线地址需要几个cell表示，该属性本身是u32类型的。”#size-cells”属性用来表示子总线地址空间的长度需要几个cell表示，属性本身的类型也是u32。可以这么理解父节点表示总线，总线上每个设备的地址长度以及地址范围是总线的一个特性，用”#address-cells”,”#size-cells”属性表示，比如总线是32位，那么”#address-cells”设置成1就可以了。这两个属性不可以继承，就是说在未定义这两个属性的时候，不会继承更高一级父节点的设置，如果没有设置的话，内核默认认为”#address-cells”为2，”#size-cells”为1。
“reg”属性用来表示节点地址资源的，比如常见的就是寄存器的起始地址及大小。要想表示一块连续地址，必须包含起始地址和空间大小两个参数，如果有多块地址，那么就需要多组这样的值表示。还记得前边说过的<prop-encoded-array>类型的属性吧，就是用来干这个的，他表示一个数组，每个元素的具体格式根据属性而定，对于’reg’属性，每个元素是一个二元组，包含起始地址和大小。还有另外一个问题，地址和大小用几个u32表示呢？这个就由父节点的”#address-cells”,”#size-cells”属性确定。
总线上设备在总线地址和总线本身的地址可能不同，”ranges”属性用来表示如何转换。和’reg’属性类似，’ranges’属性也是<prop-encoded-array>类型的属性，不同的是’ranges’属性的每个元素是三元组，按照前后顺序分别是(子总线地址，父总线地址，大小)。子总线地址需要几个u32表示由’ranges’属性所在节点的’#address-cells’属性决定，父总线地址需要几个u32表示由上一级节点的’#address-cells’属性决定，大小需要几个u32表示由当前节点的’#size-cells’属性确定。
‘dma-ranges’属性的结构和定义与’ranges’属性完全相同，唯一不同的是地址是dma使用的地址，’ranges’中的地址是cpu使用的地址。
有的时候在一个节点中需要引用另外一个节点，比如某个外设的中断连在哪个中断控制器上。在讲节点那一节我们说过，可以通过节点的全路径指定是哪个节点，但这种方法非常繁琐。’phandle’属性是专门为方便引用节点设计的，想要引用哪个节点就在该节点下边增加一个’phandle’属性，设定值为一个u32，如’phandle = <1>’，引用的地方直接使用数字1就可以引用该节点，如’interrupt-parent = <1>’。以上是规范中描述的方法，实际上这样也不方便，我在实际的代码中没有看到这么用的。还记得节点那节说过节点名字前边可以定义一个标签吧，实际情况是都用标签引用，比如节点标签为intc1，那么用’interrupt-parent = <&intc1>’就可以引用了。
‘status’属性用来表示节点的状态的，其实就是硬件的状态，用字符串表示。’okay’表示硬件正常工作，“disabled”表示硬件当前不可用，“fail”表示因为出错不可用，“fail-sss”表示因为某种原因出错不可用，sss表示具体的出错原因。实际中，基本只用’okay’和’disabled’。
中断
中断一般包括中断产生设备和中断处理设备。中断控制器负责处理中断，每一个中断都有对应的中断号及触发条件。中断产生设备可能有多个中断源，有时多个中断源对应中断控制器中的一个中断，这种情况中断产生设备的中断源称之为中断控制器中对应中断的子中断。一般情况中断产生设备数量要多于中断控制器，多个中断产生设备的中断都由一个中断控制器处理，这种多对一的关系也很像一个树形结构，所以在设备树中，中断也被描述成树，叫中断树。以下表述的时候为了明确是在说中断树，在父节点和子节点前边我们都加上“中断”二字，是为了防止和设备树的父节点、子节点混淆(虽然大部分情况设备树的父子关系就是中断树的父子关系，但是因为存在特例，所以我们还是强调是中断父子关系)。
中断产生设备用interrupts属性描述中断源(interrupt specifier)，因为不同的硬件描述中断源需要的数据量不同，所以interrupts属性的类型也是<prop-encoded-array>。为了明确表示一个中断由几个u32表示，又引入了#interrupt-cells属性，#interrupt-cells属性的类型是u32，假如一个中断源需要2个u32表示(一个表示中断号，另一个表示中断类型)，那么#interrupt-cells就设置成2。有些情况下，设备树的父节点不是中断的父节点(主要是中断控制器一般不是父节点)，为此引入了interrupt-parent属性，该属性的类型是<phandle>，用来引用中断父节点(我们前边说过，一般用父节点的标签，这个地方说中断父节点而不是中断控制器是有原因的)。如果设备树的父节点就是中断父节点，那么可以不用设置interrupt-parent属性。interrupts属性和interrupt-parent属性都是中断产生设备节点的属性，但是#interrupt-cells属性不是,#interrupt-cells属性是中断控制器节点以及interrupt nexus节点的属性，这两类节点都可能是中断父节点。
中断控制器节点用interrupt-controller属性表示自己是中断控制器，这个属性的类型是空，不用设置值，只要存在这个节点就表示该节点是中断控制器。除了这个属性外，中断控制器节点还有#interrupt-cells属性，用来表示该中断控制器直接管理下的interrupt domain(后边我们会讲中断控制器的中断子节点interrupt nexus节点有单独的interrupt domain)用几个u32表示一个中断源(interrupt specifier)。中断控制器节点就包括interrupt-controller和#interrupt-cells两个关于中断的属性。中断控制器的#address-cells属性和中断映射有关系，但是该属性不是为中断设计的，中断映射只是用到了这个属性而已。
前边说中断控制器中的一个中断可能对应中断产生设备中的多个中断源，那这种对应关系用什么描述呢？我们还说过#interrupt-celll属性不仅是中断控制器节点的属性，还是interrupt nexus节点的属性，这个interrupt nexus节点就是描述中断映射关系的，该节点通过interrupt-map，interrupt-map-mask属性描述中断映射关系。interrupt-map属性是<prop-encoded-array>类型的，每个元素表示一个中断映射关系(注意是一个”中断映射关系”，不是”一个中断”映射关系)，从前向后包括：中断子设备地址，中断子设备中断源(interrupt specifier)，中断父设备，中断父设备地址，中断父设备中断源(interrupt specifier)五部分。中断子设备地址具体由几个u32组成是由中断子设备所在总线(不是中断父设备)的#address-cells属性决定的，这个地方为什么用中断设备地址而不用中断设备的phandle，是有原因的，因为中断设备会用interrupt-parrent属性指向中断父节点，所以中断子设备是可以确定的，不需要说明。还因为中断子设备地址可以做与运算，通过interrupt-map-mask属性就可以实现多对一的映射。中断子设备中断源(interrupt specifier)由几个u32组成是由该interrupt nexus节点下的#interrupt-cell决定的。中断父设备是一个指向中断父设备的<phandle>属性，一般情况下是中断控制器，但是按照中断树的逻辑，也可能是更高一级的interrupt nexus节点。中断父设备地址具体由几个u32组成是由中断父设备节点下的#address-cells属性决定的(注意，不是中断父设备所在总线的#address-cells属性)。中断父设备中断源(interrupt specifier)由几个u32组成是由中断父设备的#interrupt-cells属性决定的。
还记得前边说过中断设备的中断源和中断控制器的中断源可能是多对一的关系，如果每个子中断都用interrupt-map中的一行表示，那么interrupt-map属性将非常大。为了让多个子中断共享映射关系，引入了interrupt-map-mask属性，该属性的类型也是<prop-enacoded-array>，包含中断子设备地址和中断子设备中断源的bit mask，给定一个子中断源，那么首先和interrupt-map-mask做与运算，运算结果再通过interrupt-map属性查找对应的中断父设备中断源。这就是我们前边为什么说interrupt-map属性的一行是一个“中断映射关系”，而不是“一个中断”映射关系的原因。
我们再来复习一下，整个中断树的最底层是中断产生设备(也可能是从interrupt nexus节点)，中断产生设备用interrupts属性描述他能产生的中断。因为他的中断父设备可能和设备树的父设备不同，那么用interrupt-parent属性指向他的中断父设备。他的中断父设备可能是中断控制器(如果中断产生设备的中断和中断控制器的中断是一一对应的，或者最底层是interrupt nexus节点)，也可能是interrupt nexus节点(如果最底层是中断产生设备，且需要映射)。interrupt nexus节点及他的所有直接子节点构成了一个interrupt domain，在该interrupt domain下中断源怎样表示由#interrupt-cells属性决定，如何由中断子设备中断源找到中断父设备中断源由interrupt-map和interrupt-map-mask属性决定。interrupt nexus的父节点可能还是一个interrupt nexus父节点，也可能是一个中断控制器，当向上找到最后一个中断控制器，并且该中断控制器再也没有中断父设备时，整个中断树就遍历完成了。中断控制器用interrupt-controller属性表示自己是中断控制器，并且用#interrupt-cells属性表示他所直接管理的interrupt domain用几个u32表示一个中断源。根据中断树的特性，一个设备树中是有可能有多个中断树的。
以上是中断在设备树中如何描述的规则，听起来是挺复杂的，但只要理解了就很简单，为了帮助理解我们举一个实际的例子。为了突出中断部分，我们做了简化。
/ {
model = “Marvell Armada 375 family SoC”;
compatible = “marvell,armada375”;
soc {
#address-cells = <2>;
#size-cells = <1>;
interrupt-parent = <&gic>;
internal-regs {
compatible = “simple-bus”;
#address-cells = <1>;
#size-cells = <1>;
timer@c600 {
compatible = “arm,cortex-a9-twd-timer”;
reg = <0xc600 0x20>;
interrupts = <GIC_PPI 13 (IRQ_TYPE_EDGE_RISING | GIC_CPU_MASK_SIMPLE(2))>;
clocks = <&coreclk 2>;
};
gic: interrupt-controller@d000 {
compatible = “arm,cortex-a9-gic”;
#interrupt-cells = <3>;
#address-cells = <0>;
interrupt-controller;
reg = <0xd000 0x1000>,
<0xc100 0x100>;
};
}
pcie-controller {
compatible = “marvell,armada-370-pcie”;
#address-cells = <3>;
#size-cells = <2>;
pcie@1,0 {
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0>;
interrupt-map = <0 0 0 0 &gic GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
};
};
}
首先我们看到timer@c600这个设备节点下定义了interrupts属性，这说明该设备可以产生中断，但是这个属性下描述了几个中断我们是看不出来的(如果有经验了，我们能猜出只是一个中断，现在我们按照规则确认)。因为该节点没有interrupt-parent属性，那么认为设备树的父节点internal-regs就是中断父节点，在internal-regs父节点下还是没有interrupt-parent属性，那么还是继续找设备树父节点，找到了soc，在该节点下边有interrupt-parent属性。该属性引用的标签为gic，搜索整个设备树，interrupt-controller@d000的标签为gic。gic节点下有interrupt-controller属性，说明他是一个中断控制器。gic节点还有属性#interrupt-cells = <3>，说明在该控制器的interrupt domain下，中断源(interrupt specifier)用3个u32表示，我们再看timer@c600下的interrupts属性也确实由3个u32组成(可以参考GIC的规范，第一个u32表示中断类型，第二个是中断号，第三个是中断触发条件)。这个例子说明如果中断产生设备的中断源和中断控制器的中断源是一一对应的，那么可以不需要interrupt nexus节点及相关的属性来表示中断映射。
再看pcie@1,0这个节点，有#interrupt-cells属性，但是没有interrupt-controller属性，这说明他是一个interrupt nexus节点。该节点的#interrupt-cells属性为1，说明该interrupt nexus节点管辖下的中断源用1个u32表示就可以了。在pcie@1,0节点下边没有子节点，且也没有节点的interrupt-parent属性指向pcie@1,0节点，所以从设备树上看不到该interrupt domain下的中断产生设备，可能的原因是这些中断产生设备软件可以动态识别所以不需要设备树描述。因为interrupt-map-mask属性是由中断产生设备的地址和中断源(interrupt specifier)组成，且中断源用1个u32表示，那么可以推测中断产生设备地址由3个u32组成。这里需要注意的是pcie@1,0节点的#address-cells属性为3，是说该总线下边的设备地址用3个u32表示，但并不代表中断产生设备的设备地址也一定3个u32表示，此处不能说是巧合，但是我们要清楚中断产生设备的地址由几个u32组成是由该设备所在总线决定的，对于pcie总线也确实是3，但是其他总线可能存在其他种的情况。现在我们来分析interrupt-map属性，前三个数字是中断设备地址，第四个数字是中断设备的中断源。因为interrupt-map-mask是全0，这样不管与什么数字做与运算结果都是0，interrupt-map属性的前4个数字也都是0，这说明在pcie@1,0下边所有的中断映射到中断父节点的中断都是一个中断。接着是指向gic的<phandle>，因为gic节点下#address-cells属性为0，所以后边不需要描述中断父设备的地址了，后边3个数字都是表示中断父设备中断源的。一句话描述就是pcie@1,0下的所有中断都映射到gic，GIC_SPI类型的第29号中断，触发类型为高电平触发。这个例子说明在中断树的最下边可以是interrupt nexus节点。
以上例子中断树的根是gic，gic下边有两个孩子，一个是中断设备timer@c600，一个是interrupt nexus节点pcie@1,0。gic直接管辖的interrupt domain用3个u32表示中断源，timer@c600在这个interrupt domain下。pcie@1,0下定义了一个新的interrupt domain，在该interrupt domain下，中断源用1个u32表示，pcie@1,0用interrupt-map和interrupt-map-mask属性将下边所有设备的中断映射到一个gic下边的中断上。
根节点
一个最简单的设备树必须包含根节点，cpus节点，memory节点。根节点的名字及全路径都是“/”，至少需要包含model和compatible两个属性。model属性我们在属性那节已经说过是用来描述产品型号的，类型为字符串，推荐的格式为“manufacturer,model-number”（非强制的）。根节点的model属性描述的是板子的型号或者芯片平台的型号，如：
model = “Atmel AT91SAM9G20 family SoC”
model = “Samsung SMDK5420 board based on EXYNOS5420”
从软件的层面讲model属性仅仅表示一个名字而已，没有更多的作用。compatible属性则不同，该属性决定软件如何匹配硬件对硬件进行初始化。属性那一节我们说过compatible属性的类型是字符串数组，按照范围从小到大的顺序排列，每个字符串表示一种匹配类型。根节点的compatible属性表示平台如何匹配，比如‘compatible = “samsung,smdk5420”, “samsung,exynos5420”, “samsung,exynos5″’，表示软件应该首先匹配’samsung,smdk5420’，这个是一款开发板。如果无法匹配，再试着匹配”samsung,exynos5420″，这个是一款芯片平台。如果还是无法匹配，还可以试着匹配 “samsung,exynos5″，这是一个系列的芯片平台。这里说的匹配是指软件根据该信息找到对应的代码，如对应的初始化函数。
根节点表示的是整个板子或者芯片平台，所以在系统初始化比较早的时候就需要确认是什么平台，怎样初始化。对于Linux，是通过在start_kernel函数调用setup_arch函数实现的。不同的架构，setup_arch函数的实现不同，对于arm架构，setup_arch函数源代码位于arch/arm/kernel/setup.c中。以下是该函数的部分源代码(代码来自内核版本4.4-rc7的官方版本，本节后边所有代码都来自该版本)。
935 void __init setup_arch(char **cmdline_p)
936 {
937 const struct machine_desc *mdesc;
938
939 setup_processor();
940 mdesc = setup_machine_fdt(__atags_pointer);
941 if (!mdesc)
942 mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);
943 machine_desc = mdesc;
944 machine_name = mdesc->name;
第940行setup_machine_fdt函数的输入是设备树(DTB)首地址，返回的mdesc是描述平台信息的结构体。还记得我们在概述那节说过启动程序如uboot把设备树读到内存中，然后在启动内核的同时将设备树首地址传给内核，此处__atags_pointer就是启动程序传给内核的设备树地址（此时内存中的设备树已经是DTB形式）。setup_machine_fdt中的fdt是flat device tree的缩写，fdt的意思是说设备树在内存中是在一块连续地址存储的，fdt和dtb说的都是同一个东西。setup_machine_tags是在设备树初始化失败的时候才调用的，所以不用管他。machine_desc和machine_name都是静态全局变量，用来保存指针方便后边引用的。为了更好的理解setup_machine_fdt具体实现了什么功能，我们首先看下machine_desc结构体。不同的架构，该结构体定义差别很大，arm架构源代码位于arch/arm/include/asm/mach/arch.h，复制如下：
27 struct machine_desc {
28 unsigned int nr; /* architecture number */
29 const char *name; /* architecture name */
30 unsigned long atag_offset; /* tagged list (relative) */
31 const char *const *dt_compat; /* array of device tree
32 * ‘compatible’ strings */
33
34 unsigned int nr_irqs; /* number of IRQs */
35
36 #ifdef CONFIG_ZONE_DMA
37 phys_addr_t dma_zone_size; /* size of DMA-able area */
38 #endif
39
40 unsigned int video_start; /* start of video RAM */
41 unsigned int video_end; /* end of video RAM */
42
43 unsigned char reserve_lp0 :1; /* never has lp0 */
44 unsigned char reserve_lp1 :1; /* never has lp1 */
45 unsigned char reserve_lp2 :1; /* never has lp2 */
46 enum reboot_mode reboot_mode; /* default restart mode */
47 unsigned l2c_aux_val; /* L2 cache aux value */
48 unsigned l2c_aux_mask; /* L2 cache aux mask */
49 void (*l2c_write_sec)(unsigned long, unsigned);
50 const struct smp_operations *smp; /* SMP operations */
51 bool (*smp_init)(void);
52 void (*fixup)(struct tag *, char **);
53 void (*dt_fixup)(void);
54 long long (*pv_fixup)(void);
55 void (*reserve)(void);/* reserve mem blocks */
56 void (*map_io)(void);/* IO mapping function */
57 void (*init_early)(void);
58 void (*init_irq)(void);
59 void (*init_time)(void);
60 void (*init_machine)(void);
61 void (*init_late)(void);
62 #ifdef CONFIG_MULTI_IRQ_HANDLER
63 void (*handle_irq)(struct pt_regs *);
64 #endif
65 void (*restart)(enum reboot_mode, const char *);
66 };
67
从以上结构体的注释可以看出，该结构体包含了非常多的信息。注意第31行的dt_compat变量，该变量就是用来匹配设备树的compatible属性的。
setup_machine_fdt函数的实现也是架构相关的，arm架构源代码位于arch/arm/kernel/devtree.c，复制代码如下：
203 /**
204 * setup_machine_fdt – Machine setup when an dtb was passed to the kernel
205 * @dt_phys: physical address of dt blob
206 *
207 * If a dtb was passed to the kernel in r2, then use it to choose the
208 * correct machine_desc and to setup the system.
209 */
210 const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
211 {
212 const struct machine_desc *mdesc, *mdesc_best = NULL;
213
214 #ifdef CONFIG_ARCH_MULTIPLATFORM
215 DT_MACHINE_START(GENERIC_DT, “Generic DT based system”)
216 MACHINE_END
217
218 mdesc_best = &__mach_desc_GENERIC_DT;
219 #endif
220
221 if (!dt_phys || !early_init_dt_verify(phys_to_virt(dt_phys)))
222 return NULL;
223
224 mdesc = of_flat_dt_match_machine(mdesc_best, arch_get_next_mach);
225
226 if (!mdesc) {
227 const char *prop;
228 int size;
229 unsigned long dt_root;
230
231 early_print(“\nError: unrecognized/unsupported “
232 “device tree compatible list:\n[ “);
233
234 dt_root = of_get_flat_dt_root();
235 prop = of_get_flat_dt_prop(dt_root, “compatible”, &size);
236 while (size > 0) {
237 early_print(“‘%s’ “, prop);
238 size -= strlen(prop) + 1;
239 prop += strlen(prop) + 1;
240 }
241 early_print(“]\n\n”);
242
243 dump_machine_table(); /* does not return */
244 }
245
246 /* We really don’t want to do this, but sometimes firmware provides buggy data */
247 if (mdesc->dt_fixup)
248 mdesc->dt_fixup();
249
250 early_init_dt_scan_nodes();
251
252 /* Change machine number to match the mdesc we’re using */
253 __machine_arch_type = mdesc->nr;
254
255 return mdesc;
256 }
第221行检查fdt指针是否为空并且调用early_init_dt_verify函数，该函数代码位于drivers/of/fdt.c，这个函数算是of模块(还记得么？是open firmware的缩写)的第一个函数，复制代码如下:
1060
1061 bool __init early_init_dt_verify(void *params)
1062 {
1063 if (!params)
1064 return false;
1065
1066 /* check device tree validity */
1067 if (fdt_check_header(params))
1068 return false;
1069
1070 /* Setup flat device-tree pointer */
1071 initial_boot_params = params;
1072 of_fdt_crc32 = crc32_be(~0, initial_boot_params,
1073 fdt_totalsize(initial_boot_params));
1074 return true;
1075 }
early_init_dt_verify首先检查fdt头部的合法性，然后设置fdt全局变量以及计算crc。这个initial_boot_params变量后边在访问设备树的时候还会用到。继续看前边第224行，of_flat_dt_match_machine函数算是of模块的第二个函数吧，在分析这个函数前，我们首先分析这个函数的第二个参数arch_get_next_mach，这是一个函数指针，arm架构的实现位于arch/arm/kernel/devtree.c，复制代码如下：
190 static const void * __init arch_get_next_mach(const char *const **match)
191 {
192 static const struct machine_desc *mdesc = __arch_info_begin;
193 const struct machine_desc *m = mdesc;
194
195 if (m >= __arch_info_end)
196 return NULL;
197
198 mdesc++;
199 *match = m->dt_compat;
200 return m;
201 }
这个函数很简单，注意的是mdesc是静态局部变量，第一次调用指向__arch_info_begin，后边每次调用都mdesc++,如果超过了__arch_info_end就返回NULL。以上代码说明在__arch_info_begin和__arch_info_end两个地址之间存储着多个machine_desc变量（也可能是一个），该函数遍历这些变量，通过match参数返回所有machine_desc结构体的dt_compat变量指针。问题是__arch_info_begin和__arch_info_end地址是怎么来的呢？在arch/arm/kernel/vmlinux.lds.S连接脚本中定义了.arch.info.init段，__arch_info_begin和__arch_info_end地址分别是该段的首尾地址。
188 .init.arch.info : {
189 __arch_info_begin = .;
190 *(.arch.info.init)
191 __arch_info_end = .;
192 }
那么.init.arch.info段的内容怎么来的呢？这就要参考DT_MACHINE_START和MACHINE_END宏了，arm架构的定义在arch/arm/include/asm/mach/arch.h文件，如下所示：
94 #define DT_MACHINE_START(_name, _namestr) \
95 static const struct machine_desc __mach_desc_##_name \
96 __used \
97 __attribute__((__section__(“.arch.info.init”))) = { \
98 .nr = ~0, \
99 .name = _namestr,
100
101 #endif
从该宏代码看出他定义了一个machine_desc类型的静态局部变量，该变量位于.arch.info.init段中。参考arch/arm/mach-exynos/exynos.c中如下代码，以下代码在.arch.info.init段定义了一个名字为__mach_desc_EXYNOS_DT，类型为machine_desc的静态局部变量，并且该变量的dt_compat字符串矩阵中有”samsung,exynos5420″的字符串。
277 static char const *const exynos_dt_compat[] __initconst = {
278 “samsung,exynos3”,
279 “samsung,exynos3250”,
280 “samsung,exynos4”,
281 “samsung,exynos4210”,
282 “samsung,exynos4212”,
283 “samsung,exynos4412”,
284 “samsung,exynos4415”,
285 “samsung,exynos5”,
286 “samsung,exynos5250”,
287 “samsung,exynos5260”,
288 “samsung,exynos5420”,
289 “samsung,exynos5440”,
290 NULL
291 };
319 DT_MACHINE_START(EXYNOS_DT, “SAMSUNG EXYNOS (Flattened Device Tree)”)
320 /* Maintainer: Thomas Abraham <thomas.abraham@linaro.org> */
321 /* Maintainer: Kukjin Kim <kgene.kim@samsung.com> */
322 .l2c_aux_val = 0x3c400001,
323 .l2c_aux_mask = 0xc20fffff,
324 .smp = smp_ops(exynos_smp_ops),
325 .map_io = exynos_init_io,
326 .init_early = exynos_firmware_init,
327 .init_irq = exynos_init_irq,
328 .init_machine = exynos_dt_machine_init,
329 .init_late = exynos_init_late,
330 .dt_compat = exynos_dt_compat,
331 .reserve = exynos_reserve,
332 .dt_fixup = exynos_dt_fixup,
333 MACHINE_END
我们已经知道了get_next_compat指针的具体实现了，现在继续看of_flat_dt_match_machine。从第732行开始的循环就是遍历.arch.info.init段中所有的dt_compat变量，然后通过of_flat_dt_match计算一个分数，并且寻找那个分数最小的。
713 /**
714 * of_flat_dt_match_machine – Iterate match tables to find matching machine.
715 *
716 * @default_match: A machine specific ptr to return in case of no match.
717 * @get_next_compat: callback function to return next compatible match table.
718 *
719 * Iterate through machine match tables to find the best match for the machine
720 * compatible string in the FDT.
721 */
722 const void * __init of_flat_dt_match_machine(const void *default_match,
723 const void * (*get_next_compat)(const char * const**))
724 {
725 const void *data = NULL;
726 const void *best_data = default_match;
727 const char *const *compat;
728 unsigned long dt_root;
729 unsigned int best_score = ~1, score = 0;
730
731 dt_root = of_get_flat_dt_root();
732 while ((data = get_next_compat(&compat))) {
733 score = of_flat_dt_match(dt_root, compat);
734 if (score > 0 && score < best_score) {
735 best_data = data;
736 best_score = score;
737 }
738 }
….
759 return best_data;
760 }
761
of_flat_dt_match_machine的其余部分代码都是出错处理及打印，现在我们看of_flat_dt_match的实现，该函数仅仅是直接调用of_fdt_match而已，不同的是增加了initial_boot_params参数（还记得我们说过前边说过的这个变量的初始化吧，其实这就是内核中的一个简单封装而已）。
685 /**
686 * of_flat_dt_match – Return true if node matches a list of compatible values
687 */
688 int __init of_flat_dt_match(unsigned long node, const char *const *compat)
689 {
690 return of_fdt_match(initial_boot_params, node, compat);
691 }
of_fdt_match函数从142行开始遍历compat数组的每一个字符串，然后通过of_fdt_is_compatible函数计算匹配度（以最小的数值作为最终的结果）。代码到这个地方已经很好理解了，compat中的数据来自内核的.arch.info.init段，这个段表示内核支持的平台，blob是设备树其实地址，通过node节点指定根节点的compatible属性，然后计算匹配度。还记得我们前边说过的compatible属性包含多个字符串，从前向后范围越来越大，优先匹配前边的，这个地方代码计算分数（score变量）就是这个目的。
131 /**
132 * of_fdt_match – Return true if node matches a list of compatible values
133 */
134 int of_fdt_match(const void *blob, unsigned long node,
135 const char *const *compat)
136 {
137 unsigned int tmp, score = 0;
138
139 if (!compat)
140 return 0;
141
142 while (*compat) {
143 tmp = of_fdt_is_compatible(blob, node, *compat);
144 if (tmp && (score == 0 || (tmp < score)))
145 score = tmp;
146 compat++;
147 }
148
149 return score;
150 }
继续看of_fdt_is_compatible函数的实现，第97行已经看到找该节点下的”compatible”属性了。
80 /**
81 * of_fdt_is_compatible – Return true if given node from the given blob has
82 * compat in its compatible list
83 * @blob: A device tree blob
84 * @node: node to test
85 * @compat: compatible string to compare with compatible list.
86 *
87 * On match, returns a non-zero value with smaller values returned for more
88 * specific compatible values.
89 */
90 int of_fdt_is_compatible(const void *blob,
91 unsigned long node, const char *compat)
92 {
93 const char *cp;
94 int cplen;
95 unsigned long l, score = 0;
96
97 cp = fdt_getprop(blob, node, “compatible”, &cplen);
98 if (cp == NULL)
99 return 0;
100 while (cplen > 0) {
101 score++;
102 if (of_compat_cmp(cp, compat, strlen(compat)) == 0)
103 return score;
104 l = strlen(cp) + 1;
105 cp += l;
106 cplen -= l;
107 }
108
109 return 0;
110 }
关于根节点的”compatible”属性我们就说到这，一句话总结下就是内核通过”compatible”属性找到对应的平台描述信息，按照范围从小到大尽量匹配范围最小的，如果匹配不到，那么说明内核不支持该平台，系统将在初始化的时候就出错。
根节点还可能包含的属性为#address-cells和#size-cells，规范中说明这两个属性是必须的，实际应用时是可选的，还记得属性那一节说这两个属性如果没有都是有默认值的，#address-cells默认值为2，#size-cells默认值为1。根节点下必须包含的子节点为cpus和memory，后边会说明cpus下边还有每个cpu的子节点，memory节点下边定义的就是memory的起始地址及大小，所以根节点的#address-cells和#size-cells属性实际上说明的就是从cpu角度看系统总线的地址长度和大小。
规范中还写根节点下边必须有一个epapr-version属性用来描述设备树的版本，实际上在linux中根本不用这个属性。
memory&chosen节点
根节点那一节我们说过，最简单的设备树也必须包含cpus节点和memory节点。memory节点用来描述硬件内存布局的。如果有多块内存，既可以通过多个memory节点表示，也可以通过一个memory节点的reg属性的多个元素支持。举一个例子，假如某个64位的系统有两块内存，分别是
• RAM: 起始地址 0x0, 长度 0x80000000 (2GB)
• RAM: 起始地址 0x100000000, 长度 0x100000000 (4GB)
对于64位的系统，根节点的#address-cells属性和#size-cells属性都设置成2。一个memory节点的形式如下(还记得前几节说过节点地址必须和reg属性第一个地址相同的事情吧)：
memory@0 {
device_type = “memory”;
reg = <0x000000000 0x00000000 0x00000000 0x80000000
0x000000001 0x00000000 0x00000001 0x00000000>;
};
两个memory节点的形式如下：
memory@0 {
device_type = “memory”;
reg = <0x000000000 0x00000000 0x00000000 0x80000000>;
};
memory@100000000 {
device_type = “memory”;
reg = <0x000000001 0x00000000 0x00000001 0x00000000>;
};
chosen节点也位于根节点下，该节点用来给内核传递参数（不代表实际硬件）。对于Linux内核，该节点下最有用的属性是bootargs，该属性的类型是字符串，用来向Linux内核传递cmdline。规范中还定义了stdout-path和stdin-path两个可选的、字符串类型的属性，这两个属性的目的是用来指定标准输入输出设备的，在linux中，这两个属性基本不用。
memory和chosen节点在内核初始化的代码都位于start_kernel()->setup_arch()->setup_machine_fdt()->early_init_dt_scan_nodes()函数中（位于drivers/of/fdt.c），复制代码如下(本节所有代码都来自官方内核4.4-rc7版本)：
1078 void __init early_init_dt_scan_nodes(void)
1079 {
1080 /* Retrieve various information from the /chosen node */
1081 of_scan_flat_dt(early_init_dt_scan_chosen, boot_command_line);
1082
1083 /* Initialize {size,address}-cells info */
1084 of_scan_flat_dt(early_init_dt_scan_root, NULL);
1085
1086 /* Setup memory, calling early_init_dt_add_memory_arch */
1087 of_scan_flat_dt(early_init_dt_scan_memory, NULL);
1088 }
of_scan_flat_dt函数扫描整个设备树，实际的动作是在回调函数中完成的。第1081行是对chosen节点操作，该行代码的作用是将节点下的bootargs属性的字符串拷贝到boot_command_line指向的内存中。boot_command_line是内核的一个全局变量，在内核的多处都会用到。第1084行是根据根节点的#address-cells属性和#size-cells属性初始化全局变量dt_root_size_cells和dt_root_addr_cells，还记得前边说过如果没有设置属性的话就用默认值，这些都在early_init_dt_scan_root函数中实现。第1087行是对内存进行初始化，复制early_init_dt_scan_memory部分代码如下：
893 /**
894 * early_init_dt_scan_memory – Look for an parse memory nodes
895 */
896 int __init early_init_dt_scan_memory(unsigned long node, const char *uname,
897 int depth, void *data)
898 {
899 const char *type = of_get_flat_dt_prop(node, “device_type”, NULL);
900 const __be32 *reg, *endp;
901 int l;
902
903 /* We are scanning “memory” nodes only */
904 if (type == NULL) {
905 /*
906 * The longtrail doesn’t have a device_type on the
907 * /memory node, so look for the node called /memory@0.
908 */
909 if (!IS_ENABLED(CONFIG_PPC32) || depth != 1 || strcmp(uname, “memory@0”) != 0)
910 return 0;
911 } else if (strcmp(type, “memory”) != 0)
912 return 0;
913
914 reg = of_get_flat_dt_prop(node, “linux,usable-memory”, &l);
915 if (reg == NULL)
916 reg = of_get_flat_dt_prop(node, “reg”, &l);
917 if (reg == NULL)
918 return 0;
919
920 endp = reg + (l / sizeof(__be32));
921
922 pr_debug(“memory scan node %s, reg size %d,\n”, uname, l);
923
924 while ((endp – reg) >= (dt_root_addr_cells + dt_root_size_cells)) {
925 u64 base, size;
926
927 base = dt_mem_next_cell(dt_root_addr_cells, ®);
928 size = dt_mem_next_cell(dt_root_size_cells, ®);
929
930 if (size == 0)
931 continue;
932 pr_debug(” – %llx , %llx\n”, (unsigned long long)base,
933 (unsigned long long)size);
934
935 early_init_dt_add_memory_arch(base, size);
936 }
937
938 return 0;
939 }
第914行可以看出linux内核不仅支持reg属性，也支持linux,usable-memory属性。对于dt_root_addr_cells和dt_root_size_cells的使用也能看出根节点的#address-cells属性和#size-cells属性都是用来描述内存地址和大小的。得到每块内存的起始地址和大小后，在第935行调用early_init_dt_add_memory_arch函数，复制代码如下：
983 void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
984 {
985 const u64 phys_offset = __pa(PAGE_OFFSET);
986
987 if (!PAGE_ALIGNED(base)) {
988 if (size < PAGE_SIZE – (base & ~PAGE_MASK)) {
989 pr_warn(“Ignoring memory block 0x%llx – 0x%llx\n”,
990 base, base + size);
991 return;
992 }
993 size -= PAGE_SIZE – (base & ~PAGE_MASK);
994 base = PAGE_ALIGN(base);
995 }
996 size &= PAGE_MASK;
997
998 if (base > MAX_MEMBLOCK_ADDR) {
999 pr_warning(“Ignoring memory block 0x%llx – 0x%llx\n”,
1000 base, base + size);
1001 return;
1002 }
1003
1004 if (base + size – 1 > MAX_MEMBLOCK_ADDR) {
1005 pr_warning(“Ignoring memory range 0x%llx – 0x%llx\n”,
1006 ((u64)MAX_MEMBLOCK_ADDR) + 1, base + size);
1007 size = MAX_MEMBLOCK_ADDR – base + 1;
1008 }
1009
1010 if (base + size < phys_offset) {
1011 pr_warning(“Ignoring memory block 0x%llx – 0x%llx\n”,
1012 base, base + size);
1013 return;
1014 }
1015 if (base < phys_offset) {
1016 pr_warning(“Ignoring memory range 0x%llx – 0x%llx\n”,
1015 if (base < phys_offset) {
1016 pr_warning(“Ignoring memory range 0x%llx – 0x%llx\n”,
1017 base, phys_offset);
1018 size -= phys_offset – base;
1019 base = phys_offset;
1020 }
1021 memblock_add(base, size);
1022 }
从以上代码可以看出内核对地址和大小做了一系列判断后，最后调用memblock_add将内存块加入内核。
本文永久更新链接地址：http://www.linuxidc.com/Linux/2016-01/127337.htm
