Hi @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!