Mmc1: Timeout waiting for hardware interrupt

Finally got it working!

I was testing on a module that didn’t have the reset line connected. Connected the Reset line and now it works as expected!

Now there is still more work to be done optimizing settings etc, but I will start a new thread in case I need help.

Thanks for your support these past few months! Hopefully it will be useful to others in the future as well

4 Likes

@ajudge Do you plan to create a KB article or otherwise summarize your findings from this post?

2 Likes

@masonwardle it’s definitely on the list. Hopefully will form part of a general hardware focused platform porting guide.

I managed to figure out that the card I was using had a hard pull-up on its RESET# line and required a fundamental reset. Simply driving it low then high again before loading the driver resolved my SDIO issues. The way the driver is written the reset-gpios dt prop doesn’t help here as the morse_hw_reset function isn’t called on an sdio_probe.

The device is working fine on an IMX8MP board as long as I use MORSE_SDIO_RW_ADDR_BOUNDARY_MASK=0xffff0004

1 Like

Yes, this is frustrating, but I believe it’s not actually straightforward for the driver itself to do the reset cleanly as it won’t be loaded until it’s detected, and it won’t be detected until the reset has happened. Some options we’ve used in the past are to work around this in user space (as I imagine you’ve done - see our morsechipreset.sh script for an example), or modify your SDIO/MMC driver to toggle any necessary GPIOs before the probe (ideally by specifying them in device tree).

Glad to hear you resolved your issues @tharvey. And thanks again for your earlier contributions to this thread!

As @james.haggerty mentions, performing the reset in the driver probe can upset some mmc host controllers configured with a non-removable device property. We do have a patch floating around to add a reset to the driver if you’re happy to use something like broken-cd to poll for device presence.

There was some internal discussion around using an mmc-pwrseq-simple node to handle this reset instead. There were some quirks with the initial attempts, but I might revisit this again to be certain.