xm530: autoload the SD card driver at boot

[yatotoshka]

Problem

On XM530 boards the vendor SD card driver (Arasan SDHC, kernel module
sdio0_sd) ships in the image but is never loaded: general/overlay/etc/modules
only lists vfat and exfat, so S35modules never modprobes it. With a card in
the slot the kernel shows no mmc controller and no /dev/mmcblk0; mdev's
automount helper (/lib/mdev/automount.sh) and majestic's record path
(/mnt/mmcblk0p1/%F) both expect the card at /dev/mmcblk0p1, so SD storage is
dead out of the box.

The module entry is appended to /etc/modules by a late post-build hook keyed on
BR2_PACKAGE_XIONGMAI_OSDRV_XM530 (xm530 and xm550 defconfigs), because
general/overlay/etc/modules is shared by every SoC and must stay board-agnostic.
check_target_modules.sh additionally asserts sdio0_sd.ko lands in the image
whenever the package is selected.

Hardware tested on

XM530AI (marking 30WX1), board IPC-RB-BLK530AI-0235P-AB0 V1.03, "anbiux-A8B-3mp",
128GB FAT32 (SDXC) card.

root@openipc-xm530:~# ipctool 
The ipctool installed as remote GitHub plugin
---
chip:
  vendor: Xiongmai
  model: XM530
board:
  vendor: Xiongmai
ethernet:
  mac: "f4:b1:9c:a8:ca:1f"
rom:
- type: nor
  block: 64K
  partitions:
    - name: boot
      size: 0x40000
      sha1: 69533542
      contains:
        - name: xmcrypto
          offset: 0x2fc00
        - name: uboot-env
          offset: 0x30000
    - name: env
      size: 0x10000
      sha1: 71a375d2
    - name: kernel
      size: 0x200000
      sha1: 0e79e563
    - name: rootfs
      size: 0x500000
      path: /,squashfs
      sha1: dc91c741
    - name: rootfs_data
      size: 0xb0000
      path: /overlay,jffs2,rw
  size: 8M
ram:
  total: 64M
  media: 29M
firmware:
  kernel: "3.10.103+ (SMP Tue Aug 18 23:09:10 UTC 2026)"
  toolchain: buildroot-gcc-13.3.0
  main-app: /tmp/majestic
sensors:
- vendor: SmartSens
  model: SC3335
  control:
    bus: 0
    type: i2c
    addr: 0x60
root@openipc-xm530:~# 

Evidence

Before — card inserted, kernel has no idea it exists:

root@openipc-xm530:~# cat /proc/partitions
major minor  #blocks  name
  31        0        256 mtdblock0
  31        1         64 mtdblock1
  31        2       2048 mtdblock2
  31        3       5120 mtdblock3
  31        4        704 mtdblock4
root@openipc-xm530:~# dmesg | grep -ci mmc
0

After (this patch, verified across a reboot):

arasan_set_clock:
	new freq 400000
mmc0: driver initialized... IRQ: 73, Base addr 0xc4e00000
arasan_set_clock:
	new freq 50000000
mmc0: new high speed SDXC card at address b368
mmcblk0: mmc0:b368 TW000 116 GiB
 mmcblk0: p1

root@openipc-xm530:~# df -h /mnt/mmcblk0p1
Filesystem       Size  Used Avail Use% Mounted on
/dev/mmcblk0p1   116G  32K  116G   1% /mnt/mmcblk0p1

Note: the kernel only supports vfat for the card (exfat is not built in and has
no module in this tree), so the card must be FAT32; this patch does not change
that.

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

Autoload the XM530 SD card driver at boot

🐞 Bug fix 🧪 Tests ⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Autoloads the XM530 SDHC driver without changing shared SoC module configuration.
• Restores SD card detection and existing mdev automount behavior on XM530/XM550 images.
• Fails CI when selected XM530 images omit the required driver module.

Diagram

graph TD
  CFG["XM530 package"] --> ROOT["Rootfs build"] --> HOOK["Autoload hook"] --> MODS["/etc/modules"] --> INIT["Boot modules"] --> DRIVER["sdio0_sd driver"] --> STORAGE["SD storage"]
  CFG --> CI["Module CI check"] --> DRIVER

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Modify the shared modules overlay

• ➕ Uses the existing static boot module list directly
• ➕ Avoids introducing a package-specific hook
• ➖ Forces an XM530-specific module onto unrelated SoC images
• ➖ Can create missing-module boot noise outside supported boards

2. Append during package installation

• ➕ Keeps all package behavior in its Buildroot makefile
• ➕ Avoids extending the late-hook registry
• ➖ The later rootfs overlay can overwrite the package-generated modules file
• ➖ Makes final image behavior dependent on Buildroot staging order

Recommendation: Keep the package-gated late post-build hook. It preserves the board-agnostic shared overlay, runs after overlay application, fails clearly if /etc/modules is absent, and avoids duplicate entries; the accompanying CI check also guards the packaged module artifact.

Files changed (3) +28 / -0

Bug fix (1) +26 / -0

post-build-hook.shRegister the SDHC driver for boot autoload +26/-0

Register the SDHC driver for boot autoload

• Adds a fail-fast, idempotent late post-build hook that appends sdio0_sd to the generated /etc/modules. This enables S35modules to load the vendor SDHC driver and expose inserted cards at boot.

general/package/xiongmai-osdrv-xm530/post-build-hook.sh

Tests (1) +1 / -0

check_target_modules.shVerify the XM530 SDHC module in CI +1/-0

Verify the XM530 SDHC module in CI

• Adds sdio0_sd.ko to the package-aware kernel module regression checks. Builds selecting BR2_PACKAGE_XIONGMAI_OSDRV_XM530 now fail when the driver is absent from the target image.

.github/scripts/check_target_modules.sh

Other (1) +1 / -0

late-post-build-hooks.listEnable the XM530 package post-build hook +1/-0

Enable the XM530 package post-build hook

• Registers the new hook under BR2_PACKAGE_XIONGMAI_OSDRV_XM530 so it runs only for package-selected XM530 and XM550 images.

general/scripts/late-post-build-hooks.list

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

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can start a comment with 'qodo' or '@qodo' to chat about any finding

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[openipc-ai]

The new module check can't fail, so it doesn't guard what it's meant to.

br-ext-chip-xiongmai/board/xm530/xm530.generic.config carries CONFIG_MMC_SD=m, and OpenIPC/linux xiongmai-xm530 has obj-$(CONFIG_MMC_SD) += sdio0_sd.o in drivers/mmc/host/Makefile. This PR's own xm530_lite run builds and installs it:

  LD [M]  drivers/mmc/host/sdio0_sd.ko
  INSTALL drivers/mmc/host/sdio0_sd.ko

So the image holds two modules called sdio0_sd.ko — that one under kernel/drivers/mmc/host/, and the vendor blob the package installs to xiongmai/. check_module does find "$TARGET_DIR/lib/modules" -name "$ko", which matches the kernel-built copy regardless of whether xiongmai-osdrv-xm530 shipped its own. If the package's INSTALL_TARGET_CMDS ever stopped installing it, the check would still print OK — exactly the #2032-class regression the script exists to catch.

Scoping the match by path fixes it without disturbing the wireguard entry:

-	if find "$TARGET_DIR/lib/modules" -name "$ko" | grep -q .; then
+	if find "$TARGET_DIR/lib/modules" -path "*/$ko" | grep -q .; then
…
-check_module BR2_PACKAGE_XIONGMAI_OSDRV_XM530 sdio0_sd.ko
+check_module BR2_PACKAGE_XIONGMAI_OSDRV_XM530 xiongmai/sdio0_sd.ko

wireguard.ko still matches as */wireguard.ko.

Worth knowing which of the two actually loads, since it isn't the in-tree source: with both present, depmod (kmod 34.2) writes only xiongmai/sdio0_sd.ko: into modules.dep — the external directory wins over kernel/, it still wins when modules.order names the kernel path, and it isn't alphabetical. So modprobe sdio0_sd loads the vendor blob and the kernel-built copy is shadowed dead weight.

Two smaller things while you're pushing, since touching late-post-build-hooks.list re-runs the full board matrix each time:

• The description implies SD works out of the box, but the driver loads with detect=0, so sdio0_powerup() leaves GPIO49 (sdio0_detect) unmuxed and need_detect/need_poll are both 0. A card present at boot enumerates, as your evidence shows; one inserted afterwards has no detect path. Worth saying hot-plug is out of scope — /etc/modules does take arguments (sdio0_sd detect=1) if it shouldn't be.
• Have you been able to try this on a second XM530 board, ideally one without a card slot? sdio0_powerup() muxes GPIO43-48 and 51-52 to SDIO and drives GPIO50 output-low unconditionally, and this makes that a default on every xm530/xm550 image. If those pads are free on all XM530 designs that's fine, but it'd be good to have it stated.

Everything else looks right to me — the hook is idempotent, the late-post-build-hooks.list placement genuinely does run after the overlay copy, and S35modules → S38mdev orders correctly (mdev sets the hotplug handler before mdev -s, so the coldplug can't race the card).