PINE64
Maintained Linux booting from eMMC - Printable Version

+- PINE64 (https://forum.pine64.org)
+-- Forum: ROCKPRO64 (https://forum.pine64.org/forumdisplay.php?fid=98)
+--- Forum: Linux on RockPro64 (https://forum.pine64.org/forumdisplay.php?fid=101)
+--- Thread: Maintained Linux booting from eMMC (/showthread.php?tid=14197)

Pages: 1 2


Maintained Linux booting from eMMC - ootoovak - 06-14-2021

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

I was using Ayufan's Ubuntu before I was concerned about the fact that it isn't well maintained and thus could be vulnerable to security exploits since the last stable release.

I also now feel like I've tried all the version of Linuxes listed on the wiki page and so far only older version of Armbian seems to boot from the eMMC module. Unfortunately, last time I tried to set it up for my use case (as a Docker host) the older version of the Linux kernel stopped progress!

I was hopeful something like SkiffOS using Gentoo would help being custom built but I've run into some walls getting it to build or copy over to the eMMC so I'm stuck there too.

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!


RE: Maintained Linux booting from eMMC - LMM - 06-20-2021

Hi ootoovak,
   I had the same problem : was using ayufan but I had some difficulties to enable the br_netfilter to work with docker. Now I am using the new Armbian with Focal and sometime Buster ( I have several Rockpro64 boards) with :
- emmc
- nvme
- sd (for tests)

and it is working well

but I do not use GUI with the emmc but only with the nvme (now the prices are now very close and even cheaper per GB). My usage is mainly for apps dev (web, navigation, visual code, docker, kubernetes ...) this is not a high expectation/resource demanding usage 

You eventually could try twister OS whose maintainer is very active in this forum (I have not tried yet this OS).

I also suppose that the OS available on the pineBook pro laptop is also compatible with Rockpro (should ask in pinebook forum).

It is true that it is frustrating not to have all ported in arn64 in general and for rockpro64 specifically concerning drivers.

Installing Armbian in emmc is straighforward. You can easily configure with armbian-config command. The GUI is rather usual.

If you have some difficulties do no hesitate to post a message.
LMM


RE: Maintained Linux booting from eMMC - MisterA - 06-28-2021

For me Armbian focal or TwisterOS is not booting from eMMC. Could you point me in the right direction on how to get it going?

For being a so called long term supported board, the support from the manufacturer is rather non existant if you ask me.


RE: Maintained Linux booting from eMMC - ootoovak - 06-28-2021

(06-28-2021, 01:08 PM)MisterA Wrote: For me Armbian focal or TwisterOS is not booting from eMMC. Could you point me in the right direction on how to get it going?

For being a so called long term supported board, the support from the manufacturer is rather non existant if you ask me.

Yeah, I fully agree and this has been my experience as well. Neither the latest Armbian or TwisterOS booted from eMMC for me either.

I also agree how disappointing it is how unsupported this board seems especially when you compare it to the support other SBC boards have. The community seems to be doing what it can but where is even the guidance from Pine64?


RE: Maintained Linux booting from eMMC - dukla2000 - 06-29-2021

(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.

I was using Ayufan's Ubuntu before I was concerned about the fact that it isn't well maintained and thus could be vulnerable to security exploits since the last stable release.

...
Just upgrade Ubuntu to hirsute. The kernel can upgrade at most to 4.4.202 in my experience otherwise you start losing support for various Rockchip functions. If you want you can load Ayufan 5.12 image but as you have found you lose eMMC support etc.

Methinks the major issue is Rockchip not upgrading. But also Armbian and others may work with other eMMC chips/sizes but certainly not with mine.


RE: Maintained Linux booting from eMMC - TRS-80 - 07-06-2021

Armbian mainline (5.10.y) kernel booted fine for me, I installed it by simply burning directly to eMMC using Pine's USB adapter. Even if you don't have one of those, (as someone mentioned above) you can use armbian-config, which in turn calls nand-sata-install if you need to install to eMMC from an SD card for instance.

TwisterOS is just Armbian with some GUI and graphical tweaks on top, geared towards desktop and gaming. But now Armbian themselves are finally publishing their own desktop images (currently experimental).

Getting these devices to boot and work is not like regular x86 GNU/Linux because of all the blobs and boot loader peculiarities. Which is sort of the raison d'être for Armbian in the first place. So, unless you are very handy with kernel patching and understanding how ARM devices boot, most people are better off just using Armbian IMO.


RE: Maintained Linux booting from eMMC - paralin1 - 03-16-2022

I see you mentioned SkiffOS, please post an issue on the repo about the EMMC for rockpro64, and we're happy to help.


RE: Maintained Linux booting from eMMC - ajtravis - 03-19-2022

(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/Flashing-U-Boot-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/bullseye/main/installer-arm64/current/images/netboot/SD-card-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.php?thread/39490-install-omv6-on-debian-11-bullseye/

Let me know how you get on,

  Tony.


RE: Maintained Linux booting from eMMC - paralin1 - 03-19-2022

Currently testing megis 5.17.x kernel on the rockpro64 with SkiffOS/Buildroot:

https://github.com/skiffos/SkiffOS/blob/master/configs/pine64/common/buildroot/kernel

... and will be supporting rockpro64 w/ any other distro running in containers for the foreseeable future. not dropping support.

[Image: xTpRsRz.png]


RE: Maintained Linux booting from eMMC - davidlsbc - 04-03-2022

I have a question about twister for the pinebook pro.  This is probably a noob question but here it goes.  The wiki says after flashing the twister image, to edit the /boot/armbianEnv.txt file.  I have tried multiple times to edit the file but it is read only (I assume since it is mounted).  I must be missing something but have found no documentation as to how to resolve.