Hardware: Custom Raspberry Pi 4 HAT built around the Seeed Studio WM-MM6108 module (Quectel FGH100M-H, MM6108 chip), SPI interface, EKH01-SPI-equivalent wiring. Driver: SDK V1_16_4 (0-rel_1_16_4_2025_Sep_18).
The problem: On this exact hardware, HaLow works perfectly under OpenWrt (kernel 5.15.167). Porting to plain Debian/Ubuntu on the same physical board — driver builds and loads, chip detection succeeds, firmware/BCF load from disk fine, but the first bulk write to the chip (cmd53_write fn=2 addr=0x00000000 count=10, the start of BCF/firmware upload) is never acknowledged:
data_ack window: ff ff ff ff ff ff ff ff e5 07 ff
morse_spi_find_data_ack failed
morse_spi_cmd53_write failed
morse_spi_dm_write failed -71
…
morse_firmware_init failed: -5
morse_spi_probe failed. The driver has not been loaded!
What we’ve ruled out (14 independently tested variables, same exact failure every time):
4 different kernel builds: our own 6.12.96 and rpi-5.15.y, plus Morse’s own official branches — both the mainline-based linux repo and the RPi-Foundation-based rpi-linux repo (mm/rpi-6.12.21/mm6108-2.0.x)
Firmware/BCF file contents (md5-identical to the OpenWrt image)
Devicetree pin/GPIO assignments, cross-checked against the board’s own pinout docs
MM_RESET pulse presence (A/B tested)
SPI0 core clock frequency (confirmed identical live, 500000992 Hz)
CS GPIO toggling correctness (patched and logged live — commanded value and readback match on every transition)
The exact compiler/toolchain — cross-built with OpenWrt’s own musl-gcc 12.3.0, confirmed byte-identical /proc/version string to the working reference
Full technical report (patches applied, exact configs, byte dumps) available on request. At this point everything observable from software matches between the working and failing systems — looking for anything from your side (undocumented sequencing/timing requirement, known SPI quirk) that isn’t in the public SDK.
Are you able to provide a logic analyser trace of the SPI lines, including the RESET line, from boot to failure?
I suspect this is a timing issue whereby the chip hasn’t come out of RESET when CMD53 starts.
There have been some improvements in this area in the 2.0 drivers, and more to come in future releases.
Thanks for the quick response, and for the pointer to mm6108-2.0.1 — much appreciated.
One clarification on the RESET-timing hypothesis, since it’s directly addressed in our original report: finding #5 already A/B-tested the MM_RESET (GPIO5) pulse itself — same power-cycle, same everything, only varying whether the driver issues the reset pulse before insmod at all. Result was byte-for-byte identical failures with and without the pulse. On top of that, the actual failure point (cmd53_write fn=2 addr=0x00000000, the first BCF bulk write) only happens after several already-successful SPI exchanges with the chip — CMD63 training, chip-ID read via CMD52, and set_address_base all complete correctly first. So by the time the failing write happens, the chip has clearly already been responding correctly over SPI for a while, which doesn’t fit a “still coming out of reset” explanation as we currently understand it.
That said, we did pull mm6108-2.0.1 and isolated just the settle-delay change (mdelay(80) after morse_hw_reset() in morse_spi_reset(), matching your commit) as a patch on top of our 1.16.4 base, and we’re happy to test it on real hardware regardless — cheap to try even though we don’t expect it to change the outcome given finding #5.
We don’t currently have a logic analyzer on hand. If that’s genuinely the only way to make further progress here, let us know and we’ll source one (even a low-cost USB one) and capture RESET + all four SPI lines from power-up through the failing cmd53_write. In the meantime, is there anything in the driver/chip internals around that specific address-0 bulk write that could produce a clean all-0xFF (bus-idle) response after several prior operations already succeeded — e.g. a chip-side buffer/DMA setup step between set_address_base and the first bulk write that isn’t visible from the host side?