当前位置：首页>Linux>Linux+RTOS 异构部署

Linux+RTOS 异构部署

2026-09-10 10:15:28

一颗芯片跑两个系统：

Linux+RTOS 异构部署到底解决了什么问题

❥ 如您对我们文章感兴趣，欢迎点击“蓝字”关注来咨询，我们帮助提供评估和全套移植服务

去年有个做控制设备的客户找过来，需求听起来很矛盾：界面要跑 Qt，要联网上云，要能插U盘升级，这些都指向 Linux；但同时电机控制环路要求 100us 级别的确定性响应，Linux 的调度延迟根本兜不住，这又指向 RTOS。

客户原来的方案是两颗芯片，一颗跑 Linux 做 UI/网络，一颗外挂 MCU 跑 RTOS 做电机控制，中间用 SPI 通信。能用，但两颗芯片、两块 PCB、两套供电，成本和体积都下不来，SPI 通信的延迟和丢包偶尔还会导致控制环路抖动。

后来换成了瑞芯微 RK3576，这颗芯片本身是 4×Cortex-A72 + 4×Cortex-A53 的大小核架构，额外还集成了一颗独立的 Cortex-M0，未来客户还期望能够跑边缘侧AI。Linux 跑在 A72/A53 上做 UI 和联网，RT-Thread 跑在 M0 上做电机控制，物理上是同一颗硅片，但是两个完全独立的运行环境，各自有自己的地址空间、自己的中断向量表、自己的调度器，谁也管不到谁——直到我们把核间通信这层机制搭起来。这套方案客户认为未来还能方便移植到其他芯片平台，能够形成不同级别的产品，比如国外客户使用iMAX系列芯片，国内客户还可以使用全志T536芯片，或RK3588芯片。RTOS选FreeRTOS或RT-Thread都可以，但RT-Thread国内技术资料丰富，客户最终还是选择了RT-Thread。

这篇文章讲的是这套东西具体怎么跑起来的，不是概念介绍。

先说清楚：这不是"一个系统模拟另一个系统"

刚接触AMP（Asymmetric Multi-Processing，非对称多处理）这个词的人，容易理解成"Linux 里跑了个 RTOS 虚拟机"，这是错的。虚拟化（QEMU、KVM）是软件层面模拟出多套硬件环境；AMP 是芯片本身物理上就有多个异构核心，A72/A53 集群和 Cortex-M0 是不同架构、不同指令集的物理核心，Linux 内核根本管不到那颗 M0，M0 上跑的 RT-Thread 也感知不到 A72 那边发生了什么。

这个区别很关键，因为它直接决定了故障隔离能力：Linux 那边死机、重启、内核 panic，只要供电和时钟没受影响，M0 上的电机控制环路可以完全不受干扰地继续跑。这是客户最看重的一点——UI死了，机器不能停。这也是为什么很多需要功能安全考量的场景（工业控制、安全联锁）会选 AMP，而不是把所有东西塞进一个 RTOS，或者塞进打了 PREEMPT_RT 补丁的单一 Linux。

启动顺序：谁先跑，谁把谁叫醒

上电之后大致的顺序是这样的：

● Boot ROM 起来，加载片内 SRAM 里的一小段代码

● TF-A（ARM Trusted Firmware）和 U-Boot 依次跑起来，初始化 DDR

● U-Boot 阶段，如果检测到 M0 固件存在，会把编译好的 M0 二进制拷贝到约定好的一块内存区域，然后通过 CRU（Clock & Reset Unit）里的复位控制寄存器把 M0 核心的复位释放掉

● M0 上的 RT-Thread 这时候就已经开始跑了，Linux 内核这时候可能还在往下走

● U-Boot 继续拉起 Linux 内核，Linux 里加载对应的 remoteproc 驱动，"认领"已经在跑的 M0 核心（也可以配置成 Linux 起来之后才由 remoteproc 驱动去拉起 M0，两种模式 RK 系列都支持）

我们项目里用的是 U-Boot 阶段就拉起 M0 的方式，好处是电机控制这种对启动时间敏感的功能，不用等 Linux 那几秒钟的启动流程跑完就已经在工作了，客户机床一上电，M0 上的急停检测、限位保护逻辑立刻生效，不用等 Linux 桌面出来才有保护。

U-Boot 里大致的操作是这样（具体命令因 SDK 版本略有差异，这里是简化后的示意）：

=> cp.b 0x60000000 0x00110000 0x20000

=> m0_boot 0x00110000

第一行把 M0 的固件从存放位置拷贝到 M0 能直接寻址的 SRAM 区域，第二行释放 M0 的复位并让它从这个地址开始执行。这个地址是提前在 RT-Thread 工程的链接脚本、以及 U-Boot 侧的启动配置里约定好的，两边必须完全一致——这个坑我们在上一篇 BSP 移植的文章里提过，地址对不上，M0 那边就是一片死寂，串口连一个字符都不会吐。

核间通信：Rockchip 用的是 IPIC + INTMUX，

不是标准 ARM MU

这里是 Rockchip 平台和 NXP i.MX 系列 AMP 方案一个比较大的差异点。i.MX 系列用的是标准 MU（Messaging Unit）做核间邮箱中断，而 Rockchip 这边用的是自己的 IPIC（可编程中断控制器）配合 INTMUX（中断多路复用器）来实现核间的中断触发和状态同步。IPIC 提供的可配置属性比较丰富，能灵活地把哪个中断源路由给哪个核心；INTMUX 相对简单，主要做多路中断的合并与分发。

通信的整体思路跟标准 OpenAMP/RPMsg 方案是一致的：

● 划出一块两边都能访问的共享内存区域，一般放在 DDR 里 A核和M0都能寻址的地址范围

● 共享内存里维护若干组环形缓冲区（vring），一边写数据，一边读数据

● 谁写完了，通过 IPIC 触发一个核间中断告诉对方"有新数据"，对方在中断服务程序里去共享内存把数据取走

RT-Thread 这边的 rpmsg 组件封装了这套流程，业务代码大概是这样收发：

Linux 端因为有标准的 rpmsg 内核框架，上层的 Qt 界面代码不需要关心 vring、IPIC 这些底层细节，通过读写字符设备（比如 /dev/ttyRPMSG0）或者走 rpmsg_char 生成的设备节点就行，操作起来跟操作一个串口差不多，这也是这套生态比较友好的地方——具体到我们项目里，界面这边是通过一个轮询线程定时读状态、写指令，跟操作本地文件没什么区别。

我们踩过的坑：Cache 一致性，

以及 M0 这边根本不带 Cache 带来的另一个误区

这是这套方案里最容易出问题、最难排查的一环，专门拿出来说。

A72/A53 核心默认开着 Cache，如果共享内存区域被当成普通可缓存内存来访问，会出现这种情况：A核写了一个数据到共享内存，这个数据可能还停留在 A核的 L1/L2 Cache 里，没有真正刷回 DDR；M0 直接读 DDR（M0 本身不带 Cache），读到的是写入之前的旧数据。反过来，M0 写的数据 A核读的时候，如果 A核 Cache 里正好有这块地址的旧副本，也可能读到脏值。

我们第一次遇到的时候，表现是电机偶发性地不响应启动指令，重发一次又好了，日志里两边收发的字节数对得上，数据内容却对不上——这种"看起来通信正常但数据是错的"的现象，十有八九就是 Cache 一致性问题，因为它不是每次都错，是偶发的、跟 Cache 行的淘汰时机有关。

解决办法是在 Linux 侧的设备树里把共享内存区域显式标记成非缓存或者用一致性内存分配接口管理：

shared-dma-pool 这个 compatible 会让 Linux 用 DMA 一致性内存 API 去管理这块区域，天然处理掉缓存一致性问题，而不需要在业务代码里手动 flush/invalidate cache line。这一步在设备树里漏配，或者共享内存地址跟 M0 端约定的不一致，都是我们实际排查中遇到过的真实原因。

另外要提一句容易搞混的地方：因为 M0 本身不带 Cache，很多人会想当然地认为"反正 M0 那边不存在 Cache 问题"，从而只在 Linux 侧做了非缓存映射就完事了。但如果共享内存区域同时还配置了写缓冲（write buffer）或者存在其他形式的总线级缓存/预取行为，光处理 A核那一侧不一定够，最好的做法还是两端都按"最坏情况有缓存"的假设去配置内存属性，宁可牺牲一点访问速度，不去赌总线行为一定符合预期。

什么场景真的需要这套方案，什么场景不需要

不是所有"要联网又要实时"的项目都得上 AMP，这套方案引入的复杂度（两套工具链、两份固件、核间通信调试）是实打实的成本，我们一般按这个标准判断：

● 实时性要求进到微秒级、且不能容忍 Linux 那边任何异常影响到它 —— 上 AMP，比如电机伺服环路、安全联锁逻辑

● 实时性要求在几十毫秒级别，能接受打了 PREEMPT_RT 补丁的 Linux 带来的抖动 —— 不一定需要 AMP，单 Linux + 实时补丁可能就够了，省掉一整套核间通信的调试成本

● 纯粹是想省成本、想少用一颗外挂 MCU，但实时性要求本身不高 —— 也不建议为了"省一颗芯片"硬上 AMP，调试成本可能比外挂一颗便宜的 MCU 还高

客户那台控制设备最后选 AMP，是因为急停响应时间是写进安全规范里的硬指标，容不得"大概率没问题"，这种场景 AMP 的核隔离特性才真正物有所值。而且选 RK3576 而不是外挂 MCU 方案，还有一个额外好处：M0 核心跟 A核共享同一颗芯片的电源管理和时钟树，BOM 上少了一整颗独立 MCU 加相关外围电路，对客户来说这笔成本是实打实能算出来的。

END