[U-Boot] [bug report] sunxi: booting from eMMC

[Maxime Ripard]

On Wed, Sep 14, 2016 at 12:05:19PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 13-09-16 13:50, Maxime Ripard wrote:
> >Hi,
> >
> >On Mon, Sep 12, 2016 at 04:47:49PM +0200, Hans de Goede wrote:
> >>On 12-09-16 15:56, Maxime Ripard wrote:
> >>>Hi,
> >>>
> >>>On Mon, Sep 12, 2016 at 01:53:24PM +0200, Ciprian Manea wrote:
> >>>>I'm using a SinA33 dev board (Allwinner a33 SoC) and at the moment
> >>>>I'm trying to boot from the eMMC.
> >>>>
> >>>>But it fails in the following way:
> >>>>
> >>>>
> >>>>*Got the following error at boot time:*
> >>>>*U-Boot SPL 2016.09-rc2-00125-g6e8b42f (Sep 08 2016 - 11:00:46) DRAM: 1024
> >>>>MiB Trying to boot from MMC2 MMC Device 1 not found spl: could not find mmc
> >>>>device. error: -19 SPL: failed to boot from all boot devices ### ERROR ###
> >>>>Please RESET the board ###*
> >>>
> >>>So I've been on the same issue for the last couple of days.
> >>>
> >>>Since that board is already supported, adding support for the eMMC
> >>>basically came down to that patch on top of 2016.09-rc2.
> >>>
> >>>http://code.bulix.org/kcgxri-106037?raw
> >>>
> >>>(Quite hackish, the 8-Bits part being a separate issue that would need
> >>>to be addressed somehow).
> >>>
> >>>However, it doesn't work, neither when flashing u-boot on the eMMC
> >>>itself (where there's a timeout error in the SPL) nor when trying to
> >>>access the eMMC from a U-Boot loaded from the (external) SD.
> >>>
> >>>In the latter case, even mmc dev 1 fails silently.
> >>>
> >>>I traced that down to the mmc_switch here:
> >>>http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/mmc.c#l530
> >>>
> >>>Which fails with ETIMEDOUT, and more specifically, it's the call to
> >>>mmc_rint_wait here
> >>>http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/sunxi_mmc.c#l383
> >>>that times out.
> >>>
> >>>Increasing the timeout value (to 10000) doesn't really change
> >>>anything. I guess this is also the reason why we had a timeout error
> >>>in the SPL.
> >>>
> >>>This eMMC works fine in Linux, with the same muxing (and I guess the
> >>>earlier commands wouldn't be successful if the muxing or power was not
> >>>set up appropriately). So I'm kind of running out of ideas on what
> >>>could be the root cause of this.
> >>>
> >>>Hans, any ideas?
> >>
> >>Maybe the emmc needs external pull-ups ? I don't remember if u-boot
> >>always enables those or not ...
> >
> >So I pushed this a bit more, and it seems like commenting the call to
> >mmc_change_freq makes everything just work.
> >
> >Reading the JEDEC spec, it looks like when you switch to high speed,
> >you also need to change the controller clock rate, that u-boot doesn't
> >seem to do at the moment, which obviously will fail, since the
> >controller will be stuck at the former rate, while the eMMC would be
> >switched.
> >
> >If I comment mmc_change_freq, everything works.
> 
> Hmm, I'm pretty sure the u-boot sunxi mmc code
> does properly change the clock, see mmc_set_mod_clk() in
> drivers/mmc/sunxi_mmc.c
>
> This will switch to the right PLL, etc. So there likely is
> something else going on making things not work at higher
> speeds.

Yep, I noticed that. However, what confuses me more is that the
command seems to be sent here:
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/mmc.c#l530

And set_ios is being called after we check that everything
works. Linux for example calls set_ios right after switching
http://lxr.free-electrons.com/source/drivers/mmc/core/mmc.c#L965

> Maybe we need a higher driver strenghts at the mmc io pins, or maybe
> we've a completely unrelated issue ?

I've tested that already. It doesn't change the outcome.

> I'm pretty sure that the eMMC's on A20 devices work fine in 50MHZ
> (SDR) mode.

What emmc was that? Did it support HS? Was it considered an SD (and
went through sd_change_freq), or an MMC?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160919/30f2e7cf/attachment.sig>