All of lore.kernel.org
 help / color / mirror / Atom feed
From: Da Xue <da@libre.computer>
To: "Jernej Škrabec" <jernej.skrabec@gmail.com>
Cc: u-boot@lists.denx.de, Andre Przywara <andre.przywara@arm.com>
Subject: Re: [PATCH] sunxi-mmc: increase stabilization delay from 1ms to 20ms
Date: Fri, 22 Jul 2022 18:40:30 -0400	[thread overview]
Message-ID: <CACqvRUbZiBovgePQwyGPx=Dfg5EVDhc2H042-5NT+wYT3eM8XQ@mail.gmail.com> (raw)
In-Reply-To: <2048327.bB369e8A3T@jernej-laptop>

On Fri, Jul 22, 2022 at 1:56 PM Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
>
> Dne petek, 22. julij 2022 ob 18:55:14 CEST je Andre Przywara napisal(a):
> > On 21/07/2022 23:08, Da Xue wrote:
> >
> > Hi,
> >
> > > Some users experienced problems booting u-boot from SPL hanging here:
> > >
> > > Trying to boot from MMC1 or Trying to boot from MMC2
> > >
> > > This seems to occur with both MicroSD and eMMC modules on ALL-H3-CC.
> > > Increasing the delay after mmc reset fixes these boot problems.
> > > Some MicroSD cards are impacted more than others so it is possible that
> > > MicroSD internals need time to stabilize. Below is some failure data.
> > >
> > > sandisk ultra   64gb 9/20 with 1ms,  20/20 with 10ms
> > > sandisk ultra   16gb 2/20 with 1ms,  20/20 with 10ms
> > > sandisk extreme 16gb 6/20 with 10ms, 20/20 with 20ms
> > >
> > > A quick comparison of schematics show series resistors for ESD
> > > protection on the MicroSD GPIOs not present on all H3/H5 boards.
> > > It is not known if this is related to the issue.
> > >
> > > This patch adds a fixed 20ms delay to mmc init to mitigate the problem.
> > > If boot time optimization is required and the platform does not require
> > > the delay. The delay can be replaced with:
> > >
> > > writel(SUNXI_MMC_GCTRL_RESET, &priv->reg->gctrl);
> > > if (wait_for_bit_le32( &priv->reg->gctrl,
> > > SUNXI_MMC_GCTRL_RESET, false, 20, false)) {
> > > printf("%s: Timeout\n", __func__);
> > > return -ETIMEDOUT;
> > > }
> >
> > So what about adding this for everyone (we should have it regardless) then?

I think it would be good to add for everyone. This only happens in SPL
so the impact is limited in terms of time cost.

> >
> > And then have an extra Kconfig option to specify an extra delay, and
> > define this only in your board defconfig? Because IIUC this is specific
> > to your board?

I only have my boards to test. I'm sure there are other devices that have the
same issue. I don't think it's exclusive to our boards.

> >
> > And as I mentioned: it looks odd to have this here and have it fixing
> > your SD card problems:
> > - The soft reset should reset just the internal controller logic (MMC
> > state machine and FIFOs), this shouldn't affect cards. IIUC, nothing
> > should happen on the MMC *pins* because of this operation.
> > - Why isn't this a problem for U-Boot proper, and Linux, FWIW?
>
> As I said before, I have issue only at cold boot in SPL. Once I pass this
> point, it works all the time, even if rebooted. Why is that so it's unclear.
>
> Thinking about this a bit, I have another question. How is it possible that
> BROM manages to read SD card just fine and loads SPL beforehand? Is it using
> lower speed? It also couldn't be power issue, since card must have been
> properly powered up by BROM...

Is the bootrom using SPI mode on first boot? If that is the case, a transition
would take time and may explain the necessity of this.

>
> Best regards,
> Jernej
>
> >
> > Cheers,
> > Andre
> >
> > > Signed-off-by: Da Xue <da@libre.computer>
> > > ---
> > >
> > >   drivers/mmc/sunxi_mmc.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
> > > index 1bb7b6d0e9..f7942b69ce 100644
> > > --- a/drivers/mmc/sunxi_mmc.c
> > > +++ b/drivers/mmc/sunxi_mmc.c
> > > @@ -297,7 +297,7 @@ static int sunxi_mmc_core_init(struct mmc *mmc)
> > >
> > >    /* Reset controller */
> > >    writel(SUNXI_MMC_GCTRL_RESET, &priv->reg->gctrl);
> > >
> > > - udelay(1000);
> > > + udelay(20000);
> > >
> > >    return 0;
> > >
> > >   }
>
>
>
>

      reply	other threads:[~2022-07-22 22:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-21 22:08 [PATCH] sunxi-mmc: increase stabilization delay from 1ms to 20ms Da Xue
2022-07-22 16:55 ` Andre Przywara
2022-07-22 17:56   ` Jernej Škrabec
2022-07-22 22:40     ` Da Xue [this message]

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='CACqvRUbZiBovgePQwyGPx=Dfg5EVDhc2H042-5NT+wYT3eM8XQ@mail.gmail.com' \
    --to=da@libre.computer \
    --cc=andre.przywara@arm.com \
    --cc=jernej.skrabec@gmail.com \
    --cc=u-boot@lists.denx.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.