Repository navigation
xiongmai: XM530V200, XM533 and XM535 boards, with the V200 series' vendor modules - #2709
Conversation
…ndor modules Xiongmai's V200 series (OpenIPC/qemu-bench#154) runs the XM530's kernel, so the boards join the xm530 family: same kernel branch and toolchain, and a kernel config each in board/xm530: - xm530v200: SMP, as its vendor kernel is, with the latched SP804 read (XM530_SP804_LATCH). - xm533, xm535: uniprocessor. Their vendor kernels and modules are built UP, and the modules' vermagic says so. Each config names its own machine (XM530_MACHINE_NAME), so ipcinfo and sysupgrade see xm530v200, xm533 or xm535 rather than xm530. Each builds xm_v200_sd for the card slot. xiongmai-osdrv-xm530v200 ships each chip's vendor modules from a camera dump, installed by OPENIPC_SOC_MODEL: the X6C-WEQ for XM530V200, X3-WQ-B for XM533, and X6E-WEQ (D1) for XM535, whose media modules D2 shares. load_xiongmai loads them in the vendor's order, with its pll.sh written as devmem. MMZ is sized from totalmem, or from the chip's usual RAM size without it; on XM535 that size also selects the D1/W1 or D2/W2 PLLC. The SD card goes through the kernel's xm_v200_sd with the board's power pad: 86, 11 and 90 on those boards. sdio_pdn in the U-Boot environment overrides it; XM535D2 uses 8. Left out: - xm_wdt.ko: the kernel's sp805 is the watchdog, as on XM530. - the vendor sdio0_sd/sdio1_sd: they pass their own kernel's arasan platform data, and the probe jumps to 0. - the Wi-Fi drivers. These boards need the kernel side in OpenIPC/linux xiongmai-xm530: clk_get_pts, kthread_set_prio, the latch, the machine name and xm_v200_sd. Majestic is left out: it drives the XM530's media interface, and the V200 series has a different one, linked into Sofia with no library to call. So the boards are in UNBUILT_BOARDS until their modules have run on a camera. Tested in qemu-bench (-M xm530v200 -smp 2, xm533, xm535 at 64 and 128 MB). The OpenIPC U-Boot's V200 support and the cameras' own U-Boot, with its env pointed at 0x50000, both boot this kernel. Every vendor module loads with no unknown symbol or Oops, ipcinfo reports the chip, MMZ follows totalmem, and the SD card mounts and reads back what was written.
PR Summary by QodoAdd XM530V200, XM533 and XM535 lite board support
AI Description
Diagram
High-Level Assessment
Files changed (70)
|
Code Review by Qodo
1. Future builds cannot reproduce modules
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
| # The V200 series' vendor modules, one set per chip, from camera firmware | ||
| # (OpenIPC/qemu-bench#154): | ||
| # xm530v200 X6C-WEQ, V5.04.R02.20241125 | ||
| # xm533 X3-WQ-B, V5.04.R02.20250828 | ||
| # xm535 X6E-WEQ (D1), V5.07.X02.20250906; D2 and W1 share its modules | ||
| # They are built for their 3.10.103 vendor kernels. This family's kernel | ||
| # matches their vermagic (SMP on xm530v200, UP on xm533 and xm535) and exports | ||
| # what those kernels add (clk_get_pts, kthread_set_prio). | ||
| XIONGMAI_OSDRV_XM530V200_FILES = $(XIONGMAI_OSDRV_XM530V200_PKGDIR)/files/$(OPENIPC_SOC_MODEL) | ||
|
|
||
| define XIONGMAI_OSDRV_XM530V200_INSTALL_TARGET_CMDS | ||
| $(INSTALL) -m 755 -d $(TARGET_DIR)/lib/modules/3.10.103+/xiongmai | ||
| $(INSTALL) -m 644 -t $(TARGET_DIR)/lib/modules/3.10.103+/xiongmai $(XIONGMAI_OSDRV_XM530V200_FILES)/kmod/*.ko |
There was a problem hiding this comment.
1. Future builds cannot reproduce modules 📘 Rule violation ⚙ Maintainability
XIONGMAI_OSDRV_XM530V200_INSTALL_TARGET_CMDS installs precompiled, model-specific .ko files from the package’s files directories without a source location or compilation step. Because all three module sets are identified as extracted from camera firmware, the three images depend on binaries that cannot be traced to a buildable source or rebuilt for a kernel change.
Agent Prompt
## Issue description
The three images install factory-extracted kernel modules without a traceable, buildable source, preventing reproducible rebuilds for kernel changes.
## Fix Focus Areas
- general/package/xiongmai-osdrv-xm530v200/xiongmai-osdrv-xm530v200.mk[7-24]
- general/package/xiongmai-osdrv-xm530v200/files/xm530v200[kmod]
- general/package/xiongmai-osdrv-xm530v200/files/xm533[kmod]
- general/package/xiongmai-osdrv-xm530v200/files/xm535[kmod]
## Recommended Fix
Replace the extracted modules with a traceable, version-pinned OpenIPC-hosted source package or vendor SDK release that builds the required per-chip modules, and integrate that compilation into the package. If buildable source is unavailable, do not ship the extracted `.ko` files until their provenance and rebuild process are established.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
There was a problem hiding this comment.
Known, and the reason this is a draft: the PR description says so at the top. These modules come from factory firmware dumps, not a vendor SDK release. The way out is an XM530V200 SDK, or open-sourcing them in OpenIPC/openxiongmai as was done for the XM530; maintainers to decide.
…ttings
Xiongmai treats the XM535D1, XM535D2 and XM535W1 as distinct chips, with
one U-Boot and one firmware each. A plain XM535 is a first-generation
part that xm530_lite already serves. So xm535_lite becomes xm535d1_lite,
xm535d2_lite and xm535w1_lite. Each has a kernel config naming its
machine, so ipcinfo and soc= match the OpenIPC U-Boot's image for the
chip. Each also has its own module set and load_xiongmai:
- xm535d1: the X6E-WEQ's modules; PLLC 444 MHz; 64 MB; SD power pad 90.
- xm535d2: the X9-WE2Q's modules (the same media modules as the D1);
PLLC 450 MHz; 128 MB; SD power pad 8.
- xm535w1: the X2W-WNG's 2024 modules and pll.sh. It loads vi.ko
(line=0) where the D1/D2 load vpss.ko, and has no SD slot.
That replaces guessing D1 from D2 by the RAM size, which picked the wrong
PLL and power pad whenever totalmem was missing (review on #2709). The
package's licence is PROPRIETARY, not MIT: these are vendor binaries, and
there is no LICENSE file to name.
In qemu-bench, booted through each chip's OpenIPC U-Boot (OpenIPC/u-boot#90),
each chip:
- reports its own chip in /proc/cpuinfo, ipcinfo and soc;
- programs its own PLLC;
- sizes MMZ from its own RAM;
- loads every module with no unknown symbol or Oops.
On the D1 and D2 the SD card mounts.
xm530v200_lite, xm533_lite, xm535d1_lite, xm535d2_lite and xm535w1_lite move from UNBUILT_BOARDS to ALL_BOARDS, beside xm530_lite, and xiongmai-osdrv-xm530v200 leaves NOT_BUILT now that they select it.
Problem
New hardware support: Xiongmai's V200 series, the XM530V200, XM533, XM535D1, XM535D2 and XM535W1. Xiongmai treats the three XM535 chips as separate chips; a plain XM535 is a first-generation part that
xm530_litealready serves. Camera dumps are in OpenIPC/qemu-bench#154. These parts run the XM530's kernel, so the boards join thexm530family:xm530v200_lite,xm533_lite,xm535d1_lite,xm535d2_liteandxm535w1_lite, with a kernel config each inboard/xm530/.CONFIG_SMP=n: their vendor kernels and modules are uniprocessor, and so is the modules' vermagic.xm535d2, ...), matchingsoc=from the OpenIPC U-Boot.xiongmai-osdrv-xm530v200: each chip's vendor modules underfiles/<soc_model>/, and aload_xiongmaiper chip.pll.shwithdevmem.totalmem, or from the chip's own RAM size; each chip has its own PLL settings and SD power pad.vi.kowhere the D1/D2 loadvpss.ko) and has no SD slot.xm_v200_sd, using the board's power pad.sdio_pdnin the env overrides it.xm_wdt. Majestic drives the XM530's media interface, and this series has a different one, linked into the vendor app with no library to call.ALL_BOARDS, besidexm530_lite.Depends on OpenIPC/linux#156 (exports, latch, machine name,
xm_v200_sd) being merged intoxiongmai-xm530. The OpenIPC U-Boot side is OpenIPC/u-boot#90.Warning
This fails the "No binaries without a buildable source" gate, knowingly. The 59
.koundergeneral/package/xiongmai-osdrv-xm530v200/files/*/kmod/were extracted from factory firmware dumps, not from a vendor SDK release:General_IPC_XM530V200_X6C-WEQ…V5.04.R02.20241125General_IPC_XM533W1_X3-WQ-B…V5.04.R02.20250828General_IPC_XM535D1_X6E-WEQ…V5.07.X02.20250906General_IPC_XM535D2_X9-WE2Q…V5.02.X02.20251223(the same media modules as the D1)General_IPC_XM535W1_X2W-WNG…V5.00.R02.20240410The modules cannot be shared between chips:
ddr.koandh264.koare shared, between XM533 and XM535;The way out is an XM530V200 SDK release, or open-sourcing these modules in OpenIPC/openxiongmai as was done for the XM530. Opened as a draft so maintainers can decide.
Hardware tested on
Not run on a camera. Only in qemu-bench, which emulates these SoCs. That is not hardware evidence: QEMU's SDHCI, SP804 and DDR do not check the vendor register values these modules and scripts write. Every image below was booted through the OpenIPC U-Boot from OpenIPC/u-boot#90, at -m 64M and -m 128M.
-M xm530v200 -smp 2-M xm533-M xm535-M xm535 -m 128M-M xm535,sensor-id=da4dEvidence
Before: there are no images for these SoCs.
After, in QEMU (not a camera). Output as captured, trimmed to the lines that matter:
SD in QEMU: a 256 KiB raw write to
/dev/mmcblk0reads back with the same md5 on xm530v200, xm533 and xm535d1. mdev mounts the vfat card at/mnt/mmcblk0on those and on xm535d2 (xm535w1 has no slot).Image sizes:
ci-matrix.py --self-test: ok (112 boards);--stdinon this diff selects all five V200 boards.Scope
general/package/all-patches/linux/(those go to OpenIPC/linux)general/overlay/or in a sharedload_<vendor>script hardcodes a value specific to my boardLD_PRELOAD, and no binaries that cannot be rebuilt from source