Repository navigation
hi3516cv6xx: room to run and to update on 64 MB -- no vendor libraries, 128 KiB blocks, sysupgrade into the media zone - #2734
Merged
Merged
Conversation
…tically majestic for the gen 5 SDK now links the vendor libraries from their static archives and keeps only the code it reaches; nothing else in the image links any of them (the sensor drivers declare only libc and take the ISP/AE/AWB callbacks and securec from majestic). The 44 shared objects, 3.7 MB before compression, no longer ship, and protobuf-c, which both variants carried only because the old majestic named it, goes too.
1 MiB blocks (#2447) saved ~430 KiB when the rootfs had to fit a fixed 5120 KiB slot; the split image (#2638) has none. The kernel holds its squashfs caches in whole blocks for as long as root is mounted: 4.2 MiB of unreclaimable slab at 1 MiB on a 64 MiB hi3516cv608 (1040 kmalloc-4k pages from squashfs_cache_init), ~0.6 MiB at 128 KiB.
On a HiSilicon part whose media zone hisi_mem carves out of the OS's
sight ("ot"), the zone sits idle once majestic stops and is far larger
than an image, while the OS has 26-30 MB on a 64 MB board. The image is
now unpacked there: phram maps the zone's free part as an MTD, jffs2
makes it a filesystem, and every step after the unpack -- checksums, the
rootfs peek, the write -- reads files from it as it would from /tmp.
It is the first choice where possible, not a fallback: passing the RAM
check is not the end of what a run needs. The rootfs peek mounts the new
image, and its squashfs caches come out of the same RAM -- on a
hi3516cv608 with 36 MB for the OS, a run to a 1 MiB-block image passed
the check and then thrashed at that mount until power was cut.
- The start of the zone, where the kernel modules keep a few hundred KB,
is left alone, and nothing is mapped unless every block they hold ends
below the mapping: the zone's allocator does not know about it. A
SIGKILLed majestic leaves its buffers there, and the run then declines
the zone and unpacks to /tmp as before.
- The stage is exported across the PID 1 hand-off and read only by it.
- RAM-backed MTDs are left out of the flash geometry.
- Both refusal paths unmap it before majestic is restarted.
- CONFIG_MTD_PHRAM=m on hi3516cv6xx.
Measured on a hi3516cv608 + SP2308: from the image that thrashed, the
same upgrade staged 24 MB of the zone, flashed and rebooted with the
settings kept. On a lite image at 32 MB for the OS with 1 MiB blocks the
run was OOM-killed in its preliminaries before it reached the stage, so
it needs the RAM the rest of this change frees.
widgetii
requested review from
cronyx,
flyrouter and
viktorxda
as code owners
October 30, 2026 19:46
PR Summary by QodoMake hi3516cv6xx lite runnable and upgradable on 64 MB boards
AI Description
Diagram
High-Level Assessment
Files changed (5)
|
Code Review by Qodo
1.
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
- Stage in the media zone only when /proc/umap/media-mem reports its totals, so a format it cannot parse never maps over live buffers. - Refuse to stage, or to unload, a phram that was loaded before us. - Keep stage_dir across the hand-off only while its jffs2 is mounted. - Check room for a local archive in the stage directory it unpacks into.
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
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.
Problem
On a 64 MB hi3516cv6xx (hi3516cv608 / cv610) the lite image leaves Linux too little memory to run, let alone update itself (OpenIPC/majestic#355).
What
Three commits:
ot). phram maps the zone's free part, and jffs2 on it is a filesystem that costs the OS nothing. Every later step reads files from it as from /tmp, and it is the first choice where available.CONFIG_MTD_PHRAM=mon hi3516cv6xx. sysupgrade 1.0.81.Hardware tested on
hi3516cv608 + SP2308, 64 MB DRAM, 16 MB NOR, with the lite image from this branch. It ran on the default layout: 32 MB for the OS, U-Boot env untouched.
Not booted: ultimate. It shares commit 1 (the libraries and protobuf-c), but this board ran only the lite image.
Evidence
Image size (
make BOARD=hi3516cv6xx_lite):Memory with the streamer running, same board, same 32 MB layout:
On master lite the streamer was OOM-killed in normal running:
On this branch the streamer starts with no vendor library on disk or mapped. The sensor comes up through the callbacks it exports, and a snapshot returns 696855 bytes:
Before, the same upgrade from a stock lite image:
After, the image upgrading itself (
sysupgrade --url=<same image> -k -r, serial console):After the reboot the board was still claimed, SSH key login worked, and
sysupgrade --historyrecorded the upgrade.Checks run:
bash .github/scripts/test_sysupgrade.sh: all checks pass.STRICT=1 test_shell_parse.sh: clean.STRICT=1 test_strip_shell_comments.sh: clean.ci-matrix.py --self-test: ok.Scope
general/package/all-patches/linux/(those go to OpenIPC/linux)general/overlay/or in a sharedload_<vendor>script hardcodes a value specific to my boardLD_PRELOAD, and no binaries that cannot be rebuilt from source