RTOS与Linux融合,是嵌入式行业的大趋势

RTOS与Linux的操作系统之争已经持续了很多年，目前RTOS和Linux之间的差距已经越来越小。

而实际上，很多场景下，RTOS和Linux存在互补关系，并且很难权衡。那么这种情况下，厂商给出了一种解决方案，那就是“我都要”。

在硬件上异构Cortex-A核和Cortex-M/R核，并通过非对称多处理器启动（AMP）来同时运行RTOS和Linux。

众所周知，目前处理器的职责是根据功能划分的，比如Cortex-A核一般基于Linux系统实现用户界面，Cortex-M或Cortex-R核则偏向于实时的嵌入式RTOS系统。现代许多SoC或MPU都开始采用多CPU核异构，甚至是RISC-V和Arm核的异构。

为了让这些核心高效处理不同工作负载，目前软件上多核处理器有三种运行模式：

• AMP（Asymmetric multiprocessing，非对称多处理）

提供与传统单核处理器系统相似的执行环境，是大多数开发人员熟悉的模式，因此为遗留代码移植提供了相对简便的路径。提供控制CPU核心使用方式的直接机制，在大多数情况下，开发人员可使用标准调试工具与技术开展工作。此外在运行裸机程序时，几乎没有开销，非常适合实时性高的应用。

AMP分为“同构”与“异构”两种：同构AMP中，每个核心运行相同类型与版本的操作系统，开发人员可选择支持分布式编程模型的操作系统，以充分利用多核心性能；异构AMP中，每个核心运行不同操作系统，或同一操作系统不同版本，在此场景下，开发人员要么需实现专有通信方案，要么需选择两个共享通用处理器间通信基础设施的操作系统，为避免资源冲突，这些操作系统还应提供访问共享硬件组件的标准化机制。

• SMP（Symmetric multiprocessing，对称多处理）

在多核设计中，资源分配可能颇具挑战。SMP通过在芯片所有核心上运行同一种操作系统，所有核心间IPC均为“本地通信”，减少内存占用并且大幅度提升性能，同时系统不再需要复杂网络协议实现通信。由于操作系统能实时掌握所有系统元素的状态，无需应用设计人员过多干预，即可在多个核心上分配资源。若操作系统具备完善的抢占机制与线程优先级管理能力，还能帮助应用设计人员确保CPU周期优先分配给最需要的应用。

目前，我们使用的x86 PC就采用的这种机制，但代价就是这种系统一般适用于功能复杂的系统，对实时性要求很高的系统并不太适用。虽然通过在单一Linux内核上通过PREEMPT_RT补丁，可以实现近似RTOS的确定性响应，但极端场景下依然不如RTOS。

• BMP（Bound multiprocessin，受约束多处理）

这是QNX首创的一种多处理模式，运行模式类似SMP，具有“透明资源管理”的优势，同时允许设计人员将任意应用（及其所有线程）锁定到特定核心，从而助力单核代码向多核环境迁移。与SMP类似，单个操作系统副本会全局掌控所有系统资源，实现资源在应用间动态分配与共享。但在应用初始化阶段，系统设计人员可通过设置，强制应用的所有线程仅在指定核心上执行。

AMP是异构计算的重要方案，特别对工业、汽车电子、智能终端来说，非常好用。

• 通过将任务分配给专属处理上下文，开发人员能构建性能可预测、延迟低、可靠性高的高效系统，兼顾复杂功能和实时需求；

• 由于每个处理器拥有自己的内存，所以核心之间互不干扰，核心之间独立且无需频繁交换数据，所以系统稳定性更高，可以减少崩溃风险；

• 通过优化内部通信，仅需一套硬件电路即可实现复杂功能，显著降低系统硬件成本。其各核心能运行不同操作系统，并行处理多任务，无需额外硬件支持，高效且经济。

目前，很多SoC芯片都原生支持AMP，如德州仪器（TI）Sitara系列、恩智浦（NXP）i.MX系列、意法（ST）STM32MP1系列、AMD（赛灵思）Zynq系列等。国内瑞芯微、赛昉科技等厂商也提供了原生支持AMP的芯片，同时释放官方例程，教学如何运行RTOS和Linux。

TI的系统主要采用TI-RTOS+Linux SDK+IPC机制（MessageQ、NameServer）。TI表示，在嵌入式Linux系统上处理诸如 IO-Link之类的实时通信会是一项挑战。在Linux用户空间中，无法在µs范围内以确定性计时读写外设（如UART）。Linux调度程序并不适合此类应用，并且还必须处理其他任务。调度程序会导致计时抖动（具体情况取决于CPU负载），进而无法实现实时通信。

另一种方法是集成到Linux内核中。在内核空间中，高分辨率计时器可产生只能被另一个内核计时器或硬件外设阻止的精确计时。在这种情况下，抖动优于用户空间实现方式，但是其仍然存在。另外，将复杂的堆栈移入内核空间也并不总是一种良好设计做法。

第三种选择是使用单独的处理器内核来处理实时通信。就比如Sitara AM5728 SoC 除了拥有两个Cortex-A15内核外，还具有多个Cortex-M4 内核,可将严格计时部分卸载，而A15和M4之间会建立非关键通信链路以用于交换数据。

Microchip在去年推出了64位RISC-V MPU PIC64GX，其由一颗E51核心（支持 RV64IMAC指令集，专用核心）与四颗U54应用核心（支持RV64GC指令集，用于通用计算）组成，可配置为运行最多两个独立的软件上下文，先进的内存管理模块，包括虚拟内存（Virtual Memory）与 2 MiB 大小的二级内存子系统（L2 Memory Subsystem），且支持 SECDEC（安全解密）功能：16路组相联缓存、松散集成内存（LIM）与暂存内存（Scratchpad Memory）；LIM内存可专属分配给单个或多个核心，且可按缓存路（128 KiB 为单位）调整大小。

Microchip也展示了AMP配置方法。例如，可在3颗U54核心上运行Linux，在剩余1颗U54核心上运行Zephyr RTOS；此外，外设也可分配给任一上下文。

开放式非对称多处理（OpenAMP）是行业标准软件框架，提供开发AMP系统软件应用所需的组件。通过支持RemoteProc（远程处理器）与RPMsg（远程处理器消息协议）等 OpenAMP软件接口，PIC64GX上跨两个AMP上下文的工作负载可轻松实现相互通信。以下是OpenAMP的核心软件接口：

• RPMsg框架：PIC64GX设备上用于核心间 / 上下文间通信的机制；

• RemoteProc框架：允许主Linux上下文控制（启动、加载固件、关闭）从上下文。

赛昉科技（StarFive）的新一代SoC平台昉·惊鸿-7110在官方例程中，演示了如何用3个CPU跑Linux操作系统、1个CPU跑RT-Thread的双系统AMP架构。

其中在RTOS的CPU运行实时的进程，并把部分实时驱动运行在RTOS中进行数据采集，同时把数据通过共享内存方式发回到Linux上，Linux端可以运行各种非实时的应用程序。这种方式可以使系统既保证实时性，又能使用Linux通用操作系统运行功能强大的应用。这已成为工业系统中一种重要架构。

这种方式可以解决RT-Linux无法达到最大调度延时15us以内的棘手问题，在昉·惊鸿-7110中，运行RTOS的CPU Core主频可以跑1.5GHz， 最大调度延时可以跑到15us以内。 

瑞芯微的RK3568及相关开发板也支持AMP双系统，分为两个方案：

第一，Arm（Linux） + RISC-V（Baremetal）方案。该方案巧妙结合了Arm架构的高性能与RISC-V的灵活性，为各类应用提供了强大的平台支持。Arm核心运行Linux操作系统，作为主核承担整个多核异构系统中共享资源的划分和管理的工作，而RISC-V核心作为从核则运行Baremetal程序，专注于实时或专用任务的处理。

这种分工协作模式，使得Arm端能够高效处理复杂的计算任务和系统管理，同时利用RISC-V端的灵活设计，满足特定场景下对硬件资源的定制化需求。通过优化资源分配，该方案有效降低了硬件成本，为电力继电保护装置、工业自动化等场景提供了高效且经济的解决方案。

第二，Arm（Linux） + Arm（Baremetal/RTOS）方案。在这个方案中，运行Linux的Arm核心作为主核，负责系统中共享资源的分配和管理。运行RTOS/Bare-metal的Arm核心作为从核，专注于实时任务的执行。这种同构多核搭配不同运行环境的方式，既能充分发挥Arm架构的性能优势，又能满足系统对实时性任务的处理需求，适用于对实时性和系统资源管理要求较高的应用场景。

虽然通过AMP，现有RTOS与Linux可以同时在不同核心上运行。但在当前发展阶段，相关领域面临着三方面显著挑战：其一，通信机制的标准化程度不足，由于各厂商多采用自定义接口且差异较大，不仅增加了调试工作的复杂度，还存在跨域调试工具不够完善的问题，进一步影响了开发效率；其二，安全隔离需求突出，需要重点防范 RTOS（实时操作系统）被 Linux 系统入侵，以保障系统整体的安全性与稳定性；其三，固件升级机制尚未形成统一方案，不同设备或系统的升级流程、标准存在差异，给后续的维护与更新带来了不便。

从未来趋势来看，首先，硬件架构将向更高集成度的MCU+MPU方向迈进，通过集成化设计提升系统性能与兼容性；其次，AI任务的轻量化部署成为重要方向，AIRTOS技术可实现将轻量级AI任务在M核侧完成，既能满足AI应用需求，又能降低系统资源消耗；再者，软件构建工具的支持能力将进一步增强；最后，自动化测试与 CI/CD（持续集成/持续部署）体系将逐步完善，为AMP架构提供更全面的支持，推动开发、测试、部署全流程的高效化与标准化。