将 Bao 带到 RVA23 Silicon
Banana Pi BPI-SM10 上的 Linux + FreeRTOS
João Peixoto，OSYX Technologies 的 Bao 维护者 | 13 分钟阅读 | 2026 年 9 月 22 日
本文将实际探讨在 RISC-V 上使用 Hypervisor 扩展和 AIA 进行混合关键性分区，这些扩展和 AIA 可在符合 RVA23 标准的 SpacemiT K3 上找到。
Banana Pi BPI-SM10 为 Bao 社区带来了一些特别有趣的东西：一个具有 Hypervisor 扩展和高级中断架构 (AIA) 的 RVA23 级 RISC-V 平台，可在真正的硅片上实现。
在这篇文章中，我们将在基于 SpacemiT K3 构建的 BPI-SM10 上安装 Bao，并用它来并行运行 Linux 和 FreeRTOS。
最终形成了一个可复现的混合关键性设置，其中 Linux 处理网络和通用工作负载，而 FreeRTOS 则独立运行在专用硬件上，并拥有串行控制台的所有权。
IMG_0080
960×540 153 KB
BPI-SM10 概述
BPI-SM10 (K3-CoM260) 是一款基于 SpacemiT K3 的 Banana Pi RISC-V 计算机模块和参考载板。其通用计算部分包括：
8 个 X100 64 位 RISC-V 应用内核，最高主频达 2.4 GHz
2 个集群，每个集群包含 4 个 X100 核心
每个集群 4 MB 共享二级缓存
每个 X100 核心配备 64 KB 指令缓存和 64 KB 数据缓存
RVA23 合规性
RISC-V 向量扩展 (RVV) 1.0，VLEN=256
8/16/32 GB LPDDR5，读写速度 6400 MT/s
该 SoC 还包含 8 个 A100 AI 计算核心，额定性能为 60 TOPS，RVV 为 1.0，VLEN 为 1024。这些 AI 核心与 Bao 在本文所述演示中使用的 X100 应用核心是分开的。
从虚拟化的角度来看，X100 芯片是该平台最重要的部分。它们实现了 RISC-V Hypervisor (H) 扩展、高级中断架构 (AIA) 和用于定时器支持的 Sstc 扩展。
首批符合 RVA23 标准的 RISC-V 平台之一
SpacemiT K3 是首批符合 RVA23 标准的 RISC-V 芯片之一，将最新的应用处理器规范引入到商用硬件中。这使得 BPI-SM10 成为一个理想的平台，可以直接在芯片上评估虚拟化和混合关键性工作负载。
载板露出：
2 个 MIPI CSI-2 摄像头连接器
M.2 Key M，支持 PCIe Gen3 x4/x1
M.2 钥匙 E
4 个 USB 3.0 Type-A 接口
USB Type-C UFP
千兆以太网
DisplayPort 1.2
MIPI DSI
40 针接头，带有 UART、SPI、I2S、I2C 和 GPIO 接口
它的封装尺寸与 NVIDIA Jetson Orin Nano 外形尺寸兼容，这也使得该板卡对正在评估 RISC-V 在已使用该载体格式的系统中的应用的开发人员来说很有吸引力。
关于包子的简要说明
Bao 是一款轻量级的开源静态分区虚拟机管理程序，旨在实现强大的隔离性和可预测的执行。
Bao 并不动态调度虚拟 CPU，而是在配置时静态地为虚拟机分配 CPU、内存区域、设备和中断。在其核心分区模型中，Bao 特意避免了以下情况：
运行时 CPU 调度
运行时内存分配
完整的设备仿真层
一个具有特权的 Linux 管理虚拟机
隔离是通过硬件虚拟化机制实现的。在带有 H 扩展的 RISC-V 系统中，这包括第二阶段（RISC-V 术语中的 G 阶段）地址转换以及硬件辅助中断虚拟化。
对于混合关键性系统，该模型为每个虚拟机分配固定的资源预算，并消除分区之间的调度程序干扰。
Bao 由社区驱动的Bao 项目开发，并以 Apache 2.0 许可证发布。
OSYX是 Bao 项目背后的面向行业的实体，为混合临界性设计提供商业支持、平台启动、系统集成和长期维护。
我们建造了什么
BPI-SM10 演示程序运行两个独立的虚拟机：
Linux：SpacemiT 的供应商内核，通过 Buildroot 构建，提供网络和通用功能。
FreeRTOS：在专用 HART 上运行实时任务并控制板载串口控制台
该板卡提供一个适用于控制台的 UART 接口。由于静态分区设备仅属于一个虚拟机，因此 UART0 被分配给 FreeRTOS。因此，Linux 以无头模式运行，并通过以太网使用 SSH 进行访问。
测试软件配置
开发板：Banana Pi BPI-SM10 (K3-CoM260) 模块和参考载板
Bao 虚拟机管理程序：feat/plat-spacemit-k3
bao-demos：feat/k3-com260
Linux：SpacemiT 供应商 6.18 内核（通过 Buildroot 安装）
bao-drivers：linux-v6.18
U-Boot 和 OpenSBI：SpacemiT 代码库已锁定到 k3-br-v1.0.0
技术演示
这仅是一次技术演示，并非生产就绪的集成。演示内容涵盖平台启动、静态分区、启动流程、设备分配以及虚拟机间通信。生产部署还需要额外的加固、验证以及（如适用）认证工作。
资源分区
该演示使用了八个 X100 应用核心中的四个：
Hart 0：Linux
哈特 1：Linux
Hart 2：Linux
Hart 3：FreeRTOS
Harts 4 至 7：未分配，可用于进一步划分或实验。
Linux 系统分配 1 GiB 内存和以太网相关设备链。FreeRTOS 系统分配 128 MiB 内存和 UART0 接口。一个 64 KiB 的共享内存区域，以及一个门铃中断，为两个虚拟机之间提供了一个受控的进程间通信 (IPC) 通道。
IMG_0078
960×540 48.5 KB
Linux 拥有三个 HART 接口和以太网设备链。FreeRTOS 拥有一个 HART 接口和 UART0。唯一跨越边界的资源是已配置的共享内存区域。
| 资源 | VM 1（Linux） | VM 2（FreeRTOS） |
| 哈茨 | 0、1、2（CPU亲和性 = 0x7） | 3（CPU亲和性=0x8） |
| 内存基础 | 0x180000000（place_phys） | 0x0 |
| 内存大小 | 1 GiB | 128 MiB |
| 设备 | gmac1、syscon_apbc、syscon_apmu、pinctrl、gpio | UART0 |
| 设备中断 | 133、277、60、58 | 42 |
| 中断控制器 | 应用程序0xe0804000，IMSIC 0xe0400000 | 应用程序0xe0804000，IMSIC 0xe0400000 |
| IPC 内存库 | 0xf0000000 | 0xf0000000 |
| IPC 内存大小 | 64 KiB | 64 KiB |
| IPC中断 | 52 | 52 |
| 网络 | 带DHCP的以太网 | 不 |
| 安慰 | SSH | UART0 |
该平台使用 RISC-V AIA 进行中断处理。在 K3 上，这包括高级平台级中断控制器 (APLIC) 和传入消息信号中断控制器 (IMSIC)。
Bao 在初始化期间配置这些资源一次。之后，每个虚拟机都在其分配的内核上运行，拥有自己的内存和设备。
以太网直通
将设备传递给静态分区的虚拟机通常比分配一个MMIO区域和一个中断要困难得多。K3以太网控制器就是一个很好的例子。
仅仅将驱动程序分配gmac1到 Linux 系统并不足以使网络接口正常工作。该驱动程序还依赖于其他几个硬件模块：
syscon_apbc：时钟和复位相关控制
syscon_apmu：时钟和复位相关控制
pinctrl：配置 RGMII 和 MDIO 焊盘
GPIO：驱动以太网PHY复位线
在传统的 Linux 系统中，内核可以通过常规的设备树和驱动程序框架访问这些提供程序设备。然而，在静态分区系统中，Linux 虚拟机无法访问 Bao 未明确分配给它的硬件。这意味着分区必须包含设备所需的完整依赖链。
Linux VM | +-- GMAC1 | +-- syscon_apbc -> clocks / reset +-- syscon_apmu -> clocks / reset +-- pinctrl -> RGMII / MDIO muxing +-- GPIO -> PHY reset
从K3培养中吸取的教训
设备直通不仅仅关乎终端设备，它还关乎客户机驱动程序运行该设备所需的所有硬件资源。向分区系统添加其他外围设备时，也适用同样的模式。
还有两点值得注意：
Linux 内存区域使用place_phys，这意味着客户机看到的区域与主机使用的物理地址相同。
目前只有一半的 X100 应用核心被分配，还剩下四个核心可供另一个虚拟机使用。
从 BootROM 到 Bao：K3 启动链
K3 的启动流程比传统的“U-Boot 加载虚拟机管理程序”序列更有趣。BootROM 和辅助启动阶段需要 SD 卡上固定偏移位置的固件组件，而不是通过文件系统来发现所有内容。
因此，Bao平台构建产生了一个完整的sdcard.img包含内容：
GPT
ext4 启动文件系统分区
bao.itb
启动.scr
固件组件已写入 K3 启动过程所需的原始位置
Bao 之前的每个阶段都由 K3 启动过程完成。Bao 配置 harts、G-stage 转换、设备、AIA 路由和 IPC 通道，然后将控制权交给两个虚拟机。
那时：
FreeRTOS 在 hart 3 上启动，占用 UART0，并开始执行任务。
Linux 系统从 harts 0 到 2 启动，初始化以太网，并通过 SSH 连接。
两个系统继续独立运行，互不干扰 CPU 调度。
K3平台启动说明
端口的一些细节对于该平台来说具有很强的特殊性，值得记录下来，以便任何将 Bao 适配到其他 K3 载板或 BSP 的人都能了解情况。
1. 固定启动固件
启动固件由 SpacemiT U-Boot 树生成，包含u-boot.itb默认环境、FSBL 和启动信息块。OpenSBI 是单独构建的fw_dynamic.itb。
该演示程序将两者都锁定在k3-br-v1.0.0标签上，而不是跟随开发分支的最新更新。这避免了诸如超出 SPL 大小限制之类的回归问题。
2. 使用 FIT 图像
此开发板上的 U-Boot 不支持此流程中使用的旧版 uImage。因此，Bao 和启动脚本以扁平化镜像树 (FIT) 镜像的形式提供。
厂商bootcmd通常支持 GRUB 引导或原始内核引导。对于 Bao 引导流程，环境变量会被替换，mkenvimage以便 U-Bootboot.scr自动加载 Bao 并进入 Bao 目录。
3. 调整 Linux 厂商内核
该 Linux 虚拟机使用 SpacemiT 提供的 6.18 内核，该内核是通过标准的 Buildroot 构建流程构建的。配置中添加了以下所需的组件：
K3 SoC 支持
时钟控制
引脚控制
GPIO
友邦保险
通用汽车金融
支持 8250 UART
另一个补丁移除了厂商的 SBI dcache-flush 调用。在 Bao 框架下，这些ecall调用由虚拟机管理程序而非厂商固件路径处理，否则厂商配置中针对这些调用的限制会破坏链接。
在将虚拟机管理程序从架构模型迁移到实际硬件时，这些正是容易被忽略的平台特定细节。
Linux 和 FreeRTOS 通信
两位访客仅通过预先配置的IPC通道进行通信：
64 KiB 共享内存
在两个访客中都映射到 0xf0000000
门铃中断：IRQ 52
在 Linux 系统中，bao-driversIPC 模块将通道公开为：
/dev/baoipc0
从 Linux 向 FreeRTOS 发送数据：
echo "Hello from Linux" > /dev/baoipc0
FreeRTOS 接收到消息后，会将其与正常任务输出一起打印到串口控制台上。FreeRTOS 可以将数据写回同一个 IPC 通道，Linux 可以使用以下方式读取该通道：
cat /dev/baoipc0
这样一来，两个虚拟机就拥有了一条可控的通信路径，而无需共享调度或设备。由于在这种配置下 Linux 是无头的，因此进程间通信 (IPC) 通道也是一种将 FreeRTOS 状态暴露给可通过网络访问的应用程序的自然方式。
构建演示
演示文件位于bao-project/bao-demos目录下：
平台：k3-com260
演示：linux+freertos
分支：feat/k3-com260
依赖关系
K3 平台除了标准bao-demos依赖项外，还需要三个软件包，因为构建过程会组装最终的 SD 卡映像。
sudo apt install build-essential bison flex git libssl-dev ninja-build
u-boot-tools pandoc libslirp-dev pkg-config libglib2.0-dev libpixman-1-dev
gettext-base curl xterm cmake python3-pip xilinx-bootgen file cpio
device-tree-compiler gdisk e2fsprogs
pip3 install pykwalify packaging pyelftools
建造
设置 RISC-V 工具链：
export CROSS_COMPILE=/path/to/riscv64-unknown-elf/bin/riscv64-unknown-elf- export OPENSBI_CROSS_COMPILE=/path/to/toolchain/bin/riscv64-unknown-linux-gnu-
克隆演示代码库：
git clone https://github.com/bao-project/bao-demos cd bao-demos
选择平台和演示版本，然后进行构建：
export PLATFORM=k3-com260 export DEMO=linux+freertos make -j$(nproc)
单次构建调用即可获取并构建完整的软件栈：OpenSBI、SpacemiT U-Boot、buildroot、SpacemiT 厂商提供的 Linux 内核、FreeRTOS、Bao 以及最终的构建组件sdcard.img。buildroot 阶段在首次构建中占据主导地位。
启动新电路板时，首先要从裸机开始。
如果您要将 K3 支持适配到其他主板或载板，请从以下步骤开始：
export DEMO=baremetal
裸机配置在所有八个 X100 硬件加速卡上运行一个虚拟机，分配 64 MiB 内存，0x102000000并直接直通 UART0。这样，在引入 Linux、AIA 设备依赖项或第二个虚拟机之前，您可以轻松验证启动链、Bao 入口、硬件加速卡初始化、内存配置和 UART 直通。
部署
将生成的镜像写入sdcard.imgmicroSD 卡并启动开发板。平台 Makefile 会dd在构建完成后打印目标镜像路径和相应的命令。相同的过程在文档中也有说明platforms/k3-com260/README.md。
启动演示，展示在 BPI-SM10 上 Bao 系统下启动 Linux 和 FreeRTOS。
启动后：
FreeRTOS 输出可通过 UART0 访问。
Linux 通过 DHCP 获取网络连接。
Linux 系统通过 SSH 访问。
IPC 可通过 /dev/baoipc0 访问。
可以尝试的东西
目前的演示版本特意留出了扩展空间。
添加另一个虚拟机/分区
目前仅使用了八个 X100 心脏中的四个。因此，心脏 4 至 7 可以分配给：
另一个 Linux 虚拟机
另一个实时操作系统
裸机工作负载
隔离的服务分区
这使得 BPI-SM10 成为试验更复杂的静态分区拓扑的有用平台。
更改资源地图
Bao 的配置可以进行修改demos/linux+freertos/configs/k3-com260.c。一些有用的实验包括：
在隔间之间移动心脏
更改 RAM 大小
分配其他外围设备
创建第三个虚拟机
改变IPC布局
添加更多设备
以太网启动是一个有用的模板。对于每个新设备，不仅要识别 MMIO 区域和中断，还要识别客户驱动程序所需的所有依赖资源：时钟、复位、引脚控制、GPIO 以及 IOMMU 或 DMA 相关资源（如适用）。
评估干扰
当前架构确立了建筑隔离边界。下一步自然是进行以下特征描述：
中断延迟
IPC延迟
执行时间抖动
缓存干扰
内存系统干扰
Bao 还支持诸如通过缓存着色进行缓存分区等技术，这些技术可在需要更严格的干扰控制时进行评估。有关静态分区和混合关键性系统的更深入分析，请参阅《揭示基于 Arm 的混合关键性系统的静态分区虚拟机管理程序》。
接下来去哪儿？
Linux 和 FreeRTOS 是一对绝佳的搭配。它们采用相同的分区模型，并且都支持以下操作系统：
多个 Linux 虚拟机，包括基于 Android 的虚拟机
Zephyr、NuttX 和 RT-Thread
当两个虚拟机需要同一个外围设备时，Bao 使用 VirtIO：一个虚拟机拥有该设备，并通过共享内存与其他虚拟机共享该设备。
对于一个基本的入门指南，请参阅bao-helloworld和我们自己的教程“ Hello, Bao!”。
结论
BPI-SM10 对 Bao 来说是一个特别有趣的平台，因为它结合了现代 RISC-V 应用处理器、RVA23 级功能、Hypervisor 扩展和基于 AIA 的中断处理，并且运行在真正的硬件上。
这里展示的演示展示了从 K3 启动链到两个隔离的客户机的完整路径：Linux 用于网络和通用工作负载，FreeRTOS 用于确定性实时执行，Bao 用于静态资源分区和硬件强制隔离。
更重要的是，启动过程揭示了将虚拟化从架构规范转移到真正的 SoC 时重要的细节：启动固件约束、中断控制器集成、设备依赖链、供应商内核假设和显式资源所有权。
对于正在评估 RISC-V 在混合关键性系统中的应用的开发人员来说，BPI-SM10 提供了一个实用的平台，可以直接在硅片上探索这些机制。
审核编辑 黄宇
