项目启动与环境搭建实践

一、项目背景与研究意义

随着国产基础软件生态的持续发展，操作系统、芯片架构与人工智能推理框架之间的协同优化，正在成为当前计算机系统领域的重要研究方向。OpenHarmony 作为开源分布式操作系统，具备轻量化、可扩展、跨设备协同等特点，在物联网终端、工业控制、智慧教育、智能家居等场景中具有广阔应用前景。

另一方面，RISC-V 作为开源指令集架构，具有开放透明、模块化设计、授权成本低、可定制化程度高等优势，近年来已成为国产芯片生态的重要发展方向。越来越多的国产 SoC、边缘计算设备和嵌入式平台开始采用 RISC-V 架构，这也对操作系统的适配能力提出了更高要求。

本次创新项目实训围绕 “面向 RISC-V 的 OpenHarmony 移植与优化” 展开，目标是在进迭时空 K1 芯片平台上推动 OpenHarmony 系统从 6.0 版本升级至 6.1 版本，并结合端侧大模型部署需求，对系统性能进行进一步优化。该项目既涉及操作系统底层移植，又涉及 AI 推理加速与体系结构优化，具有较强的工程实践价值与技术挑战性。

二、开发环境标准化部署

在操作系统移植类项目中，开发环境是否稳定，直接决定后续编译效率与协作效率。因此项目启动后，我们首先开展环境搭建工作。

2.1 Ubuntu 虚拟机环境部署

考虑到 OpenHarmony 官方工具链及依赖环境主要面向 Linux 平台，我们统一采用 Ubuntu 系统进行开发。

本次使用环境：

Ubuntu 22.04 LTS
VMware Workstation 虚拟机
4 Core CPU
16GB RAM
120GB SSD

2.2 编译依赖安装

 根据 OpenHarmony 构建要求，安装如下依赖组件：

sudo apt update
sudo apt install git git-lfs curl python3-pip zip unzip \
build-essential flex bison gperf ccache repo \
openjdk-19-jdk nodejs npm

重点依赖说明：

组件	作用
git-lfs	拉取大文件资源
repo	多仓库源码管理
ccache	提升增量编译速度
nodejs	ArkTS 构建依赖
Java	部分工具链运行依赖

2.3 ext4 镜像工具安装

OpenHarmony 编译过程中需要生成 system.img 等 ext4 文件系统镜像，因此需安装 make_ext4fs 工具。

部署过程：

unzip bin.zip
chmod +x ~/workspace/bin/*

配置环境变量：

export PATH=$PATH:/home/humm/workspace/bin
source ~/.bashrc

验证结果：

make_ext4fs

若输出：

Expected filename after options
make_ext4fs [ -l <len> ] [ -j <journal size> ] [ -b <block_size> ]
    [ -g <blocks per group> ] [ -i <inodes> ] [ -I <inode size> ]
    [ -L <label> ] [ -f ] [ -a <android mountpoint> ]
    [ -S file_contexts ] [ -C fs_config ] [ -T timestamp ]
    [ -z | -s ] [ -w ] [ -c ] [ -J ] [ -o ] [ -v ] [ -B <block_list_file> ]
    <filename> [<directory>]

说明工具安装成功。

三、源码仓库访问准备（SSH 认证）

由于项目源码托管在如意社区代码仓，因此需完成 SSH 公钥认证。

3.1 生成 SSH Key

ssh-keygen -t rsa -b 4096

查看公钥：

cat ~/.ssh/id_rsa.pub

然后将公钥添加至平台账户 SSH Keys 页面。

3.2 遇到的问题：Fingerprint 已被使用

在添加过程中出现：

Fingerprint sha256 已经被使用

该问题说明当前公钥已绑定账号。最终通过直接验证 SSH 连接确认授权状态：

ssh -T git@code.openruyi.cn

若连接成功，则可继续拉取代码。

这一过程让我认识到：大型开源项目的准备工作不仅仅是写代码，版本控制与权限管理同样重要。

四、源码拉取与构建规划

完成基础环境配置后，项目进入源码准备阶段。由于本项目基于如意社区提供的 RISC-V OpenHarmony 代码仓库，因此源码获取采用 repo + git-lfs 的方式进行统一管理。

与普通单仓库项目不同，OpenHarmony 采用多仓协同结构，系统内核、驱动、编译系统、基础库、应用框架等内容分别位于不同仓库中，因此必须使用 repo 工具统一拉取。

4.1 初始化代码仓库

首先创建项目目录并初始化 manifest：

mkdir oh6.1
cd oh6.1

repo init -u git@code.openruyi.cn:risc-verse/ruyi-desktop-os/manifest.git \
-b OpenHarmony-v6.1-Release-RISC-V \
--no-repo-verify

其中：

参数	含义
-u	manifest 仓库地址
-b	指定 OpenHarmony 6.1 RISC-V 分支
--no-repo-verify	跳过 repo 自检

4.2 同步源码

repo sync -j4 -c --fail-fast

说明：

---

-j4：4线程下载

-c：仅同步当前分支

--fail-fast：发生错误立即停止

---

4.3 拉取大文件资源

系统构建中涉及 SDK、音视频资源、预编译工具包等大文件，因此需执行：

repo forall -c 'git lfs pull'

4.4 源码目录结构

这意味着系统源码准备完成，可进入构建阶段。

五、系统构建方案与编译效率优化

5.1 工具链下载

进入源码根目录后执行：

bash build/prebuilts_download.sh

下载文件统一存放于：openharmony_prebuilts

5.2 修复 RISC-V 工具链覆盖问题

预编译工具链下载后，部分 RISC-V 编译链可能被覆盖，因此需重新同步：

repo sync toolchains_llvm_riscv
repo sync spacemit-riscv-gcc

该步骤能够避免后续出现：

---

unknown target riscv64
toolchain not found
linker error

---

5.3 首次完成编译

在完成源码同步与工具链修复后，重新执行完整编译流程：

cd ~/workspace/oh6_riscv
./build.sh --product-name qemu_riscv_mini_system_demo --ccache --prebuilt-sdk -j4

首次完整编译主要经历以下三个阶段：

① Preloader 阶段

• 解析 product 配置（product.json）
• 初始化 device / subsystem 信息
• 生成 parts.json

② GN 生成阶段

• 构建 GN target 依赖图
• 解析 BUILD.gn
• 生成 Ninja 构建文件

③ Ninja 编译阶段

• 调用 RISC-V 工具链进行源码编译
• 生成 .o / .a / bin 文件
• 输出到 out 目录

编译结果说明

编译成功后，输出目录结构如下：

out/riscv32_virt/qemu_riscv_mini_system_demo/
├── build.ninja
├── obj/
├── gen/
├── images/
└── kernel.img

首次编译意义

1. OpenHarmony 构建链路完全跑通
2. RISC-V 工具链配置正确
3. device + vendor + subsystem 配置一致
4. GN → Ninja 构建体系正常工作

六、本阶段总结

通过本阶段对 OpenHarmony 6.1 RISC-V 编译流程的实践，可以明确 OpenHarmony 构建体系并不仅仅是代码编译过程，而是一个高度依赖配置驱动的复杂工程系统。

在实际操作中，首次完整编译经历了多个问题的排查与修复，包括设备配置缺失、subsystem 解析异常以及工具链环境不一致等情况。这些问题本质上都指向同一个核心：构建系统对配置文件、依赖关系以及工具链环境的严格一致性要求。

特别是在 RISC-V 交叉编译环境中，工具链（LLVM / GCC）的版本一致性与路径完整性直接影响 GN 阶段与 Ninja 阶段的执行结果。一旦工具链被覆盖或路径异常，就会导致 target 无法识别或链接失败等问题。

总体而言，本阶段不仅完成了 OpenHarmony 在 RISC-V 平台上的首次编译验证，也对其构建体系的结构化设计有了更直观的理解，为后续系统启动与功能调试打下了基础。