RK3568 分区备份大量 `0xCC` 异常调查笔记¶

整理日期：2026-08-30
故障时间范围：2026-03-02 至 2026-03-06
板卡/工程：GEC-RK3568b2、RK3568、约 15 GB Samsung eMMC
目的：汇总镜像内容、文件时间、哈希、分区表、启动日志及多套瑞芯微工具日志，说明大量 0xCC 是怎样产生的，以及它如何影响后续启动和刷机。

1. 一句话结论¶

大量 0xCC 的直接来源是分区导出阶段发生未读取、短读或读取中断后，导出工具仍把未获得真实数据的缓冲区写入了目标镜像。

这不是设备树自身生成的内容，也不是 eMMC 正常擦除值。正常擦除区域更常见的是 0x00 或 0xFF；连续、整齐、覆盖整个文件或恰好从 16 MiB 边界开始的 0xCC，更符合工具侧预填充/未有效更新缓冲区的特征。

后续又出现了第二个问题：3 月 4 日晚，工具日志记录了多次整套分区写入。时间、分区名和顺序与刚生成的异常备份高度吻合，因此这批坏镜像很可能又被刷回了设备，从而把“导出文件损坏”扩大为“eMMC 上多个分区被破坏”。

3 月 5 日 10:50，另一套 RKDevTool v2.84 又成功解包并刷入了一套完整 update.img。这次刷写理论上会覆盖并修复 3 月 4 日晚的多数异常内容。但 3 月 5 日下午和 3 月 6 日仍有继续导出、刷写及 USB/Loader 失败操作，因此最终设备状态还受后续操作影响。

2. 结论分级¶

2.1 已确认事实¶

backup\Image\boot.img 是 32 MiB：前 16 MiB存在真实 FIT 内容，后 16 MiB全部为 0xCC。
logo.img、oem.img、backup.img、recovery.img 和 userdata.img 是全文件 0xCC。
userdata.img 长度为 9,047,096,832 字节，其 SHA-256 与等长全 0xCC 数据一致。
rootfs.img 是可识别的 EXT 文件系统，不是全 0xCC。
uboot.img 具有有效 FIT/FDT 头，不是全 0xCC。
misc.img 不是全 0xCC；该分区本身允许大量零字节，不能仅凭“多数为零”判坏。
损坏 boot 中的内核横跨 16 MiB 边界，U-Boot 对内核计算出的错误哈希与镜像内容计算结果完全对应。
多套工具日志均出现读取不支持、ReadLBA/ReadFile 失败、USB 错误 31/995/121、设备测试失败等异常。
3 月 4 日 22:36 和 22:53，RKDevTool v2.92 记录了按分区写入 boot、recovery、rootfs、OEM、logo、userdata 等操作。
3 月 5 日 10:50，OECT 目录内的 RKDevTool v2.84 成功写入 GPT 和完整分区集合，操作最终 ret=1。
4.19.232驱动backup 中 boot 的 FDT、kernel、resource 三个 FIT 子镜像 SHA-256 全部与内嵌值一致；用户回忆它们可能由 Linux dd 备份，但生成方式尚无独立证据确认。
该目录的 uboot 中，U-Boot、6 段 ATF、OP-TEE 和 U-Boot DTB 共 9 个子镜像 SHA-256 全部匹配，并包含两个逐字节相同的 2 MiB 冗余副本。

2.2 高可信推断¶

0xCC 是工具侧未被真实设备数据覆盖的占位/初始化缓冲区内容。
boot 的第一个 16 MiB读取成功，第二个 16 MiB读取失败、未执行或未正确写回文件。
3 月 4 日晚产生的异常镜像随后很可能被选入 RKDevTool 的分区列表并刷回设备。
错误由“Loader/设备模式不支持稳定读取”和“USB 通信不稳定”共同触发的可能性最高。

2.3 当前不能唯一确认¶

仅凭现有二进制和日志，不能把最底层原因唯一归结为以下某一个：

AndroidTool v2.38 或 RKDevTool 某版本内部的 16 MiB 分块缺陷；
当时下载到 RAM 的 Loader 过旧或与 RK3568/eMMC 不兼容；
设备处于 Maskrom 或其他不支持分区读取的状态；
USB 线、USB 口、Hub、驱动、供电或设备重连造成传输中断；
上述问题的组合。
4.19.232驱动backup 两个文件是否确由 dd 生成；镜像本身只能证明是完整的原始分区形态，不能唯一识别生成程序。

日志能确认“读取链路失败”，但没有记录每次底层读取命令的完整参数、实际返回字节数、所用 Loader 哈希和源镜像路径，因此无法再细分到唯一实现缺陷。

3. 调查涉及的主要目录¶

3.1 3 月 4 日分区备份¶

E:\20250526HYL\GEC-RK3568b2\backup\Image

3.2 后续整理/刷机目录¶

C:\rockdev\Image

3.3 “好板”boot 导出¶

E:\20250526HYL\GEC-RK3568b2\backup\2.38导出好板boot.img

3.4 完整可用 boot 参考¶

E:\20250526HYL\GEC-RK3568b2\4.19.232驱动backup\boot.img

3.5 工具日志¶

C:\AndroidTool_Release_v2.38\AndroidTool_Release_v2.38\Log

D:\【正点原子】RK3568开发板资料（A盘）-基础资料\05、开发工具\02、RKTools\windows\RKDevTool\RKDevTool_Release\Log

E:\20250526HYL\OECT\刷机软件及驱动\tool\Log

其中：

正点原子目录的工具版本为 RKDevTool v2.92；
OECT 目录的工具版本为 RKDevTool v2.84；
C:\AndroidTool_Release_v2.38 为 AndroidTool v2.38。

4. 正确分区布局与错误 parameter¶

4.1 备份目录中的正确布局¶

E:\...\backup\Image\parameter.txt 中的主要分区为：

分区	起始扇区	长度（扇区）	容量
uboot	`0x00004000`	`0x00002000`	4 MiB
misc	`0x00006000`	`0x00002000`	4 MiB
boot	`0x00008000`	`0x00010000`	32 MiB
recovery	`0x00018000`	`0x00010000`	32 MiB
backup	`0x00028000`	`0x00010000`	32 MiB
rootfs	`0x00038000`	`0x00c00000`	6 GiB
OEM	`0x00c38000`	`0x00040000`	128 MiB
logo	`0x00c78000`	`0x00008000`	16 MiB
userdata	`0x00c80000`	grow	剩余空间

正确关系是：

rootfs 结束于 0x00c38000
OEM    0x00c38000 ～ 0x00c78000
logo   0x00c78000 ～ 0x00c80000
userdata 从 0x00c80000 开始

4.2 `C:\rockdev\Image\parameter.txt` 的错误¶

该文件把 userdata 写成：

-@0x00c38000(userdata:grow)

这会让 userdata 从 OEM 的起点开始，覆盖 OEM 和 logo 的地址空间。正确值应为：

-@0x00c80000(userdata:grow)

这个 parameter 错误会导致刷机时分区重叠或覆盖，但它不能解释导出文件为什么整齐地全是 0xCC。它属于另一个独立风险：导出侧产生坏文件，错误 parameter 又可能在写回时扩大破坏范围。

5. 各分区导出/落盘时间线¶

以下以 NTFS CreationTime → LastWriteTime 为依据。RKDevTool 通常不记录“某分区导出成功”的逐项日志，因此文件时间是当前最可靠的落盘时间证据。若文件经过复制，创建时间可能是复制时间，最后写入时间会保留源文件时间，文中另作说明。

时间	分区/文件	大小	持续时间	内容状态
3 月 3 日 11:38:45	uboot	4 MiB	—	有效 FIT，不是 CC
3 月 3 日 15:01:25 → 3 月 4 日 10:24:08	rootfs	6 GiB	19:22:43	有效 EXT 文件系统
3 月 4 日 19:43:16 → 19:43:17	logo	16 MiB	约 1 秒	全 CC
3 月 4 日 19:50:42 → 19:50:43	misc	4 MiB	约 1 秒	不是全 CC
3 月 4 日 19:55:11 → 19:55:19	OEM	128 MiB	约 8 秒	全 CC
3 月 4 日 20:06:52 → 20:06:54	backup	32 MiB	约 2 秒	全 CC
3 月 4 日 20:08:49 → 20:08:54	boot	32 MiB	约 5 秒	前 16 MiB真实，后 16 MiB全 CC
3 月 4 日 20:10:29 → 20:10:31	recovery	32 MiB	约 2 秒	全 CC
3 月 4 日 22:23:00 → 22:31:23	userdata	9,047,096,832 B	08:23	全 CC
3 月 4 日 23:28:26	parameter.txt	535 B	—	文本配置，不是分区内容
3 月 5 日 08:39:45	GPT	32 KiB	—	低层分区表备份
3 月 5 日 08:49:21 → 08:49:22	IDB	8,355,840 B	约 1 秒	低层引导区备份
3 月 5 日 15:18:23 → 15:41:44	“2.38 导出好板 boot”	32 MiB	23:21	后 16 MiB仍为 CC
3 月 7 日 11:56:56 → 11:58:34	4.19.232 uboot	4 MiB	源修改→复制进目录	完整双副本 FIT，方法未证实
3 月 7 日 12:28:36 → 12:29:25	4.19.232 boot	32 MiB	源修改→复制进目录	完整 Linux FIT，方法未证实

5.1 uboot 的时间说明¶

原始文件位于：

E:\20250526HYL\GEC-RK3568b2\backup\4.19.219uboot\uboot.img

其创建和修改时间均为 3 月 3 日 11:38:45。backup\Image\uboot.img 是 3 月 5 日 23:49:26 才复制到当前目录的副本，保留了 3 月 3 日 11:38:45 的源修改时间。

5.2 rootfs 的异常长时间¶

rootfs 从创建到最终修改跨越约 19 小时 22 分。它最终是有效 EXT 文件系统，但这个持续时间明显异常，可能包含暂停、卡死、重试、换工具继续写或文件被另一个进程更新，不能简单解释成一次稳定、连续的 19 小时读取。

5.3 3 月 4 日晚的明显转折¶

3 月 4 日 19:43 开始，除 misc 外，后续导出的主要镜像连续出现全 CC 或部分 CC：

19:43 logo      全 CC
19:50 misc      非全 CC
19:55 OEM       全 CC
20:06 backup    全 CC
20:08 boot      后 16 MiB为 CC
20:10 recovery  全 CC
22:23 userdata  全 CC

其中 misc 位于两个坏文件之间却不是全 CC，说明问题不是简单地“从某个分区地址开始 eMMC 后面全坏了”，更符合工具连接/读取状态在不同导出动作之间变化。

6. 各镜像内容取证¶

6.1 boot：典型的 16 MiB 短读/未填充边界¶

backup\Image\boot.img：

文件总长：33,554,432 字节，即 32 MiB；
文件开头：D0 0D FE ED，是有效 FIT/FDT 魔数；
偏移 0x01000000，即 16 MiB之后，全部为 0xCC；
后半段长度恰好也是 16 MiB，即 0x8000 个 512 字节扇区。

这非常像一次按 16 MiB 分块的读取：第一块成功，第二块失败或未执行，工具仍保存了完整 32 MiB 文件。

6.2 全 CC 分区¶

以下镜像的 SHA-256 与对应长度的全 0xCC 数据一致：

文件	长度	SHA-256
logo.img	16 MiB	`EA07B7498CB65606B02F9C1214534FD1AA218634CF86C0B9E55A335999352C37`
backup.img	32 MiB	`313901D3C6DA358C92DEE4AEBE19A3D831FB8922E38CCBC12E1095F53DA5A178`
recovery.img	32 MiB	`313901D3C6DA358C92DEE4AEBE19A3D831FB8922E38CCBC12E1095F53DA5A178`
oem.img	128 MiB	`727C1AE83A3955121D8830C8C95D64B3791CD3C285BA8D9867BC1E623ADBDD2D`
userdata.img	9,047,096,832 B	`600A61A0588390EDF55383AE1BB4DEC807D0BE407E68F989891E9B2FFAFA4546`

backup 和 recovery 哈希完全相同不是因为它们原始数据相同，而是因为二者长度同为 32 MiB，并且都完全由 0xCC 构成。

6.3 misc¶

misc 的 SHA-256 为：

BB000DDEECF06C7899AAFE54581918E7E77586D69988200A262315EF3760E625

它既不等于 4 MiB全零数据，也不等于 4 MiB全 0xCC 数据，因此不能归入这批全 CC 坏镜像。misc 分区通常保存启动控制、recovery 命令等少量状态，大面积为零并不异常。

6.4 设备树问题¶

0xCC 不是可用设备树。有效 FDT/DTB 至少应以：

D0 0D FE ED

开头，并包含合法头部、结构块和字符串块。如果 DTB 所在范围被 0xCC 覆盖，该 DTB 完全不可解析。

不过本次 boot 的首要失败不是单纯“设备树没用”，而是 FIT 中 21.2 MiB 的内核本体已经跨越 16 MiB 边界，U-Boot 在加载设备树之前或同时进行的内核哈希校验就已经失败。

7. boot 哈希失败与启动日志的直接对应¶

坏板启动日志记录：

Data Size:    22267912 Bytes = 21.2 MiB
Hash value:   1792bf23cc6f42784157b9740f29f1b41d195676a166de29003a12a3b9df71b3
Verifying Hash Integrity ... sha256 Bad hash:
4a8973798784694acb6ef8346badd16b4e6b9bb76e91e5eea1ac2247c4428551
Bad Data Hash
ERROR: can't get kernel image!

FIT 中内核数据相对 boot 文件起点约从 0x22200 开始，长度为 22,267,912 字节，结束位置约为：

0x155EA08

也就是内核数据有 5,630,472 字节落在 16 MiB边界之后。后半段被 0xCC 替代后，内核不可能通过原始 SHA-256 校验。

对截断/CC 尾部 boot 中的内核数据重新计算，得到的错误值正是：

4a8973798784694acb6ef8346badd16b4e6b9bb76e91e5eea1ac2247c4428551

因此日志中的 Bad hash 与 boot 文件后半段 0xCC 之间不是猜测，而是可以一一复现的直接因果关系。

8. boot 文件之间的哈希关系¶

boot 文件	SHA-256	结论
3 月 4 日备份 boot	`0619FBE0329F8473BCBAE267A7832FBA16102FD3F22C57D0DA3EBC7BA384789F`	前半有效、后 16 MiB为 CC
3 月 5 日“2.38 导出好板 boot”	`7195A6BFDD3F676C9A44D352A4E085D9D9765DBAEE23B9791D2910B21C315EDF`	另一份前半内容，后 16 MiB仍为 CC
`C:\rockdev\Image\boot.img`	`7195A6BFDD3F676C9A44D352A4E085D9D9765DBAEE23B9791D2910B21C315EDF`	与“2.38 导出好板 boot”逐字节相同
4.19.232 完整参考 boot	`0115BB6DE1C64F476C771E7330F8287984B4F9139F1E6C3FACBD0C9ECE3D1C1E`	三个 FIT 子镜像哈希全部匹配，可作为完整参考

这说明：

3 月 4 日坏板 boot 与 3 月 5 日好板 boot 的前半部分并不相同；
两次导出却出现相同的“后 16 MiB为 CC”结构；
因而 16 MiB CC 尾部更像导出链路/工具问题，而不是两块板的 eMMC 恰好具有相同损坏模式；
C:\rockdev\Image\boot.img 不是独立的第三份完整镜像，而是与“2.38 导出好板 boot”完全相同的副本。
“2.38 导出好板 boot”的前 16 MiB与 4.19.232 完整参考 boot 逐字节相同，证明 v2.38 读出的第一块数据正确，差异完全发生在第二个 16 MiB块。

9. `C:\rockdev\Image` 与备份目录的哈希比对¶

当前重新计算 SHA-256 后，完全相同的文件共有 7 个，其中 6 个是分区镜像，另 1 个是 Loader：

文件	是否相同	SHA-256/说明
MiniLoaderAll.bin	相同	`2A157726526A3D880FACC603917161695AA7DF344863C73873DEAA78DFA48B9D`
misc.img	相同	`BB000DDE...60E625`
recovery.img	相同	`313901D3...5A178`，两边都是全 CC
backup.img	相同	`313901D3...5A178`，两边都是全 CC
rootfs.img	相同	`8C31CD507416635CC8125C874F6C103375CA8A27224009215D99551097923AFA`
oem.img	相同	`727C1AE8...DBDD2D`，两边都是全 CC
logo.img	相同	`EA07B749...352C37`，两边都是全 CC
uboot.img	不同	备份：`E483671F...BEF516`；rockdev：`8E640CC5...69FD25`，后者与 4.19.232 目录中的有效 uboot 完全相同
boot.img	不同	备份：`0619FBE0...4789F`；rockdev：`7195A6BF...315EDF`
parameter.txt	不同	rockdev 版本的 userdata 起点错误

关于 userdata：会话早期比对时确认相关 userdata 内容为全 0xCC；本次整理时，C:\rockdev\Image 下已不再存在 userdata.img，因此当前无法再次对两个路径现场重跑哈希。备份目录中的 userdata 哈希仍为上文的 600A61A0...A4546，并已确认是全 0xCC。

10. 工具日志一：正点原子 RKDevTool v2.92¶

日志目录：

D:\【正点原子】RK3568开发板资料（A盘）-基础资料\05、开发工具\02、RKTools\windows\RKDevTool\RKDevTool_Release\Log

10.1 按日错误统计¶

日期	不支持导出	err=995	err=31	err=121	ReadLBA 失败	Boot 失败	固件成功	userdata 超分区
3 月 3 日	42	17	9	8	1	0	0	0
3 月 4 日	0	18	6	17	4	3	1	2
3 月 5 日	6	5	10	9	1	6	5	3
3 月 6 日	0	7	2	7	0	0	0	0

10.2 3 月 3 日：大量明确的导出不支持¶

典型日志：

Error:ExportImageProc-->device did not support to read

当日共出现 42 次。11:20 前后还连续出现：

RKU_Write-->WriteFile failed, err=995
RKU_ResetPipe-->DeviceIoControl failed, err=31
RKU_TestDeviceReady failed, RetCode(-3)

11:32 至 11:34，ADB 转 RockUSB/Loader 也失败；11:54 又开始连续报“不支持读取”。这说明 uboot、rootfs 等文件生成前后，设备模式和 USB 通信已经不稳定。

10.3 3 月 4 日：文件生成时日志恰好静默¶

19:43 至 20:10 生成 logo、misc、OEM、backup、boot、recovery 时，v2.92 日志没有记录逐分区导出成功或失败。不能把“日志没有错误”理解为“读取成功”，因为镜像内容已经证明多数导出无效。

userdata 导出前的 22:18，日志连续出现：

RKU_Write err=31
ResetPipe err=121
RKU_ReadLBA failed, err=-3
RKU_Write err=995
RKU_ReadFlashInfo failed
RKU_ReadCapability failed

随后时间关系为：

22:18      USB/ReadLBA/FlashInfo/Capability 失败
22:23      userdata.img 开始创建
22:31      userdata.img 写完，但全文件为 CC
22:36      工具开始整套分区写入

这个前后关系是“读取失败 → 全 CC userdata → 很快进入写回”的强证据链。

10.4 3 月 4 日 22:36 和 22:53 的整套写入¶

22:36 的写入顺序：

uboot     @ 0x00004000
misc      @ 0x00006000
boot      @ 0x00008000
recovery  @ 0x00018000
rootfs    @ 0x00038000
OEM       @ 0x00c38000
logo      @ 0x00c78000
userdata  @ 0x00c80000
RunProc ret=1

22:53 再次写入，这次还包含 backup：

uboot, misc, boot, recovery, backup, rootfs, OEM, logo, userdata

日志不保存当时每一项的完整源路径和 SHA-256，因此不能绝对证明源文件就是当前 E:\...\backup\Image 中的文件。但生成时间、名称、分区顺序和操作间隔高度对应，判断为同一批文件的可信度很高。

10.5 22:10 的可疑地址组合¶

另一次日志出现：

rootfs @ 0x00028000
logo   @ 0x00038000

这两个地址分别是正常 backup 和 rootfs 的起点，和名称不匹配。可能是当时勾选项、配置行或地址发生错位。如果确实按此配置写入，会造成错误覆盖。日志本身只能证明工具显示/执行了这组映射，无法恢复当时 GUI 中所有源文件路径。

10.6 userdata 比目标分区大 31 个扇区¶

多次出现：

image size is larger than partition,
image=17670111,
partition=17670080

差值为 31 个扇区，即 15,872 字节。这说明当时 userdata 镜像长度和目标分区定义不完全匹配。即使 userdata 不是全 CC，这个尺寸问题也足以让刷写失败。

10.7 3 月 5 日好板 boot 前的失败¶

15:37:49 至 15:38:46 连续出现：

ExportImageProc-->device did not support to read
RKU_Write-->WriteFile failed, err=31
RKU_Write-->WriteFile failed, err=995

而“2.38 导出好板 boot”的最后写入时间是 15:41:44。时间线高度吻合：v2.92 尝试读取失败，随后使用/切换另一导出流程，最终得到后 16 MiB仍为 CC 的 boot。

11. 工具日志二：OECT RKDevTool v2.84¶

日志目录：

E:\20250526HYL\OECT\刷机软件及驱动\tool\Log

11.1 3 月 2 日¶

多次启动工具，但指定 Loader 不存在：

D:\360Downloads\OECT\oec群晖固件\MiniLoaderAll_oect.bin is not existed!
RunProc ret=0

11.2 3 月 3 日¶

09:15 至 09:20 至少 5 次：

ExportImageProc-->device did not support to read

并伴随：

ExportComDataProc-->device did not support to read log
RKU_Write err=31/995
RKU_TestDeviceReady failed
ADB to RockUSB failed

说明 v2.84 同样无法稳定读取设备，不是只有 v2.92 或 v2.38 出现问题。

11.3 3 月 4 日¶

只有工具启动和一次 ret=0，没有晚间分区导出或刷写记录。因此 3 月 4 日 19:43 至 22:31 那批文件不是由这份 OECT v2.84 日志所对应的进程直接生成。

11.4 3 月 5 日 10:50 的完整刷机¶

10:32，工具明确解包：

C:\Users\17937\Downloads\Filez\WebTool\RK_EVB1_RK3568\update\update.img

该文件大小为 1,755,138,634 字节。随后解包到：

E:\20250526HYL\OECT\刷机软件及驱动\tool\Output

10:48 和 10:50 前两次下载 Boot/Loader 失败，第三次成功。10:50:51 开始完整写入：

GPT
uboot      @ 0x00004000
misc       @ 0x00006000
boot       @ 0x00008000
recovery   @ 0x00018000
backup     @ 0x00028000
rootfs     @ 0x00038000
OEM        @ 0x00c38000
logo       @ 0x00c78000
userdata   @ 0x00c80000

11:02:33 结束，RunProc ret=1。该分区地址组合是正确的，也没有出现 userdata 起点与 OEM 重叠的问题。

这次操作紧跟刚才的完整固件解包，强烈说明写入来源是该 update.img 解出的分区，而不是 3 月 4 日晚的 CC 备份。当前 tool\Output 已被删除，无法再对当时解包出的各分区逐一计算哈希。

11.5 完整刷机后的异常¶

11:37 以后再次出现 err=31、995、121 和 RKU_ReadCapability failed。19:08 至 19:10 又发生测试设备及下载 Boot 失败，但没有进入 GPT 或分区写入阶段，因此 19 点这次失败操作没有实际写入分区的日志证据。

12. 工具日志三：AndroidTool v2.38¶

当前可见目录：

C:\AndroidTool_Release_v2.38\AndroidTool_Release_v2.38

12.1 3 月 5 日¶

日志出现：

RKU_Read-->ReadFile failed, err=22, size=13, read=0
RKU_ResetPipe-->CreateFile ... failed, err=2
RKU_ReadFlashInfo failed
RKU_Write err=31
DeviceIoControl err=121

12.2 3 月 6 日¶

多个时段反复出现：

RKU_Write err=995/31
RKU_ResetPipe err=121
ReadIDBProc-->RKU_ReadFlashInfo failed
ResetDeviceProc-->RKU_ResetDevice failed
ADB device offline

其 Output\ExportImage.img 当前为 0 字节。这说明 v2.38 在另一些导出尝试中也会留下无效目标文件，而不是总能在失败后给出完整、可信的镜像。

13. USB 错误码的含义¶

这些错误码不能单独指出哪根线或哪个 Loader 有问题，但能证明传输链路异常：

错误	常见含义	本案影响
995	I/O 操作被中止	设备断开、请求取消、驱动重置时常见
121	信号灯超时/设备未在规定时间响应	USB 控制请求超时、设备无响应
31	连接到系统的设备没有发挥作用	设备状态异常、端点/驱动操作失败
`err=-3/-4`	工具内部读写/设备操作失败	ReadLBA、FlashInfo、Capability、Reset 等失败
`device did not support to read`	当前设备模式/Loader声明不支持读取	无法可靠执行分区导出

RKU_Write-->WriteFile failed 中的 “WriteFile” 是 Windows 对 USB 设备句柄发命令失败，不等价于“向本地镜像文件写入失败”。但它证明工具和设备之间的 USB 命令传输失败。

14. 综合事件时间线¶

3 月 2 日¶

OECT v2.84 多次因指定 MiniLoader 不存在而结束。

3 月 3 日上午¶

OECT v2.84 多次提示设备不支持读取。
正点原子 v2.92 大量 USB、ADB 转 Loader、设备测试失败。
11:38 形成一份有效 uboot。
11:54 起 v2.92 连续提示不支持读取。

3 月 3 日下午至 3 月 4 日上午¶

rootfs 文件从 3 月 3 日 15:01 持续到 3 月 4 日 10:24，最终有效。
期间工具反复重启并出现 Loader/USB 问题，具体由哪个进程连续完成无法完全还原。

3 月 4 日晚¶

19:43：logo 全 CC。
19:50：misc 非全 CC。
19:55：OEM 全 CC。
20:06：backup 全 CC。
20:08：boot 前 16 MiB真实、后 16 MiB全 CC。
20:10：recovery 全 CC。
22:09 左右，工具曾提示 ..\rockdev\userdata.img is not existed。
22:18：ReadLBA、FlashInfo、Capability 和 USB 传输连续失败。
22:23 至 22:31：生成 8.43 GiB全 CC userdata。
22:36：按分区写入一整套镜像。
22:53：再次写入，包含 backup。
23:34、23:53 等操作出现 userdata 比分区大 31 个扇区。

3 月 5 日上午¶

08:39：生成 GPT 备份。
08:49：生成 IDB 备份。
10:32：OECT v2.84 解包 WebTool 的完整 update.img。
10:50 至 11:02：完整写入 GPT 和所有分区，ret=1。
11:37：再次出现 USB/Capability 失败。

3 月 5 日下午和晚上¶

15:37 至 15:38：v2.92 连续导出失败。
15:41：所谓“2.38 导出好板 boot”写入结束，后 16 MiB仍为 CC。
后续还有多轮固件/分区写入和 Boot 下载失败，userdata 超分区错误反复出现。

3 月 6 日¶

C:\rockdev\Image 在 12:57 左右复制了备份中的多项镜像，保留原始修改时间。
C:\rockdev\Image\boot.img 最终与“2.38 导出好板 boot”哈希完全相同。
AndroidTool v2.38 继续出现 err=31/995/121、ReadFlashInfo 失败和 ADB offline。

3 月 7 日¶

11:28：与豆包的聊天提出修改 U-Boot 环境变量、从好板备份 boot 并重新刷写等建议。
11:56:56：4.19.232 uboot.img 的源修改时间，晚于聊天 28 分 56 秒。
11:58:34：该 uboot 复制/创建到当前目录，晚于聊天 30 分 34 秒。
12:28:36：4.19.232 boot.img 的源修改时间，晚于聊天 1 小时 00 分 36 秒。
12:29:25：该 boot 复制/创建到当前目录，晚于聊天 1 小时 01 分 25 秒。
时间顺序支持“聊天后进行了相关备份/整理操作”，但没有命令日志，不能证明两个文件由聊天中的具体 dd 命令生成。

15. 最可能的故障机制¶

15.1 直接机制¶

工具按分区长度创建目标文件
        ↓
为读缓冲区保留/填入固定模式 0xCC
        ↓
向设备发出 ReadLBA/读取命令
        ↓
设备模式不支持读取，或 USB/Loader 请求失败、短读
        ↓
缓冲区没有被真实 eMMC 数据完整覆盖
        ↓
工具仍将缓冲区写入文件，并保留正常分区尺寸
        ↓
得到“大小正确、内容全 CC或部分 CC”的假备份

15.2 为什么有的分区正常、有的全 CC¶

uboot、misc 较小，可能在连接短暂正常时一次读取完成；
rootfs 可能由另一次连接、另一个工具进程或多次操作完成；
logo、OEM、backup、recovery 在各自操作中没有获得有效数据；
boot 第一块 16 MiB成功，第二块失败；
userdata 在紧邻 ReadLBA/USB 失败之后导出，整段没有获得真实数据。

15.3 为什么不是设备树导致¶

设备树只影响内核如何识别硬件、驱动和资源。设备树写错可能导致外设不工作、内核启动失败或硬件冲突，但不会让 Windows 上的导出程序把整个 16 MiB、32 MiB、128 MiB、8.43 GiB文件整齐写成同一个 0xCC 字节。

15.4 为什么不是 parameter 单独导致¶

parameter 决定分区地址和大小。地址错误会导致读错区域或刷写覆盖，但不能自然产生恰好一致的全 0xCC 哈希。它能解释“写错位置/覆盖”，不能单独解释“导出缓冲区未被真实数据覆盖”。

16. 对此前问题的集中回答¶

“为什么这些分区都是 CC？”¶

因为导出时读取没有成功，工具仍生成了完整尺寸文件，并把未获得真实数据的区域保存为 0xCC。

“boot 为什么 16 MiB之后都是 CC？”¶

32 MiB boot 很可能按两个 16 MiB块读取。第一个块成功，第二个块失败或未执行；16 MiB正好是 0x8000 个扇区。该边界在不同板子的两次导出中重复出现，强烈指向工具/Loader/传输链路，而不是单块板的存储内容。

“0xCC 设备树完全没用吗？”¶

全 0xCC 不是合法 DTB；如果设备树数据区被覆盖就完全不可用。但这份 boot 连内核本体都被 0xCC 污染，首先触发的是内核 SHA-256 校验失败。

“C:\rockdev\Image 和 backup 有几部分完全相同？”¶

当前 SHA-256 重算结果为 7 个文件完全相同：MiniLoader、misc、recovery、backup、rootfs、OEM、logo。其中 6 个是分区镜像。boot、uboot、parameter 不同。

“hash 比对了吗？”¶

已比对。完全相同的判断来自 SHA-256，不只是文件大小或时间；全 CC 的判断也通过全文件哈希与理论全 0xCC 数据核对。

“日志里的 ReadFile failed、短读、USB 995/121 体现在哪里？”¶

v2.92：3 月 3 至 6 日反复出现 ExportImage 不支持、ReadLBA、995、121、31；
v2.84：3 月 3 日同样出现不支持读取及 31/995；
v2.38：3 月 5 日出现 RKU_Read ReadFile failed, read=0，3 月 5 至 6 日继续出现 31/995/121 和 ReadFlashInfo 失败。

这些日志证明读取环境不稳定，但没有记录“第二个 16 MiB读取块具体在哪一条命令失败”，因此不能只凭日志锁定唯一软件缺陷。

17. 后续备份和刷机建议¶

17.1 不再使用这批镜像作为恢复源¶

以下文件应标记为损坏，不能继续刷入：

backup\Image\logo.img
backup\Image\oem.img
backup\Image\backup.img
backup\Image\recovery.img
backup\Image\userdata.img
backup\Image\boot.img
backup\2.38导出好板boot.img
C:\rockdev\Image\boot.img

misc、rootfs、uboot 虽未发现全 CC，但刷写前仍应按来源和目标板版本复核。

17.2 修正 parameter¶

userdata 起点必须为：

0x00c80000

不要使用 C:\rockdev\Image\parameter.txt 中的 0x00c38000 版本。

17.3 导出前固定环境¶

使用与 RK3568 板卡和 eMMC 匹配的 MiniLoaderAll；
确认工具显示为 Loader 模式并能读取 FlashInfo/Capability；
不要在 device did not support to read 后继续批量导出；
使用主板直连 USB 口，避免 Hub、前置面板和延长线；
保证板卡独立稳定供电；
固定工具版本、Loader 哈希、USB 口和驱动版本，避免边导出边换环境。

17.4 每个分区至少导出两遍¶

两次导出后立即比较：

Get-FileHash -Algorithm SHA256 -LiteralPath '第一次.img'
Get-FileHash -Algorithm SHA256 -LiteralPath '第二次.img'

若同一分区两次哈希不同，不得作为备份使用。

17.5 不只检查文件大小¶

大小正确不代表内容正确。至少检查：

SHA-256；
文件头魔数；
文件中点和尾部；
是否出现长段 CC CC CC CC；
boot 的 FIT 子镜像和内核哈希；
EXT 分区能否通过只读方式识别；
userdata 镜像长度是否超过 parameter 计算出的分区容量。

17.6 刷写前建立清单¶

建议为每个确认可用的文件保存：

文件名
分区起点
分区长度
文件字节数
SHA-256
来源板编号
导出工具版本
Loader 文件名和 SHA-256
导出日期
验证结果

只有清单完整、两次导出哈希一致、内容结构通过检查的镜像，才进入刷机目录。

18. `4.19.232驱动backup` 两个镜像专项分析¶

分析目录：

E:\20250526HYL\GEC-RK3568b2\4.19.232驱动backup

目录中的两个目标镜像是 boot.img 和 uboot.img。用户回忆它们可能是通过 Linux dd 按分区备份，但目前没有 dd 命令、shell history、终端日志或同时生成的校验清单，因此生成方式不能作为已确认事实。二者通过文件结构、长段 CC 扫描和 FIT 子镜像哈希验证，只能证明镜像内容完整，不能单凭内容唯一识别是 dd、cat、adb exec-out 还是其他原始读取程序生成。

这个来源差异需要明确区分：

3 月 4 日及 3 月 5 日异常文件：有 RKDevTool/AndroidTool 日志和时间线证据
4.19.232驱动backup 两个文件：疑似 Linux dd 原始分区读取，方法未证实

无论具体由哪一个原始读取程序生成，这两份完整镜像仍可作为内容对照组，用来判断异常工具导出结果在哪个位置偏离完整参考。当前没有保存完整命令行和终端输出，所以源设备节点、bs、count、是否使用 conv= 参数等细节均未知。

已在 E:\20250526HYL\GEC-RK3568b2 和当前工程日志中搜索 dd if=、dd of=、/dev/block/by-name/boot、/dev/block/by-name/uboot 与镜像文件名的组合。现有记录只找到分区节点列表以及闪存压力测试脚本中与本备份无关的 dd 命令，没有找到生成这两个镜像的命令或终端输出。因此目前没有日志层面的 dd 证据。

18.1 文件基本信息¶

文件	大小	创建时间	最后写入时间	文件 SHA-256
boot.img	32 MiB	2026-03-07 12:29:25	2026-03-07 12:28:36	`0115BB6DE1C64F476C771E7330F8287984B4F9139F1E6C3FACBD0C9ECE3D1C1E`
uboot.img	4 MiB	2026-03-07 11:58:34	2026-03-07 11:56:56	`8E640CC51444E0575E96C04252245BDD3E2B0C5EC6EA2B16ECE4FE70AB69FD25`

两个文件的创建时间都略晚于最后写入时间。这可以证明文件曾从其他位置复制到当前目录并保留源修改时间：12:28 和 11:56 更接近源文件最后写入时间，12:29 和 11:58 更接近复制进当前目录的时间。但这种时间关系不能识别源文件是由 dd、瑞芯微工具还是其他程序生成，也不能还原原始备份命令的执行区间。

与 3 月 7 日 11:28 豆包聊天的时间关系¶

文件	源修改时间	相对 11:28	当前目录创建时间	相对 11:28
uboot.img	11:56:56	晚 28 分 56 秒	11:58:34	晚 30 分 34 秒
boot.img	12:28:36	晚 1 小时 00 分 36 秒	12:29:25	晚 1 小时 01 分 25 秒

所以可以确认：按当前 NTFS 时间戳，这两个文件都在 11:28 聊天之后写入并复制到目标目录。这个时间顺序与“聊天后开始处理/备份镜像”相容，但不是因果证明，原因包括：

没有保存执行命令或 dd 的完成输出；
聊天示例生成的文件名是 boot_fix.img，当前文件名是 boot.img；
聊天主要示范单独备份 boot，没有给出生成单独 uboot.img 的命令；
NTFS 时间可以由复制程序保留或人工修改；
系统时钟若当时不准确，时间差也会偏移。

因此严谨结论是：两个文件在时间上位于聊天之后，可能是聊天后相关操作的产物，但目前不能证明它们就是按该聊天中的 dd 步骤生成。

豆包步骤中与本机 GPT 不一致的危险假设¶

从 backup\gpt.img 直接解析出的实际分区为：

p1 uboot    起点 0x00004000
p2 misc     起点 0x00006000
p3 boot     起点 0x00008000，长度 0x00010000 扇区
p4 recovery 起点 0x00018000
p5 backup   起点 0x00028000
p6 rootfs   起点 0x00038000
p7 oem      起点 0x00c38000
p8 logo     起点 0x00c78000
p9 userdata 起点 0x00c80000

因此聊天中的以下示例不能直接用于本板：

聊天示例	本板实际含义/风险
`dd if=/dev/mmcblk0p6 ...boot_fix.img`	p6 实际是 rootfs，不是 boot；boot 是 p3
`root=/dev/mmcblk0p7`	p7 实际是 OEM，不是 rootfs；rootfs 是 p6
`mmc write ... 0x100000 0x10000`	`0x100000` 落在 rootfs 内，不是 boot 起点；boot 起点是 `0x8000`
“`0x400000` 扇区 = 1024 MiB”	计算错误；512 字节扇区下 `0x400000` 是 2 GiB，1 GiB应为 `0x200000` 扇区
写整个 eMMC 前 1 GiB	会覆盖 GPT、uboot、misc、boot、recovery、backup 及部分 rootfs，风险远高于只修复 boot

若实际执行了 mmc write 0x70000000 0 0x400000，而内存中只通过 TFTP 加载了 1 GiB文件，命令还会继续读取并写入文件末尾之后约 1 GiB的内存内容，属于严重破坏风险。

修复本板 boot 时，只有在再次核对 mmc part 与 GPT 一致后，原始扇区参数才应是：

boot 起始 LBA = 0x8000
boot 分区长度  = 0x10000 扇区 = 32 MiB

即使地址正确，也应优先使用有分区名校验和读回哈希验证的流程，不应盲目照抄示例地址。

18.2 boot.img：完整可校验的 Linux 4.19.232 FIT¶

boot 文件总长为 32 MiB，FIT 元数据位于文件头，默认配置为 conf，包含三个外置数据子镜像：

子镜像	类型	文件内位置	大小	SHA-256	校验
fdt	ARM64 flat_dt	`0x00000800`	137,367 B	`702405C9728899CC1E3E52529D3755A8EBAE747F361F82DFE9A4D2062E3FED7C`	与 FIT 内嵌值一致
kernel	ARM64 Linux kernel，未压缩	`0x00022200`	22,267,912 B	`1792BF23CC6F42784157B9740F29F1B41D195676A166DE29003A12A3B9DF71B3`	与 FIT 内嵌值一致
resource	ARM64 multi	`0x0155EC00`	175,616 B	`DC082CC2FE143022F5D704414A22D506F8988C731DD651EEA81C668AB7E7F125`	与 FIT 内嵌值一致

内核版本字符串为：

Linux version 4.19.232 (gecedu@Gecedu)
gcc 10.3.1 / GNU ld 2.36.1
#5 SMP Thu Aug 14 19:27:53 CST 2025

设备树信息为：

model      = Rockchip RK3568 EVB1 DDR4 V10 Board
compatible = rockchip,rk3568-evb1-ddr4-v10
             rockchip,rk3568

目录中已经提取出的：

DTB\rk3568-gecedu-v1.1.dtb

SHA-256 同样为 702405C9...3FED7C，与 boot 内的 fdt 子镜像逐字节相同，说明现有反编译 DTS 确实来自这份 boot，而不是其他近似版本。

CC 扫描结果¶

整份 32 MiB boot 中 0xCC 字节总数为 18,892，占约 0.0563%，最长连续 CC 只有 3 字节。这些是内核/资源二进制中自然出现的零散字节，不存在任何可疑长段 CC，更不存在 16 MiB CC 尾部。

因此这份 boot 的判断是：

文件完整、FIT 结构正常、FDT/kernel/resource 三项哈希全部正确，可作为当前 4.19.232 版本的完整参考 boot。

这里验证的是 FIT 的 SHA-256 数据完整性；是否与某块具体硬件的显示屏、触摸、Wi-Fi等外设完全匹配，还应结合该板的硬件版本和 DTS 配置判断。

18.3 与两份截断 boot 的 16 MiB 分段比对¶

对各 32 MiB boot 分别计算前、后 16 MiB 的 SHA-256：

文件	前 16 MiB SHA-256	后 16 MiB SHA-256
4.19.232 完整 boot	`946BFB21823C9EB7A8780F8037A5B25FB986DBC8C2F0B9DE7DE77A46B4D36A95`	`E76732A6C98EB0C3AEFFEA9D5938262960B88BAC2403949EEACABEB93A9FAFD9`
2.38 导出好板 boot	`946BFB21823C9EB7A8780F8037A5B25FB986DBC8C2F0B9DE7DE77A46B4D36A95`	`EA07B7498CB65606B02F9C1214534FD1AA218634CF86C0B9E55A335999352C37`
`C:\rockdev\Image\boot.img`	`946BFB21823C9EB7A8780F8037A5B25FB986DBC8C2F0B9DE7DE77A46B4D36A95`	`EA07B7498CB65606B02F9C1214534FD1AA218634CF86C0B9E55A335999352C37`
3 月 4 日备份 boot	`152F8ED56C40EEDDFFB0E2463AE88536AA61CBD4766FB068A41925C21F8CDCD4`	`EA07B7498CB65606B02F9C1214534FD1AA218634CF86C0B9E55A335999352C37`

EA07B749...352C37 正是 16 MiB全 0xCC 数据的 SHA-256。

这个比对提供了目前最强的 16 MiB 截断/填充证据。完整参考镜像的生成程序尚未证实，因此不能把“来自独立 dd 路径”本身作为证据；真正成立的是以下逐字节关系：

“2.38 导出好板 boot”的前 16 MiB与完整 4.19.232 boot 完全一致；
说明板上真实数据和 v2.38 第一块读取结果都正确；
从第二个 16 MiB开始，正确数据被整块全 CC 替代；
因而它不是“导错了另一版本 boot”，而是“同一个正确 boot 只成功导出前半部分”；
C:\rockdev\Image\boot.img 是这份截断结果的逐字节副本；
3 月 4 日 boot 的前半内容来自另一版本/另一状态，但第二个 16 MiB同样被全 CC 替代，说明相同导出缺陷重复发生。
完整参考 boot 的第二个 16 MiB包含正常数据，证明该版本 boot 的有效内容确实超过 16 MiB；结合前半段完全相同，可排除截断文件后半本来就是 CC。

18.4 uboot.img：完整的双副本 FIT¶

uboot 文件总长 4 MiB，可分成两个逐字节完全相同的 2 MiB副本：

第一半 SHA-256：055756BA4BE400C8F862A8F9AA4677463C01DB4C6568D5CEE7EC43F350B52595
第二半 SHA-256：055756BA4BE400C8F862A8F9AA4677463C01DB4C6568D5CEE7EC43F350B52595
halves_equal：true

这符合 Rockchip U-Boot 分区中保存冗余副本的结构。两个 FIT 头分别位于 0x00000000 和 0x00200000。

第一份 FIT 的默认配置为 conf，描述为 rk3568-evb，包含：

子镜像	大小	SHA-256	校验
U-Boot	1,282,608 B	`E914F0763A95F760581BCB2E4B6BAD1BC5820C49A5B8D86CF548E22D54731265`	匹配
ATF-1	172,032 B	`FC070F5A409613601EE979E168F9586DA79366BC602E997DE24F940CE84961A2`	匹配
ATF-2	40,960 B	`B7E96F55097F01F481F5D75AACAD1D04AE9E6DD0C74F1F63E7BE14B3478E557E`	匹配
ATF-3	20,695 B	`FD593861297CB55B6D59E18041D0846AB74304F0888DBAF2E60ED71D36BF1F90`	匹配
ATF-4	8,192 B	`415B5D518F1E115B5ADAC3772DC55FE529C4E81A170E84FAA42A5BE1DC77C941`	匹配
ATF-5	8,192 B	`4D791BF0037A7C706B8724375ADC9BBFB55D7CCC3F166A3023E223C746B27C54`	匹配
ATF-6	7,732 B	`6E9D32BA2391EA86EC585080EEBB4C76FAE7B5363DCA1A69E6035BA3E4491BC8`	匹配
OP-TEE	457,112 B	`AF414B9C9F1A05B058DE55DE4AD0FA6EC1F40E6B42769454196EE63279570CC7`	匹配
U-Boot DTB	14,285 B	`FCFDA359C09A8B315DE67F0F6A4DB29122F97FADFA185D0D4A9AEE69488CC76D`	匹配

U-Boot DTB 描述：

model      = Rockchip RK3568 Evaluation Board
compatible = rockchip,rk3568-evb
             rockchip,rk3568

U-Boot 版本字符串为：

U-Boot 2017.09 #gecedu (Aug 17 2025 - 12:43:41 +0800)

正常板启动日志中多次出现：

## Checking uboot 0x00a00000 ... sha256(e914f0763a...) + OK

其中 e914f0763a... 正是本镜像内部 U-Boot 子镜像的 SHA-256，而不是整个 4 MiB文件的哈希，两者不要混淆。

CC 扫描结果¶

4 MiB文件中共有 4,032 个零散 0xCC 字节，占约 0.0961%，最长连续只有 6 字节。没有长段 CC，也没有和此前异常备份相同的填充结构。

9 个 FIT 子镜像的 SHA-256 全部与各自内嵌值一致。FIT 中还存在 sha256,rsa2048 签名描述；本次完成的是数据 SHA-256 和冗余副本一致性验证，没有另行使用公钥执行 RSA 签名认证。

18.5 uboot 与其他目录的关系¶

4.19.232驱动backup\uboot.img
SHA-256 = 8E640CC5...69FD25

C:\rockdev\Image\uboot.img
SHA-256 = 8E640CC5...69FD25

二者逐字节相同。因此 C:\rockdev\Image\uboot.img 可以追溯到这份结构完整的 uboot，而不是 3 月 3 日 backup\Image\uboot.img 的副本。

3 月 3 日备份 uboot 的文件 SHA-256 为：

E483671FF8EC32D4B5722FAED557C3DB2BD164338182DE773DDC8E83A9BEF516

它与当前 4.19.232 uboot 不同。此前检查显示它也有 FIT 头，但属于另一内容/版本，不能仅凭“都能识别为 FIT”就互相替代。

18.6 两个镜像的使用结论¶

文件	完整性结论	建议
boot.img	生成方法未证实；FIT 三项数据哈希全部匹配，无长段 CC；Linux 4.19.232、EVB1 DDR4 V10 DTB	可作为该 4.19.232 板卡配置的完整参考 boot，以及截断导出结果的内容对照
uboot.img	生成方法未证实；双 2 MiB副本完全相同，9 项 FIT 数据哈希全部匹配，无长段 CC	可作为对应 `#gecedu` 2025-08-17 构建的完整参考 uboot

从文件完整性角度，这两个镜像都明显优于 3 月 4 日的 CC 镜像。它们证明完整的 4.19.232 boot/uboot 数据确实存在，并能作为截断结果的内容对照；它们不能证明使用了哪一条读取路径。实际刷写前仍要确认目标板硬件版本、MiniLoader、parameter、DDR/存储配置及外设 DTS 与这套 4.19.232 构建匹配，不能只因哈希正确就跨硬件版本盲刷。

19. 最终判断¶

本次问题不是单一“设备树错了”或单一“parameter 地址错了”，而是一条连续故障链：

Loader/设备读取能力异常 + USB 通信不稳定
                ↓
分区导出失败或短读
                ↓
RKDevTool/AndroidTool 未正确丢弃失败结果
                ↓
生成全 CC或部分 CC 的假备份
                ↓
坏 boot 内核跨过 16 MiB边界，SHA-256 校验失败
                ↓
异常镜像很可能又被按分区刷回
                ↓
boot、recovery、OEM、logo、userdata 等内容被破坏

现有证据足以确认“CC 在导出失败时形成”和“CC boot 直接导致内核 Bad hash”；也足以高度怀疑 3 月 4 日晚坏镜像被刷回。现有日志不足以唯一判定是 v2.38 内部 bug、旧 Loader 还是具体 USB 硬件中断，但这不影响对坏镜像本身和启动失败原因的判断。

20. 2026 年 3 月启动日志标准化命名（2026-08-31 整理）¶

为避免 0305.txt、0602.txt、最新.txt 等旧名称丢失时间和故障上下文，已对 logs/ 下本次调查涉及的 5 个目录、25 个串口日志统一重命名。采用格式：

YYYY-MM-DD_HHMM_板卡状态_操作或记录范围_可直接确认的结果.log

本次只变更目录名、文件名和扩展名，没有修改日志内容。Git 对 25 个文件均识别为 100% rename。完整旧名、新名及每个名称的证据依据见：

整理时同时修正了几项容易误读之处：

原 0602.txt 不是单次失败日志，而是含 Bad Hash、mtd_boot not defined、Kernel Panic、成功进入系统等多轮状态的混合抓取。
原 MobaXterm 正常板日志不只含 DDR V1.18，后半还含 DDR V1.16 的启动周期。
mtd_boot not defined 被保留为可观察现象，但没有被写成 CC 或 FIT Bad Hash 的根因。
正常板日志也出现 Card did not respond to voltage select，因此文件名没有把该告警直接等同于 eMMC 损坏。
4A897379... 与 CA79EDC3... 分别标记，避免把两类 Bad Hash 误当成同一份坏 boot。

RK3568 分区备份大量 0xCC 异常调查笔记¶

1. 一句话结论¶

2. 结论分级¶

2.1 已确认事实¶

2.2 高可信推断¶

2.3 当前不能唯一确认¶

3. 调查涉及的主要目录¶

3.1 3 月 4 日分区备份¶

3.2 后续整理/刷机目录¶

3.3 “好板”boot 导出¶

3.4 完整可用 boot 参考¶

3.5 工具日志¶

4. 正确分区布局与错误 parameter¶

4.1 备份目录中的正确布局¶

4.2 C:\rockdev\Image\parameter.txt 的错误¶

5. 各分区导出/落盘时间线¶

5.1 uboot 的时间说明¶

5.2 rootfs 的异常长时间¶

5.3 3 月 4 日晚的明显转折¶

6. 各镜像内容取证¶

6.1 boot：典型的 16 MiB 短读/未填充边界¶

6.2 全 CC 分区¶

6.3 misc¶

6.4 设备树问题¶

7. boot 哈希失败与启动日志的直接对应¶

8. boot 文件之间的哈希关系¶

9. C:\rockdev\Image 与备份目录的哈希比对¶

10. 工具日志一：正点原子 RKDevTool v2.92¶

10.1 按日错误统计¶

10.2 3 月 3 日：大量明确的导出不支持¶

10.3 3 月 4 日：文件生成时日志恰好静默¶

10.4 3 月 4 日 22:36 和 22:53 的整套写入¶

10.5 22:10 的可疑地址组合¶

10.6 userdata 比目标分区大 31 个扇区¶

10.7 3 月 5 日好板 boot 前的失败¶

11. 工具日志二：OECT RKDevTool v2.84¶

11.1 3 月 2 日¶

11.2 3 月 3 日¶

11.3 3 月 4 日¶

11.4 3 月 5 日 10:50 的完整刷机¶

11.5 完整刷机后的异常¶

12. 工具日志三：AndroidTool v2.38¶

12.1 3 月 5 日¶

12.2 3 月 6 日¶

13. USB 错误码的含义¶

14. 综合事件时间线¶

3 月 2 日¶

3 月 3 日上午¶

3 月 3 日下午至 3 月 4 日上午¶

3 月 4 日晚¶

3 月 5 日上午¶

3 月 5 日下午和晚上¶

3 月 6 日¶

3 月 7 日¶

15. 最可能的故障机制¶

15.1 直接机制¶

15.2 为什么有的分区正常、有的全 CC¶

15.3 为什么不是设备树导致¶

15.4 为什么不是 parameter 单独导致¶

16. 对此前问题的集中回答¶

“为什么这些分区都是 CC？”¶

“boot 为什么 16 MiB之后都是 CC？”¶

“0xCC 设备树完全没用吗？”¶

“C:\rockdev\Image 和 backup 有几部分完全相同？”¶

“hash 比对了吗？”¶

“日志里的 ReadFile failed、短读、USB 995/121 体现在哪里？”¶

17. 后续备份和刷机建议¶

17.1 不再使用这批镜像作为恢复源¶

17.2 修正 parameter¶

17.3 导出前固定环境¶

17.4 每个分区至少导出两遍¶

17.5 不只检查文件大小¶

17.6 刷写前建立清单¶

18. 4.19.232驱动backup 两个镜像专项分析¶

18.1 文件基本信息¶

与 3 月 7 日 11:28 豆包聊天的时间关系¶

豆包步骤中与本机 GPT 不一致的危险假设¶

18.2 boot.img：完整可校验的 Linux 4.19.232 FIT¶

CC 扫描结果¶

18.3 与两份截断 boot 的 16 MiB 分段比对¶

RK3568 分区备份大量 `0xCC` 异常调查笔记¶

4.2 `C:\rockdev\Image\parameter.txt` 的错误¶

9. `C:\rockdev\Image` 与备份目录的哈希比对¶

18. `4.19.232驱动backup` 两个镜像专项分析¶