Increasing stabilization time in sunxi_mmc_core_init

[Da Xue]

On Thu, Jul 21, 2022 at 11:14 AM Jernej Škrabec
<jernej.skrabec at gmail.com> wrote:
>
> Hi!
>
> Dne četrtek, 21. julij 2022 ob 13:28:59 CEST je Andre Przywara napisal(a):
> > On 21/07/2022 12:03, Da Xue wrote:
> >
> > Hi Da,
> >
> > > Users were reporting non-boot on our H5 boards (ALL-H3-CC-H5). u-boot
> > > gets stuck in SPL with this message for SD/eMMC respectively.
> > >
> > > Trying to boot from MMC1 or Trying to boot from MMC2
> > >
> > > I tested about 20 MicroSD cards from different brands and some were
> > > happy and some were not. Increasing the udelay to 8-10ms in
> > > drivers/mmc/sunxi_mmc.c sunxi_mmc_core_init after reset seems to fix
> > > the issue for the MicroSD cards.
> >
> > That's interesting, thanks for the report. I don't remember hearing of
> > issues with MMC before, at least not in the SPL.
>
> I certainly experienced this issue on board in question. I vaguely remember
> asking about this issue on IRC. I also tried all sorts of tweaks, but it never
> occured to me that mmc reset timeout would be too short.
>
> Da, how did you find this?

Someone on the Armbian forum posted that they had the same problem
with eMMC so I got suspicious. I scoped the MicroSD clock line and
realized the frequency goes high and then drops to very low as if it
never found the card.
I had a hunch it was a stabilization delay and got lucky.

>
> I only test one other H5 board occasionally, namely OrangePi PC2, but I never
> observed such issue there. I always needed about 5 attempts to boot ALL-H3-CC-
> H5 board, but once it's cold booted, warm boots always succeed.

I had run into this too so it didn't make any sense. I tried 5ms and
it helped on some cards but not others.
I know the Orange Pis do not have the series resistor for ESD
protection of the SD GPIOs but that shouldn't affect this.
So...who knows?

>
> Best regards,
> Jernej
>
> > It's a bit odd that waiting after the *controller* reset should affect
> > SD cards, and 1ms seems plenty for just the reset.
> > I just checked and at least the SOFT_RESET and FIFO_RESET bits are self
> > clearing. Can you try to use wait_for_bit_le32() to wait for those parts
> > to finish? See sun8i_emac_eth_start() for an example.

I tested some more and here's the 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
Given this, I don't think it's an issue with the bit set delays. Might
need more than 10ms even. I didn't change the udelay in probe.

> >
> > And since you mentioned it's card related: can you check whether the
> > delay is actually needed somewhere else, later? At some point where we
> > wait to the card to response, for instance?
> >
> > I am not against taking this patch, if it fixes problems for you, but
> > just want to avoid that it papers over other issues.
> >
> > Cheers,
> > Andre
> >
> > > Author: Da Xue <da at libre.computer>
> > > Date:   Wed Jul 20 19:11:55 2022 -0400
> > >
> > >      sunxi: raise stabilization time for mmc from 1ms to 8ms
> > >
> > > diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
> > > index 1bb7b6d0e9..499e057725 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(8000);

This might need to be even higher. Like 20ms.

> > >
> > >          return 0;
> > >
> > >   }
> > >
> > > I don't know the implications of this change so I am seeking feedback.
> > > Are other boards having this issue as well or is it specific to our
> > > hardware?
> > >
> > > Best,
> > > Da
>