hi3519v101, gk7202v300, gk7205v300: back under the squashfs cap - #2433
Merged
Merged
Conversation
hi3519v101_lite is 16KB over its 5120KB squashfs cap on master (nightly 35129237971). Nothing in this repository grew to do it -- the board was at 5112KB with an 8KB headroom warning in the previous green nightly, and the unpinned majestic/majestic-webui refs moved it the rest of the way. #2420 has the fleet-wide analysis. This removes what the board ships but cannot load. The legacy gadget drivers g_ether, g_mass_storage and g_serial were the only things selecting libcomposite, u_ether, u_serial and the f_acm/f_serial/f_obex/f_ecm/f_subset/ f_rndis/f_mass_storage functions, and nothing on the image loads any of them: usb-dual-role is the tree's sole gadget consumer, no defconfig selects it, and since #2421 it carries its own kernel symbols, so enabling it on a board brings libcomposite and configfs back. USB_CONFIGFS was already off here, so the gadget could not even be composed the modern way. mdev.conf has no $MODALIAS rule and S40network dispatches only on the wlandev U-Boot variable, so a module is loadable if and only if a script names it. None names these. USB_GADGET stays =y and USB_HISI_UDC stays: neither costs squashfs and the vendor PHY plumbing hangs off them. Only the functions go. Left alone, having checked: SCSI is live here, unlike #2410's hi3518ev300 -- USB_STORAGE=y and USB_EHCI_HCD=y give it a real transport. R8188EU stays, per the #2404 determination recorded in this same file: it is the only symbol selecting WIRELESS_EXT on this board, and the out-of-tree drivers /etc/wireless/usb modprobes need that ioctl ABI. Refs #2420
gk7202v300_lite is 16KB over its 5120KB squashfs cap on master (nightly 35129237971). It finished the 2026-09-14 nightly at exactly 5120/5120 and #2421 bought it 32KB; upstream majestic/majestic-webui drift has since taken 48KB of that back. #2420 called this out as the largest single win left on the board. The in-tree staging r8188eu driver was never reachable. /etc/wireless/usb's profiles modprobe '8188eu', the out-of-tree rtl8188eus-openipc module, which neither gk7202v300 defconfig selects; nothing anywhere modprobes 'r8188eu'; mdev.conf has no hotplug rule and S40network dispatches only on the wlandev U-Boot variable. 431,588 B of .ko with no way to load it. No firmware blob goes with it here -- unlike #2410's hi3518ev300, this board never selected LINUX_FIRMWARE_OPENIPC_RTL_8188EU. MT7601U stays as the SoC's one in-tree USB Wi-Fi stack, and the ultimate keeps out-of-tree rtl8188fu. WIRELESS_EXT goes with it, R8188EU having been its only selector here. Safe by the same four checks as #2410: wlan0 runs wpa_supplicant -D nl80211,wext with nl80211 first; the WebUI scans via wpa_cli and reaches iwlist only behind a `command -v` guard; rtl8188fu is compiled with -DCONFIG_IOCTL_CFG80211 and registers a wiphy, verified in the driver's own Makefile; and iwconfig/iwlist/ iwpriv already did nothing for mt7601u because CFG80211_WEXT is off. This is the opposite answer to #2404 on hi3519v101, where out-of-tree drivers did need the wext ABI -- both determinations are now written into their board configs. Refs #2420
gk7205v300_lite was 4KB over its cap on master (nightly 35129237971). The ipctool trim ahead of this brings it back to exactly 5120/5120 -- inside the cap, but at zero headroom, which is where it sat before #2421 and where the next upstream majestic bump puts it back over. Daily growth has been 12-44KB; passing by 0KB is not passing for long. The gadget lever is already spent here (#2421), and unlike gk7202v300 this board has no staging r8188eu to drop. What is left is the build-in trade from #2397: the same 17 crypto symbols move from =m to =y, off the rootfs and into the kernel partition, which has 238KB free. Nothing chooses to load these. The kernel crypto API resolves them through its own request_module(), which is why #2397 built them in rather than deleting them -- deleting would break wireguard, mac80211's CCMP/GCMP and dropbear's kernel-side AEAD. Built in, every consumer keeps working and the .ko stop occupying flash. The cost is a constant: #2397 measured +12,720 B of uImage for exactly this set on hi3518ev300, and #2420 reproduced it to the byte on gk7205v300 while surveying the levers. 12KB against 238KB of kernel headroom. Not taken here: #2420's variant D, which also builds in cfg80211/mac80211/ mt7601u for a much larger rootfs win. It leaves only 39KB of kernel headroom and makes every camera carry ~730KB of Wi-Fi stack text in RAM whether a dongle is ever plugged in or not. That is the trap the issue names, and the reason #2397 built in only the crypto helpers. Refs #2420
widgetii
requested review from
cronyx,
flyrouter and
viktorxda
as code owners
September 16, 2026 19:49
PR Summary by QodoRestore hi3519v101 and GK720x images below squashfs cap
AI Description
Diagram
High-Level Assessment
Files changed (3)
|
Code Review by Qodo
1. Camera changes lack hardware proof
|
This was referenced Sep 17, 2026
Merged
openipc-ai
added a commit
that referenced
this pull request
Sep 18, 2026
Both boards were over the 5120KB squashfs cap on master at 839b990, and each needed a different lever. hi3516ev300 still shipped scsi_mod, scsi_transport_fc and sd_mod -- 276KB of modules -- while CONFIG_USB_STORAGE, CONFIG_ATA, CONFIG_ISCSI_TCP and CONFIG_LIBFC were all unset. With no transport of any kind sd_mod can never bind a device, and scsi_transport_fc is Fibre Channel on an IP camera; storage on these boards is MMC, which is untouched. Nothing in general/overlay/ or any package's files/ names them. Same dead stack #2376 removed from the four Goke boards. This matters because #2420 recorded hi3516ev300_lite as the hardest board to fix -- only 43KB of kernel headroom, so it cannot pay for the build-in trade used elsewhere. It did not have to: the crypto shape was measured on it too and came out at 5104KB rootfs but 2018KB uImage, tripping the headroom warning on both axes, where dropping SCSI costs no kernel bytes at all. gk7205v300 is genuinely out of free levers -- #2376 took its SCSI stack and built FAT in, #2421 stripped the modules it cannot load, #2433 built its crypto helpers in, and the config is down to 13 modules with every one live. So it takes the cheaper half of the only lever left. #2420's table shows cfg80211 + mac80211 + mt7601u built in saves 272KB of rootfs but costs 198KB of uImage, and calls that a trap: it trades "one commit from red on rootfs" for "one commit from red on uImage". Only cfg80211 moves; mac80211 and mt7601u stay modules. The cost is worth stating -- cfg80211 is now permanently resident, so every camera pays ~278KB of RAM for the wireless core whether a dongle is ever plugged in or not. The load path survives being built in: modules.builtin now lists cfg80211, which busybox modprobe consults, and mac80211.ko's modules.dep line no longer names it. Measured in CI: hi3516ev300_lite rootfs 5124 -> 5044KB uImage 2005 -> 2005KB gk7205v300_lite rootfs 5124 -> 5036KB uImage 1823 -> 1885KB hi3516ev300_ultimate rootfs 8124 -> 8044KB gk7205v300_ultimate rootfs 6688 -> 6600KB Neither board prints a headroom warning any more. Not run on a camera: the one hi3516ev300 in the lab is unclaimed and its login shell is openipc-claim, the other is down with no bootlimit/altbootcmd or serial, and there is no gk7205v300. Stated plainly in the PR with the Scope box unticked.
This was referenced Sep 18, 2026
openipc-ai
added a commit
that referenced
this pull request
Sep 18, 2026
The 2026-09-18 master matrix (run 35375141337, at 49908b5) failed on three boards, each at 5124KB against the 5120KB squashfs cap -- over by exactly 4KB. All three were reproduced locally from a clean worktree at that commit before anything here was changed, and the cause is the same fleet-wide drift in the unpinned majestic and majestic-webui refs that #2404, #2410, #2421, #2433, #2437 and #2440 have each answered on other boards. #2437 landed one day ago and left these two Goke boards 8KB of headroom while saying in as many words that the drift would take them again; it did. hi3516cv200 shipped two Realtek drivers waiting on firmware the image does not carry. rtl8192cu asks for rtlwifi/rtl8192cufw*.bin, and rtl8xxxu -- with RTL8XXXU_UNTESTED off, so RTL8723AU only -- asks for rtlwifi/rtl8723aufw*.bin. The only Wi-Fi blobs this board installs are mediatek/mt7601u.bin and rtlwifi/rtl8188eufw.bin, so neither could finish probing, and nothing loads them either: /etc/wireless/usb, dispatched by S40network from the wlandev U-Boot variable, is the one entry point and names mt7601u and 8188eu. That was 350KB of .ko (rtl8xxxu 104KB, rtl8192cu 90KB, rtlwifi 85KB, rtl8192c-common 54KB, rtl_usb 15KB), and RTLWIFI_DEBUG=y is why rtlwifi.ko was as large as it was. Same argument as #2404 made for hi3519v101. R8188EU stays, and the line is drawn where the firmware is: rtl8188eufw.bin is what drivers/staging/rtl8188eu/hal/fw.c requests by name, and R8188EU is the only symbol on this board selecting WIRELESS_EXT and WEXT_PRIV, which the out-of-tree drivers a camera may add still need. This is #2410 in reverse -- there the same driver went, because that board had no wext consumer left. gk7205v200 and gk7605v100 are out of free levers: #2376 took their SCSI stack, #2421 stripped the modules they cannot load, #2437 built their crypto helpers in, and every module left is named by a script or dependency-loaded by one that is. So they take the cheaper half of the one lever #2420 found remaining, the same half #2440 gave gk7205v300. Only cfg80211 moves; mac80211 and mt7601u stay modules, because moving those too would trade "one commit from red on rootfs" for the same on uImage. The cost is worth stating: cfg80211 is now permanently resident, so every camera pays for the wireless core whether a dongle is ever plugged in or not. The load path survives being built in -- modules.builtin now lists kernel/net/wireless/cfg80211.ko, which busybox modprobe consults, and mac80211.ko's modules.dep line no longer names it. Measured locally, clean builds of both the before and the after -- an incremental rebuild keeps the old .ko in target/ and reports a nonsensical saving, which is the trap #2437 documented: hi3516cv200_lite rootfs 5124 -> 5012KB uImage 1656 -> 1657KB gk7205v200_lite rootfs 5124 -> 5044KB uImage 1821 -> 1876KB gk7605v100_lite rootfs 5124 -> 5044KB uImage 1799 -> 1855KB None of the three prints a headroom warning any more.
7 tasks
johnchia
pushed a commit
to johnchia/firmware
that referenced
this pull request
Sep 23, 2026
Both boards were over the 5120KB squashfs cap on master at 839b990, and each needed a different lever. hi3516ev300 still shipped scsi_mod, scsi_transport_fc and sd_mod -- 276KB of modules -- while CONFIG_USB_STORAGE, CONFIG_ATA, CONFIG_ISCSI_TCP and CONFIG_LIBFC were all unset. With no transport of any kind sd_mod can never bind a device, and scsi_transport_fc is Fibre Channel on an IP camera; storage on these boards is MMC, which is untouched. Nothing in general/overlay/ or any package's files/ names them. Same dead stack OpenIPC#2376 removed from the four Goke boards. This matters because OpenIPC#2420 recorded hi3516ev300_lite as the hardest board to fix -- only 43KB of kernel headroom, so it cannot pay for the build-in trade used elsewhere. It did not have to: the crypto shape was measured on it too and came out at 5104KB rootfs but 2018KB uImage, tripping the headroom warning on both axes, where dropping SCSI costs no kernel bytes at all. gk7205v300 is genuinely out of free levers -- OpenIPC#2376 took its SCSI stack and built FAT in, OpenIPC#2421 stripped the modules it cannot load, OpenIPC#2433 built its crypto helpers in, and the config is down to 13 modules with every one live. So it takes the cheaper half of the only lever left. OpenIPC#2420's table shows cfg80211 + mac80211 + mt7601u built in saves 272KB of rootfs but costs 198KB of uImage, and calls that a trap: it trades "one commit from red on rootfs" for "one commit from red on uImage". Only cfg80211 moves; mac80211 and mt7601u stay modules. The cost is worth stating -- cfg80211 is now permanently resident, so every camera pays ~278KB of RAM for the wireless core whether a dongle is ever plugged in or not. The load path survives being built in: modules.builtin now lists cfg80211, which busybox modprobe consults, and mac80211.ko's modules.dep line no longer names it. Measured in CI: hi3516ev300_lite rootfs 5124 -> 5044KB uImage 2005 -> 2005KB gk7205v300_lite rootfs 5124 -> 5036KB uImage 1823 -> 1885KB hi3516ev300_ultimate rootfs 8124 -> 8044KB gk7205v300_ultimate rootfs 6688 -> 6600KB Neither board prints a headroom warning any more. Not run on a camera: the one hi3516ev300 in the lab is unclaimed and its login shell is openipc-claim, the other is down with no bootlimit/altbootcmd or serial, and there is no gk7205v300. Stated plainly in the PR with the Scope box unticked. (cherry picked from commit 947a366)
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.
Problem
Master is red. The 2026-09-16 nightly (run 35129237971) failed on three boards, all size-cap overflow on the 5120KB squashfs of an 8MB NOR layout:
Nothing in this repository grew to do it. Master moved by exactly one commit since the last green nightly (560dd17, sysupgrade) — I measured its contribution at +660 bytes compressed (66,947 → 78,755 B raw; 8,056 → 8,716 B after
strip-shell-comments.awkandxz -9), not the ~24KB needed to explain this. Every uImage is unchanged to the KB. The growth is uniform across three unrelated SoC families:That is the signature #2420 documented: the unpinned
majesticandmajestic-webuimoving refs. Both family tarballs carryLast-Modified: Wed, 16 Sep 2026 17:34— published two minutes after the nightly started at 17:36:29, so the failing jobs fetched the new binaries. This is the fifth size-cap red in six days (#2397, #2404, #2410, #2421 preceded it); each per-board diet has been consumed within 48 hours.This spends three levers #2420 had already measured and left on the table.
What each commit does
hi3519v101— drop the USB gadget stack nothing composes. The legacyg_ether/g_mass_storage/g_serialdrivers were the only things selecting libcomposite,u_ether,u_serialand the sevenf_*functions.USB_CONFIGFSwas already off, so the gadget could not be composed the modern way either.usb-dual-roleis the tree's only gadget consumer, no defconfig selects it, and since #2421 it carries its own kernel symbols, so enabling it on a board brings libcomposite and configfs back.mdev.confhas no$MODALIASrule andS40networkdispatches only on thewlandevU-Boot variable, so a module is loadable if and only if a script names it — and none names these.Left alone, having checked: SCSI is live here, unlike #2410's hi3518ev300 —
USB_STORAGE=yandUSB_EHCI_HCD=ygive it a real transport.R8188EUstays, per the #2404 determination already recorded in that file: it is the board's onlyWIRELESS_EXTselector and the out-of-tree drivers/etc/wireless/usbmodprobes need that ioctl ABI.USB_GADGETand the HiSilicon UDC stay — neither costs squashfs.gk7202v300— drop the stagingr8188eunothing can load. 431,588 B of.kowith no way to load it:/etc/wireless/usbonly ever modprobes8188eu, the out-of-treertl8188eus-openipcmodule, which neither gk7202v300 defconfig selects. No firmware blob goes with it here — unlike #2410's board, this one never selectedLINUX_FIRMWARE_OPENIPC_RTL_8188EU.MT7601Ustays as the SoC's one in-tree USB Wi-Fi stack.WIRELESS_EXTgoes with it,R8188EUhaving been its only selector. Safe by the same four checks as #2410, the fourth verified in the driver source rather than assumed:rtl8188fu(which the ultimate ships) sets-DCONFIG_IOCTL_CFG80211unconditionally in its own Makefile, so it registers a wiphy. wpa_supplicant runs-D nl80211,wextwith nl80211 first; the WebUI scans viawpa_cliand reachesiwlistonly behind acommand -vguard; andiwconfig/iwlist/iwprivalready did nothing for mt7601u becauseCFG80211_WEXTis off. hi3518ev300 has shipped exactly this shape since #2410 — includingBR2_PACKAGE_WIRELESS_TOOLS=yon both variants — and builds green.This is the opposite answer to #2404 on hi3519v101, where out-of-tree drivers did need wext. Both determinations are now written into their board configs so the next person does not have to re-derive either.
gk7205v300— build the crypto modules into the kernel. This board is the reason for the third commit rather than two. The gadget lever is already spent here (#2421) and it has no stagingr8188euto drop. What is left is #2397's trade: the same 17 crypto symbols move=m→=y, off the rootfs and into a kernel partition with 238KB free.Nothing chooses to load these — the kernel crypto API resolves them through its own
request_module(), which is why #2397 built them in rather than deleting them; deleting would break wireguard, mac80211's CCMP/GCMP and dropbear's kernel-side AEAD. The cost is a known constant: #2397 measured +12,720 B of uImage for exactly this set on hi3518ev300, and #2420 reproduced it to the byte on gk7205v300.Not taken: #2420's variant D, which also builds in
cfg80211/mac80211/mt7601ufor a much larger rootfs win. It leaves 39KB of kernel headroom and makes every camera carry ~730KB of Wi-Fi stack text in RAM whether a dongle is ever plugged in or not.Hardware tested on
None — I have no hi3519v101, gk7202v300 or gk7205v300 camera. This has not run on a board, and I am not ticking a box or pasting output I did not observe.
What it has: a local
make BOARD=<board>for each of the three, from this branch, in isolated worktrees, with the moving-ref tarballs evicted from the dl cache first so the builds fetch the samemajestic(751,758 / 789,565 B) andmajestic-webui(374,800 B) artifacts the failing nightly used. Plus CI's own matrix on this PR. Numbers in the next section.Someone with any of these three cameras confirming it still boots and streams — and on gk7202v300, that an MT7601U dongle still associates — is what this needs before it can be called verified. The
r8188euand gadget removals cannot regress a working dongle in principle, since nothing could load those modules, but principle is not a camera.Evidence
Before — the failing nightly, run 35129237971:
After —
make BOARD=<board>from this branch, all three built to completion (rc=0), productioncompression and image layout (
mksquashfs -b 128K -comp xz), in isolated worktrees with themoving-ref tarballs evicted first so each fetched the same artifacts the failing nightly used:
Both caps, both partitions, every board:
The one kernel cost is gk7205v300's, and it is the expected one: #2397 measured +12,720 B of uImage
for this exact set of 17 symbols on a different SoC, and this lands within ~300 B of it — the third
independent reproduction of that constant. It buys 225KB of remaining kernel headroom.
gk7205v300_lite still trips the 32KB headroom warning at 20KB free, and I am not hiding that.
It is under its cap and it builds, which is what this PR is for, but it is the tightest of the three.
Its gadget lever was spent in #2421 and it has no staging
r8188euto drop, so the crypto trade isthe last cheap one #2420 lists for it. #2432's ipcinfo trim stacks another ~4KB on top once it is
rebased onto this. Beyond that the board needs the structural answer #2420 points at — the two
vendor SDK blobs that are 44% of the image — which is not this PR.
Verified in the built rootfs rather than inferred from the config:
CI's matrix on this PR reproduces all three independently — 11 boards selected, all green:
Every
rootfs.squashfsfigure matches my local build to the KB. One uImage does not: hi3519v101 is1810KB in CI against 1808KB locally. That is not the change — my dl cache held an older
linux/hisilicon-hi3519v101.tar.gz, and CI deletes those every run precisely because the kernelarchive is a moving ref with a constant filename. CI's 1810KB is the number to trust, and it is
1KB below the 1809KB the failing nightly built, so the direction is unaffected. Flagging it
rather than quietly publishing the local figure.
That last line is the #2420 check that these are not dead:
usbnet,cdc_ether,mii,usb_wwanandusb-serial-simpleare dependency-loaded byoption/usbserial/rndis_host, which/etc/wireless/modemdoes modprobe. They are untouched.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 sourceBoxes left unticked deliberately — I am not the one holding these cameras. For the
record of what the diff does contain: it is three board kernel configs and nothing
else, no patch under
all-patches/linux/, no package, no overlay file, no*_SITE/*_VERSIONchange, no binary and noLD_PRELOAD. All three boards are inALL_BOARDS, so CI builds every one of them.Refs #2420