六月阶段总结

[ZR233]

概述

  AxVisor 开发任务的 6 月底阶段里程碑（2 月 ~ 6 月）的主要目标是在 ROC-RK3568-PC 开发板上进行移植及适配，以扩展及完善 AxViosr 的相关功能。

开发板

  ROC-RK3568-PC 是天启智能科技的 Filefly 团队推出的一款采用 RK3568 四核 64 位 Cortex-A55 处理器的嵌入式开发板。主频最高 2.0GHz、集成双核心架构 GPU 以及高效能 NPU；最大支持 8G 大内存；支持 WiFi6、双千兆以太网。

阶段情况

  目前，AxVisor 及其依赖的 ArceOS 均不支持 ROC-RK3568-PC 开发板（主要是 RK3568 芯片），因此，我们首要目标是根据开发板相关资源在 AxVisor 中添加相关支持！

  注意，由于 AxVisor 目前仅提供基于硬件隔离的直通方式提供虚拟化支持，在适配过程中，我们仅会添加必要的驱动支持，各种功能由直通的 Linux 客户机来处理！

阶段时间

  6 月底阶段里程碑的时间阶段是 2025 年 2 月 1 号 ~ 2025 年 6 月 30 号。

阶段目标

  针对当前 AxVisor 的开发情况，我们需要通过完善 AxVisor 的相关功能，最终实现将 AxVisor 直接部署在 ROC-RK3568-PC 开发板上的 eMMC 中，并在 AxVisor 中启动一个 Linux + 一个 ArceOS 两个客户机。为此，阶段目标制定如下：

1. 可以在 ROC-RK3568-PC 上部署及启动，并以 设备直通（硬件隔离） 的形式启动 Linux 和 ArceOS 作为客户机

2. 可以正常访问 EMMC 存储，并从 EXT4 文件系统（主要是考虑到 Linux 客户机）中读取客户机配置文件以及客户机内核镜像

3. 支持通过设备树访问硬件资源

4. 客户机 Linux 接管绝大多数开发板硬件并正常工作；客户机 ArceOS 仅用一个 VCPU，并从串口周期输出 Hello World 即可；AxVisor 本身不占用 VCPU

人员安排

  针对当前的阶段目标并结合各个开发人员的实际情况，我们对相关开发人员的工作安排如下所示：

序号	人员	主要工作描述
1	周**	1. 在 ArceOS 和 AxVisor 中增加动态设备树的支持，以便可以通过动态解析设备树获取相关硬件资源 2. 相关的其他任务
2	柏**	1. 增加 Ext4 文件系统支持，使 AxViosr 可以识别 eMMC 中的 Ext4 文件系统，进而读取客户机镜像 2. 相关的其他任务
3	杨**	1. 增加 eMMC 驱动程序，使 AxViosr 可以访问 eMMC 中的 Ext4 文件系统 2. 相关的其他任务
4	宋**	1. 在 ROC-RK3568-PC 开发板上移植适配 ArceOS 2. 相关的其他任务
5	赵**	1. 实现在 ROC-RK3568-PC 开发板上部署 AxVisor，并验证同时启动一个 Linux + 一个 ArceOS 2. 相关的其他任务

完成情况

  截止 6 月 30 日，原定阶段目标已全部达成。在整个移植适配过程中，我们为 AxVisor 添加了很多新功能，但是由于开发板资源等限制，也存在着一些没有解决（临时规避）的问题。

关键任务

  在移植适配 ROC-RK3568-PC 开发板的过程中，我们对 AxVisor 进行了多项功能的完善。开发过程中的详细记录以及问题处理参见 Github 仓库中对应 ISSUE 或阶段里程碑中的内容即可。以下是一些关键任务及相关负责人的完成进度情况：

序号	关键任务	负责人	完成情况
1	在 ROC-RK3568-PC 开发板上适配 ArceOS	宋**	已完成
2	AxVisor 增加动态设备树支持	周**	已完成
3	增加 EXT4 文件系统读写	柏**	已完成
4	新增 RK3568 的 eMMC 驱动	杨**	已完成
5	制作相关镜像以直接部署在 ROC-RK3568-PC 开发板上运行	赵**	已完成
6	验证从存储器文件系统中同时部署一个 Linux + 一个 RTOS 作为客户机	赵**	已完成

  更详细的人员工作完成情况参见后续 Commit 即可！

遗留问题

  由于瑞芯微提供的 Linux SDK 以及目前 AxVisor 仅支持基于硬件隔离的直通方式提供虚拟化支持的限制，在实际运行客户机时也会受到很多限制。虽然可以正常启动一个 Linux + 一个 RTOS 作为客户机，但是仍然存在以下问题：

1. 同时部署一个 Linux + 一个 RTOS 作为客户机时，最理想的情况是每个客户机一个终端，但是，由于 U-Boot 阶段只提供了一个串口，因此无法为每个客户机提供一个串口作为终端。

   临时解决方法为直接让 Linux 使用默认的 UART2，而 ArceOS 使用 UART3。由于 ArceOS 没有串口初始化功能，因此会阻塞在串口打印。直到 Linux 启动后，它默认会初始化串口3，但是默认是关闭的，需要在 Linux 客户机中 cat /dev/ttyS3 启动串口后，ArceOS 才能继续打印！

2. 由于目前 vGICv3 尚未实现，两个客户机时只有一个可以使用中断。

   目前，中断控制器只提供给 Linux 使用，ArceOS 中不涉及任何中断！

3. 由于没有 vGICv3 支持，因此无法同时启动两个 Linux

4. 目前，AxVisor 及其依赖的 ArceOS 中，绝大多数驱动都没有添加。

   AxVisor 除了启动客户机，基本没有任何功能

后续规划

  在本阶段开发过程中，在完成基本阶段目标的同时，也发现了不少开发管理相关问题、AxVisor 功能完善相关的问题，因此，我们计划在后续阶段中首要改进开发管理相关的问题，并在飞腾派等开发板上达到相同目的的同时进一步完善 AxVisor 功能，并迭代回 ROC-RK3568-PC 开发板！

开发问题

  从目前阶段的开发情况来看，我们对于 AxVisor 的开发管理方式存在些许不足，进而导致了效率不佳、开发进度缓慢等问题。其中，比较突出的问题有如下几个：

1. 代码仓库组织混乱。 作为组件化 OS，我们将一些组件单独存放的方法本身没有问题，但是在实际开发中，组件的划分合理性、组件的依赖关系等没有规范化的要求，进而导致了组件过渡碎片化，组件依赖不清，组件存放位置混乱。例如，目前我们的组件来源有如下几个：

   1. https://crates.io/

   2. https://github.com/arceos-org

   3. https://github.com/arceos-hypervisor

   4. 开发人员的个人账号仓库中

   5. 其他第三方引用

2. 代码的审查及合并周期太长。 由于缺乏统一的代码审查及合并规范，导致很多 PR 处于长期无人处理的情况，而随着代码的迭代，PR 又得重新调整等问题

3. 功能开发目标不明确。 目前，我们缺乏一个明确的功能目标，每个阶段及整个 2025 年度要完整那些功能没有明确的目标，导致在阶段中功能开发全靠个人喜好，功能合适合并主线不确定

4. 缺乏统一的开发管理工具。 在目前的开发中，多数开发人员都是个人为战，虽然引入了 Github，但是很少会按照 Github 的开发流程来进行开发

优化建议

  针对在目前阶段的开发过程中暴露出来的问题，我们需要通过一些方法来优化我们的开发管理以提高开发效率，加快开发进度。进而尽快让 AxVisor（ArceOS）达到实际应用的基本需求！

1. 制定明确的功能开发目标。 通过制定阶段目标以及年度总目标等来清晰指出我们的开发的最终目的，规范化开发过程

   1. 明确每个阶段，我们要新增那些功能

   2. 明确年终我们的完成目标

2. 每周或者每个阶段定时进行代码评审会议。 通过会议集中所有开发人员，统一讨论进而及时处理当前已经积压的功能更新以及 BUG 修复，以提高我们的开发效率

   1. 及时评审及合并 PR

   2. 实时反馈及修改问题

3. 制定组件规范，统一组织组件的代码仓库位置。 通过规范化的组件要求以及将组件存放到统一的位置，防止组件碎片化和依赖不清的问题

   1. 评审及规范化已有组件

   2. 实现最终组件只能从 https://crates.io/ 和我们自己的指定位置来获取

   3. 明确组件的引用方式。建议是只能通过版本号或源码仓库 TAG 来引用，防止通过分支引用时随着代码的改动而引入错误

功能完善

  从目前阶段的开发情况来看，要使 AxVisor（ArceOS） 达到实际应用环境的基本需求，仍然有很多功能需要完善，包括但不限于需要增加以下这些基本功能：

1. 增加客户机之间通信的能力。

2. 完善 AxVisor（ArceOS）的内存管理功能，可以灵活处理多内存 Region 的情况

3. 完善 AxVisor 对于虚拟化的支持，支持设备虚拟化，完整的 CPU 虚拟化等

4. 完善驱动支持，目前的 AxVisor（ArceOS）中驱动程序只有很少的几个，无法满足实际的应用需求

5. 增加控制台支持，在控制台可以增删改查客户机，查看硬件资源使用情况。当启动任何客户机时， AxVisor（ArceOS）本身就是一个独立的 OS 在运行，用户可以通过控制台随时启动客户机，而不是将客户机配置直接编译到 AxVisor 镜像中

6. 增加 AxVisor（ArceOS） 实时性支持。支持实时性程序直接运行在 AxVisor（ArceOS）中，可以通过虚拟化提供一个非实时性客户机来处理显示，网络等非实时应用

[ZCShou]

1. 完成 AxVisor 与 ArceOS 主线的同步

2. 完善 AxVisor 的各个 Crate 的整理

   1. 统一存放

   2. 有一个列表展示所有 Crate

   3. 文档

3. 驱动的整理

   1. 统一存放

   2. 有一个列表展示所有驱动

   3. 文档

4. 推动 ArceOS 下一个主线版本（支持动态设备树）

[ZR233]

个人已完成情况

ArceOS 层面

基于旧版ArceOS实现了以下功能

AArch64

1. EL1、EL2 的PIE 启动。
2. 平台信息动态化：cpu 数量、内存信息。
3. 驱动动态化：设备树解析，gicv2、gicv3、block、串口等自动匹配。
4. 真机验证：飞腾派、rk3588、rk3568、rk3566、树莓派

x86-64

1. 入口一般固定，不需要PIE启动。
2. 平台信息动态化：cpu 数量、内存信息。

Riscv64

1. PIE启动。
2. 平台信息动态化：cpu 数量、内存信息。
3. 驱动动态化：设备树解析，gicv2、gicv3、block、串口等自动匹配。
4. 真机验证： 星光2

Axvisor 层面

1. AArch64 适配 ArceOS 层面改动，对齐主线已有功能。
2. 真机适配并验证：飞腾派、rk3588、rk3568。

个人目前工作

AArch64 ArceOS主线动态平台适配（已完成）
Axvisor 适配AArch64 ArceOS主线动态平台（已完成验证，代码未整理）

目前问题

ArceOS主线平台配置信息接口缺少：中断信息、cpu数量、内核地址范围，导致这部分虽能动态读取，但不能上报给内核，仍使用手动填写。
ArceOS动态驱动部分已提交PR，待处理。
ArceOS缺少部分aarch64 Axvisor 所需的平台特有操作，目前通过 cfg(arch) 方式简单实现。
#187

后续工作 7.1-9.30

1. Axvisor 主线适配
2. Rust 多仓库组件统一管理方案 #187 待讨论
3. 动态驱动的完善和合并
4. USB驱动完善，并引入主线

[YanLien]

六月份主要工作内容

1. 添加对MBR/GPT分区表的支持，能够通过MBR/GPT分区读取文件系统偏移
2. 将phytium-mci接入到arceos，并在飞腾派上运行
   • 修复遇到的反复读取存储，但是无法进入shell的问题
   • 修复在使用ext4时，遇到的编译问题。
   • 支持 DMA/PIO两种方式
3. 将飞腾派的sd卡驱动和rk3568的emmc驱动结合到同一个仓库中，并正常运行

七月份后续工作

1. 重构phytium-mci驱动的DMA部分
2. 修复phytium-mci中断卡死的问题
3. 继续整合飞腾派的sd卡驱动和rk3568的emmc驱动
4. 需要把sd卡驱动适配Arceos新主线（可能）

[bullhh]

截止6月个人已完成情况

1. 完成ROC-RK3568-PC 开发板上部署 ArceOS
2. 完成在ROC-RK3568-PC开发板上部署axvisor静态平台
   （1）完成开发板上axvisor启动ArceOS
   （2）发现并解决arm_vcpu中某些中断函数未设置入口指针的bug

后续工作计划 7.1-9.30

1. 实现客户机设备树的memory节点可根据配置文件中memory_regions配置完成在加载中修改
2. 实现axvisor的smmuv3功能支持
3. 实现客户机配置文件精简优化