My eMMC module is Samsung KLMCG4JETD-B041 (without any FORESEE engraving), and 5A is V1.1.
So we now have five different modules with this issue (two Samsung, two Foresee and one Kioxia).
5A corrupts eMMC (was 5A does not boot)
I’d try setting them to 10.
I’ll give it a try tomorrow.
It doesn’t help. Also in rkr4 the max value of it is 6.
arm64: dts: rockchip: use rk3588s-pinconf.dtsi for rk3588s/rk3588
The rk3588s/rk3588 SoCs have 4 level for io drive-strength
2'b00: 2.5mA 100ohm
2'b01: 5mA 50ohm
2'b10: 7.5mA 33ohm
2'b11: 10mA 25ohm
Use rk3588s-pinconf.dtsi to only define specified drive strength levels.
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
Change-Id: Ibed41ab49cc0c0f955448dd1d0b75e57ce4cac63Hi @RadxaYuntian and all,
I’ve seen these EMMC issues on several RockPi4 boards (4b v1.4, 4b v1.5, 4SE and 4b+ v1.73), with different EMMC modules (3 Foresee, 1 Samsung) and throughout different kernels (v6.1.8 through 6.1.32, 6.3, 6.3.0-rc7-next-20230421). They all have the issues documented in Rock4 SE emmc input/output errors, read only FS.
However, with this Radxa Debian 10 image that uses kernel 4.4.154-116-rockchip-g86a614bc15b3 #1 SMP Mon Jan 10 12:03:08 UTC 2022 aarch64 GNU/Linux all of the EMMC modules work just fine.
The same holds true for another Debian 10 image with kernel 4.4.154-00039-g00fccd37c63c-dirty (root@runner-2jxcrytt-project-2069-concurrent-0) (gcc version 7.3.1 20180425 [linaro-7.3-2018.05 revision d29120a424ecfbc167ef90065c0eeb7f91977701] (Linaro GCC 7.3-2018.05) ) #1 SMP Fri Oct 29 12:46:00 CEST 2021.
The interesting thing here is, that both 4.4 kernels have HS400 enabled (and max-frequency=<150000000> set) in their respective device-trees. This can be checked in the repo for 4.4.154-116-rockchip-g86a614bc15b3 and for 4.4.154-00039-g00fccd37c63c. I also confirmed this by extracting the device tree from the live systems. So there’s no DT overlay being applied on the live system changing these properties.
From these findings I doubt this is a hardware issue or a HS400 mode issue with certain modules as all these modules were working fine in older kernels. Setting the MMC mode to HS200 might be a workaround to the problems observed but I suspect the root of the issue to be somewhere else.
I believe the issue was introduced with kernels 5.x and was never properly addressed as various kernel repos carry custom MMC related patches for 5 series kernels. Of course there is the possibility of hardware issues that only surfaced with newer versions of the MMC drivers in newer kernels. But since EMMCs of different manufacturers are affected in the same way this seems like a more fundamental problem.
Bisecting from one of the known good revisions of the 4.4 kernels to a known bad revision in the Radxa kernel tree might yield new insights into the source of the problem. However I’m not sure how viable this approach is as the 5.x kernel branches don’t seem to be descendents of the 4.4 branches containing the good commits…
Kind regards!
Have you tried enabling mmc-hs400-enhanced-strobe in the DTS?
Not sure why it’s disabled here. It avoids tuning completely and should be more reliable.
We recently added the HS200 workaround for ROCK 4 as well.
We have updated default kernel to use HS200 now. The updated kernel should be available in production channel soon.
Unfortunately those are not part of our rkr3.4 based kernel at the moment. Do you mean backporting?
Armbian has been using rkr3.6/rkr4 for a long time, a user from discord has solved his emmc issue by reverting these two commits. But maybe you can cherry-pick them to rkr4 to see if it helps.
Switching to HS400ES mode does the trick.
So far so good with rkr4. I’ll keep tracking it.
I was also wondering why it’s commented out.
hs200: ok
hs400: err
hs400es: ok
rock@rock-5a:~$ sudo dmesg | grep mmc
[ 10.392417] dwmmc_rockchip fe2c0000.mmc: IDMAC supports 32-bit address mode.
[ 10.392446] dwmmc_rockchip fe2c0000.mmc: Using internal DMA controller.
[ 10.392458] dwmmc_rockchip fe2c0000.mmc: Version ID is 270a
[ 10.392513] dwmmc_rockchip fe2c0000.mmc: DW MMC controller at irq 77,32 bit host data width,256 deep fifo
[ 10.392663] dwmmc_rockchip fe2c0000.mmc: Looking up vmmc-supply from device tree
[ 10.393319] dwmmc_rockchip fe2c0000.mmc: Looking up vqmmc-supply from device tree
[ 10.393994] sdhci-dwcmshc fe2e0000.mmc: Looking up vmmc-supply from device tree
[ 10.394010] sdhci-dwcmshc fe2e0000.mmc: Looking up vmmc-supply property in node /mmc@fe2e0000 failed
[ 10.395976] sdhci-dwcmshc fe2e0000.mmc: Looking up vqmmc-supply from device tree
[ 10.395991] sdhci-dwcmshc fe2e0000.mmc: Looking up vqmmc-supply property in node /mmc@fe2e0000 failed
[ 10.418869] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
[ 10.428029] mmc0: SDHCI controller on fe2e0000.mmc [fe2e0000.mmc] using ADMA
[ 10.461446] mmc0: Host Software Queue enabled
[ 10.461458] mmc0: new HS400 Enhanced strobe MMC card at address 0001
[ 10.461985] mmcblk0: mmc0:0001 064G02 58.2 GiB
[ 10.462131] mmcblk0boot0: mmc0:0001 064G02 partition 1 8.00 MiB
[ 10.462279] mmcblk0boot1: mmc0:0001 064G02 partition 2 8.00 MiB
[ 10.462537] mmcblk0rpmb: mmc0:0001 064G02 partition 3 4.00 MiB, chardev (237:0)
[ 10.465466] mmcblk0: p1
[ 12.913855] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data mode. Opts: (null)
[ 13.707883] EXT4-fs (mmcblk0p1): re-mounted. Opts: commit=600,errors=remount-roOn ROCK 4 HS400ES was not working so it had to be changed to HS200. Granted RK3588 is different from RK3399 but I’d err on the safe side for now.
Better if you can send an internal ticket to Rockchip and investigate if it’s a kernel driver issue.
1 Like
I would like to test the images.
When will we be able to dl the test images?
I think it would actually be better to enable HS400ES rather than bottlenecking the interface like this. And maybe also backport the DLL fixes from newer rkr to be safe.
If you still get reports of non-working eMMC, then it may be considered to force HS200.
Though the fact that the HS400 tuning algorithm only fails on 5A and not the 5B could mean there’s some hardware signal integrity issues.
FWIW, HS400ES is enabled on all other RK3588 boards.
EDIT: @GinKage reported on Discord that HS400ES does not fix the issue on rkr4 with his eMMC module.
@RadxaYuntian Additionally you might consider an inquiry to the linux-rockchip mailing list. So people can follow the discussion and upstream also profits from a possible fix making life easier for everyone.
Thank you for the valuable information. I also purchased Rock5A and a 64GB eMMC from allnetchana, and I am facing similar issues. I understand from reading this post that updating the kernel might solve the problem. While it may be off-topic for individual threads, could you please tell me how to update the kernel?
https://wiki.radxa.com/Rock5/guide/build-kernel-on-5b
I think this page provides instructions for building the kernel for Rock5B, but can I use it as it is? When I tried using “./build/mk-kernel.sh rk3588-rock-5a,” it resulted in an error. So, is it correct to use “./build/mk-kernel.sh rk3588-rock-5b” instead?
Kernel should be updated via normal system upgrade procedure, i.e sudo apt update && sudo apt full-upgrade. You could also run this command via our rsetup tool.