Maintained Linux booting from eMMC

[ajtravis]

Does anyone know of an actively maintained Linux that works on RockPro64 running off of the eMMC? If so please post in a reply.

[...]
This is a SUPER frustrating experience (in fact most of my Pine64 experiences have been frustrating due to software issues, OS stuff mainly). Short of learning how to build and patch my own Linux (I'm technical but that is well out of my experience) I'm at a bit of loss as what to do.

(Side question: Does anyone else find the Pine64 boards frustrating due to OS support issues?)

In any case please, if you have them, post links or instructions as to how you got an actively maintained Linux booting off of the eMMC for RockPro64 thank you!

Hi,

I thought my Rockpro64 was DOA because it would not boot from eMMC - I wrote Armbian images to eMMC using a USB adapter, then plugged the eMMC module into the Rockpro64. It was only when my friend tried booting it from a SD that we realised my board was actually working. After spending months of experimenting with different OS images and replacing the eMMC module I've concluded that the Rockpro64 will not boot directly from eMMC. However, a simple work-around is to install u-boot in the SPI:

https://github.com/sigmaris/u-boot/wiki/...oot-to-SPI

At first, it might not detect the eMMC and try to boot from the network. If that happens, you need to press a key repeatedly as soon as "u-boot" starts to interrupt the auto-boot, then identify which mmc device your eMMC is using:

Code:

mmc dev 0
mmc dev 1
mmc dev 2
mmc list

This will list the mmc devices and tell you which is the eMMC - In my case the eMMC is mmc0, so boot it like this:

Code:

run bootcmd_mmc0

The u-boot running from SPI will now look for the /boot files on eMMC and boot the kernel

Getting the image onto eMMC is affected by a serious BUG that many people have reported about the Rockpro64 suffering a Kernel OOPs when doing 'large' writes to any media other than the internal SD-card. Over the past several months I've struggled to find out why this happens and, like many before me, have burnt the midnight oil Googling (DuckDuckGo, actually) for a solution for weeks on end without finding any real solution.

I've come up with a solution that mitigates the problem by mounting filesystems in "sync" mode:

Code:

diff -Naur /usr/sbin/nand-sata-install /usr/local/sbin/nand-sata-install-sync
--- nand-sata-install    2021-08-06 15:37:59.000000000 +0100
+++ nand-sata-install-sync    2022-03-18 19:33:11.293772310 +0000
@@ -81,7 +81,7 @@
        [[ -n $1 ]] && mount ${1::-1}"1" "${TempDir}"/bootfs
        [[ -n $2 ]] && ( mount -o compress-force=zlib "$2" "${TempDir}"/rootfs 2> /dev/null || mount "$2" "${TempDir}"/rootfs )
    else
-        [[ -n $2 ]] && ( mount -o compress-force=zlib "$2" "${TempDir}"/rootfs 2> /dev/null || mount "$2" "${TempDir}"/rootfs )
+        [[ -n $2 ]] && ( mount -o sync "$2" "${TempDir}"/rootfs 2> /dev/null || mount "$2" "${TempDir}"/rootfs )
        [[ -n $1 && $1 != "spi" ]] && mount "$1" "${TempDir}"/bootfs
    fi
    rm -rf "${TempDir}"/bootfs/* "${TempDir}"/rootfs/*

Then, use the patched "nand-sata-install-sync" to install the OS from SD to eMMC without causing a Kernel OOPs. However, you will need to edit the /etc/fstab on the installed system to use "sync" mode. On my Rockpro64 it looks like this:

Code:

cat /etc/fstab
# <file system>    <mount point>    <type>    <options>    <dump>    <pass>
#tmpfs    /tmp    tmpfs    defaults,nosuid    0    0
UUID=8aa44704-1b24-45fe-b76c-fea8055d4936    /    ext4    defaults,discard,sync,noatime,commit=600,errors=remount-ro,x-gvfs
-hide    0    1
UUID=c1dfaebc-8416-442e-831c-92148fdf5a91    -    swap    sw    0    0
UUID=761f37cb-3107-4834-9d45-904ce1b71e5d    /home    ext4    defaults,sync    0    0

There is CLEARLY a problem with the Rockpro64, because this OOPs occurs using eMMC, NVMe and USB with different media and different filesystems (ext4, ZFS and btrfs). It also occurred when I tried to directly copy the eMMC module to another one in a USB adapter:

Code:

dd if=/dev/mmcblk2 of=/dev/sda obs=1M conv=fsync,notrunc

However, it works without an OOPs if I use a smaller block size:

Code:

dd if=/dev/mmcblk2 of=/dev/sda obs=64K conv=fsync,notrunc

Everything works, but, as you might expect, "sync" mode makes disk writes slow and may wear SSD's more. It also makes a nonsense of using an NVMe SSD. However, the system is rock-solid now and although I don't know enough about the kernel to actually pin-point the problem and fix it, I can at least use my Rockpro64 now!

I'm a bit worried that Armbian are going to drop support for the Rockpro64, so I've installed Debian 11 (Bullseye).

https://deb.debian.org/debian/dists/bull...rd-images/

The installer works perfectly writing to SD, but crashes badly trying to install to eMMC, NVMe or USB showing the same Kernel OOPs when writing a lot to disk. However, I used a USB serial adapter connected to the UART pins to open a shell in the Installer "screen" window. It's not obvious how to do this unless you know it's running "screen"(!). Use CTRL+A 2" to switch to the shell window, and when the installer mounts the target filesystems remount them in "sync" mode:

Code:

mount -o remount,sync /target
mount -o remount,sync /target/boot
mount -o remount,sync /home

Then I installed OMV like this:

https://forum.openmediavault.org/index.p...-bullseye/

Let me know how you get on,

  Tony.