hisilicon: five boards back under the squashfs cap - #2459
Merged
Merged
Conversation
hi3516ev200_lite went 4KB over its 5120KB cap on 2026-09-19 with no commit in this tree responsible. majestic is fetched as .master.tar.bz2 and majestic-webui as its "dist" release asset, so both move on their own: the majestic binary was rebuilt a minute before that build (1288676 -> 1297076 bytes) and the webui dist grew 125267 bytes across the day's SD-card work. Re-squashing the last good nightly's rootfs puts those at +5.52KB and +38.41KB compressed. Four more boards were a couple of ordinary commits behind it -- hi3519v101_lite at 0KB left of 5120KB, hi3516ev100_lite at 8KB, hi3516dv200_lite at 20KB, hi3518ev100_lite at 24KB -- and the webui already carries ~22KB more than the build that failed. Each board drops kernel modules that image can never load, the test #2442 used: hi3516ev200 SCSI: USB_STORAGE is off and no HBA is enabled, so scsi_mod, sd_mod and a Fibre Channel transport had nothing to bind to. Shared with the ultimate variant, which has no USB_STORAGE either, so the wireless stack stays -- ultimate ships mediatek/mt7601u.bin and its mt7601u works. hi3516dv200 the same dead SCSI, plus mt7601u/mac80211/cfg80211: this board ships no firmware at all, so mt7601u could never probe, and nothing else here is built on the stack. hi3519v101 mac80211 and cfg80211 have no user in modules.dep; the only Wi-Fi driver is the staging r8188eu, which carries its own stack and its own firmware. hi3516ev100 mac80211 has no user; cfg80211 and ZD1201 stay because ZD1201 is what selects WIRELESS_EXT here. hi3518ev100 rtl8192cu and rtl8192se wait on rtlwifi/rtl8192cufw*.bin and rtl8192sefw.bin, and the only blobs on the image are rtl8188eufw.bin and mt7601u.bin; mac80211 served only them. cfg80211 stays for the out-of-tree mt7601sta. Measured by re-squashing each board's published rootfs with the modules removed (-b 128K -comp xz, which reproduces the published figure to within 4KB): ev200 5124 -> ~5054, dv200 5100 -> ~4792, hi3519v101 5120 -> ~4936, ev100 5112 -> ~4994, hi3518ev100 5096 -> ~4916. Every edit was run through its own kernel's olddefconfig (oldnoconfig on the 3.0.8 hi3516cv100 tree) to confirm the module set changes as intended and nothing is silently turned back on, and that WIRELESS_EXT, WEXT_CORE and WEXT_PRIV survive on hi3519v101 and hi3516ev100 and WEXT_CORE on hi3518ev100 -- the trap #2442 called out for out-of-tree drivers.
openipc-ai
requested review from
cronyx,
flyrouter and
viktorxda
as code owners
September 20, 2026 05:29
PR Summary by QodoPrune unusable HiSilicon modules to restore squashfs headroom
AI Description
Diagram
High-Level Assessment
Files changed (5)
|
Code Review by Qodo
1. Camera behavior changes go untested
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
This was referenced Sep 20, 2026
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
hi3516ev200_litewent 4KB over its 5120KB squashfs cap on master(run 35458506325), failing the build and taking the CI Gate with it. No commit
in this tree is responsible.
majesticis fetched asmajestic.<family>.<variant>.master.tar.bz2andmajestic-webuias itsdistrelease asset, so both move without a commithere. The majestic binary was rebuilt at 17:33 GMT, a minute before that build
started (1288676 -> 1297076 bytes), and the webui
distgrew 125267 bytesacross that day's SD-card work (
cgi-bin/j/sdcard.cgi+47128, a newcgi-bin/wfb.cgi+17709,a/sdcard.js+9587,cgi-bin/j/ptz.cgi+7069,a/sdcard-health.js+5049).Four more boards were a couple of ordinary commits behind it, and CI said so in
the same run:
The webui already carries about 22KB more than the build that failed, so this
is not a one-board problem.
Each board here drops kernel modules that its image can never load — the test
#2442 used, one board at a time:
scsi_mod,sd_mod,scsi_transport_fc)USB_STORAGEis off and no HBA is enabled, so nothing can register a SCSI device.SCSI_LOWLEVEL=yis only the menu gate. Theusb_f_mass_storagegadget answers SCSI itself and does not use this subsystem.mt7601u/mac80211/cfg80211mt7601ucould never getmediatek/mt7601u.bin; nothing else here is built on the stackmac80211,cfg80211modules.depdepends on either; the only Wi-Fi driver is the stagingr8188eu, which carries its own stack and firmwaremac80211cfg80211andZD1201stay —ZD1201is what selectsWIRELESS_EXTheremac80211, rtlwifi familyrtl8192cuwaits onrtlwifi/rtl8192cufw*.binandrtl8192seonrtl8192sefw.bin; the only blobs on the image arertl8188eufw.binandmt7601u.bin.cfg80211stays for the out-of-treemt7601stahi3516ev200.generic.configis shared with the ultimate variant, so only theSCSI change is made there: ultimate ships
mediatek/mt7601u.binand itsmt7601uworks, and it has noUSB_STORAGEeither.Hardware tested on
hi3516ev300_lite — SoC family
hi3516ev200, kernel 4.9.37, the same boarddirectory and the same kernel tree these five configs build from. Lab camera
at 10.216.128.76, IMX335, running
nightly-20260917-1ebaef8.None of the five boards this PR changes could be run, and I will not claim
otherwise: the only lab board for any of them is the
hi3516ev200at10.216.128.45, which is off the network entirely (no ARP entry, 22/80/554 all
closed). What that camera can show is the premise — that the modules this PR
removes are carried and can never bind — because it ships the identical dead
SCSI set from the same kernel, and the identical firmware-less
mt7601u.ko.It is also the board that already had this exact change made to it. #2440
("hi3516ev300, gk7205v300: back under the squashfs cap", merged 2026-09-18)
turned
CONFIG_SCSI_MOD=minto=yand deleted the same SCSI block fromhi3516ev200/hi3516ev300.generic.config, which is the byte-for-byte shape ofthe hi3516ev200 hunk here.
fe99bb87("goke, hi3516ev300, cv500 neo: drop thekernel modules these boards cannot load") is the same class of change again.
The lab camera runs a build from 2026-09-17, one day before #2440, so it is
the before state of a change that has since been in every nightly.
What a maintainer with the actual boards should still confirm: Wi-Fi still
associates on
hi3516ev200_ultimate(shared config, wireless deliberatelyuntouched), and that nobody was relying on USB mass storage on
hi3516ev200/hi3516dv200 or an RTL8192CU/RTL8192SE dongle on hi3518ev100 — the
argument here is that those could not have worked, not that nobody wants them.
No OpenIPC/builder device targets any of the five boards, so no retail image
is affected.
Evidence
On the camera — the three modules this PR drops from hi3516ev200 are shipped
and have never been loaded, and the SCSI bus was never registered at all:
Not one of the three is loaded,
/sys/bus/scsi/devicesdoes not exist so thebus was never registered, there is no
usb-storagemodule to register one, andthere is no
/lib/firmwareformt7601u.koto ask. That is the whole argumentof this PR, on a running camera that streams.
And the same change on that board is already in production — the current
hi3516ev300_litenightly, built after #2440, has nodrivers/scsidirectoryat all:
Sizes measured by re-squashing each board's published nightly rootfs with the
modules removed,
-noappend -b 128K -comp xz— the same options the builduses, which reproduces each published figure to within 4KB:
Before:
After (re-squash of the same rootfs minus the dropped modules):
(*) ev200's base is the last good nightly rootfs with the current majestic
binary and webui dist swapped in — that is, what the next build produces if
nothing changes: 5144.35 KB against a 5120 KB cap, 24 KB over rather than the
4 KB CI caught. It lands at 5074.44, 45 KB under. The other four are their own
published rootfs re-squashed, which reproduces the published figure to within
4 KB, so their saving is measured against what CI reported.
That attribution, same method:
Every edit was run through its own kernel's
olddefconfig(oldnoconfigon the3.0.8 hi3516cv100 tree) to confirm the module set changes as intended and that
nothing is silently turned back on:
Nothing was added in any of the five.
RTL_CARDSon hi3516ev100 is a cascade:it depends on
mac80211, but it was a menu with no driver under it, so nomodule is lost — that rootfs never had
rtlwifi.ko.And the property #2442 called out — that dropping the last driver which
selectsWIRELESS_EXTtakes the wext API away from out-of-tree drivers —holds on all three boards where it applies:
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