我先把話放前面這年頭在嵌入式圈子里搜“H5”搜出來(lái)的東西十有八九是錯(cuò)的。你以為是Allwinner H5處理器結(jié)果教程全在講怎么做一個(gè)移動(dòng)端網(wǎng)頁(yè)你以為在解一個(gè)帶firmware的固件包結(jié)果被STM32Cube FW_H7的版本依賴問(wèn)題帶跑偏。我在這個(gè)坑里來(lái)回橫跳過(guò)很多次所以今天想認(rèn)真聊聊一個(gè)非常具體、也非常要命的話題當(dāng)你手里只有一個(gè)固件鏡像或者一臺(tái)貼著“H5”標(biāo)簽但來(lái)歷不明的板子時(shí)怎么從固件里把處理器類型認(rèn)死。這篇文章適合正在刷機(jī)、做固件適配、或者維護(hù)老舊H5方案產(chǎn)品的朋友。我會(huì)從二進(jìn)制分析、運(yùn)行日志、刷機(jī)失敗的現(xiàn)場(chǎng)診斷這幾個(gè)角度把“分辨H5處理器類型”這件事做成一條可復(fù)現(xiàn)的流程順便把那些同名不同物的“H5”講清楚免得你在搜索里越繞越遠(yuǎn)。1. 為什么“H5”這個(gè)標(biāo)簽在嵌入式圈里如此容易被認(rèn)錯(cuò)1.1 全志H5的江湖地位與血緣關(guān)系先明確一個(gè)大前提國(guó)內(nèi)討論的“H5處理器”絕大多數(shù)情況下指的是全志科技Allwinner的H5。這是一顆四核Cortex-A53、64位、28nm工藝的SoC主要出現(xiàn)在NanoPi NEO2、Orange Pi PC2、Banana Pi M2這類開源開發(fā)板以及一批電視盒子、智能家居中控上。它和同門的H3四核Cortex-A7、32位在引腳上基本兼容PCB設(shè)計(jì)可以直接沿用這也是后續(xù)大量誤刷固件事故的根源之一。H5的全家桶大致是H2、H3、H5、H6、H616、H713等。H3和H5關(guān)系最近很多板子甚至共用一個(gè)底板設(shè)計(jì)只換核心芯片就能出兩個(gè)型號(hào)。這也意味著你在淘寶上買到的“H5板子”如果賣家自己都分不清H3和H5那固件幾乎必然是亂給的。我遇到過(guò)一塊絲印模糊的板子商家堅(jiān)持說(shuō)它是H5結(jié)果串口日志里赫然寫著Allwinner H3這種例子一點(diǎn)也不罕見。1.2 貼紙、絲印、賣家描述都不可信的現(xiàn)狀做固件識(shí)別最忌諱的就是“信標(biāo)簽”。嵌入式設(shè)備從方案商到貼牌商再到零售中間至少經(jīng)過(guò)兩三層標(biāo)簽貼錯(cuò)是常態(tài)。有些小廠為了清庫(kù)存把H3的板子換個(gè)外殼就當(dāng)H5賣因?yàn)閮烧叩能浖蟛糠滞ㄓ靡话阌脩襞軅€(gè)官方固件根本察覺不到。但一旦你要自己編譯內(nèi)核、替換boot、適配外設(shè)驅(qū)動(dòng)芯片型號(hào)認(rèn)錯(cuò)就是災(zāi)難。芯片本體絲印也不完全可靠。H5和H3的絲印布局很接近一些打磨片、Remark片會(huì)被重新打標(biāo)除非你用放大鏡對(duì)比封裝圈和批次號(hào)否則容易看走眼。更隱蔽的是有些二手板子被維修過(guò)主控已經(jīng)換成另一顆芯片但外殼標(biāo)簽還是舊的。所以“從固件反推處理器類型”才成了最靠譜的手段因?yàn)楣碳锏淖C據(jù)是做不了假的它必須匹配芯片的啟動(dòng)協(xié)議和硬件描述假固件根本跑不起來(lái)。1.3 網(wǎng)頁(yè)H5與嵌入式H5同名的兩種生物我順手看了一下最近的熱搜詞前幾名全是“京東H5支付”“uniapp H5預(yù)覽PDF”“微信公眾號(hào)H5 點(diǎn)擊按鈕調(diào)取打開小程序”這類前端話題。這些“H5”指的是HTML5網(wǎng)頁(yè)技術(shù)和全志H5處理器八竿子打不著但搜索引擎不管這些。你在網(wǎng)上搜H5相關(guān)問(wèn)題時(shí)不得不花大量時(shí)間過(guò)濾這些前端內(nèi)容。還有一類更容易混淆的是“STM32Cube FW_H7 v1.12.1”這類內(nèi)容。STM32H7是意法半導(dǎo)體家的MCU縮寫里第二個(gè)字母是“H7”跟全志H5完全是兩個(gè)物種但在搜“H5 firmware”時(shí)它們經(jīng)?；煸谝黄?。我的建議是搜索時(shí)一定要帶精確限定詞比如“Allwinner H5”“sun50i-h5”“H5 boot0”否則你看到的參考資料就是一場(chǎng)大雜燴。2. 用二進(jìn)制層證據(jù)鏈確認(rèn)處理器類型boot0、uImage與dtb2.1 在固件里定位boot0并讀取eGON.BT0簽名拿到一個(gè)固件鏡像后第一個(gè)動(dòng)作不是雙擊解壓而是先把它當(dāng)成一個(gè)二進(jìn)制文件來(lái)分析。全志系的固件啟動(dòng)流程一般是boot0也就是SPL從存儲(chǔ)介質(zhì)加載再把u-boot從啟動(dòng)介質(zhì)里讀出來(lái)u-boot再去引導(dǎo)內(nèi)核。這里的boot0頭部會(huì)寫一個(gè)固定的魔數(shù)簽名“eGON.BT0”它是最早、最底層的身份信息。在Linux環(huán)境下我習(xí)慣先把固件鏡像中偏移8KB處第16個(gè)扇區(qū)的內(nèi)容單獨(dú)提取出來(lái)dd iffirmware.img bs512 skip16 count64 ofboot0.bin hexdump -C boot0.bin | head -20正常輸出里會(huì)看到類似00000000 65 47 4f 4e 2e 42 54 30 ... eGON.BT0如果簽名存在基本能確認(rèn)這是全志系列固件。接下來(lái)還要繼續(xù)看boot0里帶的芯片代號(hào)。不同芯片的boot0雖然都叫eGON.BT0但后續(xù)的初始化代碼、DRAM配置、引腳復(fù)用完全不同。你可以在boot0的頭部偏移處找到板級(jí)標(biāo)識(shí)或者直接strings一把strings boot0.bin | grep -i -E h3|h5|sun8i|sun50i|boot0這個(gè)方法不保證每次都能直接命中因?yàn)楹芏嗔慨a(chǎn)固件會(huì)刪掉調(diào)試字符串但結(jié)合后面的內(nèi)核鏡像和dtb信息足夠形成證據(jù)鏈。2.2 file命令與ELF頭32位ARM還是64位AArch64全志H5最硬核的區(qū)分點(diǎn)在于它是一顆64位處理器通常跑64位ARM內(nèi)核而它的親兄弟H3是32位處理器絕大多數(shù)固件跑32位內(nèi)核。所以在解包固件、找到內(nèi)核鏡像后一條file命令就能快速定位file arch/arm64/boot/Image # 輸出類似Image: PE32 executable (EFI application), AArch64 file arch/arm/boot/zImage # 輸出類似Linux kernel ARM boot executable zImage如果你的固件里只有arch/arm/boot/zImage也就是32位ARM內(nèi)核那它大概率是H3或H2的固件不可能是H5的原生固件。反之如果內(nèi)核鏡像是AArch64的Image那就要繼續(xù)看設(shè)備樹確認(rèn)它是不是sun50i-h5。這里有個(gè)細(xì)節(jié)要提醒H5也能跑32位內(nèi)核因?yàn)镃ortex-A53支持AArch32執(zhí)行狀態(tài)有些老方案商為了沿用H3的驅(qū)動(dòng)改動(dòng)會(huì)強(qiáng)行在H5上跑32位內(nèi)核。所以“64位內(nèi)核H5”是充分不必要條件反過(guò)來(lái)不成立?？吹?2位內(nèi)核別急著下結(jié)論繼續(xù)看設(shè)備樹吧。2.3 設(shè)備樹與內(nèi)核configsun50i-h5與sun8i-h3的死區(qū)別Linux內(nèi)核里的設(shè)備樹是識(shí)別開發(fā)板型號(hào)的最高權(quán)威。H5對(duì)應(yīng)的設(shè)備樹家族是sun50i-h5文件名一般在arch/arm64/boot/dts/allwinner/目錄下H3對(duì)應(yīng)的是sun8i-h3在arch/arm/boot/dts/目錄下。如果你在固件里看到sun50i-h5-nanopi-neo2.dtb或sun50i-h5-orangepi-pc2.dtb這類文件電腦型號(hào)基本就鎖死了。也可以用dtc把dtb反編譯成dts文本直接看compatible字段dtc -I dtb -O dts -o out.dts sun50i-h5-nanopi-neo2.dtb cat out.dts | grep compatible -m 5典型的輸出類似compatible xunlong,orangepi-pc2, allwinner,sun50i-h5;只要出現(xiàn)“allwinner,sun50i-h5”這條證據(jù)鏈就閉環(huán)了。這個(gè)字段是內(nèi)核啟動(dòng)時(shí)匹配machine_desc用的寫錯(cuò)一個(gè)字內(nèi)核都起不來(lái)所以固件作者不可能亂填。如果解包后找不到獨(dú)立dtb文件而是把設(shè)備樹編進(jìn)了內(nèi)核那就去看內(nèi)核配置文件。H5固件必須開了CONFIG_MACH_SUN50IH3則對(duì)應(yīng)CONFIG_MACH_SUN8I。從/boot/config-xxx或固件里的.config中g(shù)rep一下就能確認(rèn)。2.4 用fexc反編譯script.bin從board字段看板子身份在全志的舊式方案里還有一個(gè)叫script.bin的文件它是由fex格式的配置文件編譯而來(lái)的二進(jìn)制用來(lái)告訴u-boot和內(nèi)核“我這塊板子的DRAM頻率、引腳復(fù)用、電源時(shí)序是怎么配的”。新版固件漸漸改用設(shè)備樹了但很多機(jī)頂盒和IoT設(shè)備仍然沿用script.bin或者兩者共存。用sunxi-tools里的fexc工具可以把它反編譯fexc script.bin sys_config.fex打開sys_config.fex后重點(diǎn)看[target]段。這里通常會(huì)寫[target] board nanopi-neo2這個(gè)board字段雖然理論上可以被任意修改但配合dtb、內(nèi)核架構(gòu)一起看基本能鎖定板子身份。我有一次遇到一個(gè)奇怪的固件script.bin里寫的是H3板的board值但內(nèi)核是arm64、dtb是sun50i-h5的最終判斷是有人把H5固件改改script.bin硬塞給H3板子刷這種“魔改固件”在市面上不少見。3. 運(yùn)行時(shí)判定H5的最硬核證據(jù)串口打印與系統(tǒng)節(jié)點(diǎn)3.1 串口啟動(dòng)日志里的SoC型號(hào)與DRAM大小如果說(shuō)二進(jìn)制分析是“尸檢”那串口日志就是“活體檢測(cè)”。找一塊USB轉(zhuǎn)TTL模塊接上板子的UART0引腳一般是GND、TX、RX三根線波特率設(shè)為115200上電后就能看到完整的啟動(dòng)過(guò)程。u-boot的打印信息是判斷處理器型號(hào)的最直接證據(jù)U-Boot 2018.05 (Nov 21 2019 - 10:32:19) Allwinner Technology CPU: Allwinner H5 (SUN50I) Model: Xunlong Orange Pi PC2 DRAM: 1 GiB注意“CPU: Allwinner H5 (SUN50I)”這一行它來(lái)自u(píng)-boot源碼里的mach-sunxi是根據(jù)當(dāng)前運(yùn)行芯片的ID寄存器動(dòng)態(tài)讀取出來(lái)的不是寫死的字符串。所以只要系統(tǒng)能正常跑到打印這行處理器型號(hào)基本不需要再懷疑。另外DRAM大小也能作為旁證。H5官方支持到2GBH3最高也是2GB但市面上常見的是512MB/1GB二者在常見配置上差別不大所以DRAM只能輔助判斷不能當(dāng)主證據(jù)。真正想做得嚴(yán)謹(jǐn)還是要結(jié)合u-boot打印里的SoC名稱和后續(xù)內(nèi)核日志。3.2 從/proc/cpuinfo和/proc/device-tree/compatible看處理器架構(gòu)如果板子已經(jīng)能正常進(jìn)入系統(tǒng)判斷就更簡(jiǎn)單了。在SSH或者串口終端里執(zhí)行cat /proc/cpuinfo重點(diǎn)不是看“Processor”那行的廠商名而是看“CPU part”。Cortex-A53對(duì)應(yīng)的CPU part是0xd03Cortex-A7對(duì)應(yīng)的是0xc07。如果看到CPU part : 0xd03那這是一顆64位Cortex-A53核心極大概率是H5也可能是H6、H616等更新芯片但那些芯片的引腳和固件格式又不同不會(huì)混淆。如果是0xc07那就是Cortex-A7基本可以排除H5。再看內(nèi)核被什么設(shè)備樹引導(dǎo)cat /proc/device-tree/compatible輸出是一串以\0分隔的字符串比如allwinner,sun50i-h5 allwinner,sun50i-h5-nanopi-neo2這個(gè)節(jié)點(diǎn)是u-boot在啟動(dòng)內(nèi)核前把dtb的根節(jié)點(diǎn)compatible屬性暴露出來(lái)的內(nèi)核用的就是它?？吹絪un50i-h5處理器型號(hào)就板上釘釘了。3.3 順手檢查WiFi/BT固件加載日志反推硬件組合運(yùn)行時(shí)除了確認(rèn)處理器還能順便確認(rèn)無(wú)線模塊。很多H5板子出廠時(shí)搭配AP6212、RTL8723BS、MT7668等WiFi/BT模塊這些模塊需要獨(dú)立的firmware文件加載失敗時(shí)內(nèi)核日志會(huì)有明顯提示。比如mt7921e 0000:04:00.0: direct firmware load for mediatek/wifi_ram_code_mt7961 failed with error -2這種日志表示固件文件缺失或版本不匹配。我拿這個(gè)例子出來(lái)說(shuō)是想展示一個(gè)思路固件報(bào)錯(cuò)信息本身也是硬件身份的指紋。如果你看到mediatek的WiFi固件加載失敗說(shuō)明板子至少帶了MT79xx系列的無(wú)線芯片再結(jié)合SoC串口日志就能把整塊板的硬件組合確認(rèn)得七七八八。反過(guò)來(lái)如果dmesg里出現(xiàn)brcmfmac相關(guān)日志說(shuō)明用的是博通方案RAM code、nvram文件路徑都不同。這些細(xì)節(jié)在做固件移植時(shí)非常有用因?yàn)橥粋€(gè)H5芯片可以配十幾種不同WiFi模塊而對(duì)應(yīng)的固件路徑完全不一樣。3.4 內(nèi)核模塊名與驅(qū)動(dòng)路徑中的芯片代號(hào)進(jìn)入系統(tǒng)后還可以通過(guò)驅(qū)動(dòng)模塊的反向依賴來(lái)確認(rèn)芯片家族的代碼習(xí)慣。比如執(zhí)行l(wèi)s /sys/bus/soc/devices/ dmesg | grep -i sunxi\|sun50i\|sun8i在H5上dmesg里會(huì)出現(xiàn)大量sun50i相關(guān)的中斷控制器、時(shí)鐘控制器條目在H3上則對(duì)應(yīng)sun8i。它們都來(lái)自設(shè)備樹中的compatible配置所以不會(huì)自相矛盾。還有個(gè)小技巧查看/usr/lib/linux-image-*/下或者/lib/modules/$(uname -r)/下有沒有sun50i開頭的模塊目錄。內(nèi)核模塊的命名通常直接帶著硬件家族標(biāo)識(shí)比如sun50i-codec、sun50i-h5-sid。如果你在模塊目錄里看到sun8i的模塊那這個(gè)內(nèi)核鏡像大概率是給H3用的即便它跑在H5上也說(shuō)明固件是跨型號(hào)魔改版。4. 刷錯(cuò)固件的災(zāi)難現(xiàn)場(chǎng)與恢復(fù)思路4.1 拿H3固件刷H5的典型癥狀H3和H5管腳兼容但啟動(dòng)流程和內(nèi)核驅(qū)動(dòng)不同。把H3固件刷進(jìn)H5常見結(jié)果是上電后電源燈亮HDMI沒輸出串口卡在u-boot早期初始化階段或者u-boot起來(lái)后一進(jìn)內(nèi)核就死機(jī)。原因很容易理解H3固件的boot0和u-boot是按Cortex-A7、32位模式編譯的H5芯片上電后雖然能兼容執(zhí)行32位指令但DRAM初始化參數(shù)、總線配置、時(shí)鐘樹完全對(duì)不上。H3的u-boot可能會(huì)在DRAM階段就卡死或者勉強(qiáng)跑起來(lái)后被內(nèi)核里的sun8i設(shè)備樹引導(dǎo)到一個(gè)不存在的硬件上內(nèi)核panic。我在實(shí)測(cè)中見過(guò)最典型的癥狀是串口不斷重復(fù)打印一行亂碼或者停在“U-Boot SPL board init failed”這是SPL階段初始化失敗基本無(wú)解只能進(jìn)FEL模式重刷。4.2 拿H5固件刷H3的典型癥狀反過(guò)來(lái)把H5固件刷進(jìn)H3就更慘。H5固件的boot0是按AArch64啟動(dòng)協(xié)議寫的H3是純32位芯片根本不支持AArch64模式。上電后boot0的第一條指令就可能觸發(fā)未定義指令異常然后芯片直接掛死連串口打印都沒有。有些H3板子可能運(yùn)氣好能跳到u-boot但u-boot一旦嘗試跳轉(zhuǎn)到64位內(nèi)核鏡像就會(huì)因?yàn)镠3沒有AArch64執(zhí)行能力而完全無(wú)法啟動(dòng)。刷錯(cuò)固件的癥狀不只是“能不能開機(jī)”這么簡(jiǎn)單還有一類更隱蔽的“半兼容狀態(tài)”系統(tǒng)能起來(lái)但eMMC容量識(shí)別不對(duì)、GPU驅(qū)動(dòng)花屏、WiFi模塊反復(fù)reset、溫度傳感器讀出來(lái)是負(fù)值。這些癥狀源于H5固件里的設(shè)備樹和H3板子的實(shí)際電路有細(xì)微差別。很多小廠固件就是在這種半兼容狀態(tài)下量產(chǎn)出貨的用戶用著偶爾死機(jī)還以為是自己運(yùn)氣不好。4.3 固件版本依賴問(wèn)題從STM32Cube FW_H7到WiFi RAM Code引出的共性說(shuō)到固件匹配我想插一個(gè)看起來(lái)不相關(guān)但道理完全相同的例子。最近有個(gè)很熱的搜索詞“the firmware package (stm32cube fw_h7 v1.12.1) or one of its dependencies”。這是STM32CubeMX用戶在生成H7工程時(shí)遇到的依賴包缺失提示雖然芯片變成了STM32H7但底層邏輯和全志H5一模一樣固件包、芯片型號(hào)、驅(qū)動(dòng)代碼三者必須嚴(yán)格對(duì)位。WiFi固件更是如此?；氐角懊婺莻€(gè)mt7921e加載“mediatek/wifi_ram_code_mt7961”失敗的報(bào)錯(cuò)它最煩人的地方在于不同版本內(nèi)核、不同無(wú)線芯片的ram code文件不能張冠李戴。有些時(shí)候驅(qū)動(dòng)加載失敗了并不是文件不存在而是當(dāng)前內(nèi)核驅(qū)動(dòng)版本要求的文件路徑、或者文件頭部的chip ID和你放進(jìn)去的bin文件不一致。這時(shí)候光看報(bào)錯(cuò)文本沒用要順藤摸瓜去看驅(qū)動(dòng)源碼里請(qǐng)求的文件名再對(duì)著硬件芯片絲印確認(rèn)具體型號(hào)。這個(gè)共性值得你刻在腦子里固件識(shí)別從來(lái)不是只看SoC那一層而是SoC、板載外設(shè)、固件文件三者的三角匹配。H5處理器類型確認(rèn)了只代表主控認(rèn)對(duì)了不代表示系統(tǒng)就一定能跑起來(lái)。4.4 串口FEL模式的救磚路線刷錯(cuò)H5固件導(dǎo)致變磚后別急著扔板子。全志芯片內(nèi)部有一塊小的Boot ROM上電時(shí)會(huì)先檢查一個(gè)叫FEL的特殊模式如果SD卡和eMMC里都沒有可啟動(dòng)的boot0或者某個(gè)特殊引腳被拉低芯片會(huì)主動(dòng)進(jìn)入FEL模式等待USB下載。進(jìn)入FEL方式因板而異常見做法是先按住板上的FEL鍵或者短接FEL測(cè)試點(diǎn)再插入U(xiǎn)SB線此時(shí)電腦端lsusb能看到一個(gè)“FEL”設(shè)備。然后使用sunxi-fel命令燒寫sunxi-fel -p spiflash-write 0 u-boot-sunxi-with-spl.bin或者用PhoenixSuit、LiveSuit這類全志官方刷機(jī)工具選擇正確的H5固件直接恢復(fù)。這里要特別強(qiáng)調(diào)救磚工具本身不會(huì)區(qū)分H5還是H3你手動(dòng)選擇的固件才是決定成敗的關(guān)鍵。所以在點(diǎn)“刷機(jī)”按鈕之前重新做一遍第二、三章的確認(rèn)流程確保手里的固件確實(shí)是H5的。5. 一套可以抄作業(yè)的H5固件識(shí)別核對(duì)清單5.1 拿到固件包后的前5個(gè)動(dòng)作為了不讓自己在固件海里迷失我整理了一套固定動(dòng)作每拿到一個(gè)來(lái)路不明的固件包都會(huì)照著過(guò)一遍file命令看整體類型有的固件是裸鏡像有的是廠商私有打包格式先分清。binwalk掃描文件結(jié)構(gòu)快速找出固件里嵌入的內(nèi)核、dtb、rootfs偏移位置。提取boot0并檢查eGON.BT0簽名確認(rèn)全志系。定位內(nèi)核鏡像并確認(rèn)是32位還是64位AArch64指向H5或更新芯片ARM32指向H3/H2。反編譯dtb并grep compatible字段看到allwinner,sun50i-h5才收工。這五步做完90%的固件都能確認(rèn)處理器類型。剩下10%是廠商深度定制、去掉了所有標(biāo)識(shí)的固件那就只能靠刷機(jī)實(shí)測(cè)加串口日志來(lái)驗(yàn)證了。5.2 常見H5開發(fā)板與對(duì)應(yīng)dtb/fex對(duì)照為了方便比對(duì)我列幾個(gè)我做過(guò)的H5板子以及對(duì)應(yīng)內(nèi)核設(shè)備樹和官方u-boot里的型號(hào)名供你參考開發(fā)板名稱SoC內(nèi)核設(shè)備樹u-boot型號(hào)打印NanoPi NEO2Allwinner H5sun50i-h5-nanopi-neo2.dtbFriendlyARM NanoPi NEO2NanoPi NEO Plus2Allwinner H5sun50i-h5-nanopi-neo-plus2.dtbFriendlyARM NanoPi NEO Plus2Orange Pi PC2Allwinner H5sun50i-h5-orangepi-pc2.dtbXunlong Orange Pi PC2Orange Pi Zero PlusAllwinner H5sun50i-h5-orangepi-zero-plus.dtbXunlong Orange Pi Zero PlusBanana Pi M2Allwinner H5sun50i-h5-bananapi-m2-plus.dtbSinovoip Banana Pi M2這塊表看上去簡(jiǎn)單但真到了現(xiàn)場(chǎng)排查時(shí)特別好用。比如有人拿一塊“Orange Pi Zero Plus”板子固件里dtb卻是nanopi-neo2.dtb這時(shí)你要意識(shí)到它們雖然是同一個(gè)SoC但板載網(wǎng)卡、LED引腳、電源管理都可能不同直接混用會(huì)出現(xiàn)各種怪毛病。5.3 固件匹配驗(yàn)證矩陣與確認(rèn)簽字流程我個(gè)人的習(xí)慣是在批量刷機(jī)前建一個(gè)小矩陣表比對(duì)著確認(rèn)完再動(dòng)手。列大概是這樣的驗(yàn)證項(xiàng)命令/方法H5預(yù)期結(jié)果實(shí)測(cè)結(jié)果boot0簽名hexdumpeGON.BT0通過(guò)內(nèi)核架構(gòu)file ImageAArch64通過(guò)dtb compatibledtc grepallwinner,sun50i-h5通過(guò)script.bin boardfexcnanopi-neo2 / orangepi-pc2 等通過(guò)u-boot串口打印minicomAllwinner H5 (SUN50I)通過(guò)/proc/cpuinfocatCPU part 0xd03通過(guò)這個(gè)流程看起來(lái)繁瑣但比“刷完再看現(xiàn)象”要高效得多。批量生產(chǎn)環(huán)境里50塊板子只要出現(xiàn)一塊型號(hào)混料整批返工的成本就能讓你懷疑人生。6. 幾個(gè)容易誤判的邊界情況與我的處理經(jīng)驗(yàn)6.1 H5與H2/H3共用內(nèi)核時(shí)的“半兼容”陷阱H5和H3在引腳上很接近有些第三方內(nèi)核會(huì)把H3和H5的支持編在同一個(gè)鏡像里通過(guò)不同的dtb來(lái)區(qū)分。這種內(nèi)核在啟動(dòng)時(shí)可能不會(huì)打印明顯的“H5”字樣而是顯示“Allwinner sochip”之類的通用文案這時(shí)候看內(nèi)核日志容易發(fā)懵。我的經(jīng)驗(yàn)是遇到這種半兼容內(nèi)核除了dtb還要看/sys/firmware/devicetree/base/model這個(gè)節(jié)點(diǎn)。它是由dtb的model屬性生成的比compatible更直觀。比如cat /sys/firmware/devicetree/base/model如果輸出“Xunlong Orange Pi PC2”那處理器類型就不會(huì)有誤會(huì)。model字段是根節(jié)點(diǎn)里的可讀字符串雖然不代表芯片家族名但配合板型可以反推SoC。這一招在“固件里啥標(biāo)識(shí)都刪了”的情況下尤其有用。6.2 改固件里的開機(jī)logo/版本號(hào)是否會(huì)影響識(shí)別有些廠商喜歡在固件里改開機(jī)logo、Android版本號(hào)、build.prop里的硬件名這在一定程度上會(huì)干擾識(shí)別。我記得有一次拿到一個(gè)標(biāo)著“H5四核”的盒子固件解包后看build.prop里的ro.product.board寫的是“H5”但dtb卻是sun8i-h3的最后實(shí)測(cè)發(fā)現(xiàn)它其實(shí)是H3板子。這種“軟改身份”的固件大量存在于低端盒子市場(chǎng)不能只看用戶可見的版本號(hào)一定以dtb和內(nèi)核架構(gòu)為準(zhǔn)。警惕點(diǎn)在于軟件層的標(biāo)識(shí)可以被隨便改但硬件描述文件不行。dtb里的compatible、內(nèi)核鏡像的架構(gòu)、boot0的啟動(dòng)協(xié)議都是真金白銀的代碼邏輯改錯(cuò)任何一個(gè)系統(tǒng)就跑不起來(lái)。所以我的最終結(jié)論永遠(yuǎn)是先看boot0簽名再看內(nèi)核架構(gòu)最后信dtb。6.3 通過(guò)外設(shè)反推主控型號(hào)的輔助思路最后再說(shuō)一個(gè)輔助手段通過(guò)板載外設(shè)的電路特征反推主控。最近“38khz紅外發(fā)射接收模塊python紅外鍵值補(bǔ)碼h5”這類詞也常被搜到說(shuō)明不少人會(huì)在嵌入式板子上接紅外模塊然后用Python解析遙控器鍵值。但紅外模塊本身是一個(gè)極通用的外設(shè)接在H3上、H5上甚至單片機(jī)上都能工作所以它沒法作為判斷主控型號(hào)的依據(jù)。不過(guò)如果你在設(shè)備樹里看到了一段紅外接收的引腳定義比如把某個(gè)GPIO bank配置成了ir_rx功能那這個(gè)引腳的bank編號(hào)和復(fù)用選項(xiàng)多多少少能反映主控型號(hào)的管腳布局。H3和H5雖然管腳兼容但引腳復(fù)用的內(nèi)部寄存器結(jié)構(gòu)有差異設(shè)備樹里ir_rx指定的gpio controller路徑如果是/soc/pinctrl1c20800這類地址那兩者是一樣的如果地址不同就需要警惕。這類方法屬于“錦上添花”的旁證真正做判斷時(shí)還是以固件內(nèi)部的boot0、內(nèi)核架構(gòu)、dtb三者為準(zhǔn)。外設(shè)信息更適合拿來(lái)確認(rèn)“這塊板的其它硬件版本”比如知道是AP6212還是RTL8723BS方便確定WiFi固件路徑。說(shuō)到底“Distinguishing H5 processor type from firmware”這件事并沒有多高深難的是養(yǎng)成一個(gè)嚴(yán)謹(jǐn)?shù)淖R(shí)別習(xí)慣。我自己踩過(guò)幾次“標(biāo)簽寫著H5、實(shí)際上H3”的坑之后養(yǎng)成了一個(gè)兜底動(dòng)作任何固件刷進(jìn)去之前必須拆開看一眼boot0再掃一遍dtb哪怕它是官方下載頁(yè)直接拉下來(lái)的。因?yàn)檫@個(gè)世界的二手板子、翻新盒子、魔改固件比你想的多得多而固件自己不會(huì)說(shuō)謊——只要你會(huì)聽。