1、裝置樹的概念

        在核心原始碼中，存在大量對板級細節資訊描述的程式碼。這些程式碼充斥在/arch/arm/plat-xxx和/arch/arm/mach-xxx目錄，對核心而言這些platform裝置、resource、i2c_board_info、spi_board_info以及各種硬體的platform_data絕大多數純屬垃圾冗餘程式碼。為了解決這一問題，ARM核心版本3.x之後引入了原先在Power PC等其他體系架構已經使用的Flattened Device Tree。

        開源文件中對裝置樹的描述是，一種描述硬體資源的資料結構，它通過bootloader將硬體資源傳給核心，使得核心和硬體資源描述相對獨立。

         Device Tree可以描述的資訊包括CPU的數量和類別、記憶體基地址和大小、匯流排和橋、外設連線、中斷控制器和中斷使用情況、GPIO控制器和GPIO使用情況、Clock控制器和Clock使用情況。

         另外，裝置樹對於可熱插拔的裝置不進行具體描述，它只描述用於控制該熱插拔裝置的控制器。

         裝置樹的主要優勢：對於同一SOC的不同主機板，只需更換裝置樹檔案.dtb即可實現不同主機板的無差異支援，而無需更換核心檔案。

（注：要使得3.x之後的核心支援使用裝置樹，除了核心編譯時需要開啟相對應的選項外，bootloader也需要支援將裝置樹的資料結構傳給核心

2、裝置樹的組成和使用

        裝置樹包含DTC（device tree compiler），DTS（device tree source和DTB（device tree blob）。其對應關係如下圖所示：

2.1 DTS和DTSI(原始檔)

        .dts檔案是一種ASCII文字對Device Tree的描述，放置在核心的/arch/arm/boot/dts目錄。一般而言，一個.dts檔案對應一個ARM的machine。

         由於一個SOC可能有多個不同的電路板（  .dts檔案為板級定義， .dtsi檔案為SoC級定義），而每個電路板擁有一個 .dts。這些dts勢必會存在許多共同部分，為了減少程式碼的冗餘，裝置樹將這些共同部分提煉儲存在.dtsi檔案中，供不同的dts共同使用

2.2 DTC (編譯工具)

        DTC為編譯工具，dtc編譯器可以把dts檔案編譯成為dtb，也可把dtb編譯成為dts檔案。在3.x核心版本中，DTC的原始碼位於核心的scripts/dtc目錄，核心選中CONFIG_OF，編譯核心的時候，主機可執行程式DTC就會被編譯出來。 即scripts/dtc/Makefile中

1. hostprogs-y := dtc
2. always := $(hostprogs-y) ​

        在核心的arch/arm/boot/dts/Makefile中，若選中某種SOC，則與其對應相關的所有dtb檔案都將編譯出來。在linux下，make dtbs可單獨編譯dtb。以下截取了TEGRA平臺的一部分。

1. ifeq ($(CONFIG_OF),y)
2. dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
3. tegra30-beaver.dtb \
4. tegra114-dalmore.dtb \
5. tegra124-ardbeg.dtb ​

2.3 DTB (二進位制檔案)

       DTC編譯.dts生成的二進位制檔案（.dtb），bootloader在引導核心時，會預先讀取.dtb到記憶體，進而由核心解析。

        在2.6.x版本核心中，在powerpc架構下，dtb檔案可以單獨進行編譯，編譯命令格式如下：

dtc [-I input-format] [-O output-format][-o output-filename] [-V output_version] input_filename

引數說明

input-format：

- “dtb”: “blob” format

- “dts”: “source” format.

- “fs” format.

output-format：

- “dtb”: “blob” format

- “dts”: “source” format

- “asm”: assembly language file

output_version：

定義”blob”的版本，在dtb檔案的欄位中有表示，支援1　2　3和16,預設是3,在16版本上有許多特性改變

(1)  Dts編譯生成dtb

./dtc -I dts -O dtb -o B_dtb.dtb A_dts.dts

把A_dts.dts編譯生成B_dtb.dtb

(2)  Dtb編譯生成dts

./dtc -I dtb -O dts -o A_dts.dts A_dtb.dtb

把A_dtb.dtb反編譯生成為A_dts.dts

        在linux 3.x核心中，可以使用make的方式進行編譯。

2.4 Bootloader(boottloader支援)

    Bootloader需要將裝置樹在記憶體中的地址傳給核心。在ARM中通過bootm或bootz命令來進行傳遞。    

    bootm [kernel_addr] [initrd_address] [dtb_address]，其中kernel_addr為核心映象的地址，initrd為initrd的地址，dtb_address為dtb所在的地址。若initrd_address為空，則用“-”來代替。

3、linux核心對硬體的描述方式

       在以前的核心版本中：
1）核心包含了對硬體的全部描述；
2）bootloader會載入一個二進位制的核心映象，並執行它，比如uImage或者zImage；
3）bootloader會提供一些額外的資訊，成為ATAGS，它的地址會通過r2暫存器傳給核心；
    ATAGS包含了記憶體大小和地址，kernel command line等等；
4）bootloader會告訴核心載入哪一款board，通過r1暫存器存放的machine type integer；
5）U-Boot的核心啟動命令：bootm <kernel img addr>
6）Barebox變數：bootm.image (?)


現今的核心版本使用了Device Tree：
1）核心不再包含對硬體的描述，它以二進位制的形式單獨儲存在另外的位置：the device tree blob
2）bootloader需要載入兩個二進位制檔案：核心映象和DTB
    核心映象仍然是uImage或者zImage；
    DTB檔案在arch/arm/boot/dts中，每一個board對應一個dts檔案；
3）bootloader通過r2暫存器來傳遞DTB地址，通過修改DTB可以修改記憶體資訊，kernel command line，以及潛在的其它資訊；
4）不再有machine type；
5）U-Boot的核心啟動命令：bootm <kernel img addr> - <dtb addr>
6）Barebox變數：bootm.image,bootm.oftree


        有些bootloader不支援Device Tree，或者有些專門給特定裝置寫的版本太老了，也不包含。為了解決這個問題，CONFIG_ARM_APPENDED_DTB被引進。 
    它告訴核心，在緊跟著核心的地址裡查詢DTB檔案；
    由於沒有built-in Makefile rule來產生這樣的核心，因此需要手動操作：
        cat arch/arm/boot/zImage arch/arm/boot/dts/myboard.dtb > my-zImage
        mkimage ... -d my-zImage my-uImage
    (cat這個命令，還能夠直接合並兩個mp3檔案哦！so easy！)
另外，CONFIG_ARM_ATAG_DTB_COMPAT選項告訴核心去bootloader裡面讀取ATAGS，並使用它們升級DT。

4、DTB載入及解析過程

    先從uboot裡的do_bootm出發，根據之前描述，DTB在記憶體中的地址通過bootm命令進行傳遞。在bootm中，它會根據所傳進來的DTB地址，對DTB所在記憶體做一系列操作，為核心解析DTB提供保證。上圖為對應的函式呼叫關係圖。

    在do_bootm中，主要呼叫函式為do_bootm_states，第四個引數為bootm所要處理的階段和狀態。 

    在do_bootm_states中，bootm_start會對lmb進行初始化操作，lmb所管理的實體記憶體塊有三種方式獲取。起始地址，優先順序從上往下：

1.  環境變數“bootm_low”
2.  巨集CONFIG_SYS_SDRAM_BASE（在tegra124中為0x80000000）
3.  gd->bd->bi_dram[0].start

大小：

1.  環境變數“bootm_size”
2.  gd->bd->bi_dram[0].size

    經過初始化之後，這塊記憶體就歸lmb所管轄。接著，呼叫bootm_find_os進行kernel映象的相關操作，這裡不具體闡述。

    還記得之前講過bootm的三個引數麼，第一個引數核心地址已經被bootm_find_os處理，而接下來的兩個引數會在bootm_find_other中執行操作。

    首先，bootm_find_other根據第二個引數找到ramdisk的地址，得到ramdisk的映象；然後根據第三個引數得到DTB映象，同檢查kernel和ramdisk映象一樣，檢查DTB映象也會進行一系列的校驗工作，如果校驗錯誤，將無法正常啟動核心。另外，uboot在確認DTB映象無誤之後，會將該地址儲存在環境變數“fdtaddr”中。

    接著，uboot會把DTB映象reload一次，使得DTB映象所在的實體記憶體歸lmb所管理：    

• ①boot_fdt_add_mem_rsv_regions會將原先的記憶體DTB映象所在的記憶體置為reserve，保證該段記憶體不會被其他非法使用，保證接下來的reload資料是正確的；
• ②boot_relocate_fdt會在bootmap區域中申請一塊未被使用的記憶體，接著將DTB映象內容複製到這塊區域（即歸lmb所管理的區域）

注：若環境變數中，指定“fdt_high”引數，則會根據該值，呼叫lmb_alloc_base函式來分配DTB映象reload的地址空間。若分配失敗，則會停止bootm操作。因而，不建議設定fdt_high引數。

    接下來，do_bootm會根據核心的型別呼叫對應的啟動函式。與linux對應的是do_bootm_linux。

• ① boot_prep_linux

        為啟動後的kernel準備引數

• ② boot_jump_linux

    以上是boot_jump_linux的片段程式碼，可以看出：若使用DTB，則原先用來儲存ATAG的暫存器R2，將會用來儲存.dtb映象地址。

    boot_jump_linux最後將呼叫kernel_entry，將.dtb映象地址傳給核心。

    下面我們來看下核心的處理部分：

    在arch/arm/kernel/head.S中，有這樣一段：

    _vet_atags定義在/arch/arm/kernel/head-common.S中，它主要對DTB映象做了一個簡單的校驗。

    真正解析處理dbt的開始部分，是setup_arch->setup_machine_fdt。這部分的處理在第五部分的machine_mdesc中有提及。

    如圖，是setup_machine_fdt中的解析過程。

•     解析chosen節點將對boot_command_line進行初始化。
•     解析根節點的{size，address}將對dt_root_size_cells，dt_root_addr_cells進行初始化。為之後解析memory等其他節點提供依據。
•     解析memory節點，將會把節點中描述的記憶體，加入memory的bank。為之後的記憶體初始化提供條件。

•     解析裝置樹在函式unflatten_device_tree中完成，它將.dtb解析成device_node結構（第五部分有其定義），並構成單項鍊表，以供OF的API介面使用。

下面主要結合程式碼分析：/drivers/of/fdt.c

總的歸納為：

    ① kernel入口處獲取到uboot傳過來的.dtb映象的基地址

    ② 通過early_init_dt_scan()函式來獲取kernel初始化時需要的bootargs和cmd_line等系統引導引數。

    ③ 呼叫unflatten_device_tree函式來解析dtb檔案，構建一個由device_node結構連線而成的單向連結串列，並使用全域性變數of_allnodes儲存這個連結串列的頭指標。

    ④ 核心呼叫OF的API介面，獲取of_allnodes連結串列資訊來初始化核心其他子系統、裝置等。