在工业控制、电力、汽车电子等场景中，系统往往需要同时满足两类相互冲突的需求：一方面要运行 Linux 以承载复杂的业务逻辑、网络协议与文件系统；另一方面要具备硬实时性——中断响应必须在确定的时间窗口内完成，不能被 Linux 的进程调度延迟。
传统方案是"两套系统、两颗芯片、两套外围电路"，成本高、体积大、核间通信复杂。AMP（Asymmetric Multi-Processing，非对称多处理）架构给出了另一种解法：在同一颗 SoC 上集成不同架构的处理器核心，通过硬件隔离实现异构平台并行运行。
01
AMP 与 SMP为什么实时性需要"分家"
多核异构系统支持两种多处理模式：
瑞芯微多核异构系统主要采用无监督的 AMP 方案，配合虚拟化管理，使运行实时系统时能获得更快的中断响应，以满足电力、工控等行业对硬实时性的苛刻要求。
核心价值：传统平台中 Linux 与实时系统是完全独立的两套系统，需要两颗处理器和两套外围电路；AMP 通过合理的处理器核心与外设资源划分，让同一颗 SoC 同时运行两套系统——既保留了 Linux 的软件生态与外设丰富性，又满足了实时性要求。
02
RV1126B 的 HPMCU400MHz 的 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：
sudoapt updatesudoapt 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/reposync-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 三个递进式案例，覆盖从"跑起来"到"核间通信"的完整路径。对工控、电力、汽车电子等有硬实时要求的场景，这套方案可直接作为评估起点。
