上一篇已经把 OpenHarmonymini产品构建到 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 为CB24CEEE3D0766C927F43062A4C9696AF4252F8F62B151224327ADA99CA07A0ASDK 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-256F8D7B52914723A07A6D3BC2C5FE4E000B6AA0445F02E1726F6A9C775AC05F1D3 运行结论历史恢复路径本轮仅复核文件未重新烧录运行串口和高速设备串口不能混用项目文档在“开机启动与日志查看”中明确使用 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 的源码初始化而不是笼统归因于“固件不兼容”。