rootfs: drop the kmod-only module indexes when there is no kmod

[openipc-ai]

Brings hi3516cv6xx_lite back under its rootfs cap. It is rootfs.squashfs: [5124KB/5120KB] on master: the 2026-09-26 nightly (run 36259587684) and every PR that builds the board since, #2487 included.

Change

depmod writes a binary index beside every text one (modules.*.bin), plus modules.builtin.modinfo, all of them for kmod. Every board here runs busybox modprobe (full, with alias and symbol support). It reads modules.dep, modules.alias, modules.symbols and modules.builtin as text and never opens the rest, and no defconfig selects kmod. rootfs_script.sh now removes them when the image has no kmod binary, the same shape as #2480's libgcc_s rule.

Measured

On the published 2026-09-25 hi3516cv6xx lite image, with libatomic already removed as #2480 does and rebuilt with the build's squashfs options (xz, 1M blocks, BCJ arm+armthumb): 52 KB uncompressed, 12,228 bytes of squashfs, against a 4 KB overrun. Every other board that ships modules shrinks as well.

Hardware

On a lab hi3516dv100 (busybox 1.36.1), a copy of /lib/modules/$(uname -r) without these files was bind-mounted over the real one:

• rmmod vfat fat; modprobe vfat → rc 0 and both modules loaded, so dependencies resolve from the text modules.dep.
• A full load_hisilicon -r / -i cycle loaded all 30 modules, and the streamer started.

An earlier revision also built CONFIG_FW_LOADER into the cv6xx kernel and pruned open_sensor_spi on cv6xx lite. Both are dropped. The review asked for cv6xx boot evidence I can't produce right now (the lab's cv6xx board is offline), and this lever alone clears the cap with room to spare.

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

PR Summary by Qodo

hi3516cv6xx_lite: trim rootfs back under the squashfs size cap

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

AI Description

• Build firmware loader in (CONFIG_FW_LOADER=m → y); it was the only kernel module, unused as a
 module.
• Prune open_sensor_spi from hi3516cv6xx_lite; sensor libraries use I2C, none opens SSP.
• rootfs_script.sh now drops kmod-only module indexes when no kmod binary is installed,
 shrinking every board shipping modules.
• Together these save ~17.4KB of squashfs, moving hi3516cv6xx_lite back under its 5120KB cap.

Diagram

graph TD
  A["Kernel build"] --> B["firmware_class built-in"]
  C["hisilicon-opensdk.mk"] --> D["Prune open_sensor_spi.ko"]
  E["rootfs_script.sh"] --> F{"kmod binary present?"}
  F -->|no| G["Remove modules.*.bin and modules.builtin.modinfo"]
  F -->|yes| H["Keep kmod indexes"]
  B --> I[("rootfs.squashfs")]
  D --> I
  G --> I

Loading

High-Level Assessment

The PR applies three narrowly-scoped, well-measured savings consistent with prior cap fixes (#2433/#2437/#2440/#2447) rather than a single larger architectural change. Given the tight margin (17.4KB saved vs 4KB overrun) and the desire to keep other boards unaffected except where clearly safe (the kmod-index drop benefits all boards), this incremental approach is appropriate; no better alternative (e.g. bumping the cap or dropping a feature) is considered necessary.

Files changed (3) +13 / -2

Enhancement (2) +12 / -1

hisilicon-opensdk.mkPrune open_sensor_spi module on hi3516cv6xx lite +3/-1

Prune open_sensor_spi module on hi3516cv6xx lite

• Adds sensor_spi to HISILICON_OPENSDK_PRUNE_CV6XX_LITE list, removing open_sensor_spi.ko since no sensor library for this family uses SSP (all use I2C). Saves ~1.34KB of squashfs.

general/package/hisilicon-opensdk/hisilicon-opensdk.mk

rootfs_script.shDrop kmod-only module index files when kmod is not installed +9/-0

Drop kmod-only module index files when kmod is not installed

• Adds logic to remove modules.*.bin and modules.builtin.modinfo binary indexes from the target when no kmod binary is present, since busybox modprobe only reads the text-based module indexes. Saves ~12.2KB on hi3516cv6xx and shrinks any board shipping kernel modules without kmod.

general/scripts/rootfs_script.sh

Other (1) +1 / -1

hi3516cv6xx.generic.configBuild firmware loader statically instead of as a module +1/-1

Build firmware loader statically instead of as a module

• Changes CONFIG_FW_LOADER from m to y, since firmware_class.ko was the only kernel module on this family and nothing loaded it dynamically. Saves ~3.1KB of squashfs and uses available fitImage headroom.

br-ext-chip-hisilicon/board/hi3516cv6xx/hi3516cv6xx.generic.config

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

Code Review by Qodo

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

1. Camera boot behavior is unverified ✓ Resolved 📘 Rule violation ☼ Reliability

Description

CONFIG_FW_LOADER changes from a module to built-in kernel functionality without a boot or
firmware-loading check on the affected hardware. The PR explicitly says no cv610 was available for
testing, while this change and the rootfs module-index pruning alter runtime firmware and
module-loading behavior.

Code

br-ext-chip-hisilicon/board/hi3516cv6xx/hi3516cv6xx.generic.config[839]

+CONFIG_FW_LOADER=y

Evidence

Compliance rule 3 requires real-camera evidence when a change can alter camera behavior and
explicitly treats a statement that hardware testing was unavailable as a failure. The cited
configuration line changes firmware-loader operation, and the PR description states, `I have no
cv610 in the lab to boot it on`.

Rule 3: Hardware evidence is present and honest
br-ext-chip-hisilicon/board/hi3516cv6xx/hi3516cv6xx.generic.config[839-839]
general/scripts/rootfs_script.sh[43-45]

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 kernel firmware-loader behavior and removes module-loading artifacts but provides no boot or runtime verification from affected hardware.
## Fix Focus Areas
- br-ext-chip-hisilicon/board/hi3516cv6xx/hi3516cv6xx.generic.config[839-839]
- general/scripts/rootfs_script.sh[43-45]
## Recommended Fix
Test an affected hi3516cv6xx camera with the resulting image and add before-and-after evidence showing that it boots, streams, resolves embedded firmware requests, and loads any required modules successfully.

ⓘ 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 describe a rule in plain language on the Rules page and Qodo drafts it for you

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[openipc-ai]

I ran the fleet-wide lever on hardware, a lab hi3516dv100 (busybox 1.36.1 modprobe). I bind-mounted a copy of /lib/modules/$(uname -r) with modules.*.bin and modules.builtin.modinfo removed:

• rmmod vfat fat; modprobe vfat → rc 0, and both vfat and fat loaded, so dependency resolution works from the text modules.dep.
• A full load_hisilicon -r / -i cycle loaded all 30 modules, and the streamer started (HiSilicon SDK started).

Unmounting restored the board.

[openipc-ai]

Re Qodo rule-3 finding ("Camera boot behavior is unverified"): both halves are handled.

• rootfs_script.sh has hardware evidence now, from the hi3516dv100 run in my comment above.
• CONFIG_FW_LOADER=y is dropped, and so is the open_sensor_spi prune. I can't boot a cv6xx right now, and the module-index lever alone saves 12,228 B against a ≤4,096 B overrun.

The PR is now that one change.