From: Christian Loehle <christian.loehle@arm.com>
To: Tim Harvey <tharvey@gateworks.com>, u-boot <u-boot@lists.denx.de>,
Peng Fan <peng.fan@nxp.com>,
Jaehoon Chung <jh80.chung@samsung.com>,
Linux MMC List <linux-mmc@vger.kernel.org>,
Ulf Hansson <ulf.hansson@linaro.org>
Subject: Re: obscure microsd detection issue between U-Boot and kernel
Date: Mon, 3 Jun 2024 09:18:40 +0100 [thread overview]
Message-ID: <e0f38bc9-bcc2-4476-a5d4-4f2efaebc0c1@arm.com> (raw)
In-Reply-To: <CAJ+vNU3Ns0RVtROcChGAhfO=XbpnzwQv1SehexbgHX6ST6-Piw@mail.gmail.com>
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.
next prev parent reply other threads:[~2024-06-03 12:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-31 20:47 obscure microsd detection issue between U-Boot and kernel Tim Harvey
2024-06-03 8:18 ` Christian Loehle [this message]
2024-06-03 21:28 ` Tim Harvey
2024-06-04 7:47 ` Christian Loehle
2024-06-04 8:14 ` Michael Walle
2024-06-20 16:48 ` Tim Harvey
2024-06-20 18:46 ` Christian Loehle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e0f38bc9-bcc2-4476-a5d4-4f2efaebc0c1@arm.com \
--to=christian.loehle@arm.com \
--cc=jh80.chung@samsung.com \
--cc=linux-mmc@vger.kernel.org \
--cc=peng.fan@nxp.com \
--cc=tharvey@gateworks.com \
--cc=u-boot@lists.denx.de \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox