Similarly, I am having trouble booting Rock 5A from emmc.
After powering on, the blue LED does not light up or even if it does
dimmc_rockhip fe2c0000.mmc: busy; trying anyway
and cannot proceed to the next step.
I would like to know the solution.
The emmc and power supply are purchased from allnet china.
5A corrupts eMMC (was 5A does not boot)
Like what @GinKage said, I was not able to reproduce this on 16GB Foresee eMMC module. I recently worked around a different eMMC issue on ROCK 4 by reducing to HS200 so I’ll test if that solves the issue.
@dylandn @hiro and @nyanmisaka please leave your eMMC size and model here as well.
One official Foresee 64G eMMC module from Allnet and one homebrew KIOXIA 64G eMMC module (THGAMRG9T23BAIL). Both of them work fine with the official USB 3 eMMC reader and Rock 5B.
iIt’s a Samsung 16GB KLMAG1JETD-B041
@RadxaYuntian Also confirmed that downgrading to HS200 fixes the issue on my 5A with the 64G eMMC modules. So I’m guessing there might be a compatibility issue with the board itself.
Actually I think it was Foresee having issue at HS400. We reproduced the issue in our office, and I’ll try adjust pin drive as suggested above.
Still need to figure out why Samsung was not working for @dylandn though.
I tried to increase it from level 2 to 5 but it didn’t help. Is it still safe to set this to higher values?
The maximum value of it is 15 - pcfg_pull_up_drv_level_15
In which case I think drive strength is unlikely to be the issue here. I’ll validate HS200 internally and create a PR if that solves the issue.
My module seems to be identical to dylandn’s, identified in dmesg as “CJTD4R 58.2 GiB”.
Update: scratch that, my module has different capacity, I’ll post the part number later today.
Can you take a picture of the front and back of your ROCK 5A and eMMC module?
I want to know the hardware version of ROCK 5A and the brand and capacity of eMMC module.
I use the following emmc bought from allnet china.
EMMC 5.1 FOR ROCK 4 / 3A / 5B / 5A / E (ALSO FOR ODROID) 32GB
emmc writer uses the following emmc writer purchased from allnet china
EMMC TO USD BOARD
product page
Does your eMMC chip has FORESEE engraving?
Yes, there is FORESEE engraving
Is there any other information you need?
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).
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!