MM8108 on Raspberry pi CM5

Software
1

Hi all,

I’ve spent the last couple of days trying to get an MM8108-MF15457 up over SDIO on a Compute Module 5 and I’ve hit something I can’t get past on my own. Every Morse branch that supports the MM8108 crashes the RP1 SDIO host controller before the chip can enumerate, and the one branch that doesn’t crash won’t run MM8108 firmware.

My setup is a CM5 Rev 1.0 with the module on the 40-pin header of the PI. CLK on GPIO22, CMD GPIO23, D0-D3 on GPIO24/25/26/27, RESET_N on GPIO17 with a 10k pulldown. WAKE and BUSY aren’t connected — I’m only using reset. Power is fine, vcgencmd get_throttled reads 0x0.

config.txt:

gpio=17=op,dh
dtoverlay=sdio-pi5
dtoverlay=morse-sdio
kernel=kernel_2712-morse.img

The gpio= line is there because RESET_N is held low by the pulldown at boot and the chip won’t enumerate without it. My own overlay adds the child node under rp1_mmc0:

mm8108@2 {
        compatible = "morse,mm610x";
        reg = <2>;
        reset-gpios = <&gpio 17 0>;
        status = "okay";
};

I used reg = <2> because morse_of_probe runs against function 2, and morse,mm610x because the SDIO match table in sdio.c doesn’t have an MM8108 entry — just morse,mm6104 and morse,mm610x. Those were both guesses that turned out to work, so tell me if there’s a proper way to do this.

What I tried, same board and same overlay throughout:

Kernel dwcmshc probe mmc2 MM8108
Stock RPi OS 6.18.34+rpt fine yes — 0x325b / 0x0809 n/a, no driver
1.16.x + driver 1.16.4 + fw 1.16 fine yes probes, loads FW, fails at init
mm8108-2.0.x + driver 2.0.0 + fw 2.0 oops no never gets that far
mm8108-2.1.x + driver 2.1.0 + fw 2.1 oops no never gets that far

Issue is identical on 2.0.x and 2.1.x:

Unable to handle kernel execute from non-executable memory at virtual address ffffd06f59fb50d8
Internal error: Oops: 000000008600000f [#1] PREEMPT SMP
Hardware name: Raspberry Pi Compute Module 5 Rev 1.0 (DT)
CPU: 2 UID: 0 PID: 40 Comm: kworker/u19:0 Not tainted 6.12.21-morse+ #2
pc : sdhci_dwcmshc_ops+0x0/0xfffffffffffffc2f28 [sdhci_of_dwcmshc]
lr : dwcmshc_probe+0x2d0/0x778 [sdhci_of_dwcmshc]
  platform_probe+0x70/0xe8
  really_probe+0xc4/0x2d0

The rp1-sdio-clk ... loaded sdio_clk0 line shows up first, so the clock comes up and then the host controller dies in probe. No mmc2, so nothing to bind to. Dropping dtoverlay=sdio-pi5 stops the crash but leaves me with no SDIO host at all.

What makes me think this isn’t my wiring or my overlay: the exact same config on the stock Raspberry Pi kernel brings up mmc2 and enumerates the chip cleanly at vendor 0x325b, device 0x0809, two functions. So the hardware side seems right.

On 1.16.x it gets much further and then stops here:

morse_sdio mmc2:0001:1: sdio new func 1 vendor 0x325b device 0x809 block 0x8/0x8
morse_sdio mmc2:0001:2: sdio new func 2 vendor 0x325b device 0x809 block 0x200/0x200
morse_sdio mmc2:0001:2: morse_of_probe: Reading gpio pins configuration from device tree
morse_sdio mmc2:0001:2: Loaded firmware from morse/mm8108b2-rl.bin, size 456924, crc32 0xe4799c8d
morse_sdio mmc2:0001:2: Loaded BCF from morse/bcf_boardtype_0807.bin, size 2510, crc32 0xc8af8c0d
morse_sdio mmc2:0001:2: FW manifest pointer not set (ret:-5)
morse_sdio mmc2:0001:2: morse_firmware_init failed: -5

Before I matched the firmware to the branch I was getting Incompatible FW version: (Driver) 56.3.0, (Chip) 57.3.0 instead, which is what prompted me to keep kernel, driver and firmware on the same release line.

So, a few questions:

  1. Is SDIO on CM5/Pi 5 supported on any current branch? Given sdio-pi5 behaves under the stock kernel, the crash looks specific to the Morse trees rather than the hardware.
  2. Is the dwcmshc oops something you’ve seen? It’s not in 1.16.x but it’s in both 2.0.x and 2.1.x.
  3. Is the FW manifest pointer not set on 1.16.x just MM8108-over-SDIO not being supported in that release? I notice the SPI table distinguishes morse,mm610x-spi and morse,mm810x-spi, but the SDIO table only ever lists MM610x.
  4. If SDIO is a dead end here, is USB the way to go for MM8108 on RP1? The build thread mentions it skips the device tree entirely, which sounds a lot more appealing right now.

Happy to post the full dmesg from any of the four, or to try patches. Thanks for any pointers.

2

Hi @NimbleMarmot91

This is not something we’ve seen before, but Raspberry Pi CM5 boards do not form part of our regular test bed. In saying that, I wouldn’t have expected it to fail like this. We will try to reproduce and investigate.

In the meantime:

This error means the BCF or firmware do not match the version of the driver you are trying to load. Make sure the BCFs comes from the same version as the firmware.

USB is the simpler path, and if it is an option to you I’d recommend exploring it. SDIO shouldn’t be a dead end though.

To the kernel oops you are seeing, your program counter is pointing to a struct. This looks odd, and indicates that you have an ABI mismatch. Your cpu is trying to execute data!

In your build tree for one of the failing kernels, what does

   scripts/faddr2line vmlinux dwcmshc_probe+0x2d0/0x778

show?

3

Thanks for the response.

1. The Kernel Oops & faddr2line

I ran the trace against my locally rebuilt sdhci-of-dwcmshc.ko module. The offset 0x2d0 resolves directly to line 1471:

Plaintext

dwcmshc_probe+0x2d0/0x774:
dwcmshc_probe at drivers/mmc/host/sdhci-of-dwcmshc.c:1471

Line 1471 is executing a function pointer:
C

err = pltfm_data->init(&pdev->dev, host, priv);

Because the struct layout differs in the CM5 kernel, the memory offset fetches raw data from sdhci_dwcmshc_ops instead of the init function address—which perfectly explains why the CPU was trying to execute data. Additionally, the 0x778 offset you noted completely overshoots the function in my kernel (my rebuild sizes it at 0x774).

2. The v1.16 Manifest Failure (-5)

I dug into the v1.16 files to make sure I wasn’t just mixing up versions, but the 1.16 and 2.1 BCFs are actually byte-identical (crc32 0xc8af8c0d). The v1.16 tree ships bcf_boardtype_0807.bin but its Makefile doesn’t install it. Even when I manually force the genuinely matched v1.16 firmware and BCF components to load, it still fails at the manifest read.

4

What tree are you looking at? BCFs were updated here: morse-firmware/bcf/morsemicro at main · MorseMicro/morse-firmware · GitHub

(see commit history)

5

You were right about the BCFs, thanks.

My setup is two HaLowLink 1 routers one on my laptop, one on the CM5; plus the MM8108-MF15457 wired to the CM5’s SDIO.

bcf_boardtype_0807.bin is a symlink to bcf_mf15457.bin, and that file differs between releases: 2081 bytes on 1.16, 2510 on 2.0/2.1/main (reissued in 1648a72). I’d copied it across with git checkout 2.1 -- bcf/ followed by cp, which followed the symlink and pulled the 2.1 file, so I was running a 2.x BCF against the 1.16.4 driver without realising. With the genuine 1.16 BCF in place (2081 bytes, crc32 0xa80ae47b) the manifest error cleared and the chip came up.

Worth noting the 1.16 Makefile’s install list doesn’t include bcf_boardtype_0807.bin or the mm8108b2-* firmware blobs, so make install leaves them out even though they’re in the tree — that’s how I ended up hand-copying and mixing releases.

On 1.16.4 throughout (kernel, driver, firmware, BCF) the MM8108 initialises cleanly, scans, and completes WPA3-SAE association with a HaLowLink 1. Then it wedges within a few seconds, every time:

wlan1: CTRL-EVENT-CONNECTED - Connection to 94:bb:43:dc:f8:b0 completed
morse_sdio mmc2:0001:2: Command morse_cmd_cfg_qos 11:351 timed out
morse_sdio mmc2:0001:2: morse_mac_ops_conf_tx: morse_cmd_cfg_qos failed -110
morse_sdio mmc2:0001:2: sdio: memcpy_fromio fn=2 0x00008000:72 r=0x00000002 b=0x00170002 (ret:-123)
morse_sdio mmc2:0001:2: morse_yaps_hw_update_status: error reading yaps status registers: -5
...
morse_sdio mmc2:0001:2: Command morse_cmd_rm_if 05:371 timed out
Resetting Morse Chip

After that the interface disappears and every subsequent command times out. A couple of things that might narrow it down:

  • The SDHCI controller reports zero errors throughout — no command timeouts, no CRC errors on either path (/sys/kernel/debug/mmc2/err_stats all zero). So the bus looks electrically clean; the chip just stops answering.
  • I tried default_cmd_timeout_ms=5000. Commands then retry 5.1 s apart instead of 0.6 s and still get nothing, so it isn’t the chip being slow.
  • On one run the first thing to time out was morse_cmd_hw_scan rather than cfg_qos, and I saw Late response for timed out req 0x0044:02a0 have 0x0000:0000 0x002a.
  • Unloading the driver gives mmc mmc2:0001: Runtime PM usage count underflow! followed by mmc2: card 0001 removed, and the card never re-enumerates — only a full power cycle recovers it. There’s also a WARNING: driver morse_sdio did not remove its interrupt handler! on teardown.

Is MM8108 over SDIO expected to work on 1.16.4? I notice the SDIO of_device_id table only lists MM610x in every branch, while the SPI table distinguishes morse,mm610x-spi and morse,mm810x-spi. If 1.17.x is the right place for MM8108 SDIO I’m happy to rebuild onto that.

(Separately, on the 2.0.x/2.1.x oops — faddr2line puts dwcmshc_probe+0x2d0 at sdhci-of-dwcmshc.c:1471, which is err = pltfm_data->init(&pdev->dev, host, priv);. Consistent with the ABI mismatch you suspected. My rebuilt module sizes the function at 0x774 vs the 0x778 in the oops, so the offset may not land identically.)

6

Hi @NimbleMarmot91

Yes the driver is expected ot work for SDIO on 1.16.4. However for the MM8108 I would strongly recommend upgrading as there are substantial improvements. See MM8108 Linux Software Release Notes | Software releases | Morse Micro documentation

The error you are seeing could be a result of not having wake and busy connected. Make sure you are pulling the WAKE line high to prevent the chip from entering sleep mode. Also with this hardware configuration you would benefit from iw dev wlan1 set power_save off to turn of power save from the host side.

7

Thanks, that matches what I found: with enable_ps=0 plus iw dev wlan1 set power_save off, the link is now stable on 1.16.4. I’ll tie WAKE high in the next board revision.

On upgrading: I’d like to move to 2.x, but on CM5 both mm/rpi-6.12.21/mm8108-2.0.x and 2.1.x oops in sdhci_of_dwcmshc during probe (dwcmshc_probe+0x2d0, executing from a data address), so no mmc2 host is created (details in my earlier report). 1.16.x and stock 6.18 don’t have this. Is there a recommended kernel branch or tree for CM5 with the 2.x driver, or a fix for that ABI mismatch?

Thanks for all the help!

8

@NimbleMarmot91 apologies for the delay here. I’m hoping to try replicate your issue on an RPi 5. Just haven’t had a chance to attempt it yet. Will report back when I have more to share on upgrading!