[U-Boot] [bug report] sunxi: booting from eMMC
Hi,
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 ###*
More info in the linux-sunxi mailing thread:
https://groups.google.com/forum/#!topic/linux-sunxi/U4t-0VcDxLU%E2%80%8B
Thanks
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?
Thanks, Maxime
Hi,
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 ...
I've not tried booting from eMMC on A33 boards (-ENOHARDWARE) but it does work on A13 and A20 boards (last time I tried).
Regards,
Hans
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.
I've not tried booting from eMMC on A33 boards (-ENOHARDWARE) but it does work on A13 and A20 boards (last time I tried).
I'm guessing this is more about what rates and modes are supported, rather than the actual SoC.
Maxime
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
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
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?
Thanks, Maxime
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
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
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
Hi Jaehoon,
On Tue, Sep 20, 2016 at 08:10:52AM +0900, Jaehoon Chung wrote:
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.
So I've been able to test this, and we indeed not hit the timeout but the error bit is set, with 0x40.
Maxime
participants (4)
-
Ciprian Manea -
Hans de Goede -
Jaehoon Chung -
Maxime Ripard