[PATCH 1/3] rockchip: rk35xx: Remove use of eMMC DDR52 mode

Jonas Karlman jonas at kwiboo.se
Sat Feb 3 16:03:58 CET 2024


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-CFSworks@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
>>>>
>>



More information about the U-Boot mailing list