Context
Starting with the next release of OpenIPC/u-boot-hi3519v101, both published assets in OpenIPC/firmware's latest release ship unpadded — they are the raw mini-boot.bin produced by the LZMA self-extractor build:
u-boot-hi3516av200-universal.bin — was 1 MiB padded, becomes the raw blob (~199 KB).u-boot-hi3519v101-universal.bin — already raw in the current release; producer side is now formalized to keep it that way.
Rationale: padding is a flash-geometry concern (NAND erase-block alignment, NOR sector alignment, partition layout). It belongs in the tool that knows the target device, not in the boot-image producer.
Source change: OpenIPC/u-boot-hi3519v101#12
Ask
defib should pad each u-boot-${soc}-universal.bin up to the appropriate erase-block multiple before writing it to the target. The exact size depends on the board's flash geometry (typical hi3516av200 NAND uses 128 KiB or 256 KiB erase blocks; NOR variants of hi3519v101 use 64 KiB sectors; 1 MiB is a safe upper bound that historically matched the av200 asset).
Likely touch points (from a quick look at the repo):
src/defib/firmware.py — wherever the u-boot blob is read and dispatched to flash; pad just before the write call.src/defib/profiles/data/hi3516av200.json, src/defib/profiles/data/hi3519v101.json — could carry an explicit pad_to field (or derive from the partition/erase-block size already encoded in the profile).docs/nand-ubi-restore-guide.md — note the new producer-side behavior so manual users don't get surprised by smaller asset sizes.
Verification
- Download the new (unpadded) assets and run defib's flash flow against a hi3516av200 device and a hi3519v101 device.
- Confirm
mtd write / NAND program / NOR program operations still succeed (would fail today on a non-erase-block-aligned write to NAND).
- Compare bytes-on-flash vs. a prior padded asset: the leading ~199 KB should be byte-identical, and the trailing pad bytes should be 0xFF up to the next erase block.
Related
Closed issue #54 ("ubi write fails with 'Cannot start volume update' on hi3516av200") was the same SoC's flashing path — worth checking the fix path didn't already land padding logic that we can extend here.
Context
Starting with the next release of
OpenIPC/u-boot-hi3519v101, both published assets inOpenIPC/firmware'slatestrelease ship unpadded — they are the rawmini-boot.binproduced by the LZMA self-extractor build:u-boot-hi3516av200-universal.bin— was 1 MiB padded, becomes the raw blob (~199 KB).u-boot-hi3519v101-universal.bin— already raw in the current release; producer side is now formalized to keep it that way.Rationale: padding is a flash-geometry concern (NAND erase-block alignment, NOR sector alignment, partition layout). It belongs in the tool that knows the target device, not in the boot-image producer.
Source change: OpenIPC/u-boot-hi3519v101#12
Ask
defibshould pad eachu-boot-${soc}-universal.binup to the appropriate erase-block multiple before writing it to the target. The exact size depends on the board's flash geometry (typical hi3516av200 NAND uses 128 KiB or 256 KiB erase blocks; NOR variants of hi3519v101 use 64 KiB sectors; 1 MiB is a safe upper bound that historically matched the av200 asset).Likely touch points (from a quick look at the repo):
src/defib/firmware.py— wherever the u-boot blob is read and dispatched to flash; pad just before the write call.src/defib/profiles/data/hi3516av200.json,src/defib/profiles/data/hi3519v101.json— could carry an explicitpad_tofield (or derive from the partition/erase-block size already encoded in the profile).docs/nand-ubi-restore-guide.md— note the new producer-side behavior so manual users don't get surprised by smaller asset sizes.Verification
mtd write/ NAND program / NOR program operations still succeed (would fail today on a non-erase-block-aligned write to NAND).Related
Closed issue #54 ("ubi write fails with 'Cannot start volume update' on hi3516av200") was the same SoC's flashing path — worth checking the fix path didn't already land padding logic that we can extend here.