多核實(shí)戰(zhàn)：M33+FreeRTOS與OpenAmp通信避坑指南)
前陣子負(fù)責(zé)一個(gè)需要同時(shí)兼顧 Linux 生態(tài)和實(shí)時(shí)控制的項(xiàng)目最終把選型落在 STM32MP257 上。這顆芯片最大的看點(diǎn)是 Cortex-A35 旁邊那個(gè) Cortex-M33 核用 FreeRTOS 在里面跑實(shí)時(shí)邏輯再通過 OpenAmp 和 Linux 側(cè)做無感通信。很多人一聽到 MPU 就以為又是嵌入式 Linux 那一套實(shí)際上 M33 FreeRTOS 才是真正決定項(xiàng)目成敗的部分。這篇文章從 SDK 目錄結(jié)構(gòu)、啟動(dòng)順序、DTS 內(nèi)存預(yù)留一直聊到 RPMsg 收發(fā)、緩存一致性、量產(chǎn)心跳監(jiān)控的完整過程。準(zhǔn)備在 STM32MP25x 上做異構(gòu)開發(fā)的朋友可以直接當(dāng)避坑手冊(cè)用。1. 從MP1到MP2為什么這次我選了STM32MP257的M33核1.1 STM32MP257不是又一個(gè)跑Linux的開發(fā)板STM32MP257 屬于 STM32MP25x 系列內(nèi)部是多核異構(gòu)架構(gòu)。主處理器是 Cortex-A35可以跑完整的 Linux協(xié)處理器是 Cortex-M33適合跑裸機(jī)或者 FreeRTOS。很多人看到 MPU 的第一反應(yīng)是“主頻多少、內(nèi)存多大、能不能跑容器”但這些指標(biāo)只衡量了 A35 那半邊。真正讓 MP257 和普通 Linux 板卡拉開差距的是那顆 M33 核。傳統(tǒng)做法里如果一個(gè)系統(tǒng)既需要 Linux 的業(yè)務(wù)吞吐又需要對(duì)電機(jī)、IO、協(xié)議棧做“微秒級(jí)響應(yīng)”往往會(huì)外掛一顆 MCU比如 STM32F4 或者 GD32。主 SoC 和 MCU 之間用 UART、SPI、CAN 通信。通信協(xié)議自己要定義可靠性自己要保證板級(jí)面積和功耗也多了一份。MP257 把 M33 做進(jìn)同一顆 SoC兩個(gè)核之間的通信通過共享內(nèi)存和硬件郵箱完成延遲比外掛串口低一兩個(gè)數(shù)量級(jí)。從項(xiàng)目角度講這意味著可以省掉一顆外部 MCU減少整個(gè) BOM 的物料種類和貼片面積。另一方面M33 與 A35 共享同一片 DDR通過 RPMsg 傳數(shù)據(jù)天然比“外部 MCU 串口 協(xié)議解析”更穩(wěn)。當(dāng)然省掉外部 MCU 不意味著省事因?yàn)榭绾苏{(diào)試、內(nèi)存隔離、固件加載這些問題全部從硬件層級(jí)轉(zhuǎn)移到了軟件工程里。1.2 M33核在整個(gè)系統(tǒng)里的角色實(shí)時(shí)性與安全島M33 在 MP257 里承擔(dān)什么角色直接決定了 FreeRTOS 工程怎么寫。如果只是想讓 A35 跑 LinuxM33 跑一個(gè)流水燈那這顆核就浪費(fèi)了。我這次項(xiàng)目里M33 要做三類事第一類是硬實(shí)時(shí)控制。比如電流環(huán)的 PWM 更新周期是 20kHzLinux 的調(diào)度根本保證不了這種確定性。M33 本身就是單片機(jī)內(nèi)核配合定時(shí)器中斷能穩(wěn)定完成。第二類是高速 IO 響應(yīng)。MP257 有不少 GPIO 和低速外設(shè)掛在 M33 側(cè)比如部分 UART、I2C、SPI、定時(shí)器。把這些外設(shè)放在 M33 上A35 側(cè) Linux 發(fā)生調(diào)度抖動(dòng)或者網(wǎng)絡(luò)風(fēng)暴時(shí)M33 依然能按自己的節(jié)奏處理。第三類是安全兜底。Cortex-M33 支持 TrustZone可以把一部分敏感邏輯放在安全世界里。即使 Linux 側(cè)被攻破M33 里的安全固件仍然可以獨(dú)立運(yùn)行。不能說這是百分之百的安全方案但相比“所有邏輯都跑在同一個(gè)非安全環(huán)境下”攻擊面小了很多。換句話說M33 不是一個(gè)“附贈(zèng)品”而是一塊獨(dú)立的實(shí)時(shí)島。FreeRTOS 在這個(gè)島上跑OpenAmp 是島和大陸之間的橋。橋怎么搭比島上怎么蓋樓更重要。1.3 和MP157對(duì)比M33核的資源邊界用過 STM32MP157 的人應(yīng)該知道MP157 的協(xié)處理器是 Cortex-M4主核是 A7。到了 MP257主核升級(jí)為 A35協(xié)處理器升級(jí)為 M33。M33 相比 M4多了 TrustZone、MPU以及更完整的中斷控制器支持。單看頻率M33 在 MP257 上通常能跑幾百 MHz算力比老 M4 有提升但和 A35 不是一個(gè)量級(jí)。M33 可訪問的資源不是無窮的。它有自己的 TCM、SRAM也能通過總線訪問 DDR。但 A35 上的 Linux 訪問同一片 DDR 時(shí)會(huì)涉及緩存一致性問題。簡(jiǎn)單說M33 寫的內(nèi)存數(shù)據(jù)如果只是停在 CPU 的 cache 里A35 讀到的可能是舊值反過來也一樣。所以我們?cè)谠O(shè)計(jì)共享內(nèi)存時(shí)必須明確這塊內(nèi)存是否允許 cache或者由軟件主動(dòng)做 clean/invalidate。還有一個(gè)容易被忽略的地方M33 側(cè)能用的中斷不是所有 GIC SPI 都可以隨便綁。很多中斷源在硬件層面就固定了只能到 A35 或者只能到 M33。開始畫系統(tǒng)框圖前一定要對(duì)著參考手冊(cè)把每一條中斷線捋清楚否則后面寫代碼時(shí)才發(fā)現(xiàn)某個(gè)外設(shè)的中斷根本到不了 M33只能換方案。2. 動(dòng)手前必須理清的啟動(dòng)鏈與資源分配2.1 復(fù)位后的內(nèi)核啟動(dòng)順序A35先跑還是M33先跑很多第一次做 AMP 的人都會(huì)問上電后 M33 要不要自己?jiǎn)?dòng)FreeRTOS 是不是和 A35 的 Linux 一起跑答案要分階段看。MP257 默認(rèn)上電流程里ROM 引導(dǎo)鏈先啟動(dòng) A35 這一路上的 bootloader也就是 FSBL、TF-A、U-Boot最后進(jìn)入 Linux。M33 固件并不會(huì)自動(dòng)跑起來它需要由 A35 側(cè)的軟件通過 remoteproc 機(jī)制加載并啟動(dòng)。這個(gè)設(shè)計(jì)其實(shí)是刻意的M33 跑什么、什么時(shí)候跑、啟動(dòng)后加載到什么地址應(yīng)該由整個(gè)系統(tǒng)的管理者這里通常是 Linux統(tǒng)一決策便于控制資源。所以項(xiàng)目調(diào)試初期最方便的做法是讓 Linux 起來之后用 remoteproc 接口把 M33 的 elf 文件加載到指定內(nèi)存然后觸發(fā)啟動(dòng)。命令大概是echo start /sys/class/remoteproc/remoteproc0/state如果希望系統(tǒng)上電后 M33 自動(dòng)運(yùn)行可以在 U-Boot 階段通過rproc start啟動(dòng) M33。兩套方案我建議初期先全部用手動(dòng)方式確認(rèn)固件和共享內(nèi)存配置無誤后再優(yōu)化成自動(dòng)啟動(dòng)。原因很簡(jiǎn)單手動(dòng)啟動(dòng)時(shí) M33 出了問題你可以直接在 Linux 側(cè)重啟它不用反復(fù)燒錄整個(gè)系統(tǒng)。2.2 給M33分配內(nèi)存DTS reserved-memoryM33 固件要放在內(nèi)存里跑它和 Linux 的通信緩沖區(qū)也要放在內(nèi)存里。這里的難點(diǎn)在于Linux 自己也要用內(nèi)存如果 M33 使用的區(qū)域被 Linux 分配給別的進(jìn)程兩邊數(shù)據(jù)就會(huì)互相踩。所以第一步是在 Linux 的設(shè)備樹里把這些內(nèi)存區(qū)域聲明為 reserved。設(shè)備樹里常見寫法reserved-memory { #address-cells 2; #size-cells 2; ranges; m33_fw0x10000000 { reg 0x0 0x10000000 0x0 0x1000000; no-map; }; m33_rsc: m33-share0x10010000 { compatible shared-dma-pool; reg 0x0 0x10010000 0x0 0x100000; no-map; }; };這里no-map很關(guān)鍵。它告訴 Linux這塊區(qū)域不要建立頁表映射也不要給普通進(jìn)程用。M33 的固件代碼、資源表、共享內(nèi)存都放在這類區(qū)域里。如果沒有no-mapLinux 的頁表可能把這部分內(nèi)存映射為可緩存后面出現(xiàn)各種匪夷所思的奇怪錯(cuò)誤。DTS 里還要將遠(yuǎn)程處理器節(jié)點(diǎn)指向這塊共享內(nèi)存。以官方 SDK 的常見方式為例rproc 節(jié)點(diǎn)會(huì)引用 reserved-memory 中的地址Linux remoteproc 驅(qū)動(dòng)才知道加載固件到哪里以及從哪個(gè)地址讀取 M33 的資源表。這里所有地址必須是物理地址而且要和 M33 固件編譯時(shí)的鏈接地址嚴(yán)格一致。2.3 resource table和固件加載M33 固件和普通 MCU 固件有個(gè)很大的不同它需要附帶一個(gè) resource table。這個(gè)表是給 Linux remoteproc 驅(qū)動(dòng)的“配置清單”里面描述了 M33 側(cè)需要的內(nèi)存、vring 地址、備用資源等。Linux 啟動(dòng) M33 前會(huì)解析這個(gè)表把對(duì)應(yīng)的資源映射給 M33。在 M33 側(cè)工程里resource table 通常是一個(gè) C 結(jié)構(gòu)體。重點(diǎn)是里面的 vring 地址。vring 是 OpenAmp 用于兩個(gè)核之間傳遞消息的“環(huán)形緩沖區(qū)”它必須位于兩塊都很容易訪問且不會(huì)被動(dòng)過的內(nèi)存區(qū)域。我建議直接把 vring 放在 reserved-memory 里并且地址按 64 字節(jié)或者 4KB 對(duì)齊。對(duì)齊問題后面會(huì)展開這里先記住不要把這些緩沖區(qū)定義在 M33 自己的 TCM 里因?yàn)?A35 訪問 TCM 的路徑和訪問 DDR 不同鏈路更慢還容易引發(fā) cache 問題。固件加載方式上官方 SDK 提供了一套 Yocto 工程也提供了預(yù)編譯的 Demo 固件。剛開始不需要自己從頭寫鏈接腳本直接基于官方例程改會(huì)更省事。但你必須把鏈接腳本里 RAM 區(qū)域的起始地址和 DTS 里的 reserved-memory 對(duì)應(yīng)起來否則固件能加載但運(yùn)行時(shí)立刻 HardFault。3. FreeRTOS在M33上的移植看著像M4實(shí)際上三處不一樣3.1 拿SDK的例程改還是從零移植STM32MP257 的 M33 完全可以直接跑 STM32Cube 系列的 HAL 庫。ST 官方提供的 OpenAMP 例程里M33 側(cè)工程一般用的是 CM33 內(nèi)核文件、HAL 驅(qū)動(dòng)和 FreeRTOS 移植層。如果你熟悉 STM32F4/F7 的 CubeMX 工作流上手這個(gè)平臺(tái)并不難。但我不建議直接把老工程的 FreeRTOS 文件拷過來用。M33 和 M4 的底層差別不小TrustZone 會(huì)讓內(nèi)存和中斷分成安全/非安全兩組MPU 的單元數(shù)、內(nèi)存屬性配置也和 M4 不同部分外設(shè)的訪問權(quán)限要顯式打開。哪怕只是從 F4 拷貝一個(gè)port.c都可能因?yàn)榈讓訁R編指令差異而編譯不過。比較好的路徑是先打開官方 M33 FreeRTOS 例程確認(rèn)能編譯能跑然后在此基礎(chǔ)上加入自己的任務(wù)、隊(duì)列和信號(hào)量。不要一開始就想著“我要寫一個(gè)最純凈的工程”在 MP257 上官方例程本身就是最可靠的地基。3.2 TrustZone帶來的隔離問題非安全態(tài)與安全態(tài)Cortex-M33 的 TrustZone 把整個(gè)系統(tǒng)劃分為安全世界和非安全世界。FreeRTOS 可以跑在安全態(tài)也可以跑在非安全態(tài)。ST 官方關(guān)于 M33 的 OpenAMP 例程通常讓 FreeRTOS 跑在非安全態(tài)因?yàn)檫@樣 Linux 側(cè)的 remoteproc 才能正常加載和調(diào)試固件。這帶來一個(gè)實(shí)際影響你在工程啟動(dòng)文件里需要配置 SAUSecurity Attribution Unit把大部分外設(shè)和內(nèi)存區(qū)域標(biāo)記為非安全。否則非安全態(tài)的 FreeRTOS 一訪問外設(shè)寄存器立刻觸發(fā) bus error。我第一次調(diào)的時(shí)候GPIO 初始化明明沒寫錯(cuò)但只要一碰GPIOA-MODER就進(jìn) HardFault查了半天才發(fā)現(xiàn)是 SAU 里完全沒有給外設(shè)開放非安全權(quán)限。如果項(xiàng)目里有安全需求可以把一部分邏輯放到安全側(cè)非安全側(cè)和 Linux 通信安全側(cè)負(fù)責(zé)校驗(yàn)密鑰、管理關(guān)鍵數(shù)據(jù)。不過這會(huì)成倍增加開發(fā)復(fù)雜度。沒有強(qiáng)需求的話建議先用官方例程的默認(rèn)配置跑通再考慮 TrustZone 的安全隔離。3.3 中斷配置與SysTickMPU、NVIC和GIC的邊界M33 在裸機(jī) MCU 上用慣了會(huì)覺得 NVIC 是理所當(dāng)然的中斷控制器。但在 MP257 里系統(tǒng)級(jí)中斷有兩個(gè)層次M33 內(nèi)部有 NVIC同時(shí)芯片里還有一個(gè) GIC負(fù)責(zé)把各種外設(shè)中斷統(tǒng)一發(fā)給 A35 或 M33。GIC 發(fā)給 M33 的中斷會(huì)以 SPIShared Peripheral Interrupt的形式進(jìn) NVIC。因此在配置外設(shè)中斷時(shí)你不僅在操作 NVIC還要確保 GIC 側(cè)已經(jīng)使能了這條中斷線。Linux 側(cè)的設(shè)備樹里可能會(huì)把某些外設(shè)中斷指定到 M33。如果兩邊的中斷路由配置不一致M33 就永遠(yuǎn)收不到中斷。FreeRTOS 的 SysTick 在 M33 上仍然用于系統(tǒng)節(jié)拍。默認(rèn)情況下SysTick 是內(nèi)核私有定時(shí)器不需要經(jīng)過 GIC。但要注意如果在低功耗模式下關(guān)閉了內(nèi)核時(shí)鐘SysTick 也會(huì)停擺導(dǎo)致 FreeRTOS 時(shí)間片失效。這個(gè)問題在“M33 側(cè)進(jìn)入 Stop 模式”的低功耗項(xiàng)目中特別明顯后面量產(chǎn)收尾部分再細(xì)說。3.4 堆棧與MPU給FreeRTOS任務(wù)畫好“安全圈”FreeRTOS 移植好之后第一件事不是急著跑 OpenAmp而是先把多個(gè)任務(wù)跑起來確認(rèn)調(diào)度器正常。任務(wù)棧大小設(shè)多少老手都會(huì)有自己的一套經(jīng)驗(yàn)但在 M33 AMP 場(chǎng)景里任務(wù)棧和共享內(nèi)存之間會(huì)互相擠占所以需要更謹(jǐn)慎。建議打開 FreeRTOS 的堆棧溢出檢測(cè)功能至少用configCHECK_FOR_STACK_OVERFLOW 2。這個(gè)選項(xiàng)會(huì)在任務(wù)切換時(shí)主動(dòng)檢查棧頂標(biāo)志能盡早發(fā)現(xiàn)棧溢出。我遇到過的情況是任務(wù)本身看起來沒炸但 OpenAmp 一端點(diǎn)在接收大包時(shí)遞歸調(diào)用了回調(diào)棧指針一路往下漲最后把另一個(gè)任務(wù)的棧踩了。MPU 的作用是把任務(wù)的內(nèi)存區(qū)域隔離開。M33 的 MPU 支持多個(gè) region可以把每個(gè)任務(wù)棧設(shè)置成獨(dú)立 region并設(shè)置訪問權(quán)限。這個(gè)做法的代價(jià)是任務(wù)切換時(shí) MPU 配置需要同步更新帶來額外性能開銷。我的建議是前期先用最簡(jiǎn)單的方式把所有內(nèi)存權(quán)限都放開專心調(diào)試業(yè)務(wù)量產(chǎn)前再評(píng)估是否要用 MPU 做訪問保護(hù)。4. OpenAmp不是庫是套路RPMsg那條通道怎么修通的4.1 OpenAmp在M33側(cè)的角色不是操作系統(tǒng)的對(duì)立面OpenAmp 的全稱是 Open Asymmetric Multi-Processing它本身不是操作系統(tǒng)而是一套跨核通信框架。M33 側(cè)OpenAmp 庫像是一層“中間件”跑在 FreeRTOS 之上負(fù)責(zé)管理消息通道Linux 側(cè)內(nèi)核 remoteproc/rpmsg 子系統(tǒng)提供了對(duì)等驅(qū)動(dòng)。兩邊用 RPMsgRemote Processor Messaging協(xié)議通信。很多人第一次接觸 RPMsg會(huì)把郵箱和共享內(nèi)存搞混。硬件郵箱是“敲門鈴”它只負(fù)責(zé)通知對(duì)方“我有數(shù)據(jù)了”本身不傳大數(shù)據(jù)。真正傳數(shù)據(jù)靠的是共享內(nèi)存里的 vring 和消息緩沖區(qū)。舉個(gè)例子A35 要給 M33 發(fā)一條 1KB 的控制指令實(shí)際流程是A35 把數(shù)據(jù)寫入共享內(nèi)存的某個(gè) buffer 中然后寫 vring 的更新信息最后觸發(fā)一個(gè)硬件中斷給 M33M33 收到中斷后從對(duì)應(yīng)的 buffer 取出數(shù)據(jù)。M33 側(cè) OpenAmp 的初始化代碼官方例程里能看到類似這樣的流程解析 resource table拿到共享內(nèi)存地址和 vring 地址。調(diào)用openamp_init初始化遠(yuǎn)程處理器框架。注冊(cè) RPMsg 端點(diǎn)和回調(diào)函數(shù)。等待 Linux 側(cè)啟動(dòng)通信。這里的關(guān)鍵是不要試圖把 OpenAmp 和 FreeRTOS 割裂開。OpenAmp 的任務(wù)、中斷處理、接收回調(diào)都要集成到 FreeRTOS 的調(diào)度體系里。如果直接在中斷回調(diào)里處理大量數(shù)據(jù)M33 的實(shí)時(shí)任務(wù)會(huì)被嚴(yán)重拖延。4.2 共享內(nèi)存與vring郵箱和消息池是兩回事把共享內(nèi)存的布局設(shè)計(jì)好OpenAmp 就成功了一半。我習(xí)慣把共享區(qū)域分成兩層第一層是resource table里面保存了 vring 的描述信息以及各端點(diǎn)需要的共享緩沖。第二層是 vring 本身它由多個(gè)描述符組成每個(gè)描述符指向真正的數(shù)據(jù) buffer。一個(gè)常見問題是vring 的地址沒有在 DTS 和 resource table 之間保持一致。Linux remoteproc 驅(qū)動(dòng)啟動(dòng) M33 時(shí)會(huì)從 resource table 讀 vring 地址再與 DTS 中的配置比對(duì)。如果兩邊對(duì)不上要么通信掛起要么握手失敗。不要相信“看起來差不多”的地址直接用十六進(jìn)制逐字節(jié)核對(duì)。還有一個(gè)容易被忽略的細(xì)節(jié)共享內(nèi)存區(qū)域的 cache 屬性。前文提到過no-map實(shí)際使用中還要明確這段內(nèi)存是配置成 cacheable 還是 non-cacheable。為了最簡(jiǎn)單的穩(wěn)定性我通常把 vring 和共享 buffer 標(biāo)記為 non-cacheable。這樣省去了手動(dòng) cache 操作的復(fù)雜度代價(jià)是訪問共享內(nèi)存的速度稍慢。對(duì)于 RPMsg 這種小報(bào)文場(chǎng)景性能完全能接受。如果一定要用 cacheable就必須在每次發(fā)送前做 clean接收前做 invalidate否則會(huì)出現(xiàn)“對(duì)方明明寫了數(shù)據(jù)我卻讀到舊值”的問題。4.3 從Linux側(cè)發(fā)起通信rproc_boot與rpmsg_client_sampleLinux 側(cè)內(nèi)核的 remoteproc 子系統(tǒng)負(fù)責(zé)管理 M33 生命周期。啟動(dòng) M33echo start /sys/class/remoteproc/remoteproc0/state停止 M33echo stop /sys/class/remoteproc/remoteproc0/state啟動(dòng)成功后Linux 下會(huì)多出一個(gè)/dev/rpmsg0設(shè)備節(jié)點(diǎn)。應(yīng)用程序可以像普通設(shè)備文件一樣打開它、讀寫數(shù)據(jù)。官方內(nèi)核里有一個(gè)rpmsg_client_sample模塊加載后會(huì)自動(dòng)創(chuàng)建一個(gè)端點(diǎn)往 M33 發(fā)一條消息然后等待回應(yīng)。這個(gè) Sample 是驗(yàn)證整條鏈路最好的工具modprobe rpmsg_client_sample如果 M33 側(cè)的 FreeRTOS 例程已經(jīng)跑起來但rpmsg_client_sample沒反應(yīng)多半是 vring 地址不對(duì)、共享內(nèi)存 cache 配置不一致或者 M33 側(cè)根本沒有注冊(cè)對(duì)應(yīng)的服務(wù)端點(diǎn)。4.4 M33側(cè)循環(huán)收發(fā)拷貝策略與中斷回包M33 側(cè)收到 RPMsg 消息后回調(diào)函數(shù)會(huì)被 OpenAmp 庫調(diào)用。這個(gè)回調(diào)是在什么上下文里執(zhí)行的根據(jù)官方例程通常是在 OpenAmp 自己的接收任務(wù)里或者在一個(gè)由信箱中斷觸發(fā)的傘形中斷中。無論哪種都不應(yīng)該在里面做耗時(shí)操作。正確做法是回調(diào)函數(shù)里把數(shù)據(jù)拷貝到自己的任務(wù)緩沖然后通知業(yè)務(wù)任務(wù)去處理。這里有個(gè)取舍拷貝會(huì)帶來額外開銷但換來的是任務(wù)調(diào)度更加解耦。如果控制數(shù)據(jù)只有幾十字節(jié)拷貝幾乎可以忽略如果是大數(shù)據(jù)塊你也可以只拷貝指針但前提是發(fā)送方在收到 ACK 前不能重用這塊緩沖區(qū)。為了降低復(fù)雜度我初期一直是直接拷貝穩(wěn)定優(yōu)先。另外要注意M33 收到消息后如果需要回復(fù) Linux應(yīng)該在發(fā)送完成后調(diào)用一次緩存清理操作確保 Linux 能讀到最新數(shù)據(jù)。RPMsg 的發(fā)送函數(shù)rpm_send內(nèi)部一般會(huì)做必要的 cache 處理但如果你在回調(diào)里直接操作共享內(nèi)存還是要自己把關(guān)。5. 真機(jī)聯(lián)調(diào)階段踩過的坑每一個(gè)都值得記下來5.1 現(xiàn)象M33內(nèi)核崩潰但Linux毫無察覺第一次跑通 OpenAmp 后我給 M33 加了一個(gè)比較復(fù)雜的控制任務(wù)結(jié)果發(fā)現(xiàn) M33 側(cè)代碼進(jìn)入 HardFault但 Linux 側(cè)毫不知情。A35 的 remoteproc 驅(qū)動(dòng)不會(huì)主動(dòng)監(jiān)測(cè) M33 是否還活著它只負(fù)責(zé)啟動(dòng)和停止。M33 死了Linux 上的/dev/rpmsg0依然存在但收不到任何響應(yīng)。排查時(shí)我一開始以為是 FreeRTOS 里的任務(wù)棧溢出就把configCHECK_FOR_STACK_OVERFLOW打開也加了棧水印打印。后來發(fā)現(xiàn)問題出在一個(gè)定時(shí)器中斷服務(wù)函數(shù)里我在中斷里訪問了一處被 Linux 占用的外設(shè)寄存器M33 總線上直接報(bào)錯(cuò)進(jìn)入 HardFault。這種問題最坑的地方在于M33 的 HardFault 如果不處理整個(gè) M33 就“死寂”了而 Linux 側(cè)只能通過它的心跳超時(shí)才能發(fā)現(xiàn)。所以聯(lián)調(diào)初期M33 側(cè)一定要加上故障打印并且把 HardFault_Handler 里記錄的關(guān)鍵寄存器通過串口輸出。否則出了問題你根本不知道是任務(wù)調(diào)度崩了還是外設(shè)訪問違例。5.2 現(xiàn)象OpenAMP握手失敗rpmsg創(chuàng)建不了端點(diǎn)第二個(gè)坑是 OpenAmp 的握手失敗。Linux 側(cè)rpmsg_client_sample加載后/dev/rpmsg0雖然創(chuàng)建了但 M33 側(cè)一直沒有日志輸出也不回包。我一開始重新編譯了固件檢查了 endpoint 注冊(cè)順序問題依舊。后來用調(diào)試器掛在共享內(nèi)存上查看 resource table 的內(nèi)容才發(fā)現(xiàn) vring 地址和 DTS 里預(yù)設(shè)的地址差了幾百字節(jié)。原因是我改了鏈接腳本M33 固件里的 resource table 被編譯器重新排版了但 DTS 里的 reserved-memory 還是舊地址。兩邊各自都“對(duì)”就是互相不對(duì)。這里給新手一個(gè)建議不要手動(dòng)修改 resource table 的存放位置除非你完全理解 OpenAmp 的加載流程。在任何一次鏈接腳本調(diào)整后都要重新生成 resource table并和設(shè)備樹比對(duì)。5.3 現(xiàn)象printf打印影響實(shí)時(shí)性M33 側(cè)調(diào)試時(shí)很多人習(xí)慣在任務(wù)里加 printf。這個(gè)思維是從 MCU 開發(fā)帶來的但在 MP257 上要特別小心。M33 的 printf 如果走串口而串口驅(qū)動(dòng)在 FreeRTOS 里用了阻塞式發(fā)送遇到波特率 115200 時(shí)一條幾十字節(jié)的日志就要占掉幾毫秒。對(duì)于 20kHz 的控制周期這是災(zāi)難。我的做法是聯(lián)調(diào)階段把 printf 重定向到共享內(nèi)存里的一個(gè)環(huán)型日志區(qū)Linux 側(cè)隨時(shí)讀取。正式運(yùn)行階段把調(diào)試 printf 用宏關(guān)掉只保留錯(cuò)誤級(jí)別日志。這樣既不影響實(shí)時(shí)性又能完整復(fù)現(xiàn)現(xiàn)場(chǎng)。5.4 調(diào)試手段用Linux的/dev/rpmsg0和M33的log互相印證AMP 聯(lián)調(diào)最大的痛苦是“兩邊都覺得對(duì)方?jīng)]發(fā)數(shù)據(jù)”。我的經(jīng)驗(yàn)是建立一套雙向的“回環(huán)測(cè)試”再開始業(yè)務(wù)邏輯開發(fā)。先讓 M33 收到什么就回什么然后在 Linux 側(cè)寫一個(gè)簡(jiǎn)單腳本往/dev/rpmsg0發(fā)一串遞增數(shù)據(jù)接收端校驗(yàn)是否原樣返回。跑通回環(huán)后再逐步加入業(yè)務(wù)。如果回環(huán)都過不了問題一定在底層資源配置或緩存一致性上不要往下寫業(yè)務(wù)。M33 側(cè)也要把日志做成“有向心跳”每收到一條消息就通過串口輸出一個(gè)序號(hào)。這樣即使沒有調(diào)試器也能確認(rèn) OpenAmp 的接收鏈路是通的。我實(shí)測(cè)下來這套方法能過濾掉八成以上的“疑似通信問題”。6. 量產(chǎn)前必須補(bǔ)上的收尾工作6.1 監(jiān)控M33心跳光靠watchdog不夠M33 側(cè)跑 FreeRTOS通常都會(huì)開一個(gè)獨(dú)立看門狗防止任務(wù)死鎖。但看門狗只能“發(fā)現(xiàn)死機(jī)后復(fù)位”恢復(fù)后 Linux 側(cè)怎么知道 M33 已經(jīng)重啟過這是量產(chǎn)前必須設(shè)計(jì)的。我建議在 Linux 側(cè)寫一個(gè)應(yīng)用周期性通過 RPMsg 向 M33 發(fā)送心跳查詢M33 在最高優(yōu)先級(jí)任務(wù)里回應(yīng)。如果連續(xù)若干次沒有回應(yīng)Linux 主動(dòng)stopstartM33。這樣 M33 即使崩潰也能在無人工介入的情況下自動(dòng)恢復(fù)。注意這個(gè)機(jī)制不能依賴簡(jiǎn)單的一問一答建議在心跳報(bào)文里帶序列號(hào)用于發(fā)現(xiàn) M33 是否發(fā)生過重啟。M33 側(cè)同樣要監(jiān)控 Linux 側(cè)的心跳。若 Linux 側(cè)卡死或者重啟M33 要能做安全保護(hù)比如把執(zhí)行機(jī)構(gòu)歸到安全位置。異構(gòu)系統(tǒng)不能只保護(hù)單側(cè)兩側(cè)都要有“對(duì)方可能死掉”的意識(shí)。6.2 低功耗時(shí)別忘了M33的電源域MP257 的功耗管理是個(gè)大話題A35 側(cè)的 Linux 有 CPUFreq、CPUIdleM33 側(cè)也有自己的低功耗模式。M33 進(jìn)入 Deep Sleep 前必須關(guān)閉對(duì)共享內(nèi)存的訪問并讓 Linux 側(cè)的 remoteproc 先處于停止?fàn)顟B(tài)。我踩過的坑是Linux 側(cè)進(jìn)入 suspendM33 還掛在共享內(nèi)存上結(jié)果喚醒后共享數(shù)據(jù)區(qū)出現(xiàn)撕裂。正確的順序是先讓 M33 進(jìn)入低功耗等待命令狀態(tài)再讓 Linux 進(jìn)入 suspend喚醒時(shí)反過來Linux 先恢復(fù)正常再喚醒 M33。整個(gè)流程要用 RPMsg 做一個(gè)握手協(xié)議不能用簡(jiǎn)單延時(shí)“估摸”對(duì)方已經(jīng)完成。6.3 日志規(guī)范與遠(yuǎn)程升級(jí)的邊界M33 固件和 Linux 內(nèi)核是兩套獨(dú)立鏡像量產(chǎn)后的升級(jí)鏈路也完全不同。Linux 側(cè)可以通過 A/B 分區(qū)做系統(tǒng)級(jí) OTAM33 固件則需要設(shè)計(jì)自己的升級(jí)機(jī)制常見做法是由 Linux 側(cè)把新固件下載到某個(gè)分區(qū)再通過 remoteproc 停止 M33、寫入新固件、重新啟動(dòng)。升級(jí)過程中最怕兩件事一是升級(jí)到一半掉電M33 固件損壞二是新舊固件的資源表不兼容導(dǎo)致 OpenAmp 通信失敗。對(duì)第一個(gè)問題建議 M33 固件保留一個(gè)極小 Bootloader負(fù)責(zé)校驗(yàn) App 固件對(duì)第二個(gè)問題建議在 RPMsg 應(yīng)用層約定版本號(hào)Linux 啟動(dòng) M33 后先做版本握手版本不匹配直接拒絕業(yè)務(wù)。這些在項(xiàng)目初期就要定好量產(chǎn)后再改協(xié)議非常痛苦。6.4 實(shí)測(cè)性能參考與后續(xù)擴(kuò)展拿我們實(shí)際項(xiàng)目的數(shù)據(jù)做個(gè)參考A35 雙核跑 LinuxM33 跑 FreeRTOSOpenAmp 通過 RPMsg 每 1ms 雙向交換一條 64 字節(jié)狀態(tài)幀。M33 側(cè)額外跑著三個(gè)任務(wù)分別是 1kHz 控制循環(huán)、按鍵掃描、串口日志。整條鏈路跑下來RPMsg 單次收發(fā)的 CPU 占用和中斷延遲都在可接受范圍內(nèi)。如果業(yè)務(wù)需要更大帶寬可以考慮把共享緩沖區(qū)加大或使用帶 cache 的訪問模式但務(wù)必做好緩存一致性處理。后續(xù)擴(kuò)展方向上可以考慮讓 M33 直接承擔(dān)一部分傳感器數(shù)據(jù)預(yù)處理只把提煉后的結(jié)果發(fā)給 A35。也可以嘗試把部分網(wǎng)絡(luò)協(xié)議棧卸載到 Linux把實(shí)時(shí)安全策略放在 M33。這個(gè)平臺(tái)最大的魅力就在于此兩顆核各司其職又共用一套內(nèi)存。對(duì)我個(gè)人而言用過 MP257 的 M33 FreeRTOS OpenAmp 組合后再回到“外掛 MCU 串口”的老路確實(shí)回不去了。 STM32MP257異構(gòu)多核實(shí)戰(zhàn)：M33+FreeRTOS與OpenAmp通信避坑指南
前陣子負(fù)責(zé)一個(gè)需要同時(shí)兼顧 Linux 生態(tài)和實(shí)時(shí)控制的項(xiàng)目最終把選型落在 STM32MP257 上。這顆芯片最大的看點(diǎn)是 Cortex-A35 旁邊那個(gè) Cortex-M33 核用 FreeRTOS 在里面跑實(shí)時(shí)邏輯再通過 OpenAmp 和 Linux 側(cè)做無感通信。很多人一聽到 MPU 就以為又是嵌入式 Linux 那一套實(shí)際上 M33 FreeRTOS 才是真正決定項(xiàng)目成敗的部分。這篇文章從 SDK 目錄結(jié)構(gòu)、啟動(dòng)順序、DTS 內(nèi)存預(yù)留一直聊到 RPMsg 收發(fā)、緩存一致性、量產(chǎn)心跳監(jiān)控的完整過程。準(zhǔn)備在 STM32MP25x 上做異構(gòu)開發(fā)的朋友可以直接當(dāng)避坑手冊(cè)用。1. 從MP1到MP2為什么這次我選了STM32MP257的M33核1.1 STM32MP257不是又一個(gè)跑Linux的開發(fā)板STM32MP257 屬于 STM32MP25x 系列內(nèi)部是多核異構(gòu)架構(gòu)。主處理器是 Cortex-A35可以跑完整的 Linux協(xié)處理器是 Cortex-M33適合跑裸機(jī)或者 FreeRTOS。很多人看到 MPU 的第一反應(yīng)是“主頻多少、內(nèi)存多大、能不能跑容器”但這些指標(biāo)只衡量了 A35 那半邊。真正讓 MP257 和普通 Linux 板卡拉開差距的是那顆 M33 核。傳統(tǒng)做法里如果一個(gè)系統(tǒng)既需要 Linux 的業(yè)務(wù)吞吐又需要對(duì)電機(jī)、IO、協(xié)議棧做“微秒級(jí)響應(yīng)”往往會(huì)外掛一顆 MCU比如 STM32F4 或者 GD32。主 SoC 和 MCU 之間用 UART、SPI、CAN 通信。通信協(xié)議自己要定義可靠性自己要保證板級(jí)面積和功耗也多了一份。MP257 把 M33 做進(jìn)同一顆 SoC兩個(gè)核之間的通信通過共享內(nèi)存和硬件郵箱完成延遲比外掛串口低一兩個(gè)數(shù)量級(jí)。從項(xiàng)目角度講這意味著可以省掉一顆外部 MCU減少整個(gè) BOM 的物料種類和貼片面積。另一方面M33 與 A35 共享同一片 DDR通過 RPMsg 傳數(shù)據(jù)天然比“外部 MCU 串口 協(xié)議解析”更穩(wěn)。當(dāng)然省掉外部 MCU 不意味著省事因?yàn)榭绾苏{(diào)試、內(nèi)存隔離、固件加載這些問題全部從硬件層級(jí)轉(zhuǎn)移到了軟件工程里。1.2 M33核在整個(gè)系統(tǒng)里的角色實(shí)時(shí)性與安全島M33 在 MP257 里承擔(dān)什么角色直接決定了 FreeRTOS 工程怎么寫。如果只是想讓 A35 跑 LinuxM33 跑一個(gè)流水燈那這顆核就浪費(fèi)了。我這次項(xiàng)目里M33 要做三類事第一類是硬實(shí)時(shí)控制。比如電流環(huán)的 PWM 更新周期是 20kHzLinux 的調(diào)度根本保證不了這種確定性。M33 本身就是單片機(jī)內(nèi)核配合定時(shí)器中斷能穩(wěn)定完成。第二類是高速 IO 響應(yīng)。MP257 有不少 GPIO 和低速外設(shè)掛在 M33 側(cè)比如部分 UART、I2C、SPI、定時(shí)器。把這些外設(shè)放在 M33 上A35 側(cè) Linux 發(fā)生調(diào)度抖動(dòng)或者網(wǎng)絡(luò)風(fēng)暴時(shí)M33 依然能按自己的節(jié)奏處理。第三類是安全兜底。Cortex-M33 支持 TrustZone可以把一部分敏感邏輯放在安全世界里。即使 Linux 側(cè)被攻破M33 里的安全固件仍然可以獨(dú)立運(yùn)行。不能說這是百分之百的安全方案但相比“所有邏輯都跑在同一個(gè)非安全環(huán)境下”攻擊面小了很多。換句話說M33 不是一個(gè)“附贈(zèng)品”而是一塊獨(dú)立的實(shí)時(shí)島。FreeRTOS 在這個(gè)島上跑OpenAmp 是島和大陸之間的橋。橋怎么搭比島上怎么蓋樓更重要。1.3 和MP157對(duì)比M33核的資源邊界用過 STM32MP157 的人應(yīng)該知道MP157 的協(xié)處理器是 Cortex-M4主核是 A7。到了 MP257主核升級(jí)為 A35協(xié)處理器升級(jí)為 M33。M33 相比 M4多了 TrustZone、MPU以及更完整的中斷控制器支持。單看頻率M33 在 MP257 上通常能跑幾百 MHz算力比老 M4 有提升但和 A35 不是一個(gè)量級(jí)。M33 可訪問的資源不是無窮的。它有自己的 TCM、SRAM也能通過總線訪問 DDR。但 A35 上的 Linux 訪問同一片 DDR 時(shí)會(huì)涉及緩存一致性問題。簡(jiǎn)單說M33 寫的內(nèi)存數(shù)據(jù)如果只是停在 CPU 的 cache 里A35 讀到的可能是舊值反過來也一樣。所以我們?cè)谠O(shè)計(jì)共享內(nèi)存時(shí)必須明確這塊內(nèi)存是否允許 cache或者由軟件主動(dòng)做 clean/invalidate。還有一個(gè)容易被忽略的地方M33 側(cè)能用的中斷不是所有 GIC SPI 都可以隨便綁。很多中斷源在硬件層面就固定了只能到 A35 或者只能到 M33。開始畫系統(tǒng)框圖前一定要對(duì)著參考手冊(cè)把每一條中斷線捋清楚否則后面寫代碼時(shí)才發(fā)現(xiàn)某個(gè)外設(shè)的中斷根本到不了 M33只能換方案。2. 動(dòng)手前必須理清的啟動(dòng)鏈與資源分配2.1 復(fù)位后的內(nèi)核啟動(dòng)順序A35先跑還是M33先跑很多第一次做 AMP 的人都會(huì)問上電后 M33 要不要自己?jiǎn)?dòng)FreeRTOS 是不是和 A35 的 Linux 一起跑答案要分階段看。MP257 默認(rèn)上電流程里ROM 引導(dǎo)鏈先啟動(dòng) A35 這一路上的 bootloader也就是 FSBL、TF-A、U-Boot最后進(jìn)入 Linux。M33 固件并不會(huì)自動(dòng)跑起來它需要由 A35 側(cè)的軟件通過 remoteproc 機(jī)制加載并啟動(dòng)。這個(gè)設(shè)計(jì)其實(shí)是刻意的M33 跑什么、什么時(shí)候跑、啟動(dòng)后加載到什么地址應(yīng)該由整個(gè)系統(tǒng)的管理者這里通常是 Linux統(tǒng)一決策便于控制資源。所以項(xiàng)目調(diào)試初期最方便的做法是讓 Linux 起來之后用 remoteproc 接口把 M33 的 elf 文件加載到指定內(nèi)存然后觸發(fā)啟動(dòng)。命令大概是echo start /sys/class/remoteproc/remoteproc0/state如果希望系統(tǒng)上電后 M33 自動(dòng)運(yùn)行可以在 U-Boot 階段通過rproc start啟動(dòng) M33。兩套方案我建議初期先全部用手動(dòng)方式確認(rèn)固件和共享內(nèi)存配置無誤后再優(yōu)化成自動(dòng)啟動(dòng)。原因很簡(jiǎn)單手動(dòng)啟動(dòng)時(shí) M33 出了問題你可以直接在 Linux 側(cè)重啟它不用反復(fù)燒錄整個(gè)系統(tǒng)。2.2 給M33分配內(nèi)存DTS reserved-memoryM33 固件要放在內(nèi)存里跑它和 Linux 的通信緩沖區(qū)也要放在內(nèi)存里。這里的難點(diǎn)在于Linux 自己也要用內(nèi)存如果 M33 使用的區(qū)域被 Linux 分配給別的進(jìn)程兩邊數(shù)據(jù)就會(huì)互相踩。所以第一步是在 Linux 的設(shè)備樹里把這些內(nèi)存區(qū)域聲明為 reserved。設(shè)備樹里常見寫法reserved-memory { #address-cells 2; #size-cells 2; ranges; m33_fw0x10000000 { reg 0x0 0x10000000 0x0 0x1000000; no-map; }; m33_rsc: m33-share0x10010000 { compatible shared-dma-pool; reg 0x0 0x10010000 0x0 0x100000; no-map; }; };這里no-map很關(guān)鍵。它告訴 Linux這塊區(qū)域不要建立頁表映射也不要給普通進(jìn)程用。M33 的固件代碼、資源表、共享內(nèi)存都放在這類區(qū)域里。如果沒有no-mapLinux 的頁表可能把這部分內(nèi)存映射為可緩存后面出現(xiàn)各種匪夷所思的奇怪錯(cuò)誤。DTS 里還要將遠(yuǎn)程處理器節(jié)點(diǎn)指向這塊共享內(nèi)存。以官方 SDK 的常見方式為例rproc 節(jié)點(diǎn)會(huì)引用 reserved-memory 中的地址Linux remoteproc 驅(qū)動(dòng)才知道加載固件到哪里以及從哪個(gè)地址讀取 M33 的資源表。這里所有地址必須是物理地址而且要和 M33 固件編譯時(shí)的鏈接地址嚴(yán)格一致。2.3 resource table和固件加載M33 固件和普通 MCU 固件有個(gè)很大的不同它需要附帶一個(gè) resource table。這個(gè)表是給 Linux remoteproc 驅(qū)動(dòng)的“配置清單”里面描述了 M33 側(cè)需要的內(nèi)存、vring 地址、備用資源等。Linux 啟動(dòng) M33 前會(huì)解析這個(gè)表把對(duì)應(yīng)的資源映射給 M33。在 M33 側(cè)工程里resource table 通常是一個(gè) C 結(jié)構(gòu)體。重點(diǎn)是里面的 vring 地址。vring 是 OpenAmp 用于兩個(gè)核之間傳遞消息的“環(huán)形緩沖區(qū)”它必須位于兩塊都很容易訪問且不會(huì)被動(dòng)過的內(nèi)存區(qū)域。我建議直接把 vring 放在 reserved-memory 里并且地址按 64 字節(jié)或者 4KB 對(duì)齊。對(duì)齊問題后面會(huì)展開這里先記住不要把這些緩沖區(qū)定義在 M33 自己的 TCM 里因?yàn)?A35 訪問 TCM 的路徑和訪問 DDR 不同鏈路更慢還容易引發(fā) cache 問題。固件加載方式上官方 SDK 提供了一套 Yocto 工程也提供了預(yù)編譯的 Demo 固件。剛開始不需要自己從頭寫鏈接腳本直接基于官方例程改會(huì)更省事。但你必須把鏈接腳本里 RAM 區(qū)域的起始地址和 DTS 里的 reserved-memory 對(duì)應(yīng)起來否則固件能加載但運(yùn)行時(shí)立刻 HardFault。3. FreeRTOS在M33上的移植看著像M4實(shí)際上三處不一樣3.1 拿SDK的例程改還是從零移植STM32MP257 的 M33 完全可以直接跑 STM32Cube 系列的 HAL 庫。ST 官方提供的 OpenAMP 例程里M33 側(cè)工程一般用的是 CM33 內(nèi)核文件、HAL 驅(qū)動(dòng)和 FreeRTOS 移植層。如果你熟悉 STM32F4/F7 的 CubeMX 工作流上手這個(gè)平臺(tái)并不難。但我不建議直接把老工程的 FreeRTOS 文件拷過來用。M33 和 M4 的底層差別不小TrustZone 會(huì)讓內(nèi)存和中斷分成安全/非安全兩組MPU 的單元數(shù)、內(nèi)存屬性配置也和 M4 不同部分外設(shè)的訪問權(quán)限要顯式打開。哪怕只是從 F4 拷貝一個(gè)port.c都可能因?yàn)榈讓訁R編指令差異而編譯不過。比較好的路徑是先打開官方 M33 FreeRTOS 例程確認(rèn)能編譯能跑然后在此基礎(chǔ)上加入自己的任務(wù)、隊(duì)列和信號(hào)量。不要一開始就想著“我要寫一個(gè)最純凈的工程”在 MP257 上官方例程本身就是最可靠的地基。3.2 TrustZone帶來的隔離問題非安全態(tài)與安全態(tài)Cortex-M33 的 TrustZone 把整個(gè)系統(tǒng)劃分為安全世界和非安全世界。FreeRTOS 可以跑在安全態(tài)也可以跑在非安全態(tài)。ST 官方關(guān)于 M33 的 OpenAMP 例程通常讓 FreeRTOS 跑在非安全態(tài)因?yàn)檫@樣 Linux 側(cè)的 remoteproc 才能正常加載和調(diào)試固件。這帶來一個(gè)實(shí)際影響你在工程啟動(dòng)文件里需要配置 SAUSecurity Attribution Unit把大部分外設(shè)和內(nèi)存區(qū)域標(biāo)記為非安全。否則非安全態(tài)的 FreeRTOS 一訪問外設(shè)寄存器立刻觸發(fā) bus error。我第一次調(diào)的時(shí)候GPIO 初始化明明沒寫錯(cuò)但只要一碰GPIOA-MODER就進(jìn) HardFault查了半天才發(fā)現(xiàn)是 SAU 里完全沒有給外設(shè)開放非安全權(quán)限。如果項(xiàng)目里有安全需求可以把一部分邏輯放到安全側(cè)非安全側(cè)和 Linux 通信安全側(cè)負(fù)責(zé)校驗(yàn)密鑰、管理關(guān)鍵數(shù)據(jù)。不過這會(huì)成倍增加開發(fā)復(fù)雜度。沒有強(qiáng)需求的話建議先用官方例程的默認(rèn)配置跑通再考慮 TrustZone 的安全隔離。3.3 中斷配置與SysTickMPU、NVIC和GIC的邊界M33 在裸機(jī) MCU 上用慣了會(huì)覺得 NVIC 是理所當(dāng)然的中斷控制器。但在 MP257 里系統(tǒng)級(jí)中斷有兩個(gè)層次M33 內(nèi)部有 NVIC同時(shí)芯片里還有一個(gè) GIC負(fù)責(zé)把各種外設(shè)中斷統(tǒng)一發(fā)給 A35 或 M33。GIC 發(fā)給 M33 的中斷會(huì)以 SPIShared Peripheral Interrupt的形式進(jìn) NVIC。因此在配置外設(shè)中斷時(shí)你不僅在操作 NVIC還要確保 GIC 側(cè)已經(jīng)使能了這條中斷線。Linux 側(cè)的設(shè)備樹里可能會(huì)把某些外設(shè)中斷指定到 M33。如果兩邊的中斷路由配置不一致M33 就永遠(yuǎn)收不到中斷。FreeRTOS 的 SysTick 在 M33 上仍然用于系統(tǒng)節(jié)拍。默認(rèn)情況下SysTick 是內(nèi)核私有定時(shí)器不需要經(jīng)過 GIC。但要注意如果在低功耗模式下關(guān)閉了內(nèi)核時(shí)鐘SysTick 也會(huì)停擺導(dǎo)致 FreeRTOS 時(shí)間片失效。這個(gè)問題在“M33 側(cè)進(jìn)入 Stop 模式”的低功耗項(xiàng)目中特別明顯后面量產(chǎn)收尾部分再細(xì)說。3.4 堆棧與MPU給FreeRTOS任務(wù)畫好“安全圈”FreeRTOS 移植好之后第一件事不是急著跑 OpenAmp而是先把多個(gè)任務(wù)跑起來確認(rèn)調(diào)度器正常。任務(wù)棧大小設(shè)多少老手都會(huì)有自己的一套經(jīng)驗(yàn)但在 M33 AMP 場(chǎng)景里任務(wù)棧和共享內(nèi)存之間會(huì)互相擠占所以需要更謹(jǐn)慎。建議打開 FreeRTOS 的堆棧溢出檢測(cè)功能至少用configCHECK_FOR_STACK_OVERFLOW 2。這個(gè)選項(xiàng)會(huì)在任務(wù)切換時(shí)主動(dòng)檢查棧頂標(biāo)志能盡早發(fā)現(xiàn)棧溢出。我遇到過的情況是任務(wù)本身看起來沒炸但 OpenAmp 一端點(diǎn)在接收大包時(shí)遞歸調(diào)用了回調(diào)棧指針一路往下漲最后把另一個(gè)任務(wù)的棧踩了。MPU 的作用是把任務(wù)的內(nèi)存區(qū)域隔離開。M33 的 MPU 支持多個(gè) region可以把每個(gè)任務(wù)棧設(shè)置成獨(dú)立 region并設(shè)置訪問權(quán)限。這個(gè)做法的代價(jià)是任務(wù)切換時(shí) MPU 配置需要同步更新帶來額外性能開銷。我的建議是前期先用最簡(jiǎn)單的方式把所有內(nèi)存權(quán)限都放開專心調(diào)試業(yè)務(wù)量產(chǎn)前再評(píng)估是否要用 MPU 做訪問保護(hù)。4. OpenAmp不是庫是套路RPMsg那條通道怎么修通的4.1 OpenAmp在M33側(cè)的角色不是操作系統(tǒng)的對(duì)立面OpenAmp 的全稱是 Open Asymmetric Multi-Processing它本身不是操作系統(tǒng)而是一套跨核通信框架。M33 側(cè)OpenAmp 庫像是一層“中間件”跑在 FreeRTOS 之上負(fù)責(zé)管理消息通道Linux 側(cè)內(nèi)核 remoteproc/rpmsg 子系統(tǒng)提供了對(duì)等驅(qū)動(dòng)。兩邊用 RPMsgRemote Processor Messaging協(xié)議通信。很多人第一次接觸 RPMsg會(huì)把郵箱和共享內(nèi)存搞混。硬件郵箱是“敲門鈴”它只負(fù)責(zé)通知對(duì)方“我有數(shù)據(jù)了”本身不傳大數(shù)據(jù)。真正傳數(shù)據(jù)靠的是共享內(nèi)存里的 vring 和消息緩沖區(qū)。舉個(gè)例子A35 要給 M33 發(fā)一條 1KB 的控制指令實(shí)際流程是A35 把數(shù)據(jù)寫入共享內(nèi)存的某個(gè) buffer 中然后寫 vring 的更新信息最后觸發(fā)一個(gè)硬件中斷給 M33M33 收到中斷后從對(duì)應(yīng)的 buffer 取出數(shù)據(jù)。M33 側(cè) OpenAmp 的初始化代碼官方例程里能看到類似這樣的流程解析 resource table拿到共享內(nèi)存地址和 vring 地址。調(diào)用openamp_init初始化遠(yuǎn)程處理器框架。注冊(cè) RPMsg 端點(diǎn)和回調(diào)函數(shù)。等待 Linux 側(cè)啟動(dòng)通信。這里的關(guān)鍵是不要試圖把 OpenAmp 和 FreeRTOS 割裂開。OpenAmp 的任務(wù)、中斷處理、接收回調(diào)都要集成到 FreeRTOS 的調(diào)度體系里。如果直接在中斷回調(diào)里處理大量數(shù)據(jù)M33 的實(shí)時(shí)任務(wù)會(huì)被嚴(yán)重拖延。4.2 共享內(nèi)存與vring郵箱和消息池是兩回事把共享內(nèi)存的布局設(shè)計(jì)好OpenAmp 就成功了一半。我習(xí)慣把共享區(qū)域分成兩層第一層是resource table里面保存了 vring 的描述信息以及各端點(diǎn)需要的共享緩沖。第二層是 vring 本身它由多個(gè)描述符組成每個(gè)描述符指向真正的數(shù)據(jù) buffer。一個(gè)常見問題是vring 的地址沒有在 DTS 和 resource table 之間保持一致。Linux remoteproc 驅(qū)動(dòng)啟動(dòng) M33 時(shí)會(huì)從 resource table 讀 vring 地址再與 DTS 中的配置比對(duì)。如果兩邊對(duì)不上要么通信掛起要么握手失敗。不要相信“看起來差不多”的地址直接用十六進(jìn)制逐字節(jié)核對(duì)。還有一個(gè)容易被忽略的細(xì)節(jié)共享內(nèi)存區(qū)域的 cache 屬性。前文提到過no-map實(shí)際使用中還要明確這段內(nèi)存是配置成 cacheable 還是 non-cacheable。為了最簡(jiǎn)單的穩(wěn)定性我通常把 vring 和共享 buffer 標(biāo)記為 non-cacheable。這樣省去了手動(dòng) cache 操作的復(fù)雜度代價(jià)是訪問共享內(nèi)存的速度稍慢。對(duì)于 RPMsg 這種小報(bào)文場(chǎng)景性能完全能接受。如果一定要用 cacheable就必須在每次發(fā)送前做 clean接收前做 invalidate否則會(huì)出現(xiàn)“對(duì)方明明寫了數(shù)據(jù)我卻讀到舊值”的問題。4.3 從Linux側(cè)發(fā)起通信rproc_boot與rpmsg_client_sampleLinux 側(cè)內(nèi)核的 remoteproc 子系統(tǒng)負(fù)責(zé)管理 M33 生命周期。啟動(dòng) M33echo start /sys/class/remoteproc/remoteproc0/state停止 M33echo stop /sys/class/remoteproc/remoteproc0/state啟動(dòng)成功后Linux 下會(huì)多出一個(gè)/dev/rpmsg0設(shè)備節(jié)點(diǎn)。應(yīng)用程序可以像普通設(shè)備文件一樣打開它、讀寫數(shù)據(jù)。官方內(nèi)核里有一個(gè)rpmsg_client_sample模塊加載后會(huì)自動(dòng)創(chuàng)建一個(gè)端點(diǎn)往 M33 發(fā)一條消息然后等待回應(yīng)。這個(gè) Sample 是驗(yàn)證整條鏈路最好的工具modprobe rpmsg_client_sample如果 M33 側(cè)的 FreeRTOS 例程已經(jīng)跑起來但rpmsg_client_sample沒反應(yīng)多半是 vring 地址不對(duì)、共享內(nèi)存 cache 配置不一致或者 M33 側(cè)根本沒有注冊(cè)對(duì)應(yīng)的服務(wù)端點(diǎn)。4.4 M33側(cè)循環(huán)收發(fā)拷貝策略與中斷回包M33 側(cè)收到 RPMsg 消息后回調(diào)函數(shù)會(huì)被 OpenAmp 庫調(diào)用。這個(gè)回調(diào)是在什么上下文里執(zhí)行的根據(jù)官方例程通常是在 OpenAmp 自己的接收任務(wù)里或者在一個(gè)由信箱中斷觸發(fā)的傘形中斷中。無論哪種都不應(yīng)該在里面做耗時(shí)操作。正確做法是回調(diào)函數(shù)里把數(shù)據(jù)拷貝到自己的任務(wù)緩沖然后通知業(yè)務(wù)任務(wù)去處理。這里有個(gè)取舍拷貝會(huì)帶來額外開銷但換來的是任務(wù)調(diào)度更加解耦。如果控制數(shù)據(jù)只有幾十字節(jié)拷貝幾乎可以忽略如果是大數(shù)據(jù)塊你也可以只拷貝指針但前提是發(fā)送方在收到 ACK 前不能重用這塊緩沖區(qū)。為了降低復(fù)雜度我初期一直是直接拷貝穩(wěn)定優(yōu)先。另外要注意M33 收到消息后如果需要回復(fù) Linux應(yīng)該在發(fā)送完成后調(diào)用一次緩存清理操作確保 Linux 能讀到最新數(shù)據(jù)。RPMsg 的發(fā)送函數(shù)rpm_send內(nèi)部一般會(huì)做必要的 cache 處理但如果你在回調(diào)里直接操作共享內(nèi)存還是要自己把關(guān)。5. 真機(jī)聯(lián)調(diào)階段踩過的坑每一個(gè)都值得記下來5.1 現(xiàn)象M33內(nèi)核崩潰但Linux毫無察覺第一次跑通 OpenAmp 后我給 M33 加了一個(gè)比較復(fù)雜的控制任務(wù)結(jié)果發(fā)現(xiàn) M33 側(cè)代碼進(jìn)入 HardFault但 Linux 側(cè)毫不知情。A35 的 remoteproc 驅(qū)動(dòng)不會(huì)主動(dòng)監(jiān)測(cè) M33 是否還活著它只負(fù)責(zé)啟動(dòng)和停止。M33 死了Linux 上的/dev/rpmsg0依然存在但收不到任何響應(yīng)。排查時(shí)我一開始以為是 FreeRTOS 里的任務(wù)棧溢出就把configCHECK_FOR_STACK_OVERFLOW打開也加了棧水印打印。后來發(fā)現(xiàn)問題出在一個(gè)定時(shí)器中斷服務(wù)函數(shù)里我在中斷里訪問了一處被 Linux 占用的外設(shè)寄存器M33 總線上直接報(bào)錯(cuò)進(jìn)入 HardFault。這種問題最坑的地方在于M33 的 HardFault 如果不處理整個(gè) M33 就“死寂”了而 Linux 側(cè)只能通過它的心跳超時(shí)才能發(fā)現(xiàn)。所以聯(lián)調(diào)初期M33 側(cè)一定要加上故障打印并且把 HardFault_Handler 里記錄的關(guān)鍵寄存器通過串口輸出。否則出了問題你根本不知道是任務(wù)調(diào)度崩了還是外設(shè)訪問違例。5.2 現(xiàn)象OpenAMP握手失敗rpmsg創(chuàng)建不了端點(diǎn)第二個(gè)坑是 OpenAmp 的握手失敗。Linux 側(cè)rpmsg_client_sample加載后/dev/rpmsg0雖然創(chuàng)建了但 M33 側(cè)一直沒有日志輸出也不回包。我一開始重新編譯了固件檢查了 endpoint 注冊(cè)順序問題依舊。后來用調(diào)試器掛在共享內(nèi)存上查看 resource table 的內(nèi)容才發(fā)現(xiàn) vring 地址和 DTS 里預(yù)設(shè)的地址差了幾百字節(jié)。原因是我改了鏈接腳本M33 固件里的 resource table 被編譯器重新排版了但 DTS 里的 reserved-memory 還是舊地址。兩邊各自都“對(duì)”就是互相不對(duì)。這里給新手一個(gè)建議不要手動(dòng)修改 resource table 的存放位置除非你完全理解 OpenAmp 的加載流程。在任何一次鏈接腳本調(diào)整后都要重新生成 resource table并和設(shè)備樹比對(duì)。5.3 現(xiàn)象printf打印影響實(shí)時(shí)性M33 側(cè)調(diào)試時(shí)很多人習(xí)慣在任務(wù)里加 printf。這個(gè)思維是從 MCU 開發(fā)帶來的但在 MP257 上要特別小心。M33 的 printf 如果走串口而串口驅(qū)動(dòng)在 FreeRTOS 里用了阻塞式發(fā)送遇到波特率 115200 時(shí)一條幾十字節(jié)的日志就要占掉幾毫秒。對(duì)于 20kHz 的控制周期這是災(zāi)難。我的做法是聯(lián)調(diào)階段把 printf 重定向到共享內(nèi)存里的一個(gè)環(huán)型日志區(qū)Linux 側(cè)隨時(shí)讀取。正式運(yùn)行階段把調(diào)試 printf 用宏關(guān)掉只保留錯(cuò)誤級(jí)別日志。這樣既不影響實(shí)時(shí)性又能完整復(fù)現(xiàn)現(xiàn)場(chǎng)。5.4 調(diào)試手段用Linux的/dev/rpmsg0和M33的log互相印證AMP 聯(lián)調(diào)最大的痛苦是“兩邊都覺得對(duì)方?jīng)]發(fā)數(shù)據(jù)”。我的經(jīng)驗(yàn)是建立一套雙向的“回環(huán)測(cè)試”再開始業(yè)務(wù)邏輯開發(fā)。先讓 M33 收到什么就回什么然后在 Linux 側(cè)寫一個(gè)簡(jiǎn)單腳本往/dev/rpmsg0發(fā)一串遞增數(shù)據(jù)接收端校驗(yàn)是否原樣返回。跑通回環(huán)后再逐步加入業(yè)務(wù)。如果回環(huán)都過不了問題一定在底層資源配置或緩存一致性上不要往下寫業(yè)務(wù)。M33 側(cè)也要把日志做成“有向心跳”每收到一條消息就通過串口輸出一個(gè)序號(hào)。這樣即使沒有調(diào)試器也能確認(rèn) OpenAmp 的接收鏈路是通的。我實(shí)測(cè)下來這套方法能過濾掉八成以上的“疑似通信問題”。6. 量產(chǎn)前必須補(bǔ)上的收尾工作6.1 監(jiān)控M33心跳光靠watchdog不夠M33 側(cè)跑 FreeRTOS通常都會(huì)開一個(gè)獨(dú)立看門狗防止任務(wù)死鎖。但看門狗只能“發(fā)現(xiàn)死機(jī)后復(fù)位”恢復(fù)后 Linux 側(cè)怎么知道 M33 已經(jīng)重啟過這是量產(chǎn)前必須設(shè)計(jì)的。我建議在 Linux 側(cè)寫一個(gè)應(yīng)用周期性通過 RPMsg 向 M33 發(fā)送心跳查詢M33 在最高優(yōu)先級(jí)任務(wù)里回應(yīng)。如果連續(xù)若干次沒有回應(yīng)Linux 主動(dòng)stopstartM33。這樣 M33 即使崩潰也能在無人工介入的情況下自動(dòng)恢復(fù)。注意這個(gè)機(jī)制不能依賴簡(jiǎn)單的一問一答建議在心跳報(bào)文里帶序列號(hào)用于發(fā)現(xiàn) M33 是否發(fā)生過重啟。M33 側(cè)同樣要監(jiān)控 Linux 側(cè)的心跳。若 Linux 側(cè)卡死或者重啟M33 要能做安全保護(hù)比如把執(zhí)行機(jī)構(gòu)歸到安全位置。異構(gòu)系統(tǒng)不能只保護(hù)單側(cè)兩側(cè)都要有“對(duì)方可能死掉”的意識(shí)。6.2 低功耗時(shí)別忘了M33的電源域MP257 的功耗管理是個(gè)大話題A35 側(cè)的 Linux 有 CPUFreq、CPUIdleM33 側(cè)也有自己的低功耗模式。M33 進(jìn)入 Deep Sleep 前必須關(guān)閉對(duì)共享內(nèi)存的訪問并讓 Linux 側(cè)的 remoteproc 先處于停止?fàn)顟B(tài)。我踩過的坑是Linux 側(cè)進(jìn)入 suspendM33 還掛在共享內(nèi)存上結(jié)果喚醒后共享數(shù)據(jù)區(qū)出現(xiàn)撕裂。正確的順序是先讓 M33 進(jìn)入低功耗等待命令狀態(tài)再讓 Linux 進(jìn)入 suspend喚醒時(shí)反過來Linux 先恢復(fù)正常再喚醒 M33。整個(gè)流程要用 RPMsg 做一個(gè)握手協(xié)議不能用簡(jiǎn)單延時(shí)“估摸”對(duì)方已經(jīng)完成。6.3 日志規(guī)范與遠(yuǎn)程升級(jí)的邊界M33 固件和 Linux 內(nèi)核是兩套獨(dú)立鏡像量產(chǎn)后的升級(jí)鏈路也完全不同。Linux 側(cè)可以通過 A/B 分區(qū)做系統(tǒng)級(jí) OTAM33 固件則需要設(shè)計(jì)自己的升級(jí)機(jī)制常見做法是由 Linux 側(cè)把新固件下載到某個(gè)分區(qū)再通過 remoteproc 停止 M33、寫入新固件、重新啟動(dòng)。升級(jí)過程中最怕兩件事一是升級(jí)到一半掉電M33 固件損壞二是新舊固件的資源表不兼容導(dǎo)致 OpenAmp 通信失敗。對(duì)第一個(gè)問題建議 M33 固件保留一個(gè)極小 Bootloader負(fù)責(zé)校驗(yàn) App 固件對(duì)第二個(gè)問題建議在 RPMsg 應(yīng)用層約定版本號(hào)Linux 啟動(dòng) M33 后先做版本握手版本不匹配直接拒絕業(yè)務(wù)。這些在項(xiàng)目初期就要定好量產(chǎn)后再改協(xié)議非常痛苦。6.4 實(shí)測(cè)性能參考與后續(xù)擴(kuò)展拿我們實(shí)際項(xiàng)目的數(shù)據(jù)做個(gè)參考A35 雙核跑 LinuxM33 跑 FreeRTOSOpenAmp 通過 RPMsg 每 1ms 雙向交換一條 64 字節(jié)狀態(tài)幀。M33 側(cè)額外跑著三個(gè)任務(wù)分別是 1kHz 控制循環(huán)、按鍵掃描、串口日志。整條鏈路跑下來RPMsg 單次收發(fā)的 CPU 占用和中斷延遲都在可接受范圍內(nèi)。如果業(yè)務(wù)需要更大帶寬可以考慮把共享緩沖區(qū)加大或使用帶 cache 的訪問模式但務(wù)必做好緩存一致性處理。后續(xù)擴(kuò)展方向上可以考慮讓 M33 直接承擔(dān)一部分傳感器數(shù)據(jù)預(yù)處理只把提煉后的結(jié)果發(fā)給 A35。也可以嘗試把部分網(wǎng)絡(luò)協(xié)議棧卸載到 Linux把實(shí)時(shí)安全策略放在 M33。這個(gè)平臺(tái)最大的魅力就在于此兩顆核各司其職又共用一套內(nèi)存。對(duì)我個(gè)人而言用過 MP257 的 M33 FreeRTOS OpenAmp 組合后再回到“外掛 MCU 串口”的老路確實(shí)回不去了。