與Cortex內(nèi)核：從指令集到嵌入式開發(fā)實(shí)戰(zhàn))
1. 先說清楚ARM 到底是什么做嵌入式開發(fā)、搞系統(tǒng)移植、甚至只是面試聊技術(shù)方案總繞不開 ARM 這個(gè)詞。但很多剛?cè)胄械呐笥讶菀装?ARM、Cortex、內(nèi)核架構(gòu)這幾個(gè)概念攪在一起一開口就是“我用的 STM32 是 ARM 內(nèi)核”嚴(yán)謹(jǐn)來說這個(gè)說法不算全對但也不算全錯問題就出在層級沒分清楚。ARM 其實(shí)是一家公司但它不生產(chǎn)芯片只做兩件事設(shè)計(jì)指令集架構(gòu)和處理器內(nèi)核然后以 IP 授權(quán)的形式賣給芯片廠商。你在市面上看到的 STM32、NXP i.MX、瑞薩 RA、樹莓派里的博通芯片核心都是買了 ARM 的授權(quán)再根據(jù)自己的應(yīng)用場景去集成外設(shè)、定制總線、堆內(nèi)存控制器最終封裝成一顆完整的 SoC。所以梳理一下關(guān)系就清晰了ARM 公司定義指令集架構(gòu)比如 ARMv7、ARMv8、ARMv9基于架構(gòu)開發(fā)出具體的內(nèi)核 IP比如 Cortex-M3、Cortex-A53芯片廠商買內(nèi)核授權(quán)后做成各種 MCU/MPU/SoC。這就是 ARM 生態(tài)最底層的運(yùn)行邏輯。你跑應(yīng)用的時(shí)候看到的“ARM 架構(gòu)”四個(gè)字往往指的是芯片是否兼容 ARM 的指令集比如跑 Ubuntu 的時(shí)候區(qū)分 arm64 鏡像指的就是這套指令體系。這篇文章從指令集架構(gòu)講到內(nèi)核設(shè)計(jì)再到 Cortex 家族的選型思路最后拆解實(shí)時(shí)安全機(jī)制的落地手段。搞懂這一條線后面看芯片手冊、做底層驅(qū)動、評估項(xiàng)目方案都會順暢很多。2. 架構(gòu)和內(nèi)核到底誰是誰的“上級”2.1 指令集架構(gòu)ISA是契約內(nèi)核是執(zhí)行者指令集架構(gòu)Instruction Set Architecture ISA是軟件和硬件之間的契約規(guī)定了 CPU 能識別哪些指令、寄存器怎么組織、內(nèi)存怎么訪問、異常怎么處理。可以把它理解成一本協(xié)議規(guī)范只要 CPU 遵守這本協(xié)議編譯好的程序就能在上面跑。ARM 這些年公開的 ISA 版本有 ARMv4、ARMv5、ARMv6、ARMv7、ARMv8、ARMv9 等。ARMv8 是一個(gè)重要分水嶺它引入了 AArch64 執(zhí)行狀態(tài)也就是我們常說的 64 位 ARM。在這之前ARMv7 及更早版本基本都是 32 位體系地址空間只有 4GB。到了 ARMv8CPU 既能跑 32 位舊指令A(yù)Arch32也能跑全新的 64 位指令A(yù)Arch64兼容性做得非常好這也是現(xiàn)在服務(wù)器和移動設(shè)備都能順利遷移到 64 位陣營的根本原因。內(nèi)核Core則是 ISA 的具體物理實(shí)現(xiàn)。同一份 ARMv8 架構(gòu)規(guī)范ARM 可以設(shè)計(jì)出性能取向的 Cortex-A76也可以設(shè)計(jì)出能效取向的 Cortex-A55。它們都能跑同樣的 64 位指令但是流水線深度、亂序執(zhí)行寬度、緩存大小、分支預(yù)測器設(shè)計(jì)完全不同。一個(gè)側(cè)重爆發(fā)性能一個(gè)側(cè)重省電跑同樣的算法耗時(shí)可能差好幾倍。這里就引出一個(gè)大家在選型時(shí)容易忽略的點(diǎn)光看“支持 ARMv8”還不夠還得看具體內(nèi)核型號因?yàn)榧軜?gòu)決定的是軟件兼容性內(nèi)核型號決定的是真實(shí)性能表現(xiàn)。你在招聘 JD 里經(jīng)?？吹健笆煜?ARM 架構(gòu)了解 Cortex-A 系列處理器”這種描述其實(shí)就是希望你既懂 ISA 層面的規(guī)則又懂具體內(nèi)核的設(shè)計(jì)取舍。2.2 從 ARMv7 到 ARMv9指令集演進(jìn)的關(guān)鍵節(jié)點(diǎn)ARMv7 時(shí)代最經(jīng)典的是 ARMv7-A應(yīng)用處理器和 ARMv7-M微控制器前者用 MMU支持跑 Linux 這種復(fù)雜操作系統(tǒng)后者用 MPU 或者干脆裸奔主打 Cortex-M 系列。很多老工程師對 ARMv7 的印象停留在“Cortex-A9 四核 1GB 內(nèi)存跑 Android 4.0”那個(gè)年代 ARM 在手機(jī) SoC 里已經(jīng)大殺四方但是服務(wù)器和企業(yè)級市場還沒打開局面。ARMv8 的 64 位擴(kuò)展解決了服務(wù)器的最大痛點(diǎn)——內(nèi)存尋址和吞吐量。AArch64 支持 64 位虛擬地址實(shí)際實(shí)現(xiàn)通常用 48 位物理地址也能突破 4GB 限制。配合新增的 AES 加密指令、CRC 指令以及更規(guī)范化的 NEON 向量指令A(yù)RM 開始從移動端向服務(wù)器、網(wǎng)絡(luò)設(shè)備、邊緣計(jì)算全面滲透?，F(xiàn)在你在云上租一臺 arm64 實(shí)例編譯 Redis、Nginx 這些熱門服務(wù)性能已經(jīng)很有競爭力。ARMv9 是最近這幾年的重點(diǎn)核心變化集中在機(jī)密計(jì)算CCA Confidential Compute Architecture、SVE2 向量指令集和更完善的安全隔離機(jī)制。SVE2 對多媒體編解碼、AI 推理這類向量密集型負(fù)載的提升非常明顯。不過 ARMv9 的 IP 目前主要出現(xiàn)在高端手機(jī) SoC 和數(shù)據(jù)中心芯片里工業(yè)控制和物聯(lián)網(wǎng)端的 Cortex-M 系列還是老架構(gòu)為主這個(gè)格局短期內(nèi)不會變。2.3 指令集、微架構(gòu)與芯片三層選型必須分開看很多項(xiàng)目失敗的根源就是選型的時(shí)候把三層混為一談。舉個(gè)實(shí)際例子你選了一顆基于 Cortex-A53 的工業(yè)級 SoC打算在上面跑 Linux 做視覺檢測結(jié)果發(fā)現(xiàn)單核性能完全扛不住推理負(fù)載。這里的問題不出在 ARMv8 架構(gòu)上也不出在 Cortex-A53 這個(gè)內(nèi)核上而是選型時(shí)就該用 Cortex-A72 甚至更高端的 A78 內(nèi)核。三層拆開之后邏輯就清晰了指令集架構(gòu)層決定軟件兼容性、工具鏈選擇、操作系統(tǒng)支持比如你的 Linux 發(fā)行版必須提供 arm64 版本內(nèi)核和用戶態(tài)軟件包。微架構(gòu)/內(nèi)核層決定流水線深度、IPC每時(shí)鐘周期執(zhí)行的指令數(shù)、緩存層級、功耗水平比如 Cortex-A55 和 Cortex-A76 同樣跑 2GHzIPC 差距可能在 30% 以上。SoC 集成層決定外設(shè)豐富度、總線帶寬、內(nèi)存控制器、電源管理、封裝尺寸比如同樣是 Cortex-M4 內(nèi)核ST 的 STM32F4 和 NXP 的 Kinetis K6x 在外設(shè)上完全不同底層驅(qū)動根本不通用。三層各管一攤選型的時(shí)候一層一層往下篩先定 ISA 和操作系統(tǒng)決定能否跑你的軟件棧再選內(nèi)核型號決定算力是否滿足最后看 SoC 廠商決定硬件外設(shè)是否匹配、量產(chǎn)供貨是否穩(wěn)定。3. Cortex 家族的“一分為三”A、R、M 的定位差異3.1 三兄弟各自負(fù)責(zé)什么場景Cortex 家族按應(yīng)用場景分成了三條產(chǎn)品線命名規(guī)則也很有講究A 代表 Application應(yīng)用R 代表 Real-time實(shí)時(shí)M 代表 Microcontroller微控制器。Cortex-A面向應(yīng)用處理器跑 Linux、Android、Windows 這類富操作系統(tǒng)主要出現(xiàn)在手機(jī)、平板、服務(wù)器、樹莓派這類設(shè)備里。Cortex-A 系列的特點(diǎn)是具備 MMU內(nèi)存管理單元能對虛擬地址做頁表映射每個(gè)進(jìn)程擁有獨(dú)立的地址空間這是現(xiàn)代操作系統(tǒng)的前提。代表型號有 A53、A72、A76、A78、A510、A710、X1、X2 等。Cortex-R面向?qū)崟r(shí)性要求極高的場景比如汽車制動系統(tǒng)、硬盤控制器、基帶信號處理、工業(yè)電機(jī)控制。R 系列沒有 MMU但有 MPU內(nèi)存保護(hù)單元中斷響應(yīng)延遲極低通常只有幾十納秒級別并且支持硬件鎖步Lock-Step雙核冗余兩個(gè)核執(zhí)行同樣的代碼輸出結(jié)果做實(shí)時(shí)比較一旦發(fā)現(xiàn)不一致立即報(bào)錯這是功能安全里常用的手段。Cortex-M面向微控制器市場主打低成本、低功耗、易開發(fā)。M 系列沒有 MMUMCU 里的 Flash 和 RAM 直接映射在統(tǒng)一地址空間里中斷延遲能做到 12 個(gè)時(shí)鐘周期以內(nèi)配合 CMSISCortex Microcontroller Software Interface Standard ARM 官方提供的軟件接口標(biāo)準(zhǔn)生態(tài)開發(fā)效率非常高。代表型號有 M0、M3、M4、M7、M33、M55、M85 等。三條線之間沒有絕對的性能好壞之分只有適不適合場景的區(qū)別。你把 Cortex-A76 拿去做電機(jī)控制殺雞用牛刀是一方面更麻煩的是沒有硬件實(shí)時(shí)響應(yīng)機(jī)制抖動一大電機(jī)就該嘯叫了。反過來你把 Cortex-M7 拿去做深度學(xué)習(xí)推理性能差到?jīng)]法看。3.2 M 系列的完整選型梯度M 系列的選擇可以做一個(gè)技術(shù)畫像方便上手就對號入座內(nèi)核架構(gòu)流水線關(guān)鍵特性典型場景Cortex-M0ARMv6-M2級面積最小、功耗最低、指令集精簡簡單傳感器、玩具、8位 MCU 升級替代Cortex-M0ARMv6-M2級比 M0 更省電增加分支預(yù)測低功耗 IoT 設(shè)備、可穿戴Cortex-M3ARMv7-M3級硬件除法、位帶操作、成熟生態(tài)工業(yè)控制、中端家電、電機(jī)驅(qū)動Cortex-M4ARMv7E-M3-5級帶 FPU 和 DSP 擴(kuò)展部分型號數(shù)字信號處理、音頻算法、電機(jī) FOCCortex-M7ARMv7E-M6級雙發(fā)射、指令/數(shù)據(jù)緩存、性能大幅提升圖形界面、嵌入式 AI、高性能控制Cortex-M33ARMv8-M3級TrustZone 安全隔離、協(xié)處理器接口安全支付、車規(guī) MCU、OTA 安全啟動Cortex-M55ARMv8.1-M4級Helium 向量擴(kuò)展類似 NEON端側(cè)輕量 AI、語音識別、異常檢測Cortex-M85ARMv8.1-M6級性能最高的 M 系列帶 Helium復(fù)雜電機(jī)控制、實(shí)時(shí)音頻處理、AI MCU從 M3 到 M4多出來的主要是 DSP 指令和單精度浮點(diǎn)單元這意味著在沒有外部 DSP 芯片的情況下M4 可以直接跑 PID 控制算法、FFT、FIR 濾波這些數(shù)學(xué)密集型任務(wù)。如果算法里大量使用三角函數(shù)、矩陣運(yùn)算M4 的 FPU 能把效率提升好幾倍代價(jià)是多花一兩塊錢的芯片成本。M7 的進(jìn)步則體現(xiàn)在更高的主頻和更寬的總線很多型號跑 400MHz 以上不成問題但隨之而來的是功耗增加、PCB 設(shè)計(jì)難度提升需要在電源完整性和信號完整性上多花心思。3.3 A 系列的性能解構(gòu)A 系列這邊型號數(shù)字大小和性能直接相關(guān)但不完全是線性關(guān)系。拿典型的移動芯片組合來舉例我們常說的 big.LITTLE 架構(gòu)就是大核配小核大核用 A76/A78/X 系列處理突發(fā)重負(fù)載小核用 A55/A510 處理后臺任務(wù)和低頻負(fù)載兩者通過互聯(lián)總線協(xié)同工作既保證流暢度又控制功耗。Cortex-A53 是 A 系列里的經(jīng)典能效之選ARMv8 架構(gòu)中最廣泛部署的內(nèi)核之一至今仍在大量入門級開發(fā)板和工業(yè)產(chǎn)品中使用。它采用順序雙發(fā)射流水線功耗表現(xiàn)極佳性能不算突出但在 28nm 工藝下做到 2GHz 左右也夠用。A72 和 A73 是上一代性能檔的主力目前依然活躍在中低端手機(jī)和平板方案里。A76 是一個(gè)重要里程碑它引入了更寬的解碼器和更強(qiáng)亂序執(zhí)行能力單核性能比 A75 提升了大約 35% 左右同時(shí)功耗控制在合理范圍內(nèi)。如果做邊緣計(jì)算網(wǎng)關(guān)或者嵌入式服務(wù)器A72 或 A76 起步是明智選擇如果做可穿戴或者輕量級 RTOS 設(shè)備A53 仍是最穩(wěn)妥的方案。A 系列里還有 X 系列超大核是 ARM 性能王冠上的明珠但消費(fèi)級產(chǎn)品里很少單獨(dú)用都是和 A 系列小核組成異構(gòu)多核集群。4. 手把手梳理一條 ARM 芯片從復(fù)位到跑系統(tǒng)4.1 復(fù)位向量、啟動模式與存儲映射很多做應(yīng)用層開發(fā)的工程師第一次接觸 ARM 底層開發(fā)最容易蒙的環(huán)節(jié)就是芯片上電之后到底執(zhí)行了什么。其實(shí)流程并不復(fù)雜但要先把幾個(gè)關(guān)鍵概念搞懂復(fù)位向量、啟動模式和存儲映射。ARM 內(nèi)核的復(fù)位向量地址取決于架構(gòu)。Cortex-M 系列固定從 0x00000000 取棧頂指針初始 SP從 0x00000004 取復(fù)位中斷向量初始 PC這是 ARMv6-M/ARMv7-M 的規(guī)定。而 Cortex-A 系列則從 0x00000000 開始取第一條指令但在實(shí)際 Linux 啟動中引導(dǎo)程序會先接管 CPU配置 DDR、初始化時(shí)鐘然后把內(nèi)核鏡像拷貝到內(nèi)存里跳轉(zhuǎn)執(zhí)行。啟動模式則是由芯片廠商通過 BOOT 引腳來配置的。以 NXP i.MX6ULL 為例它支持從 SD 卡、eMMC、NAND、NOR Flash、USB 下載等多種啟動介質(zhì)選擇。Boot ROM 里固化了一段出廠代碼以下簡稱 ROM 代碼上電后先執(zhí)行 ROM 代碼它負(fù)責(zé)初始化時(shí)鐘、檢測啟動引腳狀態(tài)、把用戶代碼從指定介質(zhì)搬運(yùn)到內(nèi)部 SRAM 或外部 DDR然后跳轉(zhuǎn)過去。嵌入式開發(fā)和 PC 開發(fā)最大的不同在于你的程序最終會被燒寫到 Flash 里掉電不丟失上電后由 CPU 自動加載。所以你在移植 U-Boot 時(shí)第一件事就是確認(rèn)開發(fā)板的啟動撥碼開關(guān)狀態(tài)和 U-Boot 鏡像燒錄位置是否匹配否則就會出現(xiàn)“程序燒進(jìn)去了但跑不起來”這種讓人血壓升高的問題。4.2 U-Boot、內(nèi)核與設(shè)備樹的三級跳以典型的 ARM64 Linux 啟動鏈來說整個(gè)過程分三級SoC 內(nèi)部 Boot ROM → 引導(dǎo)加載程序 U-Boot → Linux 內(nèi)核。U-Boot 是整個(gè)鏈路的中間人它的任務(wù)是初始化 DDR 控制器、串口、存儲介質(zhì)加載內(nèi)核鏡像和設(shè)備樹到內(nèi)存然后傳參跳轉(zhuǎn)。U-Boot 有兩個(gè)階段SPLSecondary Program Loader和主 U-Boot。SPL 放在片內(nèi) SRAM 里體積小負(fù)責(zé)最基礎(chǔ)的 DDR 初始化和把主 U-Boot 從 Flash/SD 卡加載到 DDR。主 U-Boot 才擁有完整功能支持文件系統(tǒng)、網(wǎng)絡(luò)、命令行交互。設(shè)備樹Device Tree是 ARM Linux 生態(tài)里非常關(guān)鍵的機(jī)制。因?yàn)?ARM 平臺碎片化嚴(yán)重同一份內(nèi)核要支持各種不同外設(shè)配置的板卡如果所有硬件信息都寫死在內(nèi)核源碼里內(nèi)核會膨脹到無法維護(hù)。設(shè)備樹用 DTSDevice Tree Source描述板級硬件細(xì)節(jié)比如 GPIO 哪個(gè)引腳接了 LED、I2C 總線上掛了哪個(gè)傳感器芯片、中斷號是幾。編譯成 DTBDevice Tree Blob后由 U-Boot 加載進(jìn)內(nèi)存再把地址傳給內(nèi)核。這套三級跳的好處是板子硬件變了只需要改 DTS 重新編譯 DTB不用動內(nèi)核本體。這也是為什么你下載一個(gè)主線內(nèi)核可以直接支持大量開發(fā)板刷不同板子的鏡像區(qū)別往往只在于附帶的不同 DTB 文件。4.3 中斷、異常與系統(tǒng)調(diào)用的處理鏈路操作系統(tǒng)的運(yùn)行離不開中斷機(jī)制。ARM 的異常模型包括復(fù)位、未定義指令、SVC超級調(diào)用、prefetch abort、data abort、IRQ、FIQ 等類型。處理器發(fā)現(xiàn)異常后會跳轉(zhuǎn)到異常向量表Vector Table對應(yīng)的入口地址保存當(dāng)前狀態(tài)切換到特權(quán)模式執(zhí)行異常處理程序處理完再恢復(fù)現(xiàn)場。Cortex-M 的中斷控制器叫 NVICNested Vectored Interrupt Controller 嵌套向量中斷控制器它支持中斷嵌套高優(yōu)先級中斷可以打斷低優(yōu)先級中斷而且每個(gè)中斷源都有自己的向量入口硬件自動壓棧和出棧軟件負(fù)擔(dān)很輕。Cortex-A 的中斷控制器叫 GICGeneric Interrupt Controller 通用中斷控制器結(jié)構(gòu)復(fù)雜不少支持 SPI共享外設(shè)中斷、PPI私有外設(shè)中斷、SGI軟件觸發(fā)中斷等多種類型是 Linux 內(nèi)核處理設(shè)備驅(qū)動的核心樞紐。實(shí)際開發(fā)中如果發(fā)現(xiàn)中斷響應(yīng)延遲異常高排查重點(diǎn)往往不在 CPU 本身而是檢查中斷服務(wù)函數(shù)里是不是寫了耗時(shí)操作比如 printf、延時(shí)、阻塞等待。正確的做法是在 ISR 里只做標(biāo)志位置位和數(shù)據(jù)拷貝真正復(fù)雜的數(shù)據(jù)處理丟到任務(wù)或內(nèi)核工作隊(duì)列里執(zhí)行。ARM 的中斷是硬件快速響應(yīng)的軟件拖后腿這件事在任何平臺上都一樣常見。5. 工具鏈與編譯器選型從 ARM Compiler 5 到交叉編譯環(huán)境5.1 ARM Compiler 5 為什么還這么多人用ARM Compiler 5AC5是 ARM 公司早些年主推的 C/C 編譯器配套 Keil MDK 使用在 Cortex-M 生態(tài)里地位很高。很多老項(xiàng)目、車規(guī)項(xiàng)目、固件庫至今仍鎖死在 AC5 環(huán)境下核心原因是 AC5 對 ARMCC 語法的兼容性做得最好CMSIS 庫版本對應(yīng)關(guān)系也成熟穩(wěn)定。AC5 的最后一個(gè)版本是 5.06 update 75.06u7也就是我們常說的 ARM Compiler 5.06u7。后來 ARM 推出了 AC6基于 LLVM 的 armclang編譯速度更快、C99/C11 標(biāo)準(zhǔn)支持更完整但 AC6 對代碼的檢查和優(yōu)化比 AC5 嚴(yán)格得多導(dǎo)致很多老代碼直接用 AC6 編譯時(shí) warning 刷屏或者直接編譯不過。這既不完全是 AC6 的錯也不是代碼質(zhì)量差更多是標(biāo)準(zhǔn)嚴(yán)格度提升帶來的遷移成本。如果項(xiàng)目沒有特殊的車規(guī)認(rèn)證需求我建議新項(xiàng)目直接上 AC6因?yàn)?AC6 生成的代碼質(zhì)量更高、官方長期維護(hù)、對 Cortex-M33/M55/M85 這些新內(nèi)核支持更好。如果必須維護(hù)老項(xiàng)目保留 AC5 環(huán)境也行但要注意 AC5 已經(jīng)停止功能更新固件庫和調(diào)試器插件的新版本可能適配不佳。5.2 交叉編譯環(huán)境的搭建與踩坑交叉編譯就是在一個(gè)架構(gòu)上編譯出另一個(gè)架構(gòu)上運(yùn)行的程序。比如你在 x86 的 Ubuntu 上編譯 ARM64 的 Linux 內(nèi)核就需要安裝交叉編譯工具鏈來替代本機(jī) gcc。最常見的工具鏈?zhǔn)?arm-linux-gnueabihf-gcc32 位 ARM帶硬浮點(diǎn)和 aarch64-linux-gnu-gcc64 位 ARM。用 apt 下面的命令就可以安裝但這里有一個(gè)特別容易踩的坑工具鏈的浮點(diǎn) ABIApplication Binary Interface必須和你目標(biāo)系統(tǒng)保持一致。如果你的用戶空間是硬浮點(diǎn)編譯的卻用了軟浮點(diǎn)工具鏈運(yùn)行時(shí)會出現(xiàn)無法解析的動態(tài)鏈接器錯誤非常隱蔽。交叉編譯環(huán)境搭建完成后還要確認(rèn) sysroot 是否正確。sysroot 是目標(biāo)系統(tǒng)根文件系統(tǒng)的鏡像路徑交叉編譯器在編譯時(shí)需要用 sysroot 里的頭文件和庫文件來鏈接。如果你沒有指定 sysroot編譯器會默認(rèn)尋找本機(jī) x86 的頭文件和庫結(jié)果就是你“交叉編譯”出來的程序仍然是 x86 的放到 ARM 板子上根本無法運(yùn)行。一個(gè)實(shí)用建議給交叉編譯環(huán)境寫一個(gè)獨(dú)立的腳本或者 Dockerfile把所有環(huán)境變量、工具鏈路徑、sysroot 路徑固化下來。我自己的習(xí)慣是每次新建嵌入式項(xiàng)目第一時(shí)間把工具鏈版本、編譯參數(shù)寫進(jìn) README免得三個(gè)月后自己都忘了環(huán)境怎么配的。5.3 ARM 生態(tài)里的服務(wù)器場景Redis、Node.js 等應(yīng)用的部署差異隨著 ARM 服務(wù)器如華為鯤鵬、AWS Graviton崛起ARM64 架構(gòu)在服務(wù)器端的應(yīng)用生態(tài)已經(jīng)非常完善。Redis、Nginx、MySQL、Java 等主流軟件都提供了官方 ARM64 版本。以 Redis 為例官方 Docker Hub 里直接有 redis:7-alpine 的 arm64v8 鏡像拉下來就能跑性能在 Graviton 實(shí)例上表現(xiàn)不輸 x86。我們團(tuán)隊(duì)之前把一套基于 Redis Cluster 的緩存服務(wù)從 x86 遷移到 ARM 服務(wù)器過程比預(yù)期順利原因很簡單ARM64 的 Linux 內(nèi)核和 GNU 工具鏈早已成熟Redis 本身是純 C 代碼編譯優(yōu)化差異不大。真正需要注意的反而是依賴鏈上的二進(jìn)制包比如舊版本數(shù)據(jù)庫驅(qū)動、某些閉源監(jiān)控 agent可能沒有提供 ARM64 版本需要先確認(rèn)所有依賴支持 ARM64 再動手遷移。Java 生態(tài)在 ARM 上的表現(xiàn)也很成熟OpenJDK 的 ARM64 版本由社區(qū)長期維護(hù)Spring Boot 應(yīng)用基本上可以無感遷移。最大的坑反而是一些老舊的 JNI 庫比如用到了 x86 編譯的 .so 動態(tài)庫拿到 ARM 上肯定不行需要重新編譯源碼或者尋找 ARM 替代品。6. 實(shí)時(shí)安全機(jī)制MPU、TrustZone 與功能安全6.1 MPU 做了什么事和 MMU 有什么本質(zhì)區(qū)別MMU內(nèi)存管理單元是現(xiàn)代操作系統(tǒng)運(yùn)行的基礎(chǔ)它負(fù)責(zé)虛擬地址到物理地址的轉(zhuǎn)換、頁表的維護(hù)、內(nèi)存訪問權(quán)限控制和緩存策略管理。有了 MMU每個(gè)進(jìn)程才能擁有獨(dú)立的地址空間一個(gè)進(jìn)程崩潰了不會把別的進(jìn)程的內(nèi)存數(shù)據(jù)踩壞。MPU內(nèi)存保護(hù)單元則完全不同它不做地址轉(zhuǎn)換只是給已有的物理地址空間設(shè)置訪問權(quán)限。Cortex-M 系列通常沒有 MMU只有 MPUMCU 里的 Flash、SRAM、外設(shè)寄存器都是直接尋址的物理地址。MPU 把地址空間劃分成若干個(gè)區(qū)域每個(gè)區(qū)域可以配置讀寫權(quán)限、執(zhí)行權(quán)限、緩存屬性一旦 CPU 訪問了違反權(quán)限設(shè)置的地址就會觸發(fā) MemManage Fault。聽起來有點(diǎn)像“簡化版 MMU”但設(shè)計(jì)初衷完全不同。MCU 里的軟件通常是單鏡像或者 RTOS 多任務(wù)并不需要虛擬地址映射MPU 的核心價(jià)值是防御防止野指針、棧溢出把關(guān)鍵數(shù)據(jù)區(qū)域踩壞防止普通任務(wù)訪問特權(quán)級外設(shè)寄存器從而實(shí)現(xiàn)軟件層面的故障隔離。我在做電機(jī)控制項(xiàng)目時(shí)會把控制算法的關(guān)鍵參數(shù)存放在受 MPU 保護(hù)的 SRAM 區(qū)域配置為只讀一旦發(fā)現(xiàn)程序異常寫入直接觸發(fā) HardFault 停機(jī)這樣至少能在現(xiàn)場快速暴露問題而不是讓異常數(shù)據(jù)在系統(tǒng)里悄悄擴(kuò)散。6.2 TrustZone 與 Armv8-M 的安全擴(kuò)展TrustZone 是 ARM 提出的系統(tǒng)級安全隔離技術(shù)在 Cortex-A 系列上早已廣泛應(yīng)用完成了從 ARMv7-A 到 ARMv8-A 的過渡。它的做法是把整個(gè)系統(tǒng)從硬件層面劃分成安全世界Secure World和非安全世界Normal World兩個(gè)世界擁有獨(dú)立的特權(quán)等級和內(nèi)存/外設(shè)訪問權(quán)限。普通操作系統(tǒng)運(yùn)行在非安全世界即使內(nèi)核完全被攻破攻擊者也無法訪問安全世界里的敏感數(shù)據(jù)。安全世界里跑的是一個(gè)精簡易用的安全內(nèi)核如 Trusted Firmware-A 或華為的 iTrustee、高通的 QSEE負(fù)責(zé)密鑰管理、安全啟動、指紋比對、支付令牌處理等操作。在 Cortex-M 上TrustZone 從 ARMv8-M 架構(gòu)開始引入M33/M55/M85 都支持這個(gè)特性。對于物聯(lián)網(wǎng)設(shè)備來說這是從芯片層面解決固件安全和數(shù)據(jù)安全的重要手段安全啟動可以阻止固件被篡改或替換安全存儲可以保護(hù)密鑰和證書不被普通應(yīng)用讀取安全調(diào)試可以在量產(chǎn)時(shí)關(guān)閉調(diào)試接口防止熔絲被讀出。實(shí)際項(xiàng)目中應(yīng)用 TrustZone 需要花不少精力因?yàn)榘踩澜绾头前踩澜缰g的通信要走專用的 SMCSecure Monitor Call指令或者 TrustZone 相關(guān)的 API驅(qū)動適配也比普通外設(shè)復(fù)雜。如果只是做一個(gè)消費(fèi)級小產(chǎn)品安全需求不高可以先不開 TrustZone但做車規(guī)、支付、隱私保護(hù)類產(chǎn)品這是必備能力。6.3 功能安全鎖步、ECC 與診斷覆蓋率功能安全Functional Safety是汽車、工業(yè)、醫(yī)療等領(lǐng)域繞不開的話題ARM 在這方面的布局相當(dāng)深入。Cortex-R 系列支持鎖步Lock-Step模式兩顆 CPU 核心同時(shí)執(zhí)行相同指令硬件比較器逐周期比對輸出一旦發(fā)現(xiàn)差異就觸發(fā)安全響應(yīng)比如切斷執(zhí)行器或進(jìn)入安全狀態(tài)。這種冗余設(shè)計(jì)的好處是不需要軟件額外參與硬件自動實(shí)現(xiàn)故障檢測但代價(jià)是算力只有單核可用因?yàn)閮蓚€(gè)核其實(shí)是在跑一份代碼。Cortex-M 在功能安全方面也有完備的支持比如 Cortex-M33 的安全版本可以配合 ARM 推出的 Safety Package提供診斷庫、安全手冊、FMEDA故障模式、影響和診斷分析報(bào)告幫助開發(fā)者快速完成 IEC 61508 或 ISO 26262 的認(rèn)證流程。ECCError Correcting Code 糾錯碼則負(fù)責(zé)保護(hù)內(nèi)存數(shù)據(jù)它能檢測并糾正單比特翻轉(zhuǎn)錯誤在內(nèi)存輻射環(huán)境或者長期運(yùn)行的設(shè)備里這是防止數(shù)據(jù)悄然變壞的重要手段。做功能安全項(xiàng)目千萬不要抱著“硬件能力到位就行了”的心態(tài)。真正難的是軟件層面的安全機(jī)制設(shè)計(jì)故障注入測試要做安全機(jī)制失效時(shí)的降級策略要寫診斷覆蓋率的計(jì)算要詳細(xì)記錄認(rèn)證評審時(shí)專家會逐條核對。ARM 給的安全手冊只是起點(diǎn)項(xiàng)目級的安全策略才是認(rèn)證能否通過的關(guān)鍵。6.4 實(shí)時(shí)性不只是中斷快任務(wù)調(diào)度和資源共享同樣關(guān)鍵很多人理解 ARM 的實(shí)時(shí)性第一反應(yīng)是中斷響應(yīng)延遲覺得“我的中斷 12 個(gè)周期就進(jìn)去了所以我是實(shí)時(shí)的”這是常見誤區(qū)。真正的實(shí)時(shí)性是一個(gè)系統(tǒng)工程中斷響應(yīng)只是其中一個(gè)環(huán)節(jié)。一個(gè)典型的實(shí)時(shí)系統(tǒng)比如汽車 ECU里跑著多個(gè)不同周期的任務(wù)10ms 的任務(wù)負(fù)責(zé)扭矩計(jì)算1ms 的任務(wù)負(fù)責(zé)電流環(huán)100ms 的任務(wù)負(fù)責(zé)通訊診斷。任務(wù)調(diào)度器需要在保證高優(yōu)先級任務(wù)準(zhǔn)時(shí)執(zhí)行的同時(shí)不讓低優(yōu)先級任務(wù)餓死還必須在任務(wù)間安全共享數(shù)據(jù)。這個(gè)過程中任務(wù)切換開銷、互斥鎖等待時(shí)間、Cache 抖動、總線訪問沖突都會影響實(shí)時(shí)性。ARM 在實(shí)時(shí)性方面提供了硬件支持NVIC 的嵌套中斷可以搶占正在執(zhí)行的低優(yōu)先級任務(wù)FPU 的自動保存寄存器狀態(tài)減少了中斷服務(wù)函數(shù)里的軟件保存開銷集成的 TCMTightly Coupled Memory 緊耦合內(nèi)存讓關(guān)鍵代碼和數(shù)據(jù)可以零等待訪問。但最終能不能滿足實(shí)時(shí)性要求還得看你的代碼設(shè)計(jì)中斷里有沒有關(guān)掉全局中斷太久任務(wù)是不是用了不可重入的函數(shù)通信協(xié)議棧有沒有在關(guān)鍵路徑上做了多余拷貝。做實(shí)時(shí)系統(tǒng)的一條基本經(jīng)驗(yàn)是先列出所有任務(wù)的時(shí)序要求周期、截止時(shí)間、最壞執(zhí)行時(shí)間畫出時(shí)間軸找出排列沖突點(diǎn)再考慮中斷優(yōu)先級和任務(wù)優(yōu)先級的配置。有些工程師一上來就調(diào)多重優(yōu)先級嵌套結(jié)果一個(gè)高優(yōu)先級中斷把 CPU 占死了其他所有任務(wù)全部餓死這就是典型的“硬件實(shí)時(shí)軟件不實(shí)時(shí)”。7. 實(shí)操中最常遇到的 6 個(gè) ARM 開發(fā)問題7.1 為什么燒錄提示 “No Cortex-M SW Device Found”這是一個(gè)出現(xiàn)頻率極高的調(diào)試錯誤幾乎每個(gè)用 ST-Link 或者 J-Link 調(diào) Cortex-M 芯片的人都遇到過。首先要理解這句話的含義調(diào)試器搜索不到 SWDSerial Wire Debug接口上的目標(biāo)設(shè)備也就是目標(biāo)芯片沒有響應(yīng)調(diào)試請求。常見原因有這些目標(biāo)板未上電或者供電不足SWDIO 和 SWCLK 兩根線接反或者虛焊目標(biāo)芯片開啟了讀保護(hù)導(dǎo)致調(diào)試接口被鎖定復(fù)位電路異常芯片一直處于復(fù)位狀態(tài)調(diào)試器固件版本過舊不兼容當(dāng)前內(nèi)核。排查思路是先用萬用表量芯片電源和 GND 是否正常再檢查 SWD 兩線是否連接到調(diào)試器的正確引腳然后用調(diào)試器的命令行工具嘗試連接并加上復(fù)位引腳控制最后如果確認(rèn)是讀保護(hù)就需要用芯片廠商的燒錄工具進(jìn)行全片擦除解鎖。這里分享一個(gè)經(jīng)驗(yàn)調(diào)試器與目標(biāo)板之間的連接線越短越好特別是 SWD 時(shí)鐘頻率較高時(shí)長線纜會造成信號反射影響時(shí)序。把線長控制在 10cm 以內(nèi)報(bào)錯概率大幅下降。如果不得不走長線就把 SWD 時(shí)鐘降下來比如從 4MHz 降到 1MHz問題往往迎刃而解。7.2 為什么 “Failed to download” 但偶爾又能連上調(diào)試器這個(gè)問題的隱蔽性比上面那個(gè)高不少。芯片偶爾能連上大多數(shù)情況下又報(bào)下載失敗典型原因是目標(biāo)芯片的調(diào)試接口連接不穩(wěn)定或者芯片內(nèi)部的調(diào)試組件工作狀態(tài)異常。比較常見的一種場景是你的程序里把 SWD 引腳復(fù)用成了 GPIO上電之后程序立刻執(zhí)行引腳重映射SWD 接口就被關(guān)閉了。此時(shí)調(diào)試器在芯片復(fù)位后的極短窗口內(nèi)還能連上但程序一旦跑起來調(diào)試通道就斷了所以出現(xiàn)“時(shí)好時(shí)壞”的詭異表現(xiàn)。解決辦法是把下載算法里的 Reset and Run 選項(xiàng)關(guān)掉讓程序下載完成后不要立即運(yùn)行保持芯片在復(fù)位狀態(tài)然后再嘗試連接或者按住復(fù)位鍵同時(shí)點(diǎn)擊下載時(shí)機(jī)掐準(zhǔn)也能成功。如果做的是低功耗產(chǎn)品還有另一種情況芯片進(jìn)入睡眠模式時(shí)調(diào)試時(shí)鐘被關(guān)閉調(diào)試器無法喚醒內(nèi)核。對策是在低功耗代碼里加一個(gè)編譯開關(guān)調(diào)試階段禁用睡眠模式量產(chǎn)版本再打開。7.3 程序在 RAM 里跑得好好的燒進(jìn) Flash 就死機(jī)這類問題在 Cortex-M 開發(fā)中非常典型。程序通過調(diào)試器直接加載到 RAM 運(yùn)行一切正常只要燒寫進(jìn) Flash復(fù)位后行為就完全不對。原因往往不是代碼邏輯的問題而是地址映射和啟動配置之間的錯位。最常見的坑是中斷向量表位置不對。Cortex-M 上電后默認(rèn)從 0x00000000 取棧頂指針從 0x00000004 取復(fù)位向量。如果你的程序鏈接到 Flash 地址比如 STM32F103 的 0x08000000但編譯時(shí)沒有把向量表放到 Flash 起始位置復(fù)位后 CPU 取出的棧指針和復(fù)位向量全是垃圾數(shù)據(jù)自然跑飛。解決方法是檢查鏈接腳本里向量表的放置地址確保和實(shí)際燒錄地址一致。另一個(gè)隱蔽原因是 Flash 等待周期配置不對。CPU 主頻比較高的時(shí)候Flash 的讀取速度跟不上需要配置 Flash 等待周期Flash Latency。這個(gè)寄存器配置錯誤后CPU 從 Flash 取指令偶爾會拿到錯誤數(shù)據(jù)表現(xiàn)為“隨機(jī)死機(jī)”。在啟動代碼里正確配置 Flash 等待周期和電源電壓范圍是基本功但很多人圖省事跳過了最后被坑得體無完膚。7.4 為什么 A 系列開發(fā)板啟動時(shí)卡在 “Starting kernel ...”Cortex-A 平臺啟動時(shí)報(bào)這個(gè)提示說明 U-Boot 運(yùn)行正常但在把控制權(quán)交給 Linux 內(nèi)核時(shí)出了問題。Linux 內(nèi)核根本沒跑起來掛在啟動早期階段。常見原因一個(gè)是設(shè)備樹里內(nèi)存節(jié)點(diǎn)配置錯誤內(nèi)核發(fā)現(xiàn)的內(nèi)存地址和 U-Boot 實(shí)際初始化 DDR 的地址對不上內(nèi)核訪問內(nèi)存直接掛掉。解決思路是打開內(nèi)核早期打印earlycon在 bootargs 里加上 consolettyAMA0,115200 這類參數(shù)以及 earlyprintk才能看到內(nèi)核早期輸出信息定位是在哪一步掛掉的。還有一個(gè)常見原因是內(nèi)核鏡像格式不匹配。U-Boot 需要 booti 命令來引導(dǎo) arm64 的 Image 格式內(nèi)核如果你用了 bootm 去引導(dǎo)舊式 uImage或者 Image 內(nèi)核沒被打包好跳轉(zhuǎn)后內(nèi)核代碼根本不可執(zhí)行。多確認(rèn) U-Boot 的 bootcmd 環(huán)境變量看看實(shí)際的啟動命令是否是 booti $kernel_addr_r - $fdt_addr_r這個(gè)細(xì)節(jié)能避免很多莫名其妙的問題。7.5 為什么交叉編譯出來的程序在 ARM 板上提示 “No such file or directory”這個(gè)問題看起來詭異文件明明存在但 shell 說找不到。實(shí)際原因和文件存在與否無關(guān)而是動態(tài)鏈接器路徑不對。交叉編譯時(shí)編譯器默認(rèn)把動態(tài)鏈接器的路徑寫在 ELF 文件的 INTERP 段里。比如在 x86 Ubuntu 上交叉編譯 ARM 程序默認(rèn)的鏈接器路徑可能是 /lib/ld-linux-armhf.so.3但你目標(biāo)板上的動態(tài)鏈接器在 /lib/ld-linux-armhf.so.3如果目標(biāo)板根文件系統(tǒng)里沒有這個(gè)文件內(nèi)核就沒法加載程序shell 就會誤報(bào)“文件不存在”。解決辦法有幾種第一種是交叉編譯時(shí)用 -Wl,--dynamic-linker/lib/ld-linux-armhf.so.3 手動指定正確的鏈接器路徑第二種是確保目標(biāo)板根文件系統(tǒng)里有對應(yīng)的動態(tài)鏈接器第三種更省心的方法是直接用目標(biāo)板上的原生編譯器編譯代碼但工程量大時(shí)往往不現(xiàn)實(shí)。還有一種情況是目標(biāo)板內(nèi)核缺少對 ELF 格式的支持比如某些精簡內(nèi)核沒開 CONFIG_BINFMT_ELF也能導(dǎo)致同樣的報(bào)錯不過這種場景相對少見一般先排查動態(tài)鏈接器路徑。7.6 ARM64 上跑 Docker 容器遇到 “exec format error”這個(gè)問題在 ARM 服務(wù)器剛開始普及時(shí)非常常見現(xiàn)在的云環(huán)境里依然會遇到。原因非常直白Docker 鏡像是按架構(gòu)發(fā)布的你在 x86 機(jī)器上構(gòu)建并 push 的鏡像是 amd64 架構(gòu)的拉到 ARM64 機(jī)器上運(yùn)行時(shí)容器里的可執(zhí)行文件是 x86 指令集ARM CPU 不識別底層就會報(bào) exec format error。解決辦法也簡單構(gòu)建鏡像是用 ARM 架構(gòu)的基礎(chǔ)鏡像重新構(gòu)建或者直接用 docker buildx 做多架構(gòu)構(gòu)建一次性產(chǎn)出 amd64 和 arm64 兩個(gè)平臺的鏡像然后在 ARM 機(jī)器上拉取對應(yīng)標(biāo)簽即可。如果項(xiàng)目里用的是第三方鏡像優(yōu)先選擇官方發(fā)布的 multi-arch 鏡像比如 redis、nginx 的官方鏡像都支持。這個(gè)問題的另一個(gè)隱藏坑是如果你用了 qemu 模擬器跑 x86 鏡像雖然能跑起來但性能損失大不說還可能出現(xiàn)各種兼容性問題。生產(chǎn)環(huán)境一定要用原生 ARM 架構(gòu)的鏡像就不要用模擬方案了。8. 從 ARM 生態(tài)看個(gè)人學(xué)習(xí)與項(xiàng)目落地路徑學(xué)了這么多概念和原理很多朋友最大的困惑是我該怎么從“知道”到“會用”。我的建議是從一條主線往下扎先選一塊 Cortex-M 開發(fā)板把裸機(jī)編程跑通理解啟動文件、中斷向量表、GPIO/UART/Timer 這些最基本的東西然后上 RTOS比如 FreeRTOS把任務(wù)調(diào)度、信號量、消息隊(duì)列搞明白再往后可以嘗試 Cortex-A 平臺用樹莓派或者香橙派之類的板子跑 Linux 驅(qū)動開發(fā)從寫一個(gè)簡單的字符設(shè)備驅(qū)動開始慢慢接觸設(shè)備樹、中斷、DMA、內(nèi)核模塊編譯。ARM 生態(tài)的獨(dú)特之處在于它是一個(gè)從底層到頂層貫通的技術(shù)棧指令集、內(nèi)核微架構(gòu)、SoC 集成、啟動鏈路、操作系統(tǒng)適配、應(yīng)用開發(fā)每一層都有海量崗位需求但每一層又并非完全割裂。搞底層的人如果懂一些應(yīng)用層邏輯寫驅(qū)動的時(shí)候會更清楚數(shù)據(jù)最終怎么被消費(fèi)搞應(yīng)用層的人如果理解指令集和內(nèi)存模型排查性能瓶頸時(shí)就不會停留在黑盒猜測。另一個(gè)建議是堅(jiān)持看 ARM 的官方文檔和芯片廠商的手冊而不是只刷網(wǎng)上的碎片化帖子。ARM Architecture Reference Manual 非常勸退但配合具體問題去查收益極高。芯片廠商的參考手冊比如 STM32 Reference Manual也是同類情況很多細(xì)節(jié)網(wǎng)上沒有中文權(quán)威解釋但手冊里一定寫得明明白白。在這個(gè)領(lǐng)域沉淀久了你會發(fā)現(xiàn) ARM 的生態(tài)邏輯其實(shí)很統(tǒng)一它用指令集劃分軟件世界用內(nèi)核劃分性能檔位用安全機(jī)制劃分可靠性等級再用高度可配置的 IP 授權(quán)模式讓每家芯片廠商都能在統(tǒng)一的生態(tài)里玩出自己的差異化。理解了這一層再去看任何一款 ARM 芯片都不過是同一套底層規(guī)則在不同的應(yīng)用場景下的具體投影。 ARM架構(gòu)與Cortex內(nèi)核：從指令集到嵌入式開發(fā)實(shí)戰(zhàn)
1. 先說清楚ARM 到底是什么做嵌入式開發(fā)、搞系統(tǒng)移植、甚至只是面試聊技術(shù)方案總繞不開 ARM 這個(gè)詞。但很多剛?cè)胄械呐笥讶菀装?ARM、Cortex、內(nèi)核架構(gòu)這幾個(gè)概念攪在一起一開口就是“我用的 STM32 是 ARM 內(nèi)核”嚴(yán)謹(jǐn)來說這個(gè)說法不算全對但也不算全錯問題就出在層級沒分清楚。ARM 其實(shí)是一家公司但它不生產(chǎn)芯片只做兩件事設(shè)計(jì)指令集架構(gòu)和處理器內(nèi)核然后以 IP 授權(quán)的形式賣給芯片廠商。你在市面上看到的 STM32、NXP i.MX、瑞薩 RA、樹莓派里的博通芯片核心都是買了 ARM 的授權(quán)再根據(jù)自己的應(yīng)用場景去集成外設(shè)、定制總線、堆內(nèi)存控制器最終封裝成一顆完整的 SoC。所以梳理一下關(guān)系就清晰了ARM 公司定義指令集架構(gòu)比如 ARMv7、ARMv8、ARMv9基于架構(gòu)開發(fā)出具體的內(nèi)核 IP比如 Cortex-M3、Cortex-A53芯片廠商買內(nèi)核授權(quán)后做成各種 MCU/MPU/SoC。這就是 ARM 生態(tài)最底層的運(yùn)行邏輯。你跑應(yīng)用的時(shí)候看到的“ARM 架構(gòu)”四個(gè)字往往指的是芯片是否兼容 ARM 的指令集比如跑 Ubuntu 的時(shí)候區(qū)分 arm64 鏡像指的就是這套指令體系。這篇文章從指令集架構(gòu)講到內(nèi)核設(shè)計(jì)再到 Cortex 家族的選型思路最后拆解實(shí)時(shí)安全機(jī)制的落地手段。搞懂這一條線后面看芯片手冊、做底層驅(qū)動、評估項(xiàng)目方案都會順暢很多。2. 架構(gòu)和內(nèi)核到底誰是誰的“上級”2.1 指令集架構(gòu)ISA是契約內(nèi)核是執(zhí)行者指令集架構(gòu)Instruction Set Architecture ISA是軟件和硬件之間的契約規(guī)定了 CPU 能識別哪些指令、寄存器怎么組織、內(nèi)存怎么訪問、異常怎么處理。可以把它理解成一本協(xié)議規(guī)范只要 CPU 遵守這本協(xié)議編譯好的程序就能在上面跑。ARM 這些年公開的 ISA 版本有 ARMv4、ARMv5、ARMv6、ARMv7、ARMv8、ARMv9 等。ARMv8 是一個(gè)重要分水嶺它引入了 AArch64 執(zhí)行狀態(tài)也就是我們常說的 64 位 ARM。在這之前ARMv7 及更早版本基本都是 32 位體系地址空間只有 4GB。到了 ARMv8CPU 既能跑 32 位舊指令A(yù)Arch32也能跑全新的 64 位指令A(yù)Arch64兼容性做得非常好這也是現(xiàn)在服務(wù)器和移動設(shè)備都能順利遷移到 64 位陣營的根本原因。內(nèi)核Core則是 ISA 的具體物理實(shí)現(xiàn)。同一份 ARMv8 架構(gòu)規(guī)范ARM 可以設(shè)計(jì)出性能取向的 Cortex-A76也可以設(shè)計(jì)出能效取向的 Cortex-A55。它們都能跑同樣的 64 位指令但是流水線深度、亂序執(zhí)行寬度、緩存大小、分支預(yù)測器設(shè)計(jì)完全不同。一個(gè)側(cè)重爆發(fā)性能一個(gè)側(cè)重省電跑同樣的算法耗時(shí)可能差好幾倍。這里就引出一個(gè)大家在選型時(shí)容易忽略的點(diǎn)光看“支持 ARMv8”還不夠還得看具體內(nèi)核型號因?yàn)榧軜?gòu)決定的是軟件兼容性內(nèi)核型號決定的是真實(shí)性能表現(xiàn)。你在招聘 JD 里經(jīng)?？吹健笆煜?ARM 架構(gòu)了解 Cortex-A 系列處理器”這種描述其實(shí)就是希望你既懂 ISA 層面的規(guī)則又懂具體內(nèi)核的設(shè)計(jì)取舍。2.2 從 ARMv7 到 ARMv9指令集演進(jìn)的關(guān)鍵節(jié)點(diǎn)ARMv7 時(shí)代最經(jīng)典的是 ARMv7-A應(yīng)用處理器和 ARMv7-M微控制器前者用 MMU支持跑 Linux 這種復(fù)雜操作系統(tǒng)后者用 MPU 或者干脆裸奔主打 Cortex-M 系列。很多老工程師對 ARMv7 的印象停留在“Cortex-A9 四核 1GB 內(nèi)存跑 Android 4.0”那個(gè)年代 ARM 在手機(jī) SoC 里已經(jīng)大殺四方但是服務(wù)器和企業(yè)級市場還沒打開局面。ARMv8 的 64 位擴(kuò)展解決了服務(wù)器的最大痛點(diǎn)——內(nèi)存尋址和吞吐量。AArch64 支持 64 位虛擬地址實(shí)際實(shí)現(xiàn)通常用 48 位物理地址也能突破 4GB 限制。配合新增的 AES 加密指令、CRC 指令以及更規(guī)范化的 NEON 向量指令A(yù)RM 開始從移動端向服務(wù)器、網(wǎng)絡(luò)設(shè)備、邊緣計(jì)算全面滲透?，F(xiàn)在你在云上租一臺 arm64 實(shí)例編譯 Redis、Nginx 這些熱門服務(wù)性能已經(jīng)很有競爭力。ARMv9 是最近這幾年的重點(diǎn)核心變化集中在機(jī)密計(jì)算CCA Confidential Compute Architecture、SVE2 向量指令集和更完善的安全隔離機(jī)制。SVE2 對多媒體編解碼、AI 推理這類向量密集型負(fù)載的提升非常明顯。不過 ARMv9 的 IP 目前主要出現(xiàn)在高端手機(jī) SoC 和數(shù)據(jù)中心芯片里工業(yè)控制和物聯(lián)網(wǎng)端的 Cortex-M 系列還是老架構(gòu)為主這個(gè)格局短期內(nèi)不會變。2.3 指令集、微架構(gòu)與芯片三層選型必須分開看很多項(xiàng)目失敗的根源就是選型的時(shí)候把三層混為一談。舉個(gè)實(shí)際例子你選了一顆基于 Cortex-A53 的工業(yè)級 SoC打算在上面跑 Linux 做視覺檢測結(jié)果發(fā)現(xiàn)單核性能完全扛不住推理負(fù)載。這里的問題不出在 ARMv8 架構(gòu)上也不出在 Cortex-A53 這個(gè)內(nèi)核上而是選型時(shí)就該用 Cortex-A72 甚至更高端的 A78 內(nèi)核。三層拆開之后邏輯就清晰了指令集架構(gòu)層決定軟件兼容性、工具鏈選擇、操作系統(tǒng)支持比如你的 Linux 發(fā)行版必須提供 arm64 版本內(nèi)核和用戶態(tài)軟件包。微架構(gòu)/內(nèi)核層決定流水線深度、IPC每時(shí)鐘周期執(zhí)行的指令數(shù)、緩存層級、功耗水平比如 Cortex-A55 和 Cortex-A76 同樣跑 2GHzIPC 差距可能在 30% 以上。SoC 集成層決定外設(shè)豐富度、總線帶寬、內(nèi)存控制器、電源管理、封裝尺寸比如同樣是 Cortex-M4 內(nèi)核ST 的 STM32F4 和 NXP 的 Kinetis K6x 在外設(shè)上完全不同底層驅(qū)動根本不通用。三層各管一攤選型的時(shí)候一層一層往下篩先定 ISA 和操作系統(tǒng)決定能否跑你的軟件棧再選內(nèi)核型號決定算力是否滿足最后看 SoC 廠商決定硬件外設(shè)是否匹配、量產(chǎn)供貨是否穩(wěn)定。3. Cortex 家族的“一分為三”A、R、M 的定位差異3.1 三兄弟各自負(fù)責(zé)什么場景Cortex 家族按應(yīng)用場景分成了三條產(chǎn)品線命名規(guī)則也很有講究A 代表 Application應(yīng)用R 代表 Real-time實(shí)時(shí)M 代表 Microcontroller微控制器。Cortex-A面向應(yīng)用處理器跑 Linux、Android、Windows 這類富操作系統(tǒng)主要出現(xiàn)在手機(jī)、平板、服務(wù)器、樹莓派這類設(shè)備里。Cortex-A 系列的特點(diǎn)是具備 MMU內(nèi)存管理單元能對虛擬地址做頁表映射每個(gè)進(jìn)程擁有獨(dú)立的地址空間這是現(xiàn)代操作系統(tǒng)的前提。代表型號有 A53、A72、A76、A78、A510、A710、X1、X2 等。Cortex-R面向?qū)崟r(shí)性要求極高的場景比如汽車制動系統(tǒng)、硬盤控制器、基帶信號處理、工業(yè)電機(jī)控制。R 系列沒有 MMU但有 MPU內(nèi)存保護(hù)單元中斷響應(yīng)延遲極低通常只有幾十納秒級別并且支持硬件鎖步Lock-Step雙核冗余兩個(gè)核執(zhí)行同樣的代碼輸出結(jié)果做實(shí)時(shí)比較一旦發(fā)現(xiàn)不一致立即報(bào)錯這是功能安全里常用的手段。Cortex-M面向微控制器市場主打低成本、低功耗、易開發(fā)。M 系列沒有 MMUMCU 里的 Flash 和 RAM 直接映射在統(tǒng)一地址空間里中斷延遲能做到 12 個(gè)時(shí)鐘周期以內(nèi)配合 CMSISCortex Microcontroller Software Interface Standard ARM 官方提供的軟件接口標(biāo)準(zhǔn)生態(tài)開發(fā)效率非常高。代表型號有 M0、M3、M4、M7、M33、M55、M85 等。三條線之間沒有絕對的性能好壞之分只有適不適合場景的區(qū)別。你把 Cortex-A76 拿去做電機(jī)控制殺雞用牛刀是一方面更麻煩的是沒有硬件實(shí)時(shí)響應(yīng)機(jī)制抖動一大電機(jī)就該嘯叫了。反過來你把 Cortex-M7 拿去做深度學(xué)習(xí)推理性能差到?jīng)]法看。3.2 M 系列的完整選型梯度M 系列的選擇可以做一個(gè)技術(shù)畫像方便上手就對號入座內(nèi)核架構(gòu)流水線關(guān)鍵特性典型場景Cortex-M0ARMv6-M2級面積最小、功耗最低、指令集精簡簡單傳感器、玩具、8位 MCU 升級替代Cortex-M0ARMv6-M2級比 M0 更省電增加分支預(yù)測低功耗 IoT 設(shè)備、可穿戴Cortex-M3ARMv7-M3級硬件除法、位帶操作、成熟生態(tài)工業(yè)控制、中端家電、電機(jī)驅(qū)動Cortex-M4ARMv7E-M3-5級帶 FPU 和 DSP 擴(kuò)展部分型號數(shù)字信號處理、音頻算法、電機(jī) FOCCortex-M7ARMv7E-M6級雙發(fā)射、指令/數(shù)據(jù)緩存、性能大幅提升圖形界面、嵌入式 AI、高性能控制Cortex-M33ARMv8-M3級TrustZone 安全隔離、協(xié)處理器接口安全支付、車規(guī) MCU、OTA 安全啟動Cortex-M55ARMv8.1-M4級Helium 向量擴(kuò)展類似 NEON端側(cè)輕量 AI、語音識別、異常檢測Cortex-M85ARMv8.1-M6級性能最高的 M 系列帶 Helium復(fù)雜電機(jī)控制、實(shí)時(shí)音頻處理、AI MCU從 M3 到 M4多出來的主要是 DSP 指令和單精度浮點(diǎn)單元這意味著在沒有外部 DSP 芯片的情況下M4 可以直接跑 PID 控制算法、FFT、FIR 濾波這些數(shù)學(xué)密集型任務(wù)。如果算法里大量使用三角函數(shù)、矩陣運(yùn)算M4 的 FPU 能把效率提升好幾倍代價(jià)是多花一兩塊錢的芯片成本。M7 的進(jìn)步則體現(xiàn)在更高的主頻和更寬的總線很多型號跑 400MHz 以上不成問題但隨之而來的是功耗增加、PCB 設(shè)計(jì)難度提升需要在電源完整性和信號完整性上多花心思。3.3 A 系列的性能解構(gòu)A 系列這邊型號數(shù)字大小和性能直接相關(guān)但不完全是線性關(guān)系。拿典型的移動芯片組合來舉例我們常說的 big.LITTLE 架構(gòu)就是大核配小核大核用 A76/A78/X 系列處理突發(fā)重負(fù)載小核用 A55/A510 處理后臺任務(wù)和低頻負(fù)載兩者通過互聯(lián)總線協(xié)同工作既保證流暢度又控制功耗。Cortex-A53 是 A 系列里的經(jīng)典能效之選ARMv8 架構(gòu)中最廣泛部署的內(nèi)核之一至今仍在大量入門級開發(fā)板和工業(yè)產(chǎn)品中使用。它采用順序雙發(fā)射流水線功耗表現(xiàn)極佳性能不算突出但在 28nm 工藝下做到 2GHz 左右也夠用。A72 和 A73 是上一代性能檔的主力目前依然活躍在中低端手機(jī)和平板方案里。A76 是一個(gè)重要里程碑它引入了更寬的解碼器和更強(qiáng)亂序執(zhí)行能力單核性能比 A75 提升了大約 35% 左右同時(shí)功耗控制在合理范圍內(nèi)。如果做邊緣計(jì)算網(wǎng)關(guān)或者嵌入式服務(wù)器A72 或 A76 起步是明智選擇如果做可穿戴或者輕量級 RTOS 設(shè)備A53 仍是最穩(wěn)妥的方案。A 系列里還有 X 系列超大核是 ARM 性能王冠上的明珠但消費(fèi)級產(chǎn)品里很少單獨(dú)用都是和 A 系列小核組成異構(gòu)多核集群。4. 手把手梳理一條 ARM 芯片從復(fù)位到跑系統(tǒng)4.1 復(fù)位向量、啟動模式與存儲映射很多做應(yīng)用層開發(fā)的工程師第一次接觸 ARM 底層開發(fā)最容易蒙的環(huán)節(jié)就是芯片上電之后到底執(zhí)行了什么。其實(shí)流程并不復(fù)雜但要先把幾個(gè)關(guān)鍵概念搞懂復(fù)位向量、啟動模式和存儲映射。ARM 內(nèi)核的復(fù)位向量地址取決于架構(gòu)。Cortex-M 系列固定從 0x00000000 取棧頂指針初始 SP從 0x00000004 取復(fù)位中斷向量初始 PC這是 ARMv6-M/ARMv7-M 的規(guī)定。而 Cortex-A 系列則從 0x00000000 開始取第一條指令但在實(shí)際 Linux 啟動中引導(dǎo)程序會先接管 CPU配置 DDR、初始化時(shí)鐘然后把內(nèi)核鏡像拷貝到內(nèi)存里跳轉(zhuǎn)執(zhí)行。啟動模式則是由芯片廠商通過 BOOT 引腳來配置的。以 NXP i.MX6ULL 為例它支持從 SD 卡、eMMC、NAND、NOR Flash、USB 下載等多種啟動介質(zhì)選擇。Boot ROM 里固化了一段出廠代碼以下簡稱 ROM 代碼上電后先執(zhí)行 ROM 代碼它負(fù)責(zé)初始化時(shí)鐘、檢測啟動引腳狀態(tài)、把用戶代碼從指定介質(zhì)搬運(yùn)到內(nèi)部 SRAM 或外部 DDR然后跳轉(zhuǎn)過去。嵌入式開發(fā)和 PC 開發(fā)最大的不同在于你的程序最終會被燒寫到 Flash 里掉電不丟失上電后由 CPU 自動加載。所以你在移植 U-Boot 時(shí)第一件事就是確認(rèn)開發(fā)板的啟動撥碼開關(guān)狀態(tài)和 U-Boot 鏡像燒錄位置是否匹配否則就會出現(xiàn)“程序燒進(jìn)去了但跑不起來”這種讓人血壓升高的問題。4.2 U-Boot、內(nèi)核與設(shè)備樹的三級跳以典型的 ARM64 Linux 啟動鏈來說整個(gè)過程分三級SoC 內(nèi)部 Boot ROM → 引導(dǎo)加載程序 U-Boot → Linux 內(nèi)核。U-Boot 是整個(gè)鏈路的中間人它的任務(wù)是初始化 DDR 控制器、串口、存儲介質(zhì)加載內(nèi)核鏡像和設(shè)備樹到內(nèi)存然后傳參跳轉(zhuǎn)。U-Boot 有兩個(gè)階段SPLSecondary Program Loader和主 U-Boot。SPL 放在片內(nèi) SRAM 里體積小負(fù)責(zé)最基礎(chǔ)的 DDR 初始化和把主 U-Boot 從 Flash/SD 卡加載到 DDR。主 U-Boot 才擁有完整功能支持文件系統(tǒng)、網(wǎng)絡(luò)、命令行交互。設(shè)備樹Device Tree是 ARM Linux 生態(tài)里非常關(guān)鍵的機(jī)制。因?yàn)?ARM 平臺碎片化嚴(yán)重同一份內(nèi)核要支持各種不同外設(shè)配置的板卡如果所有硬件信息都寫死在內(nèi)核源碼里內(nèi)核會膨脹到無法維護(hù)。設(shè)備樹用 DTSDevice Tree Source描述板級硬件細(xì)節(jié)比如 GPIO 哪個(gè)引腳接了 LED、I2C 總線上掛了哪個(gè)傳感器芯片、中斷號是幾。編譯成 DTBDevice Tree Blob后由 U-Boot 加載進(jìn)內(nèi)存再把地址傳給內(nèi)核。這套三級跳的好處是板子硬件變了只需要改 DTS 重新編譯 DTB不用動內(nèi)核本體。這也是為什么你下載一個(gè)主線內(nèi)核可以直接支持大量開發(fā)板刷不同板子的鏡像區(qū)別往往只在于附帶的不同 DTB 文件。4.3 中斷、異常與系統(tǒng)調(diào)用的處理鏈路操作系統(tǒng)的運(yùn)行離不開中斷機(jī)制。ARM 的異常模型包括復(fù)位、未定義指令、SVC超級調(diào)用、prefetch abort、data abort、IRQ、FIQ 等類型。處理器發(fā)現(xiàn)異常后會跳轉(zhuǎn)到異常向量表Vector Table對應(yīng)的入口地址保存當(dāng)前狀態(tài)切換到特權(quán)模式執(zhí)行異常處理程序處理完再恢復(fù)現(xiàn)場。Cortex-M 的中斷控制器叫 NVICNested Vectored Interrupt Controller 嵌套向量中斷控制器它支持中斷嵌套高優(yōu)先級中斷可以打斷低優(yōu)先級中斷而且每個(gè)中斷源都有自己的向量入口硬件自動壓棧和出棧軟件負(fù)擔(dān)很輕。Cortex-A 的中斷控制器叫 GICGeneric Interrupt Controller 通用中斷控制器結(jié)構(gòu)復(fù)雜不少支持 SPI共享外設(shè)中斷、PPI私有外設(shè)中斷、SGI軟件觸發(fā)中斷等多種類型是 Linux 內(nèi)核處理設(shè)備驅(qū)動的核心樞紐。實(shí)際開發(fā)中如果發(fā)現(xiàn)中斷響應(yīng)延遲異常高排查重點(diǎn)往往不在 CPU 本身而是檢查中斷服務(wù)函數(shù)里是不是寫了耗時(shí)操作比如 printf、延時(shí)、阻塞等待。正確的做法是在 ISR 里只做標(biāo)志位置位和數(shù)據(jù)拷貝真正復(fù)雜的數(shù)據(jù)處理丟到任務(wù)或內(nèi)核工作隊(duì)列里執(zhí)行。ARM 的中斷是硬件快速響應(yīng)的軟件拖后腿這件事在任何平臺上都一樣常見。5. 工具鏈與編譯器選型從 ARM Compiler 5 到交叉編譯環(huán)境5.1 ARM Compiler 5 為什么還這么多人用ARM Compiler 5AC5是 ARM 公司早些年主推的 C/C 編譯器配套 Keil MDK 使用在 Cortex-M 生態(tài)里地位很高。很多老項(xiàng)目、車規(guī)項(xiàng)目、固件庫至今仍鎖死在 AC5 環(huán)境下核心原因是 AC5 對 ARMCC 語法的兼容性做得最好CMSIS 庫版本對應(yīng)關(guān)系也成熟穩(wěn)定。AC5 的最后一個(gè)版本是 5.06 update 75.06u7也就是我們常說的 ARM Compiler 5.06u7。后來 ARM 推出了 AC6基于 LLVM 的 armclang編譯速度更快、C99/C11 標(biāo)準(zhǔn)支持更完整但 AC6 對代碼的檢查和優(yōu)化比 AC5 嚴(yán)格得多導(dǎo)致很多老代碼直接用 AC6 編譯時(shí) warning 刷屏或者直接編譯不過。這既不完全是 AC6 的錯也不是代碼質(zhì)量差更多是標(biāo)準(zhǔn)嚴(yán)格度提升帶來的遷移成本。如果項(xiàng)目沒有特殊的車規(guī)認(rèn)證需求我建議新項(xiàng)目直接上 AC6因?yàn)?AC6 生成的代碼質(zhì)量更高、官方長期維護(hù)、對 Cortex-M33/M55/M85 這些新內(nèi)核支持更好。如果必須維護(hù)老項(xiàng)目保留 AC5 環(huán)境也行但要注意 AC5 已經(jīng)停止功能更新固件庫和調(diào)試器插件的新版本可能適配不佳。5.2 交叉編譯環(huán)境的搭建與踩坑交叉編譯就是在一個(gè)架構(gòu)上編譯出另一個(gè)架構(gòu)上運(yùn)行的程序。比如你在 x86 的 Ubuntu 上編譯 ARM64 的 Linux 內(nèi)核就需要安裝交叉編譯工具鏈來替代本機(jī) gcc。最常見的工具鏈?zhǔn)?arm-linux-gnueabihf-gcc32 位 ARM帶硬浮點(diǎn)和 aarch64-linux-gnu-gcc64 位 ARM。用 apt 下面的命令就可以安裝但這里有一個(gè)特別容易踩的坑工具鏈的浮點(diǎn) ABIApplication Binary Interface必須和你目標(biāo)系統(tǒng)保持一致。如果你的用戶空間是硬浮點(diǎn)編譯的卻用了軟浮點(diǎn)工具鏈運(yùn)行時(shí)會出現(xiàn)無法解析的動態(tài)鏈接器錯誤非常隱蔽。交叉編譯環(huán)境搭建完成后還要確認(rèn) sysroot 是否正確。sysroot 是目標(biāo)系統(tǒng)根文件系統(tǒng)的鏡像路徑交叉編譯器在編譯時(shí)需要用 sysroot 里的頭文件和庫文件來鏈接。如果你沒有指定 sysroot編譯器會默認(rèn)尋找本機(jī) x86 的頭文件和庫結(jié)果就是你“交叉編譯”出來的程序仍然是 x86 的放到 ARM 板子上根本無法運(yùn)行。一個(gè)實(shí)用建議給交叉編譯環(huán)境寫一個(gè)獨(dú)立的腳本或者 Dockerfile把所有環(huán)境變量、工具鏈路徑、sysroot 路徑固化下來。我自己的習(xí)慣是每次新建嵌入式項(xiàng)目第一時(shí)間把工具鏈版本、編譯參數(shù)寫進(jìn) README免得三個(gè)月后自己都忘了環(huán)境怎么配的。5.3 ARM 生態(tài)里的服務(wù)器場景Redis、Node.js 等應(yīng)用的部署差異隨著 ARM 服務(wù)器如華為鯤鵬、AWS Graviton崛起ARM64 架構(gòu)在服務(wù)器端的應(yīng)用生態(tài)已經(jīng)非常完善。Redis、Nginx、MySQL、Java 等主流軟件都提供了官方 ARM64 版本。以 Redis 為例官方 Docker Hub 里直接有 redis:7-alpine 的 arm64v8 鏡像拉下來就能跑性能在 Graviton 實(shí)例上表現(xiàn)不輸 x86。我們團(tuán)隊(duì)之前把一套基于 Redis Cluster 的緩存服務(wù)從 x86 遷移到 ARM 服務(wù)器過程比預(yù)期順利原因很簡單ARM64 的 Linux 內(nèi)核和 GNU 工具鏈早已成熟Redis 本身是純 C 代碼編譯優(yōu)化差異不大。真正需要注意的反而是依賴鏈上的二進(jìn)制包比如舊版本數(shù)據(jù)庫驅(qū)動、某些閉源監(jiān)控 agent可能沒有提供 ARM64 版本需要先確認(rèn)所有依賴支持 ARM64 再動手遷移。Java 生態(tài)在 ARM 上的表現(xiàn)也很成熟OpenJDK 的 ARM64 版本由社區(qū)長期維護(hù)Spring Boot 應(yīng)用基本上可以無感遷移。最大的坑反而是一些老舊的 JNI 庫比如用到了 x86 編譯的 .so 動態(tài)庫拿到 ARM 上肯定不行需要重新編譯源碼或者尋找 ARM 替代品。6. 實(shí)時(shí)安全機(jī)制MPU、TrustZone 與功能安全6.1 MPU 做了什么事和 MMU 有什么本質(zhì)區(qū)別MMU內(nèi)存管理單元是現(xiàn)代操作系統(tǒng)運(yùn)行的基礎(chǔ)它負(fù)責(zé)虛擬地址到物理地址的轉(zhuǎn)換、頁表的維護(hù)、內(nèi)存訪問權(quán)限控制和緩存策略管理。有了 MMU每個(gè)進(jìn)程才能擁有獨(dú)立的地址空間一個(gè)進(jìn)程崩潰了不會把別的進(jìn)程的內(nèi)存數(shù)據(jù)踩壞。MPU內(nèi)存保護(hù)單元則完全不同它不做地址轉(zhuǎn)換只是給已有的物理地址空間設(shè)置訪問權(quán)限。Cortex-M 系列通常沒有 MMU只有 MPUMCU 里的 Flash、SRAM、外設(shè)寄存器都是直接尋址的物理地址。MPU 把地址空間劃分成若干個(gè)區(qū)域每個(gè)區(qū)域可以配置讀寫權(quán)限、執(zhí)行權(quán)限、緩存屬性一旦 CPU 訪問了違反權(quán)限設(shè)置的地址就會觸發(fā) MemManage Fault。聽起來有點(diǎn)像“簡化版 MMU”但設(shè)計(jì)初衷完全不同。MCU 里的軟件通常是單鏡像或者 RTOS 多任務(wù)并不需要虛擬地址映射MPU 的核心價(jià)值是防御防止野指針、棧溢出把關(guān)鍵數(shù)據(jù)區(qū)域踩壞防止普通任務(wù)訪問特權(quán)級外設(shè)寄存器從而實(shí)現(xiàn)軟件層面的故障隔離。我在做電機(jī)控制項(xiàng)目時(shí)會把控制算法的關(guān)鍵參數(shù)存放在受 MPU 保護(hù)的 SRAM 區(qū)域配置為只讀一旦發(fā)現(xiàn)程序異常寫入直接觸發(fā) HardFault 停機(jī)這樣至少能在現(xiàn)場快速暴露問題而不是讓異常數(shù)據(jù)在系統(tǒng)里悄悄擴(kuò)散。6.2 TrustZone 與 Armv8-M 的安全擴(kuò)展TrustZone 是 ARM 提出的系統(tǒng)級安全隔離技術(shù)在 Cortex-A 系列上早已廣泛應(yīng)用完成了從 ARMv7-A 到 ARMv8-A 的過渡。它的做法是把整個(gè)系統(tǒng)從硬件層面劃分成安全世界Secure World和非安全世界Normal World兩個(gè)世界擁有獨(dú)立的特權(quán)等級和內(nèi)存/外設(shè)訪問權(quán)限。普通操作系統(tǒng)運(yùn)行在非安全世界即使內(nèi)核完全被攻破攻擊者也無法訪問安全世界里的敏感數(shù)據(jù)。安全世界里跑的是一個(gè)精簡易用的安全內(nèi)核如 Trusted Firmware-A 或華為的 iTrustee、高通的 QSEE負(fù)責(zé)密鑰管理、安全啟動、指紋比對、支付令牌處理等操作。在 Cortex-M 上TrustZone 從 ARMv8-M 架構(gòu)開始引入M33/M55/M85 都支持這個(gè)特性。對于物聯(lián)網(wǎng)設(shè)備來說這是從芯片層面解決固件安全和數(shù)據(jù)安全的重要手段安全啟動可以阻止固件被篡改或替換安全存儲可以保護(hù)密鑰和證書不被普通應(yīng)用讀取安全調(diào)試可以在量產(chǎn)時(shí)關(guān)閉調(diào)試接口防止熔絲被讀出。實(shí)際項(xiàng)目中應(yīng)用 TrustZone 需要花不少精力因?yàn)榘踩澜绾头前踩澜缰g的通信要走專用的 SMCSecure Monitor Call指令或者 TrustZone 相關(guān)的 API驅(qū)動適配也比普通外設(shè)復(fù)雜。如果只是做一個(gè)消費(fèi)級小產(chǎn)品安全需求不高可以先不開 TrustZone但做車規(guī)、支付、隱私保護(hù)類產(chǎn)品這是必備能力。6.3 功能安全鎖步、ECC 與診斷覆蓋率功能安全Functional Safety是汽車、工業(yè)、醫(yī)療等領(lǐng)域繞不開的話題ARM 在這方面的布局相當(dāng)深入。Cortex-R 系列支持鎖步Lock-Step模式兩顆 CPU 核心同時(shí)執(zhí)行相同指令硬件比較器逐周期比對輸出一旦發(fā)現(xiàn)差異就觸發(fā)安全響應(yīng)比如切斷執(zhí)行器或進(jìn)入安全狀態(tài)。這種冗余設(shè)計(jì)的好處是不需要軟件額外參與硬件自動實(shí)現(xiàn)故障檢測但代價(jià)是算力只有單核可用因?yàn)閮蓚€(gè)核其實(shí)是在跑一份代碼。Cortex-M 在功能安全方面也有完備的支持比如 Cortex-M33 的安全版本可以配合 ARM 推出的 Safety Package提供診斷庫、安全手冊、FMEDA故障模式、影響和診斷分析報(bào)告幫助開發(fā)者快速完成 IEC 61508 或 ISO 26262 的認(rèn)證流程。ECCError Correcting Code 糾錯碼則負(fù)責(zé)保護(hù)內(nèi)存數(shù)據(jù)它能檢測并糾正單比特翻轉(zhuǎn)錯誤在內(nèi)存輻射環(huán)境或者長期運(yùn)行的設(shè)備里這是防止數(shù)據(jù)悄然變壞的重要手段。做功能安全項(xiàng)目千萬不要抱著“硬件能力到位就行了”的心態(tài)。真正難的是軟件層面的安全機(jī)制設(shè)計(jì)故障注入測試要做安全機(jī)制失效時(shí)的降級策略要寫診斷覆蓋率的計(jì)算要詳細(xì)記錄認(rèn)證評審時(shí)專家會逐條核對。ARM 給的安全手冊只是起點(diǎn)項(xiàng)目級的安全策略才是認(rèn)證能否通過的關(guān)鍵。6.4 實(shí)時(shí)性不只是中斷快任務(wù)調(diào)度和資源共享同樣關(guān)鍵很多人理解 ARM 的實(shí)時(shí)性第一反應(yīng)是中斷響應(yīng)延遲覺得“我的中斷 12 個(gè)周期就進(jìn)去了所以我是實(shí)時(shí)的”這是常見誤區(qū)。真正的實(shí)時(shí)性是一個(gè)系統(tǒng)工程中斷響應(yīng)只是其中一個(gè)環(huán)節(jié)。一個(gè)典型的實(shí)時(shí)系統(tǒng)比如汽車 ECU里跑著多個(gè)不同周期的任務(wù)10ms 的任務(wù)負(fù)責(zé)扭矩計(jì)算1ms 的任務(wù)負(fù)責(zé)電流環(huán)100ms 的任務(wù)負(fù)責(zé)通訊診斷。任務(wù)調(diào)度器需要在保證高優(yōu)先級任務(wù)準(zhǔn)時(shí)執(zhí)行的同時(shí)不讓低優(yōu)先級任務(wù)餓死還必須在任務(wù)間安全共享數(shù)據(jù)。這個(gè)過程中任務(wù)切換開銷、互斥鎖等待時(shí)間、Cache 抖動、總線訪問沖突都會影響實(shí)時(shí)性。ARM 在實(shí)時(shí)性方面提供了硬件支持NVIC 的嵌套中斷可以搶占正在執(zhí)行的低優(yōu)先級任務(wù)FPU 的自動保存寄存器狀態(tài)減少了中斷服務(wù)函數(shù)里的軟件保存開銷集成的 TCMTightly Coupled Memory 緊耦合內(nèi)存讓關(guān)鍵代碼和數(shù)據(jù)可以零等待訪問。但最終能不能滿足實(shí)時(shí)性要求還得看你的代碼設(shè)計(jì)中斷里有沒有關(guān)掉全局中斷太久任務(wù)是不是用了不可重入的函數(shù)通信協(xié)議棧有沒有在關(guān)鍵路徑上做了多余拷貝。做實(shí)時(shí)系統(tǒng)的一條基本經(jīng)驗(yàn)是先列出所有任務(wù)的時(shí)序要求周期、截止時(shí)間、最壞執(zhí)行時(shí)間畫出時(shí)間軸找出排列沖突點(diǎn)再考慮中斷優(yōu)先級和任務(wù)優(yōu)先級的配置。有些工程師一上來就調(diào)多重優(yōu)先級嵌套結(jié)果一個(gè)高優(yōu)先級中斷把 CPU 占死了其他所有任務(wù)全部餓死這就是典型的“硬件實(shí)時(shí)軟件不實(shí)時(shí)”。7. 實(shí)操中最常遇到的 6 個(gè) ARM 開發(fā)問題7.1 為什么燒錄提示 “No Cortex-M SW Device Found”這是一個(gè)出現(xiàn)頻率極高的調(diào)試錯誤幾乎每個(gè)用 ST-Link 或者 J-Link 調(diào) Cortex-M 芯片的人都遇到過。首先要理解這句話的含義調(diào)試器搜索不到 SWDSerial Wire Debug接口上的目標(biāo)設(shè)備也就是目標(biāo)芯片沒有響應(yīng)調(diào)試請求。常見原因有這些目標(biāo)板未上電或者供電不足SWDIO 和 SWCLK 兩根線接反或者虛焊目標(biāo)芯片開啟了讀保護(hù)導(dǎo)致調(diào)試接口被鎖定復(fù)位電路異常芯片一直處于復(fù)位狀態(tài)調(diào)試器固件版本過舊不兼容當(dāng)前內(nèi)核。排查思路是先用萬用表量芯片電源和 GND 是否正常再檢查 SWD 兩線是否連接到調(diào)試器的正確引腳然后用調(diào)試器的命令行工具嘗試連接并加上復(fù)位引腳控制最后如果確認(rèn)是讀保護(hù)就需要用芯片廠商的燒錄工具進(jìn)行全片擦除解鎖。這里分享一個(gè)經(jīng)驗(yàn)調(diào)試器與目標(biāo)板之間的連接線越短越好特別是 SWD 時(shí)鐘頻率較高時(shí)長線纜會造成信號反射影響時(shí)序。把線長控制在 10cm 以內(nèi)報(bào)錯概率大幅下降。如果不得不走長線就把 SWD 時(shí)鐘降下來比如從 4MHz 降到 1MHz問題往往迎刃而解。7.2 為什么 “Failed to download” 但偶爾又能連上調(diào)試器這個(gè)問題的隱蔽性比上面那個(gè)高不少。芯片偶爾能連上大多數(shù)情況下又報(bào)下載失敗典型原因是目標(biāo)芯片的調(diào)試接口連接不穩(wěn)定或者芯片內(nèi)部的調(diào)試組件工作狀態(tài)異常。比較常見的一種場景是你的程序里把 SWD 引腳復(fù)用成了 GPIO上電之后程序立刻執(zhí)行引腳重映射SWD 接口就被關(guān)閉了。此時(shí)調(diào)試器在芯片復(fù)位后的極短窗口內(nèi)還能連上但程序一旦跑起來調(diào)試通道就斷了所以出現(xiàn)“時(shí)好時(shí)壞”的詭異表現(xiàn)。解決辦法是把下載算法里的 Reset and Run 選項(xiàng)關(guān)掉讓程序下載完成后不要立即運(yùn)行保持芯片在復(fù)位狀態(tài)然后再嘗試連接或者按住復(fù)位鍵同時(shí)點(diǎn)擊下載時(shí)機(jī)掐準(zhǔn)也能成功。如果做的是低功耗產(chǎn)品還有另一種情況芯片進(jìn)入睡眠模式時(shí)調(diào)試時(shí)鐘被關(guān)閉調(diào)試器無法喚醒內(nèi)核。對策是在低功耗代碼里加一個(gè)編譯開關(guān)調(diào)試階段禁用睡眠模式量產(chǎn)版本再打開。7.3 程序在 RAM 里跑得好好的燒進(jìn) Flash 就死機(jī)這類問題在 Cortex-M 開發(fā)中非常典型。程序通過調(diào)試器直接加載到 RAM 運(yùn)行一切正常只要燒寫進(jìn) Flash復(fù)位后行為就完全不對。原因往往不是代碼邏輯的問題而是地址映射和啟動配置之間的錯位。最常見的坑是中斷向量表位置不對。Cortex-M 上電后默認(rèn)從 0x00000000 取棧頂指針從 0x00000004 取復(fù)位向量。如果你的程序鏈接到 Flash 地址比如 STM32F103 的 0x08000000但編譯時(shí)沒有把向量表放到 Flash 起始位置復(fù)位后 CPU 取出的棧指針和復(fù)位向量全是垃圾數(shù)據(jù)自然跑飛。解決方法是檢查鏈接腳本里向量表的放置地址確保和實(shí)際燒錄地址一致。另一個(gè)隱蔽原因是 Flash 等待周期配置不對。CPU 主頻比較高的時(shí)候Flash 的讀取速度跟不上需要配置 Flash 等待周期Flash Latency。這個(gè)寄存器配置錯誤后CPU 從 Flash 取指令偶爾會拿到錯誤數(shù)據(jù)表現(xiàn)為“隨機(jī)死機(jī)”。在啟動代碼里正確配置 Flash 等待周期和電源電壓范圍是基本功但很多人圖省事跳過了最后被坑得體無完膚。7.4 為什么 A 系列開發(fā)板啟動時(shí)卡在 “Starting kernel ...”Cortex-A 平臺啟動時(shí)報(bào)這個(gè)提示說明 U-Boot 運(yùn)行正常但在把控制權(quán)交給 Linux 內(nèi)核時(shí)出了問題。Linux 內(nèi)核根本沒跑起來掛在啟動早期階段。常見原因一個(gè)是設(shè)備樹里內(nèi)存節(jié)點(diǎn)配置錯誤內(nèi)核發(fā)現(xiàn)的內(nèi)存地址和 U-Boot 實(shí)際初始化 DDR 的地址對不上內(nèi)核訪問內(nèi)存直接掛掉。解決思路是打開內(nèi)核早期打印earlycon在 bootargs 里加上 consolettyAMA0,115200 這類參數(shù)以及 earlyprintk才能看到內(nèi)核早期輸出信息定位是在哪一步掛掉的。還有一個(gè)常見原因是內(nèi)核鏡像格式不匹配。U-Boot 需要 booti 命令來引導(dǎo) arm64 的 Image 格式內(nèi)核如果你用了 bootm 去引導(dǎo)舊式 uImage或者 Image 內(nèi)核沒被打包好跳轉(zhuǎn)后內(nèi)核代碼根本不可執(zhí)行。多確認(rèn) U-Boot 的 bootcmd 環(huán)境變量看看實(shí)際的啟動命令是否是 booti $kernel_addr_r - $fdt_addr_r這個(gè)細(xì)節(jié)能避免很多莫名其妙的問題。7.5 為什么交叉編譯出來的程序在 ARM 板上提示 “No such file or directory”這個(gè)問題看起來詭異文件明明存在但 shell 說找不到。實(shí)際原因和文件存在與否無關(guān)而是動態(tài)鏈接器路徑不對。交叉編譯時(shí)編譯器默認(rèn)把動態(tài)鏈接器的路徑寫在 ELF 文件的 INTERP 段里。比如在 x86 Ubuntu 上交叉編譯 ARM 程序默認(rèn)的鏈接器路徑可能是 /lib/ld-linux-armhf.so.3但你目標(biāo)板上的動態(tài)鏈接器在 /lib/ld-linux-armhf.so.3如果目標(biāo)板根文件系統(tǒng)里沒有這個(gè)文件內(nèi)核就沒法加載程序shell 就會誤報(bào)“文件不存在”。解決辦法有幾種第一種是交叉編譯時(shí)用 -Wl,--dynamic-linker/lib/ld-linux-armhf.so.3 手動指定正確的鏈接器路徑第二種是確保目標(biāo)板根文件系統(tǒng)里有對應(yīng)的動態(tài)鏈接器第三種更省心的方法是直接用目標(biāo)板上的原生編譯器編譯代碼但工程量大時(shí)往往不現(xiàn)實(shí)。還有一種情況是目標(biāo)板內(nèi)核缺少對 ELF 格式的支持比如某些精簡內(nèi)核沒開 CONFIG_BINFMT_ELF也能導(dǎo)致同樣的報(bào)錯不過這種場景相對少見一般先排查動態(tài)鏈接器路徑。7.6 ARM64 上跑 Docker 容器遇到 “exec format error”這個(gè)問題在 ARM 服務(wù)器剛開始普及時(shí)非常常見現(xiàn)在的云環(huán)境里依然會遇到。原因非常直白Docker 鏡像是按架構(gòu)發(fā)布的你在 x86 機(jī)器上構(gòu)建并 push 的鏡像是 amd64 架構(gòu)的拉到 ARM64 機(jī)器上運(yùn)行時(shí)容器里的可執(zhí)行文件是 x86 指令集ARM CPU 不識別底層就會報(bào) exec format error。解決辦法也簡單構(gòu)建鏡像是用 ARM 架構(gòu)的基礎(chǔ)鏡像重新構(gòu)建或者直接用 docker buildx 做多架構(gòu)構(gòu)建一次性產(chǎn)出 amd64 和 arm64 兩個(gè)平臺的鏡像然后在 ARM 機(jī)器上拉取對應(yīng)標(biāo)簽即可。如果項(xiàng)目里用的是第三方鏡像優(yōu)先選擇官方發(fā)布的 multi-arch 鏡像比如 redis、nginx 的官方鏡像都支持。這個(gè)問題的另一個(gè)隱藏坑是如果你用了 qemu 模擬器跑 x86 鏡像雖然能跑起來但性能損失大不說還可能出現(xiàn)各種兼容性問題。生產(chǎn)環(huán)境一定要用原生 ARM 架構(gòu)的鏡像就不要用模擬方案了。8. 從 ARM 生態(tài)看個(gè)人學(xué)習(xí)與項(xiàng)目落地路徑學(xué)了這么多概念和原理很多朋友最大的困惑是我該怎么從“知道”到“會用”。我的建議是從一條主線往下扎先選一塊 Cortex-M 開發(fā)板把裸機(jī)編程跑通理解啟動文件、中斷向量表、GPIO/UART/Timer 這些最基本的東西然后上 RTOS比如 FreeRTOS把任務(wù)調(diào)度、信號量、消息隊(duì)列搞明白再往后可以嘗試 Cortex-A 平臺用樹莓派或者香橙派之類的板子跑 Linux 驅(qū)動開發(fā)從寫一個(gè)簡單的字符設(shè)備驅(qū)動開始慢慢接觸設(shè)備樹、中斷、DMA、內(nèi)核模塊編譯。ARM 生態(tài)的獨(dú)特之處在于它是一個(gè)從底層到頂層貫通的技術(shù)棧指令集、內(nèi)核微架構(gòu)、SoC 集成、啟動鏈路、操作系統(tǒng)適配、應(yīng)用開發(fā)每一層都有海量崗位需求但每一層又并非完全割裂。搞底層的人如果懂一些應(yīng)用層邏輯寫驅(qū)動的時(shí)候會更清楚數(shù)據(jù)最終怎么被消費(fèi)搞應(yīng)用層的人如果理解指令集和內(nèi)存模型排查性能瓶頸時(shí)就不會停留在黑盒猜測。另一個(gè)建議是堅(jiān)持看 ARM 的官方文檔和芯片廠商的手冊而不是只刷網(wǎng)上的碎片化帖子。ARM Architecture Reference Manual 非常勸退但配合具體問題去查收益極高。芯片廠商的參考手冊比如 STM32 Reference Manual也是同類情況很多細(xì)節(jié)網(wǎng)上沒有中文權(quán)威解釋但手冊里一定寫得明明白白。在這個(gè)領(lǐng)域沉淀久了你會發(fā)現(xiàn) ARM 的生態(tài)邏輯其實(shí)很統(tǒng)一它用指令集劃分軟件世界用內(nèi)核劃分性能檔位用安全機(jī)制劃分可靠性等級再用高度可配置的 IP 授權(quán)模式讓每家芯片廠商都能在統(tǒng)一的生態(tài)里玩出自己的差異化。理解了這一層再去看任何一款 ARM 芯片都不過是同一套底層規(guī)則在不同的應(yīng)用場景下的具體投影。