HI,
On 19-09-16 15:17, 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.
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?
Here is what "mmc info" in u-boot says on my UTOO P66 tablet (A13)
with 4G eMMC (manually transcribed, no serial console):
Device: SUNXI SD/MMC
Manufacturer ID: 70
OEM: 100
Name: MMC04
Tran Speed: 52000000
Rd Block Len: 512
MMC version 4.4.1
High Capacity: Yes
Bus-width: 4-bit
<bunch of sizes>
And here is /sys/kernel/debug/mmc1/ios under linux:
clock: 52000000 Hz
vdd: 21 (3.3 ~ 3.4 V)
bus mode: 2 (push-pull)
chip select: 0 (don't care)
power mode: 2 (on)
bus width: 3 (8 bits)
timing spec: 1 (mmc high-speed)
signal voltage: 0 (3.30 V)
driver type: 0 (driver type B)
HTH,
Regards,
Hans
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
