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


Reply via email to