gk7205v200, gk7605v100: build the crypto modules in, and go back under the squashfs cap

[openipc-ai]

Problem

Two boards do not produce an image on master: gk7205v200_lite and
gk7605v100_lite, each over its 5120KB squashfs cap by exactly 16KB.

gk7605v100_lite was not in the original diagnosis — it surfaced in this PR's
own matrix, which widened to the whole goke family because these board configs
share BR2_OPENIPC_SOC_FAMILY="gk7205v200". It has its own
gk7605v100.generic.config, untouched by the first commit here, and is red on
master for the same reason: nothing had built it lately.

gk7205v200_lite 5136KB against a
5120KB squashfs cap — over by 16KB, and repack fails the build.

It went unnoticed because nothing looks at this board. It is not in the ci-matrix
selection for any recent change, and gcc-compat — which builds gk7205v200_lite
and nothing else, and only when a diff touches Makefile,
general/package/*.mk or general/package/all-patches/ — last ran on master on
2026-09-13. I hit it because #2436 edits a .mk, which re-triggered that
workflow after four days.

Reproduced from a clean worktree at origin/master with no changes of any kind,
so this is not a side effect of that PR:

$ make BOARD=gk7205v200_lite
- uImage: [1808KB/2048KB]
- rootfs.squashfs: [5136KB/5120KB]
-- size exceeded by: 16KB
make[1]: *** [Makefile:178: repack] Error 1

What this changes

The eleven kernel crypto modules are 89,572 bytes of rootfs:

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

None of them is modprobed by anything. The kernel crypto API resolves them
through its own request_module(), so they cannot simply be dropped — doing so
would break wireguard and mac80211 and save nothing. Building them in is the
shape #2397 used and #2433 repeated for gk7205v300, gk7202v300 and
hi3519v101. gk7205v200 has the identical seventeen symbols still at =m;
it was simply missed.

The diff is those seventeen =m → =y, nothing else.

Hardware tested on

No physical camera — and unlike a driver or script change, that matters less
here than usual: this moves code from a .ko to vmlinux without altering what
the code is. The lab does have a gk7205v200 board, which is the reason to say
what was not done rather than imply otherwise: I did not flash it.

What is verified is the thing the PR is for — that the board builds again, and
by how much.

Evidence

Both numbers from clean builds (make clean first). This matters: Buildroot's
target/ keeps a .ko that an earlier build installed, so an incremental
rebuild after this change still ships all eleven modules and reports the old
size. My first attempt measured exactly that and showed a nonsensical 0-byte
saving against a kernel that had visibly grown.

Before, origin/master, clean worktree:

- uImage: [1808KB/2048KB]
- rootfs.squashfs: [5136KB/5120KB]
-- size exceeded by: 16KB

After, this branch, clean build:

- uImage: [1821KB/2048KB]
- rootfs.squashfs: [5112KB/5120KB]
- Build time: 03:25
-- headroom warning: rootfs.squashfs has 8KB left of 5120KB

The kernel takes 13KB of the 89KB and still has 227KB spare. The rootfs saves
24KB and the board builds.
target/lib/modules/4.9.37/kernel/crypto/ no longer exists on the built image.

gk7605v100_lite, same change to its own config, measured by this PR's CI
rather than locally — before, from this PR's first run:

- uImage: [1787KB/2048KB]
- rootfs.squashfs: [5136KB/5120KB]
-- size exceeded by: 16KB

after, from the run that went green:

- uImage: [1799KB/2048KB]
- rootfs.squashfs: [5112KB/5120KB]
-- headroom warning: rootfs.squashfs has 8KB left of 5120KB

Identical arithmetic: 24KB off the rootfs, 12KB onto a kernel with 249KB spare.

All seven boards the matrix selected are green:

SUCCESS  gk7202v300_lite     SUCCESS  gk7202v300_ultimate
SUCCESS  gk7205v200_lite     SUCCESS  gk7205v200_ultimate
SUCCESS  gk7205v300_lite     SUCCESS  gk7205v300_ultimate
SUCCESS  gk7605v100_lite

gk7202v300 and gk7205v300 still carry their seventeen crypto symbols as
modules and are deliberately left alone: both build with room today, and
converting a board that is not broken would be churn.

What this does not do

It leaves 8KB on each board, and the build says so for both. This gets them
building; it does not give them room, and the fleet-wide majestic drift that has taken six boards
over cap in #2421 and three in #2433 will take this one again.

There is no easy next 24KB in its module set. Every remaining non-vendor module
is either named by a script or dependency-loaded by one that is — checked
individually, including the five that look consumerless to a grep and are not:
usbnet, cdc_ether, mii, usb_wwan and usb-serial-simple are pulled in
by option / usbserial / rndis_host, which general/overlay/etc/wireless/modem
does modprobe. The USB gadget set that #2421/#2433 harvested is already gone
from this image.

Scope

• No kernel patches under general/package/all-patches/linux/ — this is a board kernel config, which CLAUDE.md places in this repository
• No files specific to a single retail camera model
• No probing or bring-up tooling
• 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
• 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 gk7205v200 crypto into kernel to restore image builds

🐞 Bug fix ⚙️ Configuration changes 🕐 Less than 10 minutes

AI Description

• Builds required crypto algorithms into the gk7205v200 kernel instead of shipping modules.
• Reduces squashfs usage below the 5120KB cap while preserving crypto consumers.
• Restores clean gk7205v200_lite image builds with 8KB rootfs headroom.

Diagram

graph TD
  A["Board config"] --> B["Crypto built-ins"] --> C["Kernel image"]
  B --> D["Crypto consumers"]
  B --> E["No crypto modules"] --> F["Smaller rootfs"] --> G["Image repack"]

Loading

High-Level Assessment

Building the crypto implementations into the kernel is the appropriate approach. Removing them would break kernel-requested dependencies for WireGuard and mac80211, while trimming unrelated modules would broaden scope and risk modem functionality; built-ins preserve capabilities and shift enough data out of squashfs to restore packaging.

Files changed (1) +17 / -17

Bug fix (1) +17 / -17

gk7205v200.generic.configLink required crypto algorithms into the gk7205v200 kernel +17/-17

Link required crypto algorithms into the gk7205v200 kernel

• Changes 17 crypto configuration symbols from modules to built-ins, eliminating eleven crypto .ko files from the rootfs. This moves functionality into the kernel image and brings gk7205v200_lite below its squashfs cap without removing crypto support.

br-ext-chip-goke/board/gk7205v200/gk7205v200.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

CONFIG_CRYPTO_AEAD and sixteen related CONFIG_CRYPTO_* settings move runtime crypto support from
loadable modules into the boot kernel without validation on a physical camera. Because the shared
configuration reaches lite, original, and ultimate gk7205v200 images as well as gk7205v210 cameras,
clean-build and size measurements alone leave boot-time initialization, streaming, wireless, and
WireGuard behavior unchecked.

Code

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

+CONFIG_CRYPTO_AEAD=y

Evidence

PR Compliance ID 1 requires real-camera evidence for changes that can alter firmware behavior and
explicitly fails changes reported as untested on hardware. The cited configuration contains the
module-to-built-in crypto conversion, and the PR description confirms that no physical camera was
flashed and supplies only build-size results; the relevant defconfigs select this shared kernel
configuration for all three gk7205v200 variants, while the lite image declares gk7205v210 as an
on-device upgrade alias and the retained gk7205v210 defconfig selects the same file.

Rule 1: Hardware evidence is present and honest
br-ext-chip-goke/board/gk7205v200/gk7205v200.generic.config[2653-2672]
br-ext-chip-goke/configs/gk7205v200_lite_defconfig[18-48]
br-ext-chip-goke/configs/gk7205v200_original_defconfig[17-40]
br-ext-chip-goke/configs/gk7205v200_ultimate_defconfig[17-48]
br-ext-chip-goke/configs/gk7205v210_lite_defconfig[1-50]

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 image-affecting crypto configuration changes move runtime crypto support from modules into the built-in kernel across multiple board variants and an aliased SoC model, but the resulting image was only build-tested and was not validated on a physical camera.
## Fix Focus Areas
- br-ext-chip-goke/board/gk7205v200/gk7205v200.generic.config[2653-2769]
## Recommended Fix
Flash a clean image onto an affected gk7205v200 camera, verify successful boot, streaming, wireless, and WireGuard operation, and add the exact observed hardware output, measurements, and test results to the pull request evidence.

ⓘ 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 enable the Remediation agent and Qodo fixes findings in a dedicated fix PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗