Showing results for 
Search instead for 
Did you mean: 
Registered: ‎05-18-2018

mmc1: Timeout waiting for hardware cmd interrupt.

Here's an issue encountered where we have worked around the problem, but the larger issue remains and should be addressed in FSBL and possibly the tooling between PCW and FSBL.

We boot from mmc0 (eMMC), jump from FSBL directly to linux. mmc1 is an accessory card. On most of our systems, the mmc1 would fail with


[   10.205936] mmc1: Timeout waiting for hardware cmd interrupt.
[   10.205945] mmc1: sdhci: ============ SDHCI REGISTER DUMP ===========
[   10.205954] mmc1: sdhci: Sys addr:  0x00000000 | Version:  0x00001002
[   10.205957] mmc1: sdhci: Blk size:  0x00000000 | Blk cnt:  0x00000000
[   10.205960] mmc1: sdhci: Argument:  0x00000000 | Trn mode: 0x00000000
[   10.205964] mmc1: sdhci: Present:   0x01f70001 | Host ctl: 0x00000001
[   10.205967] mmc1: sdhci: Power:     0x0000000e | Blk gap:  0x00000080
[   10.205970] mmc1: sdhci: Wake-up:   0x00000000 | Clock:    0x0000fa03
[   10.205973] mmc1: sdhci: Timeout:   0x00000000 | Int stat: 0x00000000
[   10.205977] mmc1: sdhci: Int enab:  0x00ff0003 | Sig enab: 0x00ff0003
[   10.205980] mmc1: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
[   10.205983] mmc1: sdhci: Caps:      0x31e8c881 | Caps_1:   0x00002007
[   10.205986] mmc1: sdhci: Cmd:       0x00000000 | Max curr: 0x00000000
[   10.205989] mmc1: sdhci: Resp[0]:   0x00000000 | Resp[1]:  0x00000000
[   10.205992] mmc1: sdhci: Resp[2]:   0x00000000 | Resp[3]:  0x00000000
[   10.205995] mmc1: sdhci: Host ctl2: 0x00000000
[   10.205999] mmc1: sdhci: ADMA Err:  0x00000000 | ADMA Ptr: 0x0000000000000000
[   10.206002] mmc1: sdhci: ============================================

The key here is that the CLOCK_CONTROL register is missing bit 2 (0x0000fa03) which should be set for the clock to be visible on the bus.

The problem comes from the fact that in our design (PCW), this controller is configured with the optional Card Detect pin as not used. In our design, the pin is used as a GPO. Up until recently, it was unclaimed in linux so it stayed as input. This wasn't supposed to matter until our development catches up to this pin and properly configures it as output.

Regardless of what anyone does or doesn't do with the pin though, this FSBL line should definitely not to this unconditionnaly:

I have lost 2 weeks on this issue mainly because I wasn't familiar with MMC/SD/SDIO and also because sdhci.c wasn't reporting the error of the bit not sticking. I intend to submit a patch for sdhci to help future integrators. But the problem in FSBL is more complicated and out of my reach.

For the moment, I have created a patch and a bbappend in my layer to apply it, which simply removes the write to IOU_SLCR_SD_CDN_CTRL line just before the handoff.