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

Fri Feb 2 12:10:39 CET 2024

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.

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.

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?

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