gk7205v500: keep 64 MB boards on the media-memory carve-out

[openipc-ai]

Problem

load_goke switches any gk7205v500 command line that names no allocator to CMA for the next boot. That switch was measured on one 128 MB V510, where Linux went from 28 MB to 125 MB (#2526). It was never run on a 64 MB board, which is what most gk7205v500 cameras carry. The 64 MB reporter in OpenIPC/majestic#350 objects to their board being moved to CMA.

At 64 MB the media zone is 32 MB with CMA or without it, and a 4 MP pipeline uses most of it. So CMA can lend Linux only the little the zone leaves free. In exchange, every media allocation depends on the kernel first migrating movable pages out of the zone.

What this is not. It is not a fix for an observed CMA failure. Both of the #350 reporter's logs, with CMA and without, fail with the same ERR_VPSS_NOMEM / ERR_VENC_NOMEM. That failure is majestic putting a 2560-wide sensor on VI offline, which is being fixed in majestic. This PR returns 64 MB boards to the configuration they had before #2526, until CMA is measured there.

Hardware tested on

Not run on a camera. The lab has no 64 MB gk7205v500. The only gk7205v500-family board (a 128 MB V510) was unreachable. A 128 MB board would only show that nothing changes for it.

The evidence below is the function itself, run in busybox with stubbed fw_printenv/fw_setenv, /proc/cmdline and /proc/meminfo. A board with this image would also show it: on a fresh 64 MB install, load_goke no longer prints Media memory: switching to CMA, and fw_printenv bootargs keeps mem=32M. Confirmation from anyone with a 64 MB board is welcome.

Evidence

check_allocator() extracted from load_goke, with /proc paths redirected to test files and osmem=32M.

Before (origin/master):

totalmem=64 [mem=32M console=ttyAMA0,115200 panic=20 root=/dev/mtdblock3] -> Media memory: switching to CMA from the next boot (mem=64M)
SETENV bootargs mem=64M console=ttyAMA0,115200 panic=20 root=/dev/mtdblock3 mmz_allocator=cma mmz=anonymous,0,0x42000000,32M
totalmem=128 [mem=32M console=ttyAMA0,115200 panic=20 root=/dev/mtdblock3] -> Media memory: switching to CMA from the next boot (mem=128M)
SETENV bootargs mem=128M console=ttyAMA0,115200 panic=20 root=/dev/mtdblock3 mmz_allocator=cma mmz=anonymous,0,0x42000000,96M
totalmem=32 [mem=32M console=ttyAMA0] -> <bootargs unchanged>
totalmem=128 [mem=128M mmz_allocator=cma mmz=anonymous,0,0x42000000,96M] -> <bootargs unchanged>

After:

totalmem=64 [mem=32M console=ttyAMA0,115200 panic=20 root=/dev/mtdblock3] -> <bootargs unchanged>
totalmem=128 [mem=32M console=ttyAMA0,115200 panic=20 root=/dev/mtdblock3] -> Media memory: switching to CMA from the next boot (mem=128M)
SETENV bootargs mem=128M console=ttyAMA0,115200 panic=20 root=/dev/mtdblock3 mmz_allocator=cma mmz=anonymous,0,0x42000000,96M
totalmem=32 [mem=32M console=ttyAMA0] -> <bootargs unchanged>
totalmem=128 [mem=128M mmz_allocator=cma mmz=anonymous,0,0x42000000,96M] -> <bootargs unchanged>

A 64 MB board that has already been switched keeps its CMA bootargs. To move it back, drop mmz_allocator= and mmz= from bootargs and set mem= back to osmem (mem=32M). Removing the allocator alone leaves mem=64M, and the carve-out then has no room for the zone.

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

Keep 64 MB gk7205v500 boards on the media-memory carve-out

🐞 Bug fix 🕐 Less than 10 minutes

AI Description

• Prevent automatic CMA migration on gk7205v500 boards with 64 MB of RAM or less.
• Preserve CMA migration for larger boards and leave existing bootargs unchanged.

Diagram

graph TD
  check["Allocator check"] --> prechecks{"Prechecks pass?"} -->|Yes| threshold{"DDR > 64 MB?"} -->|Yes| rewrite["Schedule CMA"]
  prechecks -->|No| unchanged["Leave bootargs"]
  threshold -->|No| unchanged

Loading

High-Level Assessment

The guard at the existing migration decision is the narrowest approach: it preserves behavior above 64 MB and does not overwrite boards already configured for CMA. Changing the default allocator or forcing bootargs for all boards would broaden the impact without evidence from 64 MB hardware.

Files changed (1) +6 / -0

Bug fix (1) +6 / -0

load_gokeExclude 64 MB and smaller boards from automatic CMA migration +6/-0

Exclude 64 MB and smaller boards from automatic CMA migration

• Adds an early return when detected total memory is 64 MB or less, before check_allocator rewrites bootargs for the next boot. Comments explain why the existing media-memory carve-out is retained until CMA is measured on those boards.

general/package/goke-osdrv-gk7205v500/files/script/load_goke

[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. Other cameras inherit a 64 MB policy 📘 Rule violation ≡ Correctness

Description

check_allocator() returns early when totalmem is 64 MB or less, embedding the 64 MB policy in
the shared load_goke script. Every board image that installs this script, including the separate
lite configuration, now gets the carve-out behavior based on memory size rather than device-specific
builder configuration.

Code

general/package/goke-osdrv-gk7205v500/files/script/load_goke[R112-117]

+	# CMA was measured on 128 MB (a V510: Linux 28 MB -> 125 MB, #2526). A
+	# 64 MB board has a 32 MB zone either way, and a 4 MP pipeline fills most
+	# of it, so CMA would lend Linux little while every media allocation would
+	# depend on migrating pages out first. Until it is measured there, 64 MB
+	# and less stay on the carve-out (majestic#350).
+	[ "$totalmem" -gt 64 ] || return 0

Evidence

The checklist forbids introducing board-specific values or branches in shared load scripts. The
changed script hardcodes a 64 MB cutoff, and the same package is selected by multiple board
configurations, including the separate gk7201v200_lite configuration.

general/package/goke-osdrv-gk7205v500/files/script/load_goke[112-117]
br-ext-chip-goke/configs/gk7201v200_lite_defconfig[46-53]
Best Practice: Repository guidelines

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 `load_goke` script now hardcodes a 64 MB board policy, so every board using this script inherits the behavior even when the policy is intended for a specific board family or memory configuration.
## Fix Focus Areas
- general/package/goke-osdrv-gk7205v500/files/script/load_goke[112-117]
- br-ext-chip-goke/configs/gk7201v200_lite_defconfig[46-53]
- br-ext-chip-goke/configs/gk7205v500_lite_defconfig[46-53]
## Recommended Fix
Move the memory-policy threshold or board-family selection into the appropriate device-specific builder configuration, and have the shared script consume that configuration without hardcoding a value that changes behavior for unrelated images.

ⓘ 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 see how risky a PR is at a glance with blast radius labels

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗