hi3516ev300, gk7205v300: back under the squashfs cap

[openipc-ai]

Problem

Two boards are over the 5120 KB squashfs cap on master right now, independently of any open PR:

• hi3516ev300_lite — 5124 KB, 4 KB over. It has been red since the 2026-09-17 master build (run 35253636374).
• gk7205v300_lite — passed that run at 5119.54 KB of 5120 KB, with the "0KB left" headroom warning firing, and a local build of master today comes out at 5124 KB, 4 KB over. goke + cv500 neo: drop the kernel modules these boards cannot load #2421 wrote the lesson down: a board at zero headroom will go red on the next unrelated PR, not on the one that pushed it there. That is exactly what happened — it went red on tunnel: improve startup resilience and diagnostics #2438, which only adds ~620 bytes of compressed overlay.

This is the fourth size-cap red in four days (#2397, #2404, #2410, #2421, #2433, #2437 precede it). The root cause is unpinned majestic/majestic-webui, which is deliberate and untouched here — #2420 has the analysis.

The two boards are in different states and need different levers.

hi3516ev300_lite needed no kernel bytes at all. It still ships scsi_mod, scsi_transport_fc and sd_mod — 276 KB of modules — while CONFIG_USB_STORAGE, CONFIG_ATA, CONFIG_ISCSI_TCP and CONFIG_LIBFC are all unset. There is no SCSI transport of any kind on the board, so sd_mod can never bind a device, and scsi_transport_fc is Fibre Channel on an IP camera. 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 records hi3516ev300_lite as the hardest board to fix — only 43 KB of kernel headroom, so it cannot pay for the build-in trade used elsewhere. It turns out it does not have to. For completeness I did measure the crypto build-in on it first: 5104 KB rootfs but 2018 KB uImage, tripping the headroom warning on both axes. Dropping SCSI is strictly better.

gk7205v300_lite is out of free levers. #2421 stripped the modules it cannot load, #2376 dropped its SCSI stack and built FAT in, and #2433 built its crypto helpers in two days ago. Its kernel config is down to 13 modules and every one is live. So this takes the cheaper half of the only measured lever left. #2420's table shows cfg80211 + mac80211 + mt7601u built in saves 272 KB of rootfs but costs 198 KB 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 here; mac80211 and mt7601u stay modules.

The cost is worth stating plainly: cfg80211 is now permanently resident, so every gk7205v300 camera pays ~278 KB of RAM for the wireless core whether a dongle is ever plugged in or not.

Hardware tested on

None. This has not run on a camera, and the box below is deliberately unticked.

The only hi3516ev300 in our lab (10.216.128.34) is an unclaimed camera whose login shell is openipc-claim, and claiming it would mean accepting the Majestic EULA on someone else's behalf, which CLAUDE.md forbids. The plain hi3516ev300_lite board (10.216.128.68) is down, and it has neither bootlimit/altbootcmd nor a serial path, so it is not a board to flash an unverified kernel onto. We have no gk7205v300 at all.

What can be shown without a camera is below: full rebuilds of both boards, the generated .config, and the resulting module tree.

Evidence

Full make BOARD=<board> rebuilds after make clean, real mksquashfs -b 128K -comp xz on the real target tree.

Before (master, 839b9906):

hi3516ev300_lite
- uImage: [2005KB/2048KB]
- rootfs.squashfs: [5124KB/5120KB]
-- size exceeded by: 4KB

gk7205v300_lite
- uImage: [1823KB/2048KB]
- rootfs.squashfs: [5124KB/5120KB]
-- size exceeded by: 4KB

After:

hi3516ev300_lite
- uImage: [2005KB/2048KB]          43KB free, unchanged -- zero kernel cost
- rootfs.squashfs: [5044KB/5120KB] 76KB free            -- 80KB recovered

gk7205v300_lite
- uImage: [1885KB/2048KB]          163KB free           -- +62KB
- rootfs.squashfs: [5036KB/5120KB] 84KB free            -- 88KB recovered

Neither board prints a headroom warning any more.

The generated kernel .config agrees with the checked-in file, and the module trees follow:

$ grep -E '^CONFIG_SCSI|# CONFIG_SCSI is' output-ev300size/build/linux-custom/.config
CONFIG_SCSI_MOD=y
# CONFIG_SCSI is not set
$ find output-ev300size/target -name '*scsi*.ko' -o -name 'sd_mod.ko' | wc -l
0

$ grep -E '^CONFIG_(CFG80211|MAC80211|MT7601U)=' output-gk300size/build/linux-custom/.config
CONFIG_CFG80211=y
CONFIG_MAC80211=m
CONFIG_MT7601U=m

The cfg80211 load path survives being built in, which is the thing worth checking on this kind of change. busybox modprobe consults modules.builtin, and mac80211.ko no longer declares a dependency that would need resolving:

$ grep -c cfg80211 output-gk300size/target/lib/modules/4.9.37/modules.builtin
1
$ grep -E 'mac80211.ko:|mt7601u.ko:' output-gk300size/target/lib/modules/4.9.37/modules.dep
kernel/drivers/net/wireless/mediatek/mt7601u/mt7601u.ko: kernel/net/mac80211/mac80211.ko
kernel/net/mac80211/mac80211.ko:

Selector and shell gates on the branch:

$ python3 .github/scripts/ci-matrix.py --self-test
ci-matrix: self-test ok (99 boards, 136 packages, 56 cases)
$ git diff --name-only master | python3 .github/scripts/ci-matrix.py --stdin
ci-matrix: 15/99 boards (needs_build=True) --- narrowed to the affected boards

hi3516ev300_ultimate and gk7205v300_ultimate share the two configs and gain the same gains; both are on the 8192 KB layout with room to spare.

Scope

• No kernel patches under general/package/all-patches/linux/ (those go to OpenIPC/linux)
• No files specific to a single retail camera model (those go to OpenIPC/builder)
• No probing or bring-up tooling (that goes to OpenIPC/ipctool)
• Nothing under general/overlay/ or in a shared load_<vendor> script hardcodes a value specific to my board
• Package sources come from an OpenIPC repository, and any version bump keeps at least the specificity of the pin it replaces (a new package should pin a full 40-character SHA)
• No LD_PRELOAD, and no binaries that cannot be rebuilt from source
• New code is selected by a defconfig, so CI actually builds it

Board configs only; no package source or version changes.

---

#2438 is blocked behind this — it adds a shared overlay file and tipped gk7205v300_lite over. It will be rebased once this lands.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Restore squashfs headroom for hi3516ev300 and gk7205v300

🐞 Bug fix ⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Remove unusable SCSI modules from hi3516ev300 images, recovering 80 KB.
• Build cfg80211 into gk7205v300 kernels, recovering 88 KB of rootfs space.
• Preserve modular mac80211 and mt7601u support while restoring safe image headroom.

Diagram

graph TD
  GK["GK kernel config"] --> CFG["Built-in cfg80211"] --> GIMG["GK firmware images"]
  HI["HiSilicon config"] --> SCSI["Disabled SCSI stack"] --> HIMG["HiSilicon images"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Pin size-driving packages

• ➕ Prevents unbounded userspace growth from repeatedly exhausting board images.
• ➕ Avoids permanently increasing gk7205v300 kernel memory usage.
• ➖ Freezes or delays intended Majestic and WebUI updates.
• ➖ Does not remove the demonstrably unreachable hi3516ev300 SCSI stack.
• ➖ Introduces a broader release-policy change than this recovery PR requires.

Recommendation: Use the PR's targeted configuration changes for the immediate recovery: they preserve wireless capability, remove genuinely dead SCSI modules, and restore headroom with limited scope. Separately consider pinning or size-gating frequently changing packages to prevent recurring cap regressions, especially because built-in cfg80211 imposes a permanent RAM cost.

Files changed (2) +3 / -37

Other (2) +3 / -37

gk7205v300.generic.configBuild cfg80211 into gk7205v300 kernels +1/-1

Build cfg80211 into gk7205v300 kernels

• Changes CONFIG_CFG80211 from a module to built-in while retaining modular mac80211 and mt7601u drivers. Shared lite and ultimate builds gain approximately 88 KB of squashfs headroom at the cost of a larger uImage and permanently resident wireless core.

br-ext-chip-goke/board/gk7205v200/gk7205v300.generic.config

hi3516ev300.generic.configRemove the unreachable hi3516ev300 SCSI stack +2/-36

Remove the unreachable hi3516ev300 SCSI stack

• Disables top-level SCSI support and removes the unused disk, Fibre Channel transport, and low-level SCSI configuration. Generic hi3516ev300 consumers recover approximately 80 KB of rootfs space without increasing kernel image size.

br-ext-chip-hisilicon/board/hi3516ev200/hi3516ev300.generic.config

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (1) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Camera behavior remains unverified 📘 Rule violation ☼ Reliability

Description

The PR sets CONFIG_CFG80211=y and disables CONFIG_SCSI without testing either resulting kernel
on representative gk7205v300 or hi3516ev300 hardware, while build output and module metadata
cannot verify boot-time initialization, Wi-Fi association, device probing, or physical-storage
behavior. The wireless change is exercised through nl80211 whenever Wi-Fi starts in lite or ultimate
images, and the shared SCSI change reaches the dev, glibc, lite, and ultimate variants, including
images beyond the over-cap lite image.

Code

br-ext-chip-goke/board/gk7205v200/gk7205v300.generic.config[811]

+CONFIG_CFG80211=y

Evidence

Repository policy requires real-camera evidence for changes that can alter firmware behavior,
explicitly states that CI or build success alone is insufficient, and treats an admission that
hardware testing did not occur as a failure. The cited configurations make cfg80211 built-in while
retaining modular mac80211 and remove SCSI from a shared kernel configuration; shipped networking
exercises nl80211 during association, and the common automounter handles live kernel block devices,
so build measurements and module-tree checks cannot validate these runtime paths across the affected
variants.

Rule 1: Hardware evidence is present and honest
br-ext-chip-goke/board/gk7205v200/gk7205v300.generic.config[811-811]
br-ext-chip-hisilicon/board/hi3516ev200/hi3516ev300.generic.config[1104-1106]
.github/PULL_REQUEST_TEMPLATE.md[17-36]
br-ext-chip-goke/board/gk7205v200/gk7205v300.generic.config[811-821]
general/overlay/etc/network/interfaces.d/wlan0[1-5]
br-ext-chip-goke/configs/gk7205v300_lite_defconfig[17-21]
br-ext-chip-goke/configs/gk7205v300_ultimate_defconfig[17-21]
.github/PULL_REQUEST_TEMPLATE.md[17-43]
CLAUDE.md[273-279]
br-ext-chip-hisilicon/board/hi3516ev200/hi3516ev300.generic.config[1102-1108]
br-ext-chip-hisilicon/configs/hi3516ev300_dev_defconfig[18-22]
br-ext-chip-hisilicon/configs/hi3516ev300_glibc_defconfig[17-21]
br-ext-chip-hisilicon/configs/hi3516ev300_lite_defconfig[18-22]
br-ext-chip-hisilicon/configs/hi3516ev300_ultimate_defconfig[18-22]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes runtime kernel configuration for two camera families by making cfg80211 built-in and removing SCSI, but the PR description states that neither resulting image was tested on affected hardware. Build size, generated configuration, and module metadata do not verify boot behavior, wireless operation, device probing, or physical-storage behavior.
## Fix Focus Areas
- br-ext-chip-goke/board/gk7205v200/gk7205v300.generic.config[811-811]
- br-ext-chip-hisilicon/board/hi3516ev200/hi3516ev300.generic.config[1104-1106]
## Recommended Fix
Flash and boot each resulting image on representative gk7205v300 and hi3516ev300 cameras. For gk7205v300, record before/after boot logs, driver loading, scanning, and successful Wi-Fi association through nl80211; for hi3516ev300, record before/after boot logs and relevant onboard and removable-storage behavior. Add the observed results to the PR description and check the verification checkbox. If representative hardware validation is unavailable, revert the corresponding configuration change or keep the PR in draft until testing can be performed.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can type 'qodo, fix this' on a finding and the fix lands right on your PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗