1. ARM體系架構(gòu)的底層邏輯先搞清楚自己在寫誰的代碼1.1 指令集架構(gòu)與處理器內(nèi)核的“血緣關(guān)系”ARM這個詞其實是個簡稱它包含了兩層意思一層是指令集架構(gòu)ISA另一層是具體處理器內(nèi)核。指令集架構(gòu)定義了CPU能聽懂哪些指令、寄存器和地址空間長什么樣、異常是怎么處理的它是一份規(guī)范而Cortex-A76、Cortex-M4這些才是按規(guī)范造出來的具體“核”。兩者之間的關(guān)系可以這樣理解指令集架構(gòu)是憲法處理器內(nèi)核是依據(jù)憲法制定的民事法律。ARMv7、ARMv8、ARMv9-A這些版本號是憲法條款而你在芯片選型時看到的A53、A72、M4、M7都是在這套條文約束下設(shè)計出來的實現(xiàn)。同一個ARMv8-A指令集高通可以做成驍龍,蘋果可以做成M系列瑞芯微也能做出來RK3588。指令集一樣不代表性能一樣因為它們用的微架構(gòu)完全不同。這對軟件編程的意義非常直接你的編譯產(chǎn)物只要符合某個ARM架構(gòu)版本和ABI規(guī)范理論上就能在不同廠商的同類內(nèi)核上運行。比如你為ARMv8-A 64位編譯的Linux用戶態(tài)程序放到A53、A72、還是A76上大概率都能跑。但如果你把針對Cortex-M3編譯的裸機(jī)程序硬塞給Cortex-A53那肯定是跑不起來的因為這兩個東西連指令集都不一樣。很多人會把“ARM”直接等同于“單片機(jī)”其實這是一個很常見的誤解。ARM不止有Cortex-M這種重量級輕的MCU核心還有Cortex-A這種能跑完整Linux的應(yīng)用處理器還有Cortex-R這種面向?qū)崟r控制、硬實時要求比較高的內(nèi)核。后面聊軟件編程的時候我會反復(fù)強(qiáng)調(diào)一個觀點只有先搞清楚目標(biāo)屬于A/R/M哪個家族再去談工具鏈、系統(tǒng)鏡像和啟動代碼才不會在第一步就選錯方向。1.2 RISC設(shè)計哲學(xué)為什么ARM能靠精簡指令打贏功耗戰(zhàn)ARM是典型的RISC精簡指令集計算機(jī)架構(gòu)這是它和x86最根本的差別。RISC的核心思想是讓單條指令足夠簡單盡量保證大部分指令能在一個時鐘周期內(nèi)執(zhí)行完同時要求所有數(shù)據(jù)處理都在寄存器之間進(jìn)行內(nèi)存訪問只能通過專門的Load/Store指令完成。舉個例子在x86上你可能會看到類似“把內(nèi)存地址里的值加1再寫回去”這樣的復(fù)雜指令一個指令能讀寫內(nèi)存還能做運算但在ARM上你需要先LDR把內(nèi)存讀到寄存器然后ADD做加法最后用STR把結(jié)果存回內(nèi)存?？雌饋碇噶顥l數(shù)多了但換來的是硬件設(shè)計大幅簡化、功耗顯著降低編譯器也能通過流水線和調(diào)度算法把這些指令排得更緊湊。這套設(shè)計在移動和嵌入式場景下特別吃香。為什么手機(jī)SoC普遍選擇ARM而不是x86因為同樣的低功耗預(yù)算下ARM能做到更復(fù)雜的多核布局和更靈活的頻率調(diào)節(jié)。你看現(xiàn)在手機(jī)處理器天梯圖里那些旗艦芯片基本都是8核10核的加成這種堆核思路放在x86上很難控制功耗。你需要記住的是RISC架構(gòu)雖然指令簡單但并不意味著寫匯編更簡單。恰恰相反ARM的條件執(zhí)行、桶形移位器、大量通用寄存器這些東西反而讓匯編代碼看起來更靈活也更考驗人的基本功。我見過不少從51單片機(jī)、AVR往ARM轉(zhuǎn)的開發(fā)者一開始總習(xí)慣把外設(shè)寄存器當(dāng)普通變量一樣直接讀寫結(jié)果遇到Cache和總線問題后一臉懵。這些后面會展開講。1.3 處理器天梯圖背后的真相微架構(gòu)與超標(biāo)量每次有人問我“A78和A76差多少”“驍龍?zhí)焯輬D為什么A系列排在前面”我都會先糾正一個問題天梯圖比較的是綜合性能但它背后真正的驅(qū)動因素是微架構(gòu)而不只是架構(gòu)版本號。ARMv8-A是個基底但一顆使用了亂序執(zhí)行的A78核心同一時間可以同時追蹤幾十條指令找出哪些可以并行執(zhí)行而一顆順序執(zhí)行的A53核心耗電少、發(fā)熱低但單核性能只有A78的零頭。所謂超標(biāo)量處理器設(shè)計指的就是CPU內(nèi)部有多條流水線可以同時發(fā)射多條指令。你看楊戶的技術(shù)資料或者姚永斌那本《超標(biāo)量處理器設(shè)計》里面講的Rename、ROB、發(fā)射隊列、分支預(yù)測這些概念在ARM的A系列大核里同樣存在。對于軟件工程師來說知道這些有什么用最大的用處是調(diào)優(yōu)的時候不要只盯單指令耗時。你寫的一行C代碼會被編譯成十幾條匯編這十幾條匯編會被微架構(gòu)亂序重排。所以代碼里那些相鄰指令之間看起來“沒依賴關(guān)系”的部分往往能因為亂序執(zhí)行而更快跑完。反過來如果一段代碼頻繁出現(xiàn)分支跳轉(zhuǎn)并且分支預(yù)測老失敗哪怕指令數(shù)再少性能也會很難看。另外一定要分清ARMv8.2、ARMv8.6這些版本后綴不代表微架構(gòu)只表示架構(gòu)特性的擴(kuò)展。比如Armv8.2增加了對數(shù)學(xué)運算的改進(jìn)、Armv8.6增加了SVE2等可選向量擴(kuò)展。你編譯時要不要啟用這些擴(kuò)展指令需要目標(biāo)CPU實際支持才行。我的經(jīng)驗是做產(chǎn)品最好按最低通用架構(gòu)編譯能穩(wěn)妥跑起來再想著針對特定核心做優(yōu)化不要一上來就上最強(qiáng)指令集。1.4 怎么快速分辨自己拿到的是ARM還是x86環(huán)境這是個很基礎(chǔ)、但很容易翻車的問題。工作里我經(jīng)常見到有人把ARM版的CentOS鏡像拷到x86服務(wù)器上或者把編譯好的.aarch64的JAR包直接放到Intel機(jī)器上跑結(jié)果一執(zhí)行就報“cannot execute binary file”。判斷當(dāng)前機(jī)器是什么架構(gòu)方法其實很簡單。在Windows上可以打開PowerShell或者CMD執(zhí)行echo %PROCESSOR_ARCHITECTURE%如果是ARM64說明當(dāng)前系統(tǒng)是ARM64版本如果是AMD64或x64那就是傳統(tǒng)的x86_64環(huán)境。Windows 11還直接在“設(shè)置→系統(tǒng)→系統(tǒng)信息”里標(biāo)注了系統(tǒng)類型一眼就能看到。在Linux上更簡單uname -m返回值如果是aarch64就是64位ARM如果是armv7l那就是32位ARM通常是Cortex-A系列如果是x86_64那是Intel/AMD平臺。很多新手看到armv7l里的l會莫名其妙其實它代表“l(fā)ittle endian小端”現(xiàn)在絕大多數(shù)ARM設(shè)備都是小端模式。養(yǎng)成一個習(xí)慣下載任何工具鏈、系統(tǒng)鏡像、Java運行時之前先看一眼目標(biāo)機(jī)器的uname -m。ARM版CentOS、Ubuntu、Debian鏡像滿天飛但選錯了架構(gòu)后面的所有工作都是白費。別問我是怎么知道的——我曾經(jīng)在8GB內(nèi)存的開發(fā)機(jī)上花一下午解壓一個ARM版根文件系統(tǒng)解完才發(fā)現(xiàn)自己用的明明是x86主機(jī)。2. 寫ARM軟件必懂的五塊內(nèi)功異常、內(nèi)存、緩存、屏障與宏定義2.1 異常向量和中斷上下文不是把所有寄存器壓棧那么簡單ARM的異常模型每個軟件工程師都必須重視。哪怕你只是寫應(yīng)用層不碰啟動代碼但你調(diào)用的RTOS API底層本質(zhì)上就是在跟異常打交道。ARMv7-A/R和ARMv8-A上CPU發(fā)生異常時會跳到向量表中對應(yīng)的入口向量表基地址由VBAR寄存器控制。而在Cortex-M系列上向量表通常放在0x00000000或由VTOR指定的地址且第一項是初始堆棧指針第二項才是復(fù)位向量。這就是為什么很多STM32工程里你看到的啟動匯編第一步就是設(shè)置堆棧指針和跳轉(zhuǎn)Reset_Handler。中斷來了以后CPU自動做幾件事保存當(dāng)前狀態(tài)的必要信息、切換到特權(quán)模式、關(guān)掉部分可屏蔽中斷、跳到中斷入口。剩下的事情全靠軟件處理。在Cortex-M上硬件會自動壓棧一部分寄存器xPSR、PC、LR、R12、R3-R0但其他寄存器還是要軟件手動保存。這也就是為什么RTOS每次切換任務(wù)時會有那么一大段匯編代碼在那來回壓棧出棧。我強(qiáng)烈建議你做裸機(jī)開發(fā)時親手寫一遍中斷服務(wù)程序不要全部依賴庫函數(shù)。因為只有自己處理過“中斷里該保存什么、哪里要開屏障、哪里要清中斷標(biāo)志”你才能真正理解上下文切換的開銷和隱患。如果直接用封裝好的HAL很多細(xì)節(jié)會被藏得干干凈凈出了問題就只剩玄學(xué)調(diào)試。另外中斷服務(wù)函數(shù)里不要做耗時操作這是個老生常談的規(guī)矩但實際項目里還是會有人把printf、延時、甚至文件讀寫放到中斷里。在ARM這類高性能處理器上中斷里的一個慢操作可能直接摧毀整個實時系統(tǒng)的確定性導(dǎo)致其他高優(yōu)先級中斷被長時間屏蔽。RTOS里確實允許“中斷延遲處理”機(jī)制但那也是把耗時的活兒放到線程上下文里做而不是讓中斷SR安安心心“兼職干活”。2.2 MMU/MPU與內(nèi)存類型Register地址為什么不能隨便cache在ARM軟件編程里內(nèi)存地址不是都能用同樣方式訪問的。系統(tǒng)里存在普通內(nèi)存Normal Memory和設(shè)備內(nèi)存Device Memory兩大類。普通內(nèi)存就是RAM、Flash這些可以被Cache吸收可以亂序訪問性能好。設(shè)備內(nèi)存就是外設(shè)寄存器區(qū)比如GPIO、UART、CAN、DMA控制器的寄存器通常位于固定的物理地址段。這類地址必須嚴(yán)格按順序訪問不能Cache也不能被CPU推測執(zhí)行。如果你的代碼把寄存器地址聲明成一個普通指針然后亂讀亂寫會發(fā)生什么輕則讀到臟數(shù)據(jù)重則整個外設(shè)狀態(tài)機(jī)被帶偏。最典型的現(xiàn)象是明明是寫了一個標(biāo)志位外部設(shè)備沒反應(yīng)多讀兩次寄存器DMA忽然就亂了。這就是因為硬件沒有按你代碼里寫的順序去操作總線。在帶MMU的系統(tǒng)比如Linux上內(nèi)核里通過頁表屬性來標(biāo)記內(nèi)存是“cacheable”還是“device”。在裸機(jī)/RTOS系統(tǒng)上則靠MPU內(nèi)存保護(hù)單元配置。Cortex-M7、Cortex-M33這些內(nèi)核一般都帶MPU你要顯式把某個內(nèi)存區(qū)域配置為不可緩存、禁止執(zhí)行、只讀等等。很多開發(fā)板默認(rèn)不初始化MPU程序在簡單場景下能跑但一旦DMA和CPU同時訪問同一塊數(shù)據(jù)就會開始出現(xiàn)“偶發(fā)性”錯誤排幾個月都找不到根因。這里我給一個小建議開MPU不要貪省事全區(qū)域設(shè)成cached可寫。需要和外設(shè)交互的緩沖區(qū)尤其是DMA緩沖區(qū)務(wù)必按外設(shè)要求的內(nèi)存類型配置。DMA和Cache之間如果不做一致性處理是一對經(jīng)典冤家能吵架吵到整個系統(tǒng)隨機(jī)崩潰。2.3 Cache一致性、內(nèi)存屏障與多核調(diào)度如果說單核上Cache問題還相對容易規(guī)避那到了多核ARM上內(nèi)存一致性就變成了日經(jīng)坑。現(xiàn)代ARM應(yīng)用處理器普遍是多核每個核有私有的L1 Cache多個核共享L2/L3。當(dāng)一個核修改了內(nèi)存另一個核能不能立刻看到取決于緩存一致性協(xié)議比如大小核架構(gòu)里常見的MOESI。硬件一致性協(xié)議會幫你同步但只發(fā)生在“內(nèi)存訪問遵守協(xié)議規(guī)則”的前提下。比如你用DMA直接把數(shù)據(jù)寫進(jìn)了內(nèi)存而某個核的Cache里還留著舊數(shù)據(jù)那這個核讀到的可能是垃圾。軟件層面能做的補(bǔ)救手段是內(nèi)存屏障指令。ARM提供了三條常用屏障DMB數(shù)據(jù)存儲器屏障保證屏障前后的數(shù)據(jù)訪問按順序完成、DSB數(shù)據(jù)同步屏障必須等前面的訪問全部完成才繼續(xù)、ISB指令同步屏障用于刷新流水線。它們雖然名字都帶“barrier”但使用場景完全不同。在C語言里你可以用編譯器內(nèi)置函數(shù)__dmb()、__dsb()、__isb()或者內(nèi)聯(lián)匯編來插入屏障。在多核場景中共享數(shù)據(jù)結(jié)構(gòu)的更新順序尤其講究比如一個核先寫數(shù)據(jù)再寫“數(shù)據(jù)就緒”標(biāo)志位另一個核讀標(biāo)志位再讀數(shù)據(jù)。如果中間沒有屏障后者很可能看到標(biāo)志位置位了但數(shù)據(jù)還是舊的。多核同步還有一個樸素的陷阱直接靠volatile。volatile只告訴編譯器“這個變量會變別優(yōu)化掉”它不產(chǎn)生任何硬件屏障。很多人把volatile和“線程安全”畫等號這在ARM多核上完全是幻覺。正確做法是用鎖自旋鎖、互斥鎖、原子操作、關(guān)中斷或內(nèi)存屏障。像“通用神經(jīng)網(wǎng)絡(luò)處理器下的多核調(diào)度”這種重負(fù)載場景多核之間要頻繁搬運特征圖、權(quán)重如果內(nèi)存屏障和緩存同步搞不明白性能會因為偽共享和一致性開銷直線下滑而不是因為算力不夠。2.4 預(yù)處理器符號同一份源碼如何優(yōu)雅兼容各種ARM目標(biāo)寫跨平臺ARM代碼時預(yù)處理器符號是很實用的工具。編譯器會在預(yù)處理階段自動定義一批宏用來標(biāo)記當(dāng)前編譯目標(biāo)是什么架構(gòu)、什么編譯器、什么字節(jié)序。比如用GCC編譯32位ARM時編譯器通常會定義__arm__編譯64位ARM時GCC會定義__aarch64__。Keil MDK里的ARM Compiler 5會定義__CC_ARMARM Compiler 6armclang同樣會定義__ARMCC_VERSION但行為更多時候跟Clang兼容。這些宏可以讓你在源碼里寫這樣的分支#if defined(__aarch64__) /* 64位ARM專用路徑 */ uint64_t reg 0; #elif defined(__arm__) /* 32位ARM路徑 */ uint32_t reg 0; #elif defined(__x86_64__) /* x86_64路徑 */ uint64_t reg 0; #else #error Unknown architecture #endif實際項目里這種分支最常見的用途是處理系統(tǒng)寄存器不同的地址對齊方式、選擇不同的內(nèi)聯(lián)匯編片段、定義不同的數(shù)據(jù)類型寬度。另外一個我常用的排查手段是讓編譯器把預(yù)定義宏全打印出來。GCC可以用arm-none-eabi-gcc -dM -E - /dev/null | sortKeil/ARM Compiler 5也類似。你可以先跑一遍看看目標(biāo)平臺到底定義了哪些符號再根據(jù)這些符號來設(shè)計代碼分支。這比在網(wǎng)上到處查“這個宏在哪定義”要靠譜得多。不過我也提醒一句預(yù)處理器符號不要濫用。一個文件里如果塞滿了幾十層#if defined后期維護(hù)就是噩夢。更好的做法是在Makefile/CMake里統(tǒng)一定義平臺宏把差異封裝到少數(shù)幾個平臺抽象文件里而不是把整個業(yè)務(wù)代碼寫得跟迷彩服似的。3. ARM編程環(huán)境的搭建工具鏈、編譯器與系統(tǒng)鏡像的選型3.1 交叉編譯工具鏈裸機(jī)與Linux環(huán)境怎么選寫ARM程序幾乎不可能只用本機(jī)編譯器因為你平時工作的電腦大多還是x86平臺。所謂交叉編譯就是在x86主機(jī)上運行一個面向ARM目標(biāo)的編譯器生成ARM能執(zhí)行的機(jī)器碼。選工具鏈時第一件事是要區(qū)分“裸機(jī)”還是“帶系統(tǒng)”。如果你在寫STM32這類Cortex-M裸機(jī)程序或者是RTOS但不需要Linux內(nèi)核那么最常見的選擇是arm-none-eabi-gcc。這個工具鏈里的“none”表示沒有宿主操作系統(tǒng)它編譯出來的代碼不知道什么是Linux系統(tǒng)調(diào)用。C庫默認(rèn)是newlib一個為嵌入式設(shè)計的輕量C庫。很多人問“arm-none-eabi工具鏈默認(rèn)用newlibc嗎”答案就是是的默認(rèn)配套的就是newlib。如果你做的是基于ARM Linux的應(yīng)用開發(fā)比如在樹莓派、瑞芯微開發(fā)板上跑Ubuntu/CentOS那需要的是arm-linux-gnueabihf-gcc32位ARM Linux帶硬浮點或者aarch64-linux-gnu-gcc64位ARM Linux。這類工具鏈編譯的程序依賴目標(biāo)板的Linux內(nèi)核和glibc動態(tài)庫不能像裸機(jī)程序一樣脫離操作系統(tǒng)運行。我用一個表把常見工具鏈整理一下省得你每次都要上網(wǎng)查工具鏈適用目標(biāo)典型場景arm-none-eabi-gccCortex-M/R裸機(jī)STM32、GD32、瑞薩RAarm-none-linux-gnueabihf-gcc32位ARM Linux老款手機(jī)、ARMv7開發(fā)板aarch64-linux-gnu-gcc64位ARM LinuxRK3588、樹莓派4B/5、鯤鵬服務(wù)器ARM Compiler 5/6Cortex-M/R/A裸機(jī)RTOSKeil MDK內(nèi)置clang --targetaarch64...任意ARM目標(biāo)需要LLVM特性的場景裝工具鏈的時候建議優(yōu)先從官方源安裝。Debian/Ubuntu可以用apt install gcc-arm-none-eabi或apt install gcc-aarch64-linux-gnuCentOS用dnf也能裝。如果公司內(nèi)網(wǎng)沒法聯(lián)網(wǎng)那就提前下載離線包找一個可靠的離線ARM GNU工具鏈網(wǎng)址存好之后放到內(nèi)網(wǎng)倉庫里。我吃過“國內(nèi)網(wǎng)絡(luò)下載速度感人、最后發(fā)現(xiàn)下到的是Windows版還是沒帶gdb”的虧所以現(xiàn)在都會順手驗證一下工具鏈的自帶調(diào)試器是否和編譯器版本匹配。3.2 ARM Compiler 5.06與AC6的切換老工程最折騰的一關(guān)在Keil MDK里用Cortex-M系列做開發(fā)的人必然繞不開ARM Compiler。**ARM Compiler 5也叫AC5**是經(jīng)典編譯器很多老工程的啟動代碼、標(biāo)準(zhǔn)庫配置都基于它。**ARM Compiler 6AC6**從5.0版本之后逐漸成為MDK的默認(rèn)編譯器底層是Clang/LLVM編譯速度更快、對C11/C14的支持更好、靜態(tài)檢查也更嚴(yán)格。但切換編譯器不是點個下拉框就完事。AC5和AC6在語言標(biāo)準(zhǔn)和關(guān)鍵字上有很多不兼容。比如AC5支持__packed這樣的結(jié)構(gòu)體緊湊排列關(guān)鍵字而AC6里你更應(yīng)該說__attribute__((packed))AC5的__forceinline用法和AC6也不完全一致armclang對未定義行為、隱式聲明的報錯更敏感老代碼經(jīng)常一堆警告。網(wǎng)上現(xiàn)在還能下到**ARM Compiler 5.06 update 7build 960**這種特定版本為什么大家還在找老版本因為很多芯片廠商從ST、NXP提供的驅(qū)動庫和中間件是在AC5年代寫的沒有充分把關(guān)鍵字改成AC6兼容寫法。直接拿AC6編譯報錯鋪天蓋地。我建議的遷移路線是先不要一口氣切AC6而是把工程關(guān)掉警告升級讓編譯輸出先降到零錯誤再慢慢清理零警告。也可以設(shè)置AC5和AC6并存Keil允許在Options里指定Compiler版本。平時用AC6開發(fā)新代碼遇到老庫編譯不過再臨時切回AC5驗證。等代碼全部改造完再徹底清理。另外很多“找不到編譯器和啟動文件”的問題不是代碼問題是安裝包的問題。單獨下載ARM Compiler離線包時注意版本要和MDK當(dāng)前版本匹配。5.06 update7和6.16是兩支不同的安裝包不能互相頂替。裝好之后在Keil里點擊“Manage Project Items”的Folders/Extensions查看編譯器是否被正確識別。3.3 ARM版系統(tǒng)鏡像與運行時CentOS/Debian/JDK11如果你的目標(biāo)是ARM服務(wù)器、開發(fā)板、或者國產(chǎn)ARM筆記本那就需要對應(yīng)的ARM版系統(tǒng)鏡像。以服務(wù)器為例ARM服務(wù)器如華為鯤鵬、Ampere Altra上用的CentOS/Ubuntu/Debian都有專門的aarch64版本。CentOS Stream和Rocky Linux都提供了ARM版ISOUbuntu則有Server for ARM64。下載鏡像的時候一定要認(rèn)準(zhǔn)鏡像名里的arm64或aarch64字樣千萬別和圖省事拿x86_64鏡像硬裝。這些鏡像不光是架構(gòu)不同引導(dǎo)方式、內(nèi)核內(nèi)核模塊、軟件包源都不通用。裝好系統(tǒng)之后Java開發(fā)者會面臨一個老問題JDK裝哪個版本Oracle官方和OpenJDK都提供了ARM64版本像JDK11 ARM版就是linux-aarch64后綴的tar.gz包。解壓后配置JAVA_HOME和x86機(jī)器上幾乎沒有區(qū)別。之后ARM機(jī)器上跑JAR包無非就是java -jar app.jar但有一點要注意JVM默認(rèn)的GC策略和內(nèi)存分配可能在不同架構(gòu)上有差異跑大流量服務(wù)時最好先壓測再上線別想當(dāng)然套Intel集群的JVM參數(shù)。還有一類人會找ARM版WinPE工具。做系統(tǒng)維護(hù)時大家習(xí)慣用WinPEWindows預(yù)安裝環(huán)境而ARM版WinPE可以在ARM架構(gòu)的Windows設(shè)備上用。它的思路和在x86上做PE盤差不多但需要匹配UEFI啟動方式、顯示驅(qū)動和網(wǎng)絡(luò)驅(qū)動。我自己維護(hù)過一個ARM Windows平板最折騰的就是PE里缺觸屏驅(qū)動最后只能外接鍵鼠。如果你打算做ARM WinPE建議提前把目標(biāo)設(shè)備的驅(qū)動包塞進(jìn)去否則進(jìn)PE之后根本沒法操作。3.4 沒有開發(fā)板也能先跑起來QEMU/Limbo模擬ARM環(huán)境有時候你手頭還沒拿到硬件但代碼必須先動起來怎么辦答案是模擬器。QEMU是對ARM支持最完善的開源模擬器既能完整模擬一個ARM SoC也能用用戶態(tài)模擬直接跑單個ARM程序。你甚至可以下載別人打包好的ARM Debian鏡像比如常見的debian_arm.img或qcow2格式然后用QEMU或基于QEMU封裝的圖形化工具加載。我用過的Limbo就是這樣一個圖形化封裝方案它原本主要是給x86平臺虛擬機(jī)用的但也能把ARM Debian鏡像跑起來。實際路徑是下載debian arm鏡像的img/qcow2文件新建虛擬機(jī)時指定架構(gòu)為ARM再掛載鏡像。比較關(guān)鍵的是網(wǎng)絡(luò)配置默認(rèn)橋接網(wǎng)卡可能不通要在XML里加virtio-net-pci和用戶網(wǎng)絡(luò)模式。啟動之后你可以SSH進(jìn)系統(tǒng)裝toolchain、跑編譯、甚至做簡單的服務(wù)端測試。配合QEMU做交叉編譯驗證常用的工作流是# 在x86主機(jī)上安裝QEMU sudo apt install qemu-system-arm qemu-user # 用用戶態(tài)模擬直接跑ARM版可執(zhí)行文件前提是內(nèi)核和庫匹配 qemu-aarch64 -L /usr/aarch64-linux-gnu ./hello_arm這套方案的優(yōu)點是沒有硬件門檻、調(diào)試指令方便、快照功能好用缺點是模擬速度和真實硬件差距很大中斷、Cache行為都不真實。所以模擬器適合驗證邏輯和Linux應(yīng)用層代碼不適合用來調(diào)外設(shè)時序、驅(qū)動和實時性要求高的裸機(jī)代碼。4. 從啟動到多核調(diào)度ARM程序運行全鏈路實操4.1 鏈接腳本和啟動文件知道程序被放到哪里才能裝系統(tǒng)很多人寫ARM程序時點一下編譯按鈕下載到板子跑通了就完事。但一旦出現(xiàn)“下載成功卻跑不起來”的情況大多數(shù)人就懵了。這時候最需要的是回頭看看鏈接腳本和啟動文件。鏈接腳本.ld文件或Keil里的分散加載文件決定了程序每個section被放到什么地址。以STM32F103為例它的Flash從0x08000000開始RAM從0x20000000開始。鏈接腳本里就要把.text代碼段、.rodata只讀數(shù)據(jù)放到Flash把.data初始化的全局變量放在RAM的地址同時記錄它的加載地址方便啟動代碼在C語言運行前把初始值從Flash拷貝到RAM。Keil工程里對應(yīng)的是分散加載描述sct文件雖然默認(rèn)模板通常不用改但一旦你要用外部SDRAM、做Bootloader、或者做OTA升級分散加載文件必然會成為兵家必爭之地。我做過一個BootloaderApp的雙區(qū)方案為了把App入口固定在0x08010000折騰了一整個下午最后發(fā)現(xiàn)只是鏈接腳本里的FLASH起始地址沒改App的向量表跟Bootloader重疊了。啟動文件里最重要的一段就是Reset_Handler。Cortex-M芯片上電后硬件從向量表里取出初始SP和復(fù)位向量跳轉(zhuǎn)到Reset_Handler。在這個函數(shù)里你要先設(shè)置系統(tǒng)時鐘然后慢慢地把手動拷貝data段、清零bss段這些臟活干完再跳轉(zhuǎn)到__mainKeil工程或者main。4.2 復(fù)位上電后究竟發(fā)生了什么四步到main的老路我想用四步法把ARM上電到main的過程說清楚這個理解了后面排查死機(jī)問題會非常有底氣。第一步取向量表中的SP和PC并跳轉(zhuǎn)。無論是Cortex-M還是Cortex-ACPU上電后都有一條固定的取指路徑。Cortex-M會把地址0處的32位值作為初始棧指針把地址4處的32位值作為復(fù)位函數(shù)地址然后跳過去。Cortex-A則通常由BootROM配合外部啟動介質(zhì)完成早期引導(dǎo)。第二步初始化C運行環(huán)境。這是啟動代碼的核心工作。先把.data段從Flash的加載地址拷貝到RAM的運行地址再把.bss段清零。如果處理器有浮點單元還要開啟FPU并處理浮點寄存器的上下文保存。Cortex-M上還會順便設(shè)置好Systick、中斷向量表的位置等。第三步調(diào)用系統(tǒng)初始化函數(shù)。很多廠商庫在這里安排了一個SystemInit作用是把時鐘樹初始化到期望頻率比如PLL倍頻到72MHz或400MHz。這一步別省略否則后面串口波特率、CAN波特率、定時器周期全部會算錯。第四步跳轉(zhuǎn)main并用起來。main函數(shù)收到控制權(quán)之后你又回到了熟悉的C世界。但從這一刻起系統(tǒng)的所有寄存器、內(nèi)存、外設(shè)狀態(tài)都是啟動代碼鋪好的路。這四步看起來簡單但每一處細(xì)節(jié)都能藏雷。我遇到最常見的問題是“為什么我在main里做一個延時180ms的操作跑起來卻比預(yù)期時間短很多”十有八九是時鐘樹沒有配置內(nèi)核還在用內(nèi)部默認(rèn)的8MHz低速時鐘跑。你寫的延時函數(shù)是按72MHz算的參數(shù)實際硬件在8MHz下自然快得離譜。4.3 RTX5任務(wù)調(diào)度與SMP/AMP多核設(shè)計初探單核裸機(jī)寫順手之后遲早會碰RTOS和任務(wù)調(diào)度。Keil MDK配套的CMSIS-RTOS v2 RTX5是個很適合入門的調(diào)試對象它代碼開源、配置靈活、和ARM架構(gòu)深度綁定。RTX5默認(rèn)是搶占式調(diào)度加時間片輪轉(zhuǎn)。創(chuàng)建一個簡單任務(wù)很直接#include cmsis_os2.h static void thread_led(void *arg) { while (1) { HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin); osDelay(500); } } int main(void) { osKernelInitialize(); osThreadNew(thread_led, NULL, NULL); osKernelStart(); return 0; }這里面真正需要理解的是osDelay(500)會讓當(dāng)前任務(wù)主動讓出CPU把控制權(quán)交回調(diào)度器而搶占式調(diào)度則意味著更高優(yōu)先級任務(wù)一旦就緒立刻就能打斷當(dāng)前任務(wù)。你在中斷里調(diào)用RTOS API時要特別小心有些API不能在中斷上下文里調(diào)用否則會觸發(fā)斷言或者死鎖。再往上走一步就是多核調(diào)度。ARM平臺有兩種典型的多核方式AMP非對稱多處理和SMP對稱多處理。AMP的思路是不同核跑不同程序、甚至不同操作系統(tǒng)核間用核間中斷和共享內(nèi)存通信。常見于異構(gòu)處理器比如一個Cortex-A核跑Linux做管理一個Cortex-M核跑RTOS做實時控制。SMP的思路則是所有核共享同一個內(nèi)核和同一套內(nèi)存視圖操作系統(tǒng)把任務(wù)均勻調(diào)度到各個核上。通用神經(jīng)網(wǎng)絡(luò)處理器的多核調(diào)度問題很多時候就屬于這種場景特征圖計算被切分成多個子任務(wù)分別扔到多個核上計算于是“負(fù)載均衡、緩存親和性、核間同步”就成了性能瓶頸。在RTX5上做多核工程要額外注意把中斷自動分配給指定核、明確共享內(nèi)存區(qū)的Cache一致性策略。別天真地以為RTOS上了多核就萬事大吉——多核真正帶來的復(fù)雜度是并行帶來的競態(tài)條件不是簡單的“多個核一起跑”。4.4 從CAN波特率計算看外設(shè)寄存器的配置套路很多人一提到ARM編程就想到寫寄存器但其實外設(shè)配置是有套路的。以CAN外設(shè)為例CAN波特率的計算在不同廠商芯片上略有差別但核心公式都大差不差。這里用比較常見的CAN位時間公式來說明。CAN總線的位時間由同步段、傳播段、相位緩沖段1BS1和相位緩沖段2BS2組成。假定外設(shè)時鐘頻率是APB1_CLK你要的目標(biāo)波特率是BaudRate則預(yù)分頻值BRP和CAN位時間之間的關(guān)系是BaudRate APB1_CLK / (BRP × (1 BS1 BS2))所以如果APB1_CLK是36MHz想要1Mbps假設(shè)BS18BS27那么BRP 36MHz / (1Mbps × (1 8 7)) 36 / 16 2.25這個結(jié)果不是整數(shù)說明參數(shù)組合不合適得調(diào)整BS1/BS2的配額讓整個除法結(jié)果是整數(shù)。這種湊參數(shù)的過程本質(zhì)上和C2000 DSP比如28379D里的CAN模塊設(shè)置W、預(yù)分頻值是一個思想先確立時間量子再把采樣點放在合適的位置。配置外設(shè)寄存器還有個通用原則先關(guān)外設(shè)、再改配置、配置完重新初始化不要在運行中直接改關(guān)鍵位。很多“偶發(fā)錯誤”都是因為外設(shè)還在工作時你直接往配置寄存器寫了新值導(dǎo)致內(nèi)部狀態(tài)機(jī)錯亂。我在排查一個詭異的CAN通信偶發(fā)丟幀問題時最后發(fā)現(xiàn)就是某段代碼里頻繁對過濾器寄存器做熱更新沒有先進(jìn)入初始化模式觸發(fā)了芯片勘誤表里描述的一個工作模式切換缺陷。5. ARM調(diào)試排障我踩過的坑和排查清單5.1 上電死機(jī)先查向量表、鏈接腳本和啟動文件這類問題在基于Cortex-M的項目中尤其多。程序下載進(jìn)去了用調(diào)試器看PC指針跑到0xFFFFFFFE或某個莫名其妙的地方板子完全無反應(yīng)。我排障的第一步永遠(yuǎn)是去確認(rèn)向量表是否在正確地址。如果你用的是BootloaderApp結(jié)構(gòu)而App的向量表沒有重定位到App起始地址CPU一進(jìn)中斷就會去Bootloader的向量表里找服務(wù)函數(shù)然后跳到完全錯誤的地方。Cortex-M系列通常要做一次SCB-VTOR設(shè)置SCB-VTOR APP_FLASH_BASE;別小看這一行漏掉它的后果是全工程隨機(jī)死機(jī)。另外還要檢查鏈接腳本里RAM和ROM的起始地址、大小是否和芯片型號匹配。很多人直接從一個型號的模板復(fù)制工程改芯片型號后忘了改分散加載文件結(jié)果還是老的地址范圍直接把代碼燒到不存在的Flash上。第二個高頻原因是堆棧溢出。ARM的Cortex-M上電后先取向量表第一項作為初始SP如果初始SP設(shè)得比RAM實際大小還大或者啟動代碼把棧頂設(shè)置在有其他變量的位置那么第一次函數(shù)調(diào)用壓棧就可能踩內(nèi)存。調(diào)試器里看SP寄存器是否落在RAM有效范圍內(nèi)這個動作只要半秒鐘卻能省下好幾天的“玄學(xué)”。5.2 ABI不匹配GNU工具鏈和廠商編譯器混用的隱形殺手ARM生態(tài)里最讓人郁悶的問題之一是ABI不匹配。ABI應(yīng)用二進(jìn)制接口規(guī)定了函數(shù)參數(shù)怎么傳、返回值放哪個寄存器、棧對齊要求、結(jié)構(gòu)體怎么對齊等等。GNU工具鏈里常見的兩個變體是arm-none-eabi和arm-linux-gnueabihf前者常配合裸機(jī)后者是硬浮點環(huán)境。如果你把使用硬浮點ABI編譯的庫丟給軟浮點ABI的應(yīng)用程序去鏈接鏈接器可能不報錯但運行到函數(shù)調(diào)用時就異常崩潰。解決辦法是統(tǒng)一ABI要么全部用軟浮點-mfloat-abisoft要么全部用硬浮點-mfloat-abihard。在CMake里可用-mfloat-abihard -mfpufpv5-d16這種組合來強(qiáng)制。還有時候是不同編譯器的結(jié)構(gòu)體對齊差異導(dǎo)致的結(jié)構(gòu)體內(nèi)存布局不一樣尤其是帶#pragma pack老寫法的代碼跨編譯器以后對齊規(guī)則極容易出問題。一個實用的排查技巧是在鏈接階段用readelf -A或者file命令查看可執(zhí)行文件的屬性。file hello.elf readelf -A hello.elf輸出里會有Tag_ABI_VFP_args、Tag_CPU_arch這些一眼就能看出當(dāng)前目標(biāo)用的是硬浮點還是軟浮點。兩個文件做對比很快能找到不一致的根源。5.3 浮點軟硬ABI與對齊/字節(jié)序問題浮點ABI之外另一個容易踩的坑是數(shù)據(jù)對齊。ARM指令集對未對齊訪問的態(tài)度比較嚴(yán)格Cortex-M3/M4支持一部分未對齊訪問但代價是性能下降Cortex-M0對未對齊訪問可能直接進(jìn)HardFault。比如你用一個uint8_t指針去讀一個32位變量或者把指針強(qiáng)轉(zhuǎn)成uint32_t*去訪問一個奇數(shù)地址編譯器可以編譯通過運行時就是異常。這是因為ARM處理器的LDR/STR指令要求地址按數(shù)據(jù)寬度對齊很多情況下硬件不支持代勞。字節(jié)序問題也很典型?，F(xiàn)在絕大多數(shù)ARM SoC默認(rèn)小端但很多網(wǎng)絡(luò)協(xié)議字段是大端轉(zhuǎn)換時如果不注意抓包看到的數(shù)據(jù)就會“倒過來”。調(diào)試這種問題最快的方法是在內(nèi)存視圖里直接看原始字節(jié)順序然后和協(xié)議文檔里的字節(jié)序定義做對照。5.4 模擬器、鏡像與工具鏈下載的版本黑洞做系統(tǒng)鏡像和模擬器相關(guān)工作時最常見的排障流程是下載ARM版鏡像→啟動失敗→懷疑模擬器配置→懷疑鏡像損壞→重復(fù)下載。我整理一個自己的排查順序。先確認(rèn)鏡像架構(gòu)file命令在Windows下看不了太多但在Linux下可以直接識別鏡像里的CPU類型。再用QEMU的-machine參數(shù)匹配當(dāng)前鏡像支持的開發(fā)板型號。很多人啟動ARM Linux鏡像失敗就是因為機(jī)器類型選錯。然后確認(rèn)磁盤格式和啟動方式raw和qcow2是兩種不同的磁盤格式可以在QEMU里互相轉(zhuǎn)換但啟動參數(shù)不一樣。如果你下載的是debian_arm.img這種原始鏡像通常用-drive formatraw如果是qcow2那就把format改成qcow2或者干脆讓QEMU自動檢測。工具鏈下載也一樣會有“黑洞”辛辛苦苦從一個老網(wǎng)頁下載了5.06 update7裝完發(fā)現(xiàn)Keil版本不識別又或者下載了ARM Compiler 6.16目標(biāo)卻是老芯片編譯出來的鏡像不兼容。我的習(xí)慣是在工程N(yùn)VRAM里固定一份已驗證的工具鏈版本芯片SDK版本的組合清單新同事入組時直接照著清單裝別自己上網(wǎng)探索。5.5 多核調(diào)度與中斷優(yōu)先級RTOS上最隱蔽的競態(tài)問題最后說一個我至今記憶猶新的翻車案例。當(dāng)時在做一個帶多個Cortex-A核的應(yīng)用處理器上的LinuxRTOS混合系統(tǒng)某個高優(yōu)先級中斷服務(wù)里任務(wù)A往共享隊列里寫數(shù)據(jù)另一個核上的任務(wù)B同時從隊列里讀數(shù)據(jù)。單核時代寫代碼時大家習(xí)慣在中斷里用關(guān)中斷來保護(hù)臨界區(qū)但多核上只關(guān)當(dāng)前核的中斷根本管不住其他核。這類問題排查手段一般是運行日志里找“某個核在持鎖狀態(tài)下被中斷打斷”的跡象。用硬件性能監(jiān)視器查看緩存一致性事件數(shù)量。在關(guān)鍵的共享結(jié)構(gòu)體前后加__align(64)看偽共享現(xiàn)象是否減少。最讓我感慨的是這個bug連續(xù)出現(xiàn)了三天都是偶發(fā)性的完全復(fù)現(xiàn)不出來。最后我靜下心把共享隊列的讀寫操作加上自旋鎖和必要的屏障指令再把優(yōu)先級反轉(zhuǎn)的問題用優(yōu)先級繼承協(xié)議解決掉才徹底讓系統(tǒng)穩(wěn)定下來。如果你也在做多核RTOS我的建議是一開始就把鎖、原子操作、內(nèi)存屏障當(dāng)成一等公民而不是等出了問題再加。單核時代寫“無鎖代碼”可能靠運氣過關(guān)多核時代運氣不會一直站在你這邊。