hi3518ev300: one USB Wi-Fi stack, and drop the SCSI stack nothing can reach - #2410
Merged
Merged
Conversation
… reach hi3518ev300_lite is 4KB over its 5120KB squashfs cap on master, so every pull request in the repository has a red build. The overflow itself is upstream drift -- majestic and majestic-webui are unpinned moving refs, and the two of them grew ~20KB between the 2026-09-11 and 2026-09-13 publishes, which is exactly the 16KB of headroom #2397 had bought. This buys headroom back by removing things the board ships but cannot use. THE IN-TREE 8188EU DRIVER WAS NEVER REACHABLE. /etc/wireless/usb's rtl8188eu-generic profile runs `modprobe 8188eu`; that module name belongs to the out-of-tree rtl8188eus-openipc package, which this board does not select. The in-tree staging module is called r8188eu and no profile modprobes it, there is no USB hotplug modprobe rule in mdev.conf, and S40network only ever dispatches on the `wlandev` U-Boot variable. So 431,588 B of .ko and the 15,262 B rtlwifi/rtl8188eufw.bin blob it requests shipped on every hi3518ev300 image with nothing able to load them. OpenIPC/builder had already worked this out camera-by-camera: both hi3518ev300 device profiles list r8188eu.ko in their per-device excludes, as do five hi3518ev200 ones. Of the two adapters the board carried, MT7601U is the one the tree standardises on -- its firmware is enabled on four times as many defconfigs, and every board carrying the 8188EU blob carries the MT7601U one too. 8188EU keeps a home in OpenIPC/builder, where a profile can select rtl8188eus-openipc and get the module the dispatch script has been naming all along. WIRELESS EXTENSIONS GO WITH IT, deliberately. R8188EU was the only enabled symbol selecting WIRELESS_EXT here, and CFG80211_WEXT cannot stand in -- it selects WEXT_CORE, while net_device.wireless_handlers is #ifdef CONFIG_WIRELESS_EXT. Nothing on these images needs it: - mt7601u is a mac80211 driver, and interfaces.d/wlan0 runs `wpa_supplicant -D nl80211,wext`, which tries nl80211 first; - the WebUI's Wi-Fi scan (cgi-bin/j/network.cgi) uses wpa_cli, with iwlist only as a fallback behind `command -v`; - rtl8188fu-openipc and rtl8189fs-openipc, which hi3518ev300_ultimate selects, are both compiled with -DCONFIG_IOCTL_CFG80211 in their active platform block, so they register a wiphy and keep working over nl80211. Both also guard .private on CONFIG_WEXT_PRIV and wireless_handlers on CONFIG_WIRELESS_EXT, so neither build breaks. What is lost is iwconfig/iwlist/iwpriv, which already did nothing for mt7601u because CFG80211_WEXT is off. This is #2404 in reverse: there R8188EU had to stay on hi3519v101 because out-of-tree drivers needed the wext ABI. SCSI. USB_STORAGE and USB_EHCI_HCD are both off, there is no ATA and no MMC block, and no module in the image depends on scsi_mod or sd_mod -- 184,916 B of .ko with no transport behind it. Same removal as #2399 for hi3518ev200. MEASURED, full clean rebuild of hi3518ev300_lite: before (master de53526) rootfs.squashfs 5,246,976 B [5124KB/5120KB] 4KB OVER after rootfs.squashfs 5,025,792 B [4908KB/5120KB] 212KB free uImage 1,918,672 B [1873KB/2048KB] 175KB free, no kernel cost Verified in the built rootfs: r8188eu.ko, scsi_mod.ko, sd_mod.ko and rtlwifi/rtl8188eufw.bin are gone; mt7601u.ko, mac80211.ko (still its dep), mediatek/mt7601u.bin, wireguard.ko and camhi-motor.ko all still ship. The kernel config is shared by hi3518ev300_lite and _ultimate and by no other board, so this reaches those two and nothing else. NOT TESTED ON A CAMERA -- I have no hi3518ev300. Someone with the board should confirm an MT7601U dongle still associates, and that an 8188FU or 8189FS dongle on the ultimate still comes up now that it goes through nl80211 rather than wext.
widgetii
requested review from
cronyx,
flyrouter and
viktorxda
as code owners
September 13, 2026 10:32
PR Summary by QodoTrim unreachable Wi-Fi and SCSI stacks from hi3518ev300 images
AI Description
Diagram
High-Level Assessment
Files changed (3)
|
Code Review by Qodo
1. Camera Wi-Fi changes lack field proof
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
The board has CONFIG_MMC=y, CONFIG_MMC_BLOCK=y and CONFIG_MMC_SDHCI_HISI=y, and mmc_block is in modules.builtin, so "no MMC block" was simply wrong and would have read as "this SoC has no SD/eMMC support" to the next person. The removal it justifies is unaffected -- MMC_BLOCK serves cards as mmcblk and never goes through the SCSI layer, so SCSI still has no transport behind it. Comment only; kconfig strips comments, so the built artifacts are identical.
widgetii
added a commit
to OpenIPC/builder
that referenced
this pull request
Sep 13, 2026
…and drop excludes firmware now handles (#157) Follow-up to OpenIPC/firmware#2410, which left MT7601U as the only in-tree USB Wi-Fi stack on hi3518ev300. RTL8188EU lands here as a camera profile, splitting the two adapters across the two repositories. hi3518ev300_lite_generic-rtl8188eu builds the driver INTO the kernel rather than shipping it as a module: a profile whose only Wi-Fi is that driver has no reason to carry it as loadable code, and the rootfs is the partition under pressure. The out-of-tree rtl8188eus-openipc cannot make that move -- it is an external kernel-module package, never linked into vmlinux -- so this uses the in-tree staging driver at CONFIG_R8188EU=y through a variant kernel config, the same shape as gk7205v200.generic-otg.config. Built in, the driver also has no modprobe problem: as a module it was unreachable, because /etc/wireless/usb's rtl8188eu-generic profile modprobes '8188eu' while the in-tree module is 'r8188eu'. Linked into the kernel it binds off its own USB device table at boot. CONFIG_R8188EU selects WIRELESS_EXT, so the wext ABI firmware#2410 dropped comes back on this variant only. It requests rtlwifi/rtl8188eufw.bin, so linux-firmware-openipc comes with it. Registered in .github/firmware-drift.json against the firmware blob it derives from. MEASURED in CI, against the module-based version of the same profile: uImage [1873KB/2048KB] -> [1991KB/2048KB] 56KB free rootfs.squashfs [5084KB/5120KB] -> [4728KB/5120KB] 392KB free Also drops excludes entries firmware now handles upstream: r8188eu.ko from xiaomi-mjsxj02hl, and r8188eu.ko + scsi_mod.ko + sd_mod.ko from yuancam-dgk423403. Both cameras build green; both run out-of-tree Realtek drivers over nl80211 and are otherwise unaffected. Not tested on a camera. This changes which 8188EU driver is used -- mainline staging rather than the Realtek vendor fork -- so it wants confirmation that a dongle is detected at boot without a modprobe, associates, and streams.
widgetii
added a commit
that referenced
this pull request
Sep 15, 2026
hi3516ev300_lite failed this PR's matrix at 5124KB against its 5120KB cap.
Not caused by anything here -- this branch touches four goke kernel configs,
a cv500+neo-gated hook in hisilicon-opensdk, and usb-dual-role, none of which
this board uses. It failed because it finished the 2026-09-14 nightly at
exactly 5120/5120KB, zero headroom, and the unpinned majestic/webui refs grew
another 4KB overnight. It was going to go red on the next upstream bump
whatever landed; it happened to be this run.
The board carries the identical dead set the goke boards did, and for the
identical reason: the USB gadget functions exist only for usb-dual-role, which
no defconfig selects and which ci-matrix.py lists in NOT_BUILT, and
br_netfilter and i2c-tiny-usb have no consumer anywhere in the tree. Nothing
modprobes any of these names, mdev.conf has no $MODALIAS rule, and S40network
dispatches only on the `wlandev` U-Boot variable.
USB_GADGET stays =y here too -- USB_DWC3_DUAL_ROLE=y on this board and depends
on it, so turning the subsystem off would take USB host with it. And with
usb-dual-role now carrying its own LINUX_CONFIG_FIXUPS, a board that selects
the package still gets the gadget symbols back.
MEASURED, full clean build of hi3516ev300_lite (make clean, so no stale
per-package module trees):
before [5124KB/5120KB] 4KB OVER (this PR's matrix, run 34927690505)
after [5056KB/5120KB] 64KB free
uImage [2005KB/2048KB] 43KB free, unchanged -- no kernel cost, which
matters here because this board has the second-tightest kernel
partition in the tree and could not have paid for a build-in trade.
Verified in the built rootfs: all ten .ko gone; mac80211, cfg80211, mt7601u,
wireguard and tun all still ship. SCSI is deliberately left alone -- #2410
dropped it from hi3518ev300 after establishing that board had no transport,
and scsi_mod/sd_mod here would need that determination made separately.
The config is shared by hi3516ev300_lite, _ultimate, _glibc and _dev, and none
of the four selects usb-dual-role.
NOT TESTED ON A CAMERA.
Refs #2420
widgetii
added a commit
that referenced
this pull request
Sep 15, 2026
…nnot load Six boards were over or at their squashfs cap. All of them ship kernel modules that no code path on the image can load; this removes those, at no cost to the kernel partition and with nothing dropped that anything uses. gk7205v300_lite 5140 -> 5080KB/5120 (was 20KB over) gk7205v200_lite 5132 -> 5072KB/5120 (was 12KB over) gk7605v100_lite 5124 -> 5068KB/5120 (was 4KB over) gk7202v300_lite 5120 -> 5088KB/5120 (was 0KB free) hi3516ev300_lite 5124 -> 5060KB/5120 (was 4KB over) hi3516av300_neo 8208 -> 6688KB/8192 (was 16KB over) WHY THEY WENT OVER. Nothing in this repository grew to do it. Between the last green nightly (34771958692) and the red one (34874636710), every board carrying majestic-webui grew 12-44KB, and the only three at +0KB are exactly the three that ship neither majestic nor the webui. Both are unpinned moving refs by design. Full analysis, and the levers not spent here, in #2420. THE USB GADGET STACK HAS NO CONSUMER (goke x4, hi3516ev300). libcomposite, configfs, usb_f_acm/ecm/rndis/mass_storage, u_ether and u_serial exist on these images only for usb-dual-role -- selected by zero defconfigs and listed in ci-matrix.py's NOT_BUILT. There is no USB hotplug modprobe either: mdev.conf carries 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. Nothing names these. br_netfilter and i2c-tiny-usb go too -- no consumer anywhere in the tree. USB_GADGET itself stays =y. USB_DWC3_DUAL_ROLE depends on it, so turning the subsystem off would drop the controller out of dual-role and take USB host -- and the Wi-Fi dongle -- with it. Only the functions go. Not touched, having checked: usbnet, cdc_ether, mii, usb_wwan and usb-serial-simple are dependency-loaded by option/usbserial/rndis_host, which /etc/wireless/modem does modprobe; every crypto .ko is loaded by the kernel crypto API's own request_module(), which is why #2397 built those in rather than deleting them; tun is live via vtund-openipc/files/tunnel:24. THE cv500 NEO SHIPPED EVERY VENDOR MODULE TWICE. The neo variants build the 7.x upstream-patches kernel, where buildroot's kernel-module install lands the .ko in updates/ rather than the extra/ that hisilicon-opensdk's finalize hook clears, and INSTALL_TARGET_CMDS then copies the same open_*.ko set into hisilicon/. kmod searches "updates" first, so that is the copy modprobe resolves and depmod indexes; hisilicon/ is unreachable. On hi3516av300_neo that is 45 modules and 5.4MB -- 1520KB of squashfs. Verified against the nightly's own published image: the hisilicon/ names are a pure subset of updates/, modules.dep names updates/ 156 times and hisilicon/ never, and the two copies of a module are the same object differing only in that updates/ is stripped. Scoped to cv500+neo deliberately, because the same duplication has the opposite answer next door: hi3516cv300_neo renames its modules to hi3516cv300_*/hi_* in hisilicon/, names that exist nowhere in updates/ and that its load_hisilicon insmods by filename. The 4.9 boards have no updates/ directory at all. The remaining neo boards are tracked in #2420. usb-dual-role NOW BRINGS ITS OWN KERNEL SYMBOLS, through the same LINUX_CONFIG_FIXUPS mechanism linux-patcher uses, so disabling them per board cannot strand it. The audit behind that is worth recording: usb-mode modprobes exactly configfs, libcomposite and usb_f_uvc -- it never composes ACM, ECM, RNDIS or mass_storage, which are precisely the four functions these boards were shipping -- while USB_CONFIGFS_F_UVC, the one function it does load, was absent from those configs entirely. The previous state could not have worked. Verified by selecting the package on gk7205v300_lite and rebuilding: USB_GADGET, CONFIGFS_FS, USB_CONFIGFS and USB_LIBCOMPOSITE come back. F_UVC does not, because it also needs VIDEO_V4L2 and VIDEO_DEV; the request stays in the fixup and the limit is written into both the .mk and the Config.in help. MEASURED, full clean builds (make clean, so no stale per-package module trees), before and after taken from the same build: gk7205v300_lite 5,263,360 -> 5,201,920 B uImage [1810KB/2048KB] unchanged hi3516ev300_lite [5124KB] -> [5056KB] uImage [2005KB/2048KB] unchanged No kernel cost anywhere, which matters for hi3516ev300 -- it has the second-tightest kernel partition in the tree and could not have paid for a build-in trade. Verified in the built rootfs: the removed .ko are gone and mac80211, cfg80211, mt7601u, wireguard, tun, option, usbserial, rndis_host, usbnet and mii all still ship, with modules.dep still resolving mt7601u -> mac80211 -> cfg80211. SCSI is deliberately left alone on hi3516ev300; #2410 dropped it from hi3518ev300 after establishing that board had no transport, and scsi_mod/sd_mod here need that determination separately. NOT TESTED ON A CAMERA -- I have none of these boards. Someone with a goke camera should confirm an MT7601U dongle still associates and USB host still enumerates; someone with an hi3516av300 neo should confirm it still boots and streams. hi3516av300_neo was not built locally either (it needs the 7.x kernel tree); its evidence is the published image above, and CI builds it. Refs #2420
7 tasks
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.
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
hi3518ev300_liteis 4KB over its 5120KB squashfs cap on master(
de5352647), so the board fails its own build and every open pull request inthe repository carries a red matrix.
The overflow is upstream drift, not a regression here.
majestic(
majestic.$(FAMILY).$(VARIANT).master.tar.bz2) andmajestic-webui(
MAJESTIC_WEBUI_VERSION = dist) are unpinned moving refs, and CI's own headroomannotations show the 16KB that #2397 bought being eaten in 48 hours:
rootfs.squashfs has 12KB left of 5120KBrootfs.squashfs has 4KB left of 5120KBDiffed against the exact tarballs a 09-11 local build used:
majestic.hi3516ev200.lite.master.tar.bz2majestic-webui-dist.tar.gzUnpacked, the
majesticbinary went 1,131,888 → 1,148,216 B and the webui tree943,426 → 978,938 B. The only commits since #2397 that reach this board are
#2401 (overlay shell, sub-KB once comment-stripped and xz'd) and #2400 (the
opensdk bump restructured
kernel/wdtfor cv300/cv500/cv6xx/dv500; thisfamily's entire
open_wdt.kois 9,476 B).So this removes what the board ships but cannot use, rather than chasing the
next publish.
The in-tree 8188EU driver was never reachable
/etc/wireless/usb'srtl8188eu-genericprofile runsmodprobe 8188eu. Thatmodule name belongs to the out-of-tree
rtl8188eus-openipcpackage(
MODULE_NAME = 8188eu), which this board does not select. The in-tree stagingmodule is
r8188eu, no profile modprobes it,mdev.confhas no hotplugmodprobe rule, and
S40networkonly ever dispatches on thewlandevU-Bootvariable. So 431,588 B of
.koplus the 15,262 Brtlwifi/rtl8188eufw.binitrequests shipped on every hi3518ev300 image with nothing able to load either.
OpenIPC/builder had already reached this conclusion camera by camera — seven
device profiles list
r8188eu.koin their per-device excludes (5× hi3518ev200,2× hi3518ev300). This just generalises it.
Of the two adapters the board carried, MT7601U is the one the tree standardises
on: its firmware blob is enabled on four times as many defconfigs, and every
board carrying the 8188EU blob carries the MT7601U one too. 8188EU keeps a home
in OpenIPC/builder, where a profile can select
rtl8188eus-openipcand get themodule the dispatch script has been naming all along. That follow-up is ready
and will go up once this lands.
Wireless extensions go with it, deliberately
R8188EUwas the only enabled symbol here selectingWIRELESS_EXT, andCFG80211_WEXTcannot stand in — it selectsWEXT_CORE, whilenet_device.wireless_handlersis#ifdef CONFIG_WIRELESS_EXT. Checked everyconsumer on these two images before removing it:
mt7601uis a mac80211 driver, andinterfaces.d/wlan0runswpa_supplicant -B -i wlan0 -D nl80211,wext— nl80211 is tried first.cgi-bin/j/network.cgi) useswpa_cli scan/scan_results, withiwlistonly as a fallback behindcommand -v iwlist.rtl8188fu-openipcandrtl8189fs-openipc, whichhi3518ev300_ultimateselects, are both compiled with
-DCONFIG_IOCTL_CFG80211in their activeplatform block (
CONFIG_PLATFORM_ARM_GENERICandCONFIG_PLATFORM_ARM_RK3188respectively), so they register a wiphy and keep working over nl80211. Both
also guard
.privateonCONFIG_WEXT_PRIVandwireless_handlersonCONFIG_WIRELESS_EXT, so neither build breaks.What is lost is
iwconfig/iwlist/iwpriv, which already did nothing formt7601ubecauseCFG80211_WEXTis off. This is #2404 in reverse: thereR8188EUhad to stay on hi3519v101 for exactly this reason.SCSI
USB_STORAGEandUSB_EHCI_HCDare both off, there is no ATA and no MMC block,and no module in the image depends on
scsi_modorsd_mod— 184,916 B of.kowith no transport behind it. Same removal #2399 made for hi3518ev200.Hardware tested on
Not tested on a camera — I do not have a hi3518ev300. Opened ready rather
than as a draft because a draft builds nothing and CI proving the image fits
under the cap is the whole point while master is red for this board; same
reasoning as #2397. Someone with the board please confirm an MT7601U dongle
still associates, and that an 8188FU or 8189FS dongle on the
ultimatestillcomes up now that it goes through nl80211 rather than wext.
What I can evidence is a full local
make clean+ rebuild, plus the settledkernel symbol set.
Evidence
Full clean rebuild of
hi3518ev300_lite(make cleanfirst — per-packagedirectories make an incremental rootfs measurement meaningless).
Before:
After:
221,184 B (216KB) off the rootfs, and no kernel cost — the uImage came down
3KB rather than growing, unlike #2397's build-crypto-in trade which paid +12KB.
212KB of headroom back.
Contents of the rebuilt rootfs:
The board config is hand-maintained, so I checked the edit settles the way it
reads by running the kernel's own kconfig out-of-tree over the before and after
files (
make -C <linux> O=<scratch> ARCH=arm olddefconfig). The settled symboldelta is exactly
R8188EU,88EU_AP_MODE, the fourWEXT_*/WIRELESS_EXTsymbols and the SCSI block — nothing else moved.
hi3518ev300.generic.configis used byhi3518ev300_liteandhi3518ev300_ultimateand by no other defconfig, so this reaches those twoboards. The other six the selector picks are directory-level path matches and
build unchanged:
Checks that need neither a build nor a camera, all passing:
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