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