On 6/3/24 22:28, Tim Harvey wrote:
On Mon, Jun 3, 2024 at 1:18 AM Christian Loehle christian.loehle@arm.com wrote:
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.
Hi Christian,
Are you saying the only way to properly reset from 1.8V is to have a VDD supply on the microSD card that can be turned off before booting to Linux? We have never had that before and never encountered something like this.
Yes, the only safe way to use UHS-I really anyway. You could disable UHS for u-boot but that still leaves (potentially) problematic warm-reboots of the board. Having a (software-controlled) switchable regulator on SD VCC is pretty common for this reason and you should be able to find it in most dts for host controllers with sd-uhs-* property. I'm afraid that the relevant spec section isn't available in the simplified version.
Kind Regards, Christian