[openipc-ai]

The XM510 gets the open drivers the XM530 already has. xiongmai-opensdk-xm510 now builds two kernel modules from OpenIPC/openxiongmai (pinned at 0e82ee2, OpenIPC/openxiongmai#40), and load_xiongmai loads them by modprobe, falling back to the vendor modules:

• open_mmz: the XM510 mmz.ko's allocator (blocks on the next page, no marker), ioctls 0–3 on 40-byte records, and /proc/umap/mmz layout.
• open_h264: the Hantro encoder driver (openxiongmai drivers/hx280enc), in place of the vendor xm510_h264.ko.

Neither module needs a vendor module's symbols, so modprobe doesn't pull in a vendor mmz.ko, and the vendor modules stay where they are as the fallback. libwrapper.so is still built from the package's own source. load_xiongmai -r now also unloads mmz, which it used to leave loaded. VI, ISP and RGN stay vendor.

Tested

XM510 + JX-H62 (32 MB, mem=18M), xm510_lite image from this branch flashed with sysupgrade:

• at boot, load_xiongmai loads open_mmz and open_h264, and the vendor xm510_vi, xm510_isp and xm510_rgn run on open_mmz, with the same 12 MMZ blocks at the same addresses as with the vendor mmz.ko;
• majestic streams 1280×720 H.264 (116 KB of /video.mp4 in 5 s, and an earlier capture decoded cleanly with ffmpeg);
• load_xiongmai -r, then -i, unloads every module, the open ones included, and loads them back; video returns.

JPEG snapshots return 503 on this board with the vendor modules as well, so that is unrelated to this change.

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

PR Summary by Qodo

Add open MMZ and H.264 modules for XM510

✨ Enhancement 🐞 Bug fix 🕐 20-40 Minutes

AI Description

• Build pinned open MMZ and H.264 modules while retaining the package’s local compatibility library.
• Prefer open drivers at startup, with vendor modules as fallbacks.
• Unload MMZ during module removal so XM510 drivers can be reloaded cleanly.

Diagram

graph TD
  A["load_xiongmai"] --> B{"Open MMZ loads?"} -->|yes| C["Vendor VI ISP RGN"] --> D{"Open H264 loads?"} -->|yes| E["Video stream"]
  B -->|no| F["Vendor MMZ"] --> C
  D -->|no| G["Vendor H264"] --> E

Loading

High-Level Assessment

Using the pinned upstream drivers and Buildroot’s kernel-module infrastructure follows the existing XM530 pattern. Keeping the vendor modules as runtime fallbacks limits the impact when an open module cannot load; replacing the vendor media stack or retaining vendor-only drivers offers no clear advantage for this scope.

Files changed (3) +54 / -10

Enhancement (2) +50 / -9

xiongmai-opensdk-xm510.mkBuild pinned open MMZ and H.264 modules +21/-6

Build pinned open MMZ and H.264 modules

• Fetches a pinned openxiongmai revision, builds both drivers through Buildroot’s kernel-module infrastructure, and orders installation after the vendor driver package when enabled. It continues building libwrapper.so from this package’s own source and updates the license declaration.

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

load_xiongmaiPrefer open drivers and unload MMZ on removal +29/-3

Prefer open drivers and unload MMZ on removal

• Tries open_mmz and open_h264 with modprobe, falling back to the corresponding vendor modules if loading fails. Module removal now handles either driver variant and unloads MMZ after its vendor consumers.

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

Other (1) +4 / -1

Config.inRequire a kernel for the XM510 open-driver package +4/-1

Require a kernel for the XM510 open-driver package

• Makes the package depend on a Linux kernel and documents its new MMZ and H.264 kernel modules alongside the existing compatibility library.

general/package/xiongmai-opensdk-xm510/Config.in

[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. Fallback loading can skip dependencies ✓ Resolved

Description

insert_mmz() and insert_h264() fall back to insmod after modprobe fails. On images where a
module dependency is not already loaded, these fallbacks bypass dependency resolution and can
prevent the vendor video stack from initializing.

Code

general/package/xiongmai-osdrv-xm510/files/script/load_xiongmai[R80-81]

+	modprobe open_mmz mmz_start=$MEM_START mmz_size=$MEM_LEN 2>/dev/null ||
+		insmod mmz.ko mmz_start=$MEM_START mmz_size=$MEM_LEN ||

Evidence

The loader added by this PR uses modprobe for the open modules but calls insmod when either
open-module load fails. This violates the shipped-script convention requiring kernel modules to be
loaded with modprobe, which resolves dependencies automatically.

Rule 13: Shipped scripts follow tree conventions
general/package/xiongmai-osdrv-xm510/files/script/load_xiongmai[78-93]

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 shipped loader invokes `insmod` for both vendor fallbacks, bypassing automatic kernel-module dependency resolution required by the tree's module-loading convention.
## Fix Focus Areas
- general/package/xiongmai-osdrv-xm510/files/script/load_xiongmai[80-82]
- general/package/xiongmai-osdrv-xm510/files/script/load_xiongmai[90-93]
## Recommended Fix
Replace the vendor `insmod` fallbacks with `modprobe` calls using the appropriate module names and arguments, while preserving the existing error handling and open-module preference.

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

---

2. Package help points to a different site ✓ Resolved

Description

Config.in describes the new modules as coming from OpenIPC/openxiongmai but leaves the help URL at
https://openipc.org rather than the repository named by XIONGMAI_OPENSDK_XM510_SITE. Someone
using the package help to inspect the newly fetched source is sent to the project website instead of
the pinned source repository.

Code

general/package/xiongmai-opensdk-xm510/Config.in[7]

+	  kernel modules from OpenIPC/openxiongmai.

Evidence

The help text introduces the modules but supplies only the generic project URL, while the new SITE
rule fetches from the specific GitHub repository.

general/package/xiongmai-opensdk-xm510/Config.in[5-9]
general/package/xiongmai-opensdk-xm510/xiongmai-opensdk-xm510.mk[7-8]

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 package help does not name the repository fetched by its new SITE rule.
## Fix Focus Areas
- general/package/xiongmai-opensdk-xm510/Config.in[5-9]
- general/package/xiongmai-opensdk-xm510/xiongmai-opensdk-xm510.mk[7-8]
## Recommended Fix
Replace or supplement the generic help URL with `https://github.com/openipc/openxiongmai`, matching the repository specified by the package SITE.

ⓘ 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 ↗

[openipc-ai]

Also in 14a2040, for the help-text finding: the xiongmai-opensdk-xm510 help now points to https://github.com/OpenIPC/openxiongmai, where the modules come from.