Hi Quentin, On 2024-02-02 12:10, Quentin Schulz wrote: > Hi Jonas, > > On 2/1/24 21:06, Jonas Karlman wrote: >> Hi Quentin, >> >> On 2024-02-01 13:40, Quentin Schulz wrote: >>> Hi Jonas, >>> >>> On 2/1/24 11:51, Jonas Karlman wrote: >>>> Hi Quentin, >>>> >>>> On 2024-02-01 11:18, Quentin Schulz wrote: >>>>> Hi Jonas, >>>>> >>>>> On 1/27/24 12:15, Jonas Karlman wrote: >>>>>> Hi Eugen, >>>>>> >>>>>> On 2024-01-27 04:48, Eugen Hristev wrote: >>>>>>> Hi Jonas, >>>>>>> >>>>>>> >>>>>>> On 1/27/24 01:26, Jonas Karlman wrote: >>>>>>>> Writing to eMMC using DDR52 mode does not work reliably or at all on >>>>>>>> RK356x and RK3588 boards. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> This is related to the old issue I encountered last year with mmc write? >>>>>> >>>>>> Yes, I think it is. >>>>>> >>>>>> I did some testing on RK3566/RK3568/RK3588S/RK3588 boards with different >>>>>> eMMC modules with following result: >>>>>> >>>>>> Read seem to work with all enabled modes: >>>>>> RK3566: MMC legacy, MMC High Speed (26MHz), MMC High Speed (52MHz), >>>>>> MMC DDR52 (52MHz) and HS200 (200MHz) >>>>>> RK3568/RK3588S/RK3588: all above + HS400 (200MHz) and HS400ES (200MHz) >>>>>> >>>>>> However, write had issues with some of the modes: >>>>>> MMC DDR52 (52MHz): all RK35xx >>>>>> HS400/HS400ES: only on RK3568 after changing hs400_txclk_tapnum to 8 >>>>>> >>>>>> HS200 seem to be the most stable write speed that worked on all SoCs. >>>>>> >>>>>> So, dropping MMC DDR52 (52MHz) and enable use of HS200 (200MHz) seem to >>>>>> be the best option to get speedy and working read and write eMMC. >>>>>> >>>>> >>>>> 1) we have this enabled on RK3588 Jaguar in upstream Linux... I may have >>>>> improperly tested it then, would you mind sharing how you tested this >>>>> mode on RK3588 so I can reproduce this and fix it on our product if >>>>> we're impacted? I assume because we have HS200/HS400/HS400-ES enabled, >>>>> DDR52 would never be used? (our eMMC is soldered and support the former >>>>> modes). >>>> >>>> My main mode of testing eMMC in U-Boot has been to enable following >>>> Kconfig options, >>>> >>>> CONFIG_MMC_HS200_SUPPORT=y >>>> CONFIG_MMC_HS400_SUPPORT=y >>>> CONFIG_MMC_HS400_ES_SUPPORT=y >>>> CONFIG_MMC_SPEED_MODE_SET=y >>>> >>>> and from U-Boot cli run following, >>>> >>>> => mmc rescan <mode> && mmc info && mmc read 10000000 2000 10000 >>>> => mmc rescan <mode> && mmc info && mmc write 20000000 4000 10000 >>>> >>>> for each of the modes below. >>>> >>>> 0 = MMC legacy >>>> 1 = MMC High Speed (26MHz) >>>> 3 = MMC High Speed (52MHz) >>>> 4 = MMC DDR52 (52MHz) >>>> 10 = HS200 (200MHz) >>>> 11 = HS400 (200MHz) >>>> 12 = HS400ES (200MHz) >>>> >>>> on different boards and different eMMC modules. >>>> >>>> Using some modes the read or write return ERROR instead of OK. When >>>> ERROR was reported a rescan or board reset was needed to test next mode. >>>> >>>> Please also note that I have only tested in U-Boot, not in linux. >>>> >>> >>> Thanks for the tips on how to test these. >>> >>> I have run the following commands on an RK3588 Jaguar (master branch + >>> your v6.8-rc1 DTS sync patch series + Jaguar patch series): >>> >>> => for j in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19; do for i >>> in 0 1 3 4 10 11 12; do mmc rescan $i && mmc read 10000000 2000 100000; >>> if test $? -ne 0; then echo $i FAILED; fi; done; done >>> >>> Which is 20 iterations of an mmc read at each of the 7 supported modes. >>> The result is: >>> 1 fail in HS200, 2 fails in HS400, the rest passes just fine. >> >> I am wondering if your HS200 fails could be because MMC DDR52 (52MHz) >> was being tested prior to the HS200 mode. >> >> What happens if you exclude the mmc-ddr-1_8v prop and mode 4 in your >> test loops? >> >> I did some quick re-test on a ROCK 5A (rk3588s) and ROCK 5B (rk3588) >> with DDR52 removed and could only see very few read fails with HS400. >> > > OK so I did something completely different instead. rescan in one mode, > do a read, power cycle, rescan in another mode, do a read, power cycle, > etc.... > > All tests passed. > > Then... > >>> >>> => for j in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19; do for i >>> in 0 1 3 4 10 11 12; do mmc rescan $i && mmc write 20000000 4000 100000; >>> if test $? -ne 0; then echo $i FAILED; fi; done; done >>> >>> Which is 20 iterations of an mmc write at each of the 7 supported modes. >>> The result is: >>> 20 fails in DDR52, 2 fails in HS200, the rest passes just fine. >>> >>> So it seems DDR52, HS200 and HS400 aren't stable on my board, but >>> HS400ES somehow is (which is enabled in our defconfig). >> > > I did the same for the write: > > rescan in one mode, do a write, power cycle, rescan in another mode, do > a write, power cycle, etc.... > > And this brought surprising results: > > EVERYTHING except HS200, HS400 and HS400ES failed. Like not even a block > was written.
I now vaguely remember something similar from when I tested back in November, however during re-testing before posting this series I only tested without a full power reset between different modes :-) > > Now, that was not really what I remember happening yesterday. So it > seems that the modes before HS200 may rely somehow on previous > rescans/reads. > > So I tested this theory by just running a single mmc read of one block > after doing a rescan and before doing a write. This didn't help. > > Now, I forced a HS400ES read before doing writes at modes below HS200 > (excluded) and they didn't work. However, once I did a single block read > in HS400 instead of HS400ES, the writes in those same modes started to > work (except DDR52). > > They also worked when doing a single block read in HS200. Thanks for testing this more thoroughly! > > For all those tests, I still had mmc-ddr-1_8v in my DT. > > So, I would say everything that isn't HS200+ is broken on RK3588? Did > the modes below DDR52 work for you? I re-tested booting of a SD-card on RK3588 and found out following: - Write in DDR52 mode never works, hence this patch - Read works in all modes directly after a power reset - First write in modes that isn't HS200+ fails => mmc rescan 0 && mmc write 2000000 4000 1 # ERROR - Second+ write in same mode that just failed works => mmc write 2000000 4000 1 # OK - After a rescan to HS200 mode (probably any HS200+) first write in modes that isn't HS200+ no longer fails until power reset => mmc rescan 10 && mmc rescan 0 && mmc write 2000000 4000 1 # OK - When rockchip_sdhci_execute_tuning() is empty, changing to HS200 mode no longer "fixes" the write for slower modes => mmc rescan 10 && mmc rescan 0 && mmc write 2000000 4000 1 # ERROR - Trying to execute tuning for modes slower then HS200 fails as expected So based on testing I would say that any mode that isn't HS200+ is only semi-broken because writing seem to start working after a second try. And after tuning has been executed in HS200+ any other mode seem to work. Maybe we should enable the HS200 options for ROCKCHIP_RK3588 by default instead of explicitly enabling it in defconfig for boards that have MMC_SDHCI_ROCKCHIP enabled? --- a/drivers/mmc/Kconfig +++ b/drivers/mmc/Kconfig @@ -665,6 +665,8 @@ config MMC_SDHCI_ROCKCHIP depends on ARCH_ROCKCHIP depends on DM_MMC && BLK depends on MMC_SDHCI + imply MMC_HS200_SUPPORT if ROCKCHIP_RK3588 + imply SPL_MMC_HS200_SUPPORT if ROCKCHIP_RK3588 help Support for Arasan SDHCI host controller on Rockchip ARM SoCs platform Regards, Jonas > > Cheers, > Quentin > >> Please re-test with DDR52 mode skipped and see if you get any other >> result for HS200 mode. >> >> And you are correct, HR400ES seem to also be working fine on my RK3588 >> boards. I can see now that on my old testing commit [1] I only mention >> and drop the hs400 mode and not the hs400es mode for rk3588. Could also >> be the change to emmc_data_strobe pinctrl that got synced from linux >> v6.7 that help improve HR400ES mode results. >> >> From a very quick re-test on two boards with two different emmc modules >> I could only see a few "Select HS400 failed -70" lines being reported >> when testing read and/or write using your test loops (with a few modes >> skipped and smaller amount of data to read/write). Remaining modes seem >> to be working okay. >> >> [1] >> https://github.com/Kwiboo/u-boot-rockchip/commit/cb1521aea8dee730bddcc5772afa28aa71fc69f9 >> [2] https://lore.kernel.org/all/20231205202900.4617-2-cfswo...@gmail.com/ >> >> Regards, >> Jonas >> >>> >>> I'll check if there's an easier way to test the Linux kernel than >>> rebooting with a newer DTB between every try. >>> >>> Cheers, >>> Quentin >>> >>>>> >>>>> 2) Why are we not enabling HS400/HS400-ES for RK3588 boards? You seem to >>>>> be saying there are issues with HS400/HS400-ES on RK3568 but you didn't >>>>> mention the status for RK3588. Did I misunderstand the last sentence? >>>>> Can you please rephrase in that case? >>>> >>>> I can see now that my wording was very confusing. >>>> >>>> Write for HS400/HS400ES mode only worked on RK3568 after modification to >>>> the driver, on RK3588 write always returned error for me. >>>> >>>> So on RK3568 HS400 modes could be made work, on remaining SoCs there was >>>> issues. >>>> >>>> Regards, >>>> Jonas >>>> >>>>> >>>>> Cheers, >>>>> Quentin >>>> >>