kernel: drop the SCSI stack no Goke board can use, and build FAT in, so gk7205v200 lite fits again - #2376
Conversation
…so gk7205v200 lite fits again Tonight's nightly failed on gk7205v300_lite: rootfs.squashfs 5124KB against a 5120KB partition. It is not alone. Every lite image built from this directory is at the cliff -- gk7205v200_lite 5116KB, gk7202v300_lite 5104KB -- while all three carry 266KB of unused kernel partition (uImage 1783KB of 2048KB). The rootfs has been growing about 8-16KB a night with the streamer it ships, so this was going to be tomorrow's failure on the next board. Two things pay for it, both measured from the size report of tonight's gk7205v200_lite build: - The SCSI stack is dead weight. scsi_mod.ko (145KB), sd_mod.ko (36KB) and scsi_transport_fc.ko (53KB) sit in every rootfs of this family, and nothing here can use them: CONFIG_USB_STORAGE is not set in any Goke config, no other SCSI host driver is enabled, and SD cards come in as mmcblk, not sd. A Fibre Channel transport on a camera was never going to find a fabric. Off, the same way #2185 switched f2fs off. - FAT and VFAT move from modules into the kernel. Every SD card mounted on these boards needs them, so they load on every camera with a card anyway; as .ko files they cost 77KB of rootfs, built in they cost the kernel partition roughly a third of that after compression, out of 266KB spare. NLS is already built in, so nothing new is pulled in. Together that is about 310KB of uncompressed rootfs, on the order of 110KB after xz, moved off the partition that is full and partly onto the one that is not. No feature changes hands.
PR Summary by QodoRebalance Goke lite images by removing SCSI and embedding FAT
AI Description
Diagram
High-Level Assessment
Files changed (3)
|
Code Review by Qodo
1. Camera owners get unverified changes
|
…KB from the same wall The first commit left gk7605v100.generic.config alone because that board was not in tonight's failure. The pull request's own CI then built it: rootfs.squashfs 5112KB of 5120KB. Same modules nobody can use, same FAT modules every SD card needs, same 8MB layout, so the same change.
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.
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.
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)
What broke
Tonight's nightly (run 34048925366) failed on
gk7205v300_lite:rootfs.squashfs: [5124KB/5120KB] -- size exceeded by: 4KB. It fit yesterday at 5108KB and the day before at 5100KB. The other lite boards built from this directory are at the same cliff:gk7205v200_lite5116KB,gk7202v300_lite5104KB, and this PR's own CI showedgk7605v100_liteat 5112KB. All have around 260KB of kernel partition unused. The rootfs of this family has been growing 8-16KB a night with the streamer build it ships, so the next board was going to fail tomorrow.What changes
Two things, both measured from the
sizes.gk7205v200-lite.jsonreport of tonight's run, applied to all four kernel configs underbr-ext-chip-goke/board/gk7205v200/:scsi_mod.ko(145KB),sd_mod.ko(36KB) andscsi_transport_fc.ko(53KB) ship in every rootfs of this family and nothing can use them:CONFIG_USB_STORAGEis not set in any Goke config, no other SCSI host driver is enabled, and SD cards come in asmmcblk, notsd. Same shape as kernel: disable f2fs on all *_lite configs to fix NOR rootfs overflow #2185 switching f2fs off.CONFIG_SCSI_MOD=yis whatolddefconfigderives whenSCSIis off.No feature changes hands.
Measured
Local from-scratch builds of this branch against the same majestic tarball the failed nightly fetched (686248 bytes, fetched 2026-09-06 18:50 UTC), compared with the nightly's numbers. This PR's CI rows reproduce the same numbers to the kilobyte.
Kernel +19KB and rootfs −104KB on every board. In each built tree the effective kernel
.confighas# CONFIG_SCSI is not set,CONFIG_FAT_FS=y,CONFIG_VFAT_FS=y, and the rootfs carries noscsi_mod,sd_mod,scsi_transport_fc,fatorvfatmodule (66 modules, from 71). The ultimate images of the same configs shrink by the same amount and were never near their 8192KB limit.Tested on hardware
gk7205v200 (IMX307, Xiongmai
IPC_GK7205V200_50H20AI_S38, NOR, 5120 KB rootfs partition), flashed fromnightly-20260902-dc2b3feto an image built at this PR's head (stampedBUILD_SHA=5c4361c9…,uImage 1800KB/2048KB,rootfs 5012KB/5120KB) withsysupgrade --kernel= --rootfs=. Both partitions verified by flashcp; the camera was back on SSH about 15 s after the reboot./proc/filesystemslistsvfatwith no module loaded,modules.builtincarriesfat/vfat, andkernel/drivers/scsiandkernel/fs/fatare gone from/lib/modules.modprobe vfatfromS35modulesexits 0.mkfs.vfaton a 4 MB file, loop-mount, write, remount, read back — OK on both the old and the new kernel. No SD card is fitted to this camera, so the card path itself was not exercised; the SD host controllers register as before.usb-storagewas never built for Goke —modprobe usb-storagesays not found, and loadingsd_modby hand on the old image still produced no/dev/sda. The dropped SCSI modules could not be used on this firmware./image.jpgHTTP 200. Overlay (majestic.yaml,shadow) preserved.Full before/after transcript in the review thread. Not on hardware: gk7205v300, gk7202v300, gk7605v100 — same kernel tree and the same two config changes, built by CI, but the lab has only the v200.