Repository navigation
Install NAND cameras on u-boot-xmedia SoCs as one UBI device, written with write.trimffs - #392
Merged
Merged
Conversation
… with write.trimffs OpenIPC is retiring the HiSilicon split NAND layout (boot, env, a raw kernel at 0x100000, UBI at 0x400000; `run uknand; run urnand; run setnand`) on the SoCs whose bootloader is u-boot-xmedia. Their NAND is now mtdparts <hinand|nand>:768k(boot),256k(env),-(ubi): U-Boot at 0, env at 0xc0000, and one UBI device from 0x100000 to the end of the chip holding the kernel (FIT), rootfs and rootfs_data volumes. rootfs.ubi.<board> is the only file an install writes, and it must go on with `nand write.trimffs`: a plain write programs the 0xFF padding pages, UBIFS programs them again later, and the ECC breaks (OpenIPC/firmware#2519). The same holds for a full image that contains it. Data-driven: a catalogue entry that names `uboot_nand_filename` is on the UBI-only layout and installs that bootloader on NAND; `uboot_filename` becomes its -nor.bin build. HI3516EV200, HI3516EV300, HI3518EV300 and HI3516DV200 move to u-boot-<soc>-{nor,nand}.bin. GK7205V500, GK7205V510 and GK7205V530 join the Goke catalogue the same way (board gk7205v500, load address 0x42000000 per u-boot-xmedia's baseaddr). Every other NAND SoC keeps today's flow; its wizard document is byte for byte unchanged. For a UBI-only NAND camera the wizard now prints: U-Boot: tftpboot <la> u-boot-<soc>-nand.bin && nand erase 0x0 0xc0000 && nand write <la> 0x0 0xc0000 (after mw.b <la> 0xff 0xc0000) Linux: tftpboot <la> rootfs.ubi.<board> && nand erase 0x100000 0x7f00000 && nand write.trimffs <la> 0x100000 ${filesize} (fatload from SD likewise; env/ethaddr/saveenv lines kept) Full: ... && nand erase 0x0 0x8000000 && nand write.trimffs <la> 0x0 ${filesize} with no `run setnand` in any block and no bootloader macros advertised (bootloader_variables is empty; the page drops its printenv sentence when there is nothing to name). NOR installs are unchanged apart from the bootloader file name. The full NAND image for these SoCs is the NAND bootloader at 0 (refused past 0xc0000) and rootfs.ubi at 0x100000 (bounded by the 128 MiB chip), ending at the UBI image rounded up to a 2 KiB page, 0xFF between; no uImage. layoutVersion goes to 2 so every cached image is rebuilt. Availability and the download page's missing-bootloader message ask after the bootloader the requested flash type installs. The wizard document gains uboot_nand_filename, bl_nand_url and bootloader_nand_published only on the UBI-only SoCs, so the JSON stays backward compatible; the SoC page offers both bootloaders, labelled NOR and NAND, and the by-parts U-Boot step links the one its commands write. Goldens: documents.json changes for exactly hi3516dv200, hi3516ev200, hi3516ev300 and hi3518ev300, and gains gk7205v500/510/530. The release index fixture gains u-boot-{hi3516dv200,hi3516ev200,hi3518ev300}-{nor,nand}.bin and u-boot-hi3516ev300-nor.bin as synthetic rows (no digest), standing for files the firmware repository must publish before this deploys; until it does, those SoCs read as firmware_only. The sitemap golden and deploy/firmware-segments.tsv gain the three Goke SoCs.
PR Summary by QodoInstall u-boot-xmedia NAND cameras with a single UBI layout
AI Description
Diagram
High-Level Assessment
Files changed (22)
|
Code Review by Qodo
1.
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
…th its bootloader Review on #392. - GK7205V510 has a NOR build of its own, but its NAND firmware is the GK7205V500 build. A new catalogue field, nand_board, names the build a SoC's NAND firmware comes from. firmware.BoardFor resolves the build per flash type, and the tarball, the image members, availability, the wizard's releases and its install lines all go through it. - On a UBI-only SoC, each flash type installs its own bootloader. A flash type whose bootloader is not published is no longer offered: it gets no editions and no combinations, rather than the nothing-published menu. Old links fall back to an offered chip as before. The U-Boot download link only shows when its file is published. - The UBI install erases a 128 MiB chip. The Linux block now says so, and gives the 0xff00000 length for a 256 MiB part. New tests: TestUBINandWithoutItsBootloaderIsNotOffered and TestNANDBoardIsUsedForNANDOnly. boards.json now records V510's own NOR build. Go (service/run.sh test), frontend lint, typecheck, tests and build all pass.
widgetii
added a commit
that referenced
this pull request
Oct 4, 2026
… MiB install too (#393) The UBI-only NAND install erased a fixed 0x7f00000 from 0x100000, which is the end of a 128 MiB chip. The partition is -(ubi) and runs to the end of whatever chip there is, so on a bigger one stale blocks were left behind, which UBI counts as corrupted PEBs when it attaches. - The Linux step now erases with `nand erase.part ubi`, which the u-boot-xmedia NAND build carries (OpenIPC/u-boot-xmedia#12) and the U-Boot step installs first. - The full-flash image, written from whatever U-Boot the camera has, erases with `nand erase.chip`. - Both keep write.trimffs. Also gofmt on catalogue.go, which #392 left unformatted.
widgetii
added a commit
to OpenIPC/defib
that referenced
this pull request
Oct 4, 2026
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: ``` 0x000000 boot 768K u-boot-<soc>-nand.bin 0x0C0000 env 256K 0x100000 ubi rest rootfs.ubi.<board>: UBIFS rootfs (kernel inside, /boot/fitImage) + rootfs_data ``` defib still installed the retired split layout on these SoCs and downloaded the retired `-universal` bootloader for them. ## Install (`install --nand`) For these SoCs `install --nand` now: - writes `u-boot-<soc>-nand.bin` into 0..0xc0000; - writes `rootfs.ubi.<board>` with `nand erase.part ubi` and `nand write.trimffs`, then reads it back and CRC-checks it; - runs `env default -a`, restores the MAC, and saves. **Never sent:** `setenv mtdparts`, `mtdids`, `bootcmd`, `bootargs`, or `ubi part`/`create`/`write`. **Kernel and `rootfs-data` stages:** no-ops. The kernel and an empty `rootfs_data` are inside the UBI image. **Erase safety:** - The installer checks that `mtdparts` puts `ubi` at 0x100000 before erasing. - It falls back to `nand erase 0x100000` (to the chip end) where `erase.part` is unavailable. - Other chips keep the split-layout path. ## Bootloader names These seven SoCs resolve per flash type, to `u-boot-<soc>-nor.bin` or `u-boot-<soc>-nand.bin`. - `install` follows `--nand`. `burn` gains `--nand` and defaults to NOR. `restore --flash-type` follows the flash type. - The `-universal` image is never downloaded for them, and a stale cached one doesn't stand in for the new build. - Every other chip is unchanged. ## Web UI - Takes the `-nor` build for these SoCs. - Now cuts the SPL where the compressed payload starts (`detectSplSize`, a port of `HiSiliconStandard._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-cycle` with the NAND package and the u-boot-xmedia master NAND image ran end to end: - burned U-Boot to RAM from the boot ROM; - `U-Boot OK`; - `Erased ubi: 0x100000, 0x7F00000 bytes`; - `Flash verified: E2E60EAA`; - `Restoring factory ethaddr`, `Environment saved`; - rebooted into OpenIPC, which booted `/boot/fitImage` and came up on the network. Separately, `defib burn -c hi3516ev300 -f u-boot-hi3516ev300-nand.bin` loaded the u-boot-xmedia image from the boot ROM; defib found its gzip SPL boundary at 0x4400. ## Tests - pytest: 1020 passed. ruff and mypy clean. - New `tests/test_nand_ubi_install.py`: the exact console sequence, the erase fallback, the missing-`mtdparts` path, refusing a relocated `ubi`, an env-only run, and a NOR install taking `-nor` over a cached `-universal`. - `tests/test_firmware.py` covers names per flash type. - Web tests: 92 pass. The new `detectSplSize` gives 0x4400 on the real hi3516ev300 image. ## Not verified on hardware - The gk7205v5xx and hi3516dv200 paths. - The Web UI recovery with the `-nor` images. - The `erase.part` fallback on a U-Boot without it.
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.
OpenIPC NAND images for the u-boot-xmedia SoCs now use one layout, described below. It landed in OpenIPC/u-boot-xmedia#11 and OpenIPC/firmware#2537.
The wizard's NAND instructions for these SoCs followed the retired split layout:
run uknand; run urnand; run setnand, a uImage at 0x100000, androotfs.ubiat 0x400000. They now match the new layout.What changes
The catalogue drives the change: a SoC entry with
uboot_nand_filenameuses the new flow.SoCs and bootloader files
goke.yml; they were missing from the catalogue.uboot_filenameis the-nor.binimage, and NAND uses the-nand.binone. u-boot-xmedia now publishes both for all seven, replacing the old-universalimage.U-Boot block
mw.b … 0xc0000tftpboot u-boot-<soc>-nand.bin && nand erase 0x0 0xc0000 && nand write … 0x0 0xc0000Linux block
tftpboot rootfs.ubi.<board> && nand erase 0x100000 0x7f00000 && nand write.trimffs … 0x100000 ${filesize}uknand,urnandorsetnand. The SD-card path loadsrootfs.ubithe same way.write.trimffsis required. A plain write programs the UBI image's 0xFF padding pages, and UBIFS later programs them a second time, which breaks their ECC (GK7205V500 (FMC100 SPI-NAND): silent uncorrectable-ECC rots the UBIFS rootfs — same defect as #2285 firmware#2519).Full-flash image (
firmware/layout.go)rootfs.ubiat 0x100000, and no uImage.nand write.trimffs.layoutVersionis bumped so cached images rebuild.Rest of the site
uboot_nand_filename,bl_nand_urlandbootloader_nand_published, and only for these SoCs, so it stays backward compatible.Every other SoC's output is unchanged. The
documents.jsongolden diffs are limited to the seven SoCs above.Verification
service/run.sh test(go vet + go test against postgres:17) passes.export:checkis current.TestUBINandLinesandTestUBINandImage./boot/fitImagefrom UBIFS with its hashes verified.u-boot-<soc>-{nor,nand}.binfor the four HiSilicon SoCs (published 2026-10-04), so the links resolve.