Troubleshooting guide
A successful write-tool result does not establish matching stored data or actual selection of SD boot. Retain separate evidence for the source images, readback of specified ranges and the actual boot path, all tied to the same board, build and medium.
Can an image hash be compared directly with a whole-card hash?
Usually not. An image may cover only one offset and length, while an SD card also contains partition tables, other partitions and unused space. Read the matching byte ranges from the write manifest and retain offset, length, source hash, readback hash and target-medium identity. Do not compare a whole-card hash directly with one image file.
Record when readback occurred. A booted system may change writable partitions; that is a different condition from verification immediately after writing and before first boot.
Evidence that separates the failure modes
Swipe the table horizontally to view all columns.
| Evidence | What it supports | Additional checks needed |
|---|---|---|
| Write-tool completion status | The tool reported completion of that write | Target-device identity and actual written ranges |
| Matching specified-range readback | The selected bytes matched under that read condition | Completeness of the partition manifest, cache handling and verification time |
| Bootloader loading record | The selected boot entry and load path | Root and data partitions actually mounted after kernel startup |
| Kernel, init and mount records | Startup stage reached and actual storage paths | Target peripherals, graphics and sustained-operation checks |
If the old system still boots, inspect boot selection, actual Bootloader paths and partition references first. Repeated writing is not a diagnosis. Reconfirm SD and eMMC identities before further operations and retain the existing recovery environment.
Boundaries of the original readback and boot records
The Chinese-language OpenHarmony 6.1 RK3588 project report is limited to a specified board, Build22, SD media and Stage-0 without a graphical interface. It documents storage-path adaptation and serial boot evidence. The 480-second log covers only that observation window. Graphics, peripheral coverage and long-term reliability require separate tests. Build23 build and static checks do not substitute for board regression.
For a similar investigation, provide the board, image manifest, offsets and lengths, medium identifiers and complete serial-port console logs through the Chinese-language embedded-system adaptation service. That service page describes Linux BSP work; an OpenHarmony task requires a separately agreed system baseline and adaptation scope.
Online
Phone
WeChat
Top