ARM Linux 3.x的設備樹（Device Tree）【轉】

分類： Linux Driver開發 Linux Kernel開發 2013-01-01 17:32 1043人閱讀評論(5) 收藏 舉報

1. ARM Device Tree起源

Linus Torvalds在2011年3月17日的ARM Linux郵件列表宣稱“this whole ARM thing is a f*cking pain in the ass”，引發ARM Linux社區的地震，隨後ARM社區進行了一系列的重大修正。在過去的ARM Linux中，arch/arm/plat-xxx和arch/arm/mach-xxx中充斥着大量的垃圾代碼，相當多數的代碼只是在描述板級細節，而這些板級細節對於內核來講，不過是垃圾，如板上的platform設備、resource、i2c_board_info、spi_board_info以及各種硬件的platform_data。讀者有興趣可以統計下常見的s3c2410、s3c6410等板級目錄，代碼量在數萬行。
社區必須改變這種局面，於是PowerPC等其他體系架構下已經使用的Flattened Device Tree（FDT）進入ARM社區的視野。Device Tree是一種描述硬件的數據結構，它起源於 OpenFirmware (OF)。在Linux 2.6中，ARM架構的板極硬件細節過多地被硬編碼在arch/arm/plat-xxx和arch/arm/mach-xxx，採用Device Tree後，許多硬件的細節可以直接透過它傳遞給Linux，而不再需要在kernel中進行大量的冗餘編碼。
Device Tree由一系列被命名的結點（node）和屬性（property）組成，而結點本身可包含子結點。所謂屬性，其實就是成對出現的name和value。在Device Tree中，可描述的信息包括（原先這些信息大多被hard code到kernel中）：

CPU的數量和類別
內存基地址和大小
總線和橋
外設連接
中斷控制器和中斷使用情況
GPIO控制器和GPIO使用情況
Clock控制器和Clock使用情況

它基本上就是畫一棵電路板上CPU、總線、設備組成的樹，Bootloader會將這棵樹傳遞給內核，然後內核可以識別這棵樹，並根據它展開出Linux內核中的platform_device、i2c_client、spi_device等設備，而這些設備用到的內存、IRQ等資源，也被傳遞給了內核，內核會將這些資源綁定給展開的相應的設備。

2. Device Tree組成和結構

整個Device Tree牽涉面比較廣，即增加了新的用於描述設備硬件信息的文本格式，又增加了編譯這一文本的工具，同時Bootloader也需要支持將編譯後的Device Tree傳遞給Linux內核。

DTS (device tree source)

.dts文件是一種ASCII 文本格式的Device Tree描述，此文本格式非常人性化，適合人類的閱讀習慣。基本上，在ARM Linux在，一個.dts文件對應一個ARM的machine，一般放置在內核的arch/arm/boot/dts/目錄。由於一個SoC可能對應多個machine（一個SoC可以對應多個產品和電路板），勢必這些.dts文件需包含許多共同的部分，Linux內核爲了簡化，把SoC公用的部分或者多個machine共同的部分一般提煉爲.dtsi，類似於C語言的頭文件。其他的machine對應的.dts就include這個.dtsi。譬如，對於VEXPRESS而言，vexpress-v2m.dtsi就被vexpress-v2p-ca9.dts所引用， vexpress-v2p-ca9.dts有如下一行：
/include/ "vexpress-v2m.dtsi"
當然，和C語言的頭文件類似，.dtsi也可以include其他的.dtsi，譬如幾乎所有的ARM SoC的.dtsi都引用了skeleton.dtsi。
.dts（或者其include的.dtsi）基本元素即爲前文所述的結點和屬性：

[plain] view plain copy print ?

/ {
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;
a-cell-property = <1 2 3 4>; /* each number (cell) is a uint32 */
child-node1 {
};
};
};

/ {
    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;
        a-cell-property = <1 2 3 4>; /* each number (cell) is a uint32 */
        child-node1 {
        };
    };
};

上述.dts文件並沒有什麼真實的用途，但它基本表徵了一個Device Tree源文件的結構：
1個root結點"/"；
root結點下面含一系列子結點，本例中爲"node1" 和 "node2"；
結點"node1"下又含有一系列子結點，本例中爲"child-node1" 和 "child-node2"；
各結點都有一系列屬性。這些屬性可能爲空，如" an-empty-property"；可能爲字符串，如"a-string-property"；可能爲字符串數組，如"a-string-list-property"；可能爲Cells（由u32整數組成），如"second-child-property"，可能爲二進制數，如"a-byte-data-property"。
下面以一個最簡單的machine爲例來看如何寫一個.dts文件。假設此machine的配置如下：
1個雙核ARM Cortex-A9 32位處理器；
ARM的local bus上的內存映射區域分佈了2個串口（分別位於0x101F1000 和 0x101F2000）、GPIO控制器（位於0x101F3000）、SPI控制器（位於0x10170000）、中斷控制器（位於0x10140000）和一個external bus橋；
External bus橋上又連接了SMC SMC91111 Ethernet（位於0x10100000）、I2C控制器（位於0x10160000）、64MB NOR Flash（位於0x30000000）；
External bus橋上連接的I2C控制器所對應的I2C總線上又連接了Maxim DS1338實時鐘（I2C地址爲0x58）。
其對應的.dts文件爲：

[plain] view plain copy print ?

/ {
compatible = "acme,coyotes-revenge";
#address-cells = <1>;
#size-cells = <1>;
interrupt-parent = <&intc>;
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>;
};
spi@10115000 {
compatible = "arm,pl022";
reg = <0x10115000 0x1000 >;
interrupts = < 4 0 >;
};
external-bus {
#address-cells = <2>
#size-cells = <1>;
ranges = <0 0 0x10100000 0x10000 // Chipselect 1, Ethernet
1 0 0x10160000 0x10000 // Chipselect 2, i2c controller
2 0 0x30000000 0x1000000>; // Chipselect 3, 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 0x4000000>;
};
};
};

/ {
    compatible = "acme,coyotes-revenge";
    #address-cells = <1>;
    #size-cells = <1>;
    interrupt-parent = <&intc>;

    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>;
    };

    spi@10115000 {
        compatible = "arm,pl022";
        reg = <0x10115000 0x1000 >;
        interrupts = < 4 0 >;
    };

    external-bus {
        #address-cells = <2>
        #size-cells = <1>;
        ranges = <0 0  0x10100000   0x10000     // Chipselect 1, Ethernet
                  1 0  0x10160000   0x10000     // Chipselect 2, i2c controller
                  2 0  0x30000000   0x1000000>; // Chipselect 3, 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 0x4000000>;
        };
    };
};

上述.dts文件中,root結點"/"的compatible 屬性compatible = "acme,coyotes-revenge";定義了系統的名稱，它的組織形式爲：<manufacturer>,<model>。Linux內核透過root結點"/"的compatible 屬性即可判斷它啓動的是什麼machine。
在.dts文件的每個設備，都有一個compatible 屬性，compatible屬性用戶驅動和設備的綁定。compatible 屬性是一個字符串的列表，列表中的第一個字符串表徵了結點代表的確切設備，形式爲"<manufacturer>,<model>"，其後的字符串表徵可兼容的其他設備。可以說前面的是特指，後面的則涵蓋更廣的範圍。如在arch/arm/boot/dts/vexpress-v2m.dtsi中的Flash結點：

[plain] view plain copy print ?

flash@0,00000000 {
compatible = "arm,vexpress-flash", "cfi-flash";
reg = <0 0x00000000 0x04000000>,
<1 0x00000000 0x04000000>;
bank-width = <4>;
};

flash@0,00000000 {
     compatible = "arm,vexpress-flash", "cfi-flash";
     reg = <0 0x00000000 0x04000000>,
     <1 0x00000000 0x04000000>;
     bank-width = <4>;
 };

compatible屬性的第2個字符串"cfi-flash"明顯比第1個字符串"arm,vexpress-flash"涵蓋的範圍更廣。
再比如，Freescale MPC8349 SoC含一個串口設備，它實現了國家半導體（National Semiconductor）的ns16550 寄存器接口。則MPC8349串口設備的compatible屬性爲compatible = "fsl,mpc8349-uart", "ns16550"。其中，fsl,mpc8349-uart指代了確切的設備， ns16550代表該設備與National Semiconductor 的16550 UART保持了寄存器兼容。
接下來root結點"/"的cpus子結點下面又包含2個cpu子結點，描述了此machine上的2個CPU，並且二者的compatible 屬性爲"arm,cortex-a9"。
注意cpus和cpus的2個cpu子結點的命名，它們遵循的組織形式爲：<name>[@<unit-address>]，<>中的內容是必選項，[]中的則爲可選項。name是一個ASCII字符串，用於描述結點對應的設備類型，如3com Ethernet適配器對應的結點name宜爲ethernet，而不是3com509。如果一個結點描述的設備有地址，則應該給出@unit-address。多個相同類型設備結點的name可以一樣，只要unit-address不同即可，如本例中含有cpu@0、cpu@1以及serial@101f0000與serial@101f2000這樣的同名結點。設備的unit-address地址也經常在其對應結點的reg屬性中給出。ePAPR標準給出了結點命名的規範。
可尋址的設備使用如下信息來在Device Tree中編碼地址信息：

reg
#address-cells
#size-cells

其中reg的組織形式爲reg = <address1 length1 [address2 length2] [address3 length3] ... >，其中的每一組address length表明了設備使用的一個地址範圍。address爲1個或多個32位的整型（即cell），而length則爲cell的列表或者爲空（若#size-cells = 0）。address 和 length 字段是可變長的，父結點的#address-cells和#size-cells分別決定了子結點的reg屬性的address和length字段的長度。在本例中，root結點的#address-cells = <1>;和#size-cells = <1>;決定了serial、gpio、spi等結點的address和length字段的長度分別爲1。cpus 結點的#address-cells = <1>;和#size-cells = <0>;決定了2個cpu子結點的address爲1，而length爲空，於是形成了2個cpu的reg = <0>;和reg = <1>;。external-bus結點的#address-cells = <2>和#size-cells = <1>;決定了其下的ethernet、i2c、flash的reg字段形如reg = <0 0 0x1000>;、reg = <1 0 0x1000>;和reg = <2 0 0x4000000>;。其中，address字段長度爲0，開始的第一個cell（0、1、2）是對應的片選，第2個cell（0，0，0）是相對該片選的基地址，第3個cell（0x1000、0x1000、0x4000000）爲length。特別要留意的是i2c結點中定義的 #address-cells = <1>;和#size-cells = <0>;又作用到了I2C總線上連接的RTC，它的address字段爲0x58，是設備的I2C地址。
root結點的子結點描述的是CPU的視圖，因此root子結點的address區域就直接位於CPU的memory區域。但是，經過總線橋後的address往往需要經過轉換才能對應的CPU的memory映射。external-bus的ranges屬性定義了經過external-bus橋後的地址範圍如何映射到CPU的memory區域。

[plain] view plain copy print ?

ranges = <0 0 0x10100000 0x10000 // Chipselect 1, Ethernet
1 0 0x10160000 0x10000 // Chipselect 2, i2c controller
2 0 0x30000000 0x1000000>; // Chipselect 3, NOR Flash

        ranges = <0 0  0x10100000   0x10000     // Chipselect 1, Ethernet
                  1 0  0x10160000   0x10000     // Chipselect 2, i2c controller
                  2 0  0x30000000   0x1000000>; // Chipselect 3, NOR Flash

ranges是地址轉換表，其中的每個項目是一個子地址、父地址以及在子地址空間的大小的映射。映射表中的子地址、父地址分別採用子地址空間的#address-cells和父地址空間的#address-cells大小。對於本例而言，子地址空間的#address-cells爲2，父地址空間的#address-cells值爲1，因此0 0 0x10100000 0x10000的前2個cell爲external-bus後片選0上偏移0，第3個cell表示external-bus後片選0上偏移0的地址空間被映射到CPU的0x10100000位置，第4個cell表示映射的大小爲0x10000。ranges的後面2個項目的含義可以類推。
Device Tree中還可以中斷連接信息，對於中斷控制器而言，它提供如下屬性：
interrupt-controller – 這個屬性爲空，中斷控制器應該加上此屬性表明自己的身份；
#interrupt-cells – 與#address-cells 和 #size-cells相似，它表明連接此中斷控制器的設備的interrupts屬性的cell大小。
在整個Device Tree中，與中斷相關的屬性還包括：
interrupt-parent – 設備結點透過它來指定它所依附的中斷控制器的phandle，當結點沒有指定interrupt-parent 時，則從父級結點繼承。對於本例而言，root結點指定了interrupt-parent = <&intc>;其對應於intc: interrupt-controller@10140000，而root結點的子結點並未指定interrupt-parent，因此它們都繼承了intc，即位於0x10140000的中斷控制器。
interrupts – 用到了中斷的設備結點透過它指定中斷號、觸發方法等，具體這個屬性含有多少個cell，由它依附的中斷控制器結點的#interrupt-cells屬性決定。而具體每個cell又是什麼含義，一般由驅動的實現決定，而且也會在Device Tree的binding文檔中說明。譬如，對於ARM GIC中斷控制器而言，#interrupt-cells爲3，它3個cell的具體含義Documentation/devicetree/bindings/arm/gic.txt就有如下文字說明：

[plain] view plain copy print ?

01 The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
02 interrupts.
03
04 The 2nd cell contains the interrupt number for the interrupt type.
05 SPI interrupts are in the range [0-987]. PPI interrupts are in the
06 range [0-15].
07
08 The 3rd cell is the flags, encoded as follows:
09 bits[3:0] trigger type and level flags.
10 1 = low-to-high edge triggered
11 2 = high-to-low edge triggered
12 4 = active high level-sensitive
13 8 = active low level-sensitive
14 bits[15:8] PPI interrupt cpu mask. Each bit corresponds to each of
15 the 8 possible cpus attached to the GIC. A bit set to '1' indicated
16 the interrupt is wired to that CPU. Only valid for PPI interrupts.

01   The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
02   interrupts.
03
04   The 2nd cell contains the interrupt number for the interrupt type.
05   SPI interrupts are in the range [0-987].  PPI interrupts are in the
06   range [0-15].
07
08   The 3rd cell is the flags, encoded as follows:
09         bits[3:0] trigger type and level flags.
10                 1 = low-to-high edge triggered
11                 2 = high-to-low edge triggered
12                 4 = active high level-sensitive
13                 8 = active low level-sensitive
14         bits[15:8] PPI interrupt cpu mask.  Each bit corresponds to each of
15         the 8 possible cpus attached to the GIC.  A bit set to '1' indicated
16         the interrupt is wired to that CPU.  Only valid for PPI interrupts.

另外，值得注意的是，一個設備還可能用到多箇中斷號。對於ARM GIC而言，若某設備使用了SPI的168、169號2箇中斷，而言都是高電平觸發，則該設備結點的interrupts屬性可定義爲：interrupts = <0 168 4>, <0 169 4>;
除了中斷以外，在ARM Linux中clock、GPIO、pinmux都可以透過.dts中的結點和屬性進行描述。

DTC (device tree compiler)

將.dts編譯爲.dtb的工具。DTC的源代碼位於內核的scripts/dtc目錄，在Linux內核使能了Device Tree的情況下，編譯內核的時候主機工具dtc會被編譯出來，對應scripts/dtc/Makefile中的“hostprogs-y := dtc”這一hostprogs編譯target。
在Linux內核的arch/arm/boot/dts/Makefile中，描述了當某種SoC被選中後，哪些.dtb文件會被編譯出來，如與VEXPRESS對應的.dtb包括：

[plain] view plain copy print ?

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

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下，我們可以單獨編譯Device Tree文件。當我們在Linux內核下運行make dtbs時，若我們之前選擇了ARCH_VEXPRESS，上述.dtb都會由對應的.dts編譯出來。因爲arch/arm/Makefile中含有一個dtbs編譯target項目。

Device Tree Blob (.dtb)

.dtb是.dts被DTC編譯後的二進制格式的Device Tree描述，可由Linux內核解析。通常在我們爲電路板製作NAND、SD啓動image時，會爲.dtb文件單獨留下一個很小的區域以存放之，之後bootloader在引導kernel的過程中，會先讀取該.dtb到內存。

Binding

對於Device Tree中的結點和屬性具體是如何來描述設備的硬件細節的，一般需要文檔來進行講解，文檔的後綴名一般爲.txt。這些文檔位於內核的Documentation/devicetree/bindings目錄，其下又分爲很多子目錄。

Bootloader

Uboot mainline 從 v1.1.3開始支持Device Tree，其對ARM的支持則是和ARM內核支持Device Tree同期完成。
爲了使能Device Tree，需要編譯Uboot的時候在config文件中加入
#define CONFIG_OF_LIBFDT
在Uboot中，可以從NAND、SD或者TFTP等任意介質將.dtb讀入內存，假設.dtb放入的內存地址爲0x71000000，之後可在Uboot運行命令fdt addr命令設置.dtb的地址，如：
U-Boot> fdt addr 0x71000000
fdt的其他命令就變地可以使用，如fdt resize、fdt print等。
對於ARM來講，可以透過bootz kernel_addr initrd_address dtb_address的命令來啓動內核，即dtb_address作爲bootz或者bootm的最後一次參數，第一個參數爲內核映像的地址，第二個參數爲initrd的地址，若不存在initrd，可以用 -代替。

3. Device Tree引發的BSP和驅動變更

有了Device Tree後，大量的板級信息都不再需要，譬如過去經常在arch/arm/plat-xxx和arch/arm/mach-xxx實施的如下事情：
1. 註冊platform_device，綁定resource，即內存、IRQ等板級信息。

透過Device Tree後，形如

ARM Linux 3.x的設備樹（Device Tree）【轉】

分類： Linux Driver開發 Linux Kernel開發 2013-01-01 17:32 1043人閱讀 評論(5) 收藏 舉報

1. ARM Device Tree起源

2. Device Tree組成和結構

DTS (device tree source)

DTC (device tree compiler)

Device Tree Blob (.dtb)

Binding

Bootloader

3. Device Tree引發的BSP和驅動變更

4. 常用OF API

5. 總結

分類： Linux Driver開發 Linux Kernel開發 2013-01-01 17:32 1043人閱讀評論(5) 收藏舉報