obscure microsd detection issue between U-Boot and kernel

[Tim Harvey]

On Tue, Jun 4, 2024 at 1:14 AM Michael Walle <michael at walle.cc> wrote:
>
> On Tue Jun 4, 2024 at 9:47 AM CEST, Christian Loehle wrote:
> > On 6/3/24 22:28, Tim Harvey wrote:
> > > On Mon, Jun 3, 2024 at 1:18 AM Christian Loehle
> > > <christian.loehle at 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.
>
> I can second that. And also keep in mind that the actual supply
> voltage must be below that threshold. Thus, the power-off time also
> depends on the capacitance on that supply line after the power load
> switch. There are switches with dedicated output discharge circuits
> built-in.
>
> That being said, from my experience there are cards which will work
> when switching back from 1V8 to 3V3 signalling and some don't. I
> haven't digged deeper into that topic, though.
>
> -michael
>
> > 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
>

Thanks for both of your responses here!

I have a situation where I can re-create a problem switching from 1.8V
back to 3.3V with a specific card on a board that has ESD protection
between the IMX8MM host and the microSD connector (Semtech
ECLAMP2410P.TCT [1]) but works just fine on a previous revision of
that same PCB that does not have the ESD protection added. Boards with
proper ESD protection are the first time I've seen this issue occur.
Does this make sense at all?

I believe that the MMC device is 'reset' via a series of CLK cycles
with CMD/DAT non-asserted so I'm having a difficult time understanding
how this wouldn't work if the host has been reset to 3.3V.

Best Regards,

Tim
[1] https://www.semtech.com/products/circuit-protection/esd-emi-filter-devices/eclamp2410p