Re: eMMC errors on RK3588 (rock5b)
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/cb1521aea8dee730bddcc5772afa28aa71fc69f9 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. >> >> 0. >> https://lore.kernel.org/u-boot/20230619103347.278004-1-eugen.hris...@collabora.com/ > > > 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
Re: eMMC errors on RK3588 (rock5b)
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. 0. https://lore.kernel.org/u-boot/20230619103347.278004-1-eugen.hris...@collabora.com/ 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
Re: eMMC errors on RK3588 (rock5b)
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.hris...@collabora.com/
Re: eMMC errors on RK3588 (rock5b)
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 0x5000 64 1 > [snip] >> MMC read: dev # 0, block # 100, count 1 ... >> 1 blocks read: OK >> => mmc write 0x5000 64 1 >> MMC write: dev # 0, block # 100, count 1 ... > [snip] >> 0 blocks written: ERROR >> => mmc write 0x5000 64 5 >> MMC write: dev # 0, block # 100, count 5 ... > [snip] >> 0 blocks written: ERROR >> => mmc read 0x5000 64 5 >> MMC read: dev # 0, block # 100, count 5 ... > [snip] >> 0 blocks read: ERROR >> => mmc read 0x5000 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 2000 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 2000 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 2000 40 200 > > Erase 256KiB from sector 64: > => mmc erase 40 200 > > Write 256KiB (TPL+SPL) from @512 MiB DRAM to sector 64: > => mmc write 2000 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 ! >
Re: eMMC errors on RK3588 (rock5b)
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 0x5000 64 1 [snip] > MMC read: dev # 0, block # 100, count 1 ... > 1 blocks read: OK > => mmc write 0x5000 64 1 > MMC write: dev # 0, block # 100, count 1 ... [snip] > 0 blocks written: ERROR > => mmc write 0x5000 64 5 > MMC write: dev # 0, block # 100, count 5 ... [snip] > 0 blocks written: ERROR > => mmc read 0x5000 64 5 > MMC read: dev # 0, block # 100, count 5 ... [snip] > 0 blocks read: ERROR > => mmc read 0x5000 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 2000 40 4 Erase 256KiB from sector 64: => mmc erase 40 4 Write 256KiB (TPL+SPL) from @512 MiB DRAM to sector 64: => mmc write 2000 40 4 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 !
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 0x5000 64 1 CMD_SEND:0 ARG 0x MMC_RSP_NONE CMD_SEND:8 ARG 0x01aa RET -110 CMD_SEND:55 ARG 0x RET -110 CMD_SEND:0 ARG 0x MMC_RSP_NONE CMD_SEND:1 ARG 0x MMC_RSP_R3,4 0x40ff8080 CMD_SEND:1 ARG 0x4006 MMC_RSP_R3,4 0x40ff8080 CMD_SEND:1 ARG 0x4006 MMC_RSP_R3,4 0x40ff8080 CMD_SEND:1 ARG 0x4006 MMC_RSP_R3,4 0xc0ff8080 CMD_SEND:2 ARG 0x 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 0x0001 MMC_RSP_R1,5,6,7 0x0500 CMD_SEND:9 ARG 0x0001 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 0x0001 MMC_RSP_R1,5,6,7 0x0700 CMD_SEND:8 ARG 0x MMC_RSP_R1,5,6,7 0x0900 CMD_SEND:6 ARG 0x03b70200 MMC_RSP_R1b 0x0900 CMD_SEND:13 ARG 0x0001 MMC_RSP_R1,5,6,7 0x0900 CURR STATE:4 CMD_SEND:6 ARG 0x03b90100 MMC_RSP_R1b 0x0900 CMD_SEND:13 ARG 0x0001 MMC_RSP_R1,5,6,7 0x0900 CURR STATE:4 CMD_SEND:6 ARG 0x03b70600 MMC_RSP_R1b 0x0900 CMD_SEND:13 ARG 0x0001 MMC_RSP_R1,5,6,7 0x0900 CURR STATE:4 CMD_SEND:8 ARG 0x MMC_RSP_R1,5,6,7 0x0900 MMC read: dev # 0, block # 100, count 1 ... CMD_SEND:17 ARG 0x0064 MMC_RSP_R1,5,6,7 0x0900 1 blocks read: OK => mmc write 0x5000 64 1 MMC write: dev # 0, block # 100, count 1 ... mmc bwrite1 mmc bwrite2 CMD_SEND:17 ARG 0x MMC_RSP_R1,5,6,7 0x0900 CMD_SEND:18 ARG 0x0040 MMC_RSP_R1,5,6,7 0x0900 CMD_SEND:12 ARG 0x MMC_RSP_R1b 0x0b00 CMD_SEND:18 ARG 0x0002 MMC_RSP_R1,5,6,7 0x0900 CMD_SEND:12 ARG 0x MMC_RSP_R1b 0x0b00 mmc bwrite3 CMD_SEND:24 ARG 0x0064 RET -70 mmc write failed 0 blocks written: ERROR => mmc write 0x5000 64 5 MMC write: dev # 0, block # 100, count 5 ... mmc bwrite1 mmc bwrite2 mmc bwrite3 CMD_SEND:25 ARG 0x0064 RET -70 mmc write failed 0 blocks written: ERROR => mmc read 0x5000 64 5 MMC read: dev # 0, block # 100, count 5 ... CMD_SEND:18 ARG 0x0064 RET -110 0 blocks read: ERROR => mmc read 0x5000 64 1 MMC read: dev # 0, block # 100, count 1 ... CMD_SEND:17 ARG
