[openipc-ai]

The XM510 gets the open VI driver. xiongmai-opensdk-xm510 now also builds drivers/xm510_vi (open_vi.ko) from OpenIPC/openxiongmai, pinned at 9498822 (OpenIPC/openxiongmai#41). load_xiongmai loads it by modprobe, falling back to the vendor xm510_vi.ko.

open_vi keeps the vendor /dev/vi ABI and the vendor buffer protocol. It also:

• releases the frames a consumer still holds when it exits;
• adds poll and a non-blocking get;
• stops capture DMA before VI's reset.

It looks up the MMZ symbols at run time, so it has no module dependency and loads on open_mmz or on the vendor mmz.ko.

The vendor fallback uses insmod, not modprobe. xm510_vi.ko declares depends=mmz, so with open_mmz loaded, modprobe xm510_vi tries to load the vendor mmz.ko beside it. That fails, and the whole fallback with it. Seen on the camera:

modprobe: can't load module mmz (xiongmai/mmz.ko): invalid module format
mmz: exports duplicate symbol mmz_alloc (owned by open_mmz)

insmod xm510_vi.ko takes the symbols from whichever MMZ module is loaded.

Tested

XM510 + JX-H62, xm510_lite image from this branch flashed with sysupgrade:

• Boot: load_xiongmai loads open_mmz, open_vi and open_h264, the vendor ISP and RGN run on them, and majestic streams H.264.
• Reload: load_xiongmai -r, then -i, unloads everything and loads it back, and video returns.
• Fallback: with open_vi hidden, the fallback loads the vendor xm510_vi on top of open_mmz, and video streams.

The driver's own tests are in OpenIPC/openxiongmai#41:

• same /proc/umap/vi and picture as the vendor driver;
• poll, non-blocking get, release and release-on-close;
• live resizing;
• ten restarts and fifteen kill -9.

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

PR Summary by Qodo

Use open_vi for XM510 video input with vendor fallback

✨ Enhancement 🐞 Bug fix 🕐 20-40 Minutes

AI Description

• Build and prefer open_vi for XM510 video input while retaining the vendor driver as a fallback.
• Use insmod for the fallback to avoid loading vendor MMZ alongside open_mmz.
• Document the new module in the package help and license metadata.

Diagram

graph TD
  L["load_xiongmai"] --> M["MMZ module"] --> V{"open_vi available?"}
  V -->|modprobe| O["open_vi"] --> R["ISP RGN H.264"]
  V -->|insmod fallback| X["xm510_vi"] --> R

Loading

High-Level Assessment

Prefer the open driver while retaining the vendor fallback: this supports images without open_vi and preserves the existing VI load order. Keeping only the vendor driver would forgo the new driver, while modprobe for the vendor fallback can attempt to load a conflicting vendor MMZ module.

Files changed (3) +30 / -14

Enhancement (1) +8 / -6

xiongmai-opensdk-xm510.mkBuild open_vi from a newer openxiongmai revision +8/-6

Build open_vi from a newer openxiongmai revision

• Pins openxiongmai to 9498822 and adds drivers/xm510_vi to the kernel-module build. Extends license metadata and package comments to cover open_vi and its runtime MMZ symbol lookup.

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

Bug fix (1) +20 / -6

load_xiongmaiPrefer open_vi and preserve a working vendor VI fallback +20/-6

Prefer open_vi and preserve a working vendor VI fallback

• Loads open_vi with the existing buffer setting, falling back to insmod of xm510_vi to avoid modprobe pulling in vendor MMZ alongside open_mmz. Unloads whichever VI module was used before removing MMZ.

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

Documentation (1) +2 / -2

Config.inDocument open_vi in XM510 package help +2/-2

Document open_vi in XM510 package help

• Adds video input to the package description alongside the existing open MMZ and H.264 modules.

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

[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. Vendor fallback skips dependency checks 📘 Rule violation ⚙ Maintainability

Description

insert_vi invokes insmod xm510_vi.ko when modprobe open_vi fails, so the shipped script no
longer uses the tree's required module loader for its vendor path. Any image taking that fallback
reaches a dependency-blind loader instead of having modprobe resolve and validate the module's
declared dependencies.

Code

general/package/xiongmai-osdrv-xm510/files/script/load_xiongmai[R96-97]

+	modprobe open_vi buffer=$VI_BUFF 2>/dev/null ||
+		insmod xm510_vi.ko buffer=$VI_BUFF

Evidence

The changed fallback path directly calls insmod xm510_vi.ko, while the compliance rule requires
shipped scripts to load kernel modules with modprobe.

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

Agent prompt

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

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
Issue description
The shipped `load_xiongmai` script falls back to `insmod xm510_vi.ko`, which bypasses the repository convention requiring shipped scripts to load kernel modules with `modprobe`.
Fix Focus Areas
- general/package/xiongmai-osdrv-xm510/files/script/load_xiongmai[96-97]
Recommended Fix
Make the vendor fallback dependency-aware without attempting to load the conflicting vendor `mmz.ko` over `open_mmz`; then remove the direct `insmod xm510_vi.ko` call. Preserve the existing preference for `open_vi` and ensure the vendor fallback still works when only the vendor MMZ module is loaded.

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