作为软件工程专业的一名学生，本次项目实训的内容是面向 RISC-V 架构的 OpenHarmony 移植和优化。底层系统适配涉及复杂的编译工具链和硬件驱动框架。本篇博客主要记录在 MUSE Pi v30（基于 SpacemiT K1 芯片）开发板上，进行 OpenHarmony 6.0 源码下载、环境搭建以及全量编译初期的排错过程。

关于 OpenHarmony 6.1 主线代码的获取与进阶操作，我将在下一篇博客中详细记录。

一、 开发环境准备与资源分配

编译 OpenHarmony 全量源码需要极大的系统资源。为避免编译中途因资源不足导致失败，前期环境配置必须留有充足的余量。

• 硬件配置：我为 Ubuntu 虚拟机分配了 16GB 物理内存 和 8个 CPU 核心。充足的 CPU 核心数可以提升 Ninja 多线程并发编译的效率。

• 磁盘空间：建议至少分配 300GB 磁盘空间。OpenHarmony 源码及 .repo 版本历史本身占用极大，编译过程中 out/ 目录下生成的海量 .o 目标文件、中间库以及 .ccache 缓存会快速消耗剩余空间。实测中，低于 250GB 极易在链接阶段因磁盘写满而报错。

二、 获取 OH 6.0 适配源码与 Repo 权限问题

本阶段的目标是获取进迭时空官方针对 K1 芯片适配的 OH 6.0 源码，以跑通基础的内核和系统镜像。 (参考文档与下载链接：SpacemiT K1 OH6.0 Build Flash)

在配置 repo 工具并同步源码时，遇到以下权限路径问题：

1. 直接运行提示“权限不够”：Linux 系统默认不授予下载文件可执行权限。

2. 使用 sudo 运行提示“找不到命令”：使用 sudo 提权时，系统会加载安全的全局环境变量，从而忽略当前用户 .bashrc 中配置的 ~/WorkSpace/bin 路径，导致无法找到 repo 命令。

解决方案： 无需使用 sudo，直接对文件赋予执行权限并以普通用户执行：

chmod +x ~/WorkSpace/bin/repo
repo init -u ...
repo sync -c -j8

三、 OH 6.0 编译初期的典型报错与修复方案

在执行 ./build.sh --product-name deb1 --ccache --no-prebuilt-sdk 命令进行交叉编译时，由于跳过了预编译 SDK 下载，遇到了多个依赖缺失问题。以下是核心报错及修复方法：

1. Webview 组件 SDK 库缺失 (Code: 4016)

• 错误现象：系统提示 libbundle_ndk.z.so 缺失，无法找到编译目标。

• 问题原因：交叉编译 RISC-V 架构时，系统缺少对应的 Native SDK 库文件。

• 修复方法：首先单独编译 ohos-sdk，然后手动拷贝依赖库至预编译目录。

  # 编译 SDK
  ./build.py --product-name ohos-sdk --ccache=true ...
  
  # 拷贝对应的 riscv64 库文件至目标目录
  cp out/sdk/sdk-native/os-irrelevant/sysroot/usr/lib/riscv64-linux-ohos/libbundle_ndk.z.so \
  prebuilts/ohos-sdk/linux/20/native/sysroot/usr/lib/riscv64-linux-ohos/
  

2. Hvigor 应用层组件编译失败 (Code: 4000)

• 错误现象：power_dialog、dlp_manager 等系统级 HAP 包编译失败，提示 Unable to find components: toolchains:20。

• 问题原因：上述组件属于上层 UI 应用，构建过程强依赖完整的 Node.js 环境及 OpenHarmony SDK。在底层硬件移植阶段，这些组件并非内核启动的必需项。

• 修复方法：修改编译脚本 build/scripts/compile_app.py，直接跳过应用包的实际编译过程，返回成功状态，以优先保障内核和 HDF 驱动框架的编译。

  # 在 compile_app.py 中截断执行
  import sys
  # ... 写入空 JSON 以通过文件生成检查 ...
  sys.exit(0) # 直接返回 0 表示成功
  

3. HDI 接口头文件路径错误 (Code: 4000)

• 错误现象：编译 Display 驱动或多模输入（Multimodal Input）服务时，提示 display_composer_type.h 或 ievent_filter.h 找不到，或出现重定义错误。

• 问题原因：RISC-V 厂商代码中的 include 路径配置与实际生成的路径不一致，或编译器误读取了 test/ 目录下的测试用例文件而非 out/deb1/gen/ 下的实际生成文件。

• 修复方法：使用 find 命令在源码或生成目录中定位正确的头文件，直接将其 cp 拷贝至报错模块所包含的 include/ 或 gen/ 目录下，修正路径依赖。

4. 磁盘空间耗尽导致 .git 软链接失效

• 错误现象：内核编译脚本 build_kernel.sh 崩溃，提示 cp -rL 失败: 调用 stat 失败。

• 问题原因：编译后期磁盘空间不足，我手动删除了 .repo 目录以释放空间。此操作导致源码子目录下的 .git 文件夹全部变为无效软链接。内核打包使用的 cp -rL 命令在跟随这些死链时发生异常。

• 修复方法：全局查找并删除损坏的软链接文件，随后恢复编译。

  find . -name ".git" -type l -delete
  

四、 阶段性总结

通过排查上述工具链和依赖问题，OH 6.0 的编译流程已成功走通，系统最终在 out/deb1/packages/phone/images/ 目录下生成了底板所需的 boot.img 与 system.img。这标志着底层内核和基础驱动编译环境的完全打通。

为了进一步分析最新系统的架构演进和性能优化点，我们还需要获取 OpenHarmony 主线代码。关于 OpenHarmony 6.1 源码的具体拉取操作与后续的目录结构分析，我将在下一篇博客中详细记录。