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)