dtb文件上篇博客中已经分析过了，接下来分析一些特殊情况，将dts文件编译成dtb文件之后再用fdtdump反编译出来，对比两个文件看看有什么差异。

　　用指令fdtdump test.dtb > dump.txt 将test.dtb文件反编译成test.txt文件，fdtdump指令可以加参数的，可以输入fdtdump –h查看支持的参数，如输入fdtdump -sd test.dtb > dump.txt的话生成的dump.txt文件中就会包含很多调试信息。

　　接下来通过一些案例，对比源文件和反编译后的文件，来了解一些特殊情况是怎么编译的：

　　注：反编译后的文件包含了文件头信息，为了方便查看，

案例一

原文件：

1 /dts-v1/;
2 / {
3     property = [01 02 03 04];
4 };

 

反编译文件：

1 /dts-v1/;
2 / {
3     property = <0x01020304>;
4 };

 

分析：

原先的property = [01 02 03 04];变成了property = <0x01020304>;其实是一样的。

 

案例二

原文件：

1 /dts-v1/;
2 / {
3     property = <&label>;
4     
5     label: node {
6     
7     };
8 };

 

反编译文件（偷个懒，在之后的反编译文件中去掉了/des-v1/这一行）：

1 / {
2     property = <0x00000001>;
3     node {
4         linux,phandle = <0x00000001>;
5         phandle = <0x00000001>;
6     };
7 };

 

分析：

如果属性值中某一项用尖括号包含了，其值引用了某个节点，那么其值变成了一个32位数，被引用的节点会多出linux,phandle和phandle两个属性，这两个属性的值是两个相同的32位数，这个数和引用它的数是相等的。

 

案例三

原文件：

复制代码
 1 /dts-v1/;
 2 / {
 3 
 4     property = <&label1>;
 5     property2 = <&label2>;
 6     property3 = <&label1>;
 7 
 8     label1: node {
 9     
10     };
11     
12     label2: node2 {
13     
14     };
15 };
复制代码

 

反编译文件：

复制代码
 1 / {
 2     property = <0x00000001>;
 3     property2 = <0x00000002>;
 4     property3 = <0x00000001>;
 5     node {
 6         linux,phandle = <0x00000001>;
 7         phandle = <0x00000001>;
 8     };
 9     node2 {
10         linux,phandle = <0x00000002>;
11         phandle = <0x00000002>;
12     };
13 };
复制代码

 

分析：

不同的被引用的节点phandle值会从1开始递增，引用相同的节点其phandle值相等。

 

案例四

原文件：

复制代码
 1 /dts-v1/;
 2 / {
 3 
 4     property = <1>;
 5     property2 = <&label>;
 6 
 7     label: node {
 8     
 9     };
10 };
复制代码

 

反编译文件：

1 / {
2     property = <0x00000001>;
3     property2 = <0x00000001>;
4     node {
5         linux,phandle = <0x00000001>;
6         phandle = <0x00000001>;
7     };
8 };

 

分析：

这个案例中，property的值就设定为1，property2的值引用了node节点，我以为生成的phandle值会避开1这个值，结果竟然还是1，那这样property和property2两个属性不就没法区分了吗，将原文件改为如下：

复制代码
 1 /dts-v1/;
 2 / {
 3 
 4     property = <&label>;
 5     property2 = <&label>;
 6 
 7     label: node {
 8     
 9     };
10 };
复制代码

反编译出来的文件与 property = <1>;的文件一样，那这样就有问题了呀，内核怎么区分这个属性值是一个引用还是这就是它的值呢？

 

案例五

原文件：

复制代码
 1 /dts-v1/;
 2 / {
 3 
 4     property = &grandson;
 5     label: node {
 6         child-node {
 7             grandson: grandson-node {
 8             
 9             };
10         };
11     };
12 };
复制代码

 

反编译文件：

复制代码
1 / {
2     property = "/node/child-node/grandson-node";
3     node {
4         child-node {
5             grandson-node {
6             };
7         };
8     };
9 };
复制代码

 

分析：

如果某个属性的值直接就引用某个节点（不带尖括号），那么相当于传入的属性值是一个字符串，这个字符串表示的是被引用的节点的路径

 

案例六

原文件：

1 /dts-v1/;
2 / {
3 
4     property = <&label 1 2>;
5     label: node {
6 
7     };
8 };

 

反编译文件：

1 / {
2     property = <0x00000001 0x6e6f6465 0x00000009>;
3     node {
4         linux,phandle = <0x00000001>;
5         phandle = <0x00000001>;
6     };
7 };

 

分析：

这个结果可真是把我吓坏了，我赶紧用winhex打开dtb文件，一看：

 

见选中处，发现并没有什么问题，这么说那就是fdtdump工具有问题了，又经过几次测试发现当属性的值是一个32位数组（尖括号里面不止一个数）的时候，fdtfump工具就会出问题。

 

 

案例七

原文件：

复制代码
 1 /dts-v1/;
 2 / {
 3 
 4     property = <1>;
 5     property2 = <2>;
 6     label: node {
 7 
 8     };
 9 };
10 
11 / {
12     property2 = "hello";
13     property3 = <3>;
14 };
复制代码

 

反编译文件：

1 / {
2     property = <0x00000001>;
3     property2 = "hello";
4     property3 = <0x00000003>;
5     node {
6     };
7 };

 

分析：

后面写的根节点可以认为是对前面根节点的解释或修改，不同的属性会直接加进去，相同的属性会被重写。同样的也可以对其他节点进行重写，但是一定要在最外层路径上用引用的方式重写，下面列出一些错误的重写方式：

1. 同一节点下有两个相同的子节点

复制代码
 1 /dts-v1/;
 2 / {
 3     node {
 4 
 5     };
 6     
 7     node {
 8     
 9     };
10 };
复制代码

2. 引用没放在最外层

复制代码
 1 /dts-v1/;
 2 / {
 3     label:node {
 4 
 5     };
 6     
 7     &label {
 8         property = "hello";
 9     };
10 };
复制代码

 

下面这种写法才是合法的：

复制代码
 1 /dts-v1/;
 2 / {
 3     label:node {
 4 
 5     };
 6 };
 7 
 8 &label {
 9     property = "hello";
10 };
复制代码

 

反编译结果：

1 / {
2     node {
3         property = "hello";
4     };
5 };

 

案例八

原文件：

1 /dts-v1/;
2 / {
3     node@0 {
4 
5     };
6 };

 

二进制文件：

 

 节点名带地址的形式编译器并没有将节点名和地址分开处理，而是将它们当成一个整体算作节点名（当这并不意味着节点名加地址没用）。

另外还发现一个现象，就是FDT_NOP这个标签从来都没有出现过。是不是说正常编译器编译的文件中不会带有这个标志。

 

到这里基本上设备树文件已经算是吃透了，唯一不解的地方就是案例四，接下来要进内核分析一下内核是怎么做的了。