非對稱多處理架構的興起與核心挑戰
在當前嵌入式系統單晶片（SoC）的設計趨勢中，單一架構的處理器已難以同時兼顧高效能運算與極低延遲的即時控制。為了解決這項矛盾，業界廣泛採用非對稱多處理（Asymmetric Multiprocessing，簡稱 AMP）架構。在這種系統架構下，高運算能力的多核心應用處理器通常負責執行 Linux 作業系統以處理複雜的應用邏輯，而架構較輕量、著重確定性反應時間的微控制器或即時核心（如運行 Zephyr 作業系統的核心）則整合於同一顆晶片中，專門負責處理即時控制任務。
根據 InfoQ 的技術報導，資深 Linux 核心開發者兼 I2C 子系統維護者 Wolfram Sang 於 2026 年歐洲嵌入式 Linux 大會（Embedded Linux Conference Europe）上，針對 Linux 支援 AMP 的基礎架構進行了全面檢視。Sang 指出，Linux 核心在 AMP 領域所建立的各項軟體積木已經具備穩固的架構基礎，足以支撐複雜系統的運作；然而，這套架構正面臨貢獻者基礎薄弱、維護人力集中以及跨平台測試零碎分散的隱憂。這項觀察源於他嘗試向核心上游提交硬體自旋鎖（hardware-spinlock）驅動程式的實務經驗，進而促使他深入檢視整個 Linux AMP 技術堆疊的健康狀態。
Linux AMP 關鍵通訊層與運作機制解析
要在同一個晶片內讓 Linux 與即時核心協同工作，核心軟體堆疊必須建立清晰的分工與溝通管道。最基礎的運作方式是透過共享記憶體（如內部靜態隨機存取記憶體 SRAM 或系統動態記憶體 DDR）來承載資料，並搭配郵箱機制（Mailbox）作為中斷通知信號。郵箱本質上是一種硬體中斷機制，通常扮演單向門鈴（doorbell）的角色，用來通知另一端的處理器已有待處理的資料就緒。
在管理與資料交換層次上，Linux 核心仰賴多個相互協同的子系統。首先是遠端處理器控制框架（remoteproc），其主要功能在於負責遠端核心的生命週期管理，包含載入韌體映像檔、啟動或停止遠端核心，並解析韌體二進位檔案中所宣告的資源需求清單。當遠端核心就緒後，系統便能建立遠端處理器訊息傳遞機制（RPMsg），這是一種基於共享記憶體與驅動程式回呼函式的雙向通訊協定，專門用來在相異處理器之間傳輸訊息。
此外，虛擬化輸入輸出標準（Virtio）透過共享記憶體中的虛擬佇列（virtqueues）提供了通用的資料交換規範，使非對稱核心能夠以標準化介面交換大量資料。Sang 在演講中特別釐清了架構邊界，指出 RPMsg 是專為處理器間通訊量身打造的機制，而社群中討論的訊息通道傳輸 Virtio（virtio-over-message transport）則是將 Virtio 流量封裝於訊息通道中的新興提案，該機制尚未被合併進 Linux 核心上游。
硬體與韌體整合中的隱性複雜度
當多個獨立核心同時運作於同一晶片時，更複雜的挑戰在於共享資源的仲裁與管理。為了避免 Linux 與即時核心各自獨立控制相同的底層硬體導致衝突，系統通常採用系統控制與管理介面（System Control and Management Interface，簡稱 SCMI）。SCMI 定義了一套標準化協定，讓 Linux 核心能夠將時脈、供電與重設等硬體資源的管理權責，委託給專屬的系統控制處理器統一調配，而非由 Linux 直接操作底層暫存器。
然而，實際的硬體與韌體實作往往遠比概念架構圖複雜。Sang 說明，硬體門鈴中斷本質上是單向的，若要建立一個基本的「請求與回應」通道，就需要兩個單向郵箱相互搭配；如果需要建立完整且具備雙向主動通知與確認機制的 SCMI 架構，硬體甚至可能需要配置多達四個獨立郵箱通道。
更棘手的問題在於既有晶片韌體的設計限制。Sang 以德州儀器的 Keystone 架構為例，該平台的既有韌體僅使用兩個單向郵箱來維持雙向 SCMI 通訊，這導致系統在發出事件通知時，缺乏對等的反向確認路徑。這種底層硬體與韌體實作上的落差，使得 Linux 核心必須在抽象架構與特定晶片現實之間妥協，大幅增加了軟體堆疊的調適難度。
子系統維護現況與開發者社群生態分析
Sang 透過數據深入調查了 Linux 核心中 AMP 相關子系統的發展現況。數據顯示，負責核心生命週期的 remoteproc 子系統，其核心程式碼提交數量從 Linux 5.0 版本的 175 次成長至約 1,550 次，顯示出早期的爆發性成長，但近期的推進步調已逐漸趨於平緩。
在硬體中斷通知的 Mailbox 子系統方面，雖然近期的驅動程式數量持續增加，但整體的程式碼維護人力極為單薄，長期以來只有大約四位開發者貢獻過五個以上的程式碼補丁。最為冷門的則是硬體自旋鎖（hardware-spinlock）子系統，這項用於跨異質核心進行底層硬體資源互斥鎖定的關鍵機制，其核心程式碼提交數量在長達七年的時間內僅從 19 次微幅增加至 30 次，且支援的驅動程式數量幾乎長期停滯。
這種生態現象並不意味著相關模組存在嚴重缺陷，而是揭示了核心維護者面臨的高昂負擔。Sang 以自身開發硬體自旋鎖驅動程式為例，表面看似單純的驅動程式提交，實務上卻牽動了核心標頭檔重構、物件生命週期管理等深層結構問題；當開發者試圖加入除錯功能時，還可能踩到已被標記為廢棄的核心內部應用介面（API）。
測試斷層與未來實務發展的關鍵瓶頸
阻礙 AMP 技術健康發展的另一個關鍵瓶頸在於驗證環境的高度破碎化。在傳統的 Linux 驅動程式開發中，單元測試與回歸測試通常能透過模擬器或標準硬體完成；然而，驗證 AMP 相關驅動程式往往需要高度客製化的韌體映像檔與經過修改的開機載入程式 U-Boot，開發者光是為了讓硬體進入能夠測試驅動程式的狀態，就必須付出極大的先期配置成本。
雖然開放原始碼社群推動了 OpenAMP 計畫，試圖為異質架構提供標準化的建置指南與測試案例，但其實際表現仍有待加強。Sang 指出，OpenAMP 現有的測試範例尚無法在所有支援的開發板上維持一致且穩定的執行結果。
總結而言，Linux 在非對稱多處理領域已經擁有堅實的概念架構與運作基礎，包括 remoteproc、RPMsg 以及 SCMI 等元件均展現了成熟的系統設計思維。然而，隨著未來晶片設計對非對稱多處理的依賴程度日益加深，若要維持這些複雜系統的長期穩定，整個產業與開源社群必須正視審查人力不足與測試環境零碎的現實，投入更多資源降低跨平台測試的阻力，才能確保 Linux 在異質運算時代持續扮演穩定的核心支柱。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。