hi3518ev300: build the crypto modules into the kernel, off the rootfs

[widgetii]

Problem

hi3518ev300_lite has been red since the 2026-09-10 nightly (run 34508971947):

- rootfs.squashfs: [5128KB/5120KB]
-- size exceeded by: 8KB

It is the only board of 99 that fails, and nothing in this repository grew to
do it. Diffing every downloaded tarball between the last green nightly
(34383640663, 09-09) and the red one, exactly two inputs changed size:

input	09-09	09-10	delta
majestic.hi3516ev200.lite.master.tar.bz2	707,587	722,505	+14,918 B
majestic-webui-dist.tar.gz	294,421	299,309	+4,888 B

Both are unpinned moving refs — majestic.mk fetches …master.tar.bz2,
majestic-webui.mk pins VERSION = dist — so an upstream publish lands in the
next nightly with no pull request here to point at. The growth is uniform
across boards, confirmed by the headroom annotations: hi3518ev300_lite went
12KB free → 8KB over, and hi3519v101_lite went 28KB free → 8KB free. Both
exactly −20KB. The Sigmastar uImage headroom barely moved (25→24KB), so the
kernel did not change.

CI printed the warning a day early, exactly as CHECK_SIZE's 32KB band is
meant to:

::warning::hi3518ev300_lite: rootfs.squashfs has 12KB left of 5120KB

Why this board. It carries a USB-WiFi stack its hi3516ev300_lite sibling
does not — wpa_supplicant, wireless-tools, json-c, and
linux-firmware-openipc with MEDIATEK_MT7601U and RTL_8188EU.

Why not simply rebalance the partitions. The kernel partition has 184KB
idle (1864KB of 2048KB), but it cannot be lent to the rootfs. The 8MB map is
compiled into U-Boot and saved in every deployed camera's environment:

mtdparts=hi_sfc:256k(boot),64k(env),2048k(kernel),5120k(rootfs),-(rootfs_data)

rootfs starts at 0x250000 and is immediately followed by rootfs_data, the
owner's overlay. A squashfs over 5120k would run past the end of the rootfs MTD
and into it on every camera still on the old map. Code can move the other way,
though, and that is what this does.

Hardware tested on

Not run on a camera. There is no hi3518ev300 within reach — the change is
verified by local build only, and I have not ticked anything I did not observe.
Someone with the board should confirm it boots, streams, and still brings up an
MT7601U or RTL8188EU dongle before this is trusted in the field.

The evidence that does apply is below: two full local builds of
hi3518ev300_lite from this tree, the second differing only by this diff. The
baseline reproduces CI's numbers exactly (1864KB / 5128KB), which is what makes
the after-figures meaningful.

Evidence

Before:

- uImage: [1864KB/2048KB]
- rootfs.squashfs: [5128KB/5120KB]
-- size exceeded by: 8KB
make[1]: *** [Makefile:178: repack] Error 1

After:

- uImage: [1876KB/2048KB]
- rootfs.squashfs: [5104KB/5120KB]
-- headroom warning: rootfs.squashfs has 16KB left of 5120KB

The repack now completes and produces openipc.hi3518ev300-nor-lite.tgz
(7,129,032 B).

What moved. 11 .ko totalling 89,572 bytes leave /lib/modules; the
kernel grows 12KB. The trade works because most of a small .ko is ELF symbol
table, relocations and .modinfo, all of which disappear once the code is
linked in:

gcm.ko 16604   ccm.ko 12544   drbg.ko 11840   gf128mul.ko 9844
jitterentropy_rng.ko 9740   ctr.ko 6940   hmac.ko 5456   seqiv.ko 4640
echainiv.ko 4172   ghash-generic.ko 4020   crc32_generic.ko 3772

After the rebuild: 0 crypto .ko under /lib/modules, 32 crypto entries in
modules.builtin.

Nothing is dropped. mt7601u.ko, r8188eu.ko, mac80211.ko and
wireguard.ko all still ship, so both USB WiFi dongles behave as before. The
load path is unaffected: busybox modprobe reads modules.builtin
(modutils/modprobe.c:631) and answers module ... is builtin rather than
not found in modules.dep, and general/overlay/etc/wireless/usb does
modprobe mt7601u; exit 0, ignoring the exit status.

Shared config. hi3518ev300.generic.config is used by
hi3518ev300_lite and hi3518ev300_ultimate. The ultimate's kernel cap is
4096KB, so it absorbs the 12KB without coming close.

Selector and self-tests, run from the repo root:

$ git diff --name-only origin/master | python3 .github/scripts/ci-matrix.py --stdin
  hi3518ev300_lite
  hi3518ev300_ultimate
needs-build=true
reason=narrowed to the affected boards

$ python3 .github/scripts/ci-matrix.py --self-test
ci-matrix: self-test ok (99 boards, 135 packages, 56 cases)

$ python3 general/scripts/tests/test_kconfig_graph.py
Ran 2 tests — OK

$ STRICT=1 bash .github/scripts/test_shell_parse.sh
checked 141 shell script(s) — all parsed clean under busybox ash

$ STRICT=1 bash .github/scripts/test_strip_shell_comments.sh
All strip-shell-comments checks passed.

Known limitations

• 16KB of margin is thin. Majestic has been growing roughly 20KB a bump, so
  this buys one bump, not a year. The durable fix is upstream size discipline
  or a pin; this stops the bleeding without dropping a feature.
• The kernel and rootfs are a matched pair for this board from here on. A
  camera updated with sysupgrade -r alone would have the modules gone from
  the rootfs and not yet built into its kernel, and would lose WiFi until it
  also takes the kernel. The combined-image path writes both.
• hi3519v101_lite is the next domino, now at 8KB free of 5120KB. It is
  untouched here.

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

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

PR Summary by Qodo

Build hi3518ev300 crypto modules into the kernel

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

AI Description

• Builds 17 crypto options into hi3518ev300 kernels instead of loadable modules.
• Frees 24KB of rootfs space while consuming 12KB of kernel headroom.
• Preserves deployed flash partition layouts and existing WiFi functionality.

Diagram

graph TD
  C["Kernel config"] --> K["Built-in crypto"] --> U["uImage"] --> F["Firmware bundle"]
  C -->|"excludes crypto modules"| P["Module packaging"] --> R["Root filesystem"] --> F

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Pin upstream application artifacts

• ➕ Prevents unreviewed nightly size changes
• ➕ Makes firmware builds reproducible
• ➕ Retains kernel and rootfs contents unchanged
• ➖ May hold back upstream fixes and features
• ➖ Requires selecting and maintaining stable revisions
• ➖ Does not accommodate future intentional application growth

2. Resize flash partitions

• ➕ Provides substantially more rootfs headroom
• ➕ Avoids relocating functionality between artifacts
• ➖ Conflicts with deployed U-Boot environments
• ➖ Can overwrite existing rootfs_data overlays
• ➖ Requires a coordinated and risky migration path

3. Remove optional rootfs features

• ➕ Creates immediate rootfs headroom
• ➕ Avoids increasing the kernel image
• ➖ Regresses supported WiFi or application functionality
• ➖ Changes board capabilities to address a packaging constraint

Recommendation: The proposed module-to-built-in conversion is the best immediate fix because it preserves functionality and the deployed flash map while using available kernel headroom efficiently. Follow up by pinning or otherwise controlling the moving Majestic artifacts, and require hardware validation of boot, streaming, and both supported USB-WiFi drivers before field deployment.

Files changed (1) +17 / -17

Other (1) +17 / -17

hi3518ev300.generic.configLink required crypto algorithms into hi3518ev300 kernels +17/-17

Link required crypto algorithms into hi3518ev300 kernels

• Changes 17 crypto framework, cipher, hash, and random-number options from loadable modules to built-ins. This removes 11 crypto '.ko' files from the rootfs while retaining their functionality in kernels shared by the lite and ultimate variants.

br-ext-chip-hisilicon/board/hi3516ev200/hi3518ev300.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 lacks hardware proof 📘 Rule violation ☼ Reliability

Description

hi3518ev300.generic.config changes CONFIG_CRYPTO_AEAD and related crypto settings from loadable
modules to built-ins, but the resulting kernel was not tested on a real camera and its crypto
self-tests are disabled. The shared configuration reaches both lite and ultimate images, changing
initialization and module-loading behavior used by boot, streaming, WireGuard, and MT7601U or
RTL8188EU USB Wi-Fi paths without runtime validation.

Code

br-ext-chip-hisilicon/board/hi3516ev200/hi3518ev300.generic.config[2594]

+CONFIG_CRYPTO_AEAD=y

Evidence

The cited kernel configuration changes crypto support from a module to a built-in, while the PR
description explicitly says that no camera testing was performed. Both deployable hi3518ev300
variants select this shared configuration and package WPA/WireGuard functionality and the affected
USB Wi-Fi firmware; because crypto manager self-tests and the crypto test module are disabled,
successful build and size checks provide no repository-side runtime validation of booting,
streaming, or wireless operation.

Rule 1: Hardware evidence is present and honest
br-ext-chip-hisilicon/board/hi3516ev200/hi3518ev300.generic.config[2594-2594]
br-ext-chip-hisilicon/configs/hi3518ev300_lite_defconfig[18-24]
br-ext-chip-hisilicon/configs/hi3518ev300_lite_defconfig[32-37]
br-ext-chip-hisilicon/configs/hi3518ev300_lite_defconfig[61-63]
br-ext-chip-hisilicon/configs/hi3518ev300_ultimate_defconfig[18-24]
br-ext-chip-hisilicon/configs/hi3518ev300_ultimate_defconfig[33-38]
br-ext-chip-hisilicon/board/hi3516ev200/hi3518ev300.generic.config[2611-2619]

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 shared hi3518ev300 kernel configuration changes crypto components from loadable modules to built-ins and affects both lite and ultimate images, but neither resulting image has been exercised on real hardware. Build and size checks cannot establish that the rebuilt kernel boots or that streaming, USB Wi-Fi, and WireGuard still operate, particularly because kernel crypto self-tests are disabled.
## Fix Focus Areas
- br-ext-chip-hisilicon/board/hi3516ev200/hi3518ev300.generic.config[2594-2594]
- br-ext-chip-hisilicon/configs/hi3518ev300_lite_defconfig[18-24]
- br-ext-chip-hisilicon/configs/hi3518ev300_ultimate_defconfig[18-24]
## Recommended Fix
Build the before-and-after lite and ultimate images and test them on affected hi3518ev300 hardware. Update the PR evidence with observed successful boot and streaming results, then exercise WireGuard and the supported MT7601U and RTL8188EU USB Wi-Fi paths where the hardware is available before merging.

ⓘ 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 switch off images and animations for a plain-text comment

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗