gk7205v500 NAND: FIT kernel volume, CMA, and sysupgrade for UBI layouts - #2526
Merged
Merged
Conversation
PR Summary by QodoBootable gk7205v500 NAND images with CMA and UBI sysupgrade
AI Description
Diagram
High-Level Assessment
Files changed (14)
|
Member
Author
|
The hisilicon-opensdk CMA patch carried here is now upstream as OpenIPC/openhisilicon#236 (same diff, against |
Code Review by Qodo
1.
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
The gk7205v500 family ran with mem=${osmem} (32M) and an xmedia
carve-out for the MMZ, so Linux saw a quarter of a V510's 128 MiB. That
is the wrong configuration for this SoC. On gk7205v200 the MMZ is a CMA
zone inside Linux's memory; this does the same for gk7205v500.
- Kernel: CMA, DMA_CMA, CMA_MEM_SHARED, plus COMPACTION and MIGRATION.
The xmedia kernel reserves the zone named by mmz= on the command line
(drivers/xmedia/cma) and, with CMA_MEM_SHARED, lends it to movable
pages while the media stack does not need it.
- load_goke:
- A command line that names no allocator is rewritten for the next
boot:
mem=${totalmem} ... mmz_allocator=cma mmz=anonymous,0,<osmem>,<rest>
Every other bootargs token is kept (#2281). totalmem is the DDR size
u-boot-xmedia writes into the env.
- xm_osal then loads with mmz_allocator=cma mmz=$MMZ.
- mmz_allocator=xmedia in bootargs keeps the carve-out.
- The "os_mem from mem=" override (for vendor bootloaders passing
mem=70M) now applies to the carve-out only. Under CMA, mem= is the
whole DDR, and the override tripped load_goke's own
"os_mem over total_mem" guard, so no module loaded.
- hisilicon-opensdk is bumped to dfc3a81 (OpenIPC/openhisilicon#236). The
gk7205v500 osal now builds its CMA allocator against the xmedia
kernel's API, honours the caller's alignment, and refuses to load with
no usable zone. Both variants take every xm_*.ko from opensdk, so all
are rebuilt against this kernel.
Verified on a GK7205V510 (128 MiB DDR):
- First boot after the change, still on mem=32M with the carve-out:
29 modules, no oops, and bootargs rewritten.
- Next boot: "cma: Reserved 96 MiB at 0x42000000", "cmz zone phys
0x42000000, nbytes 0x6000000". MemTotal is 125840 kB with ~97 MB
available, against 28612 kB total and ~15 MB available before.
CmaFree falls by the ~15 MB the media stack allocates.
- majestic reports "HiSilicon SDK started".
A squashfs root on ubiblock (root=/dev/ubiblockX_Y) names no "ubifs" on
the command line, so init took the jffs2 branch. That branch looks
rootfs_data up in /proc/mtd, and gluebi publishes the UBI volume there.
jffs2 then fails to mount on the UBIFS it holds ("Magic bitmask not
found"), and init runs flash_eraseall on it. Every boot erased the
overlay, and the camera's claim with it.
A ubiblock root now mounts ubi0:rootfs_data as UBIFS, as a UBIFS root
does. A squashfs reached through gluebi's mtdblock (root=/dev/mtdblockN,
sigmastar) does not match and keeps the jffs2 branch.
Verified on a GK7205V510 with root=/dev/ubiblock0_1 ubi.block=0,1: the
overlay is ubi0:rootfs_data (ubifs, rw) and the claim survives reboots.
u-boot-xmedia's NAND env reads the UBI volume `kernel`, but the gk7205v500 NAND image had no such volume: only UBIFS `rootfs` and `rootfs_data`. A release nand-ultimate image therefore did not boot on that U-Boot (#2524). - The NAND image gains a `kernel` volume holding a FIT (board/gk7205v500/nand-fit.its): the zImage and xm720xxx-demb.dtb, each with crc32 + sha1 hashes. U-Boot refuses a kernel NAND has corrupted instead of booting it. - board/gk7205v500/ubinize-nand.cfg: kernel 4 MiB, rootfs 32 MiB (UBIFS), rootfs_data autoresize. - rootfs_script.sh builds the FIT for any board shipping a nand-fit.its, from the kernel tree. ubinize runs before post-image, so post-build is the last place it can happen. - The kernel config is unchanged. The NOR image still boots the uImage with its appended DTB, and a plain zImage carries none. - The -nand- package carries fitImage and rootfs.ubifs, the two images sysupgrade writes into those volumes, plus rootfs.ubi for a fresh install. Each is size-checked against its volume. Needs u-boot-xmedia with FIT support for gk7205v500 NAND (OpenIPC/u-boot-xmedia, "xm720xxx: NAND boots a hashed FIT kernel from the UBI kernel volume").
sysupgrade addressed flash by MTD partition name. On a NAND camera whose
kernel and rootfs are UBI volumes, `kernel`, `rootfs` and `rootfs_data`
named nothing, or gluebi's view of a volume that is in use, so -k, -r and
-n could not work. This supports both UBI layouts:
ubifs kernel = FIT, rootfs = UBIFS (root=ubi0:rootfs). Installs the
-nand- package: fitImage.<soc> + rootfs.ubifs.<soc>.
ubiblock kernel = uImage, rootfs = squashfs through ubiblock
(root=/dev/ubiblockX_Y). Its volumes hold the NOR artifacts
verbatim, so it keeps the NOR package.
Everything else -- NOR, a raw NAND kernel partition, a squashfs on
gluebi's mtdblock -- takes the MTD path as before.
Writing:
- Volumes are written with ubiupdatevol, which also trims the 0xFF tail
of every LEB (#2519).
- UBI_IOCVOLUP takes the volume exclusively (get_exclusive() in
drivers/mtd/ubi/cdev.c), and the rootfs volume is held open on both
layouts:
- UBIFS opens its volume even for a read-only mount;
- ubiblock holds a reader.
- Measured on a ubiblock root, from inside the existing ramfs pivot:
"ubiupdatevol: UBI_IOCVOLUP: Resource busy".
- The pivot cannot help. init's overlay root is the old root, and PID 1
runs from it.
- So a rootfs write, or -n on a mounted UBIFS overlay, hands PID 1 off
first, as OpenWrt does with procd/upgraded:
- inittab gains ::restart:/sbin/init.
- sysupgrade stages a RAM root whose /sbin/init is its flash phase,
saves its state there (init execs it with init's environment, not
ours), pivot_roots (which moves PID 1's root too) and sends SIGQUIT
to PID 1.
- busybox init runs its shutdown actions inside the RAM root. umount
is moved off /bin, so `/bin/umount -a -f` cannot take /tmp and the
images. init then kills every process and execs the RAM root's
/sbin/init.
- As PID 1, the flash phase lazily unmounts the old root, which closes
the volumes, then writes, then reboots. It never exits: PID 1
exiting is a panic.
- A kernel-only run never needs the hand-off: the kernel volume is not
mounted.
Refusals, all before anything is written:
- an inittab with no ::restart: entry;
- a rootfs format the command line will not mount (squashfs on a UBIFS
root, or the reverse);
- a UBIFS image made for other LEBs than the volume's;
- an image larger than its volume (reserved_ebs * usable_eb_size).
A UBIFS rootfs cannot be loop-mounted, so its SoC rests on the evidence
an unmountable squashfs's does, and its whole verdict is reached before
the pivot.
Unpacking:
- A UBIFS package also holds rootfs.ubi, which is never written here.
tar leaves it, and its checksum, in the archive: /tmp is RAM.
- The RAM check sizes what is kept. That is about half of the unpacked
total, but 65% of the packed size measured on the gk7205v500 image:
UBIFS's 0xFF LEB padding costs gzip almost nothing.
Verified on a GK7205V510 (GD5F1GM7 NAND, 128 MiB DDR, CMA), each run
through the full sysupgrade over HTTP:
- ubifs: --url=...-nand-ultimate.tgz. Hand-off, "Flashing from RAM
(pid 1)", FIT kernel and UBIFS rootfs written, reboot. U-Boot reports
"Verifying Hash Integrity ... crc32+ sha1+ OK", the new build boots,
and the overlay and claim are preserved.
- ubiblock: --url=...-nor-ultimate.tgz. Hand-off, uImage and squashfs
written, new build boots, overlay and claim preserved.
- -n on the UBIFS overlay: hand-off, rootfs_data erased, and the next
boot says "default file-system created".
- No ECC, CRC or oops in dmesg after any of them.
widgetii
force-pushed
the
nand/ubi-fit-sysupgrade
branch
from
October 3, 2026 19:01
ba56981 to
ad09c41
Compare
- load_goke switches to CMA only where the kernel has it
(/proc/meminfo has CmaTotal). The script also loads gk7201v200, whose
kernel has no CMA, and it would have lost its MMZ.
- The NAND FIT is described as "OpenIPC <soc>", stamped from
OPENIPC_SOC_MODEL at build time.
- sysupgrade reads that as the SoC witness for the UBIFS rootfs beside
it (fit_soc), and checks it on the kernel write too.
- A local archive no longer counts as pinned by its file names: a UBIFS
rootfs without a FIT naming its SoC needs --force_soc.
- Stage 2 refuses to write anything when the old root cannot be
detached, instead of putting the kernel down and then failing on the
rootfs volume.
- A ubiblock camera whose inittab predates ::restart: is written through
gluebi's mtd, as before, rather than refused. Without gluebi it is
refused, with nothing written.
- init falls back to a tmpfs overlay when rootfs_data will not mount as
UBIFS, as its jffs2 branch does, instead of PID 1 exiting.
- Repack picks the FIT NAND package by the board's nand-fit.its, not by
whatever fitImage a reused output directory holds. rootfs_script.sh
also drops a stale one before building.
test_sysupgrade.sh gains the new cases: 246 checks, green against the
tree and the comment-stripped copy.
Verified on a GK7205V510, sysupgrade --url=...-nand-ultimate.tgz:
"SoC from the FIT kernel beside it: gk7205v500", "SoC OK", PID 1
hand-off, FIT and UBIFS written, the new build boots, the overlay is
kept, and there is no ECC/CRC/oops.
Member
Author
|
Review addressed in de9a4d1:
|
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.
Fixes #2524. gk7205v500 NAND gets a bootable layout, the whole DDR, and a working sysupgrade, for both UBI layouts.
Needs OpenIPC/u-boot-xmedia#10 (FIT boot from the UBI
kernelvolume) for the new NAND image to boot from that U-Boot's default env.Commits
load_gokeswitches a command line that names no allocator to CMA for the next boot.mmz_allocator=xmediakeeps the carve-out.hisilicon-opensdkbumped todfc3a81(gk7205v500: build the CMA allocator into osal openhisilicon#236), which builds the gk7205v500 osal's CMA allocator.kernel(FIT: zImage + DTB, crc32 + sha1),rootfs(UBIFS) androotfs_datavolumes.-nand-package carriesfitImage+rootfs.ubifsfor sysupgrade, plusrootfs.ubifor fresh installs.-nand-package) and the squashfs-over-ubiblock layout (NOR package).ubiupdatevolneeds its volume exclusively, and a mounted rootfs volume is always in use.::restart:/sbin/initentry, SIGQUIT, then a lazy unmount of the old root.Hardware verification
GK7205V510 + GD5F1GM7 NAND, 128 MiB DDR, U-Boot from u-boot-xmedia#10. Each case below was a real
sysupgradeover HTTP:--url=…-nand-ultimate.tgzcrc32+ sha1+ OK, new build boots, overlay/claim kept, 0 ECC/CRC/oops--url=…-nor-ultimate.tgz-non the UBIFS overlaymem=32Menv)load_gokeswitches the envThe
-nand-unpack (fitImage + rootfs.ubifs, ~14 MB) was refused onmem=32Mby sysupgrade's RAM check, correctly. It fits once the board runs CMA.Tests
test_sysupgrade.sh: 240 checks, 16 of them new for the UBI layouts:-nand-URL, and therootfs.ubiexclusion.One transient failure in 9 local runs did not reproduce.
test_shell_parse.shandtest_strip_shell_comments.shpass.Notes
Timeout from venc channel 0with and without CMA and on the old kernel too. That's a separate (sensor/ISP) problem, not part of this PR.