上一篇已经把 OpenHarmony mini 产品构建到 WS63 .fwpkg 的过程拆开，这一篇继续处理构建之后最容易混淆的部分：BurnTool 到底证明了什么、Loader 在什么时候参与、怎样做完整内部 Flash 导出，以及出问题后如何回到已知可工作的固件。本文依据小鸿项目自带的 Windows 烧录指南、本地真实固件包和一份已经完成长度、内容分布与 SHA-256 核对的 4 MiB 原始备份整理，不把官方操作说明、历史烧录结果和本轮文件核验混成同一条证据。

先说明本轮边界：今天没有再次占用串口对设备写入，也没有把第 03 篇的新构建包烧进实机。本文能够确认的是 BurnTool 输入文件、项目文档步骤、历史恢复包、Loader-only 诊断包，以及原始备份文件仍然存在且哈希没有变化。凡是涉及“这一次写入成功”或“这一个包已经启动”的结论，都必须以当次 BurnTool 控制台和启动串口为准。

先确认烧录对象是 WS63 的 .fwpkg

当前小鸿本体是 OpenHarmony mini、LiteOS-M 和 WS63 SDK v106 组合，完整固件包扩展名为 .fwpkg。它不能交给 esptool.py，也不能按 ESP32-P4 的 bootloader、partition、app 三段地址填写。项目目录中同时存在 xiaohong-p4，所以“看到开发板上还有 ESP32-P4”并不足以决定工具；必须以正在更新的芯片和实际产物格式为准。

本地目前用于界面开发的包 000_BURN_THIS_42_GUGUGAGA_DETAILED_UI_WS63_20260723_2040.fwpkg 为 1,974,056 字节，SHA-256 为 30B031CEB2C3C3B51EF278452F15CF0748639AB79E9D36C91C5B3327C66AB0A4。记录这两个值的目的不是宣称它已经通过本轮实机回归，而是防止选择文件时被名称相似的快捷副本或旧输出误导。

$firmware = Get-Item -LiteralPath ".\000_BURN_THIS_42_GUGUGAGA_DETAILED_UI_WS63_20260723_2040.fwpkg"
$hash = Get-FileHash -LiteralPath $firmware.FullName -Algorithm SHA256
$firmware.Length
$hash.Hash

项目自带指南给出的正常写入流程

项目文档 开发指南/烧录小鸿镜像-windows.md 的真实步骤是：安装 CH341/CH340 USB 转串口驱动，打开 BurnTool，选择实际出现的 COM 口，勾选 Auto burn 与 Auto disconnect，再通过 Select file 选择 .fwpkg。点击 Connect 后，同时按下小鸿左右按键让设备进入下载流程；进度完成后，控制台预期出现 Execution Successful。实操案例中的另一种成功文案是 All images burn successfully。

Select file -> 选择 WS63 .fwpkg
COM        -> 选择本机实际枚举出的端口
Auto burn -> 勾选
Auto disconnect -> 勾选
Connect    -> 同时按下左右按键
完成标志   -> Execution Successful

这里不能把 COM4 写成所有人的固定端口。COM4 只是在这台机器的既有排查中出现过的 CH340 端口，重新插拔、更换 USB 口或驱动后编号都可能变化。正确做法是先看设备管理器或 BurnTool 列表，在拔出、插入之间确认新增的端口，再开始连接。

Loader 成功只代表下载通道已经建立

WS63 下载流程会先让芯片进入可接收镜像的 Loader/loaderboot 阶段，再处理包内镜像。Loader 能启动，说明串口、握手和前置引导至少走到相应阶段；它不能证明主应用镜像已经写入，也不能证明 LCD、Wi-Fi、音频或按键已经运行。

本地保留了两个刻意命名为“只测 Loader、零 Flash 写入”的诊断包。SDK 1.10.101 版本大小为 31,568 字节，SHA-256 为 CB24CEEE3D0766C927F43062A4C9696AF4252F8F62B151224327ADA99CA07A0A；SDK 1.10.106 版本大小为 31,888 字节，SHA-256 为 CC8C3D9D1E924A46427E6C8390F55B7EA68583941865BB803DBA37D959026AB0。它们的文件名已经明确写着 NO_FLASH 或 ZERO_FLASH，因此只能用于隔离 Loader 兼容性，不能作为功能固件。

成功文案后仍要核对写入的是哪一个包

BurnTool 控制台出现成功文案，只能确认工具对当时选中的包完成了下载操作。至少还要把四项记录在同一份操作账本中：文件名、字节数、SHA-256、操作时间。如果只截图最后一行 success，而没有保存文件哈希，之后无法判断烧录的是刚生成的包、恢复包还是同名旧包。

本项目历史上确实出现过“烧录流程完成但屏幕黑掉”的包。这说明成功文案与业务启动之间存在明确边界。正常的验收顺序应是：BurnTool 完成；设备重启；以 115200、8N1、无流控打开运行日志；确认本包对应的启动标识；再检查屏幕、三键、Wi-Fi、CI1302 和 Agent。任何一层失败，都不应该回头修改另一层来掩盖。

写入账本示例
包名：000_FLASH_THIS_NOW_RECOVER_SCREEN_GOOD_WS63.fwpkg
大小：1,908,264 bytes
SHA-256：F8D7B52914723A07A6D3BC2C5FE4E000B6AA0445F02E1726F6A9C775AC05F1D3
运行结论：历史恢复路径；本轮仅复核文件，未重新烧录

运行串口和高速设备串口不能混用

项目文档在“开机启动与日志查看”中明确使用 115200、8 数据位、1 停止位、无校验、无流控。这是设备启动日志的观察参数。板级源码中 UART2 的 921600 则用于 WS63 与 CI1302 语音芯片通信，不是用户打开启动日志时应该照抄的调试波特率。

如果 BurnTool 还占着 COM 口，串口终端通常无法同时打开；如果终端占着端口，BurnTool 连接也可能失败。因此每次切换阶段都应确认上一工具已经断开。看到“端口可打开”也只代表 Windows 句柄成功，不代表设备正输出预期固件日志。

Export 是原始 Flash 读取，不是 Read efuse

备份固件时要走 BurnTool 的 Export/读取流程，而不是 Read efuse。efuse 保存的是芯片一次性配置或身份相关信息，既不是应用固件，也无法替代 Flash 镜像。导出前应关闭会触发自动写入或自动断开的选项，让 Loader 保持在可下载/可读取状态，再填写起始地址和长度。

本机 SDK 证据把 GD25Q32 对应为 4 MiB，因此已经验证过的完整原始导出参数是起始地址 0x0、长度 0x400000。0x400000 等于 4,194,304 字节。这里的 4 MiB 是 WS63 内部固件备份口径，不是第 02 篇中 SPI1 外挂 W25Q128 的 16 MiB 字库存储。

Export address : 0x00000000
Export size    : 0x00400000
Expected bytes : 4194304
Target         : WS63 GD25Q32 raw flash
Not target     : W25Q128 / font.bin / Read efuse

真实 4 MiB 备份怎样证明不是空文件

已验证备份 ch2_factory_full_flash_4mb_20260716_212319.bin 当前仍为 4,194,304 字节，SHA-256 仍为 4F8EE79D2D3D5D5F65C720B666A1E8027AF29C0378ECCB7487A5ECC4CE60E00A。本轮重新读取文件后统计到 16,339 个 0x00 字节、2,891,113 个 0xFF 字节，以及 1,286,852 个其他值。它显然不是一个全零或全 FF 的占位文件。

历史导出核验还把原文件复制到正式备份名，源、目标 SHA-256 完全一致，并对首 4 KiB 做过回读匹配。长度、内容分布、复制哈希与小范围回读形成四个互相独立的检查点；只看文件创建成功或只看 BurnTool 旧控制台都不够。

.fwpkg 偏移不能直接当作原始 Flash 地址

.fwpkg 是包含 Loader、镜像描述与多个镜像内容的容器；原始备份则是从 Flash 地址零开始连续读取的数据。包内字节偏移和芯片 Flash 地址不是同一个坐标系。在没有解析容器头、镜像表、目标地址和长度之前，不能拿 .fwpkg 的某个偏移直接去原始备份中搜索，再据此判断写入正确或错误。

同理，Loader-only 包只有三万多字节，并不意味着 Loader 就被写在 Flash 的同一字节偏移；它只是一个为诊断目的生成的下载容器。文章只记录可核实的文件大小和哈希，不虚构七个镜像的具体地址。若要做镜像级对照，应先从当前 SDK 的打包配置导出镜像表，再逐项和 raw dump 比较。

回滚优先使用已知可工作的完整包

当新包写入后出现黑屏、无日志或按键失效，第一步不是继续叠加试验补丁，而是恢复一个已知可工作的完整 .fwpkg，确认硬件和基础下载链还在。本项目屏幕恢复包 000_FLASH_THIS_NOW_RECOVER_SCREEN_GOOD_WS63.fwpkg 与较长别名文件内容完全相同，二者大小都是 1,908,264 字节，SHA-256 都是 F8D7B52914723A07A6D3BC2C5FE4E000B6AA0445F02E1726F6A9C775AC05F1D3。

回滚包也必须重新计算哈希，不能只信“RECOVERY”文件名。恢复写入完成后先看启动和显示，再逐个启用按键、Wi-Fi、音频、Agent 等模块。这样可以把“BurnTool 连接问题”“包内容问题”和“业务初始化问题”分开，避免每次都从最复杂的联网链路开始猜。

把四种成功状态写进同一份验收表

以后每次更新至少写四栏：Loader 已进入、Flash 写入已完成、启动串口已出现本包标识、功能回归已通过。前两项来自 BurnTool，第三项来自运行串口，第四项来自屏幕和交互测试。某栏没有证据就保持未验证，不用一句“烧录成功”覆盖全部状态。

本文验证到的范围是：烧录对象与工具匹配；项目文档步骤可追溯；两个 Loader-only 包、黑屏恢复包和当前 UI 包的字节数与哈希已经固定；4 MiB 原始备份仍与历史哈希一致且包含有效数据。本文没有声称今天把任何包写入设备。下一篇将复盘为什么一个能够被 BurnTool 正常写入的包仍会让屏幕黑掉，并把根因落到 GPIO14/PWR_ON 的源码初始化，而不是笼统归因于“固件不兼容”。