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

[Maxime Ripard]

Hi Jaehoon,

On Tue, Sep 20, 2016 at 08:10:52AM +0900, Jaehoon Chung wrote:
> On 09/19/2016 10:17 PM, Maxime Ripard wrote:
> > 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.
> 
> timeout_msecs is expired or hit SUNXI_MMC_RINT_INTERRUPT_ERROR_BIT?
> If hit ERROR_BIT, did you check which bit is set?

I haven't check, I'll look (next week though, I'm at a conference and
away from that board).

> If error is occurred when mmc_change_freq() is running, cid/ext_csd
> register have already read.
>
> It means the controller read the something from eMMC card.

It really is the next command right after the switch that fails, it
really feels like that switch changes the timings of the card without
changing the one from the host.

> 
> >>>>>
> >>>>> 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
> 
> If then..i guess that it's possible to set the initial clock as
> higher clock than 400KHz.  Did you check this?

I'll try. But wouldn't that introduce some compatibility issues of its
own?

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/20160921/b98cf0f1/attachment.sig>