[openipc-ai]

This lets an XM530/XM550 camera opt in to a CMA-backed MMZ, as set_allocator does on Goke and HiSilicon. The default stays the fixed mem= zone.

Builds on:

• xm530: CONFIG_CMA without breaking the binary vendor modules linux#157 (merged): with CONFIG_CMA on, it keeps the binary vendor modules' ABI (struct device layout and the zonelist offset).
• xm530: CONFIG_CMA without an area, coherent memory from the page allocator linux#160: with CONFIG_CMA but no area (no cma=, the default layout), coherent memory comes from the page allocator. Without it, every dma_alloc_coherent() fails, and the XM550 oopses in the Ethernet driver at every boot. This PR must not merge before При ночном режиме картинка сиреневая #160.
• [xm_mmz] CMA mode: blocks from the kernel's CMA area openxiongmai#39 (merged): open_mmz allocator=cma. The xiongmai-opensdk pin moves to it (bf18f77).

Changes

• Kernel config: xm530.generic.config gets CONFIG_CMA=y with CONFIG_CMA_SIZE_MBYTES=0, so no area is reserved unless cma= asks for one. That costs about 4 KB of kernel.
• set_allocator cma [osmem]: writes mem=<DDR-1>M cma=<DDR-1-osmem>M mmz_allocator=cma and keeps the rest of bootargs in order.
  • Linux gets all of DDR except the top 1 MB. That 1 MB stays a fixed zone for xm530_rgn, which ioremap()s its block.
  • The media share becomes a CMA area that Linux uses for its own pages while the pipeline doesn't need it.
  • It refuses a kernel without CMA and an image without open_mmz/open_vi, since either would boot without video.
• set_allocator xm [osmem]: writes mem=<osmem>M, the default layout.
• load_xiongmai: on a mmz_allocator=cma boot it loads open_mmz allocator=cma, and it now reads mem= from anywhere on the command line.
• xiongmai-opensdk: pin bf18f77.

Tested

xm530_lite image built from this branch (kernel with #160 applied), flashed with sysupgrade onto an XM550 + IMX335:

• Default (mem=80M): open_mmz with the fixed zone and open_vi, no oops, snapshot OK.
• set_allocator cma 96, then reboot: mem=127M cma=31M mmz_allocator=cma, with 32 MiB of CMA reserved. majestic's 22 MB in 13 blocks came from CMA, rgn from the 1 MB zone, with 86 MB of memory free. No oops, snapshot OK.
• set_allocator xm 80, then reboot: back to mem=80M and the fixed zone, snapshot OK.

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

PR Summary by Qodo

Add opt-in CMA media allocation for XM530/XM550

✨ Enhancement ⚙️ Configuration changes 🕐 40+ Minutes

AI Description

• Enable kernel CMA support without reserving memory in the default layout.
• Add guarded allocator switching while retaining the fixed zone needed by xm530_rgn.
• Update open_mmz and module loading to use CMA when selected.

Diagram

graph TD
  A["set_allocator"] --> B["U-Boot bootargs"] --> C["Kernel layout"] --> D{"CMA selected?"}
  D -->|Yes| E["open_mmz CMA"] --> F["CMA area"]
  D -->|No| G["Fixed MMZ"] --> H["Fixed zone"]
  E -->|rgn 1 MB| H

Loading

High-Level Assessment

Keep the opt-in boot-argument approach: it preserves the working fixed-zone default and uses the updated open_mmz rather than changing the vendor module. The upstream kernel fix in OpenIPC/linux#160 is a merge prerequisite; without it, default-layout coherent DMA allocation can fail and XM550 can oops at boot.

Files changed (5) +103 / -3

Enhancement (2) +92 / -1

load_xiongmaiLoad CMA-backed MMZ when requested +12/-1

Load CMA-backed MMZ when requested

• Reads mem= from anywhere on the kernel command line. On CMA boots, it first loads open_mmz with allocator=cma, logs a failure, and retains the existing fixed-MMZ fallback.

general/package/xiongmai-osdrv-xm530/files/script/load_xiongmai

set_allocatorAdd guarded XM/CMA allocator switching +80/-0

Add guarded XM/CMA allocator switching

• Adds a command to write either the legacy mem= layout or a CMA layout for the next boot, preserving unrelated boot arguments. It validates the requested memory share and requires CMA kernel support plus open_mmz and open_vi before enabling CMA.

general/package/xiongmai-osdrv-xm530/files/script/set_allocator

Other (3) +11 / -2

xm530.generic.configEnable CMA with no default reservation +9/-1

Enable CMA with no default reservation

• Enables kernel CMA support for the shared XM530/XM550 configuration while setting its default area size to zero. An area is reserved only when boot arguments request one.

br-ext-chip-xiongmai/board/xm530/xm530.generic.config

xiongmai-opensdk.mkPin openxiongmai with CMA-capable open_mmz +1/-1

Pin openxiongmai with CMA-capable open_mmz

• Advances the opensdk revision to bf18f77, which provides the open_mmz allocator=cma support required by the new boot mode.

general/package/xiongmai-opensdk/xiongmai-opensdk.mk

xiongmai-osdrv-xm530.mkInstall set_allocator in target images +1/-0

Install set_allocator in target images

• Installs the new allocator-switching script as an executable in /usr/bin.

general/package/xiongmai-osdrv-xm530/xiongmai-osdrv-xm530.mk

[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. Video can fail after CMA allocation fails ✓ Resolved

Description

insert_mmz falls back to a fixed-zone allocator after open_mmz allocator=cma fails, although the
CMA boot layout leaves only one megabyte in that zone. If the CMA module fails to load or
initialize, insert_ko still loads the video stack against that undersized region rather than
stopping startup.

Code

general/package/xiongmai-osdrv-xm530/files/script/load_xiongmai[R73-76]

+		logger -s -p daemon.err -t xiongmai \
+			"open_mmz allocator=cma failed; set_allocator xm restores the fixed zone"
+	fi
modprobe open_mmz mmz_start="$MEM_START" mmz_size="$MEM_LEN" 2>/dev/null ||

Evidence

The new bootargs give Linux all but the top megabyte of DDR. The loader calculates its fixed MMZ
region from total DDR minus the booted mem= value, so its non-CMA fallback gets only that megabyte;
the video modules are then loaded regardless.

general/package/xiongmai-osdrv-xm530/files/script/set_allocator[63-68]
general/package/xiongmai-osdrv-xm530/files/script/load_xiongmai[9-11]
general/package/xiongmai-osdrv-xm530/files/script/load_xiongmai[70-77]
general/package/xiongmai-osdrv-xm530/files/script/load_xiongmai[106-116]

Agent prompt

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

## Issue description
A CMA boot has only a one-megabyte fixed zone, but a failed CMA module load falls through to fixed-zone MMZ and video startup.
## Fix Focus Areas
- general/package/xiongmai-osdrv-xm530/files/script/load_xiongmai[70-77]
- general/package/xiongmai-osdrv-xm530/files/script/load_xiongmai[106-116]
## Recommended Fix
On a CMA boot, report the CMA module failure and stop module startup instead of trying the fixed-zone allocator. Retain the existing fixed-zone fallback for non-CMA boots.

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

---

2. A later switch can use stale memory size ✓ Resolved

Description

set_allocator does not check whether fw_setenv osmem succeeds after writing bootargs, yet its
next invocation prefers that saved value over the booted memory layout. If the second environment
write fails, a later switch without an explicit size calculates its layout from the old osmem
rather than the size written to bootargs.

Code

general/package/xiongmai-osdrv-xm530/files/script/set_allocator[78]

+fw_setenv osmem "${os}M"

Evidence

The script writes bootargs first, ignores the status of its separate osmem write, and subsequently
selects osmem before consulting /proc/cmdline. Its CMA sizing formula then uses whichever value was
selected.

general/package/xiongmai-osdrv-xm530/files/script/set_allocator[38-44]
general/package/xiongmai-osdrv-xm530/files/script/set_allocator[65-68]
general/package/xiongmai-osdrv-xm530/files/script/set_allocator[74-80]

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 bootargs and osmem environment writes can diverge, and subsequent invocations prefer the stale osmem value.
## Fix Focus Areas
- general/package/xiongmai-osdrv-xm530/files/script/set_allocator[38-44]
- general/package/xiongmai-osdrv-xm530/files/script/set_allocator[74-80]
## Recommended Fix
Check the osmem write and report failure rather than success. Ensure a subsequent invocation derives its default from the effective boot layout when the saved osmem value did not persist.

ⓘ 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 turn on the rule miner and Qodo learns your standards from review history

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗