RTOS與Linux融合，是嵌入式行業(yè)的大趨勢

RTOS與Linux的操作系統(tǒng)之爭已經(jīng)持續(xù)了很多年，目前RTOS和Linux之間的差距已經(jīng)越來越小。

而實際上，很多場景下，RTOS和Linux存在互補關(guān)系，并且很難權(quán)衡。那么這種情況下，廠商給出了一種解決方案，那就是“我都要”。

在硬件上異構(gòu)Cortex-A核和Cortex-M/R核，并通過非對稱多處理器啟動（AMP）來同時運行RTOS和Linux。

看懂多核的AMP啟動

眾所周知，目前處理器的職責(zé)是根據(jù)功能劃分的，比如Cortex-A核一般基于Linux系統(tǒng)實現(xiàn)用戶界面，Cortex-M或Cortex-R核則偏向于實時的嵌入式RTOS系統(tǒng)。現(xiàn)代許多SoC或MPU都開始采用多CPU核異構(gòu)，甚至是RISC-V和Arm核的異構(gòu)。

為了讓這些核心高效處理不同工作負載，目前軟件上多核處理器有三種運行模式：

• AMP（Asymmetric multiprocessing，非對稱多處理）

提供與傳統(tǒng)單核處理器系統(tǒng)相似的執(zhí)行環(huán)境，是大多數(shù)開發(fā)人員熟悉的模式，因此為遺留代碼移植提供了相對簡便的路徑。提供控制CPU核心使用方式的直接機制，在大多數(shù)情況下，開發(fā)人員可使用標準調(diào)試工具與技術(shù)開展工作。此外在運行裸機程序時，幾乎沒有開銷，非常適合實時性高的應(yīng)用。

AMP分為“同構(gòu)”與“異構(gòu)”兩種：同構(gòu)AMP中，每個核心運行相同類型與版本的操作系統(tǒng)，開發(fā)人員可選擇支持分布式編程模型的操作系統(tǒng)，以充分利用多核心性能；異構(gòu)AMP中，每個核心運行不同操作系統(tǒng)，或同一操作系統(tǒng)不同版本，在此場景下，開發(fā)人員要么需實現(xiàn)專有通信方案，要么需選擇兩個共享通用處理器間通信基礎(chǔ)設(shè)施的操作系統(tǒng)，為避免資源沖突，這些操作系統(tǒng)還應(yīng)提供訪問共享硬件組件的標準化機制。

• SMP（Symmetric multiprocessing，對稱多處理）

在多核設(shè)計中，資源分配可能頗具挑戰(zhàn)。SMP通過在芯片所有核心上運行同一種操作系統(tǒng)，所有核心間IPC均為“本地通信”，減少內(nèi)存占用并且大幅度提升性能，同時系統(tǒng)不再需要復(fù)雜網(wǎng)絡(luò)協(xié)議實現(xiàn)通信。由于操作系統(tǒng)能實時掌握所有系統(tǒng)元素的狀態(tài)，無需應(yīng)用設(shè)計人員過多干預(yù)，即可在多個核心上分配資源。若操作系統(tǒng)具備完善的搶占機制與線程優(yōu)先級管理能力，還能幫助應(yīng)用設(shè)計人員確保CPU周期優(yōu)先分配給最需要的應(yīng)用。

目前，我們使用的x86 PC就采用的這種機制，但代價就是這種系統(tǒng)一般適用于功能復(fù)雜的系統(tǒng)，對實時性要求很高的系統(tǒng)并不太適用。雖然通過在單一Linux內(nèi)核上通過PREEMPT_RT補丁，可以實現(xiàn)近似RTOS的確定性響應(yīng)，但極端場景下依然不如RTOS。

• BMP（Bound multiprocessin，受約束多處理）

這是QNX首創(chuàng)的一種多處理模式，運行模式類似SMP，具有“透明資源管理”的優(yōu)勢，同時允許設(shè)計人員將任意應(yīng)用（及其所有線程）鎖定到特定核心，從而助力單核代碼向多核環(huán)境遷移。與SMP類似，單個操作系統(tǒng)副本會全局掌控所有系統(tǒng)資源，實現(xiàn)資源在應(yīng)用間動態(tài)分配與共享。但在應(yīng)用初始化階段，系統(tǒng)設(shè)計人員可通過設(shè)置，強制應(yīng)用的所有線程僅在指定核心上執(zhí)行。

AMP是異構(gòu)計算的重要方案，特別對工業(yè)、汽車電子、智能終端來說，非常好用。

• 通過將任務(wù)分配給專屬處理上下文，開發(fā)人員能構(gòu)建性能可預(yù)測、延遲低、可靠性高的高效系統(tǒng)，兼顧復(fù)雜功能和實時需求；

• 由于每個處理器擁有自己的內(nèi)存，所以核心之間互不干擾，核心之間獨立且無需頻繁交換數(shù)據(jù)，所以系統(tǒng)穩(wěn)定性更高，可以減少崩潰風(fēng)險；

• 通過優(yōu)化內(nèi)部通信，僅需一套硬件電路即可實現(xiàn)復(fù)雜功能，顯著降低系統(tǒng)硬件成本。其各核心能運行不同操作系統(tǒng)，并行處理多任務(wù)，無需額外硬件支持，高效且經(jīng)濟。

一些典型的平臺

目前，很多SoC芯片都原生支持AMP，如德州儀器（TI）Sitara系列、恩智浦（NXP）i.MX系列、意法（ST）STM32MP1系列、AMD（賽靈思）Zynq系列等。國內(nèi)瑞芯微、賽昉科技等廠商也提供了原生支持AMP的芯片，同時釋放官方例程，教學(xué)如何運行RTOS和Linux。

TI的系統(tǒng)主要采用TI-RTOS+Linux SDK+IPC機制（MessageQ、NameServer）。TI表示，在嵌入式Linux系統(tǒng)上處理諸如 IO-Link之類的實時通信會是一項挑戰(zhàn)。在Linux用戶空間中，無法在μs范圍內(nèi)以確定性計時讀寫外設(shè)（如UART）。Linux調(diào)度程序并不適合此類應(yīng)用，并且還必須處理其他任務(wù)。調(diào)度程序會導(dǎo)致計時抖動（具體情況取決于CPU負載），進而無法實現(xiàn)實時通信。

另一種方法是集成到Linux內(nèi)核中。在內(nèi)核空間中，高分辨率計時器可產(chǎn)生只能被另一個內(nèi)核計時器或硬件外設(shè)阻止的精確計時。在這種情況下，抖動優(yōu)于用戶空間實現(xiàn)方式，但是其仍然存在。另外，將復(fù)雜的堆棧移入內(nèi)核空間也并不總是一種良好設(shè)計做法。

第三種選擇是使用單獨的處理器內(nèi)核來處理實時通信。就比如Sitara AM5728 SoC 除了擁有兩個Cortex-A15內(nèi)核外，還具有多個Cortex-M4 內(nèi)核,可將嚴格計時部分卸載，而A15和M4之間會建立非關(guān)鍵通信鏈路以用于交換數(shù)據(jù)。

Microchip在去年推出了64位RISC-V MPU PIC64GX，其由一顆E51核心（支持 RV64IMAC指令集，專用核心）與四顆U54應(yīng)用核心（支持RV64GC指令集，用于通用計算）組成，可配置為運行最多兩個獨立的軟件上下文，先進的內(nèi)存管理模塊，包括虛擬內(nèi)存（Virtual Memory）與 2 MiB 大小的二級內(nèi)存子系統(tǒng)（L2 Memory Subsystem），且支持 SECDEC（安全解密）功能：16路組相聯(lián)緩存、松散集成內(nèi)存（LIM）與暫存內(nèi)存（Scratchpad Memory）；LIM內(nèi)存可專屬分配給單個或多個核心，且可按緩存路（128 KiB 為單位）調(diào)整大小。

Microchip也展示了AMP配置方法。例如，可在3顆U54核心上運行Linux，在剩余1顆U54核心上運行Zephyr RTOS；此外，外設(shè)也可分配給任一上下文。

開放式非對稱多處理（OpenAMP）是行業(yè)標準軟件框架，提供開發(fā)AMP系統(tǒng)軟件應(yīng)用所需的組件。通過支持RemoteProc（遠程處理器）與RPMsg（遠程處理器消息協(xié)議）等 OpenAMP軟件接口，PIC64GX上跨兩個AMP上下文的工作負載可輕松實現(xiàn)相互通信。以下是OpenAMP的核心軟件接口：

• RPMsg框架：PIC64GX設(shè)備上用于核心間 / 上下文間通信的機制；

• RemoteProc框架：允許主Linux上下文控制（啟動、加載固件、關(guān)閉）從上下文。

賽昉科技（StarFive）的新一代SoC平臺昉·驚鴻-7110在官方例程中，演示了如何用3個CPU跑Linux操作系統(tǒng)、1個CPU跑RT-Thread的雙系統(tǒng)AMP架構(gòu)。

其中在RTOS的CPU運行實時的進程，并把部分實時驅(qū)動運行在RTOS中進行數(shù)據(jù)采集，同時把數(shù)據(jù)通過共享內(nèi)存方式發(fā)回到Linux上，Linux端可以運行各種非實時的應(yīng)用程序。這種方式可以使系統(tǒng)既保證實時性，又能使用Linux通用操作系統(tǒng)運行功能強大的應(yīng)用。這已成為工業(yè)系統(tǒng)中一種重要架構(gòu)。

這種方式可以解決RT-Linux無法達到最大調(diào)度延時15us以內(nèi)的棘手問題，在昉·驚鴻-7110中，運行RTOS的CPU Core主頻可以跑1.5GHz， 最大調(diào)度延時可以跑到15us以內(nèi)。

瑞芯微的RK3568及相關(guān)開發(fā)板也支持AMP雙系統(tǒng)，分為兩個方案：

第一，Arm（Linux） + RISC-V（Baremetal）方案。該方案巧妙結(jié)合了Arm架構(gòu)的高性能與RISC-V的靈活性，為各類應(yīng)用提供了強大的平臺支持。Arm核心運行Linux操作系統(tǒng)，作為主核承擔(dān)整個多核異構(gòu)系統(tǒng)中共享資源的劃分和管理的工作，而RISC-V核心作為從核則運行Baremetal程序，專注于實時或?qū)Ｓ萌蝿?wù)的處理。

這種分工協(xié)作模式，使得Arm端能夠高效處理復(fù)雜的計算任務(wù)和系統(tǒng)管理，同時利用RISC-V端的靈活設(shè)計，滿足特定場景下對硬件資源的定制化需求。通過優(yōu)化資源分配，該方案有效降低了硬件成本，為電力繼電保護裝置、工業(yè)自動化等場景提供了高效且經(jīng)濟的解決方案。

第二，Arm（Linux） + Arm（Baremetal/RTOS）方案。在這個方案中，運行Linux的Arm核心作為主核，負責(zé)系統(tǒng)中共享資源的分配和管理。運行RTOS/Bare-metal的Arm核心作為從核，專注于實時任務(wù)的執(zhí)行。這種同構(gòu)多核搭配不同運行環(huán)境的方式，既能充分發(fā)揮Arm 架構(gòu)的性能優(yōu)勢，又能滿足系統(tǒng)對實時性任務(wù)的處理需求，適用于對實時性和系統(tǒng)資源管理要求較高的應(yīng)用場景。

挑戰(zhàn)和未來

雖然通過AMP，現(xiàn)有RTOS與Linux可以同時在不同核心上運行。但在當(dāng)前發(fā)展階段，相關(guān)領(lǐng)域面臨著三方面顯著挑戰(zhàn)：其一，通信機制的標準化程度不足，由于各廠商多采用自定義接口且差異較大，不僅增加了調(diào)試工作的復(fù)雜度，還存在跨域調(diào)試工具不夠完善的問題，進一步影響了開發(fā)效率；其二，安全隔離需求突出，需要重點防范 RTOS（實時操作系統(tǒng)）被 Linux 系統(tǒng)入侵，以保障系統(tǒng)整體的安全性與穩(wěn)定性；其三，固件升級機制尚未形成統(tǒng)一方案，不同設(shè)備或系統(tǒng)的升級流程、標準存在差異，給后續(xù)的維護與更新帶來了不便。

從未來趨勢來看，首先，硬件架構(gòu)將向更高集成度的MCU+MPU方向邁進，通過集成化設(shè)計提升系統(tǒng)性能與兼容性；其次，AI任務(wù)的輕量化部署成為重要方向，AI RTOS技術(shù)可實現(xiàn)將輕量級AI任務(wù)在M核側(cè)完成，既能滿足AI應(yīng)用需求，又能降低系統(tǒng)資源消耗；再者，軟件構(gòu)建工具的支持能力將進一步增強；最后，自動化測試與 CI/CD（持續(xù)集成/持續(xù)部署）體系將逐步完善，為AMP架構(gòu)提供更全面的支持，推動開發(fā)、測試、部署全流程的高效化與標準化。

參考文獻

[1]Microchip：https://ww1.microchip.com/downloads/aemDocuments/documents/MPU64/ProductDocuments/SupportingCollateral/Asymmetric_Multi-Processing_on_PIC64GX_White_Paper.pdf

[2]NXP：https://www.nxp.com/docs/en/brochure/PWRARBYNDBITSRAS.pdf

[3]嵌入式基地：https://zhuanlan.zhihu.com/p/455322207

[4]創(chuàng)龍科技：https://www.tronlong.com/Article/show/346.html

[5]CSDN：https://blog.csdn.net/Interview_TC/article/details/148368172

[6]賽昉科技：https://doc.rvspace.org/VisionFive2/PDF/VisionFive2_RT_Thread.pdf

[7]Promwad：https://promwad.com/news/rtos-linux-amp-systems

歡迎將我們設(shè)為“星標”，這樣才能第一時間收到推送消息。

關(guān)注EEWorld旗下訂閱號：“機器人開發(fā)圈”

回復(fù)“DS”領(lǐng)取《DeepSeek:從入門到精通》完整版

掃碼添加小助手回復(fù)“機器人”

進群和電子工程師們面對面交流經(jīng)驗

*封面圖由AI生成