Hi,
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. 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.
Yeah, sorry, I was missing the mmc_set_clock call in that function, that ends up calling mmc_set_mod_clk.
I'll look more into it, it might be just a matter of phases to adjust.
Maxime