[U-Boot] 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
Dear Cliff,
On 10/16/2015 01:46 PM, Cliff Brust wrote:
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
Regards, -- Hector Palacios
Hi Hector and Cliff,
On Mon, Oct 19, 2015 at 9:06 AM, Hector Palacios hector.palacios@digi.com wrote:
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 =>
Regards,
Fabio Estevam
Hi Fabio,
On Thu, 12 Nov 2015 21:56, Fabio Estevam wrote:
Hi Hector and Cliff,
On Mon, Oct 19, 2015 at 9:06 AM, Hector Palacios hector.palacios@digi.com wrote:
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 =>
I can reproduce it with latest U-Boot on a mx6qsabresd both on the SD card and on the eMMC:
U-Boot 2015.10-00638-g9ac4fc82071c (Nov 13 2015 - 12:44:11 +0100)
CPU: Freescale i.MX6Q rev1.2 996 MHz (running at 792 MHz) CPU: Automotive temperature grade (-40C to 125C) at 45C Reset cause: POR Board: MX6-SabreSD I2C: ready DRAM: 1 GiB PMIC: PFUZE100 ID=0x10 MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 *** Warning - bad CRC, using default environment
PCI: pcie phy link never came up No panel detected: default to Hannstar-XGA Display: Hannstar-XGA (1024x768) In: serial Out: serial Err: serial Net: FEC [PRIME] Hit any key to stop autoboot: 0
SDCARD test:
=> mmc dev 1 switch to partitions #0, OK mmc1 is current device => mmc erase 4000 1000
MMC erase: dev # 1, block # 16384, count 4096 ... Timeout waiting for DAT0 to go high! mmc erase failed 0 blocks erased: ERROR
eMMC test:
=> 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 ... Timeout waiting for DAT0 to go high! mmc erase failed 0 blocks erased: ERROR =>
Could it be a silicon revision issue? My CPU is i.MX6Q rev1.2.
I tested on two SABRESD units with similar results. In the second board, erasing the SD card (mmc erase 4000 1000) occasionally works (it takes around 30 seconds). But the rest of times fails after a random number of blocks: => mmc erase 4000 1000
MMC erase: dev # 1, block # 16384, count 4096 ... Timeout waiting for DAT0 to go high! mmc erase failed 1412 blocks erased: ERROR
The eMMC however *always* fails in both SABRESD boards (and in my custom board) after erasing sector #0. My eMMC is v4.5 and SABRESD is v4.4.1, but both of them fail:
=> mmcinfo (SABRE) 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
=> mmcinfo (custom board) Device: FSL_SDHC Manufacturer ID: fe OEM: 14e Name: P1XXX Tran Speed: 52000000 Rd Block Len: 512 MMC version 4.5 High Capacity: Yes Capacity: 3.6 GiB Bus Width: 8-bit Erase Group Size: 512 KiB HC WP Group Size: 4 MiB User Capacity: 3.6 GiB Boot Capacity: 16 MiB ENH RPMB Capacity: 128 KiB ENH
Regards, -- Héctor Palacios
On Fri, Nov 13, 2015 at 10:26 AM, Palacios, Hector Hector.Palacios@digi.com wrote:
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.
Regards,
Fabio Estevam
Hi Hector,
On Fri, Nov 13, 2015 at 12:37 PM, Fabio Estevam festevam@gmail.com wrote:
On Fri, Nov 13, 2015 at 10:26 AM, Palacios, Hector Hector.Palacios@digi.com wrote:
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
Regards,
Fabio Estevam
On Mon, Nov 16, 2015 at 1:23 PM, Fabio Estevam festevam@gmail.com wrote:
Hi Hector,
On Fri, Nov 13, 2015 at 12:37 PM, Fabio Estevam festevam@gmail.com wrote:
On Fri, Nov 13, 2015 at 10:26 AM, Palacios, Hector Hector.Palacios@digi.com wrote:
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
Boards revC2 and revC4 failed. (Both are TO1.2)
Board revB (with TO1.1) works fine.
Hi all,
On 11/16/2015 08:30 AM, Fabio Estevam wrote:
On Mon, Nov 16, 2015 at 1:23 PM, Fabio Estevam festevam@gmail.com wrote:
Hi Hector,
On Fri, Nov 13, 2015 at 12:37 PM, Fabio Estevam festevam@gmail.com wrote:
On Fri, Nov 13, 2015 at 10:26 AM, Palacios, Hector Hector.Palacios@digi.com wrote:
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
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=c5054d66...
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.
Regards,
Eric
Hi Eric,
On Tue, Dec 1, 2015 at 5:05 PM, Eric Nelson eric@nelint.com wrote:
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
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#l390Seems 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.
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?
Thanks,
Fabio Estevam
Hi Fabio,
On 12/02/2015 10:23 AM, Fabio Estevam wrote:
Hi Eric,
On Tue, Dec 1, 2015 at 5:05 PM, Eric Nelson eric@nelint.com wrote:
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
We're seeing this pretty intermittently and only with certain devices from the same batch, so I'm not sure I'd conclude that the problem won't happen on revB or revC5.
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#l390Seems 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.
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.
Regards,
Eric
Hi Eric,
On Wed, Dec 2, 2015 at 4:47 PM, Eric Nelson eric@nelint.com wrote:
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
Hi Fabio,
On 12/02/2015 11:52 AM, Fabio Estevam wrote:
Hi Eric,
On Wed, Dec 2, 2015 at 4:47 PM, Eric Nelson eric@nelint.com wrote:
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=c5054d66...
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=7aea7e94...
I think you can instrument and find out using this:
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index 53084a7..8f5d9e1 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -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; }
Hi Eric,
On Wed, Dec 2, 2015 at 5:28 PM, Eric Nelson eric@nelint.com wrote:
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?
Then the error changes to:
=> mmc erase 4000 1000
MMC erase: dev # 2, block # 16384, count 4096 ... Timeout waiting card ready 0 blocks erased: ERROR
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/fsl_esdhc.c;h=c5054d66...
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
It is MMC_CMD_ERASE as shown below.
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/mmc_write.c;h=7aea7e94...
I think you can instrument and find out using this:
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index 53084a7..8f5d9e1 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -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 =>
Thanks
Hi Fabio,
On 12/02/2015 12:53 PM, Fabio Estevam wrote:
On Wed, Dec 2, 2015 at 5:28 PM, Eric Nelson eric@nelint.com wrote:
...
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index 53084a7..8f5d9e1 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -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?
I'm only seeing the error sporadically, which makes it difficult to test.
Hi Eric,
On Fri, Dec 4, 2015 at 2:35 PM, Eric Nelson eric@nelint.com wrote:
How easy is this for you to reproduce?
Very easy as it happens 100% of the times I run 'mmc erase' on a revC2 or revC4 board.
Thanks
Hi all,
On 12/04/2015 09:35 AM, Eric Nelson wrote:
Hi Fabio,
On 12/02/2015 12:53 PM, Fabio Estevam wrote:
On Wed, Dec 2, 2015 at 5:28 PM, Eric Nelson eric@nelint.com wrote:
...
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index 53084a7..8f5d9e1 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -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?
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,
Eric
diff --git a/include/mmc.h b/include/mmc.h index cda9a19..b1528d4 100644 --- a/include/mmc.h +++ b/include/mmc.h @@ -121,7 +121,7 @@ #define OCR_VOLTAGE_MASK 0x007FFF80 #define OCR_ACCESS_MODE 0x60000000
-#define SECURE_ERASE 0x80000000 +#define SECURE_ERASE 0x00000000
Hi Eric,
On Fri, Dec 4, 2015 at 8:42 PM, Eric Nelson eric@nelint.com wrote:
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,
That sounds promising. I will test it on Monday when I get access to a revC4 board.
Thanks a lot!
Hi Eric,
On Fri, Dec 4, 2015 at 8:42 PM, Eric Nelson eric@nelint.com wrote:
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?
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 fabio.estevam@freescale.com
Thanks!
Hi Fabio,
On 12/06/2015 05:21 PM, Fabio Estevam wrote:
Hi Eric,
On Fri, Dec 4, 2015 at 8:42 PM, Eric Nelson eric@nelint.com wrote:
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?
Managed to get access to a revC2 board and tested your change.
I am happy to say that 'mmc erase' works now :-)
Glad to hear it.
Good job, Eric!
When you send a formal patch then you can add:
Tested-by: Fabio Estevam fabio.estevam@freescale.com
Will do.
Hi
On Wed, Dec 2, 2015 at 7:52 PM, Fabio Estevam festevam@gmail.com wrote:
Hi Eric,
On Wed, Dec 2, 2015 at 4:47 PM, Eric Nelson eric@nelint.com wrote:
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 =>
Can you print the sysctl & 0xF? I want to check if this workaround is really applied
Michael
Thanks _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Hi Michael,
On Wed, Dec 2, 2015 at 5:37 PM, Michael Trimarchi michael@amarulasolutions.com wrote:
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
On Wed, Dec 2, 2015 at 8:54 PM, Fabio Estevam festevam@gmail.com wrote:
Hi Michael,
On Wed, Dec 2, 2015 at 5:37 PM, Michael Trimarchi michael@amarulasolutions.com wrote:
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/i...
So if you hit this timeout without having this set, I don't think it can work
Michael
Regards,
Fabio Estevam
Hi Michael,
On 12/02/2015 01:00 PM, Michael Trimarchi wrote:
Hi
On Wed, Dec 2, 2015 at 8:54 PM, Fabio Estevam festevam@gmail.com wrote:
Hi Michael,
On Wed, Dec 2, 2015 at 5:37 PM, Michael Trimarchi michael@amarulasolutions.com wrote:
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/i...
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=7a5b80297bc6cef0c10e5f57ac04...
Hi all,
On 12/04/2015 09:08 AM, Eric Nelson wrote: ...
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=7a5b80297bc6cef0c10e5f57ac04...
Following up, this code is bugged on i.MX6:
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/fsl_esdhc.c;h=c5054d66...
As are a couple of other things in the driver, as seen by trying to compile without the constants for the low 4 bits:
diff --git a/include/fsl_esdhc.h b/include/fsl_esdhc.h index aa1b4cf..a4b87ce 100644 --- a/include/fsl_esdhc.h +++ b/include/fsl_esdhc.h @@ -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
Hi
On Dec 4, 2015 5:50 PM, "Eric Nelson" eric@nelint.com wrote:
Hi all,
On 12/04/2015 09:08 AM, Eric Nelson wrote: ...
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=7a5b80297bc6cef0c10e5f57ac04...
Happy if you fix down your problem
Michael
Following up, this code is bugged on i.MX6:
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/fsl_esdhc.c;h=c5054d66...
As are a couple of other things in the driver, as seen by trying to compile without the constants for the low 4 bits:
diff --git a/include/fsl_esdhc.h b/include/fsl_esdhc.h index aa1b4cf..a4b87ce 100644 --- a/include/fsl_esdhc.h +++ b/include/fsl_esdhc.h @@ -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 fabio.estevam@freescale.com Signed-off-by: Eric Nelson eric@nelint.com --- drivers/mmc/mmc_write.c | 2 +- include/mmc.h | 7 ++++++- 2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/mmc_write.c b/drivers/mmc/mmc_write.c index 7aea7e9..221bf30 100644 --- a/drivers/mmc/mmc_write.c +++ b/drivers/mmc/mmc_write.c @@ -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); diff --git a/include/mmc.h b/include/mmc.h index cda9a19..b89962a 100644 --- a/include/mmc.h +++ b/include/mmc.h @@ -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
#define MMC_STATUS_MASK (~0x0206BF7F) #define MMC_STATUS_SWITCH_ERROR (1 << 7)
Hi Eric and Fabio,
On 12/07/2015 03:50 PM, Eric Nelson wrote:
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 fabio.estevam@freescale.com Signed-off-by: Eric Nelson eric@nelint.com
drivers/mmc/mmc_write.c | 2 +- include/mmc.h | 7 ++++++- 2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/mmc_write.c b/drivers/mmc/mmc_write.c index 7aea7e9..221bf30 100644 --- a/drivers/mmc/mmc_write.c +++ b/drivers/mmc/mmc_write.c @@ -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);
diff --git a/include/mmc.h b/include/mmc.h index cda9a19..b89962a 100644 --- a/include/mmc.h +++ b/include/mmc.h @@ -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
#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 hector.palacios@digi.com
On the uSD card, it occasionally works (when it didn't before), but it still fails many times, after erasing a random number of blocks (at random times). I guess this must be a different issue, though. I could reproduce it on my board (4 data lines) and on the SabreSD (8 data lines) with v2015.04. Here is an output from the SabreSD:
=> time mmc erase 200000 100
MMC erase: dev # 1, block # 2097152, count 256 ... 256 blocks erased: OK
time: 1.866 seconds => time mmc erase 200000 1000
MMC erase: dev # 1, block # 2097152, count 4096 ... Timeout waiting for DAT0 to go high! mmc erase failed 1409 blocks erased: ERROR
time: 11.263 seconds => time mmc erase 200000 10000
MMC erase: dev # 1, block # 2097152, count 65536 ... Timeout waiting for DAT0 to go high! mmc erase failed 8192 blocks erased: ERROR
time: 59.139 seconds
Thank you -- Hector Palacios
Hi Tom and Pantelis,
On Wed, Dec 9, 2015 at 8:55 AM, Hector Palacios hector.palacios@digi.com wrote:
Hi Eric and Fabio,
On 12/07/2015 03:50 PM, Eric Nelson wrote:
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 fabio.estevam@freescale.com Signed-off-by: Eric Nelson eric@nelint.com
drivers/mmc/mmc_write.c | 2 +- include/mmc.h | 7 ++++++- 2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/mmc_write.c b/drivers/mmc/mmc_write.c index 7aea7e9..221bf30 100644 --- a/drivers/mmc/mmc_write.c +++ b/drivers/mmc/mmc_write.c @@ -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);diff --git a/include/mmc.h b/include/mmc.h index cda9a19..b89962a 100644 --- a/include/mmc.h +++ b/include/mmc.h @@ -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
#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 hector.palacios@digi.com
Could this one be applied to 2016.01?
Thanks
On Mon, Dec 07, 2015 at 07:50:01AM -0700, Eric Nelson wrote:
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 fabio.estevam@freescale.com Signed-off-by: Eric Nelson eric@nelint.com Tested-by: Hector Palacios hector.palacios@digi.com
Applied to u-boot/master, thanks!
participants (7)
-
Cliff Brust -
Eric Nelson -
Fabio Estevam -
Hector Palacios -
Michael Trimarchi -
Palacios, Hector
-
Tom Rini