5A corrupts eMMC (was 5A does not boot)

#104

I think this is the solution. You might add an overlay that sets the speed to HS400 for “known good” EMMCs, but I doubt something better will be found (except a new HW revision maybe).

#105

One way to “fix” it is to use Orange Pi eMMC modules instead of the ones sold at AllNet China (Samsung ones, to be specific). These are dirt-cheap and have no issues with 5A and HS400ES.

#106

We just created a RC build for ROCK 5A which contains the HS200 fix. We should have an official release soon.

I think this is something we could do but probably in a future release.

#107

Is it possible for Orange pi emmc to work with Rock 5A after writing the image with emmc witer purchased from allnet china?
If it is possible, I will give it a try.

#108

the connector should work in the same way on the rock and on the eMMC writer

#109

Just to add data to the pile, I got a 5A yesterday, and tried it with a 64GB module from Hardkernel that I got with an Odroid-N2 a while ago. With the Radxa b16 image I get a steady stream of errors on any attempted write.This module is a KLMCG4JETD-B041.

As expected, Armbian works just fine. I installed from the 23.5.4 Jammy Legacy image linked from Armbian’s rock5b page. The userland has upgraded to 23.08.0-trunk Jammy but the kernel is still 5.10.160-rk35xx

I have an OrangePi module coming (thanks for the tip on the cheap 256GB!) as well as a 64GB from Allnet and will report back on those.

Given that Radxa’s solution for their builds appears to be slowing down to HS200, I guess I’ll stick with Armbian.

2 Likes
#110

I also have this problem. I wrote Armbian_23.5.4_Rock-5a_bookworm_legacy_5.10.160_minimal.img to the 16GB emmc I bought together with the Rock 5A from allnetchina, using the USB emmc writer also from allnetchina.

It boots up and I can ssh in and perform the first configuration steps. I have tried from the initial Armbian image three times now. It always ends up with block I/O errors within 5-15 minutes. I even managed to do the first apt update/dist-upgrade once. But eventually after too many write operations the I/O errors show up.

Is there a workaround/solution? Thanks.

# dmesg | grep -i mmc
[    8.667384] dwmmc_rockchip fe2c0000.mmc: IDMAC supports 32-bit address mode.
[    8.667406] dwmmc_rockchip fe2c0000.mmc: Using internal DMA controller.
[    8.667417] dwmmc_rockchip fe2c0000.mmc: Version ID is 270a
[    8.667469] dwmmc_rockchip fe2c0000.mmc: DW MMC controller at irq 77,32 bit host data width,256 deep fifo
[    8.667562] dwmmc_rockchip fe2c0000.mmc: Looking up vmmc-supply from device tree
[    8.670355] sdhci-dwcmshc fe2e0000.mmc: Looking up vmmc-supply from device tree
[    8.670376] sdhci-dwcmshc fe2e0000.mmc: Looking up vmmc-supply property in node /mmc@fe2e0000 failed
[    8.672722] sdhci-dwcmshc fe2e0000.mmc: Looking up vqmmc-supply from device tree
[    8.672741] sdhci-dwcmshc fe2e0000.mmc: Looking up vqmmc-supply property in node /mmc@fe2e0000 failed
[    8.673116] dwmmc_rockchip fe2c0000.mmc: Looking up vqmmc-supply from device tree
[    8.688728] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
[    8.704207] mmc0: SDHCI controller on fe2e0000.mmc [fe2e0000.mmc] using ADMA
[    8.742961] mmc0: Host Software Queue enabled
[    8.742988] mmc0: new HS400 Enhanced strobe MMC card at address 0001
[    8.744191] mmcblk0: mmc0:0001 AJTD4R 14.6 GiB 
[    8.744619] mmcblk0boot0: mmc0:0001 AJTD4R partition 1 4.00 MiB
[    8.745064] mmcblk0boot1: mmc0:0001 AJTD4R partition 2 4.00 MiB
[    8.745384] mmcblk0rpmb: mmc0:0001 AJTD4R partition 3 4.00 MiB, chardev (237:0)
[    8.750791]  mmcblk0: p1
[    9.325467] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data mode. Opts: (null)
[   10.049354] EXT4-fs (mmcblk0p1): re-mounted. Opts: commit=600,errors=remount-ro
[   13.060354] blk_update_request: I/O error, dev mmcblk0, sector 2708872 op 0x1:(WRITE) flags 0x4800 phys_seg 7 prio class 0
[   13.060374] EXT4-fs warning (device mmcblk0p1): ext4_end_bio:347: I/O error 10 writing to inode 2180 starting block 338687)
[   13.060388] Buffer I/O error on device mmcblk0p1, logical block 334513
[   13.060428] Buffer I/O error on device mmcblk0p1, logical block 334514
[   13.060436] Buffer I/O error on device mmcblk0p1, logical block 334515
[   13.060441] Buffer I/O error on device mmcblk0p1, logical block 334516
[   13.060447] Buffer I/O error on device mmcblk0p1, logical block 334517
[   13.060455] Buffer I/O error on device mmcblk0p1, logical block 334518
[   13.060461] Buffer I/O error on device mmcblk0p1, logical block 334519
[   13.060465] Buffer I/O error on device mmcblk0p1, logical block 334520
[   13.060470] Buffer I/O error on device mmcblk0p1, logical block 334521
[   13.060475] Buffer I/O error on device mmcblk0p1, logical block 334522
#111

There’s an RC build a few posts up that slows down the MMC to HS200 to make it work. Or you could run Armbian, which doesn’t seem to have this problem.

1 Like
#112

Bad. The only thing I would try: add a serial console and log on another machine. Maybe the kernel said something before reboot …

#113

I do run the latest Armbian image and I experience the problem! I/O errors after a while during extensive writes. Only with EMMC. No problems with SD card.

#114

Interesting. I haven’t done a ton with my 5a yet, but haven’t seen the issue in Armbian… so maybe it’s waiting for me. I’m going to go with one of the big OrangePi emmcs anyway, which is also reported not to have the issue. One of the motivations for using this hardware at all is fast eMMC to reduce boot time. If crippling that is going to be the solution, I might just go back to better supported hardware.

Edit: I’d think this is in the kernel, but I’m running bullseye, not bookworm.

#115

Armbian does definitety not help here (and how, mostly the same kernel). I have the same problem. Try the HS200 patch.

1 Like
#116

This would be great, since as of now this revision could be considered defective and it’s not providing the best it could do. I didn’t buy this because I wanted a compromised product.

1 Like
#117

New image has been released aiming to have eMMC boot working out of the box.

1 Like
#118

I just tried the new Armbian image (Armbian_23.5.4_Rock-5a_jammy_legacy_5.10.160.img.xz) and it still corrupts the file system on the eMMC.
[edit] Oh, as already noted above

#119

@mo123 its fixed.

#120

I’m new to SBC, and I have a question. Why does the eMMC from Orange Pi work fine, but the one from Rock doesn’t? Additionally, if I upgrade the system on the currently working eMMC, will it downgrade my eMMC speed to HS200?

#121

Yeah. So it’s not really a “fix” but maybe a band-aid, as it breaks more stuff.

1 Like
#122

Why does the eMMC from Orange Pi work fine, but the one from Rock doesn’t?

Please read the discussion above, not just the thread title. The modules are based on different chips. Much bigger question is: why do the same modules work fine on 5B, but not 5A.

2 Likes
#123

Just FYI, I compiled armbian 23.8.1 with that PR and it runs nicely from eMMC now where before it was always failing w/ write errors. If I may @ amazingfate, you are the maintainer of armbian for rock-5a, no? Just asking (not complaining) if there is a reason for not changing the upstream in 23.8