eMMC errors on RK3588 (rock5b)
Hi Jonas,
I tried some basic eMMC read/write commands, and in my setup with rock5b, it fails at single/multiple block read/write , even if sometimes, the initial read works fine.
Here is some log :
=> mmc read 0x50000000 64 1 CMD_SEND:0 ARG 0x00000000 MMC_RSP_NONE CMD_SEND:8 ARG 0x000001aa RET -110 CMD_SEND:55 ARG 0x00000000 RET -110 CMD_SEND:0 ARG 0x00000000 MMC_RSP_NONE CMD_SEND:1 ARG 0x00000000 MMC_RSP_R3,4 0x40ff8080 CMD_SEND:1 ARG 0x40060000 MMC_RSP_R3,4 0x40ff8080 CMD_SEND:1 ARG 0x40060000 MMC_RSP_R3,4 0x40ff8080 CMD_SEND:1 ARG 0x40060000 MMC_RSP_R3,4 0xc0ff8080 CMD_SEND:2 ARG 0x00000000 MMC_RSP_R2 0x15010042 0x4a544434 0x5203d923 0x738d5900
DUMPING DATA 000 - 15 01 00 42 004 - 4a 54 44 34 008 - 52 03 d9 23 012 - 73 8d 59 00 CMD_SEND:3 ARG 0x00010000 MMC_RSP_R1,5,6,7 0x00000500 CMD_SEND:9 ARG 0x00010000 MMC_RSP_R2 0xd0270132 0x0f5903ff 0xf6dbffef 0x8e404000
DUMPING DATA 000 - d0 27 01 32 004 - 0f 59 03 ff 008 - f6 db ff ef 012 - 8e 40 40 00 CMD_SEND:7 ARG 0x00010000 MMC_RSP_R1,5,6,7 0x00000700 CMD_SEND:8 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000900 CMD_SEND:6 ARG 0x03b70200 MMC_RSP_R1b 0x00000900 CMD_SEND:13 ARG 0x00010000 MMC_RSP_R1,5,6,7 0x00000900 CURR STATE:4 CMD_SEND:6 ARG 0x03b90100 MMC_RSP_R1b 0x00000900 CMD_SEND:13 ARG 0x00010000 MMC_RSP_R1,5,6,7 0x00000900 CURR STATE:4 CMD_SEND:6 ARG 0x03b70600 MMC_RSP_R1b 0x00000900 CMD_SEND:13 ARG 0x00010000 MMC_RSP_R1,5,6,7 0x00000900 CURR STATE:4 CMD_SEND:8 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000900
MMC read: dev # 0, block # 100, count 1 ... CMD_SEND:17 ARG 0x00000064 MMC_RSP_R1,5,6,7 0x00000900 1 blocks read: OK => mmc write 0x50000000 64 1
MMC write: dev # 0, block # 100, count 1 ... mmc bwrite1 mmc bwrite2 CMD_SEND:17 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x00000900 CMD_SEND:18 ARG 0x00000040 MMC_RSP_R1,5,6,7 0x00000900 CMD_SEND:12 ARG 0x00000000 MMC_RSP_R1b 0x00000b00 CMD_SEND:18 ARG 0x00000002 MMC_RSP_R1,5,6,7 0x00000900 CMD_SEND:12 ARG 0x00000000 MMC_RSP_R1b 0x00000b00 mmc bwrite3 CMD_SEND:24 ARG 0x00000064 RET -70 mmc write failed 0 blocks written: ERROR => mmc write 0x50000000 64 5
MMC write: dev # 0, block # 100, count 5 ... mmc bwrite1 mmc bwrite2 mmc bwrite3 CMD_SEND:25 ARG 0x00000064 RET -70 mmc write failed 0 blocks written: ERROR => mmc read 0x50000000 64 5
MMC read: dev # 0, block # 100, count 5 ... CMD_SEND:18 ARG 0x00000064 RET -110 0 blocks read: ERROR => mmc read 0x50000000 64 1
MMC read: dev # 0, block # 100, count 1 ... CMD_SEND:17 ARG 0x00000064 RET -110 0 blocks read: ERROR =>
So now after this attempt, there is a timeout when reading too.
Can you try to reproduce this on your setup as well ?
P.S. booting from eMMC works fine. When I am trying this, I am booting from the eMMC.
Thanks !
Hi Eugen,
On 2023-05-25 11:23, Eugen Hristev wrote:
Hi Jonas,
I tried some basic eMMC read/write commands, and in my setup with rock5b, it fails at single/multiple block read/write , even if sometimes, the initial read works fine.
Here is some log :
=> mmc read 0x50000000 64 1
[snip]
MMC read: dev # 0, block # 100, count 1 ... 1 blocks read: OK => mmc write 0x50000000 64 1 MMC write: dev # 0, block # 100, count 1 ...
[snip]
0 blocks written: ERROR => mmc write 0x50000000 64 5 MMC write: dev # 0, block # 100, count 5 ...
[snip]
0 blocks written: ERROR => mmc read 0x50000000 64 5 MMC read: dev # 0, block # 100, count 5 ...
[snip]
0 blocks read: ERROR => mmc read 0x50000000 64 1
[snip]
MMC read: dev # 0, block # 100, count 1 ... 0 blocks read: ERROR =>
So now after this attempt, there is a timeout when reading too.
Can you try to reproduce this on your setup as well ?
I was able to reproduce similar issue on rk356x, did not test on rk3588 yet. Also going to try similar write commands on the rk3399 (arasan) compatible of the rk sdhci driver, guess both rk35xx (dwc) compatible is affected.
Something odd that I noticed was that write sometime reported OK when a read command for same blocks was issued, e.g. something similar worked in some of my testing:
Select eMMC device to reset state: => mmc dev 0
Read 256KiB (TPL+SPL) from sector 64 to @512 MiB DRAM: => mmc read 20000000 40 40000
Erase 256KiB from sector 64: => mmc erase 40 40000
Write 256KiB (TPL+SPL) from @512 MiB DRAM to sector 64: => mmc write 20000000 40 40000
After something fails the use of "mmc dev 0" could be used to reset into a working read state. Some retry/reset handling may be needed in driver to fully support write commands.
A quick peek at vendor u-boot: rk u-boot include some form of retry logic for write and hardkernel u-boot implement some sort of sw reset.
Regards, Jonas
P.S. booting from eMMC works fine. When I am trying this, I am booting from the eMMC.
Thanks !
Hi again, On 2023-05-29 17:27, Jonas Karlman wrote:
Hi Eugen,
On 2023-05-25 11:23, Eugen Hristev wrote:
Hi Jonas,
I tried some basic eMMC read/write commands, and in my setup with rock5b, it fails at single/multiple block read/write , even if sometimes, the initial read works fine.
Here is some log :
=> mmc read 0x50000000 64 1
[snip]
MMC read: dev # 0, block # 100, count 1 ... 1 blocks read: OK => mmc write 0x50000000 64 1 MMC write: dev # 0, block # 100, count 1 ...
[snip]
0 blocks written: ERROR => mmc write 0x50000000 64 5 MMC write: dev # 0, block # 100, count 5 ...
[snip]
0 blocks written: ERROR => mmc read 0x50000000 64 5 MMC read: dev # 0, block # 100, count 5 ...
[snip]
0 blocks read: ERROR => mmc read 0x50000000 64 1
[snip]
MMC read: dev # 0, block # 100, count 1 ... 0 blocks read: ERROR =>
So now after this attempt, there is a timeout when reading too.
Can you try to reproduce this on your setup as well ?
I was able to reproduce similar issue on rk356x, did not test on rk3588 yet. Also going to try similar write commands on the rk3399 (arasan) compatible of the rk sdhci driver, guess both rk35xx (dwc) compatible is affected.
I tested on rk3399 and there was no problem loading u-boot-rockchip.bin from SD-card and writing it to eMMC using the following commands:
Load u-boot-rockchip.bin to @512 MiB DRAM from SD-card: => load mmc 1:1 20000000 u-boot-rockchip.bin 9264128 bytes read in 402 ms (22 MiB/s)
Select eMMC device: => mmc dev 0 switch to partitions #0, OK mmc0(part 0) is current device
Erase 12 MiB starting from sector 64: => mmc erase 40 6000 MMC erase: dev # 0, block # 64, count 24576 ... 24576 blocks erased: OK
Write 12 MiB from @512 MiB DRAM to sector 64: => mmc write 20000000 40 6000 MMC write: dev # 0, block # 64, count 24576 ... 24576 blocks written: OK
So something in controller or driver cause write issues on rk35xx.
Something odd that I noticed was that write sometime reported OK when a read command for same blocks was issued, e.g. something similar worked in some of my testing:
Select eMMC device to reset state: => mmc dev 0
Read 256KiB (TPL+SPL) from sector 64 to @512 MiB DRAM: => mmc read 20000000 40 200
Erase 256KiB from sector 64: => mmc erase 40 200
Write 256KiB (TPL+SPL) from @512 MiB DRAM to sector 64: => mmc write 20000000 40 200
Count param was in bytes in my prior mail, corrected to block count above.
Regards, Jonas
After something fails the use of "mmc dev 0" could be used to reset into a working read state. Some retry/reset handling may be needed in driver to fully support write commands.
A quick peek at vendor u-boot: rk u-boot include some form of retry logic for write and hardkernel u-boot implement some sort of sw reset.
Regards, Jonas
P.S. booting from eMMC works fine. When I am trying this, I am booting from the eMMC.
Thanks !
I am able to reproduce this on RK3588 QuartzPro64.
I cannot reproduce on the vendor u-boot, used on stock RK3588 QuartzPro64. That works fine.
I thought "[PATCH v2 RESEND] mmc: dw_mmc: reset controller after data error"[0] might fix this, but after applying that, I am still able to reproduce the issue.
0. https://lore.kernel.org/u-boot/20230619103347.278004-1-eugen.hristev@collabo...
On 11/23/23 07:22, Tom Fitzhenry wrote:
I am able to reproduce this on RK3588 QuartzPro64.
I cannot reproduce on the vendor u-boot, used on stock RK3588 QuartzPro64. That works fine.
I thought "[PATCH v2 RESEND] mmc: dw_mmc: reset controller after data error"[0] might fix this, but after applying that, I am still able to reproduce the issue.
I never said that patch would fix this issue. It fixes another problem that was happening when the controller was resetting. But that issue was arising only in a specific scenario which happened only during my tests. So the fix is here, it's helpful, but not fixing this issue. And it appears that this fix will not be accepted to upstream, as it's months since I am resending it.
Eugen
On 2023-11-23 10:58, Eugen Hristev wrote:
On 11/23/23 07:22, Tom Fitzhenry wrote:
I am able to reproduce this on RK3588 QuartzPro64.
I have also been able to reproduce this and made the following finding:
rk35xx: drop ddr52 mode to fix write rk3568: change txclk tapnum to fix write at hs400 speed rk3588: enable hs200 mode to fix write rk3588: drop hs400 mode to fix write
Have not had time to complete test and send patches, should have some time later this weekend to complete test and send patches.
WIP: rockchip: rk35xx: improve emmc write https://github.com/Kwiboo/u-boot-rockchip/commit/cb1521aea8dee730bddcc5772af...
Regards, Jonas
I cannot reproduce on the vendor u-boot, used on stock RK3588 QuartzPro64. That works fine.
I thought "[PATCH v2 RESEND] mmc: dw_mmc: reset controller after data error"[0] might fix this, but after applying that, I am still able to reproduce the issue.
I never said that patch would fix this issue. It fixes another problem that was happening when the controller was resetting. But that issue was arising only in a specific scenario which happened only during my tests. So the fix is here, it's helpful, but not fixing this issue. And it appears that this fix will not be accepted to upstream, as it's months since I am resending it.
Eugen
participants (3)
-
Eugen Hristev -
Jonas Karlman -
Tom Fitzhenry