1. 先弄懂U-Boot在4412啟動(dòng)鏈中的位置再談源碼結(jié)構(gòu)在4412開發(fā)板上做嵌入式學(xué)習(xí)到了第十篇這個(gè)階段大多已經(jīng)跑過裸機(jī)程序、編過內(nèi)核、燒過文件系統(tǒng)。操作層面熟練之后很容易對(duì)U-Boot產(chǎn)生一種“會(huì)用但沒吃透”的感覺知道它負(fù)責(zé)加載內(nèi)核但不知道它啟動(dòng)時(shí)執(zhí)行了什么能敲命令但不知道命令背后對(duì)應(yīng)哪一段源碼。這篇主要解決的就是uboot源代碼結(jié)構(gòu)問題把整套引導(dǎo)程序拆成功能模塊搞清楚每個(gè)模塊放在哪個(gè)目錄、由誰編譯、怎么被調(diào)用。只有先把結(jié)構(gòu)吃透后面做移植、裁剪、調(diào)試才談得上效率。1.1 看代碼前的啟動(dòng)流程基礎(chǔ)4412是四核Cortex-A9架構(gòu)它的完整啟動(dòng)流程是分層加載的。片上iROM里固化的代碼最先運(yùn)行初始化基礎(chǔ)時(shí)鐘和存儲(chǔ)控制器然后把第一段引導(dǎo)代碼從啟動(dòng)介質(zhì)SD卡、eMMC、USB等加載到片內(nèi)SRAM執(zhí)行這一段通常叫BL1主要作用是把DRAM初始化好。BL1隨后把第二段引導(dǎo)代碼加載到DRAM運(yùn)行這一段才是U-Boot本體在廠商BSP里有時(shí)也直接叫BL2。U-Boot拿到控制權(quán)之后完成更完整的硬件初始化等待命令行交互或者按預(yù)設(shè)指令從啟動(dòng)介質(zhì)讀取內(nèi)核鏡像、設(shè)備樹、啟動(dòng)參數(shù)最后跳轉(zhuǎn)到內(nèi)核入口。這個(gè)流程里有三個(gè)關(guān)鍵點(diǎn)容易忽略。第一BL1和U-Boot往往由同一套源碼產(chǎn)物加工而來或者BL1本身就是廠商固化好的二進(jìn)制所以在U-Boot源碼目錄里不一定能看到完整的BL1實(shí)現(xiàn)它更像一個(gè)介于硬件和U-Boot之間的中間環(huán)節(jié)。第二U-Boot的職責(zé)是“把環(huán)境準(zhǔn)備好、把內(nèi)核請(qǐng)進(jìn)來”所有跟操作系統(tǒng)運(yùn)行無關(guān)的常駐服務(wù)都不是它的任務(wù)所以它的代碼量雖然大但主線非常清晰。第三4412的BSP往往帶了很多廠商定制的驅(qū)動(dòng)和命令源碼結(jié)構(gòu)跟主線標(biāo)準(zhǔn)版不完全一致閱讀前最好先確認(rèn)自己手里的代碼版本和目錄風(fēng)格避免拿主線結(jié)構(gòu)硬套。1.2 為什么要優(yōu)先掌握源碼結(jié)構(gòu)初學(xué)U-Boot最常犯的錯(cuò)誤是把源碼壓縮包當(dāng)成一本小說打算從第一行讀到最后一頁。但一套完整的U-Boot源碼樹動(dòng)輒幾千個(gè)文件、幾十萬行代碼按文件順序翻頁撐不了幾天就會(huì)迷失在drivers或arch目錄里。我之前給同學(xué)的建議都是反過來的先搞懂目錄結(jié)構(gòu)再帶著具體問題去定位代碼。這就跟查字典一樣不需要通讀整本字典但必須知道它的排序規(guī)則和檢索方法。結(jié)構(gòu)本身就是信息?？吹揭粋€(gè)文件在arch/arm/cpu/armv7下面基本能確定它是CPU架構(gòu)相關(guān)的代碼看到它在board/samsung目錄里大概率是和具體板卡硬件初始化強(qiáng)相關(guān)的代碼看到它在common/cmd_*.c里那對(duì)應(yīng)的是某個(gè)命令行命令的實(shí)現(xiàn)。這種“路徑即分類、目錄即模塊”的組織方式是U-Boot能被大量不同平臺(tái)復(fù)用的根本原因。所以掌握結(jié)構(gòu)本質(zhì)上是掌握一套代碼檢索系統(tǒng)后面無論做交叉移植還是功能裁剪都能快速找到下手的位置。2. U-Boot頂層目錄結(jié)構(gòu)全景先建立全局地圖再動(dòng)手把源碼壓縮包解壓后第一件事不是打開某個(gè)文件而是先看目錄。頂層目錄的命名基本就是模塊分類經(jīng)典U-Boot2010.x到2013.x那個(gè)年代和更新一些的主線版本雖然在目錄上有增刪但骨架一直保持穩(wěn)定。對(duì)4412這個(gè)型號(hào)的BSP來說目錄風(fēng)格偏向經(jīng)典結(jié)構(gòu)理解起來反而更直觀。2.1 目錄樹的全局劃分我建議把目錄分組來記不要一個(gè)目錄一個(gè)目錄孤立地看。拿一套比較典型的BSP來說解壓后頂層大致如下/uboot源碼根目錄 ├── arch/ # CPU架構(gòu)相關(guān)代碼ARM、x86、RISC-V等各占一個(gè)子目錄 ├── board/ # 板級(jí)代碼按廠商/開發(fā)板組織 ├── common/ # U-Boot通用邏輯命令框架與公共流程 ├── configs/ # 新版本板級(jí)配置文件入口老版本在include/configs ├── drivers/ # 各類硬件驅(qū)動(dòng)串口、網(wǎng)卡、MMC、USB、顯示等 ├── dts/ # 設(shè)備樹源文件與編譯相關(guān) ├── fs/ # 文件系統(tǒng)支持ext4、fat、jffs2等 ├── include/ # 全局頭文件configs子目錄存放板級(jí)配置文件 ├── lib/ # 通用庫函數(shù)與輔助代碼 ├── net/ # 網(wǎng)絡(luò)協(xié)議棧主要用于tftp、nfs等啟動(dòng)方式 ├── scripts/ # Kconfig配置腳本和構(gòu)建輔助腳本 ├── tools/ # mkimage、fw_printenv等輔助工具源碼 ├── Makefile # 頂層構(gòu)建入口 ├── config.mk # 全局編譯規(guī)則與變量 ├── mkconfig # 經(jīng)典版本配置階段的核心腳本 └── rules.mk # 通用編譯規(guī)則這十幾項(xiàng)可以按職責(zé)分成幾組arch、board、common、drivers、lib、fs、net是源碼本體include是頭文件和配置文件Makefile、config.mk、rules.mk、mkconfig、scripts是構(gòu)建體系tools是輔助工具。閱讀優(yōu)先級(jí)上源碼本體優(yōu)先構(gòu)建體系其次tools最后。2.2 各核心目錄的職能與特點(diǎn)對(duì)4412這種ARM平臺(tái)arch/arm目錄是必看的重點(diǎn)。arch/arm下面繼續(xù)按話題拆分cpu目錄按ARM內(nèi)核分類比如armv7對(duì)應(yīng)Cortex-A系列里面能找到start.S、cpu.c這類核心文件lib目錄放架構(gòu)相關(guān)的內(nèi)存操作、延時(shí)函數(shù)、異常處理等include目錄放架構(gòu)專屬頭文件。你要找“CPU上電后執(zhí)行的第一行代碼”答案就在arch/arm/cpu/armv7/start.S這個(gè)文件被鏈接腳本指定為入口點(diǎn)。board目錄在經(jīng)典U-Boot里是board/廠商/板子這樣的二級(jí)結(jié)構(gòu)比如board/samsung下面可能放著好幾個(gè)型號(hào)的板級(jí)代碼。4412的BSP里這一塊的板級(jí)代碼往往已經(jīng)由廠商準(zhǔn)備好包含板級(jí)初始化的C文件和匯編文件比如lowlevel_init.S、board.c、sd_boot.c等?？吹絙oard目錄要格外注意兩點(diǎn)一是此處的代碼跟著具體板子走不同板子的內(nèi)存容量、時(shí)鐘頻率、引腳定義全在這里體現(xiàn)二是以后燒寫時(shí)碰到某個(gè)外設(shè)不工作十有八九要回到board目錄查配置。drivers目錄最容易讓人迷失因?yàn)轵?qū)動(dòng)數(shù)量太多。閱讀策略是只關(guān)注當(dāng)前板子用到的類別比如MMC、網(wǎng)卡、串口、USB Host這幾個(gè)。44512 BSP里最常見的啟動(dòng)方式是從eMMC/SD卡引導(dǎo)所以drivers/mmc下的代碼優(yōu)先級(jí)會(huì)比較高如果經(jīng)常用tftp下載內(nèi)核drivers/net也要看。驅(qū)動(dòng)目錄的閱讀不需要從頭到尾用到哪個(gè)驅(qū)動(dòng)就深入哪個(gè)其他保持“知道位置”即可。2.3 arch/arm 下與4412最相關(guān)的部分我在實(shí)際閱讀時(shí)會(huì)再把a(bǔ)rch/arm目錄拆細(xì)一些。arch/arm/cpu/armv7/start.S是啟動(dòng)起點(diǎn)負(fù)責(zé)設(shè)置異常向量、切換CPU模式、準(zhǔn)備棧指針如果是較新的源碼還可能看到cpu.c里面放著輔助性的CPU控制函數(shù)。arch/arm/lib里則有board_init_f、board_init_r這類板級(jí)流程入口函數(shù)它們是U-Boot啟動(dòng)主干中的關(guān)鍵節(jié)點(diǎn)。另一個(gè)容易被忽略的是mach或soc目錄。不少BSP會(huì)按廠商平臺(tái)放置獨(dú)立的平臺(tái)代碼目錄里面是時(shí)鐘、內(nèi)存控制器、引腳配置等平臺(tái)級(jí)代碼。這些代碼比board目錄更底層比arch通用代碼更具體正好處于中間層。理解源碼結(jié)構(gòu)時(shí)按“通用架構(gòu)層—平臺(tái)層—板級(jí)層”三層來看arch/arm是通用架構(gòu)層mach/soc是平臺(tái)層board/samsung/xxx是板級(jí)層。對(duì)于4412這樣的定制化板子產(chǎn)品差異和硬件適配問題大多集中在平臺(tái)層和板級(jí)層。3. 4412專屬代碼在哪三步鎖定板級(jí)支撐文件從源碼結(jié)構(gòu)上找到屬于4412這塊板子的代碼是后續(xù)所有移植和裁剪工作的前提。這里分享一套三步定位法先看board目錄再看板級(jí)配置頭文件最后用Makefile確認(rèn)它確實(shí)參與了編譯。按這個(gè)順序走基本不會(huì)漏掉關(guān)鍵文件。3.1 第一步從board目錄找板級(jí)代碼進(jìn)入board目錄找到samsung子目錄里面通常會(huì)有一到多個(gè)板級(jí)目錄。命名風(fēng)格因BSP而異常見的有smdk4412、origen、itop4412這種格式要是不完全一致就找和開發(fā)板型號(hào)最接近的那個(gè)。這個(gè)目錄下一般包含三部分Makefile決定本目錄哪些文件編進(jìn)U-Boot、一個(gè)或幾個(gè)C文件板級(jí)初始化和定制功能以及一個(gè)或幾個(gè)匯編文件如lowlevel_init.S負(fù)責(zé)DRAM和時(shí)鐘等早期硬件配置。查看板級(jí)代碼時(shí)重點(diǎn)看兩件事電源、時(shí)鐘、DDR初始化參數(shù)以及外設(shè)引腳復(fù)用和驅(qū)動(dòng)注冊(cè)情況。4412這類板子的DDR參數(shù)和時(shí)鐘樹極其依賴BSP預(yù)置值亂改board目錄里的數(shù)值很容易讓板子直接變磚。如果BSP還包含sd_boot或mmc相關(guān)文件這些文件通常負(fù)責(zé)啟動(dòng)介質(zhì)初始化它們和BL1的配合關(guān)系比較緊密建議結(jié)合串口啟動(dòng)日志去理解純?cè)创a閱讀階段可以先跳過。3.2 第二步從include/configs找板級(jí)配置在include/configs目錄部分新版本是configs目錄找到對(duì)應(yīng)板子的頭文件這是整個(gè)U-Boot源碼里最重要的配置入口之一。這個(gè)頭文件塞滿了宏定義每個(gè)宏決定一個(gè)模塊是否編譯或一項(xiàng)功能是否啟用。典型的宏包括CONFIG_CMD_MMC、CONFIG_CMD_NET、CONFIG_BOOTCOMMAND、CONFIG_SYS_TEXT_BASE等。初看會(huì)覺得信息密度太大但它的本質(zhì)是一塊“開關(guān)面板”需要的外設(shè)驅(qū)動(dòng)就打開不需要的模塊就裁掉啟動(dòng)參數(shù)在這里寫準(zhǔn)。頭文件里最值得做筆記的幾個(gè)宏直接決定系統(tǒng)能不能啟動(dòng)宏名作用配置錯(cuò)了的后果CONFIG_SYS_TEXT_BASE指定U-Boot鏈接基地址鏡像加載地址錯(cuò)亂必死CONFIG_SYS_INIT_SP_ADDR早期棧指針位置棧覆蓋代碼或數(shù)據(jù)行為詭異CONFIG_BOOTCOMMAND自動(dòng)啟動(dòng)時(shí)執(zhí)行的命令序列自動(dòng)引導(dǎo)失敗或進(jìn)入不了系統(tǒng)CONFIG_BOOTARGS傳給內(nèi)核的命令行參數(shù)內(nèi)核啟動(dòng)參數(shù)錯(cuò)誤外設(shè)失聯(lián)CONFIG_ENV_IS_IN_MMC環(huán)境變量存儲(chǔ)介質(zhì)選擇環(huán)境變量保存不了或加載錯(cuò)亂這些宏在標(biāo)準(zhǔn)U-Boot里基本都有但具體定義方式會(huì)隨版本變化。閱讀舊版本BSP時(shí)還會(huì)看到大量不帶CONFIG_前綴的宏比如USE_4410_BOARD或CFG_XXX之類的舊式寫法這些是歷史版本遺留的叫法作用類似遇到時(shí)別慌。3.3 第三步順著Makefile確認(rèn)編譯參與情況U-Boot里一個(gè)源文件是否編進(jìn)最終鏡像不只看文件在不在目錄里還要看目錄內(nèi)的Makefile有沒有引用它。打開board目錄下的Makefile能看到obj-y、obj-$(CONFIG_XXX)這類寫法。obj-y表示無條件編譯obj-$(CONFIG_XXX)表示只有當(dāng)對(duì)應(yīng)配置宏打開時(shí)才編譯。通過Makefile既可以確認(rèn)哪些文件參與了構(gòu)建也能學(xué)會(huì)改配置的正確姿勢(shì)增加驅(qū)動(dòng)文件就添加obj-y條目或者在板級(jí)配置頭文件里打開對(duì)應(yīng)CONFIG宏。經(jīng)典U-Boot里還經(jīng)常出現(xiàn)COBJS-y、SOBJS-y這類歷史寫法分別代表C目標(biāo)文件和匯編目標(biāo)文件職責(zé)和obj-y一樣只是不同版本的命名習(xí)慣不同。理解了這些細(xì)節(jié)之后你甚至可以從源碼結(jié)構(gòu)推算出最終U-Boot鏡像里包含哪些功能配置頭文件定義開關(guān)Makefile決定文件與開關(guān)的對(duì)應(yīng)關(guān)系兩者結(jié)合一目了然。4. 從make到.bin構(gòu)建系統(tǒng)如何把零散源碼組織成固件源碼結(jié)構(gòu)不只是目錄布局構(gòu)建系統(tǒng)也屬于結(jié)構(gòu)的一部分。很多人在源碼里找不到頭緒問題往往出在不了解U-Boot的構(gòu)建流程。經(jīng)典U-Boot的構(gòu)建分兩個(gè)大階段配置階段和編譯階段。把這兩個(gè)階段的流程走一遍目錄結(jié)構(gòu)和構(gòu)建方式就串起來了。4.1 配置階段的流程配置階段通常執(zhí)行“make _config”這樣的命令比如make smdk4412_config。這一步并不真正編譯代碼而是執(zhí)行根目錄下的mkconfig腳本完成幾件事根據(jù)board、cpu、soc等參數(shù)生成include/config.mk文件記錄板級(jí)和架構(gòu)信息生成include/config.h文件把板級(jí)配置頭文件引入進(jìn)來生成后續(xù)編譯要用的各種中間配置。一句話總結(jié)配置階段就是把“這塊板子是什么、用哪套配置”固化到構(gòu)建系統(tǒng)能讀取的文件里。實(shí)戰(zhàn)中如果改了板級(jí)頭文件里的宏光執(zhí)行make往往不會(huì)重新觸發(fā)配置舊配置殘留會(huì)導(dǎo)致新改動(dòng)不生效或者出現(xiàn)和改動(dòng)無關(guān)的詭異編譯錯(cuò)誤。我在操作時(shí)習(xí)慣改成“make distclean再make xxx_config最后make”全套流程雖然多花一點(diǎn)時(shí)間但能避免大量莫名其妙的問題。特別提醒如果你同時(shí)改了交叉編譯工具鏈路徑一定要在頂層Makefile里確認(rèn)CROSS_COMPILE變量否則后面編譯到一半才報(bào)錯(cuò)更難排查。4.2 編譯階段的構(gòu)成配置完成后執(zhí)行make頂層Makefile開始真正發(fā)揮作用。它讀取include/config.mk、config.mk、rules.mk等文件解析編譯工具鏈、編譯選項(xiàng)、目標(biāo)文件列表然后遞歸進(jìn)入各個(gè)子目錄生成.o文件最后通過鏈接腳本把所有目標(biāo)文件鏈接成ELF格式的u-boot再用objcopy生成純二進(jìn)制的u-boot.bin。部分BSP還會(huì)繼續(xù)執(zhí)行自定義腳本給鏡像添加頭部信息或拆分成適合燒寫的多個(gè)文件。閱讀頂層Makefile不需要逐行讀抓住幾個(gè)關(guān)鍵變量即可。CROSS_COMPILE是交叉編譯工具鏈前綴CONFIG_SYS_TEXT_BASE或TEXT_BASE是鏈接基地址LDSCRIPT指向鏈接腳本位置MKIMAGE對(duì)應(yīng)tools目錄下的鏡像工具。理解這些變量之后改工具鏈、改內(nèi)存地址、改鏡像生成方式都能快速找到對(duì)應(yīng)位置。還要注意頂層Makefile里可能會(huì)有“目標(biāo)幫助”注釋列出各種板子的config目標(biāo)名想知道當(dāng)前BSP支持哪些板子直接看這段列表就行。4.3 鏈接腳本和鏡像產(chǎn)物的來龍去脈鏈接腳本在源碼里一般放在CPU或board目錄下文件名通常是u-boot.lds或u-boot.lds.S。它規(guī)定了輸出文件的段布局最關(guān)鍵的是入口點(diǎn)和第一個(gè)段的起始位置。對(duì)ARM平臺(tái)來說鏈接腳本開頭基本會(huì)把.text段的起始地址設(shè)置為CONFIG_SYS_TEXT_BASE對(duì)應(yīng)的值然后讓start.S所在的第一個(gè)目標(biāo)文件排在最前面。u-boot.lds里還能看到.text、.rodata、.data、.bss等段的排列順序這些排布直接決定鏡像在內(nèi)存里的實(shí)際布局。編譯完成后源碼根目錄會(huì)出現(xiàn)一堆產(chǎn)物。u-boot是ELF格式的調(diào)試鏡像里面有完整的符號(hào)信息GDB調(diào)試時(shí)用它u-boot.bin是去掉ELF頭的純二進(jìn)制鏡像燒寫用這個(gè)u-boot.map記錄每個(gè)符號(hào)被鏈接到的地址查函數(shù)入口、確認(rèn)代碼段大小、分析鏈接地址沖突都靠它。有些BSP還會(huì)生成u-boot.img、u-boot.bin等帶頭部格式的文件這些通常由tools/mkimage加工具體格式跟BSP腳本相關(guān)。建議每次編譯完都瞄一眼u-boot.map開頭的內(nèi)存布局時(shí)間長了能建立起非常扎實(shí)的地址感。5. 啟動(dòng)流程在源碼中的對(duì)應(yīng)關(guān)系和閱讀路徑看懂了目錄和構(gòu)建下一步要把這些知識(shí)和代碼串聯(lián)起來。U-Boot的啟動(dòng)流程不是抽象的它的每一步都能在源碼里找到對(duì)應(yīng)實(shí)現(xiàn)?！鞍戳鞒陶掖a”是嵌入式源碼閱讀的核心能力掌握之后調(diào)試效率會(huì)明顯提升。5.1 從start.S開始的早期初始化CPU上電復(fù)位后會(huì)從鏈接腳本指定的入口進(jìn)入start.S。這個(gè)匯編文件通常會(huì)做這些事設(shè)置異常向量表切換CPU到SVC模式并關(guān)中斷初始化關(guān)鍵的狀態(tài)寄存器如果啟動(dòng)介質(zhì)需要還會(huì)做一部分SoC層面的早期初始化最后設(shè)置當(dāng)前執(zhí)行環(huán)境的棧指針。對(duì)4412來說start.S里可能會(huì)回調(diào)板級(jí)代碼完成DRAM初始化這個(gè)回調(diào)函數(shù)就是lowlevel_init這也是board目錄下存在lowlevel_init.S文件的原因。閱讀start.S時(shí)容易被大段的條件編譯和宏定義擋住視線。我個(gè)人的做法是先抽出整體流程不逐行死磕匯編入口在哪、哪些是CPU通用流程、哪些是CONFIG宏控制的板級(jí)差異。等真遇到啟動(dòng)異常再回頭針對(duì)具體寄存器逐行分析。匯編代碼里的注釋一般比較少遇到不懂的寄存器和位域操作同步打開芯片手冊(cè)對(duì)照看效率最高。5.2 板級(jí)初始化和重定位早期初始化完成后啟動(dòng)流程進(jìn)入C語言階段。經(jīng)典U-Boot的路徑大致是start.S調(diào)用board_init_f完成早期的板級(jí)初始化比如串口、時(shí)鐘、DRAM等然后在內(nèi)存里準(zhǔn)備新的棧和環(huán)境接著執(zhí)行代碼重定位把U-Boot自身搬運(yùn)到運(yùn)行地址之后調(diào)用board_init_r完成板級(jí)后期初始化建立完整的運(yùn)行環(huán)境最終進(jìn)入main_loop在那里實(shí)現(xiàn)命令行交互和自動(dòng)啟動(dòng)邏輯。這里的board_init_f和board_init_r名字里就帶著“board”字樣說明它們都是板級(jí)頂層入口。這兩個(gè)函數(shù)通常定義在arch/arm/lib/board.c或相近位置內(nèi)部會(huì)調(diào)用一系列指向板級(jí)目錄的回調(diào)函數(shù)。之前強(qiáng)調(diào)過board目錄要重點(diǎn)看真正原因就在這里啟動(dòng)流程的骨架是通用的但具體板子的硬件動(dòng)作全部落在board目錄的回調(diào)里。閱讀時(shí)先看board_init_f調(diào)用了哪些板級(jí)回調(diào)再順著回調(diào)進(jìn)board目錄整個(gè)啟動(dòng)鏈路就串起來了。5.3 如何根據(jù)啟動(dòng)日志反查代碼位置調(diào)試階段最實(shí)用的技能是通過串口日志反推代碼路徑。U-Boot啟動(dòng)時(shí)會(huì)打印大量日志包括版本信息、DRAM容量、啟動(dòng)介質(zhì)、環(huán)境變量加載狀態(tài)等。每個(gè)日志字符串都能在源碼里用搜索找到唯一出處。如果在日志里看到“Board init”或者“MMC init”這類關(guān)鍵字直接用字符串搜索定位到打印函數(shù)往往就能順藤摸瓜找到整個(gè)初始化鏈。這個(gè)方法比盲目讀源碼高效很多因?yàn)樗怯脤?shí)際運(yùn)行結(jié)果來指導(dǎo)閱讀方向的。錯(cuò)誤信息日志同樣很有價(jià)值。U-Boot源碼的錯(cuò)誤路徑一般都會(huì)打印字符串比如“mmc init failed”“Invalid boot device”。看到這類日志后搜索對(duì)應(yīng)字符串可以直接定位到出錯(cuò)分支再分析為什么會(huì)走到錯(cuò)誤分支比在代碼里瞎猜準(zhǔn)得多。實(shí)際操作中還要注意打印緩沖區(qū)和串口波特率的匹配問題很多“啟動(dòng)卡死”其實(shí)只是串口配置沒對(duì)上并不代表代碼真的跑飛了。6. 源碼閱讀中常見的坑和排查方法源碼結(jié)構(gòu)搞清楚了實(shí)際應(yīng)用里還是會(huì)碰到一堆頭疼問題。這里列幾個(gè)我見過最多的情況以及對(duì)應(yīng)的排查思路權(quán)當(dāng)一份速查表。6.1 配置文件改了卻不生效這類問題幾乎每天都能遇到。改完板級(jí)頭文件重新make發(fā)現(xiàn)改動(dòng)沒生效或者編譯報(bào)錯(cuò)提示宏未定義。常見原因有兩個(gè)一是沒有清除舊的配置產(chǎn)物include/config.h和include/config.mk還是老版本構(gòu)建系統(tǒng)讀到的仍然是舊內(nèi)容二是宏定義本身存在依賴關(guān)系某個(gè)宏需要依賴另一組宏先定義順序不對(duì)就會(huì)失效。解決辦法是執(zhí)行make distclean重新走配置和編譯的全流程。如果還不行就檢查板級(jí)頭文件是否真的被include/config.h引用了路徑寫沒寫對(duì)有沒有因版本差異而放在其他目錄。6.2 符號(hào)找不到和鏈接錯(cuò)誤U-Boot鏈接錯(cuò)誤最常見的是undefined reference。這類問題一般和Makefile對(duì)象列表或配置宏有關(guān)某個(gè)目標(biāo)文件調(diào)用了函數(shù)但定義這個(gè)函數(shù)的源文件沒有參與編譯鏈接自然找不到符號(hào)。排查步驟是先在源碼里搜索函數(shù)定義在哪個(gè)文件再去該目錄下的Makefile確認(rèn)文件是否參與編譯如果沒參與判斷它應(yīng)該無條件編譯還是由某個(gè)CONFIG宏控制然后在板級(jí)配置頭文件里打開宏。宏已經(jīng)打開還不行時(shí)嘗試clean后重新編譯因?yàn)榕f的目標(biāo)文件可能沒被重新構(gòu)建這也是新手最容易忽視的。6.3 合理使用搜索工具在幾十萬行代碼里找函數(shù)靠肉眼翻文件不現(xiàn)實(shí)。C語言源碼的查找順序一般是先在當(dāng)前目錄搜再在上級(jí)目錄擴(kuò)大范圍然后查include頭文件最后全源碼搜。常用命令是grep -rn和grep -rln分別用來搜內(nèi)容和只列文件。建議在源碼根目錄生成tags和cscope數(shù)據(jù)庫配合編輯器使用跳轉(zhuǎn)效率會(huì)提升一個(gè)檔次。搜索時(shí)注意區(qū)分函數(shù)聲明、定義、調(diào)用三種場(chǎng)景搜“函數(shù)名 (”和單獨(dú)搜函數(shù)名的結(jié)果差別很大用正則過濾掉注釋和聲明能少看很多噪音。還有幾個(gè)搜索時(shí)容易踩的細(xì)節(jié)宏里嵌套宏函數(shù)通過函數(shù)指針間接調(diào)用不同目錄下同名文件。碰到搜索出多個(gè)結(jié)果時(shí)多看一眼文件路徑前綴路徑通常能幫你判斷當(dāng)前平臺(tái)真正用的是哪一個(gè)。尤其要注意一個(gè)函數(shù)可能在arch、board、include三個(gè)目錄各出現(xiàn)一次實(shí)際生效的那個(gè)由鏈接腳本和Makefile共同決定不能只看搜索順序。6.4 編譯工具鏈和主機(jī)平臺(tái)相關(guān)的坑在Windows環(huán)境下折騰U-Boot源碼比Linux環(huán)境麻煩得多最直接的問題就是mkconfig等腳本依賴shell環(huán)境換行符轉(zhuǎn)換、路徑分隔符不一致都會(huì)導(dǎo)致配置階段失敗。即使強(qiáng)行通過后續(xù)編譯也可能出現(xiàn)莫名報(bào)錯(cuò)。我的建議是優(yōu)先在Linux環(huán)境或WSL里操作工具鏈?zhǔn)褂门cBSP配套的交叉編譯器版本太新或太舊都可能導(dǎo)致某條匯編指令或內(nèi)嵌匯編語法不兼容。遇到編譯告警不用太緊張U-Boot老版本對(duì)告警的容忍度很高但如果告警里出現(xiàn)“missing binary operator”這類預(yù)處理錯(cuò)誤多半是配置宏或頭文件包含順序出了問題。7. 一份更省時(shí)間的源碼閱讀路線最后給出我總結(jié)的閱讀順序主打“先框架、后細(xì)節(jié)、再擴(kuò)展”的思路避免走彎路。7.1 從主線開始向外擴(kuò)展不建議從鏈接腳本、Makefile、start.S一頭扎進(jìn)去死磕雖然這些是入口但信息密度太大新手很容易看崩潰。建議按這個(gè)順序做三輪閱讀先梳理啟動(dòng)流程整體框架知道BL1、U-Boot、內(nèi)核三者如何接力。再讀板級(jí)配置頭文件把關(guān)鍵宏和它們的作用整理出來。通過串口啟動(dòng)日志建立“現(xiàn)象—日志—源碼”的對(duì)應(yīng)關(guān)系。這三件事做完后再回頭啃start.S和board_init_f/board_init_r。這時(shí)候你已經(jīng)知道每一段代碼在為什么服務(wù)讀起來負(fù)擔(dān)小很多。之后再進(jìn)入命令實(shí)現(xiàn)、驅(qū)動(dòng)框架、環(huán)境變量機(jī)制等外圍模塊就屬于按需深入了。7.2 閱讀時(shí)建立自己的代碼地圖學(xué)習(xí)過程中建議把目錄結(jié)構(gòu)、關(guān)鍵文件、關(guān)鍵函數(shù)、關(guān)鍵宏記成一個(gè)自己的筆記形式不限紙質(zhì)、電子文檔、思維導(dǎo)圖都可以。筆記里可以寫“改內(nèi)存頻率去board目錄的哪個(gè)文件”“改啟動(dòng)參數(shù)去配置頭文件搜CONFIG_BOOTARGS”“想加命令去common目錄看cmd_*文件怎么注冊(cè)命令”。這些記錄本質(zhì)上是在把U-Boot源碼的“目錄索引”升級(jí)成“功能索引”以后移植或者裁剪時(shí)這套索引比讀十遍源碼都管用。我自己的習(xí)慣是把每一塊板子對(duì)應(yīng)的關(guān)鍵信息單獨(dú)建一頁上面記著DDR初始化參數(shù)所在文件、啟動(dòng)介質(zhì)配置宏、環(huán)境變量存儲(chǔ)位置、常用編譯命令和燒寫命令。換一塊板子做項(xiàng)目時(shí)直接復(fù)制模板再修改能省掉大量重復(fù)摸索的時(shí)間。7.3 版本差異是常態(tài)別老想著一步到位最后提醒一點(diǎn)不同版本的U-Boot之間目錄組織、宏命名、Makefile寫法都有差異。4412的BSP和一些主線版本的差異尤其明顯這是正?，F(xiàn)象。面對(duì)一份新源碼時(shí)先花半小時(shí)確認(rèn)它的目錄風(fēng)格屬于哪個(gè)年代再?zèng)Q定用哪套查找策略比一開始就套用記憶里的舊經(jīng)驗(yàn)可靠得多。只要掌握“配置頭文件控開關(guān)、Makefile管參與、arch管架構(gòu)、board管板級(jí)差異”這個(gè)核心框架任何U-Boot源碼樹都能較快上手。我在反復(fù)對(duì)照源碼結(jié)構(gòu)和實(shí)際啟動(dòng)流程之后最大的體會(huì)是U-Boot這種項(xiàng)目把它只當(dāng)成“會(huì)用”的工具時(shí)能力邊界是很有限的一旦把它當(dāng)成一部可翻閱的代碼大百科能獲取的信息量會(huì)成倍增加很多問題根本不用四處搜索自己查看源碼就能找到答案。源碼目錄結(jié)構(gòu)就是這部大百科的目錄索引花點(diǎn)時(shí)間把索引摸熟后面無論是繼續(xù)深入設(shè)備驅(qū)動(dòng)還是研究環(huán)境變量存儲(chǔ)都會(huì)順暢得多。