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.
5A corrupts eMMC (was 5A does not boot)
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.
the connector should work in the same way on the rock and on the eMMC writer
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
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 334522There’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
Bad. The only thing I would try: add a serial console and log on another machine. Maybe the kernel said something before reboot …
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.
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.
Armbian does definitety not help here (and how, mostly the same kernel). I have the same problem. Try the HS200 patch.
1 Like
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
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
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?
Yeah. So it’s not really a “fix” but maybe a band-aid, as it breaks more stuff.
1 Like
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
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
I’m running Armbian_23.8.3_Rock-5a_bookworm_legacy_5.10.160 on my 5A on the 32GB eMMC and encountering the same issues:
2023-11-22T04:32:30.647396+00:00 rock-5a kernel: [ 3249.196325] blk_update_request: I/O error, dev mmcblk0, sector 1634664 op 0x1:(WRITE) flags 0x20800 phys_seg 1 prio class 0
2023-11-22T04:32:30.647469+00:00 rock-5a kernel: [ 3249.196340] blk_update_request: I/O error, dev mmcblk0, sector 1634664 op 0x1:(WRITE) flags 0x20800 phys_seg 1 prio class 0
2023-11-22T04:32:30.647477+00:00 rock-5a kernel: [ 3249.196426] Aborting journal on device mmcblk0p1-8.
2023-11-22T04:32:30.660685+00:00 rock-5a kernel: [ 3249.210743] EXT4-fs error (device mmcblk0p1): ext4_journal_check_start:83: Detected aborted journal
2023-11-22T04:32:30.660739+00:00 rock-5a kernel: [ 3249.210752] EXT4-fs (mmcblk0p1): Remounting filesystem read-only
2023-11-22T04:32:30.660742+00:00 rock-5a kernel: [ 3249.210776] EXT4-fs (mmcblk0p1): failed to convert unwritten extents to written extents -- potential data loss! (inode 279746, error -30)
2023-11-22T04:32:30.660747+00:00 rock-5a kernel: [ 3249.210954] EXT4-fs (mmcblk0p1): failed to convert unwritten extents to written extents -- potential data loss! (inode 279747, error -30)
2023-11-22T04:32:30.660751+00:00 rock-5a kernel: [ 3249.211016] EXT4-fs (mmcblk0p1): failed to convert unwritten extents to written extents -- potential data loss! (inode 279748, error -30)
2023-11-22T04:32:30.660755+00:00 rock-5a kernel: [ 3249.211071] EXT4-fs (mmcblk0p1): failed to convert unwritten extents to written extents -- potential data loss! (inode 279749, error -30)
2023-11-22T04:32:30.661355+00:00 rock-5a kernel: [ 3249.211117] EXT4-fs (mmcblk0p1): failed to convert unwritten extents to written extents -- potential data loss! (inode 279750, error -30)
2023-11-22T04:32:30.663963+00:00 rock-5a kernel: [ 3249.212815] EXT4-fs (mmcblk0p1): failed to convert unwritten extents to written extents -- potential data loss! (inode 279852, error -30)
2023-11-22T04:32:30.663997+00:00 rock-5a kernel: [ 3249.212927] EXT4-fs (mmcblk0p1): failed to convert unwritten extents to written extents -- potential data loss! (inode 279743, error -30)
2023-11-22T04:32:30.664001+00:00 rock-5a kernel: [ 3249.213000] EXT4-fs (mmcblk0p1): failed to convert unwritten extents to written extents -- potential data loss! (inode 279744, error -30)
2023-11-22T04:32:30.664003+00:00 rock-5a kernel: [ 3249.213101] EXT4-fs (mmcblk0p1): failed to convert unwritten extents to written extents -- potential data loss! (inode 279745, error -30)
I am seeing this after running for ~10 minutes. I was able to install packages and do some work, but then it suddenly switches to read-only mode. This has happened twice now, the first time I was running Ubuntu so I switched to Armbian to see if that would help.
Anyone else still having issues? Am I running the right version?
There’s a known quirk on rockchip’s emmc controller against certain emmc modules.
You can rebuild the kernel or image with this patch and see if it helps.
2 Likes