Linux設備樹語法詳解

概念

Linux內核從3.x開始引入設備樹的概念,用於實現驅動代碼與設備信息相分離。在設備樹出現以前,所有關於設備的具體信息都要寫在驅動裏,一旦外圍設備變化,驅動代碼就要重寫。引入了設備樹之後,驅動代碼只負責處理驅動的邏輯,而關於設備的具體信息存放到設備樹文件中,這樣,如果只是硬件接口信息的變化而沒有驅動邏輯的變化,驅動開發者只需要修改設備樹文件信息,不需要改寫驅動代碼。比如在ARM Linux內,一個.dts(device tree source)文件對應一個ARM的machine,一般放置在內核的"arch/arm/boot/dts/"目錄內,比如exynos4412參考板的板級設備樹文件就是"arch/arm/boot/dts/exynos4412-origen.dts"。這個文件可以通過$make dtbs命令編譯成二進制的.dtb文件供內核驅動使用。

基於同樣的軟件分層設計的思想,由於一個SoC可能對應多個machine,如果每個machine的設備樹都寫成一個完全獨立的.dts文件,那麼勢必相當一些.dts文件有重複的部分,爲了解決這個問題,Linux設備樹目錄把一個SoC公用的部分或者多個machine共同的部分提煉爲相應的.dtsi文件。這樣每個.dts就只有自己差異的部分,公有的部分只需要"include"相應的.dtsi文件, 這樣就是整個設備樹的管理更加有序。我這裏用`Linux4.8.5源碼自帶的dm9000網卡爲例來分析設備樹的使用和移植。這個網卡的設備樹節點信息在"Documentation/devicetree/bindings/net/davicom-dm9000.txt"有詳細說明,其網卡驅動源碼是"drivers/net/ethernet/davicom/dm9000.c"

設備樹框架

設備樹用樹狀結構描述設備信息,它有以下幾種特性

  1. 每個設備樹文件都有一個根節點,每個設備都是一個節點。
  2. 節點間可以嵌套,形成父子關係,這樣就可以方便的描述設備間的關係。
  3. 每個設備的屬性都用一組key-value對(鍵值對)來描述。
  4. 每個屬性的描述用;結束

所以,一個設備樹的基本框架可以寫成下面這個樣子,一般來說,/表示板子,它的子節點node1表示SoC上的某個控制器,控制器中的子節點node2表示掛接在這個控制器上的設備(們)

/{                                  //根節點
    node1{                          //node1是節點名,是/的子節點
        key=value;                  //node1的屬性
        ...
        node2{                      //node2是node1的子節點
            key=value;              //node2的屬性
            ...
        }
    }                               //node1的描述到此爲止
    node3{
        key=value;
        ...
    }
}

節點名

理論個節點名只要是長度不超過31個字符的ASCII字符串即可,此外
Linux內核還約定設備名應寫成形如<name>[@<unit_address>]的形式,其中name就是設備名,最長可以是31個字符長度。unit_address一般是設備地址,用來唯一標識一個節點,下面就是典型節點名的寫法

上面的節點名是firmware,節點路徑是/firmware@0203f000,這點要注意,因爲根據節點名查找節點的API的參數是不能有"@xxx"這部分的

Linux中的設備樹還包括幾個特殊的節點,比如chosen,chosen節點不描述一個真實設備,而是用於firmware傳遞一些數據給OS,比如bootloader傳遞內核啓動參數給內核

引用

當我們找一個節點的時候,我們必須書寫完整的節點路徑,這樣當一個節點嵌套比較深的時候就不是很方便,所以,設備樹允許我們用下面的形式爲節點標註引用(起別名),藉以省去冗長的路徑。這樣就可以實現類似函數調用的效果。編譯設備樹的時候,相同的節點的不同屬性信息都會被合併,相同節點的相同的屬性會被重寫,使用引用可以避免移植者四處找節點,直接在板級.dts增改即可。

下面的例子中就是直接引用了dtsi中的一個節點,並向其中添加/修改新的屬性信息

KEY

在設備樹中,鍵值對是描述屬性的方式,比如,Linux驅動中可以通過設備節點中的"compatible"這個屬性查找設備節點。
Linux設備樹語法中定義了一些具有規範意義的屬性,包括:compatibleaddressinterrupt等,這些信息能夠在內核初始化找到節點的時候,自動解析生成相應的設備信息。此外,還有一些Linux內核定義好的,一類設備通用的有默認意義的屬性,這些屬性一般不能被內核自動解析生成相應的設備信息,但是內核已經編寫的相應的解析提取函數,常見的有 "mac_addr""gpio""clock""power""regulator" 等等。

compatible

設備節點中對應的節點信息已經被內核構造成struct platform_device。驅動可以通過相應的函數從中提取信息。compatible屬性是用來查找節點的方法之一,另外還可以通過節點名或節點路徑查找指定節點。dm9000驅動中就是使用下面這個函數通過設備節點中的"compatible"屬性提取相應的信息,所以二者的字符串需要嚴格匹配。
在下面的這個dm9000的例子中,我們在相應的板級dts中找到了這樣的代碼塊:

然後我們取內核源碼中找到dm9000的網卡驅動,從中可以發現這個驅動是使用的設備樹描述的設備信息(這不廢話麼,顯然用設備樹好處多多)。我們可以找到它用來描述設備信息的結構體,可以看出,驅動中用於匹配的結構使用的compatible和設備樹中一模一樣,否則就可能無法匹配,這裏另外的一點是struct of_device_id數組的最後一個成員一定是空,因爲相關的操作API會讀取這個數組直到遇到一個

address

(幾乎)所有的設備都需要與CPU的IO口相連,所以其IO端口信息就需要在設備節點節點中說明。常用的屬性有

  • #address-cells,用來描述子節點"reg"屬性的地址表中用來描述首地址的cell的數量
  • #size-cells,用來描述子節點"reg"屬性的地址表中用來描述地址長度的cell的數量

有了這兩個屬性,子節點中的"reg"就可以描述一塊連續的地址區域。下例中,父節點中指定了#address-cells = <2>;#size-cells = <1>,則子節點dev-bootscs0中的reg中的前兩個數表示一個地址,即MBUS_ID(0xf0, 0x01)0x1045C,最後一個數的表示地址跨度,即是0x4

interrupts

一個計算機系統中大量設備都是通過中斷請求CPU服務的,所以設備節點中就需要在指定中斷號。常用的屬性有

  • interrupt-controller 一個空屬性用來聲明這個node接收中斷信號,即這個node是一箇中斷控制器。
  • #interrupt-cells,是中斷控制器節點的屬性,用來標識這個控制器需要幾個單位做中斷描述符,用來描述子節點中"interrupts"屬性使用了父節點中的interrupts屬性的具體的哪個值。一般,如果父節點的該屬性的值是3,則子節點的interrupts一個cell的三個32bits整數值分別爲:<中斷域 中斷 觸發方式>,如果父節點的該屬性是2,則是<中斷 觸發方式>
  • interrupt-parent,標識此設備節點屬於哪一個中斷控制器,如果沒有設置這個屬性,會自動依附父節點的
  • interrupts,一箇中斷標識符列表,表示每一箇中斷輸出信號

設備樹中中斷的部分涉及的部分比較多,interrupt-controller表示這個節點是一箇中斷控制器,需要注意的是,一個SoC中可能有不止一箇中斷控制器,這就會涉及到設備樹中斷組織的很多概念,下面是在文件"arch/arm/boot/dts/exynos4.dtsi"中對exynos4412的中斷控制器(GIC)節點描述:

要說interrupt-parent,就得首先講講Linux設備管理中對中斷的設計思路演變。隨着linux kernel的發展,在內核中將interrupt controller抽象成irqchip這個概念越來越流行,甚至GPIO controller也可以被看出一個interrupt controller chip,這樣,系統中至少有兩個中斷控制器了,另外,在硬件上,隨着系統複雜度加大,外設中斷數據增加,實際上系統可以需要多箇中斷控制器進行級聯,形成事實上的硬件中斷處理結構:

在這種趨勢下,內核中原本的中斷源直接到中斷號的方式已經很難繼續發展了,爲了解決這些問題,linux kernel的大牛們就創造了irq domain(中斷域)這個概念。domain在內核中有很多,除了irqdomain,還有power domain,clock domain等等,所謂domain,就是領域,範圍的意思,也就是說,任何的定義出了這個範圍就沒有意義了。如上所述,系統中所有的interrupt controller會形成樹狀結構,對於每個interrupt controller都可以連接若干個外設的中斷請求(interrupt source,中斷源),interrupt controller會對連接其上的interrupt source(根據其在Interrupt controller中物理特性)進行編號(也就是HW interrupt ID了)。有了irq domain這個概念之後,這個編號僅僅限制在本interrupt controller範圍內,有了這樣的設計,CPU(Linux 內核)就可以根據級聯的規則一級一級的找到想要訪問的中斷。當然,通常我們關心的只是內核中的中斷號,具體這個中斷號是怎麼找到相應的中斷源的,我們作爲程序員往往不需要關心,除了在寫設備樹的時候,設備樹就是要描述嵌入式軟件開發中涉及的所有硬件信息,所以,設備樹就需要準確的描述硬件上處理中斷的這種樹狀結構,如此,就有了我們的interrupt-parant這樣的概念:用來連接這樣的樹狀結構的上下級,用於表示這個中斷歸屬於哪個interrupt controller,比如,一個接在GPIO上的按鍵,它的組織形式就是:

中斷源--interrupt parent-->GPIO--interrupt parent-->GIC1--interrupt parent-->GIC2--...-->CPU

有了parant,我們就可以使用一級一級的偏移量來最終獲得當前中斷的絕對編號,這裏,可以看出,在我板子上的dm9000的的設備節點中,它的"interrupt-parent"引用了"exynos4x12-pinctrl.dtsi"(被板級設備樹的exynos4412.dtsi包含)中的gpx0節點:

而在gpx0節點中,指定了"#interrupt-cells = <2>;",所以在dm9000中的屬性"interrupts = <6 4>;"表示dm9000的的中斷在作爲irq parant的gpx0中的中斷偏移量,即gpx0中的屬性"interrupts"中的"<0 22 0>",通過查閱exynos4412的手冊知道,對應的中斷號是EINT[6]。

gpio

gpio也是最常見的IO口,常用的屬性有

  • "gpio-controller",用來說明該節點描述的是一個gpio控制器
  • "#gpio-cells",用來描述gpio使用節點的屬性一個cell的內容,即 `屬性 = <&引用GPIO節點別名 GPIO標號 工作模式>

GPIO的設置同樣採用了上述偏移量的思想,比如下面的這個led的設備書,表示使用GPX2組的第7個引腳:

驅動自定義key

針對具體的設備,有部分屬性很難做到通用,需要驅動自己定義好,通過內核的屬性提取解析函數進行值的獲取,比如dm9000節點中的下面這句就是自定義的節點屬性,用以表示配置EEPROM不可用。

VALUE

dts描述一個鍵的值有多種方式,當然,一個鍵也可以沒有值

字符串信息

32bit無符號整型數組信息

二進制數數組

字符串哈希表

混合形式

上述幾種的混合形式

設備樹/驅動移植實例

設備樹就是爲驅動服務的,配置好設備樹之後還需要配置相應的驅動才能檢測配置是否正確。比如dm9000網卡,就需要首先將示例信息掛接到我們的板級設備樹上,並根據芯片手冊和電路原理圖將相應的屬性進行配置,再配置相應的驅動。需要注意的是,dm9000的地址線一般是接在片選線上的,所以設備樹中就應該歸屬與相應片選線節點,我這裏用的exynos4412,接在了bank1,所以是"<0x50000000 0x2 0x50000004 0x2>"
最終的配置結果是:

勾選相應的選項將dm9000的驅動編譯進內核。

make menuconfig
[*] Networking support  --->
    Networking options  --->
        <*> Packet socket
        <*>Unix domain sockets 
        [*] TCP/IP networking
        [*]   IP: kernel level autoconfiguration
Device Drivers  --->
    [*] Network device support  --->
        [*]   Ethernet driver support (NEW)  --->
            <*>   DM9000 support
File systems  --->
    [*] Network File Systems (NEW)  --->
        <*>   NFS client support
        [*]     NFS client support for NFS version 3
        [*]       NFS client support for the NFSv3 ACL protocol extension
        [*]   Root file system on NFS

執行make uImage;make dtbs,tftp下載,成功加載nfs根文件系統並進入系統,表示網卡移植成功

http://www.cnblogs.com/xiaojiang1025/p/6131381.html

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章