JH-7110现已支持AMP双系统（Linux + RT-Thread）

[ErinD]

近期昉·惊鸿-7110（JH-7110）再次实现新升级，现已支持异构AMP双系统（Linux + RT-Thread），具有更强的系统实时性、稳定性，降低系统硬件成本，可用于要求高度定制化、实时性和可靠性的工业领域。

AMP(Asymmetric Multi-Processing)

1. 降低系统硬件成本：

昉·惊鸿-7110（JH-7110）包含4个U74 CPU，此次实现的异构AMP即让其中1个CPU运行RT-Thread RTOS，以此形成3个U74运行Linux操作系统，1个U74运行RT-Thread RTOS的双系统AMP架构。在开发中无需额外搭建其他系统硬件设备支持，仅需一套硬件电路可以实现复杂功能，大大降低了系统硬件成本。

2. 提高系统实时性与稳定性：

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

随着工业自动化等领域对实时性能的高要求，RTOS的需求正不断增加。近期，RT-Linux Kernel 6.6也正式支持了RISC-V架构，内核现已包含赛昉科技昉·惊鸿-7110（JH-7110）的驱动代码。

赛昉科技在实时性系统适配上取得的突破性进展，将为工业自动化、电力互联网等领域提供更多稳定且可靠的实时解决方案。

AMP 双系统（Linux + RT-Thread） 示例

目前赛昉科技已展示在新一代SoC平台昉·惊鸿-7110（JH-7110）上运行异构AMP双系统（Linux + RT-Thread）的演示示例。

1. 核间通信方式

两核通信使用标准的virtio-base的RPMsg（Remote Processor Messaging）协议，它定义了异构多核处理系统AMP中核与核之间进行通信时所使用的标准二进制接口。

Linux：在Linux内核代码中，RPMsg的代码主要位于drivers/rpmsg/下，相关的代码如下：

driver/rpmsg/virtio_rpmsg_bus.c
drivers/rpmsg/virtio_rpmsg_starfive.c

RT-Thread：使用开源的rpmsg-lite代码，也是开源的virtio-base的RPMsg代码，能够按照协议和Linux收发数据。核间的IPI中断和共享内存配合能实现异构核间的数据传输。RT-Thread代码路径如下：
bsp/starfive/jh7110/driver/rpmsg_lite

2. 编译&运行

① 连接Linux和RTOS的调试串口，串口的波特率均设置为115,200。

② 将编译出来的u-boot-spl.bin.normal.out和visionfive2_fw_payload.img文件刷写到SPI NOR FLASH上。

③ 上电启动：RT-Thread启动很快，并且运行rpmsg linux test的测试程序，RT-Thread在等待Linux端发送IPI中断，Linux端是Rpmsg的master，需要配置virtio queue的控制内存和共享内存。

图1: RT-Thread上电启动

④ 启动Linux：启动linux过程中，virtio_rpmsg_bus驱动会注册，virtio_rpmsg_starfive驱动也会被注册，注册完成后会发IPI中断给RT-Thread。

图2: Linux启动

RT-Thread接受到IPI中断后，rpmsg_linux_test会继续执行，这时RT-Thread的finsh shell也能正常使用。

图3: RT-Thread进程

⑤ Linux端运行以下命令能看到 RT-thread发给Linux的IPI中断：
cat /proc/interrupts

图4: IPI中断

⑥ 运行以下测试程序：
rpsmg_echo

图5: 测试结果

IPI中断情况：

cat /proc/interrupt
IPI5: 12 0 0 AMP rpmsg interrupts

AMP双系统（Linux + RT-Thread）的演示示例现已更新至RVSpace：
在昉·星光2上运行AMP双系统（Linux + RT-Thread）

[jiangtao9999]

我觉得这个双系统方案，最大的意义是 riscv 异构。

这样 CPU 就可以设计成 riscv64gc 外加专用计算扩展指令（其实我觉得专用计算核心，rv64imac 足以，浮点计算直接用扩展指令的）专门用于数据计算，以及 RVA22 用作用户应用程序。实现两边都有对应硬件提供效率性能的设计。

我感觉目前 riscv CPU 直接做本体系的异构已经是必然趋势了。但是现在的问题就是怎么解决两边不同的协调问题。
貌似现在很多人的想法是专用核心直接跑裸金属应用，但是我觉得还是上个专用的系统为好。这样可以降低专用核心应用开发难度。

但是现在两边内存如何分配我觉得还是个问题。如何实现共用内存地址，降低无意义的内存数据拷贝是个难题。

[ganboing]

这个例子是用3个U74跑Linux，1个U74跑RTOS，还不算异构。如果用S7来跑RTOS那么确实就是异构了。我现在就在实验能否用S7+U7来做。目前先要把S7跑起来，然后实测一下是否内存性能过低，因为手册上已经指明S7没有data cache。另外就是S7没有S模式，以及目前PLIC中断控制器还是太基本，并不能很方便的从一个hart直接inject硬件中断到另一个hart，只能是inject software interrupt (IPI)。还有就是S7不能使用LR/SC指令。这些问题都是让S7非常难以使用。我基本想通过opensbi模拟来解决。

回到这个帖子，他是直接hook了Linux的IPI handler，以及在opensbi中添加了非常hacky的ecall来实现hart之间互相通知的，这种实现是肯定不能提交到上游的。如果从opensbi实现一个mailbox或者什么其他的虚拟设备，然后通过它来沟通，那么有可能能够尝试提交给上游。当然这怕是也是得再虚拟出一个irqchip。我正在尝试给opensbi提交一个更改：
http://lists.infradead.org/pipermail/opensbi/2024-January/006318.html
这可以提供一个接口，让opensbi里面的jh7110 platform能够去实现一些虚拟设备。至少是第一步。

[jiangtao9999]

等你好消息了。
不过我想 S7 本来定位就不是高性能的通用核心，目前只要能实现 S7 独立运行证明异构可行性就行了吧？

如果真的能实现异构，那么不如直接让硬件厂家根据需求再重新设计核心构成。
甚至我觉得完全可以直接增加一些异构需要的设计作为规范，从基础设计上去实现异构来降低难度。