1. 全編譯的痛為什么內(nèi)核必須學(xué)會(huì)單獨(dú)編我先說(shuō)一個(gè)真實(shí)的開(kāi)發(fā)場(chǎng)景。你手里有一塊RK3588的開(kāi)發(fā)板跑Android12玩到第三天需求來(lái)了屏幕模組換了一家觸摸IC改了一個(gè)型號(hào)或者要在板子上外接一顆新的音頻Codec。這些改動(dòng)落到代碼層面全是設(shè)備樹(shù)、內(nèi)核config、內(nèi)核驅(qū)動(dòng)的事情。你要是老老實(shí)實(shí)每次全編譯一遍Android12第一次全量構(gòu)建哪怕是i9級(jí)別的機(jī)器加上NVMe固態(tài)也得兩個(gè)小時(shí)起步。后面每次增量編譯運(yùn)氣好半小時(shí)運(yùn)氣差碰到公共頭文件變了又是四十分鐘起步。一天下來(lái)有效工作時(shí)間全耗在等編譯上。更麻煩的是全編譯還會(huì)被無(wú)關(guān)問(wèn)題打斷。你改的是內(nèi)核dts但系統(tǒng)鏡像里某個(gè)JAVA模塊因?yàn)榫W(wǎng)絡(luò)拉包失敗掛了整個(gè)make流程終止你連驗(yàn)證內(nèi)核的機(jī)會(huì)都沒(méi)有。單獨(dú)編譯內(nèi)核就沒(méi)有這個(gè)問(wèn)題它只關(guān)心arch/arm64下的東西所有和系統(tǒng)應(yīng)用層、framework層無(wú)關(guān)的構(gòu)建都不會(huì)觸發(fā)。再算一筆燒錄賬。全編譯產(chǎn)物是一個(gè)完整的update.img動(dòng)輒兩三GB用RKDevTool燒錄復(fù)制加寫(xiě)入要等好幾分鐘。而單獨(dú)編譯內(nèi)核最終產(chǎn)物就是幾十MB的boot.img和幾MB的resource.img燒錄時(shí)間按秒算。調(diào)試階段一天可能要燒幾十次這個(gè)時(shí)間差累積下來(lái)非?？捎^的。所以我說(shuō)單獨(dú)編內(nèi)核和單獨(dú)燒內(nèi)核是玩RK3568/RK3588 Android12的必修課沒(méi)有人會(huì)每次全量編譯整個(gè)系統(tǒng)來(lái)驗(yàn)證一個(gè)dts修改。下面這套流程我跑了很多遍RK3568和RK3588通用環(huán)境變量那些坑基本都踩過(guò)了照著做就行。2. 動(dòng)手前先看清家底SDK內(nèi)核目錄、工具鏈與三分鐘檢查清單2.1 SDK里四個(gè)你真正需要關(guān)心的位置Rockchip的Android12 SDK解壓之后目錄龐大得能勸退新人但編譯內(nèi)核真正需要關(guān)心的位置只有四個(gè)第一個(gè)是內(nèi)核源碼目錄。用ls -d kernel-*查一下常見(jiàn)的是kernel-4.19或kernel-5.10。RK3568在Android12上多數(shù)SDK給的是kernel-4.19RK3588則兩種都可能出現(xiàn)這取決于你什么時(shí)候從Rockchip或方案商拿到的SDK。千萬(wàn)不要憑芯片型號(hào)去猜內(nèi)核目錄直接看SDK里實(shí)際存在什么。有些定制板卡方案商還會(huì)直接改內(nèi)核大版本所以這一步不要省。第二個(gè)是交叉工具鏈目錄。Android12 SDK里通常自帶prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/這是Rockchip用來(lái)編譯內(nèi)核的GCC工具鏈。注意它和編譯Android系統(tǒng)應(yīng)用層用的Clang不是一回事別混了。后面會(huì)有專(zhuān)門(mén)章節(jié)講工具鏈混用的問(wèn)題。第三個(gè)是板級(jí)配置目錄device/rockchip/。你燒錄時(shí)查partition分區(qū)表要用的parameter文件、產(chǎn)品mk文件都在這。不同產(chǎn)品、不同芯片的parameter內(nèi)容不一樣后續(xù)燒錄offset要從這里查。第四個(gè)是固件二進(jìn)制目錄rkbin/。里面放的是Rockchip的loader等二進(jìn)制比如RK3588的SPL loader燒錄時(shí)如果板子狀態(tài)異常需要用rkdeveloptool db加載它。另外還有一個(gè)rockdev/目錄SDK構(gòu)建完成后可燒錄鏡像會(huì)軟鏈接到這里。很多時(shí)候./mkimage.sh打包完boot.img和resource.img就出現(xiàn)在這里不用去out目錄里翻。2.2 編譯器選型先走通GCC再考慮ClangAndroid12是個(gè)分水嶺。Google在AOSP層面已經(jīng)移除了GCC編譯內(nèi)核的支持全面切換Clang/LLVM。但Rockchip的SDK保留了兩條路GCC和Clang都能編。GCC 4.9路徑Rockchip默認(rèn)流程。SDK自帶的腳本、文檔、示例全都默認(rèn)指向它兼容性最好。我認(rèn)為90%的場(chǎng)景都應(yīng)該先用GCC跑通尤其是新手不要在工具鏈選型上給自己加難度。Clang路徑只有在驗(yàn)證編譯器相關(guān)問(wèn)題、追查某些只有Clang才能復(fù)現(xiàn)的bug、或者要編Google主線內(nèi)核時(shí)才需要考慮切Clang。我一直強(qiáng)調(diào)這個(gè)順序的原因很簡(jiǎn)單單獨(dú)編譯內(nèi)核這件事本身已經(jīng)有足夠多的變量了環(huán)境變量、defconfig、打包、燒錄工具鏈再引入一個(gè)變量出問(wèn)題時(shí)你根本不知道是代碼問(wèn)題還是編譯器問(wèn)題。先把GCC跑通后續(xù)進(jìn)化成Clang也是順手的事。2.3 三分鐘檢查清單正式編譯之前花三分鐘確認(rèn)環(huán)境能幫你省下后面一小時(shí)的排錯(cuò)時(shí)間# 1. 確認(rèn)內(nèi)核目錄看當(dāng)前SDK是kernel-4.19還是kernel-5.10 ls -d kernel-* # 預(yù)期輸出: kernel-5.10 # 2. 確認(rèn)工具鏈目錄存在 ls prebuilts/gcc/linux-x86/aarch64/ # 預(yù)期輸出: aarch64-linux-android-4.9 # 3. 確認(rèn)主機(jī)有make/gcc等基礎(chǔ)工具 which make gcc # 預(yù)期輸出: /usr/bin/make /usr/bin/gcc # 4. 磁盤(pán)余量檢查建議留20GB以上 df -h關(guān)于磁盤(pán)多說(shuō)一句。很多人的機(jī)器全編完Android12之后剩余空間其實(shí)已經(jīng)很緊張。內(nèi)核編譯雖然沒(méi)有整包構(gòu)建那么夸張但也會(huì)在當(dāng)前內(nèi)核目錄下生成大量.o文件如果磁盤(pán)滿(mǎn)了報(bào)錯(cuò)信息五花八門(mén)編譯器寫(xiě)到一半說(shuō)No space left on device你很容易誤判成代碼問(wèn)題。我的底線是至少留20GB余量有條件留50GB最穩(wěn)妥。3. 內(nèi)核單獨(dú)編譯完整流程從defconfig到boot.img與resource.img3.1 環(huán)境變量初始化三行export是全部前提假設(shè)SDK根目錄變量為SDK_ROOT當(dāng)前內(nèi)核目錄是kernel-5.10。kernel-4.19的操作一模一樣只是目錄名不同。直接照抄cd $SDK_ROOT/kernel-5.10 export ARCHarm64 export CROSS_COMPILE$SDK_ROOT/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin/aarch64-linux-android- export PATH$SDK_ROOT/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin:$PATH這三行的作用分別是ARCHarm64告訴Makefile當(dāng)前編譯目標(biāo)的CPU架構(gòu)是arm64而不是你主機(jī)默認(rèn)的x86。CROSS_COMPILE指定交叉編譯器的完整路徑前綴。Makefile會(huì)把$(CROSS_COMPILE)gcc拼成要執(zhí)行的編譯器名稱(chēng)。PATH把工具鏈bin目錄加到最前面保證make在找工具鏈時(shí)優(yōu)先命中SDK自帶的版本而不是宿主機(jī)的其他交叉編譯器。如果你一定要用Clang把CROSS_COMPILE換成下面這樣同時(shí)保留前面兩行export CCclang export CLANG_TRIPLEaarch64-linux-gnu-但我在前面已經(jīng)說(shuō)了新手先別碰Clang這里只做展示。3.2 生成內(nèi)核配置rockchip_defconfig的選擇與驗(yàn)證配置生成就一條命令make rockchip_defconfig它會(huì)把a(bǔ)rch/arm64/configs/rockchip_defconfig展開(kāi)成當(dāng)前目錄下的.config。Rockchip的這套匯總defconfig本身會(huì)通過(guò)Kconfig機(jī)制根據(jù)芯片型號(hào)打開(kāi)對(duì)應(yīng)的配置項(xiàng)所以RK3568和RK3588在Android12平臺(tái)下都用這個(gè)名字。這里有一個(gè)重要的驗(yàn)證步驟做完后不要急著往下編。直接搜config文件確認(rèn)芯片對(duì)應(yīng)的配置項(xiàng)真的打開(kāi)了grep -E CONFIG_ROCKCHIP_RK3588|CONFIG_ROCKCHIP_RK3568 .config你編譯RK3588預(yù)期看到CONFIG_ROCKCHIP_RK3588y編譯RK3568預(yù)期看到CONFIG_ROCKCHIP_RK3568y。如果兩個(gè)都不是說(shuō)明defconfig沒(méi)選對(duì)你的芯片繼續(xù)往下編譯只會(huì)得到一個(gè)起不來(lái)的內(nèi)核。這個(gè)坑我在早期換SDK版本時(shí)踩過(guò)一次浪費(fèi)了整整半天。如果只是為了編譯做到這一步就夠了。但如果你還想去掉默認(rèn)沒(méi)打開(kāi)的某些驅(qū)動(dòng)或者臨時(shí)打開(kāi)某個(gè)調(diào)試選項(xiàng)可以順手做一次圖形化配置make menuconfigmenuconfig需要系統(tǒng)裝了ncurses庫(kù)沒(méi)有的話先sudo apt install libncurses5-dev libncursesw5-dev。改完配置后如果你希望下次編譯還保留這些改動(dòng)需要把改動(dòng)保存回defconfig否則下次make rockchip_defconfig會(huì)把你的修改覆蓋掉。保存的方法是make savedefconfig生成的精簡(jiǎn)defconfig再手動(dòng)覆蓋到arch/arm64/configs/rockchip_defconfig。這一步很多新手會(huì)漏掉建議養(yǎng)成習(xí)慣。3.3 執(zhí)行編譯Image和dtbs.img兩個(gè)目標(biāo)缺一不可配置就緒后執(zhí)行make -j$(nproc) Image dtbs.img這里有兩個(gè)目標(biāo)各有各的用處Image編譯生成的arm64內(nèi)核鏡像最終產(chǎn)物在arch/arm64/boot/Image。dtbs.img把當(dāng)前平臺(tái)相關(guān)的dts編譯成dtb再打包成Rockchip的resource.img格式。最終產(chǎn)物在當(dāng)前內(nèi)核目錄下名字就是resource.img。為什么要兩個(gè)一起編因?yàn)锳ndroid12平臺(tái)上內(nèi)核Image和dtb/resource是分開(kāi)打包、分開(kāi)燒錄的。你光編Image不編dtbs.img改了dts也白改。反過(guò)來(lái)如果只編dtbs.img不編Image內(nèi)核代碼的改動(dòng)又進(jìn)不去。兩個(gè)一起編最省事。關(guān)于并發(fā)數(shù)-j$(nproc)nproc會(huì)返回CPU邏輯核心數(shù)常規(guī)情況下直接用沒(méi)問(wèn)題。但如果你的機(jī)器內(nèi)存小于16GB建議手動(dòng)降級(jí)用-j8甚至-j4。內(nèi)核編譯是純CPU密集型任務(wù)每個(gè)并發(fā)編譯任務(wù)會(huì)吃掉幾百M(fèi)B內(nèi)存內(nèi)存不夠時(shí)會(huì)被OOM Killer直接殺掉報(bào)錯(cuò)信息看起來(lái)像是代碼問(wèn)題實(shí)際是內(nèi)存不夠。我在8GB老機(jī)器上踩過(guò)一次教訓(xùn)深刻。編譯結(jié)束后確認(rèn)兩個(gè)關(guān)鍵產(chǎn)物都生成了ls -lh arch/arm64/boot/Image resource.img正常情況下Image大小在30-50MB之間resource.img根據(jù)dtb數(shù)量和logo文件大小在幾百KB到幾MB之間。如果只有Image沒(méi)有resource.img說(shuō)明dtbs.img目標(biāo)沒(méi)執(zhí)行成功回去看編譯日志。3.4 打包boot.img兩種方式看你的環(huán)境支持哪個(gè)到這里你已經(jīng)有了Image和resource.img但還不能直接燒錄。RKDevTool和rkdeveloptool燒錄認(rèn)的是分區(qū)鏡像boot分區(qū)需要把Image和ramdisk打包成boot.img。打包有兩條路。方式一用SDK根目錄的mkimage.sh。這是最省事的方式。先回到SDK根目錄再執(zhí)行cd $SDK_ROOT ./mkimage.shmkimage.sh會(huì)掃描你剛編譯的內(nèi)核產(chǎn)物找到Image和resource.img后將它們和ramdisk一起打包成boot.img和resource.img輸出到out/target/product目錄以及rockdev目錄。它的優(yōu)點(diǎn)是處理了所有依賴(lài)關(guān)系resource.img也會(huì)重新生成好。缺點(diǎn)是這個(gè)腳本依賴(lài)之前l(fā)unch過(guò)的產(chǎn)品環(huán)境。如果你是在一個(gè)干凈終端里直接跑它可能會(huì)默認(rèn)用某個(gè)產(chǎn)品配置最后打包出來(lái)的鏡像和你板子實(shí)際用的分區(qū)表對(duì)不上。所以如果你發(fā)現(xiàn)mkimage.sh生成的boot.img路徑不對(duì)多半是shell環(huán)境缺了產(chǎn)品信息。方式二手動(dòng)用mkbootimg。更可控但需要找到mkbootimg工具而且需要手動(dòng)指定ramdisk.img。先找到工具find $SDK_ROOT -name mkbootimg -type f 2/dev/null通常它存在于out/host/linux-x86/bin/mkbootimg前提是你完整編譯過(guò)系統(tǒng)或者在rkbin/tools/mkbootimg。找到后$SDK_ROOT/out/host/linux-x86/bin/mkbootimg \ --kernel $SDK_ROOT/kernel-5.10/arch/arm64/boot/Image \ --ramdisk $SDK_ROOT/out/target/product/rk3588/ramdisk.img \ -o boot.img注意--ramdisk路徑里的產(chǎn)品名要換成你自己板的實(shí)際目錄名。如果你不確定ramdisk路徑可以用ls out/target/product/看看當(dāng)前產(chǎn)品目錄是什么。其實(shí)在實(shí)際開(kāi)發(fā)中我更推薦方式一因?yàn)閙kimage.sh會(huì)自動(dòng)把resource.img也放出來(lái)。手動(dòng)方式容易只打包boot.img忘了重新生成resource.img導(dǎo)致dts改動(dòng)沒(méi)進(jìn)到燒錄包里。如果你手動(dòng)打包記得兩個(gè)都準(zhǔn)備好。4. 環(huán)境變量避坑案例每一個(gè)坑背后都是浪費(fèi)掉的一下午標(biāo)題里專(zhuān)門(mén)提到環(huán)境變量避坑說(shuō)明這不是小事。Rockchip這套平臺(tái)的編譯流程本身很成熟絕大多數(shù)編譯失敗其實(shí)不是代碼問(wèn)題而是環(huán)境變量問(wèn)題。下面這幾個(gè)坑我全踩過(guò)或者親眼看著別人踩過(guò)。4.1 CROSS_COMPILE只寫(xiě)前綴沒(méi)寫(xiě)完整路徑這是新手最高發(fā)的錯(cuò)誤。有人會(huì)寫(xiě)成export CROSS_COMPILEaarch64-linux-android-看起來(lái)和教程差不多但如果PATH里沒(méi)有工具鏈路徑make在拼出aarch64-linux-android-gcc后會(huì)直接報(bào)command not found。更隱蔽的是如果系統(tǒng)里之前用apt裝過(guò)gcc-aarch64-linux-gnu或者你source過(guò)別的芯片廠商的環(huán)境腳本PATH里可能真的有一個(gè)同名前綴的編譯器它不報(bào)找不到而是編譯到一半報(bào)根本看不懂的語(yǔ)法錯(cuò)誤。這種情況下排錯(cuò)非常痛苦。我的經(jīng)驗(yàn)是CROSS_COMPILE必須寫(xiě)完整絕對(duì)路徑前綴同時(shí)把bin目錄加進(jìn)PATH。兩條都做互相兜底export CROSS_COMPILE$SDK_ROOT/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin/aarch64-linux-android- export PATH$SDK_ROOT/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin:$PATH然后務(wù)必驗(yàn)證一下當(dāng)前終端實(shí)際生效的編譯器which aarch64-linux-android-gcc如果輸出不是SDK里的路徑說(shuō)明PATH順序有問(wèn)題繼續(xù)往下編就是給自己挖坑。4.2 忘設(shè)ARCHarm64編出一個(gè)x86內(nèi)核的迷惑行為這個(gè)坑非常有意思。只設(shè)了CROSS_COMPILE沒(méi)設(shè)ARCH的話make會(huì)默認(rèn)當(dāng)前主機(jī)的架構(gòu)。在x86主機(jī)上它就會(huì)嘗試編譯x86內(nèi)核。這時(shí)候你看到的報(bào)錯(cuò)往往集中在arch/x86/路徑下或者匯編器報(bào)某些指令不識(shí)別。判斷技巧只要編譯輸出里出現(xiàn)了arch/x86/字樣立刻CtrlC重新export ARCHarm64再編。不要想著碰運(yùn)氣繼續(xù)跑x86的內(nèi)核就算編出來(lái)燒到ARM板子上也起不來(lái)。順便說(shuō)一句export這個(gè)坑最煩人的地方在于它不是報(bào)一個(gè)立竿見(jiàn)影的錯(cuò)誤而是一堆看似無(wú)關(guān)的報(bào)錯(cuò)堆在一起。我建議在make之前先用一串echo自檢一下echo $ARCH echo $CROSS_COMPILEARCH輸出應(yīng)該是arm64CROSS_COMPILE輸出應(yīng)該是完整路徑前綴。習(xí)慣成自然每次編譯前這兩條命令就是護(hù)身符。4.3 多平臺(tái)開(kāi)發(fā)的環(huán)境變量殘留污染嵌入式開(kāi)發(fā)的人手里通常不止一塊板子今天調(diào)RK3588明天調(diào)海思后天調(diào)全志這是常態(tài)。問(wèn)題在于如果沿用同一個(gè)終端窗口上次編譯海思平臺(tái)設(shè)置的環(huán)境變量會(huì)殘留下來(lái)。比如CROSS_COMPILE還指向上一個(gè)平臺(tái)的工具鏈路徑或者KERNEL_DIR指向別的內(nèi)核目錄。這時(shí)候的你不過(guò)是換了個(gè)目錄而已但編譯器已經(jīng)換人了。癥狀非常典型一進(jìn)內(nèi)核目錄make立刻報(bào)工具鏈找不到或者版本不匹配。我的操作習(xí)慣是每次切換平臺(tái)時(shí)絕不復(fù)用上一個(gè)終端。開(kāi)一個(gè)新終端先清空再設(shè)置unset ARCH unset CROSS_COMPILE unset CC unset CLANG_TRIPLE再用env | grep -iE arch|cross|cc|kernel確認(rèn)環(huán)境干凈了然后再設(shè)置當(dāng)前平臺(tái)的環(huán)境變量。一次清空省得后面被莫名其妙的問(wèn)題折磨。4.4 source build/envsetup.sh之后的環(huán)境污染Android開(kāi)發(fā)者通常習(xí)慣先執(zhí)行source build/envsetup.sh lunch rk3588_s-userdebug這個(gè)環(huán)境對(duì)編譯整個(gè)Android系統(tǒng)非常有用但如果你在這個(gè)環(huán)境里接著去編內(nèi)核可能會(huì)被一堆Android構(gòu)建變量干擾。比如TARGET_PRODUCT、ANDROID_PRODUCT_OUT這些變量可能會(huì)讓mkimage.sh把boot.img輸出到錯(cuò)誤的產(chǎn)品目錄或者讓make階段的行為和預(yù)期不一致。我的建議是獨(dú)立開(kāi)個(gè)終端專(zhuān)門(mén)編內(nèi)核不要source envsetup.sh。除非你有多年經(jīng)驗(yàn)知道自己在干什么。這不是說(shuō)envsetup.sh有什么問(wèn)題而是保持環(huán)境變量最小化能大幅降低出問(wèn)題的概率。4.5 GCC和Clang混用導(dǎo)致鏈接階段崩潰有些同學(xué)會(huì)照著網(wǎng)上教程設(shè)置CCclang又沒(méi)有關(guān)掉之前殘留的GCC相關(guān)變量最后出現(xiàn)GCC編譯、Clang鏈接或者反過(guò)來(lái)Clang編譯、GCC的as去匯編的混亂局面。報(bào)錯(cuò)往往在鏈接階段什么ld.lld: error: unrecognized argument之類(lèi)。這種混用狀態(tài)最難排因?yàn)榫幾g日志里一半是clang一半是gcc。記清楚邏輯Clang只是編譯器它生成的匯編要交給GNU assembler處理所以用Clang時(shí)CROSS_COMPILE還是必須設(shè)置的。要么全部走GCC默認(rèn)路徑要么全部走Clang路徑。我綜合評(píng)價(jià)下來(lái)對(duì)Rockchip SDK來(lái)說(shuō)GCC路徑是最省心的99%的調(diào)試場(chǎng)景不需要Clang。另外還有個(gè)小坑工具鏈和主機(jī)架構(gòu)也要匹配。如果你的主機(jī)是32位系統(tǒng)SDK自帶的這個(gè)x86_64預(yù)編譯工具鏈?zhǔn)怯貌涣说摹，F(xiàn)在應(yīng)該沒(méi)什么人用32位系統(tǒng)了但如果是老舊的虛擬機(jī)鏡像還是確認(rèn)一下uname -m是x86_64比較好。4.6 編譯報(bào)缺依賴(lài)那是系統(tǒng)包的問(wèn)題不是內(nèi)核代碼問(wèn)題雖然不是環(huán)境變量但很容易被誤判。比如報(bào)fatal error: openssl/bio.h: No such file or directory這是缺libssl-dev報(bào)flex: command not found是缺flex報(bào)bison: command not found是缺bison。這些都不是內(nèi)核代碼問(wèn)題用apt裝一下sudo apt install libssl-dev flex bison bc裝上之后重新編譯通常問(wèn)題就消失了。這條經(jīng)驗(yàn)分享一下免得你在網(wǎng)上搜半天編譯錯(cuò)誤發(fā)現(xiàn)自己只是沒(méi)裝系統(tǒng)包。5. 燒錄內(nèi)核的四種方式分區(qū)選擇、命令參數(shù)與適用場(chǎng)景5.1 燒錄前必須懂的分區(qū)概念boot和resource哪個(gè)都不能漏Rockchip Android12平臺(tái)和內(nèi)核相關(guān)的分區(qū)主要有兩個(gè)boot分區(qū)存放boot.img里面是內(nèi)核Image和ramdisk。resource分區(qū)存放resource.img里面是設(shè)備樹(shù)dtb和開(kāi)機(jī)logo資源。關(guān)鍵原則如果改動(dòng)涉及dtsboot.img和resource.img要一起燒。只燒boot.img而不燒resource.img可能出現(xiàn)屏幕不亮、觸摸無(wú)響應(yīng)、外設(shè)不工作等情況因?yàn)閮?nèi)核和設(shè)備樹(shù)不匹配。反過(guò)來(lái)如果只是改了內(nèi)核代碼邏輯或config開(kāi)關(guān)不涉及硬件描述那燒boot.img就夠resource.img可以不燒。要確認(rèn)自己的改動(dòng)是不是涉及dts最簡(jiǎn)單的判斷標(biāo)準(zhǔn)你有沒(méi)有動(dòng)過(guò)arch/arm64/boot/dts/rockchip/下的文件。動(dòng)過(guò)就要一起燒。5.2 方式一Windows下RKDevTool新手最友好的圖形化燒錄如果你身邊有Windows機(jī)器用RKDevTool是門(mén)檻最低的方式。流程如下讓板子進(jìn)Loader模式。兩種方法板子開(kāi)著機(jī)并且能連adb執(zhí)行adb shell reboot loader。板子斷電按住板上的升級(jí)鍵RECOVERY/固件升級(jí)鍵插上USB或者上電等待PC識(shí)別到Loader設(shè)備。打開(kāi)RKDevTool設(shè)備列表中會(huì)出現(xiàn)一個(gè)Loader設(shè)備。在燒錄列表中找到boot分區(qū)點(diǎn)擊右側(cè)選擇文件選中你編譯的boot.img。如果dts有改動(dòng)同時(shí)找到resource分區(qū)選中resource.img。只勾選這兩行點(diǎn)擊執(zhí)行。這里要特別提醒千萬(wàn)忍住不要點(diǎn)一鍵燒錄或者勾選所有分區(qū)。RKDevTool的勾選邏輯是勾哪個(gè)燒哪個(gè)如果你把整包固件都勾上等于又回到了全量燒錄浪費(fèi)時(shí)間不說(shuō)還容易因?yàn)槟闶掷锏墓碳姹静慌涮锥寻遄铀⑵鸩粊?lái)。5.3 方式二Linux下rkdeveloptool命令行最常用Linux環(huán)境下rkdeveloptool是官方開(kāi)源的USB燒錄工具可以直接從Rockchip倉(cāng)庫(kù)拉源碼編譯也可以在部分Ubuntu源上直接apt安裝。先讓板子進(jìn)Loader模式和上面一樣然后按這個(gè)順序操作# 列出所有連接的設(shè)備確認(rèn)板子被識(shí)別 rkdeveloptool ld # 如果設(shè)備識(shí)別不到或狀態(tài)異常先用db命令加載loader rkdeveloptool db $SDK_ROOT/rockdev/rk3588_spl_loader_v1.08.bin # 寫(xiě)入boot分區(qū) rkdeveloptool wl 0x4000 boot.img # 寫(xiě)入resource分區(qū) rkdeveloptool wl 0x6000 resource.img # 重啟設(shè)備 rkdeveloptool rdrkdeveloptool的wl命令參數(shù)是以512字節(jié)扇區(qū)為單位的偏移。這里的0x4000是boot分區(qū)偏移0x6000是resource分區(qū)偏移這只是我RB3588平臺(tái)的一個(gè)示例值不同SDK、不同產(chǎn)品完全可能不一樣。正確做法是打開(kāi)SDK里對(duì)應(yīng)產(chǎn)品的parameter文件搜索(boot)和(resource)關(guān)鍵字找到實(shí)際的扇區(qū)偏移。以RK3588一份典型parameter文件為例相關(guān)片段長(zhǎng)這樣CMDLINE: mtdpartsrkxxxx:...:0x000020000x00004000(boot),...:0x000020000x00006000(resource),...這里的0x00004000(boot)就表示boot分區(qū)起始扇區(qū)是0x40000x00006000(resource)表示resource分區(qū)起始扇區(qū)是0x6000。直接用這個(gè)數(shù)字傳給wl命令就對(duì)。強(qiáng)烈建議每次燒錄前把你手上固件的parameter文件解出來(lái)看一眼不要憑記憶敲offset。我吃過(guò)一次虧換了SDK版本之后boot分區(qū)offset從0x4000變成了別的值我還按老經(jīng)驗(yàn)燒結(jié)果燒完板子起不來(lái)。5.4 方式三adb加dd調(diào)試階段效率最高的燒錄方法這是我最?lèi)?ài)的燒錄方式?jīng)]有之一。前提是板子是userdebug或eng版本有root權(quán)限。過(guò)程不超過(guò)十秒# 連接板子并獲取root adb root # 確認(rèn)boot分區(qū)節(jié)點(diǎn)存在并查看分區(qū)情況 adb shell ls -l /dev/block/by-name/boot # 傳輸boot.img到板子 adb push boot.img /data/local/tmp/ # 用dd寫(xiě)入boot分區(qū) adb shell dd if/data/local/tmp/boot.img of/dev/block/by-name/boot bs1M # resource.img同樣處理 adb push resource.img /data/local/tmp/ adb shell dd if/data/local/tmp/resource.img of/dev/block/by-name/resource bs1M # 重啟 adb reboot為什么這個(gè)方法效率高因?yàn)椴恍枰M(jìn)Loader模式不需要額外燒錄工具不需要斷電按鍵一條adb命令就把鏡像寫(xiě)進(jìn)分區(qū)了。對(duì)于一天改十幾次內(nèi)核的調(diào)試場(chǎng)景這是最順手的路徑。風(fēng)險(xiǎn)提示dd命令寫(xiě)錯(cuò)分區(qū)的后果是災(zāi)難性的。執(zhí)行前務(wù)必確認(rèn)of指向的是/dev/block/by-name/boot或/dev/block/by-name/resource不要手滑寫(xiě)到其他分區(qū)。如果板子上沒(méi)有/dev/block/by-name這個(gè)軟鏈接目錄可以先執(zhí)行adb shell ls /dev/block/by-name/看看實(shí)際分區(qū)名有些定制系統(tǒng)分區(qū)命名可能不一樣。5.5 方式四fastboot能不能用看設(shè)備部分RK板子在Android12上開(kāi)啟了fastboot支持可以這樣試adb reboot bootloader fastboot devices fastboot flash boot boot.img fastboot flash resource resource.img fastboot reboot但坦白說(shuō)Rockchip平臺(tái)上fastboot不是默認(rèn)必現(xiàn)的不同SDK差異很大。如果fastboot devices識(shí)別不到就別糾結(jié)用前面三種方式。fastboot在RK平臺(tái)更像是一個(gè)可用可不用的彩蛋不要依賴(lài)它。6. 燒錄后的驗(yàn)證與啟動(dòng)失敗排查6.1 確認(rèn)內(nèi)核真的更新了燒錄完重啟第一件事是驗(yàn)證內(nèi)核版本和編譯時(shí)間adb shell uname -a adb shell cat /proc/version/proc/version里會(huì)顯示內(nèi)核編譯時(shí)間。如果你打印出的時(shí)間正好是你剛才編譯的時(shí)間說(shuō)明boot分區(qū)燒對(duì)了。如果時(shí)間還是舊版本說(shuō)明你燒的分區(qū)不對(duì)或者板子實(shí)際從另一個(gè)分區(qū)啟動(dòng)了。比如部分板子使用A/B分區(qū)架構(gòu)實(shí)際啟動(dòng)的是boot_a或boot_b而不是名為boot的符號(hào)鏈接默認(rèn)指向的那個(gè)。這種情況需要燒到對(duì)應(yīng)的a/b分區(qū)。設(shè)備樹(shù)的驗(yàn)證也做一下adb shell cat /proc/device-tree/model adb shell cat /proc/device-tree/compatible如果model輸出和你的板型或你改動(dòng)的dts一致說(shuō)明resource分區(qū)也燒對(duì)了。如果model是老的那resource.img沒(méi)生效回去查燒錄offset。6.2 卡在開(kāi)機(jī)logo不動(dòng)兩個(gè)img不匹配的問(wèn)題燒錄后板子卡在開(kāi)機(jī)logo最常見(jiàn)的兩個(gè)原因一是boot.img和resource.img不是同一套SDK編出來(lái)的內(nèi)核和dts版本不匹配二是內(nèi)核config缺了某個(gè)啟動(dòng)關(guān)鍵配置。排查思路建議這樣走先確保兩個(gè)img來(lái)自同一次make調(diào)用。如果你用舊SDK編了resource.img新SDK編了boot.imglogo卡死不奇怪?；赝说街澳苡玫耐暾碳_認(rèn)板子本身沒(méi)壞。手邊常備一份全量固件和燒錄工具是干這行的基本素養(yǎng)。如果完整固件能啟動(dòng)再只燒新的boot.img不燒resource.img看能不能過(guò)logo。能過(guò)的話基本斷定問(wèn)題出在resource.img身上不能過(guò)就是boot.img的問(wèn)題。這樣二分定位最快。6.3 能進(jìn)系統(tǒng)但外設(shè)異常優(yōu)先懷疑dts不匹配內(nèi)核能起來(lái)但Wifi打不開(kāi)、觸摸沒(méi)響應(yīng)、藍(lán)牙掃描不到、音頻不出聲這類(lèi)問(wèn)題在單獨(dú)編譯燒錄場(chǎng)景下最大概率是resource.img里的dtb沒(méi)更新和你當(dāng)前內(nèi)核版本不匹配或者dts的硬件描述與真實(shí)硬件布局不一致。解決方向把resource.img完整重新燒一次。如果你不方便重?zé)€有一個(gè)排查小技巧把新舊resource.img里的dtb分別反編譯出來(lái)做對(duì)比# dtc是設(shè)備樹(shù)編譯器在SDK或者系統(tǒng)dtc工具都可以 dtc -I dtb -O dts -o old.dts old.dtb dtc -I dtb -O dts -o new.dts new.dtb diff old.dts new.dts這樣你能很直觀地看到設(shè)備樹(shù)差異判斷是不是某些硬件節(jié)點(diǎn)因?yàn)閐ts沒(méi)更新而缺失。另外還有一層容易被忽略——dtsi的include層級(jí)。Rockchip的dts通常由多個(gè)dtsi分散include組成你改的是某個(gè)子dtsi但最終編譯進(jìn)resource.img的可能是另一個(gè)dts文件。如果你改了某個(gè)通用dtsi記得確認(rèn)最終生效的dts確實(shí)包含了你的改動(dòng)用生成的dtb反編譯確認(rèn)最靠譜。6.4 內(nèi)核panic或反復(fù)重啟串口日志才是關(guān)鍵如果內(nèi)核在啟動(dòng)早期就panicadb還沒(méi)起來(lái)你看不到dmesg。這時(shí)候必須接串口。Rockchip平臺(tái)的調(diào)試串口默認(rèn)波特率是1500000不是常見(jiàn)的115200這個(gè)特別容易坑到人。用minicom或者picocom連sudo picocom -b 1500000 /dev/ttyUSB0打開(kāi)串口后上電你能看到完整的U-Boot日志和內(nèi)核啟動(dòng)日志。panic棧在哪一行、哪個(gè)驅(qū)動(dòng)初始化失敗串口上打印得明明白白。調(diào)內(nèi)核啟動(dòng)問(wèn)題沒(méi)有串口等于瞎猜。最常見(jiàn)的幾種panic原因dts里某個(gè)節(jié)點(diǎn)引用的時(shí)鐘不存在clk_get失敗導(dǎo)致驅(qū)動(dòng)直接BUG。內(nèi)核config里關(guān)閉了某個(gè)平臺(tái)必需的驅(qū)動(dòng)比如GIC中斷控制器沒(méi)編進(jìn)去。內(nèi)存布局和dts里的reg地址不匹配導(dǎo)致訪問(wèn)非法地址。這些在串口日志里其實(shí)都有提示關(guān)鍵是先學(xué)會(huì)看日志。另外建議每次編譯完把Image保存在一個(gè)有版本標(biāo)識(shí)的目錄里比如boot_20250610_1600.img不然燒多了之后你根本不知道自己燒的是哪一個(gè)。6.5 容易忽略的坑ramdisk和vendor分區(qū)里的內(nèi)核模塊Android12里不少內(nèi)核驅(qū)動(dòng)是編譯成.ko模塊放在ramdisk或vendor分區(qū)里的。單獨(dú)編譯內(nèi)核燒錄后如果這些分區(qū)里的模塊沒(méi)跟著更新會(huì)出現(xiàn)內(nèi)核能起來(lái)、但某些功能異常的情況。比如模塊加載時(shí)報(bào)version magic不匹配或者unknown symbol都是模塊和內(nèi)核版本對(duì)不上的典型癥狀。出現(xiàn)這種情況別懷疑內(nèi)核編譯有問(wèn)題要意識(shí)到是模塊盤(pán)跟不上了。處理方式把對(duì)應(yīng)模塊重新編譯后手動(dòng)push到板子對(duì)應(yīng)目錄。先看模塊都在哪adb shell ls /vendor/lib/modules/ adb shell ls /vendor/lib/modules/*.ko然后從你內(nèi)核編譯產(chǎn)物中找到對(duì)應(yīng)的.kofind $SDK_ROOT/kernel-5.10 -name *.ko | grep your_modulepush進(jìn)去adb push your_module.ko /vendor/lib/modules/ adb shell sync adb reboot不過(guò)要注意模塊和內(nèi)核版本強(qiáng)相關(guān)每次改內(nèi)核后最好都用同一套編譯產(chǎn)物把相關(guān)模塊一起更新不要混著用。6.6 環(huán)境變量坑的最后一口氣重編前先清理不管上面哪種問(wèn)題讓你重新編譯建議重新編譯前把內(nèi)核目錄里的舊產(chǎn)物清理一下尤其是改了defconfig里的大選項(xiàng)之后。有時(shí)候舊編譯產(chǎn)物會(huì)緩存一些config相關(guān)的中間文件導(dǎo)致你改了配置卻不生效make clean # 或者如果你想徹底一點(diǎn) make mrproper然后重新走一遍defconfig、make流程。這一條不是環(huán)境變量問(wèn)題但和編譯異常的關(guān)系極其密切。尤其是你在menuconfig里改了某個(gè)選項(xiàng)卻發(fā)現(xiàn)編譯產(chǎn)物沒(méi)有任何變化先make clean再試。調(diào)到最后你會(huì)發(fā)現(xiàn)RK3568/RK3588內(nèi)核單獨(dú)編譯這件事本身并不難難的是每一次出錯(cuò)都讓人覺(jué)得毫無(wú)頭緒。而所有毫無(wú)頭緒的背后幾乎都是環(huán)境變量、分區(qū)偏移、模塊匹配這幾個(gè)老問(wèn)題在輪流轉(zhuǎn)。把這篇教程里提到的問(wèn)題都提前避開(kāi)了你就能把一天里省下來(lái)的時(shí)間真正花在調(diào)試業(yè)務(wù)代碼上而不是和編譯環(huán)境較勁。這是我個(gè)人實(shí)際做下來(lái)最大的體會(huì)也希望對(duì)你有用。