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 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
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.
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?
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.
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.
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)
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.
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.
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.
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)
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)
