1. 從編譯報(bào)錯(cuò)說起為什么U-Boot移植繞不開Kbuild第一次給一塊新板子做U-Boot移植的人十有八九會(huì)在編譯階段卡住。現(xiàn)象往往很樸素make xxx_defconfig跑完看著挺正常接著make一敲報(bào)錯(cuò)信息刷屏什么No rule to make target、undefined reference、recipe for target failed翻來覆去就是找不到某個(gè)文件或者某個(gè)符號(hào)。你打開源碼目錄一看文件明明躺在那里路徑也沒寫錯(cuò)可編譯系統(tǒng)就是不認(rèn)。這個(gè)場(chǎng)景背后幾乎都指向同一件事你沒搞懂U-Boot的構(gòu)建系統(tǒng)也就是Kbuild。U-Boot從2014年底開始逐步把原來的手工Makefile體系遷移到Kbuild框架到現(xiàn)在主流版本已經(jīng)完全基于Kbuild組織。這意味著移植U-Boot不再只是改改寄存器地址、填填時(shí)鐘參數(shù)那么簡(jiǎn)單你得先讓構(gòu)建系統(tǒng)認(rèn)識(shí)你的板子、認(rèn)識(shí)你的目錄、認(rèn)識(shí)你的配置文件否則代碼寫得再對(duì)也編不進(jìn)去。Kbuild本身不是U-Boot發(fā)明的它最早來自Linux內(nèi)核的構(gòu)建體系核心思想是用一套分層的Makefile加上Kconfig配置系統(tǒng)把配置和構(gòu)建這兩件事解耦。配置階段決定哪些代碼參與編譯構(gòu)建階段根據(jù)配置結(jié)果去實(shí)際編譯。U-Boot借用了這套機(jī)制但做了裁剪和適配所以它跟內(nèi)核的Kbuild像又不完全一樣。很多人拿著內(nèi)核的經(jīng)驗(yàn)直接套U-Boot結(jié)果在Kconfig語法、Makefile的obj-y規(guī)則、defconfig的生成方式上反復(fù)踩坑。這篇內(nèi)容面向的是正在做U-Boot移植、被構(gòu)建系統(tǒng)折磨過的嵌入式開發(fā)者也適合想系統(tǒng)理解Kbuild在U-Boot里怎么落地的人。我會(huì)從移植視角出發(fā)把Kbuild的目錄結(jié)構(gòu)、Kconfig配置鏈路、Makefile編譯規(guī)則、defconfig生成邏輯講透再結(jié)合一塊假想的新板子把新增一個(gè)板級(jí)支持的完整流程走一遍?？赐昴銘?yīng)該能做到拿到一塊新板子知道該動(dòng)哪些文件、為什么動(dòng)、動(dòng)完之后怎么驗(yàn)證而不是靠搜索引擎拼湊答案。2. U-Boot目錄里的Kbuild骨架先認(rèn)清誰管配置、誰管編譯2.1 頂層目錄的分工邏輯打開一份U-Boot源碼頂層目錄一眼看過去很雜但跟Kbuild相關(guān)的其實(shí)就那么幾個(gè)關(guān)鍵角色。理解它們的分工是后面所有操作的基礎(chǔ)。Kconfig是配置系統(tǒng)的總?cè)肟谒恢苯佣x選項(xiàng)而是通過source語句把各個(gè)子目錄下的Kconfig文件串起來形成一棵配置樹。Makefile是構(gòu)建系統(tǒng)的總?cè)肟谪?fù)責(zé)定義編譯目標(biāo)、工具鏈變量、以及遞歸進(jìn)入子目錄的規(guī)則。configs/目錄存放的是各種xxx_defconfig文件這些是配置的初始快照make xxx_defconfig就是從這里拷貝一份配置到根目錄的.config。scripts/kconfig/下面是配置系統(tǒng)的實(shí)現(xiàn)代碼包括conf、mconf、gconf等工具你平時(shí)敲的make menuconfig最終調(diào)用的就是這里編譯出來的程序。還有一個(gè)容易被忽略的角色是scripts/Makefile.build和scripts/Makefile.lib。前者定義了子目錄里obj-y、obj-m這些變量怎么被展開成實(shí)際的編譯命令后者提供了一堆輔助函數(shù)和變量比如ccflags-y、asflags-y怎么拼接。移植時(shí)如果遇到我明明寫了obj-y foo.o但沒編進(jìn)去八成是這兩個(gè)文件里的規(guī)則沒被正確觸發(fā)。提示不要試圖去改scripts/下的通用構(gòu)建邏輯來適配你的板子。這些文件是全平臺(tái)共用的改了會(huì)影響所有板子而且升級(jí)U-Boot版本時(shí)必然沖突。板級(jí)差異應(yīng)該通過配置和板級(jí)目錄里的Makefile解決。2.2 配置與構(gòu)建的分離Kconfig和Makefile各管一攤Kbuild最核心的設(shè)計(jì)就是配置和構(gòu)建分離。Kconfig文件只負(fù)責(zé)描述有哪些配置項(xiàng)、它們的依賴關(guān)系、默認(rèn)值是什么它不關(guān)心代碼怎么編譯。Makefile只負(fù)責(zé)根據(jù)當(dāng)前配置決定編譯哪些文件、用什么參數(shù)編譯它不關(guān)心配置項(xiàng)是怎么來的。這個(gè)分離帶來的直接好處是同一份源碼通過不同的.config可以編譯出完全不同的固件。對(duì)移植來說這意味著你新增一塊板子時(shí)主要工作是兩件事——在Kconfig里聲明這塊板子相關(guān)的配置項(xiàng)在Makefile里聲明這塊板子需要編譯哪些文件。兩件事各做各的互不干擾。舉個(gè)具體的例子。假設(shè)你的板子叫myboard用的是ARM Cortex-A7那么你需要在arch/arm/mach-xxx/Kconfig里加一個(gè)config TARGET_MYBOARD的選項(xiàng)在board/vendor/myboard/Kconfig里加板級(jí)配置然后在對(duì)應(yīng)的Makefile里寫obj-$(CONFIG_TARGET_MYBOARD) myboard.o。配置項(xiàng)打開時(shí)obj-y生效文件被編譯配置項(xiàng)關(guān)閉時(shí)obj-為空文件被跳過。整個(gè)過程不需要任何條件判斷語句全靠變量展開。2.3 一次完整編譯的調(diào)用鏈路理解調(diào)用鏈路能幫你在出問題時(shí)快速定位是哪一環(huán)斷了。當(dāng)你敲下make時(shí)大致經(jīng)歷這么幾個(gè)階段第一階段是配置檢查。頂層Makefile會(huì)檢查根目錄下有沒有.config沒有就報(bào)錯(cuò)提示你先跑make xxx_defconfig。有的話它會(huì)調(diào)用scripts/kconfig/conf工具根據(jù).config生成一個(gè)include/config/auto.conf和一堆include/generated/下的頭文件。auto.conf里的內(nèi)容就是CONFIG_XXXy這種形式它會(huì)被子目錄的 Makefile 包含進(jìn)來成為obj-y判斷的依據(jù)。第二階段是遞歸構(gòu)建。頂層Makefile通過obj-y變量列出要進(jìn)入的子目錄然后調(diào)用scripts/Makefile.build逐個(gè)進(jìn)入。每進(jìn)入一個(gè)目錄Makefile.build會(huì)包含該目錄的Makefile讀取里面的obj-y把.o文件展開成編譯命令。如果目錄下還有子目錄繼續(xù)遞歸。第三階段是鏈接。所有.o編譯完成后根據(jù)鏈接腳本u-boot.lds把它們鏈接成u-boot可執(zhí)行文件再經(jīng)過格式轉(zhuǎn)換生成u-boot.bin等最終產(chǎn)物。這條鏈路里任何一個(gè)環(huán)節(jié)的變量沒對(duì)上都會(huì)導(dǎo)致編譯失敗或產(chǎn)物不對(duì)。移植時(shí)最常見的錯(cuò)誤就是auto.conf里沒有你期望的CONFIG_XXXy導(dǎo)致obj-y為空文件根本沒參與編譯最后鏈接時(shí)報(bào)符號(hào)未定義。3. Kconfig語法在U-Boot里的實(shí)際寫法別照搬內(nèi)核那一套3.1 config、menuconfig、choice的基本用法U-Boot的Kconfig語法跟內(nèi)核高度相似但支持的語法子集更小有些內(nèi)核里能用的寫法在U-Boot里會(huì)報(bào)錯(cuò)。最常用的三個(gè)關(guān)鍵字是config、menuconfig和choice。config定義一個(gè)獨(dú)立的配置項(xiàng)最基本的寫法是config TARGET_MYBOARD bool Support myboard depends on ARCH_MYCHIP help Say Y here to support the myboard development board.bool表示這是一個(gè)布爾選項(xiàng)在menuconfig里顯示為[ ]或[*]。depends on定義依賴關(guān)系只有ARCH_MYCHIP被選中時(shí)這個(gè)選項(xiàng)才會(huì)出現(xiàn)。help后面是幫助文本按?時(shí)顯示。menuconfig用來定義一個(gè)帶子菜單的配置項(xiàng)通常用于組織一組相關(guān)配置。它本身也是一個(gè)配置項(xiàng)選中后進(jìn)入子菜單。choice用于互斥選擇比如多個(gè)板子只能選一個(gè)就用choice包起來里面每個(gè)config是一個(gè)選項(xiàng)。U-Boot里有個(gè)約定俗成的做法板級(jí)配置項(xiàng)通常以TARGET_開頭架構(gòu)配置項(xiàng)以ARCH_開頭驅(qū)動(dòng)配置項(xiàng)以CONFIG_開頭雖然所有配置項(xiàng)最終都是CONFIG_前綴但定義時(shí)省略。這個(gè)命名習(xí)慣不是強(qiáng)制的但遵循它能讓你的配置樹更清晰。3.2 depends on和select的取舍depends on和select是Kconfig里最容易用錯(cuò)的兩個(gè)關(guān)鍵字它們的方向正好相反。depends on是我依賴別人寫在被依賴項(xiàng)的下游。比如TARGET_MYBOARD依賴ARCH_MYCHIP就寫在TARGET_MYBOARD里。效果是ARCH_MYCHIP沒選時(shí)TARGET_MYBOARD在菜單里不可見。select是我要求別人被選中寫在上游。比如你選了TARGET_MYBOARD它必須用到某個(gè)串口驅(qū)動(dòng)就寫select SYS_NS16550_SERIAL。效果是TARGET_MYBOARD被選中時(shí)SYS_NS16550_SERIAL自動(dòng)被選中不需要用戶手動(dòng)去開。移植時(shí)一個(gè)常見的坑是濫用select。select會(huì)強(qiáng)制打開一個(gè)選項(xiàng)即使那個(gè)選項(xiàng)有depends on條件也不管用這會(huì)導(dǎo)致配置不一致。比如你select了一個(gè)依賴DM的驅(qū)動(dòng)但DM沒開編譯時(shí)就會(huì)出問題。所以select只應(yīng)該用在這個(gè)板子離開這個(gè)功能就活不了的場(chǎng)景而且被select的選項(xiàng)最好不要有復(fù)雜的依賴鏈。注意U-Boot的Kconfig對(duì)select的處理比內(nèi)核寬松不會(huì)強(qiáng)制檢查依賴是否滿足。這意味著錯(cuò)誤使用select時(shí)配置階段不報(bào)錯(cuò)編譯階段才暴露。排查這類問題時(shí)先看auto.conf里被select的項(xiàng)是不是真的為y再看它的依賴項(xiàng)是不是也滿足。3.3 板級(jí)Kconfig該放在哪、寫什么板級(jí)Kconfig的位置有講究。對(duì)于大多數(shù)架構(gòu)板級(jí)配置放在board/vendor/boardname/Kconfig。這個(gè)文件會(huì)被上層board/vendor/Kconfig通過source引入最終匯入配置樹。板級(jí)Kconfig里通常寫這么幾類內(nèi)容板子本身的TARGET_XXX選項(xiàng)、板子特有的硬件配置比如DDR大小、啟動(dòng)介質(zhì)、板子需要的驅(qū)動(dòng)select。不要在這里寫跟板子無關(guān)的通用配置那些應(yīng)該放在架構(gòu)或驅(qū)動(dòng)目錄的Kconfig里。一個(gè)實(shí)際的板級(jí)Kconfig大概長(zhǎng)這樣if TARGET_MYBOARD config SYS_BOARD default myboard config SYS_VENDOR default myvendor config SYS_CONFIG_NAME default myboard config SYS_TEXT_BASE default 0x87800000 config MYBOARD_DDR_SIZE int DDR size in MB default 512 endifSYS_BOARD、SYS_VENDOR、SYS_CONFIG_NAME這三個(gè)是U-Boot構(gòu)建系統(tǒng)約定的變量分別告訴構(gòu)建系統(tǒng)板子名、廠商名、頭文件名。SYS_TEXT_BASE是U-Boot運(yùn)行的起始地址不同芯片不一樣。MYBOARD_DDR_SIZE是自定義配置用int類型讓用戶填數(shù)值。這里有個(gè)細(xì)節(jié)SYS_CONFIG_NAME決定構(gòu)建系統(tǒng)去找include/configs/name.h這個(gè)頭文件。如果你的板子頭文件叫myboard.h這里就必須填myboard否則編譯時(shí)會(huì)提示找不到配置頭文件。這個(gè)頭文件里放的是那些不適合放進(jìn)Kconfig的宏定義比如寄存器基地址、引腳復(fù)用配置。4. Makefile里的obj-y規(guī)則文件是怎么被編進(jìn)去的4.1 obj-y、obj-m、obj-$(CONFIG_XXX)的區(qū)別U-Boot的Makefile里控制文件編譯的核心變量是obj-系列。最常見的是obj-y表示無條件編譯。但實(shí)際移植中你幾乎不會(huì)用裸的obj-y而是用obj-$(CONFIG_XXX)這種形式。obj-$(CONFIG_XXX) foo.o的含義是如果CONFIG_XXX的值為y那么這行展開成obj-y foo.ofoo.o被編譯如果值為n或者未定義展開成obj- foo.o等于沒寫foo.o被跳過。這就是配置和構(gòu)建聯(lián)動(dòng)的關(guān)鍵機(jī)制。obj-m在U-Boot里用得很少因?yàn)閁-Boot基本是靜態(tài)鏈接的不支持內(nèi)核那種模塊機(jī)制。偶爾在工具目錄里會(huì)看到但板級(jí)移植不用管。還有一種寫法是obj-$(CONFIG_XXX) bar/末尾帶斜杠表示這是一個(gè)子目錄構(gòu)建系統(tǒng)會(huì)遞歸進(jìn)入。這個(gè)在組織多文件驅(qū)動(dòng)時(shí)很有用。4.2 板級(jí)Makefile的最小寫法板級(jí)Makefile放在board/vendor/boardname/Makefile內(nèi)容通常很簡(jiǎn)潔obj-$(CONFIG_TARGET_MYBOARD) myboard.o obj-$(CONFIG_TARGET_MYBOARD) ddr_init.o obj-$(CONFIG_TARGET_MYBOARD) spl.o這幾行的意思是當(dāng)TARGET_MYBOARD被選中時(shí)編譯myboard.o、ddr_init.o、spl.o三個(gè)文件。注意這里用的是TARGET_MYBOARD而不是別的因?yàn)榘寮?jí)Makefile的編譯條件就是這塊板子被選中。如果板子目錄下文件很多可以按功能拆成子目錄比如drivers/、ddr/然后在Makefile里寫obj-$(CONFIG_TARGET_MYBOARD) ddr/。子目錄里再寫自己的Makefile規(guī)則一樣。提示板級(jí)Makefile里不要寫跟板子無關(guān)的編譯規(guī)則。有些開發(fā)者圖省事把通用驅(qū)動(dòng)的編譯也塞進(jìn)板級(jí)Makefile結(jié)果換一塊板子就得復(fù)制一遍。正確的做法是把通用驅(qū)動(dòng)放到drivers/下用驅(qū)動(dòng)自己的Kconfig和Makefile管理。4.3 編譯參數(shù)怎么傳ccflags-y和asflags-y有時(shí)候板級(jí)代碼需要特殊的編譯參數(shù)比如指定某個(gè)宏、加某個(gè)頭文件路徑。這些通過ccflags-y和asflags-y傳遞ccflags-y -DCONFIG_MYBOARD_DEBUG ccflags-y -I$(srctree)/board/myvendor/myboard/include asflags-y -DCONFIG_MYBOARD_ASMccflags-y影響C文件編譯asflags-y影響匯編文件。$(srctree)是源碼根目錄的變量構(gòu)建系統(tǒng)自動(dòng)定義用它拼路徑能保證在 out-of-tree 編譯時(shí)也正確。這里有個(gè)容易踩的坑ccflags-y是追加的不是覆蓋的。如果你寫ccflags-y -DFOO會(huì)把構(gòu)建系統(tǒng)默認(rèn)加的參數(shù)全沖掉導(dǎo)致編譯異常。永遠(yuǎn)用。另一個(gè)坑是頭文件路徑。U-Boot的構(gòu)建系統(tǒng)默認(rèn)會(huì)把include/和arch/arch/include/加進(jìn)搜索路徑但板級(jí)私有頭文件不在其中。如果你在板級(jí)代碼里#include myboard.h而這個(gè)頭文件在板級(jí)目錄下用相對(duì)路徑#include myboard.h能編過因?yàn)榫幾g器會(huì)先找源文件所在目錄。但如果頭文件在子目錄里就得用ccflags-y加路徑或者用相對(duì)路徑#include include/myboard.h。5. defconfig的生成與維護(hù)配置快照怎么來的5.1 make xxx_defconfig背后做了什么make xxx_defconfig這個(gè)命令看起來簡(jiǎn)單背后其實(shí)做了好幾件事。首先頂層Makefile會(huì)去configs/目錄找xxx_defconfig文件。找到后調(diào)用scripts/kconfig/conf工具以這個(gè)文件為輸入結(jié)合各層Kconfig的默認(rèn)值生成根目錄下的.config。注意xxx_defconfig里并不是所有配置項(xiàng)都列出來它只列那些跟默認(rèn)值不同的項(xiàng)。conf工具會(huì)先加載所有Kconfig的默認(rèn)值再用defconfig里的值覆蓋最后得到完整的.config。這就是為什么你打開一個(gè)defconfig文件發(fā)現(xiàn)內(nèi)容很少但生成的.config卻很長(zhǎng)。defconfig文件的格式很簡(jiǎn)單就是CONFIG_XXXy或CONFIG_XXXstring或CONFIG_XXX123這種。它不寫# CONFIG_XXX is not set因?yàn)闆]寫的項(xiàng)自動(dòng)取默認(rèn)值。5.2 從零生成一份板級(jí)defconfig給新板子生成defconfig的標(biāo)準(zhǔn)流程是先手動(dòng)創(chuàng)建一個(gè)最小的defconfig只包含最關(guān)鍵的幾項(xiàng)然后make xxx_defconfig再make menuconfig進(jìn)去調(diào)整調(diào)完make savedefconfig生成精簡(jiǎn)版。最小defconfig大概長(zhǎng)這樣CONFIG_ARMy CONFIG_ARCH_MYCHIPy CONFIG_TARGET_MYBOARDy CONFIG_DEFAULT_DEVICE_TREEmyboard CONFIG_SYS_TEXT_BASE0x87800000CONFIG_ARMy指定架構(gòu)CONFIG_ARCH_MYCHIPy指定芯片系列CONFIG_TARGET_MYBOARDy指定板子CONFIG_DEFAULT_DEVICE_TREE指定設(shè)備樹文件名CONFIG_SYS_TEXT_BASE指定運(yùn)行地址。這幾項(xiàng)定了構(gòu)建系統(tǒng)就知道該編哪些文件、用哪個(gè)設(shè)備樹。make savedefconfig是個(gè)好東西它會(huì)把當(dāng)前.config跟默認(rèn)值對(duì)比只輸出差異項(xiàng)生成一個(gè)精簡(jiǎn)的defconfig。你把這個(gè)文件拷到configs/下就是你的板級(jí)defconfig。這樣做的好處是defconfig里只保留真正需要改的項(xiàng)升級(jí)U-Boot版本時(shí)新增的默認(rèn)值不會(huì)跟你的defconfig沖突。注意savedefconfig生成的defconfig默認(rèn)叫defconfig在根目錄下。你需要手動(dòng)cp defconfig configs/myboard_defconfig。別直接改configs/下的文件然后指望它自動(dòng)更新savedefconfig不認(rèn)那個(gè)路徑。5.3 defconfig的版本兼容性坑U-Boot版本升級(jí)時(shí)defconfig最容易出問題。新版本可能刪除了某些配置項(xiàng)、改了某些項(xiàng)的默認(rèn)值、或者新增了必選項(xiàng)。你的老defconfig拿到新版本上跑輕則警告某些項(xiàng)不存在重則編譯失敗。處理這個(gè)問題的經(jīng)驗(yàn)是升級(jí)U-Boot版本后不要直接make old_defconfig然后make。先make old_defconfig再make menuconfig進(jìn)去看看有沒有報(bào)錯(cuò)或警告把廢棄的項(xiàng)去掉把新增的必選項(xiàng)補(bǔ)上最后make savedefconfig重新生成。這個(gè)過程雖然麻煩但能避免很多隱蔽問題。另一個(gè)坑是defconfig里的字符串項(xiàng)。比如CONFIG_DEFAULT_DEVICE_TREEmyboard如果新版本要求這個(gè)值必須跟arch/arm/dts/下的某個(gè).dts文件名匹配而你改了文件名沒改這里編譯時(shí)就會(huì)提示找不到設(shè)備樹。這類問題不會(huì)在配置階段報(bào)錯(cuò)只在構(gòu)建階段暴露排查時(shí)先檢查defconfig里的字符串項(xiàng)跟實(shí)際文件名是否一致。6. 新增一塊板子的完整實(shí)操從目錄創(chuàng)建到編譯通過6.1 目錄結(jié)構(gòu)和文件清單假設(shè)我們要新增一塊板子廠商acme板子名falcon芯片是mychip系列。需要?jiǎng)?chuàng)建和修改的文件如下文件路徑作用操作board/acme/falcon/Kconfig板級(jí)配置項(xiàng)新建board/acme/falcon/Makefile板級(jí)編譯規(guī)則新建board/acme/falcon/falcon.c板級(jí)初始化代碼新建board/acme/Kconfig引入板級(jí)Kconfig修改board/acme/Makefile引入板級(jí)Makefile修改arch/arm/mach-mychip/Kconfig芯片級(jí)配置修改configs/falcon_defconfig板級(jí)配置快照新建arch/arm/dts/falcon.dts設(shè)備樹新建include/configs/falcon.h板級(jí)頭文件新建這個(gè)清單不是絕對(duì)的不同架構(gòu)、不同芯片可能略有差異但大體框架一致。核心思路是板級(jí)的東西放board/下芯片級(jí)的東西放arch/下配置快照放configs/下設(shè)備樹放arch/arm/dts/下。6.2 逐文件編寫與關(guān)鍵點(diǎn)說明先寫board/acme/falcon/Kconfigif TARGET_FALCON config SYS_BOARD default falcon config SYS_VENDOR default acme config SYS_CONFIG_NAME default falcon config SYS_TEXT_BASE default 0x87800000 endif這里if TARGET_FALCON包起來保證只有選中這塊板子時(shí)這些配置才生效。SYS_CONFIG_NAME填falcon對(duì)應(yīng)include/configs/falcon.h。再寫board/acme/falcon/Makefileobj-$(CONFIG_TARGET_FALCON) falcon.o如果板子有SPL再加obj-$(CONFIG_TARGET_FALCON) spl.o。然后寫board/acme/falcon/falcon.c最小實(shí)現(xiàn)是提供一個(gè)board_init函數(shù)#include common.h #include init.h int board_init(void) { /* 板級(jí)初始化比如設(shè)置引腳復(fù)用、初始化時(shí)鐘 */ return 0; }這個(gè)函數(shù)會(huì)在U-Boot啟動(dòng)早期被調(diào)用具體調(diào)用時(shí)機(jī)取決于架構(gòu)。ARM架構(gòu)下通常在board_init_f或board_init_r階段。接著修改board/acme/Kconfig加入source board/acme/falcon/Kconfig修改board/acme/Makefile加入obj-y falcon/注意這里是obj-y不是obj-$(CONFIG_...)因?yàn)槟夸洷旧硪獰o條件進(jìn)入具體編不編由子目錄的Makefile決定。再修改arch/arm/mach-mychip/Kconfig加入config TARGET_FALCON bool Support acme falcon board select MYCHIP_DDR3 select SYS_NS16550_SERIAL help Support for acme falcon board based on mychip.這里select了DDR和串口驅(qū)動(dòng)因?yàn)檫@塊板子必須用到它們。最后寫configs/falcon_defconfigCONFIG_ARMy CONFIG_ARCH_MYCHIPy CONFIG_TARGET_FALCONy CONFIG_DEFAULT_DEVICE_TREEfalcon CONFIG_SYS_TEXT_BASE0x87800000以及include/configs/falcon.h放一些不適合進(jìn)Kconfig的宏#ifndef __FALCON_H #define __FALCON_H #define CONFIG_SYS_INIT_SP_ADDR 0x87800000 #define CONFIG_SYS_LOAD_ADDR 0x88000000 #endif6.3 編譯驗(yàn)證與常見報(bào)錯(cuò)處理文件都建好后執(zhí)行make falcon_defconfig make -j4如果一切順利會(huì)在根目錄生成u-boot.bin。但第一次幾乎不可能一次通過常見報(bào)錯(cuò)和處理方式如下報(bào)錯(cuò)No rule to make target board/acme/falcon/falcon.o說明Makefile里的obj-規(guī)則沒生效。檢查board/acme/Makefile里有沒有obj-y falcon/以及board/acme/falcon/Makefile里的obj-$(CONFIG_TARGET_FALCON)是否拼寫正確。報(bào)錯(cuò)undefined reference to board_init說明falcon.o沒被編進(jìn)去或者board_init函數(shù)簽名不對(duì)。檢查falcon.c里有沒有包含init.h函數(shù)名和參數(shù)是否跟架構(gòu)要求的一致。報(bào)錯(cuò)Cannot find default device tree falcon說明arch/arm/dts/falcon.dts不存在或者defconfig里的CONFIG_DEFAULT_DEVICE_TREE值跟文件名不匹配。檢查文件名和配置值。報(bào)錯(cuò)include/configs/falcon.h: No such file說明SYS_CONFIG_NAME填的值跟頭文件名不一致。檢查board/acme/falcon/Kconfig里的SYS_CONFIG_NAME。提示排查編譯問題時(shí)先看include/config/auto.conf里有沒有你期望的CONFIG_TARGET_FALCONy。如果沒有說明配置階段就出了問題回頭檢查Kconfig的依賴和defconfig。如果有說明配置沒問題問題在Makefile或代碼本身。7. 移植過程中那些文檔不會(huì)寫的經(jīng)驗(yàn)7.1 配置項(xiàng)的可見性調(diào)試技巧Kconfig的依賴關(guān)系復(fù)雜時(shí)一個(gè)配置項(xiàng)在menuconfig里不顯示你很難判斷是依賴沒滿足還是語法寫錯(cuò)了。這時(shí)候可以用make menuconfig里的搜索功能按/輸入配置項(xiàng)名字它會(huì)告訴你這個(gè)項(xiàng)的當(dāng)前值、依賴項(xiàng)、以及為什么不可見。另一個(gè)技巧是直接看include/config/auto.conf。這個(gè)文件是配置的最終結(jié)果所有CONFIG_XXXy都在里面。如果你在menuconfig里選了某項(xiàng)但auto.conf里沒有說明這個(gè)項(xiàng)被別的依賴覆蓋了或者它本身是個(gè)select出來的項(xiàng)但依賴不滿足。還有個(gè)更底層的方法scripts/kconfig/conf --listnewconfig Kconfig可以列出所有配置項(xiàng)及其當(dāng)前值不過輸出很長(zhǎng)適合用grep過濾。7.2 編譯產(chǎn)物分析u-boot.map和System.map編譯通過不代表產(chǎn)物正確。u-boot.map是鏈接器生成的映射文件里面列出了每個(gè)符號(hào)的地址和來源。如果你懷疑某個(gè)函數(shù)沒被鏈接進(jìn)去可以在u-boot.map里搜函數(shù)名看它屬于哪個(gè).o。System.map是符號(hào)表格式是地址 類型 符號(hào)名。調(diào)試啟動(dòng)問題時(shí)如果U-Boot跑飛了串口打印出一個(gè)地址你可以在System.map里反查這個(gè)地址對(duì)應(yīng)哪個(gè)函數(shù)快速定位問題。這兩個(gè)文件在移植階段非常有用尤其是當(dāng)你遇到代碼明明寫了但沒執(zhí)行的情況。先確認(rèn)符號(hào)在不在System.map里在的話看地址對(duì)不對(duì)不在的話回頭查Makefile。7.3 版本升級(jí)時(shí)的Kbuild遷移注意事項(xiàng)U-Boot的Kbuild體系本身也在演進(jìn)。老版本里一些寫法在新版本里可能被廢棄比如早期的CONFIG_SYS_EXTRA_OPTIONS在新版本里被Kconfig選項(xiàng)取代boards.cfg被defconfig取代。升級(jí)版本時(shí)這些遷移點(diǎn)最容易出問題。我的經(jīng)驗(yàn)是升級(jí)前先看U-Boot源碼里的doc/目錄和README里面通常會(huì)說明本版本的重大變更。然后拿一塊已經(jīng)支持的板子做參照對(duì)比它的defconfig、Kconfig、Makefile跟你的有什么差異。最后用make savedefconfig重新生成配置不要手工改.config。另一個(gè)經(jīng)驗(yàn)是升級(jí)時(shí)不要一次性跳太多版本。U-Boot每年發(fā)布好幾個(gè)版本跨版本升級(jí)時(shí)Kbuild的變更可能累積。如果從很老的版本升到最新建議中間找一兩個(gè)過渡版本逐步遷移每次遷移后都編譯驗(yàn)證這樣出問題時(shí)容易定位是哪個(gè)版本引入的。7.4 多板子共用代碼時(shí)的Kconfig組織一個(gè)廠商往往有多塊板子它們共用大量代碼。這時(shí)候Kconfig的組織就很重要。常見的做法是在board/vendor/下建一個(gè)公共的Kconfig定義廠商級(jí)的公共配置然后每塊板子的Kconfig里select這些公共配置。Makefile同理公共代碼放在board/vendor/common/下用obj-y編譯板級(jí)Makefile里通過obj-$(CONFIG_TARGET_XXX) ../common/foo.o引用。不過這種跨目錄引用要小心路徑問題$(srctree)和相對(duì)路徑混用時(shí)容易出錯(cuò)。更清晰的做法是把公共代碼抽到drivers/或arch/下用獨(dú)立的Kconfig管理板級(jí)只負(fù)責(zé)select。這樣代碼歸屬清晰也方便其他廠商復(fù)用。8. 把Kbuild吃透之后移植還剩什么Kbuild是U-Boot移植的入口但不是全部。把構(gòu)建系統(tǒng)跑通只意味著你的代碼能被編進(jìn)去、能生成固件至于固件能不能跑起來還得看時(shí)鐘配置、DDR初始化、引腳復(fù)用、啟動(dòng)介質(zhì)這些硬件相關(guān)的東西。但反過來說如果Kbuild沒搞明白后面這些根本無從談起因?yàn)槟氵B一個(gè)能編譯的基線都沒有。我個(gè)人在移植時(shí)的習(xí)慣是先把Kbuild這條鏈路走通用一個(gè)最小的board_init空函數(shù)確保能編譯出u-boot.bin。然后再逐步往里加DDR初始化、串口輸出、啟動(dòng)參數(shù)。每加一塊功能就編譯一次、燒錄一次、看串口輸出。這樣出問題時(shí)范圍很小容易定位。還有一點(diǎn)U-Boot的Kbuild雖然借自內(nèi)核但細(xì)節(jié)差異不少尤其是defconfig的生成方式和select的行為。遇到問題時(shí)與其去翻內(nèi)核的文檔不如直接看U-Boot源碼里scripts/kconfig/的實(shí)現(xiàn)或者找一塊官方支持的、跟你的板子最接近的板子做參照。參照現(xiàn)成的實(shí)現(xiàn)比從零推導(dǎo)快得多也可靠得多。