Mmc2: error -110 whilst initialising SDIO card

Hello everybody!

I am currently attempting to use ALFA’s AHM26108D M.2 module (uses Morse Micro MM6108 HaLow chipset) with a NXP I.MX8ULP-EVK. Unfortunately I have been unable to get the module to enumerate.
I am using imx-linux-scarthgap on the EVK

The errors I am running into:
mmc2: SDHCI controller on 298f0000.mmc [298f0000.mmc] using ADMA
mmc2: error -110 whilst initialising SDIO card
mmc2: error -110 whilst initialising SDIO card
mmc2: error -110 whilst initialising SDIO card
mmc2: error -110 whilst initialising SDIO card
mmc2: Failed to initialize a non-removable card

But if I use the module that is provided with the EVK it outputs:
mmc2: SDHCI controller on 298f0000.mmc [298f0000.mmc] using ADMA
mmc2: new ultra high speed SDR104 SDIO card at address 0001

My initial concern was the SDIO voltage from the EVK is 1.8V but the pinout on ALFA’s site states I should be able to use 1.8V or 3.3V based on the VDDIO_SELECT pin. In my use case it is set to 1.8V

I did reach out to ALFA but the limited response I was able to receive led me to believe the device should work with the EVK.

Has anyone been able to successfully use the MM6108 at 1.8V?
Are there any thoughts on what I may need to do differently to get the module to enumerate on this EVK? mmc2: error -110 whilst initialising SDIO card

I wonder if this is related to Mmc1: Timeout waiting for hardware interrupt which has been reproduced on both iMX6 and iMX8 platforms.

The error I am running into seems to be a bit earlier on as the module doesn’t enumerate.
Here is the related dmesg output:

root@imx8ulpevk:~# dmesg | grep -i mmc2 
[    2.367506] mmc2: SDHCI controller on 298f0000.mmc [298f0000.mmc] using ADMA
[    2.484332] mmc2: error -110 whilst initialising SDIO card
[    2.570903] mmc2: error -110 whilst initialising SDIO card
[    2.663105] mmc2: error -110 whilst initialising SDIO card
[    2.756805] mmc2: error -110 whilst initialising SDIO card
[    2.771866] mmc2: Failed to initialize a non-removable card

I did connect the module to a logic analyser as an attempt to provide any additional relevant information. Doing so gave me a slightly different dmesg output ( error -110 no longer appears):

root@imx8ulpevk:~# dmesg | grep -i mmc2
[    2.370909] mmc2: SDHCI controller on 298f0000.mmc [298f0000.mmc] using ADMA
[    2.589836] mmc2: Failed to initialize a non-removable card

Here is a screenshot of the logic analyser capture during the time it attempts to initialize the card as well as a table with the corresponding MM6108 pin:
A0 - Busy GPIO0 - Pin 17
A1 - SDIO_D3 - Pin 25
A2 - SDIO_D2 - Pin 26
A3 - SDIO_D1 - Pin 27
A4 - SDIO_D0 - Pin 29
A5 - SDIO_CMD - Pin 30
A6 - SDIO_CLK - Pin 31

I just noticed that the CMD and CLK traces are identical. We are looking into why.

We found the reason the error -110 no longer appearing was a bridge between SDIO_CMD and SDIO_CLK. After fixing this the error -110 was showing up again. Below is a new capture of just those 2 pins at a higher sample rate.

1 Like

One point of note: the SDIO data lines were still static.

Hello!

Which driver version are you using? This helps me verify what I should be seeing in your logs. 1.12.4?

Has anyone been able to successfully use the MM6108 at 1.8V?

Yes! We have had customers successfully bring up the MM6108 with a 1.8V VDDIO. I don’t believe this will be your problem.

mmc2: error -110 whilst initialising SDIO card

A -110 errno on this platform translates to -ETIMEDOUT. With the timing of the errors in relation to the registration of the host controller driver. I’m suspicious the MM6108 isn’t booting correctly or is possibly held in reset. Are you able to capture the reset line - pin 23 - of the Alfa module?

the SDIO data lines were still static.

Were these traces captured with a Logic Analyzer of fairly high sample rate (>250MS/s)? If so, are you able to export and share the Logic files (.sal) of the early init sequence?

When compared to Mmc1: Timeout waiting for hardware interrupt it doesn’t look like the driver initialisation is getting far enough in the process to send data - I’m not seeing any of the Morse Micro info logs for example. This lack of logging could of course be due to DEBUG not being enabled, printk verbosity, or dynamic debug parameters - if enabled.

More logging would generally be helpful here, including within the mmc host controller driver. Are you able to turn the log level up?

Hi @ajudge

Yes, I am using driver version 1.12.4.

Yes, I’ve included a screen capture, unfortunately I cannot include the capture file as a new user.

I am still working on finding a Logic Analyzer with a higher sample rate and turning the log level up. I will include an update when/if I am able to provide this information.

Hi @rtopham

See if you can attach the logic analyzer files now, I’ve increased permissions for you accordingly.

Is the capture shown one instance of a driver probe event? Or have you captured multiple attempts to insert the Morse driver?

If the former, the RESETN line looks like it is going low mid transaction which would cause the failures you are seeing. Is there something else attached to that line which is causing it to be driven low? Perhaps another peripheral in device tree is configured on that pin?

Feel free to share your device tree config. Happy for you to share the device tree binary as we can decompile that and see the full context of the device configuration.

Hi @ajudge
Thank you for the assistance.

Yes this is just one instance of a driver probe event.

There should not be anything else attached to this line, I have been able to successfully use a different SDIO M.2 module with a different radio.
I have attached my device tree and logic analyzer file.
imx8ulp-mm-files.tar.xz (601.9 KB)

1 Like

Hi @rtopham

Sorry for the delay getting back to you!

Just to confirm, as in your screenshot, in this capture are the signals:
Channel 0: Busy
Channel 1: DAT3
Channel 2: DAT2
Channel 4: DAT1 – (not present in this capture)
Channel 3: DAT0
Channel 5: CMD
Channel 6: CLK
Channel 7: RESET

If so, the reset behaviour is definitely concerning. It’s going low between transactions, which will reset the MM6108. The device tree is fairly innocuous, and has some properties I was expecting to see.

I’ve looked at the hardware design for the iMX 8ULP, and the RESET line is a dedicated reset line running through an I2C attached IO expander.

I’ll get back to you shortly with a specific update about RESET line handling, if anything.


One thing to note, however. The MM6108 does have a quirk where it reports to the host that it supports voltage switch by CMD5 in R4 - when in fact it does not. This is because the MM6108 is strictly an SDIO 2.0 compatible device. As the iMX processors are SDIO 3.0 which has changed the format of the R4 response this host may be trying to effect a CMD11 to trigger a change in voltage.

We apply this patch to our OpenWrt distribution to prevent a host sending CMD5 and skip the voltage switch. I suspect the no-1-8-v devicetree property may do a similar thing, but have not confirmed.

Please try applying the patch above to the kernel. If you need a patch for an alternative kernel version let me know!

A small caveat: we may need to investigate forcing the host to 1.8V if the patch still doesn’t work. I note that the IO signals run directly to the host and level shifting is managed there. Hopefully this can be done via devicetree or a register in the mmc host, if required.

Hi @ajudge
Thank you for the response!

Yes, this is correct. I apologize for not including the labels on that capture.

Are you able to send this patch for kernel version 6.6.36?

See attached patch for kernel 6.6.

0010-sdio_18v_quirk.patch (1.8 KB)

After applying the patch I am still getting the same error as I did before the patch.

For the MM6108 to work with SDIO 3.0 will it need 3.3v? It seems that the IMX8ULP EVK can only supply 1.8v over SDIO.

I have attached a logic analyzer capture from after the patch
ALFA-HaLow-SDIO-Digital-W-Patch2.sal (76.9 KB)

There shouldn’t be any problem using 1.8V for the IO voltage (VDDIO), any issues which do arise will likely come from the host trying to change the voltage. The patches disables the change functionality.

Note however, that VBAT must be 3.0-3.6V.

I would point the problem at this RESET line behaviour:


It could possibly be floating to an indeterminate state which is causing the transitions to show with clock edges. Anything outside of a well defined state is going to prevent the Morse Micro chip from booting.

Can you ensure there is a suitable pull-up resistor to VBAT (3.3V) on this line? Also getting an oscilloscope capture of the reset line may help further.

VBAT_PWR and VBAT_AON measure a steady ~3.278 V on a multimeter.


(Sorry I don’t have permission to attach files)

The reset line is being driven on and off. Is that the driver doing that?

The driver will only pull the configured reset line low on removal. This could be caused by Linux attempting to insert the driver multiple times after a probe failure.

From the trace you’ve provided, the RESET line high voltage level is only 1.8V. It looks like the ALFA M2 module uses an MIC826 which is supplied with a VCC of 3.3V.

These are the input voltage levels of the MIC826

As your reset line is 1.8V, this is under the 0.7Vcc required for an Input high level.

Try adding a pull-up from the RESET GPIO to 3.3V.
If the iMX8 baseboard you are using already has a pull-up to 1.8V you would want to consider removing it.

After providing the RESET GPIO with 3.3V we have been able to get the module to enumerate!
However there are a few caveats:

The module will only enumerate if we don’t update the device tree to the correct line that the reset pin is using. But in this case when the driver is loaded it fails (output included below)

[70181.268722] Morse Micro Dot11ah driver registration. Version 0-rel_1_12_4_2024_Jun_11
[70181.294007] morse micro driver registration. Version 0-rel_1_12_4_2024_Jun_11
[70181.308604] morse_sdio mmc2:0001:2: Device node not found
[70181.314049] morse_sdio mmc2:0001:2: No pin configs found, using defaults...
[70191.178303] mmc2: Timeout waiting for hardware interrupt.
[70191.183673] mmc2: sdhci: ============ SDHCI REGISTER DUMP ===========
[70191.190051] mmc2: sdhci: Sys addr:  0xd39d2000 | Version:  0x00000002
[70191.196427] mmc2: sdhci: Blk size:  0x00000004 | Blk cnt:  0x00000001
[70191.202794] mmc2: sdhci: Argument:  0x149a4004 | Trn mode: 0x00000013
[70191.209164] mmc2: sdhci: Present:   0x01f8820e | Host ctl: 0x00000012
[70191.215534] mmc2: sdhci: Power:     0x00000002 | Blk gap:  0x00000080
[70191.221906] mmc2: sdhci: Wake-up:   0x00000008 | Clock:    0x0000003f
[70191.228277] mmc2: sdhci: Timeout:   0x0000008f | Int stat: 0x00000000
[70191.234652] mmc2: sdhci: Int enab:  0x117f100b | Sig enab: 0x117f100b
[70191.241026] mmc2: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000502
[70191.247396] mmc2: sdhci: Caps:      0x07eb0000 | Caps_1:   0x0000b407
[70191.253766] mmc2: sdhci: Cmd:       0x0000353a | Max curr: 0x00ffffff
[70191.260138] mmc2: sdhci: Resp[0]:   0x00000000 | Resp[1]:  0x00000000
[70191.266514] mmc2: sdhci: Resp[2]:   0x00000000 | Resp[3]:  0x00000000
[70191.272889] mmc2: sdhci: Host ctl2: 0x00000000
[70191.277288] mmc2: sdhci: ADMA Err:  0x00000003 | ADMA Ptr: 0x85228204
[70191.283660] mmc2: sdhci-esdhc-imx: ========= ESDHC IMX DEBUG STATUS DUMP =========
[70191.291148] mmc2: sdhci-esdhc-imx: cmd debug status:  0x3100
[70191.296747] mmc2: sdhci-esdhc-imx: data debug status:  0x32a0
[70191.302432] mmc2: sdhci-esdhc-imx: trans debug status:  0x33a0
[70191.308202] mmc2: sdhci-esdhc-imx: dma debug status:  0x3400
[70191.313800] mmc2: sdhci-esdhc-imx: adma debug status:  0x35b4
[70191.319483] mmc2: sdhci-esdhc-imx: fifo debug status:  0x3680
[70191.325168] mmc2: sdhci-esdhc-imx: async fifo debug status:  0x3750
[70191.331368] mmc2: sdhci: ============================================
[70191.338174] morse_sdio mmc2:0001:2: sdio readl failed 4294967186
[70191.344192] morse_sdio mmc2:0001:2: morse_sdio_reg32_read failed 18446744073709551506
[70191.352015] morse_sdio mmc2:0001:2: morse read chip id failed: -5
[70191.358252] morse_sdio_probe failed. The driver has not been loaded!
[70191.364602] morse_sdio: probe of mmc2:0001:2 failed with error -5

I have also attached captures with the device tree GPIO change and without in hopes that this will provide beneficial information.
mm-captures.tar.xz (10.8 MB)