install: write the UBI-only NAND layout for u-boot-xmedia SoCs - #147
Merged
Merged
Conversation
OpenIPC retired the HiSilicon split NAND layout (1M boot, 1M env, 8M raw
kernel, ubi) and the u-boot-hi3516ev200 "universal" build that carried
it. hi3516ev200, hi3516ev300, hi3518ev300, hi3516dv200 and
gk7205v500/v510/v530 now boot u-boot-xmedia, published per flash type in
the OpenIPC/firmware latest release as u-boot-<soc>-nor.bin and
u-boot-<soc>-nand.bin. The NAND build uses one layout:
0x000000 boot 768K u-boot-<soc>-nand.bin
0x0C0000 env 256K
0x100000 ubi rest rootfs.ubi.<board> (rootfs volume with the
kernel as /boot/fitImage, plus rootfs_data)
and its default environment defines mtdids/mtdparts, bootcmd and
bootargs for it.
firmware: PER_FLASH_TYPE_UBOOT lists those SoCs. asset_name(),
firmware_url(), has_firmware(), get_cached_path() and download_firmware()
take an optional flash_type ("nor"/"nand", NOR when unknown) and resolve
u-boot-<soc>-<type>.bin for them; other chips ignore it. The universal
image is never downloaded for these SoCs. A universal image already in the
cache is no longer reported by get_cached_path() (it would shadow the
published build), but download_firmware() still falls back to it for NOR
when the download fails. gk7205v5x0 NOR shares its cache name with
download_v500_donor(), so either source satisfies the other.
Callers: install picks the build from --nand; burn gains --nand (NOR by
default); restore uses the NAND build for --flash-type nand and warns that
"auto" means NOR for these SoCs. agent upload/flash only take the SPL,
whose DDR init is the same in both builds, so they keep the NOR default.
install: with --nand on those SoCs the plan becomes
uboot tftp u (padded to 0xC0000), crc32, nand erase 0x0 0xc0000,
nand write <ram> 0x0 0xc0000
kernel no-op: the kernel is inside the UBI image
rootfs tftp r (rootfs.ubi.<board>), crc32, printenv mtdparts,
nand erase.part ubi, nand write.trimffs <ram> 0x100000 <len>,
nand read + crc32 readback when crc32 is available
rootfs-data no-op: the UBI image carries an empty rootfs_data
env (if uboot was written) env default -a, restore ethaddr, saveenv
reset
with no setenv mtdparts/bootcmd/bootargs and no ubi create/write.
write.trimffs is required: a plain nand write programs the image's 0xFF
pages and UBIFS programming them again breaks ECC (OpenIPC/firmware#2519).
erase.part erases the whole partition, so chips over 128 MiB lose every
stale block. It runs only when the live mtdparts puts ubi at 0x100000; a
different offset aborts before any erase. Without mtdparts, or when the
U-Boot lacks erase.part (no "Erasing at" in the reply), the installer
erases with `nand erase 0x100000`, which U-Boot runs to the chip end. The
reported erase offset must be 0x100000 and the image must fit the
reported size. The firmware package member is rootfs.ubi.<board>
(never rootfs.ubifs.*); a package without one is rejected with a pointer
to openipc.<board>-nand-<variant>.tgz.
The split layout stays only for `install --nand` on other chips: it is
chip-agnostic code the existing hi3516cv300 test drives, and nothing in
the tree says those chips moved.
Tests: offline FakeNandUBoot console checks the exact hi3516ev300 NAND
command sequence, the erase.part fallback, the missing-mtdparts path, the
refusal on a foreign ubi offset, an env-only run, the NOR install picking
u-boot-hi3516ev300-nor.bin, package member selection, and the per-flash
naming for all seven SoCs.
Untested on hardware: the full install. The command sequence follows the
manual procedure verified on a hi3516ev300 with a defib-burned
u-boot-hi3516ev300-nand.bin; the erase.part fallback and the readback CRC
step have not run on a camera.
The seven u-boot-xmedia SoCs (hi3516ev200/ev300/dv200, hi3518ev300, gk7205v500/v510/v530) publish their U-Boot per flash type now. The -universal image the Web UI looked for is the retired u-boot-hi3516ev200 build, or absent. A recovery loads U-Boot into RAM and needs no flash layout, so the Web UI takes the -nor build (fwAssetName), as `defib burn` does without --nand. A stale -universal asset of these SoCs is ignored rather than taken in its place. Those images put their compressed payload earlier than the reference SPL the profiles describe (gzip at 0x4400 against FILELEN 0x6000). The Web UI sent the profile's length, and bytes past the payload land in SRAM the bootrom uses for its own state. detectSplSize ports HiSiliconStandard._detect_spl_size: it finds the LZMA or gzip header from 0x4000, rounds down to 1K and caps at SRAMLIMIT where a profile has one. On the real u-boot-hi3516ev300-nand.bin it gives 0x4400, the same as defib's Python. Web tests: 92 pass.
PR Summary by QodoInstall the UBI-only NAND layout for u-boot-xmedia SoCs
AI Description
Diagram
High-Level Assessment
Files changed (12)
|
Code Review by Qodo
1.
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
Review on #147. - load_firmware_bundle checks that rootfs.ubi.<board> is built for the chip being installed, through ubi_nand_boards: the chip itself, plus gk7205v500 for gk7205v510/v530, which share that build. The image carries its kernel, so one built for another board would put that board's system on this camera's NAND. - mtdparts_partition_offset(..., nand_only=True) looks for `ubi` only on NAND devices (an mtd-id with "nand" in it). A `ubi` on a SPI device listed first can no longer pass, or fail, the erase guard for the NAND one. - The Web UI cuts the SPL at its payload only for the u-boot-xmedia images. Its profiles carry no SRAMLIMIT, so on other chips, where a payload can sit past the SRAM window (hi3520dv200, 0x4400 against 0x3B00), it keeps sending the profile length as it always did.
This was referenced Oct 4, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The u-boot-xmedia SoCs (hi3516ev200/ev300/dv200, hi3518ev300, gk7205v500/v510/v530) moved to one NAND layout. It landed in OpenIPC/u-boot-xmedia#11 and #12, OpenIPC/firmware#2537, and OpenIPC/website#392 and #393:
defib still installed the retired split layout on these SoCs and downloaded the retired
-universalbootloader for them.Install (
install --nand)For these SoCs
install --nandnow:u-boot-<soc>-nand.bininto 0..0xc0000;rootfs.ubi.<board>withnand erase.part ubiandnand write.trimffs, then reads it back and CRC-checks it;env default -a, restores the MAC, and saves.Never sent:
setenv mtdparts,mtdids,bootcmd,bootargs, orubi part/create/write.Kernel and
rootfs-datastages: no-ops. The kernel and an emptyrootfs_dataare inside the UBI image.Erase safety:
mtdpartsputsubiat 0x100000 before erasing.nand erase 0x100000(to the chip end) whereerase.partis unavailable.Bootloader names
These seven SoCs resolve per flash type, to
u-boot-<soc>-nor.binoru-boot-<soc>-nand.bin.installfollows--nand.burngains--nandand defaults to NOR.restore --flash-typefollows the flash type.-universalimage is never downloaded for them, and a stale cached one doesn't stand in for the new build.Web UI
-norbuild for these SoCs.detectSplSize, a port ofHiSiliconStandard._detect_spl_size). The u-boot-xmedia images put it at 0x4400, while the profile says 0x6000. Sending the profile length writes into SRAM the boot ROM uses for its own state.Verified
On a hi3516ev300 (W25N01GV, 128 MiB, 5 factory bad blocks),
defib install -c hi3516ev300 --nand --power-cyclewith the NAND package and the u-boot-xmedia master NAND image ran end to end:U-Boot OK;Erased ubi: 0x100000, 0x7F00000 bytes;Flash verified: E2E60EAA;Restoring factory ethaddr,Environment saved;/boot/fitImageand came up on the network.Separately,
defib burn -c hi3516ev300 -f u-boot-hi3516ev300-nand.binloaded the u-boot-xmedia image from the boot ROM; defib found its gzip SPL boundary at 0x4400.Tests
tests/test_nand_ubi_install.py: the exact console sequence, the erase fallback, the missing-mtdpartspath, refusing a relocatedubi, an env-only run, and a NOR install taking-norover a cached-universal.tests/test_firmware.pycovers names per flash type.detectSplSizegives 0x4400 on the real hi3516ev300 image.Not verified on hardware
-norimages.erase.partfallback on a U-Boot without it.