mmc erase fails from U-Boot command line

I have the need to erase our eMMC from U-Boot on our custom board due to a hard wired boot up configuration. Our design is based on the Freescale i.MX6Q SabreSD Board reference design. The bottom line is the U-Boot command "mmc erase" is failing with the error "Timeout waiting for DAT0 to go high!". Here's a list of the U-Boot commands issued and the result of each so you can see what is going on.
----------------------------------------
=> mmc list
FSL_SDHC: 0
FSL_SDHC: 1 (SD)
FSL_SDHC: 2 (eMMC)

=> mmc dev 2
switch to partitions #0, OK
mmc2(part 0) is current device

=> mmc info
Device: FSL_SDHC
Manufacturer ID: 45
OEM: 100
Name: SEM08
Tran Speed: 52000000
Rd Block Len: 512
MMC version 4.4.1
High Capacity: Yes
Capacity: 7.4 GiB
Bus Width: 8-bit
Erase Group Size: 512 KiB
HC WP Group Size: 16 MiB
User Capacity: 7.4 GiB WRREL
Boot Capacity: 2 MiB ENH
RPMB Capacity: 128 KiB ENH

=> mmc erase 0 0x400
MMC erase: dev # 2, block # 0, count 1024 ...
Timeout waiting for DAT0 to go high!
mmc erase failed
0 blocks erased: ERROR
----------------------------------------

Any insight on this issue is greatly appreciated.
Thanks, Cliff

This issue is reproducible on Freescale's SABRESD on both SD card and eMMC with v2015.04. The issue has been there always, I believe.
Apparently the command erases the first block, but the operation returns an error, so it aborts and it doesn't continue erasing futher blocks.

I opened a similar thread a while ago:
http://lists.denx.de/pipermail/u-boot/2015-June/215912.html

Hi Hector and Cliff,

Quoted 6 lines · Hector Palacios

This issue is reproducible on Freescale's SABRESD on both SD card and eMMC with v2015.04. The issue has been there always, I believe. Apparently the command erases the first block, but the operation returns an error, so it aborts and it doesn't continue erasing futher blocks.

I opened a similar thread a while ago:
http://lists.denx.de/pipermail/u-boot/2015-June/215912.html

I am running mainline U-boot on a mx6qsabresd and it works fine here:

=> mmc dev 2
switch to partitions #0, OK
mmc2(part 0) is current device
=> mmc erase 4000 1000

MMC erase: dev # 2, block # 16384, count 4096 ... 4096 blocks erased: OK =>

Could it be a silicon revision issue?
My CPU is i.MX6Q rev1.2.

Quoted 2 lines · Hector

Could it be a silicon revision issue?
My CPU is i.MX6Q rev1.2.

I will try to test this on other sabresd boards next week.

Hi Hector,

Quoted 3 lines · Fabio Estevam

On Fri, Nov 13, 2015 at 10:26 AM, Palacios, Hector <[email protected]> wrote:

Quoted 4 lines

Quoted 2 lines

Could it be a silicon revision issue?
My CPU is i.MX6Q rev1.2.

I will try to test this on other sabresd boards next week.

I tested this on other mx6qsabresd board I have and I could see the error.

The board that failed is revC2

Quoted 11 lines · Fabio Estevam

Hi Hector,

Quoted 7 lines · Fabio Estevam

Quoted 2 lines · Hector

Could it be a silicon revision issue?
My CPU is i.MX6Q rev1.2.

I will try to test this on other sabresd boards next week.

Quoted 3 lines

I tested this on other mx6qsabresd board I have and I could see the error.

The board that failed is revC2

Boards revC2 and revC4 failed. (Both are TO1.2)

Board revB (with TO1.1) works fine.

I've also recently seen this on two different custom boards. Both are running i.MX6Q TO1.2 and both are using eMMC from Micron.

The code which is generating the error message:

        http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/fsl_esdhc.c;h=c5054d66bdcda029f0485958c87bd5154ccee591;hb=HEAD#l390

Seems to refer to an errata for the i.MX35 (ENGcm03648):
http://cache.freescale.com/files/dsp/doc/errata/IMX35CE.pdf

I don't see any reference to the errata in the i.MX6 docs.

Ignoring the error (removing the return statement) seems to leave things in a workable state, so I suspect the problem isn't with an insufficient timeout.

Hi Eric,

Quoted 2 lines · Eric Nelson

I've also recently seen this on two different custom boards. Both are running i.MX6Q TO1.2 and both are using eMMC from Micron.

One colleague of mine tested eMMC erasure on a mx6qsabresd revC5 board with a eMMC from Micron and it worked fine.

So far I see:

revB and revC5: works
revC2 and revC4: don't work

Quoted 9 lines

The code which is generating the error message:

        http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/fsl_esdhc.c;h=c5054d66bdcda029f0485958c87bd5154ccee591;hb=HEAD#l390

Seems to refer to an errata for the i.MX35 (ENGcm03648):
http://cache.freescale.com/files/dsp/doc/errata/IMX35CE.pdf

I don't see any reference to the errata in the i.MX6 docs.

This piece of code came from:
7a5b80297bc6cef ("mmc: fsl_esdhc: Poll until card is not busy anymore")

Yes, ENGcm03648 is not listed in mx6 errata document.

Quoted 3 lines

Ignoring the error (removing the return statement) seems to leave things in a workable state, so I suspect the problem isn't with an insufficient timeout.

May I see your change, please?

Sure. It's a hack, but shows where we're hitting the problem (with the stop command).

We haven't been using the "mmc erase" command, but see this when using ums to program eMMC.

Hi Eric,

Quoted 5 lines · Eric Nelson

Sure. It's a hack, but shows where we're hitting the problem (with the stop command).

We haven't been using the "mmc erase" command, but see this when using ums to program eMMC.

Ok, applied your patch, but still get:

=> mmc erase 4000 1000

MMC erase: dev # 2, block # 16384, count 4096 ... Timeout waiting for DAT0 to go
high!
mmc erase failed
0 blocks erased: ERROR
=>

You're hitting the block from a different path than we are and it will be tomorrow before I can get an offending board on my desk.

What happens if you "#if 0" around this block?

http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/fsl_esdhc.c;h=c5054d66bdcda029f0485958c87bd5154ccee591;hb=HEAD#l390

Do you know which command is failing? It should be one of these:
MMC_CMD_ERASE_GROUP_START MMC_CMD_ERASE_GROUP_END
MMC_CMD_ERASE

http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/mmc_write.c;h=7aea7e943b9e05c8aa537653f4ae8878ecb1b04b;hb=HEAD#l17

I think you can instrument and find out using this:

drivers/mmc/mmc.c +0 -0

index 53084a7..8f5d9e1 100644

On Wed, Dec 2, 2015 at 5:28 PM, Eric Nelson <[email protected]> wrote:

Quoted 6 lines

drivers/mmc/mmc.c +0 -0

index 53084a7..8f5d9e1 100644

drivers/mmc/mmc.c int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd · line 112

Quoted 8 lines

drivers/mmc/mmc.c +3 -0

@@ -105,6 +105,9 @@ int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
 *cmd, struct mmc_data *data)
 #else
        ret = mmc->cfg->ops->send_cmd(mmc, cmd, data);
 #endif
+       if (ret)
+               printf("error %d from CMD_SEND:%d\n", ret, cmd->cmdidx);
+
        return ret;

Applying this change on top of head I get:

=> mmc erase 4000 1000

MMC erase: dev # 2, block # 16384, count 4096 ... Timeout waiting for DAT0 to go
high!
error -19 from CMD_SEND:38
mmc erase failed
0 blocks erased: ERROR

How easy is this for you to reproduce?

Hi Fabio,

Quoted 2 lines · Fabio Estevam

On Wed, Dec 2, 2015 at 5:28 PM, Eric Nelson <[email protected]> wrote:

...

Quoted 17 lines

Quoted 6 lines

drivers/mmc/mmc.c +0 -0

index 53084a7..8f5d9e1 100644

drivers/mmc/mmc.c int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd · line 112

Quoted 8 lines

drivers/mmc/mmc.c +3 -0

@@ -105,6 +105,9 @@ int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
 *cmd, struct mmc_data *data)
 #else
        ret = mmc->cfg->ops->send_cmd(mmc, cmd, data);
 #endif
+       if (ret)
+               printf("error %d from CMD_SEND:%d\n", ret, cmd->cmdidx);
+
        return ret;

Applying this change on top of head I get:

Quoted 7 lines

=> mmc erase 4000 1000

MMC erase: dev # 2, block # 16384, count 4096 ... Timeout waiting for DAT0 to go
high!
error -19 from CMD_SEND:38
mmc erase failed
0 blocks erased: ERROR

How easy is this for you to reproduce?

I'm only seeing the error sporadically, which makes it difficult to test.

I've figured out a way to repeat this on my machine.

If I write 0xff's to the eMMC blocks, then issue an erase for the same, I get the problem with each MMC_ERASE command.

I've also found something that fixes the issue in my testing.

Changing SECURE_ERASE to 0 from 0x80000000 in include/mmc.h allows things to function for me.

Page 115 of the JEDEC eMMC 4.5 spec says that bit 31 is obsolete and should be zero:

        http://www.jedec.org/sites/default/files/docs/jesd84-B45.pdf

Hector and Fabio, can you test that change?

Please advise,

I've figured out a way to repeat this on my machine.

If I write 0xff's to the eMMC blocks, then issue an erase for the same, I get the problem with each MMC_ERASE command.

I've also found something that fixes the issue in my testing.

Changing SECURE_ERASE to 0 from 0x80000000 in include/mmc.h allows things to function for me.

Page 115 of the JEDEC eMMC 4.5 spec says that bit 31 is obsolete and should be zero:

        http://www.jedec.org/sites/default/files/docs/jesd84-B45.pdf

Hector and Fabio, can you test that change?

Hi Eric,

Quoted 14 lines · Eric Nelson

I've figured out a way to repeat this on my machine.

If I write 0xff's to the eMMC blocks, then issue an erase for the same, I get the problem with each MMC_ERASE command.

I've also found something that fixes the issue in my testing.

Changing SECURE_ERASE to 0 from 0x80000000 in include/mmc.h allows things to function for me.

Page 115 of the JEDEC eMMC 4.5 spec says that bit 31 is obsolete and should be zero:

        http://www.jedec.org/sites/default/files/docs/jesd84-B45.pdf

Quoted 1 line

Hector and Fabio, can you test that change?

Managed to get access to a revC2 board and tested your change.

I am happy to say that 'mmc erase' works now :-)

Good job, Eric!

When you send a formal patch then you can add:

Tested-by Fabio Estevam <[email protected]>

Hi Eric,

Quoted 5 lines · Eric Nelson

Sure. It's a hack, but shows where we're hitting the problem (with the stop command).

We haven't been using the "mmc erase" command, but see this when using ums to program eMMC.

Ok, applied your patch, but still get:

=> mmc erase 4000 1000

MMC erase: dev # 2, block # 16384, count 4096 ... Timeout waiting for DAT0 to go
high!
mmc erase failed
0 blocks erased: ERROR
=>

Thanks
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Can you print the sysctl & 0xF? I want to check if this workaround is really applied

Hi Michael,

Quoted 2 lines · Michael Trimarchi

Can you print the sysctl & 0xF? I want to check if this workaround is really applied

In my testing I see the error with or without the ENGcm03648 workaround.

Regards,

Fabio Estevam

Hi

Quoted 10 lines · Fabio Estevam

Hi Michael,

Quoted 2 lines · Michael Trimarchi

Can you print the sysctl & 0xF? I want to check if this workaround is really applied

In my testing I see the error with or without the ENGcm03648 workaround.

Well the workaround works if the sysctl is 0xf on the last bits, because it needs the
clocks enable according to the original description.

http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/commit/drivers/mmc/imx_esdhc.c?h=imx_v2009.08_12.01.01&id=e436525a70fe47623d346bc7d9f08f12ff8ad787

So if you hit this timeout without having this set, I don't think it can work

I think you're onto something.

According to the i.MX35 reference manual, which I think was the origin of this patch, the low four bits of the SYSCTL register of the SDHC5

	3	- SDCLKEN
	2	- PEREN
	1	- HCKEN
	0	- IPGEN

See page 603 of
http://cache.freescale.com/files/dsp/doc/ref_manual/IMX35RM.pdf

But in the i.MX6 reference manual, the low four bits are reserved and say "Always write as 1".

See pages 5679-5680 of
http://cache.freescale.com/files/32bit/doc/ref_manual/IMX6DQRM.pdf

It appears that when this patch was ported from the Freescale version, the test for "is_usdhc" was lost.

http://git.denx.de/?p=u-boot.git;a=commitdiff;h=7a5b80297bc6cef0c10e5f57ac0450678dc7bc5e

Hi all,

On 12/04/2015 09:08 AM, Eric Nelson wrote:
...

Quoted 23 lines

I think you're onto something.

According to the i.MX35 reference manual, which I think was the origin of this patch, the low four bits of the SYSCTL register of the SDHC5

      3       - SDCLKEN
      2       - PEREN
      1       - HCKEN
      0       - IPGEN

See page 603 of
http://cache.freescale.com/files/dsp/doc/ref_manual/IMX35RM.pdf

But in the i.MX6 reference manual, the low four bits are reserved and say "Always write as 1".

See pages 5679-5680 of
http://cache.freescale.com/files/32bit/doc/ref_manual/IMX6DQRM.pdf

It appears that when this patch was ported from the Freescale version, the test for "is_usdhc" was lost.

Quoted 2 lines

Following up, this code is bugged on i.MX6:

As are a couple of other things in the driver, as seen by trying to compile without the constants for the low 4 bits:

include/fsl_esdhc.h +2 -0

index aa1b4cf..a4b87ce 100644
@@ -25,10 +25,12 @@
 #define SYSCTL_INITA           0x08000000
 #define SYSCTL_TIMEOUT_MASK    0x000f0000
 #define SYSCTL_CLOCK_MASK      0x0000fff0
+#if !defined(CONFIG_MX6)
 #define SYSCTL_CKEN            0x00000008
 #define SYSCTL_PEREN           0x00000004
 #define SYSCTL_HCKEN           0x00000002
 #define SYSCTL_IPGEN           0x00000001
+#endif
 #define SYSCTL_RSTA            0x01000000
 #define SYSCTL_RSTC            0x02000000
 #define SYSCTL_RSTD            0x04000000

Table 41 of the JEDEC standard for eMMC says that bit 31 of the command argument is obsolete when issuing the ERASE command (CMD38) on page 115 of this document:

	http://www.jedec.org/sites/default/files/docs/jesd84-B45.pdf

The SD Card Association Physical Layer Simplified Specification also makes no mention of the use of bit 31.

	https://www.sdcard.org/downloads/pls/part1_410.pdf

The Linux kernel distinguishes between secure (bit 31 set) and non-secure erase, and this patch copies the macro names from include/linux/mmc/core.h.

Tested-by Fabio Estevam <[email protected]>

Signed-off-by Eric Nelson <[email protected]>

---
 drivers/mmc/mmc_write.c | 2 +-
 include/mmc.h           | 7 ++++++-
 2 files changed, 7 insertions(+), 2 deletions(-)

drivers/mmc/mmc_write.c +1 -1

index 7aea7e9..221bf30 100644
@@ -51,7 +51,7 @@ static ulong mmc_erase_t(struct mmc *mmc, ulong start, lbaint_t blkcnt)
 		goto err_out;
 
 	cmd.cmdidx = MMC_CMD_ERASE;
-	cmd.cmdarg = SECURE_ERASE;
+	cmd.cmdarg = MMC_ERASE_ARG;
 	cmd.resp_type = MMC_RSP_R1b;
 
 	err = mmc_send_cmd(mmc, &cmd, NULL);

include/mmc.h +0 -0

index cda9a19..b89962a 100644
@@ -121,7 +121,12 @@
 #define OCR_VOLTAGE_MASK	0x007FFF80
 #define OCR_ACCESS_MODE		0x60000000
 

Hi Eric and Fabio,

Quoted 49 lines · Eric Nelson

Table 41 of the JEDEC standard for eMMC says that bit 31 of the command argument is obsolete when issuing the ERASE command (CMD38) on page 115 of this document:

      http://www.jedec.org/sites/default/files/docs/jesd84-B45.pdf

The SD Card Association Physical Layer Simplified Specification also makes no mention of the use of bit 31.

      https://www.sdcard.org/downloads/pls/part1_410.pdf

The Linux kernel distinguishes between secure (bit 31 set) and non-secure erase, and this patch copies the macro names from include/linux/mmc/core.h.

Tested-by Fabio Estevam <[email protected]>

Signed-off-by Eric Nelson <[email protected]>

---
 drivers/mmc/mmc_write.c | 2 +-
 include/mmc.h           | 7 ++++++-
 2 files changed, 7 insertions(+), 2 deletions(-)

drivers/mmc/mmc_write.c +1 -1

index 7aea7e9..221bf30 100644
@@ -51,7 +51,7 @@ static ulong mmc_erase_t(struct mmc *mmc, ulong start, lbaint_t blkcnt)
              goto err_out;
 
      cmd.cmdidx = MMC_CMD_ERASE;
-     cmd.cmdarg = SECURE_ERASE;
+     cmd.cmdarg = MMC_ERASE_ARG;
      cmd.resp_type = MMC_RSP_R1b;
 
      err = mmc_send_cmd(mmc, &cmd, NULL);

include/mmc.h +6 -1

index cda9a19..b89962a 100644
@@ -121,7 +121,12 @@
 #define OCR_VOLTAGE_MASK     0x007FFF80
 #define OCR_ACCESS_MODE              0x60000000
 
-#define SECURE_ERASE         0x80000000
+#define MMC_ERASE_ARG                0x00000000
+#define MMC_SECURE_ERASE_ARG 0x80000000
+#define MMC_TRIM_ARG         0x00000001
+#define MMC_DISCARD_ARG              0x00000003
+#define MMC_SECURE_TRIM1_ARG 0x80000001
+#define MMC_SECURE_TRIM2_ARG 0x80008000
 

include/mmc.h line 132

Quoted 3 lines

include/mmc.h +0 -0

 #define MMC_STATUS_MASK              (~0x0206BF7F)
 #define MMC_STATUS_SWITCH_ERROR      (1 << 7)

This fixes the issue on eMMC. Very good job! Thank you.

Tested-by Hector Palacios <[email protected]>

Table 41 of the JEDEC standard for eMMC says that bit 31 of the command argument is obsolete when issuing the ERASE command (CMD38) on page 115 of this document:

	http://www.jedec.org/sites/default/files/docs/jesd84-B45.pdf

The SD Card Association Physical Layer Simplified Specification also makes no mention of the use of bit 31.

	https://www.sdcard.org/downloads/pls/part1_410.pdf

The Linux kernel distinguishes between secure (bit 31 set) and non-secure erase, and this patch copies the macro names from include/linux/mmc/core.h.

Tested-by Fabio Estevam <[email protected]>

Signed-off-by Eric Nelson <[email protected]>

Tested-by Hector Palacios <[email protected]>