Repository navigation
hi3516cv6xx, hi3519dv500: the split NOR image, as on the gk7205v200 family - #2638
Conversation
…amily 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.
PR Summary by QodoUnify HiSilicon and Goke split NOR firmware builds and upgrades
AI Description
Diagram
High-Level Assessment
Files changed (25)
|
Code Review by Qodo
1.
|
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.
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".
|
The Goke split builds and GCC rows failed in the new kernel-read check: it stat'ed images/uImage, which the fixed-slot repack had already renamed to uImage.. Fixed in 27da5cd: it now reads the size from firmware.bin's uImage header, as a bootloader does. A full gk7205v200_lite build passes locally, as do the cv6xx and dv500 repacks. |
#156) hi3516cv608/cv610/cv613 and hi3519dv500/hi3516dv500 move to the split NOR image the gk7205v200 family has: one firmware.bin, a uImage and the squashfs, which the kernel divides at boot. Nothing about them is a case in the install path; what differs is data in defib.firmware: - FIRMWARE_PACKAGE_BOARD: the package a chip installs, where it is not its own -- one hi3516cv6xx build for cv608/cv610/cv613, the hi3519dv500 build for hi3516dv500. NOR_SPLIT_SOCS and split_boards() are keyed by it. - NOR_BOOT_AREAS: (boot, env) where a board's differs from 256k/64k. hi3519dv500's signed boot image is 383 KiB, so its board has 512k boot and 256k env, and the firmware from 0xc0000. install pads the boot image to the board's boot partition (it refused that image before: "does not fit the boot partition"), erases its env, and writes firmware.bin where the area ends. Behind a non-standard area there are no fixed slots, so a fixed-slot package is refused by name. - CV6XX_BOOT_VARIANTS is BOOT_IMAGE_VARIANTS: SoCs whose U-Boot is a signed composite boot image, boot-<chip>[-<variant>]-nor.bin. The boot images that scan the split layout on these parts are published from OpenIPC/u-boot (#32, #35), and OpenIPC/firmware#2638 publishes the split packages for them. Tests: a dv500 install over a 16 MiB fake U-Boot (boot image padded to 512K, firmware.bin at 0xc0000, erase to the chip end), a cv610 install of the hi3516cv6xx package at 0x50000, the fixed-slot refusal, the data. Emptying NOR_BOOT_AREAS fails three of them. Not run against hardware or QEMU: qemu-hisilicon does not emulate the CV6xx boot-ROM download.
… layout (#486) Lists hi3516cv610, hi3516cv608 and hi3519dv500 with wizard instructions and on-demand full images, on the split NOR layout their firmware moved to (OpenIPC/firmware#2638, OpenIPC/u-boot#32/#35, OpenIPC/linux#101-#109). Differences are catalogue data; no SoC-name branches in code, and every existing SoC's wizard document is byte-identical. **Catalogue** - One entry per published signed boot image, named like the firmware's full images: `hi3516cv610-ddr2-64m` (10b), `hi3516cv610-ddr3-128m` (20s), `hi3516cv610-ddr3-512m` (00s), `hi3516cv608`, `hi3519dv500-dmeb`, `hi3519dv500-dmebpro`. No new wizard menu or URL parameter. - New optional fields: `nor_firmware_offset` (default 0x50000; dv500 0xc0000: 512K boot + 256K env), `nor_kernel_read` (default 0x200000; dv500 0x600000: what bootloaders in the field read to boot), `nor_split_only` (no fixed-slot build: install, link and assemble the split package whatever FIT-era plain package the index still lists). **Wizard**: the U-Boot step blanks/erases/writes up to the SoC's firmware offset (dv500's 0x5FC00-class boot image no longer overruns a 0x50000 erase); firmware.bin goes there and the rest of the chip is erased. Split-only `-split.tgz` editions count as published. **Full images**: split mode for split-only editions -- boot image at 0 (bounded by the offset), firmware.bin at the offset (bounded by the chip less 64K), the rest 0xFF; a uImage longer than `nor_kernel_read` is refused. `layoutVersion` 3. Goke (plain and split) keeps fixed-slot images. **Explorer/wizard menu**: the boot-area constant and the "Ultimate only" note corrected (cv6xx has lite and ultimate; dv500 ultimate). **Tests**: `service/run.sh test` passes (new `TestSplitOnlySoCs`, `TestSplitImages`, `TestSplitImageOnlyWhenSplitOnly`, `TestSplitOnlyIgnoresAStalePlainPackage`); `bin/conformance` passes; frontend lint/typecheck pass, `npm test` and the Astro build pass under Node 24. Goldens, testdata, sitemap and `firmware-segments.tsv` regenerated. **For a maintainer to confirm** - Per-board catalogue entries rather than a variant menu. - 20g/00g left out: same DDR tables as 20s/00s, as image.yml assembles. - Status `mvp` for cv6xx (a contributor runs a cv610 on hardware, #2460), `wip` for dv500 (QEMU only). - `load_address` 0x42000000 for all six. **Not verified**: against the production index -- the cv6xx/dv500 `-split` packages appear with the next firmware nightly; the fixture's `-split` entries are the old plain ones renamed. Validate on dev.openipc.org before production once they are published.
…ut too (#610) The page was the GK7205V200 family's. Hi3516CV610, Hi3516CV608 and Hi3519DV500 now run the same layout (OpenIPC/firmware#2638), so it says what differs between them, which is data: - a table of SoC, boot area, firmware offset, bootloader and packages: Hi3519DV500 has 512K boot + 256K env, firmware from 0xc0000; - the signed boot images published once per board, and which DDR each is; - the split-only packages (one hi3516cv6xx build, one hi3519dv500), and that sysupgrade goes straight to them; - the kernel limit the bootloaders impose (2 MiB, 6 MiB on Hi3519DV500); - openipc.org's per-board pages, defib and the full images; - the U-Boot commands with dv500's offsets beside the 0x50000 ones. README and sysupgrade.md name the new SoCs where they point here. From review: the Hi3519DV500 boot-image commands with a 0x80000 erase, plain words for the signed image, and the shared hi3516cv6xx package named in sysupgrade.md.
…ll there is OpenIPC/firmware#2638 moved hi3516cv6xx to the split NOR image, and the FIT-era openipc.hi3516cv6xx-nor-ultimate.tgz is gone from latest, so the hi3516cv610 boot job could not download anything ("gzip: stdin: not in gzip format"). It now takes the -split package from latest, else the plain one, else the newest nightly-* that carries either, and splits whichever it got: a split firmware.bin is a legacy uImage (the zImage with its DTB appended, so no -dtb) and the SquashFS at the next 64 KiB; a FIT as before. Checked locally: the step, run from this file, fell back to a nightly's FIT package and extracted kernel, dtb and rootfs; the split uImage from a hi3516cv6xx build boots under the job's QEMU command, without -dtb, to "openipc-hi3516cv6xx login:".
… a card or stick can be tested (#165) * hisilicon: SD and xHCI on hi3519dv500 / hi3516dv500, so recovery from a card or stick can be tested Both machines get the two SDIO controllers from the vendor dtsi (the card slot @0x10030000, SPI 51, first so -drive if=sd,index=0 is the slot; SDIO1 @0x10040000, SPI 52) and the DWC3's xHCI @0x10320000, SPI 60. The eMMC controller @0x10020000 stays out: NOR boards have none. The DWC3 globals, USB2 PHY, USB3 misc and OTP (USB trim and vendor id) are RAM-backed register stubs, enough for the vendor PHY init in U-Boot to run through. An erased flash holding only the boot image, a FAT image with firmware.bin.hi3519dv500 on -drive if=sd or on -device usb-storage: U-Boot finds it ("bsp-sdhci: 0 (SD)", "1 Storage Device(s) found"), writes it at 0xc0000, and the kernel boots the split NOR layout to userspace. Linux's dwc3 does not recognise the stub ("not a DesignWare USB3 DRD Core"); the kernel side of USB is not modelled. * ci: boot cv610 from the split package, or the FIT one where that is all there is OpenIPC/firmware#2638 moved hi3516cv6xx to the split NOR image, and the FIT-era openipc.hi3516cv6xx-nor-ultimate.tgz is gone from latest, so the hi3516cv610 boot job could not download anything ("gzip: stdin: not in gzip format"). It now takes the -split package from latest, else the plain one, else the newest nightly-* that carries either, and splits whichever it got: a split firmware.bin is a legacy uImage (the zImage with its DTB appended, so no -dtb) and the SquashFS at the next 64 KiB; a FIT as before. Checked locally: the step, run from this file, fell back to a nightly's FIT package and extracted kernel, dtb and rootfs; the split uImage from a hi3516cv6xx build boots under the job's QEMU command, without -dtb, to "openipc-hi3516cv6xx login:".
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.
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.
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).
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.
Closes #2460.