Repository navigation
install: the split NOR layout, and OpenIPC/u-boot for the gk7205v200 family - #154
Merged
Merged
Conversation
…family
gk7202v300, gk7205v200, gk7205v300 and gk7605v100 now boot OpenIPC/u-boot
(openipc-hisilicon), published per flash type as u-boot-<soc>-nor.bin and
-nand.bin; the -universal.bin they used came from the retired
u-boot-gk7205v200 repository. They join PER_FLASH_TYPE_UBOOT, so burn,
install and restore fetch the new build.
That U-Boot works out the NOR layout at every boot -- fixed slots or the
split layout -- and sets mtdparts and the root device itself. Its
environment has no bootcmdnor, so the env stage's `setenv bootcmd
${bootcmdnor}` would have left these cameras without a bootcmd. On these
SoCs the env stage now loads the U-Boot defaults (env default -a) and
carries the ethaddr across, as the NAND UBI layout already does.
Their firmware also ships openipc.<board>-nor-<variant>-split.tgz
(OpenIPC/firmware#2617): one firmware.bin.<board>, a hashed FIT and then
the squashfs at the next 64 KiB, written at 0x50000; the kernel divides
it into kernel, rootfs and rootfs_data at boot. install recognises the
package by its contents:
- the image is checked for that shape and the board it names;
- the rootfs stage writes it at 0x50000 and erases the rest of the chip,
so nothing of the old layout is left for U-Boot's scan or the overlay;
- the kernel and rootfs-data stages have nothing of their own to do;
- the size check is the image end plus one block of overlay against the
detected chip;
- refused: another SoC, NAND, a stock-U-Boot migration, and
--wipe-rootfs-data without the rootfs stage. A plan without the uboot
stage warns that the flashed U-Boot must boot the layout.
Tests: tests/test_install_nor_split.py drives run_install against a
byte-accurate 8 MiB NOR console for the split and fixed-slot packages.
…05v200 family
Found installing the split layout on the lab GK7205V200 and GK7205V300
with the published OpenIPC/u-boot:
- That U-Boot probes the flash at boot and its `sf probe 0` prints nothing
at the prompt, so the size fell back to 8 MiB: right by luck on the 8 MB
board, and a 16 MB board would have been laid out as 8. When the probe
reports no size, a 16-byte `sf read` just below 32, 16 and 8 MiB asks
the chip: `sf read` refuses an offset past the end ("Offset exceeds
device limit"), and the largest that reads is the size.
- Its `sf` has no lock subcommand and answers `sf lock 0` with the usage
table, which carries `sf protect` but no `sf lock`. The console echo of
the command sat above "Usage:" and was taken for a table entry, so the
unlock was a hard failure. Only lines from "Usage:" on count now.
- `env default -a` dropped totalmem, which this U-Boot sets in RAM from
the DRAM it measured. Linux sizes its media memory from the saved value
(set_allocator) and without one assumes 64 MB: the GK7205V300 came up
with a 32 MB gk allocator instead of 96 MB of CMA. The value is read
before the reset and set again after it, like ethaddr.
Verified: defib install of openipc.gk7205v200-nor-lite-split.tgz on the
GK7205V200 (8 MiB) and openipc.gk7205v300-nor-ultimate-split.tgz on the
GK7205V300 (16 MiB, detected; erase 0x50000+0xFB0000). Both boot with the
FIT hashes checked and kernel/rootfs/rootfs_data split as computed; the
V300's first boot picks CMA with a 96 MB zone.
PR Summary by QodoSupport split NOR firmware and per-flash U-Boot on GK7205V200-family SoCs
AI Description
Diagram
High-Level Assessment
Files changed (9)
|
Code Review by Qodo
1.
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
…d mode, erase time From review of the split NOR install: - An image that ends inside the squashfs its superblock declares is refused as truncated; only bytes past the rounded end were refused. - ubi_nand_boards() also accepts the board an aliased chip is published under: gk7201v200 now installs the gk7205v200 NAND U-Boot and must take its rootfs.ubi.gk7205v200. - The NOR size reads go through _cmd_result(allow_failure=True). In download-command mode a refused read came back as a failed command, which _cmd turns into the end of the install; a read that fits is the command's OK status there, "Read: OK" in the shell. - The erase timeout grows with the region, about a second per 64 KiB block with 180 s as the floor: the split layout erases from 0x50000 to the end of the chip, 0x1FB0000 on 32 MiB. The shape test's parameters are bytes, and their generated ids reached PYTEST_CURRENT_TEST, past Windows' 32767-character limit on an environment variable; they carry short ids now.
widgetii
added a commit
to OpenIPC/website
that referenced
this pull request
Oct 17, 2026
…nand.bin
Review of the previous commit: Bootloader("nand") falls back to
uboot_filename, so moving these SoCs to u-boot-<soc>-nor.bin handed that
NOR build to NAND installs and NAND full images.
OpenIPC/u-boot publishes a NAND build for each of them too,
u-boot-<soc>-nand.bin in latest, and that build is the UBI-only layout
(768k boot, 256k env, the rest one UBI device), the same as u-boot-xmedia's.
So the catalogue names it as uboot_nand_filename, which is what moves a
SoC's NAND installs onto that layout; defib (OpenIPC/defib#154) installs
these SoCs on NAND the same way. The retired -universal.bin, and its split
NAND layout, is not offered for them again.
The fixture index gains the four published -nand.bin. boards.json carries
them; the gk7202v300 NAND row of the image reference is dropped, since it
is the split NAND layout this SoC no longer installs (hi3516av100's row
still covers that layout). The documents golden is regenerated.
widgetii
added a commit
to OpenIPC/website
that referenced
this pull request
Oct 17, 2026
…yout (#482) * Wizard: the GK7205V200 family on OpenIPC/u-boot, and the split NOR layout GK7202V300, GK7205V200, GK7205V210, GK7205V300 and GK7605V100 now install OpenIPC/u-boot's u-boot-<soc>-nor.bin (OpenIPC/u-boot#18, #19), published in latest, in place of the -universal.bin of the retired u-boot-gk7205v200 repository. That bootloader scans the NOR layout at boot, so these SoCs take the #477 install: each image written at its offset, no uknor/urnor macros, no sf lock. The same bootloader boots the split NOR layout (OpenIPC/linux#96, OpenIPC/firmware#2617, #2621): one firmware.bin -- a hashed FIT, then the squashfs at the next 64 KiB -- at 0x50000, which the kernel divides into kernel, rootfs and rootfs_data at boot. Their firmware publishes it as openipc.<board>-nor-<edition>-split.tgz beside the fixed-slot package. The catalogue marks these SoCs nor_split; where the -split package is published for the board and edition, the Linux step writes that one image at 0x50000 and erases to the end of the chip in the same guarded line (0x7b0000 on 8 MB, 0xfb0000 on 16 MB), and the page links the -split package. Where it is not, the two-image install stays. The full image and the backup/restore steps are unchanged: the bootloader boots the fixed slots the full image carries. The fixture index gains the four published u-boot-<soc>-nor.bin, so the availability reference stands; boards.json and the documents golden are regenerated for the five SoCs. TestSplitNORInstall covers the split lines, gk7205v210 through its gk7205v200 build, the SD path, and the fall-back when no -split package is published. The split install was verified on the lab GK7205V200 (8 MB) and GK7205V300 (16 MB) with these bootloaders and the 2026-10-17 nightly's images, by the same U-Boot write: boots with the FIT hashes checked and kernel, rootfs and rootfs_data where the image puts them. * Wizard: the GK7205V200 family's NAND bootloader is OpenIPC/u-boot's -nand.bin Review of the previous commit: Bootloader("nand") falls back to uboot_filename, so moving these SoCs to u-boot-<soc>-nor.bin handed that NOR build to NAND installs and NAND full images. OpenIPC/u-boot publishes a NAND build for each of them too, u-boot-<soc>-nand.bin in latest, and that build is the UBI-only layout (768k boot, 256k env, the rest one UBI device), the same as u-boot-xmedia's. So the catalogue names it as uboot_nand_filename, which is what moves a SoC's NAND installs onto that layout; defib (OpenIPC/defib#154) installs these SoCs on NAND the same way. The retired -universal.bin, and its split NAND layout, is not offered for them again. The fixture index gains the four published -nand.bin. boards.json carries them; the gk7202v300 NAND row of the image reference is dropped, since it is the split NAND layout this SoC no longer installs (hi3516av100's row still covers that layout). The documents golden is regenerated.
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.
gk7202v300, gk7205v200, gk7205v300 and gk7605v100 now boot OpenIPC/u-boot (
openipc-hisilicon), published per flash type asu-boot-<soc>-nor.binand-nand.bin. Their firmware also ships the split NOR layout (OpenIPC/firmware#2617, #2621) asopenipc.<board>-nor-<variant>-split.tgz: onefirmware.binwritten at 0x50000, which the kernel divides into kernel, rootfs and rootfs_data at boot (OpenIPC/linux#96).What changes
PER_FLASH_TYPE_UBOOT, soburn,installandrestorefetch-nor.bin/-nand.bin. Before this they fetched the old-universal.binfrom the retired u-boot-gk7205v200 repo.bootcmdnor, so the env stage'ssetenv bootcmd ${bootcmdnor}would have left these cameras without a bootcmd. On these SoCs the env stage now loads the defaults (env default -a) and carriesethaddrandtotalmemacross.totalmemis the DRAM size U-Boot measured. Without the saved value, Linux assumes 64 MB.installrecognises it by its contents.--wipe-rootfs-datawithout the rootfs stage. A plan without the uboot stage gets a warning.sf probe 0prints nothing at the prompt. Before this, the size fell back to 8 MiB, so a 16 MB board would have been laid out as 8 MB. When the probe gives no size, 16-bytesf reads just below 32, 16 and 8 MiB ask the chip:sf readrefuses offsets past the end.sf lock: itssfhas no lock subcommand. The console's echo ofsf lock 0above the usage table was taken for a table entry, which made the unlock a hard failure. Only lines fromUsage:on count now.Tests
tests/test_install_nor_split.pydrivesrun_installagainst a fake NOR console that keeps every byte of an 8 MiB chip. It answerssf probe/sf lockas this U-Boot does and refuses out-of-range reads. It covers the split and fixed-slot packages, the package checks and the refusals.sf lockecho.test_firmware.pyis updated for the new U-Boot names.Verified on hardware
defib installwith the split packages built from OpenIPC/firmware master, and the published U-Boot (g7e52056f):firmware.binwritten and CRC-verified, erased 0x50000+0x7B0000. It boots withVerifying Hash Integrity ... crc32+ sha1+ OK, and the partitions are where expected: kernel 0x50000–0x230000, rootfs from 0x230000, rootfs_data from 0x730000.totalmemfix, the first boot picks the CMA allocator with a 96 MB zone, as before the install.