单芯片同时跑 Linux 与 RT-Thread：RV1126B的AMP异构方案完整拆解

在工业控制、电力、汽车电子等场景中，系统往往需要同时满足两类相互冲突的需求：一方面要运行 Linux 以承载复杂的业务逻辑、网络协议与文件系统；另一方面要具备硬实时性------中断响应必须在确定的时间窗口内完成，不能被 Linux 的进程调度延迟。

传统方案是"两套系统、两颗芯片、两套外围电路"，成本高、体积大、核间通信复杂。AMP（Asymmetric Multi-Processing，非对称多处理）架构给出了另一种解法：在同一颗 SoC 上集成不同架构的处理器核心，通过硬件隔离实现异构平台并行运行。

01------AMP 与 SMP 为什么实时性需要"分家"

多核异构系统支持两种多处理模式：

瑞芯微多核异构系统主要采用无监督的 AMP 方案，配合虚拟化管理，使运行实时系统时能获得更快的中断响应，以满足电力、工控等行业对硬实时性的苛刻要求。

核心价值： 传统平台中 Linux 与实时系统是完全独立的两套系统，需要两颗处理器和两套外围电路；AMP 通过合理的处理器核心与外设资源划分，让同一颗 SoC 同时运行两套系统------既保留了 Linux 的软件生态与外设丰富性，又满足了实时性要求。

02------RV1126B 的 HPMCU 400MHz 的 RISC-V 实时核

RV1126B 内部集成了一个 HPMCU（High Performance MCU），RISC-V 架构，具备以下资源：

⚠️ 关键约束：MCU 与 Linux Kernel 必须互斥地访问资源。 MCU 使用到的引脚，Linux 端不能再占用------开发时需通过 pinctrl 确认引脚归属，否则会引发资源冲突。

启动时序：

复制代码

Bootloader 运行在 CPU0，加载至 U-Boot
    ↓
U-Boot 读取并启动 MCU 运行 AMP 固件
    ↓
U-Boot 继续在 CPU0 运行，加载启动 Linux Kernel
    ↓
Linux Kernel 启动 CPU1 / CPU2 / CPU3

MCU 先于 Linux 启动，这一顺序保证了实时任务可以尽早进入工作状态。

03------开发环境与 SDK 编译

1. 安装编译工具

AMP 案例编译依赖scons：

复制代码

sudo apt update
sudo apt install scons

2. 获取 SDK

复制代码

repo init --repo-url ssh://git@os.easy-eai.com/ubuntu_sdk/repo \
  -u git@os.easy-eai.com:ubuntu_sdk/manifest -b lmo -m lmo-amp.xml
. repo/repo/repo sync -c -v

3. 选择 AMP 配置文件

复制代码

./build.sh configs/easy-eai-nano-tb-amp_gstreamer-2204-cfg.sh

4. 完整编译

复制代码

./build.sh all

编译产物输出至ubuntu/output/，其中 amp.img是 AMP 方案相比传统 SMP 多出的固件（约 100KB）。

⚠️ 踩坑点：amp.img不能与 SMP 固件混烧 。首次必须完整烧写整套固件；后续若仅修改 RTOS 案例，可只替换 amp.img，取消其他分区勾选单独烧写。

5. 局部编译与案例切换

复制代码

./build.sh rtos

默认编译rv1126b-mcu案例。切换案例需修改配置文件中的RTOS_MCU_DIR：

复制代码

vim configs/easy-eai-nano-tb-amp_gstreamer-2204-cfg.sh
# 修改 export RTOS_MCU_DIR=... 为 rv1126b-led 或 rv1126b-rpmsg
./build.sh rtos

编译成功会打印Build RTOS(rv1126b-led) success。

SDK 内置三个递进式 Demo（位于 ubuntu/rtos/bsp/rockchip/）：

04------实操案例及分析

案例一：rv1126b-led

------ 实时任务的最小闭环

硬件连接： 使用 GPIO5_C0 引脚外接 LED。

运行现象： 烧写amp_led/bin/下的amp.img 后，RT-Thread debug 口（uart6）打印程序运行信息，底板外接 LED 每 1 秒闪烁一次 ，并打印LED ON/OFF。

📌 排障提示：若 LED 无反应，先确认 Linux 端是否占用了 GPIO5_C0 ------ 用 pinctrl 检查引脚归属。这是 AMP 开发中最常见的资源冲突来源。

这个案例的价值在于验证**"实时任务确实跑在独立核上"**：LED 闪烁由 RT-Thread 的定时器驱动，其精度不受 Linux 侧负载波动影响。

案例二：rv1126b-rpmsg

------ 核间通信的完整实现

rpmsg 是 Linux 与 MCU 之间标准的数据通道。本案例中：

A53 侧（Linux） ：运行linux_char_rpmsg 应用层程序
MCU 侧（RT-Thread）：运行 RT-Thread 程序，完成数据接收与回送

通信流程：

复制代码

(1) MCU 端先完成 rpmsg 初始化，广播自身端点名称，启动接收任务等待数据
(2) Linux 端 rpmsg_char 应用创建并打开同名端点设备，主线程周期性发送数据
(3) MCU 收到数据后打印，并自动回送一份数据至 Linux 端
(4) Linux 端通过独立接收线程监听端点设备，接收并展示回送数据
(5) 双方循环收发，配合中断与共享内存机制实现核间通信

Linux 侧关键代码：

复制代码

/* 1. 打开控制设备 */
ctrl_fd = open(ctrl_dev, O_RDWR);
if (ctrl_fd < 0) {
    perror("[ERROR] 无法打开 rpmsg_ctrl 设备");
    printf("[HINT] 确认内核已启用 CONFIG_RPMSG_CTRL=y\n");
    return -1;
}

/* 2. 构造端点信息 */
memset(&ept_info, 0, sizeof(ept_info));
strncpy(ept_info.name, ept_name, sizeof(ept_info.name) - 1);
ept_info.src = RPMSG_ADDR_ANY;
ept_info.dst = EPT_DST_ADDR;

/* 3. 通过 ioctl 创建端点 */
/* 内核会在 /dev/ 下创建 rpmsgX 设备节点，
   并自动通过 Name Service 匹配 MCU 端 announce 的同名端点 */
ret = ioctl(ctrl_fd, RPMSG_CREATE_EPT_IOCTL, &ept_info);
if (ret < 0) { perror("[ERROR] RPMSG_CREATE_EPT_IOCTL 失败");

💡 机制说明： Linux 端通过RPMSG_CREATE_EPT_IOCTL 创建端点后，内核借助 Name Service自动匹配 MCU 端广播的同名端点------两端无需预先约定地址，只需约定端点名称，这降低了跨团队协作时的耦合度。

测试验证：

复制代码

# 板端执行 Linux 应用
./linux_char_rpmsg

RT-Thread debug 口（uart6）收到 Linux 发来的hello from linux，并回复hello for mcu给 Linux 端，双向通信建立。按 Ctrl+C 停止收发。

开发注意事项汇总

结语

AMP 架构的工程价值，在于用一颗芯片同时满足"功能丰富"与"硬实时"这两个原本互斥的需求。Linux 侧承载文件系统、网络协议与 AI 推理，MCU 侧以 400MHz RISC-V 独立运行 RT-Thread 处理实时任务，两者通过 MailBox 与共享内存完成核间通信------硬件隔离保证了实时性不受 Linux 调度抖动影响，单芯片集成则避免了双芯片方案的成本与体积开销。

灵眸科技的 EASY-EAI-Nano-TB 已完整支持该 AMP 方案，SDK 内置 mcu、led、rpmsg 三个递进式案例，覆盖从"跑起来"到"核间通信"的完整路径。对工控、电力、汽车电子等有硬实时要求的场景，这套方案可直接作为评估起点。