(06-14-2021, 02:01 AM)ootoovak Wrote: 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:
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.