最近盤點了手上幾塊閑置的開發(fā)板發(fā)現(xiàn)最有價值、也最值得拿出來聊一聊的反而是那塊ARM Cortex A8的System on ModuleSoM核心板。這兩年做工業(yè)控制相關的項目最后硬件方案定下來的居然是這顆看起來“有點年頭的芯片”搭配核心板形態(tài)說實話自己一開始也沒想到。SoM這類模塊把CPU、DDR、eMMC、電源管理這些難啃的硬骨頭預先集成好用戶拿到的是一塊經(jīng)過驗證的核心小板只需要按產(chǎn)品需求設計自己的底板外設就行。對中小團隊、個人開發(fā)者、以及想快速出原型驗證方案的人來說這種模式是真的省心。這篇文章就圍繞這個平臺把選型邏輯、硬件設計要點、交叉編譯環(huán)境、調(diào)試方法和常見坑位完整梳理一遍給同樣在評估Cortex A8 SoM方案的朋友做參考。1. 項目背景與方案選型為什么是Cortex A8 SoM很多人一聽到Cortex A8第一反應是“這玩意兒是不是太老了”畢竟現(xiàn)在手機上的ARM核心都已經(jīng)到Cortex-X系列了。但嵌入式工業(yè)產(chǎn)品和消費電子完全是兩個節(jié)奏。Cortex A8在工控、醫(yī)療、電力、物聯(lián)網(wǎng)網(wǎng)關這些領域還有大量存量市場芯片供貨穩(wěn)定BSP完善資料豐富而且價格早就被攤薄了。加上SoM這種產(chǎn)品形態(tài)本身就是為了降低開發(fā)門檻而存在的兩者結(jié)合起來對一個要快速出貨的項目來說反而是一條非常務實的路徑。1.1 先搞清楚SoM到底解決了什么問題SoM全稱System on Module國內(nèi)通常叫核心板或者模塊系統(tǒng)。它和整板設計的核心區(qū)別在于SoM把“技術難度高、但差異化價值低”的部分集成到一起比如處理器、DDR顆粒、eMMC/NAND Flash、PMU電源管理單元、時鐘晶振甚至網(wǎng)絡PHY都會放上去。這些部分恰恰是硬件設計中最容易出問題的區(qū)域——DDR布線要等長、阻抗匹配要高精度、電源時序要嚴格、高速信號要控干擾哪一項做不好都是“能用但偶發(fā)死機”這種最難排查的故障。我需要提醒的就是SoM最大的價值不是省那幾顆料而是省掉了一整個維度的debug時間。底板設計你只需要關心外圍接口RS485電平轉(zhuǎn)換、CAN收發(fā)器、繼電器驅(qū)動、ADC前端采集、以太網(wǎng)變壓器座、LCD接口這些難度直接從“高速數(shù)字電路”降到了“常規(guī)外圍電路”的層級。實際上用了SoM之后硬件工程師可以把精力放在產(chǎn)品的差異化部分而不是反復去驗證DDR信號完整性和電源紋波。1.2 Cortex A8這顆“老芯片”憑什么還能打Cortex A8是ARM第一代超標量Cortex應用處理器主頻通常落在600MHz到1GHz這個區(qū)間。在SoM生態(tài)里最典型的代表就是TI的AM335x系列基于Cortex A8核心集成了SGX530 GPU、Ethernet MAC、CAN控制器、PRU協(xié)處理器等一大堆工業(yè)場景需要的功能。相比Cortex A9和A7A8的流水線更深同頻性能其實并不差關鍵是對外的接口非常齊全工業(yè)級溫寬-40到85度的型號也很多這是很多消費級ARM芯片給不了的。和Cortex A7比A8沒有明顯劣勢在單核性能上反而更好。和A9比A8少一個核心但功耗更低、更穩(wěn)定。對于單進程處理為主的工控應用比如HMI人機界面、協(xié)議網(wǎng)關、數(shù)據(jù)采集終端A8的性能完全夠用。加上AM335x系列的PRU協(xié)處理器還能做實時IO控制這在Linux系統(tǒng)下做硬實時擴展很自然是很多純A8/A9芯片不具備的。1.3 選型時最在意的幾個指標我在評估SoM方案時會按下面的優(yōu)先級來看順序基本就是決定項目成敗的權重排序選型指標為什么重要我的判斷標準引腳兼容性核心板換型號/升級不用重畫底板同一封裝下有多個型號可選引腳pin-to-pin兼容BSP成熟度直接決定軟件工程師的存活率官方提供完整U-Boot/內(nèi)核/文件系統(tǒng)長期維護供貨周期工業(yè)項目生命周期通常5-10年芯片廠商明確承諾工業(yè)級10年供貨文檔與社區(qū)資料遇到問題能否自己解決官方有詳細的TRM技術參考手冊、勘誤表、應用筆記價格與起訂量成本復核可行性單顆芯片價格和最小起訂量都在可接受范圍對Cortex A8這個級別的SoM一般核心板價格在200到500元之間底板自己打樣整套硬件成本控制起來非常靈活。如果直接畫整板光是DDR3布線要處理的信號完整性問題就夠團隊喝一壺的。這也是越來越多方案商寧可多花幾百塊買核心板也不愿意自己去啃高速布線的核心原因。2. 硬件架構(gòu)與關鍵電路設計要點確定了SoM方案之后還得知道核心板上到底發(fā)生了什么。畢竟軟件工程師要寫驅(qū)動、調(diào)設備樹對硬件結(jié)構(gòu)沒有概念的話做起來會非常吃力。這里以典型的AM335x Cortex A8核心板為例把硬件架構(gòu)拆開來看。2.1 核心板內(nèi)部都有什么一個標準的Cortex A8 SoM核心區(qū)域通常包含以下幾大塊處理器AM335x系列Cortex A8內(nèi)核主頻最高1GHz工業(yè)級型號可到800MHz。DDR3內(nèi)存常見配置為256MB到1GB采用128Mb/256Mb×16bit顆粒組合數(shù)據(jù)總線寬度通常是16bit兩顆疊die組成32bit。存儲4GB到16GB eMMC或者NAND Flash。eMMC方案是目前的主流原因是軟件升級和系統(tǒng)穩(wěn)定性都更好。PMU電源管理單元典型的如TPS65217提供多路DCDC和LDO輸出完成上電時序。以太網(wǎng)PHY很多SoM會直接板載一顆MAC PHY芯片比如AR8031/AR8035引出RJ45接口省掉底板的以太網(wǎng)設計。時鐘24MHz主晶振32.768kHz RTC晶振以及DDR顆粒需要的參考時鐘。SoM的核心設計理念就是“能放上去的高難度器件都放上去”。底板B2B連接器或者郵票孔焊盤引出的通常是帶保護的GPIO、串口、CAN、USB、以太網(wǎng)、LCD信號。這些信號電平在底板上做轉(zhuǎn)換不需要再跑高速DDR信號這就是SoM能保持體積小但可靠性高的原因。2.2 DDR等長布線與電源完整性的那些坑如果你自己去畫整板DDR3部分的布線規(guī)則是最考察硬件功底的。DDR3工作在400MHz到800MHz信號上升沿非常陡要走Fly-by拓撲盡量緩解反射和同步開關噪聲。先說等長DDR3地址/控制信號組要求相對于時鐘信號等長偏差一般控制在±20mil以內(nèi)數(shù)據(jù)信號組DQ/DQS/DM以字節(jié)通道為單位每組內(nèi)部等長偏差控制在±5mil以內(nèi)而且DQ到DQS需要做相對時序差補償。這個活兒用Cadence Allegro或者Altium的Interactive Diff Pair Length Tuning工具調(diào)起來很磨人手工拉線經(jīng)常一拉就是一整天。再說電源完整性DDR3的VDD和VTT供電質(zhì)量直接影響系統(tǒng)穩(wěn)定性。核心板通常采用同步降壓轉(zhuǎn)換器輸出1.5V/1.35V DDR電源VTT基準電壓必須從源端經(jīng)過去耦電阻和磁珠隔離后單獨供給。布線時要注意DDR電源層必須有完整的參考平面回流路徑不能被分割否則會出現(xiàn)“常溫下沒事一跑高溫就死機”這種詭異故障。如果你選用成熟的SoM模塊這些問題都已經(jīng)由模塊廠商解決了。設備樹里會看到DDR3的時序參數(shù)配置這些參數(shù)是基于PCB的布線和芯片datasheet標定好的。你自己做底板時只需要給SoM供電根本不用管DDR信號。這也是為什么我前面強調(diào)使用SoM不是浪費錢而是把高速電路設計風險轉(zhuǎn)嫁給模塊廠商這比省幾百塊錢重要得多。2.3 電源樹與時序設計的思路Cortex A8核心板的電源樹比MCU復雜得多通常有這么多路VDD_CORE核心電壓0.9V到1.1V左右動態(tài)調(diào)壓給ARM核和內(nèi)部邏輯供電。VDD_MPUMPU電壓1.1V到1.3V左右專門給Cortex A8處分。VDDS_DDRDDR3供電1.5V或1.35V取決于DDR3L還是DDR3。VDDS_SRAMSRAM待機電壓1.8V。VDDS_A模擬電源比如ADC、PLL、USB PHY、以太網(wǎng)PHY等通常3.3V。VDDS_RTCRTC電源獨立1.8V或3.3V。PMU芯片的主要工作不是簡單降壓而是管理上電時序。典型上電順序為先給RTC電源然后是SRAM電源核心電壓再是IO電源最后是DDR電源和模擬電源。順序錯了芯片長期工作會出現(xiàn)內(nèi)部閂鎖Latch-up風險直接燒掉芯片都不是沒可能。官方勘誤表里專門有一條就是關于電源時序要求的我建議做硬件設計的人把TRM里的Power Sequencing章節(jié)完整讀一遍這比看100篇博客都有用。從底板設計角度你需要關心的是SoM引出的電源域有哪些。一般SoM會把3.3V和5V的IO電源引到B2B連接器上底板外設直接掛這些電源就行。電源紋波控制在50mV內(nèi)是基礎要求如果外設里有模擬電路或者射頻模塊還需要額外加LC濾波避免開關頻率干擾。3. 軟件工具鏈與交叉編譯環(huán)境搭建硬件平臺確定之后軟件才是大頭。Cortex A8上跑的是Linux或者裸機程序絕大多數(shù)場景都是Linux。既然是ARM處理器所有軟件都必須依賴交叉編譯在x86的PC上生成ARM架構(gòu)的可執(zhí)行文件。這個過程對剛?cè)腴T的嵌入式工程師來說最容易卡住的地方就是工具鏈的選擇和環(huán)境變量的配置。3.1 ARM GNU工具鏈版本選擇的第一課做交叉編譯第一步就是選對工具鏈。對于Cortex A8常見的有三個選擇arm-none-eabi-gcc用于裸機開發(fā)沒有Linux用戶空間支持編譯出來的程序不依賴操作系統(tǒng)直接跑在硬件上。適合做裸機固件、RTOS應用。arm-linux-gnueabihf-gcc用于帶Linux系統(tǒng)的用戶空間程序編譯支持硬浮點針對ARMv7-A架構(gòu)。Cortex A8帶VFPv3浮點單元用gnueabihf版本能發(fā)揮浮點性能。Linaro GCC針對ARM的長期支持工具鏈版本更新快性能優(yōu)化好是很多板級SDK的基礎。一個很典型的坑是用錯了工具鏈版本編譯出來的程序要么段錯誤要么直接提示Illegal instruction。比如你用arm-none-eabi-gcc去編譯Linux用戶態(tài)程序鏈接階段就過不了因為缺少libc和動態(tài)鏈接器。用arm-linux-gnueabi軟浮點版去跑硬浮點環(huán)境老版本的glibc會出現(xiàn)浮點參數(shù)傳遞不一致的問題。所以選工具鏈之前先確認目標系統(tǒng)的glibc版本和動態(tài)鏈接器路徑再決定工具鏈版本。我習慣的做法是直接用板卡SDK里自帶的工具鏈或者從Linaro官方下載最新的arm-linux-gnueabihf工具鏈解壓到/opt目錄然后手動設置環(huán)境變量export PATH/opt/gcc-arm-linux-gnueabihf/bin:$PATH export CROSS_COMPILEarm-linux-gnueabihf- export ARCHarm這三行環(huán)境變量算是所有ARM交叉編譯的基礎。ARCH告訴內(nèi)核構(gòu)建系統(tǒng)目標架構(gòu)是armCROSS_COMPILE指定前綴讓Makefile自動調(diào)用arm-linux-gnueabihf-gcc、arm-linux-gnueabihf-ld這些工具。3.2 U-Boot與內(nèi)核編譯跟著Makefile走一遍拿到Cortex A8 SoM之后要構(gòu)建系統(tǒng)鏡像核心就三步編譯U-Boot引導程序、編譯Linux內(nèi)核、構(gòu)建根文件系統(tǒng)。U-Boot編譯相對簡單因為它每個板卡都有單獨配置文件。以AM335x為例make am335x_evm_defconfig make -j8編譯完會生成MLO和u-boot.img兩個文件。MLO是TI特有的二級引導加載器放在SD卡的FAT分區(qū)或者eMMC的boot分區(qū)里負責初始化DDR和外設再將U-Boot主程序加載到內(nèi)存。U-Boot主程序再引導內(nèi)核。內(nèi)核編譯稍微麻煩一些因為需要先選設備樹和內(nèi)核配置make omap2plus_defconfig make zImage make am335x-evm.dtb這里有個細節(jié)Cortex A8的DTS設備樹源文件會定義板卡上的所有硬件外設比如串口地址、GPIO復用、LCD時序、以太網(wǎng)MAC、CAN控制器等。如果你在底板上新增了一個I2C設備或者換了一個LCD屏都需要修改對應的DTS節(jié)點重新編譯設備樹。設備樹寫錯最典型的癥狀是“某個外設能識別但驅(qū)動加載失敗”所以每次修改DTS后我都建議先用dtc工具反編譯看實際加載的設備樹內(nèi)容確認節(jié)點確實生效了。3.3 根文件系統(tǒng)與Busybox的交叉編譯內(nèi)核跑起來之后必須掛載根文件系統(tǒng)否則系統(tǒng)只能停在Kernel panic - not syncing: VFS: Unable to mount root fs。對于精簡的嵌入式系統(tǒng)最常用的做法是使用Busybox構(gòu)建最小根文件系統(tǒng)。Busybox號稱Linux系統(tǒng)的瑞士軍刀把ls、cp、sh、init等幾百個常用命令合并成一個靜態(tài)鏈接的可執(zhí)行文件大小只有幾百KB。交叉編譯Busybox的命令如下make ARCHarm CROSS_COMPILEarm-linux-gnueabihf- defconfig make ARCHarm CROSS_COMPILEarm-linux-gnueabihf- menuconfig make ARCHarm CROSS_COMPILEarm-linux-gnueabihf- -j8編譯完成后在busybox目錄下執(zhí)行make install會生成一個_install目錄里面就是基本的目錄結(jié)構(gòu)和busybox軟鏈接。再手動創(chuàng)建一些系統(tǒng)目錄加上必要的設備節(jié)點用cp命令把交叉編譯好的glibc庫libc.so、ld-linux.so等拷進lib目錄基本上就是一個可啟動的根文件系統(tǒng)了。但這里有一個天坑Busybox默認編譯配置可能不帶動態(tài)加載支持如果你后續(xù)要在系統(tǒng)里跑Qt等重量級應用動態(tài)庫依賴會很難處理。更讓我頭疼的是如果工具鏈的glibc版本和之前編譯內(nèi)核時用的工具鏈glibc版本不同從文件系統(tǒng)啟動時經(jīng)常出現(xiàn)“version GLIBC_2.27 not found”這類錯誤。遇到這種情況要么升級/降級工具鏈要么直接用Buildroot或Yocto一鍵生成完整系統(tǒng)鏡像少走彎路。3.4 Qt應用在嵌入式Linux上的部署如果產(chǎn)品要做HMI人機界面Qt是繞不開的方案。Cortex A8 SGX530 GPU雖然性能有限但跑Qt的EglFS模式做一個簡單的觸摸界面還是相當流暢的。Qt的交叉編譯比普通C程序復雜得多。你需要先編譯Qt庫本身再編譯你的應用程序。典型的配置步驟./configure -prefix /opt/qt-5.15.2-arm \ -xplatform linux-arm-gnueabihf-g \ -eglfs -opengl es2 \ -no-feature-vnc -no-feature-xcb \ -nomake examples -nomake tests \ -release make -j8 make install重點在于xplatform參數(shù)它指定了Qt的交叉編譯平臺描述文件。如果不指定Qt默認會按x86桌面平臺編譯生成的庫根本沒法在ARM上跑。即使交叉編譯成功部署時也要注意把Qt的插件目錄platforms、imageformats等和動態(tài)庫完整拷貝到根文件系統(tǒng)對應的路徑否則跑起來會直接報qt.qpa.plugin: Could not find the Qt platform plugin eglfs這個經(jīng)典錯誤。我對Qt交叉編譯的建議是能用Buildroot就別裸編譯。Buildroot把工具鏈、內(nèi)核、根文件系統(tǒng)、Qt庫、應用集成到一條流水線上生成鏡像后直接燒錄底層的依賴問題大部分都被自動處理了。之前裸著編譯Qt浪費了我整整兩天時間換成Buildroot之后兩小時就出鏡像了項目周期緊張的時候效率就是王道。4. 虛擬化調(diào)試環(huán)境QEMU模擬ARM開發(fā)板在拿不到實體板卡之前QEMU模擬器是預研和算法驗證的好幫手。尤其對于Cortex A8這種級別性能模擬相對成熟跑一個精簡Linux系統(tǒng)完全沒問題。很多人在找“ARM開發(fā)板模擬器”的時候默認就是QEMU因為它是目前最通用的開源方案。4.1 為什么需要模擬器沒有模擬器的時代每次寫底層代碼都要反復燒寫SD卡、刷eMMC那不僅是時間成本還有燒寫次數(shù)多了導致Flash壽命的問題。當你需要反復驗證內(nèi)核配置、測試根文件系統(tǒng)依賴、調(diào)應用程序啟動流程時QEMU的啟動時間通常只有10幾秒比硬件板卡還要快而且可以直接掛接GDB調(diào)試內(nèi)核和應用程序調(diào)試體驗比實體板還順。另一個典型場景是跨平臺CI。如果你的團隊沒有足夠的實體板卡分配給每個開發(fā)人員可以在CI服務器上啟動QEMU虛擬機跑自動化測試用例。我就是用QEMU來跑TCP協(xié)議網(wǎng)關的壓力測試沒有給每臺開發(fā)機配板子服務器上同步用QEMU模擬ARM環(huán)境效果很穩(wěn)定。4.2 QEMU在Cortex A8平臺上的實測用法Cortex A8的模擬QEMU支持比較齊全的是TI的AM335x系列對應的機器型號是ti_sitara或者beaglebone等?；締用钊缦聁emu-system-arm -machine beaglebone \ -m 512M \ -kernel zImage \ -dtb am335x-bone.dtb \ -drive filerootfs.ext4,formatraw \ -append consolettyO0,115200 root/dev/mmcblk0 rw \ -serial stdio \ -net nic -net user注意Cortex A8的調(diào)試串口在AM335x上叫ttyO0不是ttyS0這個細節(jié)直接關系到你能否在串口終端看到內(nèi)核日志。我第一次用QEMU跑AM335x時append參數(shù)里寫錯了串口名控制臺一片空白排查了半天才發(fā)現(xiàn)是控制臺參數(shù)的問題。用QEMU啟動之后就能在串口終端里看到完整的Linux啟動日志進入shell。我在QEMU里完成過U-Boot啟動階段的測試。方法是先用QEMU加載MLO和u-boot.imgqemu-system-arm -machine beaglebone -m 256M \ -sd sd_image.img \ -serial stdio把U-Boot寫到SD卡鏡像里QEMU就能從SD卡啟動完整模擬ROM → MLO → U-Boot → kernel的啟動鏈路。調(diào)試U-Boot階段這個方式比反復插拔SD卡高效得多。芯片的啟動模式撥碼開關與SD卡分區(qū)結(jié)構(gòu)的配合也能在QEMU里反復驗證做板卡生產(chǎn)時就能避免“燒錄成功但無法啟動”的問題。4.3 模擬器與現(xiàn)實板卡之間容易踩的坑用模擬器調(diào)試有個大坑就是感覺“在模擬器上能運行在真板上起不來”的現(xiàn)象。我踩過一次在QEMU里跑得好好的一個內(nèi)核配置燒到真板之后發(fā)現(xiàn)以太網(wǎng)驅(qū)動根本不工作。原因很簡單QEMU模擬的以太網(wǎng)控制器和真實板卡上的PHY芯片并不是同款驅(qū)動模型差別巨大。模擬器只能驗證軟件邏輯和系統(tǒng)流程沒法驗證外設驅(qū)動的硬件相關性。所以我的習慣是模擬器只用來驗證“與硬件無關”的部分比如文件系統(tǒng)完整性、啟動腳本、應用程序邏輯一旦涉及外設驅(qū)動、時鐘配置、DDR時序必須拿到真實板卡上調(diào)試。否則就是自己騙自己項目最后一樣要花大把時間在真機聯(lián)調(diào)上。5. 常見問題與排查技巧實錄在實際開發(fā)過程中總會遇到各種千奇百怪的問題這里把幾個經(jīng)典場景的排查過程和解決方案整理出來希望能幫人少走彎路。5.1 Keil中ARM Compiler許可證錯誤c9555e怎么處理很多做Cortex A8 SoM底板的工程師同一時間還會用Keil MDK做MCU開發(fā)。經(jīng)常遇到的報錯是ARM Compiler許可證錯誤c9555eKeil打開工程直接編譯不了。這個錯誤出現(xiàn)在Keil使用ARM Compiler 5.06時最常見因為編譯器授權驗證文件過期或者被誤刪導致IDE認為許可證無效。處理辦法分三步先檢查許可證狀態(tài)打開Keil uVision點擊File → License Management看能否看到有效的ARM Compiler許可證記錄。如果顯示invalid或者沒有就需要重新激活。其次卸載重裝對應版本的ARM Compiler官方下載地址能找到ARM Compiler 5.06 update 7build 960安裝后通常能修復c9555e錯誤。最后如果重裝編譯器還是不行檢查殺毒軟件是否把FlexNet的許可證文件當病毒清理了在信任區(qū)加白名單一下。這個錯誤和ARM Cortex A8的Linux交叉編譯沒什么關系ARM Compiler 5.06是MDK里用來編譯MCU程序的很多做ARM開發(fā)的人容易把這兩個“ARM編譯器”混為一談。實際上一套是ARM自家商業(yè)編譯器另一套是GNU開源工具鏈兩者針對的目標平臺和生態(tài)完全不同。5.2 交叉編譯工具鏈的一些“隱形”陷阱交叉編譯的坑很多時候不是語法問題而是環(huán)境問題。第一個坑是“使用”-static“靜態(tài)鏈接但庫不完整”。在Cortex A8上跑一個數(shù)據(jù)采集程序用arm-linux-gnueabihf-gcc編譯時加了-static參數(shù)編譯成功但運行時報Segmentation fault。查下來是因為靜態(tài)鏈接了glibc的NSS模塊而這個模塊在目標板上的/etc/nsswitch.conf和庫緩存不匹配。解決辦法很簡單去掉-static用動態(tài)鏈接方式并把對應的.so庫拷貝到目標板。第二個坑是“硬浮點和軟浮點的ABI不兼容”。Cortex A8支持硬浮點VFPv3但如果你用了gnueabi軟浮點工具鏈編譯的庫去鏈接gnueabihf硬浮點編譯的程序鏈接器會報“selected processor does not support pld”或者直接報錯無法解析符號。排查思路是檢查工具鏈前綴和系統(tǒng)內(nèi)庫的編譯方式是否一致。第三個坑是“文件系統(tǒng)屬性錯亂”。每次用root用戶交叉編譯的文件拷貝到目標板后權限位可能丟掉。別人遇到過啟動時提示“-sh: ./app: Permission denied”ls -l看文件權限明明是755。最后用stat命令看了inode屬性才發(fā)現(xiàn)是ext4的security.capability屬性被錯誤設置用setcap -r命令清理后解決。5.3 ARM平臺上的應用軟件兼容性問題Cortex A8跑的是ARM架構(gòu)Linux很多習慣在x86上用的閉源軟件在ARM上根本沒有對應版本。最常見的就是Navicat在ARM服務器上裝navicat基本是裝不了的很多地方安裝失敗就是因為只有x86的deb包強行安裝之后會提示Exec format error。遇到這種情況我的原則是“先找替代方案再考慮源碼編譯”。數(shù)據(jù)庫管理工具在ARM上可以用DBeaver或者命令行客戶端代替容器部署的話先確認docker是否有ARM版本鏡像。這里要專門說一個點docker desktop本身在ARM Mac上沒問題但如果你在中國市場常見的統(tǒng)信UOS等ARM系統(tǒng)上裝docker直接用軟件源里的版本往往依賴關系殘缺我見過有人安裝依賴文件后無法運行的大概率是libc6版本和docker二進制不兼容。處理方法是優(yōu)先用發(fā)行版自帶倉庫的docker.io包或者自己下載對應的arm64版本靜態(tài)二進制包手動部署。另一個讓我印象很深的場景是存儲性能測試工具vdbench。很多搞存儲的同事習慣在x86服務器上跑vdbench換到ARM服務器上就發(fā)現(xiàn)原生的vdbench只有x86版本。其實vdbench是基于Java的只要ARM上有對應架構(gòu)的JRE就能跑不需要特意找ARM版安裝ARM版的JDK8之后直接執(zhí)行vdbench腳本就行。5.4 常見問題速查表問題現(xiàn)象可能原因排查步驟啟動后串口無輸出U-Boot燒錄位置錯誤或DDR初始化失敗檢查MLO分區(qū)位置確認啟動撥碼開關檢查DDR電源內(nèi)核啟動到一半停止設備樹和硬件不匹配用dtc反編譯DTB核對硬件引腳復用交叉編譯程序提示Illegal instruction工具鏈浮點ABI不匹配確認工具鏈hf/eabi重新編譯以太網(wǎng)丟包嚴重PHY供電紋波過大示波器測PHY供電紋波增加濾波電容Qt程序無法啟動eglfs缺少GPU驅(qū)動或插件目錄不完整檢查libQt5EglFs.so是否存在確認SGX驅(qū)動加載系統(tǒng)時間每次重啟都重置RTC時鐘未配置或電池沒電確認RTC設備樹節(jié)點檢查RTC電池電壓文件系統(tǒng)只讀掛載eMMC文件系統(tǒng)壞塊過多用fsck檢查文件系統(tǒng)考慮換eMMC6. 這個平臺后續(xù)還能怎么擴展Cortex A8的SoM做完了第一版之后接下來的擴展方向其實很明確。如果你想在同一個底板上做性能升級業(yè)內(nèi)主流做法是找引腳兼容的更高端核心板比如從AM335x升級到AM437x或者AM57x這兩款雖然核心不同但很多底板設計是可以平移的。做產(chǎn)品規(guī)劃的時候從一開始就預留好引腳兼容的擴展位能省掉一次完整的改版成本。如果你的應用開始涉及到圖像處理或者輕量級AI推理Cortex A8內(nèi)置的SGX530 GPU確實有些吃力。此時可以考慮外掛一顆USB接口的NPU加速棒或者換用帶NPU的SoM模塊比如瑞芯微RK3588S、算能BM1684這類雖然核心不是Cortex A8了但軟件框架和交叉編譯的思路完全一樣。對嵌入式Linux工程師來說工具鏈的使用、設備樹的修改、Uboot的編譯流程這些底層技能是通用的換平臺只是換個配置而已。從量產(chǎn)角度來看用SoM方案還有一個好處是核心板單獨做老化測試底板只負責外圍接口生產(chǎn)故障率會低很多。我見過整板方案出貨后出現(xiàn)DDR虛焊導致的現(xiàn)象在SoM方案里基本不會出現(xiàn)。這也是為什么很多工業(yè)級產(chǎn)品寧愿成本高一點也要用核心板模塊廠商在SMT工藝和測試流程上的積累不是一般組裝廠能替代的。另外如果你手頭正好有閑置的Cortex A8板子建議別急著吃灰拿它來練手Linux驅(qū)動開發(fā)、學一學設備樹語法、跑一跑Buildroot構(gòu)建系統(tǒng)都是性價比非常高的學習路徑。這塊“老平臺”的文檔和資料在網(wǎng)絡上非常豐富遇到的問題幾乎都有人踩過學習曲線比最新旗艦芯片平滑得多。我在實際使用中發(fā)現(xiàn)最終把一個項目做成功的往往不是平臺有多新而是你手里這套工具鏈有多稱手、對平臺的每個細節(jié)有多少把握。