obscure microsd detection issue between U-Boot and kernel

[Christian Loehle]

On 5/31/24 21:47, Tim Harvey wrote:
> Greetings,
> 
> I'm seeing an issue on an imx8mm board (imx8mm-venice-gw73xx) where
> for a specific set of microsd cards if I have accessed the microsd in
> U-Boot with UHS/1.8V the kernel will not recognize that microsd when
> scanning.
> 
> The issue does not occur with all microsd cards but seems to appear
> with a large sample size of a specific card/model (Kingston SDC32 32GB
> SDR104 card). I do not see a signal integrity issue on the scope.
> 
> Instrumenting the kernel the issue is that the host reports a CRC
> error as soon as the first mmc_send_if_cond call which occurs in
> mmc_rescan_try_freq.
> 
> I can avoid the issue by either not accessing the microsd in U-Boot or
> by disabling UHS/1.8V mode in U-Boot therefore what I think is
> happening is that U-Boot leaves the card in UHS/1.8V signalling mode
> and when the kernel scans it sets the voltage back to 3.3V
> standard/default and default timings then issues its clock cycles to
> 'reset' the card and the card does not recognize the reset. I'm
> wondering if this is because the reset is done via clock cycles after
> the kernel has set the I/O voltage back to 3.3V when perhaps the card
> is still in 1.8V mode (although I don't see how that would cause an
> issue)?

It will cause an issue for many cards and might break some cards.

> 
> Is there some sort of MMC 'reset' I can/should do in U-Boot before
> booting the kernel? Has anyone encountered anything like this before?

There is no 'switching back' to 3.3V signalling from UHS 1.8V.
The only way this can be done is therefore a full power-off.
Is that done correctly for your system?
AFAIR spec dictates 500ms of <0.5V on VCC. Note that  driving CLK/signal
lines can also sustain the card somewhat, as leakage is only limited
within operating voltage.