Linux+RTOS 异构部署

一颗芯片跑两个系统：

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

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

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

刚接触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

这里是 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 组件封装了这套流程，业务代码大概是这样收发：

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

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

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

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

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

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

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

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