Hi, 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? 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. >>>>> >>>>> 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? Best Regards, Jaehoon Chung > > 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 > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot