现代计算系统依赖于高性能处理器, 而ISA作为操作系统和芯片之间的接口规范, 对于设计一个优秀的处理器至关重要. RISC-V指令集架构由加州大学伯克利分校的Waterman等人于2010年发起^[1], 近年来引起了极大关注, 并逐渐成为与x86和ARM并列的主流指令集. 作为一个开放、可扩展和安全的ISA, RISC-V未来在服务器、个人电脑、智能手机、物联网和其他计算设备中具有相当大的潜力^[2].

随着RISC-V ISA的快速发展, 面向RISC-V的操作系统成为近年来研究领域的热点. 目前, 国内外主流的操作系统发行版本已经陆续支持RISC-V架构^[3,4], 例如openEuler、openKylin^[5]、Ubuntu、Debian、FreeRTOS、FreeBSD等, 主要面向嵌入式、桌面和服务器设备. 然而, 由于RISC-V是一种新兴的硬件架构, 其操作系统领域在性能、功能和应用生态等方面仍存在诸多问题需要解决. 操作系统不仅要具备有效地管理计算机系统的硬件资源的能力, 还要提供必需的标准功能服务支撑上层应用, 并且需要为用户提供友好的人机交互功能, 以提高系统的易用性. 智能终端设备的数量持续高速增长, 催生出了更加碎片化、多样化的需求和场景, 从而对新一代操作系统提出了更高的要求^[6].

OpenHarmony (OH)是面向分布式全场景、开源开放的智能终端操作系统. 官方标准系统支持ARM架构相关开发板平台, 但缺乏对RISC-V架构的支持. 自2022年以来, RISC-V硬件生态陆续推出高性能开发板, 如VisionFive2和Lichee Pi 4A, 并且面向操作系统领域诞生了一些RISC-V特有的软件栈, 如蓬莱TEE. 同时, OH硬件平台的使用需求量不断增大, 目前, 已经有14所高校成立了OH技术俱乐部. 因此, 为了丰富RISC-V软硬生态产品的应用领域并为学生提供一个快速开发、调试和测试的OH硬件平台, 构建一个基于RISC-V虚拟化平台的OH标准系统是非常吸引人的. 然而, 随着RISC-V硬件平台的发展, 必须解决许多挑战, 如系统构建、硬件适配和应用程序生态系统.

本文介绍了基于QEMU RISC-V架构的OH移植技术. 我们首先明确了RISC-V平台的OH标准系统支持的整体方法, 然后在RISC-V架构上移植了OH标准系统包括的主要软件栈, 如工具链、编译系统、基础C库、ARK运行时等, 并基于QEMU RISC-V Virt平台进行图形显示模块的移植, 从而使RISC-V架构平台上的OH标准系统成功进入系统桌面.

1 基于RISC-V平台的OH标准系统 1.1 OH标准系统介绍

OH是一个旨在构建一个全场景、全连接的智能终端操作系统. OH的设计目标是支持多种设备类型, 包括手机、平板电脑、智能穿戴设备、智能家居设备、车载系统等. 它提供了一个统一的开发平台和开发框架, 使开发者能够更轻松地开发应用程序, 并且能够在不同设备上无缝运行^[7].

OH支持轻量(面向MCU类处理器例如ARM Cortex-M、RISC-V 32位的设备)、小型(面向应用处理器例如ARM Cortex-A的设备, 支持的设备最小内存为1 MiB)和标准系统(面向应用处理器例如ARM Cortex-A的设备, 支持的设备最小内存为128 MiB), 这种划分允许OH适配不同级别的硬件设备, 使其具有广泛的适用性和灵活性. 本文工作只面向标准系统, 其软件栈主要包括内核、硬件抽象HDF、系统服务层、框架层和应用层.

1.2 RISC-V平台的OH标准系统架构

目前, 面向Ubuntu、Fedora和openEuler等Linux操作系统的RISC-V架构移植主要面临两大难点, 即内核适配和广泛的软件包支持. 内核适配需要确保硬件平台通过引导加载程序正确运行内核, 并支持RISC-V架构的特性和功能. 由于这些Linux操作系统拥有广泛的软件包生态系统, 为适配新的架构, 需要重新编译和调整软件包, 并投入大量的人力. 虽然OH标准系统同样基于Linux内核, 但作为智能终端操作系统, 依赖于大量的设备驱动程序, 包括图形、摄像头、无线网络等. 在RISC-V架构上移植OH时, 需要重新编写或调整这些驱动程序, 以适配新的架构和硬件设备. 此外, OH标准系统为不同硬件平台提供了特定的功能和优化, 如传感器、GPS、移动网络等, 移植时需要解决这些平台特定功能的支持. 最后, OH拥有其特定的应用程序生态系统, 无法参考其他Linux操作系统应用移植. 综上所述, 与常见的Linux操作系统相比, 大量的驱动适配和不同硬件平台的定制化适配导致OH标准系统的RISC-V移植难度更高.

另外, OH标准系统在RISC-V架构平台还面临许多挑战. 首先, RISC-V软件生态目前还处于发展阶段, 与x86和ARM相比, 指令集相关的软件栈功能尚不完善. 因此, 我们需要对OH依赖的软件栈进行功能的移植, 尽可能与ARM架构对齐, 以确保OH能够在RISC-V平台上正常运行. 其次, OH标准系统提供了增强的交互能力、3D GPU以及硬件合成能力, 然而, 目前满足这些需求的RISC-V开发板较少, 并且相应的驱动模块不完善.

为了解决上述提到的挑战, 我们提出了OH标准系统RISC-V移植架构, 见图1所示. 首先, 面对RISC-V硬件平台数量有限且性能弱的问题, 我们选择基于QEMU RISC-V虚拟化平台进行移植, 并采用VirtIO虚拟化驱动模块作为设备驱动, 以实现与QEMU RISC-V架构的驱动对接. 其次, OH标准系统在RISC-V架构上的支持主要集中于架构强相关的软件栈, 比如编译工具链、编译框架、musl libc库、ARK运行时, 以及其他依赖包, 包括unwind解析库、编解码库和图形库等. 最终, 在QEMU RISC-V虚拟化平台上成功启动了OH标准系统, 并运行了系统基础应用, 例如设置、时钟和计算器等.

2 QEMU RISC-V架构的OH标准系统移植 2.1 架构强相关软件栈移植

为实现OH标准系统软件栈在RISC-V架构上的移植, 首要工作是确保工具链对RISC-V的支持和适配编译子系统, 以满足OH所有软件栈在RISC-V架构下的编译构建需求. 其次, 我们通过关键字索引的方法定位OH标准系统中与架构强相关的软件栈, 明确当前OH版本需要移植的代码仓列表. 这些架构强相关的代码主要涉及编译脚本、汇编代码以及与架构相关的函数实现和宏定义等. 在完成所有架构相关的代码仓适配后, 我们即可编译构建适用于RISC-V 64架构的通用软件包, 为后续的芯片移植工作提供支撑. 整体流程详见图2.

2.1.1 工具链适配

OH的源码已完全使用Clang来进行系统的整体构建. OH工具链^[8]主要包括LLVM和libcxx-ndk.llvm提供了Clang compiler, lldb, Clang-tidy等工具, 以及面向不同目标设备的libc++、Clang_rt、asan、fuzzer库. 在LLVM工具链编译完成后, 再构建libcxx-ndk, 其包含了对目标平台ndk的支持的libc++库.

目前, LLVM社区^[9]已支持RISC-V指令集架构. 因此, 工具链的适配工作主要是为RISC-V添加工具前缀、架构配置以及运行时库相关的支持. 通过build.py脚本按照图3所示流程完成工具的生成.

同时, OH标准系统在面向RISC-V架构编译构建时往往会出现工具链导致的兼容性报错, 需要持续解决和优化^[10]. 例如, OH中将配置、图片等文件通过objcopy转换成二进制文件, 而在LLVM12 RISC-V版本中, 链接器对二进制文件进行了判断, 非体系架构二进制文件会导致报错. 为解决这一编译报错, 我们通过删除此判断, 详细信息见图4.

RISC-V指令具有模块化的特点. 随着不同平台对扩展指令(如V扩展)的支持不断优化, 我们可以在LLVM中添加指令和寄存器的tablegen相关描述, 从而使OH标准系统能够得到相应RISC-V硬件平台扩展指令的加速优化.

2.1.2 编译框架和构建支持

OH编译构建子系统采用基于GN和ninja^[11,12]的编译构建框架. 根据产品配置, 可生成对应的镜像包. 编译构建流程如下.

(1) 使用GN配置构建目标.

(2) GN生成ninja文件.

(3) 通过运行ninja执行编译任务.

OH编译构建子系统位于build目录下, 主要包括编译相关的Python脚本、配置项、编译入口BUILD.gn配置以及编译打包流程配置, 还有kits、ndk、notice版本打包、sa和sdk模板和处理流程、编译工具链配置等. 针对新的RISC-V指令集架构, 需要维护函数库路径、编译链接选项、ABI、架构名称字串、架构名称匹配、工具链的路径和参数, 以及与指令集架构相关的编译配置等.

2.1.3 musl C库适配

基础C库主要封装了常用内存操作函数、内核提供的系统调用和数据结构等, 为用户态程序提供了标准化的接口. OH基础C库采用了musl^[13], 它是一个为 Linux 基本系统实现的轻量级、快速、简单、免费、标准兼容和安全的标准库. musl已支持RISC-V指令集. 在OH的GN编译脚本中, 首要工作是添加RISC-V架构选项和架构编译配置. 同时, 为了与ARM架构功能对齐, 需要参考OH musl已支持的ARM架构, 对部分汇编源码和脚本进行RISC-V架构适配, 解决由于指令集导致的兼容性问题. 具体代码示例详见图5.

2.1.4 ARK运行时支持

方舟编译器(ArkCompiler)^[14,15]是一个统一的编译运行时平台, 旨在支持多种编程语言和多种芯片平台的联合编译和运行. ArkCompiler主要包括编译工具链和运行时两个部分.

ArkCompiler的编译工具链以ArkTS/TS/JS源码作为输入, 将其编译生成为abc (ArkCompiler Bytecode, 即方舟字节码)文件.

ArkCompiler运行时直接运行字节码文件, 实现对应语言规范的语义逻辑.

该子系统包含ets_runtime (ArkTS运行时组件)、runtime_core (运行时公共组件)、ets_frontend (ArkTS语言的前端工具)和toolchain (ArkTS工具链).

移植RISC-V的关键在于与体系架构相关的运行时公共组件和ArkTS工具链. 目前, 官方ArkTS工具链已经支持RISC-V架构. 因此, 主要的移植工作是完成运行时公共组件中RISC-V指令集的汇编功能和RISC-V架构的编译配置. 此外, 还需要为ArkTS运行时组件添加RISC-V架构编译配置.

2.1.5 其他架构相关组件和三方库

除了上述提到的关键软件栈移植之外, 还需要对部分OH组件和依赖的第三方库进行编译配置和少量源码的适配工作. 具体列表如表1和表2.

2.2 基于QEMU RISC-V架构的OH芯片移植-图形显示模块

OH标准系统芯片移植主要包括产品配置添加、内核启动、升级、音频ADM化、Camera、TP、LCD、WiFi、BT、vibrator、sensor和图形显示等模块的适配. 图形显示模块作为智能终端操作系统的核心功能, 移植优先级最高. 本文将以QEMU RISC-V虚拟化平台为设备主体, 完成OH图形显示模块的适配, 实现在RISC-V架构平台上运行OH, 并通过launcher启动OH桌面.

2.2.1 OH图形显示模块

OH显示模块架构如图6所示. 图形显示模块主要由平台驱动层、芯片平台适配层和LCD器件驱动层3部分组成.

(1) Display平台驱动层

该层通过HDF (hardware driver framework)提供的IOService数据通道, 与公共HAL (hardware abstract layer)对接, 集中接收并处理各类上层调用指令.

(2) SoC平台驱动适配层

此SoC适配层在内核态实现HDF display驱动和SoC侧驱动(标准的显示框架)解耦, 主要完成芯片平台相关的参数配置, 并将平台驱动层的调用传递到器件驱动层.

(3) LCD器件驱动层

器件驱动层^[16]主要实现与器件自身强相关的驱动适配接口, 例如发送初始化序列、上下电、背光设置等.

基于display驱动模型开发LCD驱动, 可以借助平台提供的各种能力和接口, 较大程度地降低器件驱动的开发周期和难度, 提升开发效率.

2.2.2 OH内核移植

(1) 添加显示相关配置

QEMU RISC-V虚拟化平台^[17,18]官方已支持多种RISC-V硬件仿真平台, 例如sifive_u、shakti_c、virt等. 本方案将选择QEMU RISC-V Virt Machine, 该平台是为RISC-V软件开发和测试而创建的虚拟平台, 它使用 VirtIO 设备进行网络、存储和其他类型的IO.

OH的图形驱动采用DRM图形框架, QEMU可以使用“virtio-gpu”设备模拟器来模拟VirtIO GPU驱动程序, 该驱动程序可以运行在QEMU虚拟机中, 并与实际GPU硬件交互. Linux内核已对该驱动提供支持, 需要再内核配置中打开VirtIO相关配置项.

CONFIG_DRM_VIRTIO_GPU=y

CONFIG_VIRTIO=y

CONFIG_VIRTIO_MENU=y

CONFIG_VIRTIO_PCI=y

CONFIG_VIRTIO_PCI_LEGACY=y

CONFIG_VIRTIO_BALLOON=y

CONFIG_VIRTIO_INPUT=y

CONFIG_VIRTIO_MMIO=y

我们通过完成上述内核配置, 在运行于QEMU RISC-V虚拟化平台上的Linux操作系统中, 用户态即可发现LCD设备/dev/dri/card0, 从而实现OH display HDI对QEMU DRM/GPU的功能的正常访问.

(2) HDF内核态(khdf)补丁

khdf主要包含驱动程序、驱动配置、驱动资源, 是OH驱动开发的基础公共部分. 它完成了驱动的公共逻辑, 资源配置、资源解析以及驱动的加载和初始化功能. 此部分工作主要将OH HDF内核补丁移植至Linux kernel中.

2.2.3 HAL层适配

基于RISC-V的OH HDF驱动开发流程分为两步. 第1步是移植HDF内核态程序khdf, 第2步是完成uhdf的适配, 包含peripheral和framework的适配.

在uhdf适配中, 主要进行用户空间的HDF移植. OH提供了标准的调用流程和使用示例, 位于Peripheral目录中, 用于各个驱动外围设备. 通过遵循HDI (hardware driver interface), 我们能够进行适配、开发和测试, 并保证测试用例通过.

在display HDI中, 需要进行display_device和display_gralloc两部分的适配.

(1) Display device

Display device模块提供显示设备管理、layer管理、硬件加速等功能. 在该部分, 我们需要定义DRM设备节点.

在hardware/display/src/display_device/drm_device.cpp文件中, 我们将DRM设备节点名称修改成QEMU RISC-V架构对应的“virtio_gpu”节点.

由于QEMU RISC-V架构目前不支持硬件合成, 我们需要在drm_display.cpp文件中跳过gfx的初始化, 并在hardware/display/src/display_device/hdi_gfx_composition.cpp文件中修改set_layers方法, 使用CPU合成显示.

(2) Display gralloc适配

Gralloc模块提供显示内存管理功能. 在这部分适配中, 需要根据实际情况修改hardware/display/src/display_gralloc/display_gralloc_gbm.c文件中的DRM设备节点.

const char *g_drmFileNode = “/dev/dri/card0”;

2.2.4 OH 图形子系统适配

在完成上述底层内核DRM驱动对接和HAL层适配后, 我们需要确保图形子系统中graphic、render、bootanimation、launcher等服务正常运行^[19]. 该部分属于上层组件, 第2.1节已完成适配移植工作.

2.3 编译构建并启动QEMU RISC-V架构OH标准系统 2.3.1 编译构建

面向OH标准系统QEMU RISC-V架构平台, 我们定义了qemu_riscv64_virt_linux_system的产品配置. 在完成上述OH主要软件栈RISC-V移植和图形显示模块的芯片移植后, 我们可以通过执行./build.sh --product-name qemu_riscv64_virt_linux_system来编译出QEMU RISC-V架构的OH镜像, 其中包含内核Image和文件系统ramdisk.img、system.img、updater.img、userdata.img和vendor.img镜像.

2.3.2 QEMU RISC-V启动OH

在运行OH之前, 我们需要在宿主机安装QEMU虚拟机^[20]. 本文实验是在x86-64位的Windows环境, 安装官方QEMU 7.0版本(支持RISC-V架构).

QEMU RISC-V 64虚拟平台硬件参数通过启动命令对设备名称、分配内存、CPU核数和各设备驱动等进行配置. QEMU RISC-V架构默认使用OpenSBI^[21]引导, 并加载内核, 启动OH标准系统文件系统中的init程序.

成功启动OH后, 运行开机动画并进入锁屏界面如图7所示, 鼠标解锁后正常进入OH界面如图8所示.

当前, OH标准系统(适配版本3.2 beta2)的应用生态相对缺失, 目前仅对原生系统自带的应用, 如设置、计算器、时间等进行测试, 这些系统应用可以正常运行.

在代码量方面, 该工作涉及了OH标准系统中34个代码仓的适配, 新增了3个代码仓, 共计新增18000多行代码.

RISC-V开发板上的OH标准系统移植包括工具链构建、OH三方库适配、OH子系统组件适配和芯片移植4个部分工作. 前3部分的工作具有复用性, 对于新的RISC-V开发板移植, 只需完成芯片移植工作, 因此我们提供了QEMU RISC-V虚拟平台的芯片移植的参考, 为RISC-V开发板在OH标准系统上适配提供了80%以上的参考依据.

该移植工作的源码和附带的文档是开源的, 读者后续可在聚元PolyOS社区^[22]下载.

3 结论与展望

针对OH不支持RISC-V架构平台的问题, 我们在QEMU RISC-V架构上成功移植了OH标准系统, 并得出以下经验总结, 希望可以为其他架构迁移工作提供借鉴.

(1) 硬件支持: 在进行架构迁移前, 首先需要了解清楚目标RISC-V平台的硬件特性、指令集支持以及设备驱动等关键信息. 确保目标平台与OH的要求和功能相匹配, 避免硬件兼容性问题, 是成功迁移的关键基础.

(2) 内核调整: 针对RISC-V架构进行必要的内核适配和配置, 确保内核能够正确启动并支持目标平台的硬件特性. 它是整个迁移过程中最核心的一步, 也是保证系统稳定性和性能的关键.

(3) 驱动程序适配: 设备驱动程序的适配是确保目标平台上硬件设备能够与OH系统正常通信和工作的关键步骤. 系统需要完整的硬件支持, 驱动程序适配是其中不可或缺的一环.

(4) 解决指令集差异: RISC-V指令集可能与现有的OH所基于的ARM架构存在差异. 因此, 在进行移植工作时, 需要仔细解决指令集差异, 进行指令集转换和适配工作, 以确保软件在新的架构上能够正确运行.

(5) 选择合适的OH版本: 选择与目标平台相匹配的OH版本是保证兼容性的重要因素. OH标准系统存在多个版本, 为了保证成功迁移, 需要选择与目标平台相匹配的OH版本. 这样可以确保内核和应用程序的兼容性, 避免不必要的兼容性问题和冲突.

(6) 应用程序兼容性: 应用程序兼容性对于整个迁移工作非常重要, 确保OH应用程序能够在新的RISC-V平台上正确运行, 需要重新编译或调整应用程序以适应新的硬件和操作系统环境. 对于核心应用程序, 兼容性测试是必不可少的.

(7) 开源社区合作: 参与开源社区合作是推进RISC-V生态和OH移植工作的重要手段. 与其他开发者分享经验, 寻求帮助和合作, 同时也可以获得更多有用的经验和资源. 在开源社区中共同探讨和解决问题, 可以大大提高迁移工作的效率和质量.

在进行类似工作时, 重点关注硬件支持、内核调整、驱动程序适配和解决指令集差异等方面, 可以有效地引导开发者完成架构迁移, 提高工作的成功率和效率.

这项工作促进了RISC-V软硬生态的发展. 通过提供开源的虚拟化环境, 我们为RISC-V OH应用生态提供了支持, 使开发者能够快速进行RISC-V平台的OH应用开发和测试. 此外, 我们为不断发布的RISC-V开发板提供OH芯片移植参考, 大大提高了RISC-V开发板在OH的适配效率, 丰富了OH的硬件生态, 并推动了OH开源社区的发展.

目前QEMU RISC-V架构已初步完成OH图形模块的移植. 接下来, 我们将继续推进音频、网络、键鼠、摄像头等驱动模块的芯片移植工作, 为开发者提供更全面的驱动设备支持, 提升用户的交互体验. 同时, 我们还将对QEMU RISC-V架构的功能和稳定性进行验证测试, 并结合与ARM架构相比的性能差异点进行优化^[23], 例如指令集的使用效率、缓存和内存访问的优化等. 随着OH上层UI组件的不断迭代, 应用生态将逐渐丰富. 我们将对各类应用进行适配测试, 以验证系统移植的正确性和鲁棒性.