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

[Hans de Goede]

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. Maybe we need a higher driver strenghts at the
mmc io pins, or maybe we've a completely unrelated issue ?

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

Regards,

Hans