Repository navigation
hi3519dv500: load the media zone the kernel laid out - #2632
Merged
Merged
Conversation
The step #2240 took for the Goke V200 and hi3516ev200 families, for the two V5 SDK packages. A kernel that measures DRAM itself (OpenIPC/linux, hisi_mem: the hisilicon-hi3516cv6xx and -hi3519dv500 branches follow) publishes its layout in /sys/module/hisi_mem/parameters -- dram, osmem, allocator, mmz -- and load_hisilicon now loads open_mmz with exactly that, under any bootloader, without reading or writing the environment. That matters most on hi3519dv500, whose U-Boot passes mem=512M and no totalmem: load_hisilicon took the 64M default, found the OS share over it and exited before loading a single module. On a kernel without hisi_mem the zone still comes from totalmem/osmem and the command line, as before, minus the first-boot fw_setenv of mmz_allocator, which nothing on these parts reads back. set_allocator, the user's override (ot|cma|auto|mmz), is the hi3516ev200 one with the carve-out named "ot" as the V5 SDK names it, and hi3516cv6xx now installs it as hi3519dv500 does. test_load_hisilicon_layout.sh runs the same cases for all three packages under busybox sh and awk: the kernel's zone taken over a vendor mem=, nothing written to the environment, the older kernel's path unchanged. Tested in qemu-hisilicon with the kernels that publish hisi_mem: hi3516cv610 at 128M/256M/512M (cma 96M/224M/480M), hi3516cv608 at 64M ("ot", 32M), hi3519dv500 at 512M/1G/2G (cma 376M/516M/1540M): "mmz: anony=1 mmz_allocator=... mmz=anonymous,0,..." loaded, login. Not run on hardware: no board of either family in the lab.
widgetii
requested review from
cronyx,
flyrouter and
viktorxda
as code owners
October 19, 2026 03:57
PR Summary by QodoLoad V5 media zones from the kernel's memory layout
AI Description
Diagram
High-Level Assessment
Files changed (6)
|
Code Review by Qodo
1. Camera boot behavior is unverified
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
From review. On a kernel with hisi_mem, set_allocator wrote the OS share it was given as it was: `set_allocator ot 48` put mem=48 -- 48 bytes -- on the next boot's command line, and the camera did not come up again until someone recovered it over serial. It now takes N or NM, refuses anything else, and refuses a share below the 32M the kernel accepts or leaving under 8M of DRAM, as the kernel would. With no size given it keeps the share this boot runs with (128M on hi3519dv500), not a fixed 32M. Same in the hi3516ev200 package, where the bug came from. For an older kernel without totalmem, dt_mem_total read only a one-cell memory node (32-bit ARM). hi3519dv500's is two cells, and its U-Boot fixes it up from 0x40030000 (the 512M less ATF's 0x30000), so the size is now rounded up to whole 64 MiB there; the one-cell 512M stays the device tree's placeholder, as before. `set_allocator cma` still writes no osmem=: the kernel takes an explicit mmz= as the whole layout, and the OS share is what lies below the zone. test_load_hisilicon_layout.sh runs set_allocator for the three packages under busybox sh: 48 and 48M, 48K, 16M, 508M of 512M, cma's default, the two-cell and one-cell memory nodes. The scripts before this change fail six cases in each package.
Member
Author
|
Re the summary's finding 5 (comments claiming load_hisilicon calls set_allocator): fixed in 2f8c5a3. The cv6xx/dv500 set_allocator header no longer says so. |
The lite rootfs is exactly full on master (rootfs.squashfs 5120K of its 5120K slot), and the script tipped it 4K over. It is installed with the move to the split NOR package, where the rootfs is no longer held to a fixed slot. Nothing here calls it: load_hisilicon reads the kernel's layout, or the command line on an older kernel.
hi3516cv6xx_lite's rootfs is exactly full on master: 5120K of its 5120K fixed slot. The load_hisilicon change alone took it to 5124K. The cv6xx side moves to the change that publishes cv6xx as the split NOR package, where the rootfs is held to the chip, not a fixed slot. This PR is now hi3519dv500, and the set_allocator fix in hi3516ev200.
widgetii
changed the title
widgetii
added a commit
that referenced
this pull request
Oct 19, 2026
…amily (#2638) * hi3516cv6xx, hi3519dv500: the split NOR image, as on the gk7205v200 family No separate cases are left for hi3516cv6xx or hi3519dv500 in how the firmware is packed, upgraded or assembled; what differs is data. The image. One post-image script for every board on the split NOR layout, general/scripts/post-image-split.sh, in place of the gk7205v200, hi3516cv6xx and hi3519dv500 post-image.sh and both fit-image.its: firmware.bin is a legacy uImage, then the squashfs at the next 64 KiB. 32-bit ARM takes the kernel's own uImage (the zImage with its DTB appended, CONFIG_BUILD_ARM_APPENDED_DTB_IMAGE_NAMES); arm64 cannot append a DTB, so there it is a legacy multi-file uImage -- Image.gz, a trailer-only initramfs, the DTB -- which bootm unpacks the same way. The kernels (OpenIPC/linux #101-#109) find the layout from their device tree and divide "firmware" into kernel, rootfs and rootfs_data at boot. - Config.in: BR2_OPENIPC_NOR_FIRMWARE_OFFSET (0x50000; 0xC0000 on hi3519dv500, whose signed boot image needs 512k boot + 256k env) and BR2_OPENIPC_NOR_FIXED_PACKAGE (the Goke boards, which also publish the fixed-slot package). The Makefile's cv6xx and dv500 branches go; one branch packs every board that builds firmware.bin, checks it against the chip less the offset and an overlay, and publishes -split. - hi3516cv6xx/hi3519dv500 kernel configs: MTD_SPLIT_*, root from the split; cv6xx UIMAGE with its DTB appended, CMA; dv500 drops mem=128M and gains OVERLAY_FS, which it never had (its overlay stayed read-only). - The cv6xx memory userspace held back from #2632 (its lite rootfs was full on the FIT layout): load_hisilicon from hisi_mem, set_allocator installed. Upgrades. sysupgrade knows the split layout without a SoC list: a camera is split when its "firmware" partition holds the kernel's own partitions, the offset is read from /proc/mtd, and the -split package is fetched wherever the release publishes one. The FIT combined path, used by nobody else, is gone. Boards that publish only the split package are listed in the manifest under a new flash key, nor_split (consumers match the column exactly, so one asking for "nor" never takes it), and --build/--channel/--list fall back to it. Older scripts asking for the plain cv6xx package get a 404 and stop -- they cut firmware.bin at its 4th-7th bytes as a FIT size, and a uImage's header CRC sits there -- while every -k/-r run fetches this script first. CI. image.yml assembles the cv6xx (lite on 8 MiB, ultimate on 16 MiB) and hi3519dv500 (dmeb, dmebpro, 16 MiB) full images with one create_split: the boot image at 0, firmware.bin where the boot area ends, the rest erased; split_layout holds each board's boot and env sizes, and nothing else differs. hisi_layout/create_hisi and the withdrawal step go (#2460). build.yml and build-one.yml take the -split package as the NOR one where there is no plain one. Tested in qemu-hisilicon with the published boot images (OpenIPC/u-boot f8747f7b): full images from create_split -- hi3516cv610 DDR3-128M lite, rootfs_data at 7552 KiB as create_split reports, login; hi3519dv500 dmeb ultimate at 1G, cma 888M, rootfs_data at 14976 KiB. Packages: cv6xx lite at 64M/128M/256M/512M, dv500 at 128M-2G, overlay kept across a reboot. gk7205v200's firmware.bin and packages unchanged by the shared script (only the uImage header's time and CRC). Shell suites, lint, ci-matrix self-test pass. Not run on hardware: no hi3516cv6xx or hi3519dv500 board in the lab. * nor split: the uImage within what a bootloader in the field reads From review. The split image boots under any bootloader that reads a uImage from the firmware offset, but the ones in the field read a fixed amount: 2 MiB on hi3516cv6xx (its published U-Boot before it scanned the flash, and vendor ones), 6 MiB on hi3519dv500's. The fixed-slot package's 2 MiB check went with it for cv6xx, and nothing else bounded the kernel: a cv6xx uImage past 2 MiB would build, publish and assemble, and then be read short and fail its CRC on those bootloaders. cv6xx's is 2021K now. BR2_OPENIPC_NOR_KERNEL_READ_SIZE holds that read (0x200000; 0x600000 on hi3519dv500), and every split build checks the uImage against it in bytes -- CHECK_SIZE counts whole KB, which would let one byte over through. image.yml's create_split refuses the same. Checked: repack for hi3516cv6xx_lite (uImage 2021KB/2048KB) and hi3519dv500_ultimate (5630KB/6144KB) pass; with the limit set to 0x100000 the cv6xx repack stops, "size exceeded by: 1021261 bytes"; create_split from the workflow file passes both images and refuses the cv6xx one at a 1024 KiB read. * nor split: measure the uImage from firmware.bin's header CHECK_KERNEL_READ stat'ed images/uImage, which the fixed-slot package's repack has already renamed to uImage.<soc> on the boards that ship one: every Goke split build (and the GCC rows, which build gk7205v200) stopped there. It now reads the size as a bootloader does, from firmware.bin's own uImage header -- 64 bytes, then the data size at byte 12. Checked locally: a full gk7205v200_lite build (uImage 1879KB/2048KB read by the bootloader, both packages), hi3516cv6xx_lite (2021KB/2048KB) and hi3519dv500_ultimate (5630KB/6144KB) repacks; at 0x100000 the cv6xx one still stops, "size exceeded by: 1021261 bytes". Closes #2460.
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 step #2240 took for the Goke V200 and hi3516ev200 families, for hi3519dv500. A kernel that measures DRAM itself (OpenIPC/linux, hisi_mem; the hisilicon-hi3519dv500 branch follows) publishes its layout in /sys/module/hisi_mem/parameters -- dram, osmem, allocator, mmz -- and load_hisilicon now loads open_mmz with exactly that, under any bootloader, without reading or writing the environment.
That matters on hi3519dv500, whose U-Boot passes mem=512M and no totalmem: load_hisilicon took the 64M default, found the OS share over it and exited before loading a single module.
On a kernel without hisi_mem the zone still comes from totalmem/osmem and the command line, as before, minus the first-boot fw_setenv of mmz_allocator, which nothing on this part reads back. set_allocator, the user's override (ot|cma|auto|mmz), is the hi3516ev200 one with the carve-out named "ot" as the V5 SDK names it.
From review: set_allocator takes the OS share in whole MiB only (a bare "48" became mem=48, 48 bytes, and an unbootable camera), within what the kernel accepts, defaulting to the share the camera runs with; and an older kernel's two-cell (arm64) memory node is read. Fixed in the hi3516ev200 copy too.
hi3516cv6xx is left out: its lite rootfs is exactly full (5120K of 5120K) and the same change took it to 5124K. It comes with the move to the split NOR package, which holds the rootfs to the chip rather than a fixed slot.
test_load_hisilicon_layout.sh runs load_hisilicon and set_allocator for hi3516ev200 and hi3519dv500 under busybox sh and awk.
Tested in qemu-hisilicon with a hi3519dv500 kernel that publishes hisi_mem, at 512M/1G/2G (cma 376M/516M/1540M): open_mmz loaded with the published zone, login. Not run on hardware: no hi3519dv500 board in the lab.