干過(guò)嵌入式Linux驅(qū)動(dòng)開(kāi)發(fā)的朋友一定都經(jīng)歷過(guò)被“設(shè)備樹(shù)”支配的恐懼。尤其是當(dāng)你拿到一塊瑞芯微RK3568的開(kāi)發(fā)板想要點(diǎn)個(gè)燈、驅(qū)動(dòng)個(gè)串口卻發(fā)現(xiàn)光是要搞清楚“該用哪個(gè)設(shè)備樹(shù)文件”就得翻半天資料。今天不聊虛的咱們直接從設(shè)備樹(shù)和驅(qū)動(dòng)的這套組合拳講起結(jié)合我在RK3568平臺(tái)上的實(shí)際開(kāi)發(fā)經(jīng)驗(yàn)把這套東西從頭到尾捋一遍。這篇文章適合剛?cè)腴T(mén)Linux驅(qū)動(dòng)開(kāi)發(fā)的新手也適合那些已經(jīng)被設(shè)備樹(shù)繞暈、想系統(tǒng)梳理一遍的同行看完你就能自己改設(shè)備樹(shù)、匹配驅(qū)動(dòng)讓外設(shè)真正跑起來(lái)。1. 內(nèi)容整體設(shè)計(jì)與思路拆解1.1 設(shè)備樹(shù)出現(xiàn)的背景從硬編碼到“硬件說(shuō)明書(shū)”很多初學(xué)者不理解為什么現(xiàn)在搞嵌入式Linux幾乎離不開(kāi)設(shè)備樹(shù)這得從前Linux時(shí)代講起。那時(shí)候每一塊開(kāi)發(fā)板上的硬件資源比如GPIO怎么復(fù)用、中斷接到哪個(gè)腳、I2C控制器地址是多少、SPI片上設(shè)備有哪些統(tǒng)統(tǒng)都是寫(xiě)在內(nèi)核源碼里的board-xxx.c文件中。這就意味著廠商每出一塊新板子就得往內(nèi)核里塞一堆硬件描述的代碼。隨著ARM平臺(tái)碎片化越來(lái)越嚴(yán)重這種“硬編碼”的方式幾乎把內(nèi)核社區(qū)壓垮了。更痛苦的是用戶(hù)想換個(gè)屏幕、改個(gè)GPIO都得重新編譯整個(gè)內(nèi)核效率極低。設(shè)備樹(shù)Device Tree的出現(xiàn)就是為了把“硬件描述”和“內(nèi)核驅(qū)動(dòng)代碼”徹底解耦。它本質(zhì)上是一種描述硬件資源的數(shù)據(jù)結(jié)構(gòu)用樹(shù)狀的方式記錄板卡上有哪些設(shè)備、資源如何分配、如何連接。內(nèi)核啟動(dòng)時(shí)Bootloader比如U-Boot會(huì)把設(shè)備樹(shù)二進(jìn)制文件DTB傳給內(nèi)核內(nèi)核解析這顆樹(shù)就知道板子上有什么硬件然后把對(duì)應(yīng)的驅(qū)動(dòng)程序掛載起來(lái)。你可以把設(shè)備樹(shù)看作一份“硬件說(shuō)明書(shū)”驅(qū)動(dòng)則是“操作員”操作員照著說(shuō)明書(shū)干活板子換了就換說(shuō)明書(shū)操作員本身不用天天改。在瑞芯微RK3568平臺(tái)上這套機(jī)制體現(xiàn)得尤為典型。RK3568的SDK里內(nèi)核目錄arch/arm64/boot/dts/rockchip/下躺著幾十個(gè).dts、.dtsi文件比如rk3568-evb.dts、rk3568-rock-3a.dts還有按不同功能模塊拆分的rk3568.dtsi廠商把SoC內(nèi)部所有控制器的信息都寫(xiě)在rk3568.dtsi里把具體板卡的差異寫(xiě)在板級(jí).dts里。不同開(kāi)發(fā)板、不同屏幕、不同模組選擇不同的DTS內(nèi)核通過(guò)編譯時(shí)確定DTB的方式實(shí)現(xiàn)一個(gè)內(nèi)核適配N(xiāo)種硬件。1.2 為什么強(qiáng)調(diào)“驅(qū)動(dòng)與設(shè)備樹(shù)配合”有了設(shè)備樹(shù)是不是驅(qū)動(dòng)就不用改了不是的。設(shè)備樹(shù)只是描述了硬件真正去操作寄存器的還是驅(qū)動(dòng)代碼。驅(qū)動(dòng)需要通過(guò)匹配設(shè)備樹(shù)中的compatible屬性找到屬于自己的節(jié)點(diǎn)然后從中讀取寄存器地址、中斷號(hào)、GPIO編號(hào)等資源信息。如果你只改了設(shè)備樹(shù)驅(qū)動(dòng)里沒(méi)有對(duì)應(yīng)的匹配邏輯內(nèi)核根本不會(huì)理你。舉個(gè)例子。你在設(shè)備樹(shù)里新增了一個(gè)I2C設(shè)備節(jié)點(diǎn)compatible some,vendor-device如果內(nèi)核里沒(méi)有一個(gè)驅(qū)動(dòng)聲明of_match_table中帶了some,vendor-device這個(gè)字符串那么這個(gè)節(jié)點(diǎn)就是“孤兒”不會(huì)被任何驅(qū)動(dòng)接管。反過(guò)來(lái)驅(qū)動(dòng)再厲害如果設(shè)備樹(shù)里沒(méi)有描述這個(gè)設(shè)備的節(jié)點(diǎn)驅(qū)動(dòng)也找不到設(shè)備去工作。設(shè)備樹(shù)和驅(qū)動(dòng)的關(guān)系就像鑰匙和鎖必須嚴(yán)絲合縫地對(duì)上硬件才能跑起來(lái)。這也是我在指導(dǎo)新人時(shí)反復(fù)強(qiáng)調(diào)的一個(gè)思路先搜設(shè)備樹(shù)再找驅(qū)動(dòng)最后看內(nèi)核日志。拿到一個(gè)陌生的模塊比如一個(gè)ES8388音頻解碼芯片先grep -r es8388 arch/arm64/boot/dts/看有沒(méi)有現(xiàn)成節(jié)點(diǎn)再去內(nèi)核源碼里grep -r es8388 sound/soc/看有沒(méi)有驅(qū)動(dòng)最后在板子上啟動(dòng)系統(tǒng)看dmesg里有沒(méi)有es8388相關(guān)打印。這套流程下來(lái)大部分硬件問(wèn)題都能定位清楚。2. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)2.1 設(shè)備樹(shù)文件的三件套dts、dtsi、dtb剛開(kāi)始看設(shè)備樹(shù)源碼時(shí)很容易被一堆文件后綴搞糊涂。我來(lái)理清楚.dtsDevice Tree Source設(shè)備樹(shù)源文件描述的是“一塊具體板卡”的硬件信息。一般至少包含一個(gè)根節(jié)點(diǎn)model和一個(gè)compatible板級(jí)匹配字符串。.dtsiDevice Tree Source Include設(shè)備樹(shù)頭文件描述的是“一類(lèi)硬件平臺(tái)”的公共信息。rk3568.dtsi就屬于SoC級(jí)公共文件它把CPU核心、中斷控制器、UART控制器、GPIO控制器、I2C控制器等所有SoC內(nèi)部資源都定義好。板級(jí).dts文件通過(guò)#include rk3568.dtsi引入然后針對(duì)具體板卡覆蓋或增加內(nèi)容。.dtbDevice Tree Blob設(shè)備樹(shù)二進(jìn)制文件編譯生成是內(nèi)核實(shí)際解析的目標(biāo)。在SDK中查看文件結(jié)構(gòu)大概是這樣的arch/arm64/boot/dts/rockchip/ ├── rk3568.dtsi # SoC級(jí)所有控制器基礎(chǔ)信息 ├── rk3568-evb.dts # 板級(jí)EVB評(píng)估板硬件配置 ├── rk3568-rock-3a.dts # 板級(jí)Radxa Rock 3A └── rk3568-xxx.dtsi # 板級(jí)公共可能按功能再拆分很多剛接觸OpenHarmony或RK平臺(tái)的朋友都會(huì)問(wèn)這么多設(shè)備樹(shù)到底該選哪個(gè)其實(shí)判斷標(biāo)準(zhǔn)就一條你的板子叫什么名字焊了哪顆PMIC、哪顆Codec、哪個(gè)版本的DDR選對(duì)應(yīng)的.dts就行。如果板子上做了一些私有改動(dòng)最穩(wěn)妥的方式是在官方.dts的基礎(chǔ)上新建一個(gè)你自己的.dts然后用#include把公共部分拉進(jìn)來(lái)不要直接在公共文件上亂改。因?yàn)橛袝r(shí)候SDK升級(jí)會(huì)覆蓋這些公共文件你的板級(jí)專(zhuān)屬配置保存在獨(dú)立文件里升級(jí)才不容易沖突。2.2 設(shè)備樹(shù)基礎(chǔ)語(yǔ)法節(jié)點(diǎn)、屬性、分解寄存器和GPIO設(shè)備樹(shù)語(yǔ)法并不復(fù)雜但是它有自己的“八股文”結(jié)構(gòu)不按照套路寫(xiě)后面驅(qū)動(dòng)讀資源就會(huì)出問(wèn)題。一個(gè)典型的設(shè)備樹(shù)節(jié)點(diǎn)長(zhǎng)這樣uart0 { status okay; pinctrl-names default; pinctrl-0 uart0_xfer; clock-frequency 1500000; };拆開(kāi)來(lái)看uart0是一個(gè)“引用”語(yǔ)法意思是在rk3568.dtsi里已經(jīng)定義過(guò)uart0這個(gè)節(jié)點(diǎn)現(xiàn)在我針對(duì)板級(jí)配置去修改它。status okay讓這個(gè)節(jié)點(diǎn)處于啟用狀態(tài)。默認(rèn)很多節(jié)點(diǎn)是status disabled的不寫(xiě)這一句硬件就算存在也不會(huì)被驅(qū)動(dòng)初始化。pinctrl-names和pinctrl-0引腳復(fù)用配置。UART的TX、RX引腳怎么復(fù)用就是通過(guò)這兩個(gè)屬性控制的對(duì)應(yīng)的引腳配置在rk3568-pinctrl.dtsi中。clock-frequency外設(shè)總線(xiàn)頻率由驅(qū)動(dòng)主動(dòng)讀取使用。再來(lái)看一下GPIO相關(guān)的節(jié)點(diǎn)配置我很常用的一段LED燈節(jié)點(diǎn)leds { compatible gpio-leds; status okay; led_rgb_g { label green; gpios gpio4 2 GPIO_ACTIVE_HIGH; default-state off; }; };這個(gè)節(jié)點(diǎn)描述了一個(gè)GPIO控制的LED燈。gpio4 2表示第4組GPIO控制器下的第2號(hào)引腳也就是物理上常見(jiàn)的GPIO4_C2GPIO_ACTIVE_HIGH表示引腳輸出高電平時(shí)LED點(diǎn)亮。驅(qū)動(dòng)側(cè)內(nèi)核自帶的leds-gpio.c會(huì)匹配compatible gpio-leds這個(gè)字符串然后遍歷子節(jié)點(diǎn)解析gpios屬性最終在/sys/class/leds/下創(chuàng)建對(duì)應(yīng)的控制接口。這個(gè)例子也是新手理解“設(shè)備樹(shù)如何影響驅(qū)動(dòng)行為”的一個(gè)經(jīng)典案例。2.3 驅(qū)動(dòng)側(cè)如何讀取設(shè)備樹(shù)資源platform 機(jī)制與 of_match_table設(shè)備樹(shù)寫(xiě)好了驅(qū)動(dòng)怎么找到“自己那一份”資源這就要說(shuō)到Linux的platform驅(qū)動(dòng)機(jī)制了。所謂platform設(shè)備可以理解為一條總線(xiàn)上的虛擬設(shè)備用來(lái)掛載那些不依附于PCle、USB等真實(shí)總線(xiàn)的硬件比如板載UART、I2C控制器、GPIO LED等。設(shè)備樹(shù)把平臺(tái)設(shè)備描述出來(lái)內(nèi)核啟動(dòng)時(shí)會(huì)用of_platform_bus_probe()遍歷設(shè)備樹(shù)里的節(jié)點(diǎn)為每個(gè)compatible屬性匹配到對(duì)應(yīng)驅(qū)動(dòng)。下面是一個(gè)非常典型的platform驅(qū)動(dòng)匹配方式static const struct of_device_id my_led_of_match[] { { .compatible gpio-leds, }, { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, my_led_of_match); static struct platform_driver my_led_driver { .probe my_led_probe, .remove my_led_remove, .driver { .name my_led, .of_match_table my_led_of_match, }, }; module_platform_driver(my_led_driver);當(dāng)內(nèi)核對(duì)一個(gè)設(shè)備節(jié)點(diǎn)調(diào)用匹配邏輯時(shí)會(huì)拿節(jié)點(diǎn)的compatible值逐一比對(duì)驅(qū)動(dòng)結(jié)構(gòu)體里of_match_table中每個(gè)of_device_id的.compatible字段匹配成功后就調(diào)用probe函數(shù)。進(jìn)入probe后驅(qū)動(dòng)又通過(guò)下面這組常用的API來(lái)獲取設(shè)備樹(shù)中描述的資源struct device_node *np pdev-dev.of_node; ret of_property_read_string(np, label, str); ret of_property_read_u32_index(np, reg, 0, value); gpio of_get_named_gpio(np, gpios, 0);你會(huì)發(fā)現(xiàn)設(shè)備樹(shù)屬性名和驅(qū)動(dòng)API其實(shí)是“對(duì)暗號(hào)”的關(guān)系label對(duì)應(yīng)of_property_read_stringgpios對(duì)應(yīng)of_get_named_gpio。寫(xiě)驅(qū)動(dòng)時(shí)一定要反復(fù)確認(rèn)屬性名拼寫(xiě)不然內(nèi)核會(huì)靜默地讀取失敗報(bào)文都查不到。3. 實(shí)操過(guò)程與核心環(huán)節(jié)實(shí)現(xiàn)3.1 在RK3568上定制設(shè)備樹(shù)以修改串口和GPIO為例實(shí)操才是真正長(zhǎng)本事的地方。下面我以RK3568為例帶大家完整走一遍“修改設(shè)備樹(shù) → 編譯內(nèi)核 → 刷新DTB → 驗(yàn)證效果”的流程。首先建議在SDK根目錄下確認(rèn)環(huán)境變量和編譯腳本。以Rockchip Linux SDK為例常見(jiàn)的一鍵編譯指令是source build/envsetup.sh lunch rk3568-evb1-ddr4-v10.img ./build.sh kernel這里主要編的就是kernel.img其中包含了編譯好的內(nèi)核鏡像和DTB。編譯完成后新的DTB會(huì)在kernel/arch/arm64/boot/dts/rockchip/下生成最終被打包進(jìn)boot.img或者resource.img具體看你的分區(qū)策略。燒錄時(shí)用upgrade_tool或者SDK自帶的update.img燒寫(xiě)工具即可。修改文件的時(shí)候找到你板卡對(duì)應(yīng)的DTS文件比如rk3568-evb.dts新增自定義節(jié)點(diǎn)。假設(shè)你要外接一個(gè)UART3但默認(rèn)它處于禁用狀態(tài)你需要在DTS里打開(kāi)并配置引腳uart3 { status okay; pinctrl-names default; pinctrl-0 uart3m1_xfer; };這里的uart3m1_xfer是在rk3568-pinctrl.dtsi里定義好的引腳組表示UART3使用哪一組引腳復(fù)用。如果你不確定引腳組的名字在SDK里直接grep -r uart3 arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi就能看到。再舉一個(gè)修改GPIO引腳的例子。很多板子會(huì)擴(kuò)展一個(gè)調(diào)試LED電阻焊的位置可能和官方EVB不一樣這時(shí)你不能直接用官方gpio-leds節(jié)點(diǎn)得改成自己板上的實(shí)際引腳。官方節(jié)點(diǎn)里也許是用gpio4 2你的板子實(shí)際接在gpio3 17直接把gpios gpio4 2 GPIO_ACTIVE_HIGH;改成gpios gpio3 17 GPIO_ACTIVE_HIGH;重新編譯內(nèi)核、燒錄、啟動(dòng)LED的邏輯立馬就變了。3.2 手寫(xiě)一個(gè)基于設(shè)備樹(shù)的platform驅(qū)動(dòng)掌握了修改設(shè)備樹(shù)之后我們?cè)儆H手寫(xiě)一個(gè)最簡(jiǎn)驅(qū)動(dòng)把“設(shè)備樹(shù)對(duì)接驅(qū)動(dòng)”這條路完整走通。假設(shè)我在DTS里新增了這樣一個(gè)節(jié)點(diǎn)my_device: my-device { compatible myvendor,my-device; reg 0x0 0xff320000 0x0 0x1000; my-gpios gpio4 5 GPIO_ACTIVE_HIGH; my-value 42; };這個(gè)節(jié)點(diǎn)描述了一個(gè)掛在內(nèi)存映射地址上的設(shè)備起始地址0xff320000長(zhǎng)度0x1000還帶一個(gè)GPIO和一個(gè)自定義數(shù)值。驅(qū)動(dòng)的核心probe函數(shù)可以這樣寫(xiě)static int my_dev_probe(struct platform_device *pdev) { struct resource *res; struct device *dev pdev-dev; struct gpio_desc *gpio; u32 val; int ret; /* 獲取reg地址資源 */ res platform_get_resource(pdev, IORESOURCE_MEM, 0); if (!res) return -ENXIO; dev_info(dev, reg base 0x%llx, size 0x%llx\n, (unsigned long long)res-start, (unsigned long long)resource_size(res)); /* 獲取GPIO屬性描述符方式 */ gpio devm_gpiod_get(dev, my, GPIOD_IN); if (IS_ERR(gpio)) return PTR_ERR(gpio); dev_info(dev, gpio number: %d\n, desc_to_gpio(gpio)); /* 獲取自定義整數(shù)屬性 */ ret of_property_read_u32(dev-of_node, my-value, val); if (!ret) dev_info(dev, my-value %d\n, val); return 0; }大家注意幾個(gè)細(xì)節(jié)platform_get_resource拿到的是DTS中reg描述的地址范圍和長(zhǎng)度對(duì)應(yīng)的是寄存器物理地址后續(xù)如果要操作寄存器需要ioremap映射到虛擬地址。devm_gpiod_get(dev, my, ...)中的第二個(gè)參數(shù)my對(duì)應(yīng)屬性my-gpios也就是去掉-gpios后綴的那部分。of_property_read_u32(dev-of_node, my-value, val)直接按屬性名讀取名稱(chēng)必須一字不差。編譯時(shí)除了把驅(qū)動(dòng)放進(jìn)內(nèi)核源碼目錄還需要在Makefile里增加對(duì)應(yīng)的obj-y或obj-m規(guī)則比如obj-m my-dev.o然后執(zhí)行make ARCHarm64 CROSS_COMPILEaarch64-linux-gnu- modules。如果你是做內(nèi)核模塊把生成的.ko拷貝到板子上insmod my-dev.ko同時(shí)確保設(shè)備樹(shù)里的節(jié)點(diǎn)存在驅(qū)動(dòng)就能正常過(guò)來(lái)了。如果DTS里沒(méi)有這個(gè)節(jié)點(diǎn)probe永遠(yuǎn)不會(huì)被調(diào)用模塊加載時(shí)會(huì)靜默無(wú)反應(yīng)。3.3 設(shè)備樹(shù)到底是“選了誰(shuí)”O(jiān)penHarmony場(chǎng)景下的DTS選擇最近OpenHarmony適配RK3568很火論壇里經(jīng)常有人問(wèn)OpenHarmony的RK3568有那么多設(shè)備樹(shù)到底該選哪個(gè)這個(gè)問(wèn)題其實(shí)反映了很多人的困惑OpenHarmony的SDK和經(jīng)典Linux SDK目錄結(jié)構(gòu)不一致DTS的生成方式也帶了自己的構(gòu)建系統(tǒng)。在OpenHarmony的設(shè)備開(kāi)發(fā)中設(shè)備樹(shù)同樣位于內(nèi)核目錄下通常要看kernel/linux/build腳本里指定的DTS名稱(chēng)。以Dayu200開(kāi)發(fā)板為例它在編譯內(nèi)核時(shí)會(huì)指定rockchip_rk3568_evb.dtb但對(duì)于同一顆芯片的不同硬件版本比如EVB1、EVB2或者是其他第三方板卡DTB文件名可能都不同。我的建議是先看板卡原理圖確認(rèn)DDR型號(hào)、PMIC型號(hào)、Codec型號(hào)再去找官方SDK里帶相同器件配置的DTS作為基礎(chǔ)模板。比如你的板子用的PMIC是RK809相同WIFI模組型號(hào)一致那大概率官方EVB的DTS改改就能用。如果板子的PMIC換了那就不能直接用EVB的DTS必須換成對(duì)應(yīng)PMIC的公共DTSI否則內(nèi)核啟動(dòng)時(shí)電源管理部分可能直接崩潰。當(dāng)然更高效的方式是直接進(jìn)入kernel的menuconfig在Device Tree and Open Firmware support選項(xiàng)中找到默認(rèn)DTB配置項(xiàng)或者在arch/arm64/boot/dts/rockchip/Makefile里看到所有可生成的DTB列表。板子上電后在Uboot階段按任意鍵進(jìn)入命令行執(zhí)行printenv fdtfile也能看到當(dāng)前用的DTB文件名順著這個(gè)名字反查源代碼即可。3.4 用configfs和overlay實(shí)現(xiàn)設(shè)備樹(shù)運(yùn)行時(shí)修改除了重新編譯DTS還有一種不需要重編內(nèi)核的調(diào)試方式設(shè)備樹(shù)OverlayDTSO。這對(duì)像我這種經(jīng)常要臨時(shí)加一個(gè)驅(qū)動(dòng)、點(diǎn)一盞燈的人來(lái)說(shuō)簡(jiǎn)直是福音。它的原理類(lèi)似一個(gè)“運(yùn)行時(shí)補(bǔ)丁”在系統(tǒng)啟動(dòng)后臨時(shí)把一個(gè)小的DTS片段合入系統(tǒng)的設(shè)備樹(shù)中從而動(dòng)態(tài)創(chuàng)建節(jié)點(diǎn)。以RK3568為例如果內(nèi)核開(kāi)啟了CONFIG_OF_OVERLAY你可以把下面這段配置作為overlay dts/dts-v1/; /plugin/; / { fragment0 { target-path /; __overlay__ { my_overlay_dev { compatible myvendor,my-overlay-device; my-value 100; }; }; }; };然后通過(guò)configfs接口加載它mkdir /config mount -t configfs configfs /config mkdir /config/device-tree/overlays/myoverlay cat myoverlay.dtbo /config/device-tree/overlays/myoverlay/dtbo加載成功后/proc/device-tree/目錄下會(huì)多出my_overlay_dev這個(gè)節(jié)點(diǎn)對(duì)應(yīng)的驅(qū)動(dòng)如果已經(jīng)加載就會(huì)直接匹配。調(diào)試完臨時(shí)設(shè)備比不停改DTS重編內(nèi)核高效太多。唯一的坑是Overlay的節(jié)點(diǎn)不能與已有的主設(shè)備樹(shù)節(jié)點(diǎn)完全沖突比如重復(fù)的compatible節(jié)點(diǎn)否則可能導(dǎo)致解析報(bào)錯(cuò)日志里會(huì)有__of_attach_node_sysfs相關(guān)報(bào)錯(cuò)信息。4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄4.1 常用調(diào)試入口在哪里驗(yàn)證設(shè)備樹(shù)有沒(méi)有生效寫(xiě)設(shè)備樹(shù)驅(qū)動(dòng)最大的煩惱是你改了文件卻不知道內(nèi)核到底有沒(méi)有按你想的解析。這里我列一組最高頻的驗(yàn)證入口基本能覆蓋90%的排查場(chǎng)景。/proc/device-tree/這是設(shè)備樹(shù)在運(yùn)行時(shí)解析后的真實(shí)“鏡子”內(nèi)核對(duì)每一個(gè)設(shè)備樹(shù)節(jié)點(diǎn)都會(huì)在這個(gè)目錄下生成對(duì)應(yīng)子目錄。你可以在板子上直接執(zhí)行以下命令來(lái)驗(yàn)證節(jié)點(diǎn)是否存在ls /proc/device-tree/leds/led_rgb_g/ cat /proc/device-tree/leds/led_rgb_g/compatible如果節(jié)點(diǎn)存在說(shuō)明設(shè)備樹(shù)解析到了如果不存在要么DTB沒(méi)燒錄成功要么在解析之前的某個(gè)環(huán)節(jié)被丟棄了。我經(jīng)?？窟@一步來(lái)判斷問(wèn)題到底出在DTS編譯階段還是驅(qū)動(dòng)匹配階段。/sys/firmware/devicetree/base/這是現(xiàn)代內(nèi)核更標(biāo)準(zhǔn)的設(shè)備樹(shù)導(dǎo)出界面結(jié)構(gòu)和/proc/device-tree一致推薦優(yōu)先用這個(gè)目錄驗(yàn)證。/sys/bus/platform/devices/在這個(gè)目錄下列出所有platform設(shè)備可以看你的設(shè)備名是否出現(xiàn)在里面。如果設(shè)備樹(shù)節(jié)點(diǎn)在但platform設(shè)備沒(méi)生成一般是device_node到platform_device的注冊(cè)過(guò)程出了問(wèn)題常見(jiàn)原因是某些屬性缺失導(dǎo)致of_platform_bus_probe跳過(guò)該節(jié)點(diǎn)。4.2 驅(qū)動(dòng)不 probe 的排查方法“不知不覺(jué)”里最常見(jiàn)的問(wèn)題驅(qū)動(dòng)不probe是設(shè)備樹(shù)調(diào)試?yán)镒钅ト说膯?wèn)題。結(jié)合我自己踩過(guò)的坑我總結(jié)了一套排查順序先確認(rèn)設(shè)備樹(shù)節(jié)點(diǎn)狀態(tài)是不是status disabled沒(méi)改我見(jiàn)過(guò)太多人只添加了子節(jié)點(diǎn)忘了把父節(jié)點(diǎn)或控制器狀態(tài)改掉結(jié)果整個(gè)外設(shè)模塊壓根沒(méi)有被初始化。執(zhí)行這條命令最直觀cat /proc/device-tree/xxx/status確認(rèn)compatible字符串完全一致節(jié)點(diǎn)里寫(xiě)的是myvendor,my-device驅(qū)動(dòng)里of_match_table寫(xiě)成了myvendor,mydevice少了一個(gè)字符都不行。LInux內(nèi)核匹配compatible是嚴(yán)格字符串比較不允許模糊匹配。確認(rèn)驅(qū)動(dòng)模塊是否真的加載了如果你是模塊方式加載執(zhí)行l(wèi)smod | grep my_dev看看模塊是否在列表中。模塊加載成功了但probe沒(méi)執(zhí)行一般說(shuō)明平臺(tái)驅(qū)動(dòng)沒(méi)有注冊(cè)成功或者設(shè)備樹(shù)中節(jié)點(diǎn)對(duì)應(yīng)的設(shè)備沒(méi)被創(chuàng)建出來(lái)?？磧?nèi)核日志中的ACPI/OF相關(guān)打印在啟動(dòng)參數(shù)里加上loglevel8或者在dmesg里執(zhí)行dmesg | grep -i of_platform\|my.device\|match很多匹配過(guò)程失敗時(shí)內(nèi)核會(huì)打印OF: fsl_mcu: no match found之類(lèi)的信息一眼就知道是compatible不匹配。我還想強(qiáng)調(diào)一點(diǎn)不要忽略設(shè)備樹(shù)里的status屬性對(duì)“整棵子樹(shù)”的影響。有時(shí)你看到uart3節(jié)點(diǎn)status是okay但它的父節(jié)點(diǎn)比如某個(gè)總線(xiàn)節(jié)點(diǎn)是disabled那uart3也會(huì)被跳過(guò)。排查時(shí)一定要順著設(shè)備樹(shù)的父子關(guān)系往上查直到根節(jié)點(diǎn)。4.3 設(shè)備樹(shù)編譯與燒錄的三個(gè)高頻坑除了硬件和驅(qū)動(dòng)匹配問(wèn)題設(shè)備樹(shù)編譯燒錄階段也有不少“翻車(chē)現(xiàn)場(chǎng)”。我見(jiàn)過(guò)最頻繁的三類(lèi)問(wèn)題這里統(tǒng)一寫(xiě)出來(lái)dts語(yǔ)法沒(méi)通過(guò)編譯內(nèi)核卻還編過(guò)了這是新手最容易懵的。有些DTS語(yǔ)法錯(cuò)誤比如少了分號(hào)花括號(hào)不匹配會(huì)在預(yù)編譯階段就被攔截報(bào)錯(cuò)信息里會(huì)直接指出行號(hào)比如Error: arch/arm64/boot/dts/rockchip/rk3568-evb.dts:120.1-2 syntax error。遇到這種問(wèn)題老老實(shí)實(shí)回去檢查語(yǔ)法別指望僥幸通過(guò)。燒錄了錯(cuò)誤的DTB分區(qū)部分平臺(tái)把DTB單獨(dú)放在resource分區(qū)部分平臺(tái)把DTB打包進(jìn)boot.img。如果你改了DTS但燒錄時(shí)只燒了Kernel沒(méi)有燒resource.img那改動(dòng)的DTB根本沒(méi)進(jìn)系統(tǒng)。刷機(jī)前先搞清SDK的鏡像分區(qū)邏輯不然排查到頭都找不出為什么系統(tǒng)行為沒(méi)變化。#include引用路徑問(wèn)題在DTS中寫(xiě)#include dt-bindings/gpio/gpio.h時(shí)如果頭文件路徑不對(duì)編譯會(huì)報(bào)找不到文件。正常情況下SDK的編譯腳本會(huì)把這些頭文件路徑通過(guò)-I參數(shù)傳進(jìn)來(lái)但如果你把DTS拷到別的目錄單獨(dú)編譯就得自己手動(dòng)指定頭文件路徑否則一堆宏定義比如GPIO_ACTIVE_LOW會(huì)變成未定義數(shù)字語(yǔ)法上沒(méi)問(wèn)題但行為會(huì)變得非常詭異。4.4 從驅(qū)動(dòng)到驗(yàn)證一個(gè)完整的復(fù)現(xiàn)示例為了讓大家能直接“抄作業(yè)”我再把前面所有環(huán)節(jié)串成一個(gè)最小的完整示例。設(shè)備樹(shù)節(jié)點(diǎn)就下面這一段/ { compatible myvendor,my-board; test_led: test-led { compatible myvendor,test-led; status okay; gpios gpio0 RK_PA5 GPIO_ACTIVE_LOW; }; };驅(qū)動(dòng)端一個(gè)極簡(jiǎn)的.c文件#include linux/module.h #include linux/platform_device.h #include linux/gpio/consumer.h #include linux/of.h static int test_led_probe(struct platform_device *pdev) { struct gpio_desc *desc; desc devm_gpiod_get(pdev-dev, NULL, GPIOD_OUT_LOW); if (IS_ERR(desc)) return PTR_ERR(desc); gpiod_set_value(desc, 1); dev_info(pdev-dev, LED ON\n); return 0; } static const struct of_device_id test_led_ids[] { { .compatible myvendor,test-led }, { } }; MODULE_DEVICE_TABLE(of, test_led_ids); static struct platform_driver test_led_driver { .probe test_led_probe, .driver { .name test_led, .of_match_table test_led_ids, }, }; module_platform_driver(test_led_driver); MODULE_LICENSE(GPL);在板子的內(nèi)核源碼樹(shù)目錄下執(zhí)行make ARCHarm64 CROSS_COMPILEaarch64-linux-gnu- M$(pwd)/drivers/misc modules將生成的.ko推送到板子執(zhí)行insmod test_led.ko如果一切正常你會(huì)在dmesg看到LED ON打印。如果設(shè)備樹(shù)里沒(méi)有那個(gè)節(jié)點(diǎn)模塊加載后不會(huì)有任何輸出因?yàn)轵?qū)動(dòng)找不到匹配的設(shè)備。這個(gè)示例雖然短但設(shè)備樹(shù)和驅(qū)動(dòng)交互的主干鏈路已經(jīng)完全跑通了。5. 工具鏈與實(shí)操心得補(bǔ)充5.1 必備工具與命令速查調(diào)試設(shè)備樹(shù)和驅(qū)動(dòng)我確實(shí)離不開(kāi)下面這些命令匯總成一張速查表給各位留存參考。命令/文件作用dtc -I dtb -O dts -o xxx.dts xxx.dtb反編譯DTB為DTS查看運(yùn)行時(shí)真實(shí)設(shè)備樹(shù)內(nèi)容fdtdump xxx.dtb快速查看DTB內(nèi)節(jié)點(diǎn)結(jié)構(gòu)不帶源碼注釋/proc/device-tree或/sys/firmware/devicetree/base運(yùn)行時(shí)查看內(nèi)核解析后的設(shè)備樹(shù)節(jié)點(diǎn)dmesg | grep -i of過(guò)濾設(shè)備樹(shù)解析相關(guān)信息ls /sys/bus/platform/devices/查看所有platform設(shè)備確認(rèn)節(jié)點(diǎn)是否注冊(cè)成功cat /proc/interrupts查看中斷注冊(cè)情況驗(yàn)證設(shè)備樹(shù)中斷屬性是否生效devmem直接讀取內(nèi)存映射地址值驗(yàn)證寄存器基址是否符合設(shè)備樹(shù)描述insmod / modprobe / rmmod加載和卸載內(nèi)核模塊調(diào)試驅(qū)動(dòng)匹配lsmod查看已加載模塊狀態(tài)最容易被忽略的是devmem。曾有一次我懷疑設(shè)備樹(shù)的reg寫(xiě)錯(cuò)導(dǎo)致驅(qū)動(dòng)訪問(wèn)寄存器總是讀不到值后來(lái)直接在板子上用devmem 0xff320000讀了一下物理地址發(fā)現(xiàn)地址本來(lái)就是錯(cuò)的問(wèn)題根本不在驅(qū)動(dòng)代碼。硬件調(diào)試時(shí)這個(gè)命令能幫你把問(wèn)題邊界畫(huà)得很清楚。5.2 我的幾點(diǎn)獨(dú)家經(jīng)驗(yàn)最后分享幾條我個(gè)人調(diào)試設(shè)備和驅(qū)動(dòng)時(shí)沉淀下來(lái)的經(jīng)驗(yàn)希望能幫大家少走彎路。第一命名規(guī)范一定要遵守。compatible屬性建議用廠商,設(shè)備名的格式比如rockchip,rk3568-uart。這不僅是社區(qū)慣例而且能避免不同廠商同名設(shè)備互相“搶驅(qū)動(dòng)”。你自己新增節(jié)點(diǎn)時(shí)也盡量帶上自己公司的前綴別在私有節(jié)點(diǎn)上寫(xiě)test,device后面量產(chǎn)時(shí)分分鐘出問(wèn)題。第二改動(dòng)要小步驗(yàn)證。我見(jiàn)過(guò)不少同事一次改了一堆設(shè)備樹(shù)節(jié)點(diǎn)結(jié)果啟動(dòng)直接掛死到處找問(wèn)題。更科學(xué)的做法是一次只改一個(gè)節(jié)點(diǎn)重新編譯、燒錄、驗(yàn)證把正確性確認(rèn)在每一個(gè)提交點(diǎn)之后這樣即使出了問(wèn)題回溯成本也最小。第三DTS 的包含順序會(huì)影響屬性覆蓋。同一個(gè)節(jié)點(diǎn)屬性如果被多個(gè).dtsi定義后包含的會(huì)覆蓋先包含的。所以你在板級(jí)文件里覆蓋某個(gè)屬性時(shí)要確保它是在對(duì)應(yīng).dtsi之后被包含的否則你改了半天最后還是被公共文件覆蓋回去了。遇到奇怪的現(xiàn)象時(shí)直接反編譯DTB確認(rèn)最終生成的DTS形態(tài)一切就真相大白。第四善用git blame和提交記錄。在廠商SDK里設(shè)備樹(shù)某個(gè)節(jié)點(diǎn)為什么長(zhǎng)這樣通常有歷史原因git log -- arch/arm64/boot/dts/rockchip/rk3568-evb.dts能幫你快速找到當(dāng)初誰(shuí)改過(guò)、為什么改這比自己去猜靠譜得多。設(shè)備樹(shù)這套東西說(shuō)穿了就是“數(shù)據(jù) 驅(qū)動(dòng)”兩條腿走路。數(shù)據(jù)描述硬件驅(qū)動(dòng)消費(fèi)數(shù)據(jù)理解了這個(gè)核心邏輯再多的文件后綴、再多的匹配規(guī)則都只是皮相。你去翻RK3568 SDK的時(shí)候別再害怕那一大堆設(shè)備樹(shù)文件了——那不是迷宮而是一張清晰標(biāo)注了所有硬件資源的地圖。照著地圖走你會(huì)發(fā)現(xiàn)調(diào)一個(gè)GPIO、嫁接一顆新芯片其實(shí)都是水到渠成的事。