前两篇先把工程身份和板级关系拆清楚，这一篇只回答一个可复现的问题：当前小鸿本体怎样从 OpenHarmony mini 产品走到 WS63 可用的 .fwpkg。这不是把 README 命令再抄一遍，而是记录 2026 年 7 月 24 日在本地完整源码树中真正执行过的命令、遇到的失败、采用的兼容路径，以及最后产物的大小和 SHA-256。

先给结论：本轮最终构建退出码为 0，HB 返回 build success，Ninja 完成到 [22/22] STAMP，生成了 ws63-liteos-app_all.fwpkg。但是当前检出、本机 HB 与 WS63 SDK 的组合不能直接把 README 中的 hb build -f 当作唯一命令；默认流程会请求一个不存在的 images 目标。本文因此把“文档入口”和“本机已验证入口”分开写，并明确保留本地 LiteOS-M 兼容补丁的边界。

先锁定 mini、LiteOS-M 与 WS63 SDK v106

当前对象是 vendor/atomgit/xiaohong，不是 xiaohong-p4 的 ESP-IDF 工程。真实配置文件 vendor/atomgit/xiaohong/config.json 给出 type: mini、kernel_type: liteos_m，第三方目录指向 hisilicon/ws63v100/sdkv106/open_source。这三项共同决定后续使用 HB/GN 和 RISC-V 交叉编译工具链，输出也是 WS63 的 .fwpkg，不是 HarmonyOS 应用的 HAP，也不是 ESP32 的多个 .bin 下载组合。

下面是当前文件的原样摘录。ohos_version 是产品配置字段，不能单独替代当前 Git 分支；本文同时用 OpenHarmony-6.1.0.31-Release 分支、基础提交和文件哈希定位源码。

{
  "product_name": "xiaohong",
  "type": "mini",
  "version": "3.0",
  "ohos_version": "OpenHarmony 1.0",
  "device_build_path": "device/board/atomgit/xiaohong",
  "board": "xiaohong",
  "kernel_type": "liteos_m",
  "kernel_is_prebuilt": true,
  "third_party_dir": "//device/soc/hisilicon/ws63v100/sdkv106/open_source",
  "product_adapter_dir": "//vendor/atomgit/xiaohong/hals"
}

文档命令是入口，不是本机成功证据

项目 README 给出的正常使用方式是在 OpenHarmony 源码根目录通过 hb set 选择产品，然后执行 hb build -f。这条命令表达的是产品级构建意图，仍然是首次配置环境时应该知道的入口。

# 在 OpenHarmony 源码根目录执行
hb set
hb build -f

但命令是否对“当前检出 + 当前 HB 版本 + 当前 SDK”有效，必须看本次退出码和日志，不能用文档描述代替。在本轮环境中，GN 生成阶段能够完成，随后 Ninja 报告 unknown target 'images'。也就是说，失败点不是小鸿业务 C 文件的语法，而是 HB 默认请求的顶层目标与当前生成图不一致。

先识别 images 目标错位，再找真实 SDK 入口

排查时不能看到 images 就自行创建一个同名空目标，否则只会把问题藏起来。继续沿设备 SoC 目录反查，可以在 device/soc/hisilicon/ws63v100/sdkv106/BUILD.gn 找到 run_sdk_build。它通过 build_ext_component 调用 hm_build.sh，把 OpenHarmony 输出目录、WS63 SDK 开关和 XTS 开关传给厂商 SDK 构建。

下面是本次本地兼容文件中的真实连续片段。为了适配当前 LiteOS-M 组合，依赖只保留 :sdk 和 //build/lite:ohos；这是文章记录的本地兼容补丁，不冒充上游原始文件。

build_ext_component("run_sdk_build") {
  exec_path = rebase_path(".", root_build_dir)
  outdir = rebase_path(root_out_dir)
  command = "bash hm_build.sh $outdir $build_ws63_sdk_open $build_xts"
  deps = [
    ":sdk",
    "//build/lite:ohos",
  ]
}

本轮随后把 GN 根目标临时指向 //device/soc/hisilicon/ws63v100/sdkv106:run_sdk_build，并显式执行 hb build -T run_sdk_build。这种做法的价值是目标边界清楚：HB 仍负责生成，Ninja 只执行已经确认存在的 SDK 目标，不再假设当前构建图一定提供 images。

LiteOS-M 依赖不完整时要做最小兼容

把根目标切回完整 //build/lite:ohos 后，本轮还遇到了若干 external_deps 在当前 WS63 产品组合中不可用的问题，集中在 startup/init 与设备标识等 LiteOS-M 路径。这类错误必须区分两种情况：一是产品确实需要某能力但组件没配置，二是通用构建文件把仅适用于其他系统形态的依赖带进了当前小型系统。

本轮采用的是第二类处理：只对当前 liteos_m 条件裁掉不可提供的依赖，并为 WS63 已经捆绑的 mbedTLS 指定包含路径；SDK 的 run_sdk_build 目标也移除了当前产品未提供的 HiChain 依赖。改动范围包含 .gn 和 9 个 BUILD*.gn 文件，每个补丁文件都单独记录了 SHA-256。构建完成后，所有这些源文件已与构建前备份逐一比较并恢复。

这一步的正确结论是“本机经过兼容适配后构建成功”，不是“仓库原始检出开箱即构建成功”。如果后续要把补丁产品化，应拆成独立提交，逐项解释依赖为何对 WS63/LiteOS-M 不成立，并重新执行完整回归。

工具链 PATH 必须指向 SDK 自带的 RISC-V 编译器

目标正确后，第一次 run_sdk_build 仍然失败，直接原因是 Shell 找不到 riscv32-linux-musl-gcc。SDK 已经带有对应工具链，但当前 WSL 会话没有把其 bin 目录放入 PATH。因此最终命令只在当前进程前置 SDK 编译器路径，没有永久改写用户配置。

cd /opt/xiaohong

env PATH=/opt/xiaohong/device/soc/hisilicon/ws63v100/sdkv106/tools/bin/compiler/riscv/cc_riscv32_musl_105/cc_riscv32_musl/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
  hb build -T run_sdk_build

这段命令适用于本文记录的 WSL 路径，不能直接粘贴到 Windows PowerShell。若源码根目录不同，应只替换 /opt/xiaohong 部分，并先用 command -v riscv32-linux-musl-gcc 验证最终解析到 SDK 中的编译器。

历史 root 产物会制造与源码无关的失败

工具链问题解决后，本轮还依次遇到 SDK 中间目录、签名临时文件、补丁临时目录和 efuse.csv 的权限错误。它们的共同点是历史构建由 root 执行，当前非 root 用户能够读取源码，却无法覆盖生成文件。这不是 C/GN 实现问题，也不应该靠反复重跑掩盖。

处理前先查看准确路径的属主，再只修复当前构建需要写入的输出或生成目录。不要对整个 WSL 根目录执行递归 chown，也不要为了省事长期使用 root 构建。源文件如果确实需要临时修改，应先做备份、保存哈希，完成后恢复属主、模式与内容。

# 只做诊断，先确认具体阻塞路径
stat -c '%U:%G %a %n' \
  out/xiaohong/xiaohong \
  device/soc/hisilicon/ws63v100/sdkv106/interim_binary \
  device/soc/hisilicon/ws63v100/sdkv106/output

# 构建后核对源文件是否恢复
sha256sum .gn
sha256sum device/soc/hisilicon/ws63v100/sdkv106/BUILD.gn

本文不提供对未知目录的通配递归改权命令，因为那会把正常的源码所有权一并改变。实际修复只落在已经由错误日志确认的目标上，且构建后重新检查了源文件内容。

HB、GN、SDK 脚本和打包各自负责什么

这一条链可以分成四层。HB 读取产品选择并驱动 GN；GN 根据产品配置和 BUILD.gn 生成 Ninja 图；run_sdk_build 进入 WS63 SDK 的 hm_build.sh；SDK 完成编译、链接、镜像处理和 .fwpkg 打包。小鸿业务库是否进入应用镜像，仍由 vendor/atomgit/xiaohong/xiaohong/BUILD.gn 的 sources 和依赖关系决定。

因此，“GN 成功”只表示构建图生成完成；“Ninja 执行到 SDK action”才表示厂商构建真正开始；只有最终命令退出码为 0、目标文件时间更新并重新计算哈希，才能说本次构建产物已经生成。任何一层的历史输出都不能替代本轮证据。

本轮成功日志可以确认到什么程度

最终命令开始于 2026-07-24 09:32:31，结束于 09:33:24，墙钟耗时约 52 秒。HB 输出 build success，Ninja 最后一步为 [22/22] STAMP obj/device/soc/hisilicon/ws63v100/sdkv106/run_sdk_build.stamp，ccache 汇总命中率为 99.87%。

target: //device/soc/hisilicon/ws63v100/sdkv106:run_sdk_build
ninja:  [22/22] STAMP obj/device/soc/hisilicon/ws63v100/sdkv106/run_sdk_build.stamp
HB:     build success
exit:   0
time:   2026-07-24 09:32:31 -> 09:33:24
ccache: hit rate 99.87%

99.87% 命中率说明这不是干净缓存性能测试，所以不能用 52 秒推导首次全量构建速度。它仍然能证明当前目标、工具链、兼容补丁和打包流程在这次执行中闭环。文章保留该缓存事实，避免把增量结果包装成全量性能数据。

产物必须同时记录文件名、大小和 SHA-256

本轮两个打包产物位于 out/xiaohong/xiaohong/ws63-liteos-app/。ws63-liteos-app_all.fwpkg 大小为 1,973,096 字节，SHA-256 为 F300EBB3BAD7E3C17433075AA21A3E5D023FB4BAF005C88902BF0DD2899CA502。同目录还生成 load-only 包；SDK 中间输出目录则保留签名后的应用镜像。

ws63-liteos-app_all.fwpkg
  1,973,096 bytes
  F300EBB3BAD7E3C17433075AA21A3E5D023FB4BAF005C88902BF0DD2899CA502

ws63-liteos-app_load_only.fwpkg
  1,842,004 bytes
  932C749F8CC6B517593404281AA35068B053248E9E5DBCE071368A4A2E2AF3AF

ws63-liteos-app-sign.bin
  1,810,048 bytes
  B5BEC7FE0AF40EEE0D9E8A627B13FDA00A830B28AC6374E90C6C66B6CCDEE9A6

文件名只能表示用途，大小和哈希才用于区分具体内容。准备烧录前应再次对实际选择的文件计算 SHA-256，避免把昨日输出、快捷别名或另一个产品的同名包带入 BurnTool。

构建成功与烧录、运行仍是三条证据

本文已经确认：当前产品配置属于 OpenHarmony mini/LiteOS-M；WS63 SDK v106 的 run_sdk_build 目标实际执行完成；两个固件包和签名应用镜像在本轮更新；主 .fwpkg 的字节数与 SHA-256 已保存；临时修改的源文件已恢复。

本文没有执行 WS63 BurnTool，因此没有“写入成功”结论；也没有从串口读取本包的启动标识，没有验证屏幕、三个按键、Wi-Fi、CI1302 音频和联网 Agent。即便后续 BurnTool 出现 All images burn successfully，也仍需单独完成运行层回归。第 04 篇会继续记录 .fwpkg 的镜像结构、Loader、写入、导出与回滚，不把本篇构建日志重复当成实机证据。

可复用的 WS63 构建验收清单

以后每次构建至少保存六项：当前分支与源文件哈希、产品选择、完整命令、退出码、产物时间与大小、SHA-256。若使用兼容补丁或增量缓存，还要显式记录，不能只保留一句 success。遇到失败时按“目标图、产品依赖、工具链 PATH、写权限、业务源码”的顺序定位，通常比从最后一条编译器输出倒猜更稳定。

本次结果可以标记为“构建已验证”，但还不能标记为“候选固件已通过设备验收”。这个边界看起来严格，却能避免最常见的固件混淆：源码改的是一份、打包来自另一份、烧录选中第三份，最终又拿旧串口日志证明全部通过。