The repository introduces a new ffmpeg package that integrates and substitues the base ffmpeg package and its related packages.

Preconditions:

• Mainline kernel 6.1 or more recent
• armhf or arm64 architecture
• Supported distributions:
  • Debian 12 - Bookworm
  • Debian 13 - Trixie
  • Ubuntu 22.04 - Jammy
  • Ubuntu 24.04 - Noble
• Rockchip and Allwinner have already been tested, but this should work on other platforms with stateless decoders supported in kernel

APT REPOSITORY SETUP

To install the repository, just copy and paste the lines in a terminal:

$ sudo wget http://apt.undo.it:7242/apt.undo.it.asc -O /etc/apt/trusted.gpg.d/apt.undo.it.asc
$ . /etc/os-release && echo "deb http://apt.undo.it:7242 $VERSION_CODENAME main" | sudo tee /etc/apt/sources.list.d/apt.undo.it.list
$ echo -e "Package: *\nPin: release o=apt.undo.it\nPin-Priority: 600" | sudo tee /etc/apt/preferences.d/apt-undo-it

INSTALL FFMPEG AND MPV PACKAGES

$ sudo apt update
$ sudo apt install ffmpeg mpv

SETUP MPV CONFIG FILE

$ sudo mkdir -p /etc/mpv
$ echo -e "hwdec=drm\ndrm-drmprime-video-plane=primary\ndrm-draw-plane=overlay" | sudo tee /etc/mpv/mpv.conf

You can now play your videos using mpv and they should run with hardware decoding if supported, either in virtual terminals or in X11/Wayland windows!

Enjoy!

Notes:

• your mileage may vary a lot: the more recent is the kernel version, the better is support (you may need edge kernel)
• bug: when rendered in X11/Wayland window, video may show scattered tiles during frames
• bug: Lima driver (Mali 400/450) shows a red/pink tint when video is played in X11/Wayland (see https://github.com/mpv-player/mpv/issues/12968) (workaround below: https://forum.armbian.com/topic/32449-repository-for-v4l2request-hardware-video-decoding-rockchip-allwinner/?do=findComment&comment=177968)
• you may want to add --gpu-hwdec-interop=drmprime-overlay to the mpv command line if used in pure virtual terminal (no X, no Wayland) to use direct-to-overlay output
• Panfrost driver should work flawlessy
• 10 bit HEVC are generally supported on all Rockchip devices (rk322x, rk3288, rk33x8, rk3399), but Allwinner H3 have no hardware support for that

(new, fully rewritten, replaces my earlier tutorial on this topic)

MMGen (https://github.com/mmgen)

This tutorial provides detailed, step-by-step instructions for setting up full root filesystem encryption on an Armbian system.  The disk can be unlocked remotely via SSH or the serial console, permitting unattended bootup.

An automated script that performs the same steps, saving you much time and effort, can be found at https://github.com/mmgen/mmgen-geek-tools

Note that unlike my earlier tutorial all steps are performed within a running Armbian system.

The tutorial is known to work with the following board/image combinations (plus possibly others—follow the comments in this thread for additional info):

* Boards/images in bold blue type are personally tested by the author. Others may have issues or require additional steps provided by users below.

** For instructions on how to adapt this tutorial for the Raspberry Pi, see here (instructions are provided by a third party and are untested by the author).

You may have success with other boards/images too. If so, please post the details below (or open an issue in the mmgen-geek-tools Github repository), and I’ll add your board to the list.

Requirements:

• A SoC with a running, upgradeable and Internet-connected Armbian system
• A blank Micro-SD card and USB card reader, or, alternatively, an eMMC installed on the board
• The ability to edit text files and do simple administrative tasks on the Linux command line

Step 1 - Preliminaries

All steps in this tutorial are performed as root user on a running Armbian system (the “host”).

The encrypted system (the “target”) will be created on a blank micro-SD card (the “target device”).

If the board has an eMMC, it may be used as the target device instead of an SD card. Depending on your platform, you may need to run “armbian-install” and select “Install/Update the bootloader on MTD Flash” (preferable) or “Install/Update the bootloader on eMMC” to enable booting from the eMMC.

Architecture of host and target (e.g. 64-bit or 32-bit ARM) must be the same.

For best results, the host and target hardware should also be identical or similar.  Building on a host with more memory than the target, for example, may lead to disk unlocking failure on the target.

If you’re building the target system for the currently running board and with the currently running image, which is the recommended approach, the two preceding points will be a non-issue.

Packages will be installed using APT, so the host machine must be Internet-connected and its clock correctly set.

Step 2 - Upgrade your system and install the cryptsetup package

# apt update && apt upgrade
# apt install cryptsetup

Step 3 - Get and unpack the latest Armbian image for your board

Create your build directory:

# mkdir armbenc-build && cd armbenc-build

Download the Armbian image of your choice for your board, place it in this directory and unpack:

# xz -dv *.img.xz

Step 4 - Create mount directories and set up the loop mount

Create the mount directories:

# mkdir -p mnt boot root

Determine your first free loop device:

# losetup -f

Associate the image file with the loop device name displayed by the previous command.  This will be '/dev/loop0' in most cases, but if your output was different, substitute that for '/dev/loop0' in the following steps.

# losetup -P /dev/loop0 *.img

Examine the disk image using fdisk on the loop device:

# fdisk -l /dev/loop0

The output should look something like this:

Device        Start      End  Sectors  Size Type
/dev/loop0p1  32768 61931519 61898752 29.5G Linux filesystem

Make a note of the start sector (32768 in this case).  You’ll need this value in the steps below.

Now mount the loop device:

# mount /dev/loop0p1 mnt

Step 5 - Copy the boot loader to the target device

If applicable, insert a blank micro-SD card and card reader into a USB port.

Determine the target device name using 'dmesg' or 'lsblk'.  We’ll assume it to be '/dev/sda', since that’s the most likely case.  If your device name is different, substitute it for '/dev/sda' in the the following steps.  For an eMMC, the device name will be something like '/dev/mmcblk1'.

WARNING: if '/dev/sda' refers to some other storage device, running the following commands unchanged will destroy data on that device, so always remember to substitute the correct device name!!!  The best way to eliminate this danger is to disconnect all unused storage devices on the board before proceeding further.

Determine whether your image has a GPT partition table or a legacy MBR (i.e. DOS) one. This can be done by running fdisk -l on the image file and examining the “Disklabel type” entry. For GPT images, also make note of the value in the “Type” column. On ARM devices, it’s likely to be “Linux root (ARM-64)”, for example. You’ll need this information soon when partitioning the target device:

# fdisk -l *.img

Copy the image’s boot loader to the target device. With MBR-partitioned images, we use the Start sector value from Step 4 as the argument for 'count', while with GPT ones we skip the first 64 sectors and correspondingly subtract 64 from 'count', reducing the number of copied sectors by 64:

### MBR (DOS) images:
# dd if=$(echo *.img) of=/dev/sda bs=512 count=32768

### GPT images:
# dd if=$(echo *.img) of=/dev/sda bs=512 skip=64 seek=64 count=32704

Step 6 - Partition the target device

# fdisk /dev/sda

At the fdisk prompt, create a new disk label with the 'o' command (for MBR images) or 'g' (for GPT images).  Use the 'n' command to create a partition of size +400M beginning at the same Start sector as the disk image (for MBR images, select the “primary” partition type).  Type 'p' to view the partition table, which should now look something like this:

Device     Start       End   Sectors  Size Type
/dev/sda1  32768    851967    819200  400M Linux root (ARM-64)

Use 'n' again to create another partition beginning one sector after the first partition’s end sector and filling the remainder of the device (for MBR, select “primary” again). Type 'p' once more to view the partition table:

Device     Start       End   Sectors  Size Type
/dev/sda1  32768    851967    819200  400M Linux root (ARM-64)
/dev/sda2 851968 120829951 119977984 57.2G Linux root (ARM-64)

Ensure that the first partition’s Start sector matches that of the disk image (32768 in this example) and that the second partition’s Start sector is one greater than the End sector of the first (851967 and 851968, respectively, in this example).  If you’ve made a mistake, use 'd' to delete a partition and start again.

With GPT images, you’ll need to change the partition type of your two partitions to match that of the image. Type 'l' to list the known partition types and find the entry matching the value of the “Type” column you made note of above. Note the entry’s integer code and exit the pager with 'q'. Using the 't' command, change the type of your two partitions using this code. Type 'p' once again to view the partition table, which should now look something like this (depending on your platform):

Device      Boot  Start      End  Sectors  Size Id Type
/dev/sda1         32768   442367   409600  200M 83 Linux root (ARM-64)
/dev/sda2        442368 30636031 30193664 14.4G 83 Linux root (ARM-64)

Once everything looks correct, type 'w' to write the partition table to disk.

Step 7 - Copy the system to the target device

The following commands will create a filesystem on the target device’s boot partition and copy the boot partition data from the image file to it.  Don’t forget to substitute the correct device name if necessary.  If you’re building the system on an eMMC, the boot partition device will be something like '/dev/mmcblk1p1' instead of '/dev/sda1'.

 # mkfs.ext4 /dev/sda1            # or '/dev/mmcblk1p1', for an eMMC target
 # e2label /dev/sda1 CRYPTO_BOOT
 # mount /dev/sda1 boot
 # cp -av mnt/boot/* boot
 # (cd boot; ln -s . boot)

Create the encrypted root partition.  When prompted for a passphrase, it’s advisable to choose an easy one like 'abc' for now.  The passphrase can be changed later with the 'cryptsetup luksChangeKey' command (type 'man cryptsetup' for details) once your encrypted system is up and running.

# cryptsetup luksFormat /dev/sda2 # or '/dev/mmcblk1p2', for an eMMC target

Activate the encrypted root partition and create a filesystem on it:

# cryptsetup luksOpen /dev/sda2 rootfs  # enter your passphrase from above
# mkfs.ext4 /dev/mapper/rootfs

Mount the encrypted root partition and copy the system to it:

# mount /dev/mapper/rootfs root
# (cd mnt && rsync -a --info=progress2 --exclude=boot * ../root)
# sync # be patient, this could take a while
# mkdir root/boot
# touch root/root/.no_rootfs_resize

Unmount the boot partition and image and free the loop device:

# umount mnt boot
# losetup -d /dev/loop0

Step 8 - Prepare the target system chroot

# BOOT_PART=($(lsblk -l -o NAME,LABEL | grep CRYPTO_BOOT))
# ROOT_PART=${BOOT_PART%1}2
# ROOT_UUID="$(lsblk --nodeps --noheadings --output=UUID /dev/$ROOT_PART)"
# BOOT_UUID="$(lsblk --noheadings --output=UUID /dev/$BOOT_PART)"

# cd root
# mount /dev/$BOOT_PART boot
# mount -o rbind /dev dev
# mount -t proc proc proc
# mount -t sysfs sys sys

Copy '/etc/resolv.conf' and '/etc/hosts' so you’ll have a working Internet connection within the chroot:

# cat /etc/resolv.conf > etc/resolv.conf
# cat /etc/hosts > etc/hosts

If you’re using non-default APT repositories, you may need to copy their configuration files as well so that 'apt update' and 'apt install' will use them inside the chroot.  Note that you can only do this if the host and target systems have the same distro/version.  If that’s not the case, you’ll have to edit the target files by hand.

# cat /etc/apt/sources.list > etc/apt/sources.list
# cat /etc/apt/sources.list.d/armbian.list > etc/apt/sources.list.d/armbian.list

If you’re using an apt proxy, then copy its configuration file too:

# cp /etc/apt/apt.conf.d/*proxy etc/apt/apt.conf.d/

Step 9 - Edit or create required configuration files in the target system

Perform the editing steps below using a text editor of your choice:

1. If the file 'boot/armbianEnv.txt' exists, edit it so that the 'rootdev', 'console' and 'bootlogo' lines read as follows.  If you’ll be unlocking the disk via the serial console, then use 'console=serial' instead of 'console=display'. Note that enabling the serial console will make it impossible to unlock the disk from the keyboard and monitor, though unlocking via SSH will still work:

   rootdev=/dev/mapper/rootfs
   console=display
   bootlogo=false
   

2. If your image lacks an 'armbianEnv.txt' file, you’ll need to edit the file 'boot/extlinux/extlinux.conf' instead. All changes will be made to the line beginning with “append”. Alter the argument beginning with “root=” so that it reads “root=/dev/mapper/rootfs”. If you’ll be unlocking the disk via the serial console, remove the “console=tty1” argument. If not, remove the argument beginning with “console=ttyS...”. Replace the “splash plymouth...” argument with “splash=verbose”. Make sure to read the note about unlocking via serial console in the previous step.

3. Edit 'etc/initramfs-tools/initramfs.conf'.  If your board will have a statically configured IP, add the following line to the end of the file, substituting the correct IP in place of 192.168.0.88:

   IP=192.168.0.88:::255.255.255.0::end0:off

   If the board will be configured via DHCP, then edit the DEVICE line as follows:

   DEVICE=end0

   If your default network device has a different name, say eth0, then use that instead of end0. The device name can be discovered by issuing the command ip link and looking for the device labelled link/ether.

4. If host and target systems are both Debian buster, you may wish add some key modules to the initramfs to avoid a blank display at bootup time.  The easiest way to do this is to add all currently loaded modules as follows:

   # lsmod | cut -d ' ' -f1 | tail -n+2 > etc/initramfs-tools/modules
   

5. Retrieve the SSH public key from the remote unlocking host and copy it to the target:

   # mkdir -p etc/dropbear/initramfs
   # rsync yourusername@remote_machine:.ssh/id_*.pub etc/dropbear/initramfs/authorized_keys
   

   If you want to unlock the disk from more than one host, then edit the authorized_keys file by hand, adding the required additional keys.

6. Create 'etc/crypttab':

   # echo "rootfs UUID=$ROOT_UUID none initramfs,luks" > etc/crypttab
   

7. Create 'etc/fstab':

   # echo '/dev/mapper/rootfs / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1' > etc/fstab
   # echo "UUID=$BOOT_UUID /boot ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 2" >> etc/fstab
   # echo 'tmpfs /tmp tmpfs defaults,nosuid 0 0' >> etc/fstab
   

8. Create the dropbear configuration file:

   # echo 'DROPBEAR_OPTIONS="-p 2222"' > etc/dropbear/initramfs/dropbear.conf
   # echo 'DROPBEAR=y' >> etc/dropbear/initramfs/dropbear.conf
   

    

9. If the target is Ubuntu bionic, then a deprecated environment variable must be set as follows:

   # echo 'export CRYPTSETUP=y' > etc/initramfs-tools/conf.d/cryptsetup

    

10. Set up automatic disk unlock prompt. Performing this optional step will cause the disk password prompt to appear automatically when you log in remotely via SSH to unlock the disk. Using your text editor, create the file 'etc/initramfs-tools/hooks/cryptroot-unlock.sh' with the following contents:

    #!/bin/sh
    
    if [ "$1" = 'prereqs' ]; then echo 'dropbear-initramfs'; exit 0; fi
    
    . /usr/share/initramfs-tools/hook-functions
    
    source='/tmp/cryptroot-unlock-profile'
    
    root_home=$(echo $DESTDIR/root-*)
    root_home=${root_home#$DESTDIR}
    
    echo 'if [ "$SSH_CLIENT" ]; then /usr/bin/cryptroot-unlock; fi' > $source
    
    copy_file ssh_login_profile $source $root_home/.profile
    
    exit 0
    

     

11. Save the file and execute the command:

    chmod 755 'etc/initramfs-tools/hooks/cryptroot-unlock.sh'

     

Step 10 - Chroot into the target system, install packages and configure

Now chroot into the encrypted system.  All remaining steps will be performed inside the chroot:

# chroot .

Install the cryptsetup package and the dropbear SSH server:

# apt update
# echo 'force-confdef' > /root/.dpkg.cfg
# apt --yes install cryptsetup-initramfs dropbear-initramfs # for a buster or focal image
# apt --yes install cryptsetup dropbear-initramfs           # for a bionic image
# rm /root/.dpkg.cfg

Make sure everything was included in the initramfs (all three commands should produce output):

# lsinitramfs /boot/initrd.img-* | grep 'usr.*cryptsetup'
# lsinitramfs /boot/initrd.img-* | grep dropbear
# lsinitramfs /boot/initrd.img-* | grep authorized_keys

Now regenerate your SSH host keys:

# ssh-keygen -A

Your work is finished! Exit the chroot and shut down the board:

# exit
# halt -p

Insert your freshly written SD card into the board’s main SD slot (or, if the target is an eMMC, just remove the SD card from that slot) and reboot.

Unlock the disk by executing the following command on your remote unlocking machine, substituting the correct IP address if necessary:

$ ssh -p 2222 root@192.168.0.88

If you performed step 9.10 above, the disk password prompt should appear automatically after login.  If not, you must enter the command 'cryptroot-unlock'.

You may also unlock the disk from the target board’s console if you wish.  Note, however, that certain disk images (RockPi 4 buster mainline, for example) might give you a blank display at startup, so you’ll have to enter your disk password “blindly”.  This bug will hopefully be fixed in the future.

If all went well, your root-filesystem encrypted Armbian system is now up and running!

This example will expect dtb directories (or links) to be in the /boot directory, using the convention that I've seen Armbian use. Here is an example of a /boot directory listing for (pure) Debian Trixie with two kernels:

-rw-r--r-- 1 root root   336036 Aug 27 04:10 config-6.12.43+deb13-arm64
-rw-r--r-- 1 root root   343394 Sep  6 12:48 config-6.16.3+deb13-arm64
lrwxrwxrwx 1 root root       42 Sep 20 16:17 dtb -> ../usr/lib/linux-image-6.16.3+deb13-arm64/
lrwxrwxrwx 1 root root       43 Sep 20 16:17 dtb-6.12.43+deb13-arm64 -> ../usr/lib/linux-image-6.12.43+deb13-arm64/
lrwxrwxrwx 1 root root       42 Sep 20 16:18 dtb-6.16.3+deb13-arm64 -> ../usr/lib/linux-image-6.16.3+deb13-arm64/
drwxr-xr-x 3 root root     4096 Sep 20 15:13 efi
drwxr-xr-x 5 root root     4096 Sep 20 16:26 grub
lrwxrwxrwx 1 root root       29 Sep 15 21:30 initrd.img -> initrd.img-6.16.3+deb13-arm64
-rw------- 1 root root 42521317 Sep 20 16:26 initrd.img-6.12.43+deb13-arm64
-rw------- 1 root root 43760872 Sep 20 16:25 initrd.img-6.16.3+deb13-arm64
lrwxrwxrwx 1 root root       30 Sep 15 20:38 initrd.img.old -> initrd.img-6.12.43+deb13-arm64
-rw-r--r-- 1 root root       83 Aug 27 04:10 System.map-6.12.43+deb13-arm64
-rw-r--r-- 1 root root       92 Sep  6 12:48 System.map-6.16.3+deb13-arm64
lrwxrwxrwx 1 root root       26 Sep 15 21:30 vmlinuz -> vmlinuz-6.16.3+deb13-arm64
-rw-r--r-- 1 root root 37449664 Aug 27 04:10 vmlinuz-6.12.43+deb13-arm64
-rw-r--r-- 1 root root 41507328 Sep  6 12:48 vmlinuz-6.16.3+deb13-arm64
lrwxrwxrwx 1 root root       27 Sep 15 20:38 vmlinuz.old -> vmlinuz-6.12.43+deb13-arm64

Note: The relative pathways of the dtb links above assume that the /boot directory is part of the main OS partition, not on its own boot partition. Otherwise you'd need to copy those directories to /boot/ as Armbian does.

For The Current Partition's OS Entries (each devicetree will be specific to the respective kernel)

1. Open the file with a text/source editor (using sudo):

/etc/grub.d/10_linux

2. Find every line that looks something like this (currently on my system, there is only one, and it's line 189)

linux	${rel_dirname}/${basename} root=${linux_root_device_thisversion} ro ${args}

3. Just above it, add your own system's version of this line:

devicetree ${rel_dirname}/dtb-${version}/[VENDOR SUB-DIRECTORY]/[SBC PRODUCT].dtb

Specific Example: OrangePI-5-Plus

devicetree ${rel_dirname}/dtb-${version}/rockchip/rk3588-orangepi-5-plus.dtb

Specific Example from the resulting grub.cfg, of the current trixie-backport kernel, again on the OrangePI-5-Plus:

devicetree /boot/dtb-6.16.3+deb13-arm64/rockchip/rk3588-orangepi-5-plus.dtb

For Other Partitions' OS Entries, via os-prober (I'm unfamiliar with the variables in this so each devicetree will be the same generic path, regardless of kernel)

1. Open the file with a text/source editor (using sudo):

 /etc/grub.d/30_os-prober

2. Find every line that looks something like this (currently on my system, there are two, lines 277 and 297)

linux ${LKERNEL} ${LPARAMS}

3. Just above it, add your own system's version of this line:

devicetree /boot/dtb/[VENDOR SUB-DIRECTORY]/[SBC PRODUCT].dtb

Specific Example: OrangePI-5-Plus

devicetree /boot/dtb/rockchip/rk3588-orangepi-5-plus.dtb

Then run update-grub, and take a look at the resulting /boot/grub/grub.cfg

https://gist.github.com/ag88/65db5434158683e43d1cc77c337ebdb5

• Introduction

Rpi-monitor
https://github.com/XavierBerger/RPi-Monitor
is a very nice app for monitoring sbc (single board computers/ actually bigger computers as well) like RPi on a web.
it gives you a quick look at various system metrics cpu load, uptime, temperatures etc and more on a nice web page.
and on top, makes nice time series graphs for the same, practically a dashboard.

• Installing in Armbian 25.8 for Orange Pi Zero 3

Rpi-monitor is normally not found in the common Apt repositories and actually the binary is a little old.
I tried installing it based on the 'formal' docs but hit some invalid public keys errors, possibly expired certs.
https://xavierberger.github.io/RPi-Monitor-docs/11_installation.html

so here is a 'workaround'

•  Deb packages for rpi-monitor

you can find the packages in this repository (note that this may not be permanant and may change)
https://github.com/XavierBerger/RPi-Monitor-deb

use the **rpimonitor_latest.deb** file
https://github.com/XavierBerger/RPi-Monitor-deb/tree/develop/packages

• install rpimonitor_latest.deb in Armbian

use apt to install *rpimonitor_latest.deb* as it has varous package dependencies. 
e.g. download it to a folder and from there run

sudo apt install ./rpimonitor_latest.deb 

the prior step should install rpimonitor, and check that the service is running by going to  http://your_sbc_ip_address:8888

• checking the setup
•  

rpi-monitor is runa as a systemd (unit) service 

if it is not running you can try 

systemctl status rpimonitor.service

or 
 

journalctl -u rpimonitor.service

to check what went wrong.

to start / stop rpi-monitor it is as per basic systemd services e.g.

systemctl start rpimonitor.service

•  temperature 'not displaying'

apparently, it is affected by this issue:
https://github.com/XavierBerger/RPi-Monitor/issues/374

accordingly the fix/'workaround' is edit /etc/rpimonitor/template/temperature.conf
replace

#dynamic.1.postprocess=sprintf("%.2f", $1/1000)
dynamic.1.postprocess=$1/1000

> apt update
...
Err:8 https://github.armbian.com/configng stable InRelease               
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 93D6889F9F0E78D5
...
W: Failed to fetch https://github.armbian.com/configng/dists/stable/InRelease  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 93D6889F9F0E78D5

observed in Armbian image for Orange pi zero 3 Armbian_community_25.8.0-trunk.90_Orangepizero3_bookworm_current_6.12.30_minimal.img build date May 28, 2025

fix:

- run this as root

> su - 
^ login as root
> wget -O - https://apt.armbian.com/armbian.key | gpg --dearmor -o /usr/share/keyrings/armbian.gpg

you should find a file /usr/share/keyrings/armbian.gpg about 2 KB in size

repeat apt update etc should have resolved the error

Yesterday I spend the whole day to install Armbian Desktop (XFCE) on my Pinebook Pro.

Why Armbian ?

The PBP was delivered with Manjaro Arm on it. Everything worked fine until Manjaro stopped support for the Arm platform.

For about one year there is no update on stable and the unstable branch couldn't establish a connection to Wifi.

I used Manjaro Arm to install tow-boot to the SPI following this website:

https://forum.pine64.org/showthread.php?tid=17529

 I downloaded the current Bookworm XFCE edition and wrote that to an SD card.

Booting from the SD with tow-boot went fine. I installed armbian on the SD card and used armbian-config to install

it on the internal eMMC.

That didn't work.

fsarchiver to the rescue !

I created a GPT partition table on the internal disk, created two partitions with the correct flags and restored

both partitions from the SD saved with fsarchiver to the internal disk.

Booting went fine from the internal disk after that.

Now I am fighting with firefox ("Can't read configuration file - contact your systemadministrator") and the nextcloud client.

I can't add a online account anywhere. The application starts up but there is no button execpt (Information about ...)

which shows the supported clients a.o. Owncloud (which will work with nextcloud) but there is no way to add an account.

I'll open other posts to track that.

Hi all. 
In this video I show how to use armbian-gamingX86. A script to install Steam, PPSSPP, Retropie and Xonotic on Armbian Jammy/Noble X86.
 

Here link to armbian-gamingX86 : https://github.com/NicoD-SBC/armbian-gamingX86

Here my video about it.

Cheers, NicoD

Reposting this below just in case it may be useful 

----

how i set it up

https://gist.github.com/ag88/de02933ba65500376d1ff48e504b1bf3

---

 Imho for WiFi purposes nmcli (network manager cli) is not very different from hostapd, just that hostapd possibly has more configuration options.

To setup an access point, there are quite a few pieces of network configuration that needs to be setup:

• The WiFi AP itself (e.g. using network manager or hostapd) if you are able to connect and verify that in the log, that is probably solved. e.g.

journalctl -u NetworkManager
or for hostapd
journalctl -u hostapd

hostapd tends to have log entries for every host that connects, I'm not sure about NetworkManager.

• DHCP (issuing IP address to connected hosts) this is particularly true for IPv4 hosts on dynamic IP.
  DHCP would likely also need to distribute the DNS server, so configure that if it isn't done.
  e.g. https://ubuntu.com/server/docs/how-to-install-and-configure-isc-dhcp-server
• For IPv6 you may need to setup radvd (router advertisement daemon)  https://en.wikipedia.org/wiki/Radvd so that the connected hosts can setup their own IPv6 address
  quite often IPV6 requires its own /64 address range / network (* note below dnsmasq does this as well) e.g.

apt install radvd

https://wiki.archlinux.org/title/IPv6#For_gateways

• Configure the WiFi AP as a router or bridge.
• Router:

• note that if you are using hostapd and not using a network bridge and there are no DHCP servers, you would need to configure the wlan0 interface with an ip address and network using say ip commands e.g.
  (ref: https://wiki.debian.org/NetworkConfiguration)

  /etc/network/interfaces

  source /etc/network/interfaces.d/*
  # Network is managed by Network manager
  auto lo
  iface lo inet loopback
  # added the following
  auto wlan0
  iface wlan0 inet static
  address 192.168.1.1
  netmask 255.255.255.0

• To run it as a router, you would need to do DHCP (and RADV) for your WiFi hosts as above
  For such reasons, I tend to use isc-dhcp-daemon so that I can configure the dhcpd precisely as I needed. But I'd guess it may be possible with Network manager. (* note below dnsmasq does this as well) e.g.
  https://ubuntu.com/server/docs/how-to-install-and-configure-isc-dhcp-server

apt install isc-dhcp-server

• Configure routing and/or IP NAT (e.g. IP masquerading). I've tried IP NAT and that sometimes it is easier as up stream normally only a single IP address is needed.
  
  Routing would need a subnet to be setup, that is normally ok but that you would need to configure your main gateway router as well for the overall network setup so that it knows where/how to forward packets. many consumer getway/routers simply used NAT, that is ok as well. But that your main gateway/router may need a static route to say that for that subnet, send it to your OPi Zero 3 Wifi AP.

• Bridging:
• To run it as a bridge you would need to setup the zero 3 WiFi AP as a bridge. This can be done using nmcli (network manager). In fact, this is my own personal preference for a small network.
  e.g.  
  https://www.cyberciti.biz/faq/how-to-add-network-bridge-with-nmcli-networkmanager-on-linux/
  https://gist.github.com/ag88/de02933ba65500376d1ff48e504b1bf3
• DHCP (and RADV) can be done from the main gateway/router so long as the bridged packets reaches the WiFi hosts. Similarly, the DNS server likely needs to be distributed this way as well

I've not done it completely from within nmcli for this setup as I used hostapd for the WiFi AP. But that I used nmcli (network manager) for the bridge.

But that those notes above remains similar whether you used network manager or hostapd.

take note that with hostapd for WiFi AP, you probably need to un-manage the Wifi interface in Network Manager configs so that it doesn't conflict with hostapd.

https://gist.github.com/ag88/de02933ba65500376d1ff48e504b1bf3

oh and when messing with network interfaces use a debug usb-uart serial dongle or you may get 'locked out' from your zero 3

Apparently, dnsmasq does all three: DNS, DHCP, RADV

https://thekelleys.org.uk/dnsmasq/doc.html

but that there may be some configurations that are needed for it to work correctly

https://docs.fedoraproject.org/en-US/fedora-server/administration/dnsmasq/

https://wiki.archlinux.org/title/Dnsmasq

(Disclaimer: The following is for techies only that like to dig a bit deeper. And if you're not interested in energy-efficient servers then probably this is just a waste of time  ) 

EDIT: Half a year after this poorly designed SBC has been released just one of the many design flaws has been fixed: Micro USB for DC-IN has been replaced by the barrel jack that was present on the pre-production batches. If you were unfortunate to get a Micro USB equipped M3 please have a look here how to fix this. Apart from that check the Banana forums what to expect regarding software/support first since this is your only source)

SinoVoip sent me a review sample of the recently shipped so called "Banana Pi M3" yesterday. It's a SBC sharing name and form factor of older "Banana Pi" models but is of course completely incompatible to them due to a different SoC, an A83T (octa-core Cortex-A7 combined with a PowerVR SGX544 GPU). For detailed and up-to-date informations please always refer to the linux-sunxi wiki.

This new model distinguishes itself from the Banana Pi M2 with twice as much CPU cores and DRAM (LPDDR3), 8 GB eMMC onboard and BT4.0. And compared to the "M1" (the original Banana Pi) it features also 802.11 b/g/n Wi-Fi. Unlike the M2 the M3 is advertised as being SATA capable. But that's not true, it's just an onboard GL830 USB-to-SATA bridge responsible for horribly slow disk access. Unfortunately the GL830 and both externally available USB ports are behind an internal USB hub therefore all ports have to share bandwidth this way and use just one single USB connection to the SoC.

Since my use cases for ARM boards are rather limited you won't find a single word about GPIO stuff (should work if pin mappings are defined correctly), GPU performance, BT, Wi-Fi or Android. Simply because I don't care 

Getting Started:

The board arrived without additional peripherals (no PSU) therefore you need an USB cable using a Micro-USB connector to power the board. Both DC-IN and USB-OTG feature an Micro-USB connector which is bad news since pre-production samples had a real DC-In connector (4.0mm/1.7mm barrel plug, centre positive like the M2). I suffered from several sudden shutdowns under slight load until I realized that I used a crappy cable. Many (most?) USB cables lead to voltage drops and when the board demands more power it gets in an undervoltage situation and the PMU shuts off.

Same will happen to you unless you can verify that you've a good cable. I did not succeed querying the M3's powermanagement unit (PMU) regarding available voltage (/sys/devices/platform/axp81x_board/axp81x-supplyer.47/power_supply/ac/voltage_now shows always 0). This was a lot easier with the older Banana Pi M1: Here you can watch my cable being responsible for voltage drops under high load (I accidentally used this again with the M3).

To avoid the crappy Micro-USB connector (limited to 1.8A maximum by specs and tiny contacts) you can desolder it and solder a cable or a barrel plug -- the PCB is already prepared for the latter. Or ask SinoVoip if they can fix this mistake with the next batch of PCBs. On the bottom side of the PCB there are also solder pads for a Li-Ion battery. It has to be confirmed whether the AXP813 PMU can also be fed with 5V through the Li-Ion connector since this is the preferred way to fix the faulty power design other SinoVoip products show.

One final word regarding power: It seems currently something's wrong with power initialisation in the early boot stages (u-boot). With a connected bus-powered USB disk the board won't start or immediately shut down when the disk is connected within the first 10 seconds. I didn't verify when exactly because if you've a look at SinoVoip's commit log it seems they began to fix many obvious bugs just right now after they already started shipping the board (we've seen that with the M2 also).

First Showstoppers:

Since the board came with an unpopulated eMMC (why the heck?) I had to try out the available OS images from the banana-pi.org download site. Unlike everyone else on this planet they don't provide MD5/SHA1 checksums to be able to check integrity of downloads and even if you tell them that they've uploaded corrupted images they don't care. From 4 OS images 3 are corrupted (according to unzip) and all failed soon after boot with kernel panics. I tried the Android image to verify FEL mode works.

But since Android is of zero use for me, I decided to build an own OS image from an Ubuntu distro running on the Orange Pi where I had the SD-card inserted. Since details are boring just as a reference. From then on I used this Ubuntu image and exchanged only the freshly built stuff from SinoVoip's BSP Github repo (3.4.39 kernel, modules, bootloader and also simple things like hardware initialisation since kernel/u-boot they prefer does NOT support script.bin)

First Impressions:

Heat (dissipation):

The A83T needs a heatsink otherwise you won't be able to benefit from its performance. Allwinner's 3.4.39 kernel provides 'budget cooling' using 2 techniques: thermal throttling and shutting down CPU cores. You can define this 'thermal configuration' in sysconfig.fex and have to take care that you understand what you're doing since if throttling doesn't help your CPU cores will be deactivated and you have to can't bring them back online manually the usual way since Allwinner's kernel doesn't allow so:

echo 1 >/sys/devices/system/cpu/cpuX/online

Therefore it's better to stay with the thermal defaults to allow throttling and improve heat dissipation instead. I used a $0.5 heatsink that performs ok. Without heatsink when running CPU intensive jobs throttling limited clockspeed to 1.2 GHz but with the heatsink I was able to run most of the times at ~1.6Ghz under full load. With heatsink and an annoying fan I managed to let the SoC run constantly at 1.8GHz and achieved a 7-zip score close to 6000 and finished "sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=8" in less than 53 seconds.

This is an example for wrong throttling values (too high) so that the kernel driver does not limit clockspeeds but starts to drop CPU cores instead:

CPU performance:

Since the H3 (used on the more recent Orange Pis) and the A83T seem to use much of the same kernel sources (especially the 'thermal stuff') I did a few short tests. When running with identical clockspeed and the same amount of cores they perform identical (that means they're slower than older Cortex-A7 SoCs like eg. the A20 when running at identical clockspeed -- a bit strange). Obviously the difference between H3 and A83T is the process. Both already made in 28nm but the A83T as 'tablet SoC' in the more energy efficient HPC process allowing less voltage and higher clockspeeds. According to sysconfig.fex the SoC should be able to clock above 2.1 GHz but since exceeding 1.6 Ghz already needs a fan this is pretty useless on a SBC (might be different inside a tablet where the back cover could be used as a large heatsink).

Network throughput:

I used my usual set of iperf testings and tried GBit Ethernet performance (with and without network tunables it remains the same -- reason below):

BPi-M3 --> Client:

[  4]  0.0-10.0 sec   671 MBytes   563 Mbits/sec
[  4]  0.0-10.0 sec   673 MBytes   564 Mbits/sec
[  4]  0.0-10.0 sec   870 MBytes   729 Mbits/sec
[  4]  0.0-10.0 sec   672 MBytes   564 Mbits/sec
[  4]  0.0-10.0 sec   675 MBytes   566 Mbits/sec

[  4]  0.0-10.0 sec   714 MBytes   599 Mbits/sec
[  5]  0.0-10.0 sec   876 MBytes   734 Mbits/sec
[  4]  0.0-10.0 sec   598 MBytes   501 Mbits/sec
[  5]  0.0-10.0 sec   690 MBytes   578 Mbits/sec
[  4]  0.0-10.0 sec   604 MBytes   506 Mbits/sec

Accessing disks:

Since there's a SATA connector on the board I gave it a try.

Important: the SATA-power connector uses the same polarity as older Banana Pis and Orange Pis (keep that in mind since combined SATA data/power cables from LinkSprite and Cubietech that share exactly the same connector use inverted polarity!).

I started with the Samsung EVO I always use for tests (but due to the old 3.4 kernel using ext4 instead of btrfs) and was shocked: 13.5/23 MB/s is the worst result I ever measured. I then realised that I limited maximum cpufreq to 480 MHz and tried with 1800 MHz again. A bit better but far away from acceptable:

GL830 USB-to-SATA performance:

480 MHz:      kB  reclen    write  rewrite    read    reread
         4096000       4    13529    13466    22393    22516
         4096000    1024    13588    13411    22717    26115
         
1.8 GHz: 4096000       4    15090    15082    30968    30316
         4096000    1024    15174    15131    30858    29441

I disconnected the SSD from the 'SATA port' and put it in an enclosure with a JMicron JMS567 USB-to-SATA bridge and measured again: Now sequential transfer speeds @ 1800 MHz exceeded 35/34 MB/s. The GL830 is responsible for low throughput -- especially writes are slow as hell.

I made then a RAID-1 through mdadm consisting of an external 3TB HDD (good news: the GL830 can deal with partitions larger than 2 TB) and the SSD. First test with the HDD connected to the M3's GL830 bridge (GL) and the SSD connected to the JMS567 (JM). Then I disconnected the HDD from the GL830 and put it in another external enclosure with an ASMedia 1053 (ASM). 

Obviously SinoVoip's decision to use an internal USB hub and only one host port of the SoC leads in both situations to limited (shared) bandwidth. But in case the internal USB-to-SATA bridge is involved performance is even worse:

GL/JM:        kB  reclen    write  rewrite    read    reread
         4096000       4    17800    17140    14382    16807
         4096000    1024    17741    17258    14493    14368

JM/ASM:  4096000       4    19307    18458    22855    26241
         4096000    1024    19231    18518    21995    22362

If SinoVoip would've saved the GL830 USB-to-SATA bridge and wired both SoC's host ports to the 2 type-A USB ports directly without the internal hub in between overall performance would be twice as good. And obviously the M3's 'SATA port' is the worst choice to connect a disk to. Any dirt-cheap external USB enclosure will perform better.

SD-card and eMMC:

Just a quick check with the usual iozone settings running @ 1.8 GHz:

              kB  reclen    write  rewrite    read    reread 
eMMC:    4096000       4    26572    27014    59187    59239
         4096000    1024    25875    26614    56587    56667

SD-card: 4096000       4    20483    20855    22473    22892
         4096000    1024    20526    19948    22285    22660

LOL, eMMC twice as fast as 'SATA'. The performance numbers of the SD-card (SanDisk "Extreme Pro") are irrelevant since I can not provide performance numbers from a known fast reference implementation. But since I might be able to provide this the next few days, I decided to give it a try. On older Allwinner SoCs there's a hard limitation regarding SDIO/SD-card speed. Maybe this applies here too.

EDIT: Yes, it's a board/SoC limitation. When reading/writing the SD-card on a MacBook Pro I achieve ~80 MB/s. It seems SDIO on A83T is limited to ~20MB/s

Other issues:

• If you want to try out the M3 you'll have to stay on the bleeding edge. Don't expect that any of the available OS images are close to useable. They just recently started to fix a lot of essential bugs in code and hardware initialisation. If you want to test the M3 be prepared to compile the BSP daily and exchange the bootloader/kernel/initialisation stuff on your SD-card/eMMC
• Currently average load is always 1 or above. When we started over 2 years ago with Cubieboards (and an outdated kernel 3.4.x) there was a similar issue. Maybe it's related. I just opened a Github issue
• Mainline kernel support in very early stage. Don't count on this that soon (situation with Banana Pi M2 was a bit different. All the OS images from SinoVoip based on kernel 3.3 weren't useable but the community provided working distros backed by the work of the linux-sunxi community and existing mainline kernel support for the M2's A31s)
• Always keep in mind that hardware without appropriate software is somewhat useless. SinoVoip has a long history of providing essential parts of software way too late or not at all (still applies to the M2 -- before you buy any SinoVoip product better have a look into their forums to get the idea which level of support you can expect: zero). Even worse: For the M2 and its A31s SoC there exists mainline kernel support (everything developed by the community while the vendor held back necessary informations). This does not apply to the A83T used on the M3. At the moment you're somewhat lost since you've to rely on the manufacturer's OS images (all of them currently being broken)

Conclusion:

Still no idea what to do with such a device.

Integer performance is great when you use a heatsink and even greater with an annoying fan. But where's the use case? If I would use the M3 with Android then everything that's relevant for performance does not depend on CPU (but instead CedarX for HW accelerated video decoding and GPU for 2D/3D acceleration -- BTW: the A83T is said to contain only a single core SGX544MP1 but the fex file's contents let me believe it's a faster MP2 instead).

Due to limited I/O and network bandwidth the integer performance is also irrelevant for nearly all kinds of server tasks. If it's just about 'SBC stuff' why wasting so much money? Triggering GPIO pins works also with cheap H3 based boards like Orange Pi PC or Orange Pi One that also have 4 times more I/O bandwidth compared to the M3 (due to 4 available USB ports instead of one).

And if I would really need a performant ARM SoC then I would buy such a thing and not an outdated Cortex-A7 design. I still have no idea what the M3 is made for. Except of selling something under the "Banana" brand to clueless people. Don't know. For my use cases the Banana Pi M1 outperforms the M3 easily -- both regarding price and performance (sufficient CPU power, 3 x USB and real SATA not 'worst USB-to-SATA implementation ever'). As usual: YMMV 

Maybe the worst design decision (next to choosing the crappy Micro-USB connector for DC-IN) on the M3 is the 'SATA port'. If they would've saved both internal USB hub and GL830 and instead use the two available USB host ports then achievable I/O bandwidth would be way higher. Now both USB ports and the 'SATA port' have to share the bandwidth of a single USB 2.0 connection. Almost as bad as with the Raspberry Pis.

But most importantly: Check software und support situation first and don't rely on 'hardware features'. Remember: SinoVoip shipped the M2 with OS images where not a single GPIO pin was defined and Ethernet worked only with 100Mb/s since they 'forgot' to define GMAC pins. They fixed that months later but still not for every OS image (the Android image they provide is corrupted since months but they don't care even if users complain several times). Visit their forums first to get an idea what to expect. It's important!

Armbian support:

Not to be expected soon. It's worthless when having to rely on Allwinner's old 3.4.39 kernel. I combined loboris' H3 Debian image with kernel/bootloader stuff for the A83T and it worked as expected (even my RPi-Monitor setup matched almost perfectly).

Unless the linux-sunxi community improves mainline support for the A83T this situation won't change. But maybe someone interested in M3 (definitely not me) teaches SinoVoip how to escape from u-boot/kernel without support for script.bin in the meantime. Would be a first step.

( https://www.friendlyarm.com/index.php?route=product/product&product_id=169 )
using kernel 4.14.87-sunxi and armbian 5.67 (or later would be only 5.65?)
(before that I did use legacy kernel 3.4.x with the PCM510A)

and the armbian-BuildSystem

plus (THANKS to) informations in threads from  @dony71 , @Christos, @Valery Rezvyakov
and the the Reference-Threads you could find above

----------------------------------------------------------------------------------------------------------------------------------
BACKUP DTB (on NanoPi Neo)
----------------------------------------------------------------------------------------------------------------------------------
cp /boot/dtb/sun8i-h3-nanopi-neo.dtb /boot/dtb/sun8i-h3-nanopi-neo.dtb_org

----------------------------------------------------------------------------------------------------------------------------------
CONVERT dtb to dts (on NanoPi Neo)
----------------------------------------------------------------------------------------------------------------------------------
dtc -I dtb -O dts /boot/dtb/sun8i-h3-nanopi-neo.dtb -o /boot/dtb/sun8i-h3-nanopi-neo.dts

----------------------------------------------------------------------------------------------------------------------------------
EDIT /boot/dtb/sun8i-h3-nanopi-neo.dts
----------------------------------------------------------------------------------------------------------------------------------

nano /boot/dtb/sun8i-h3-nanopi-neo.dts

- change: status from "disabled" to "okay"

----------------------------------------------------------------------------------------------------------------------------------
FROM
 

                i2s@1c22000 {
                        #sound-dai-cells = <0x0>;
                        compatible = "allwinner,sun8i-h3-i2s";
                        reg = <0x1c22000 0x400>;
                        interrupts = <0x0 0xd 0x4>;
                        clocks = <0x3 0x38 0x3 0x54>;
                        clock-names = "apb", "mod";
                        dmas = <0x13 0x3 0x13 0x3>;
                        resets = <0x3 0x2b>;
                        dma-names = "rx", "tx";
                        status = "disabled";
                        phandle = <0x4e>;
                };

TO
 

                i2s@1c22000 {
                        #sound-dai-cells = <0x0>;
                        compatible = "allwinner,sun8i-h3-i2s";
                        reg = <0x1c22000 0x400>;
                        interrupts = <0x0 0xd 0x4>;
                        clocks = <0x3 0x38 0x3 0x54>;
                        clock-names = "apb", "mod";
                        dmas = <0x13 0x3 0x13 0x3>;
                        resets = <0x3 0x2b>;
                        dma-names = "rx", "tx";
                        status = "okay";
                        phandle = <0x4e>;
                };

----------------------------------------------------------------------------------------------------------------------------------
CONVERT (BACK) dts to dtb (on NanoPi Neo)
----------------------------------------------------------------------------------------------------------------------------------
dtc -I dts -O dtb /boot/dtb/sun8i-h3-nanopi-neo.dts -o /boot/dtb/sun8i-h3-nanopi-neo.dtb_I2S_okay

----------------------------------------------------------------------------------------------------------------------------------
COPY new dtb over dtb (on NanoPi Neo)
----------------------------------------------------------------------------------------------------------------------------------
cp /boot/dtb/sun8i-h3-nanopi-neo.dtb_I2S_okay /boot/dtb/sun8i-h3-nanopi-neo.dtb
                
----------------------------------------------------------------------------------------------------------------------------------
COPY sun8i-h3-I2S-out.dts to home (working directory on NanoPi Neo)
----------------------------------------------------------------------------------------------------------------------------------
copy sun8i-h3-I2S-out.dts -->  /home/guido/

----------------------------------------------------------------------------------------------------------------------------------
armbian-add-overlay (on NanoPi Neo)

does only work if you got the kernel-headers installed for your actual kernel-version

(at this time the lastest kernel-header are (via armbian-config -> Software -> Install Headers)

Linux kernel headers for 4.14.84-sunxi on armhf - so NOT for kernel 4.19.y)
----------------------------------------------------------------------------------------------------------------------------------
root@npi-neo(192.168.6.24):/home/guido# armbian-add-overlay ./sun8i-h3-I2S-out.dts
Compiling the overlay
Copying the compiled overlay file to /boot/overlay-user/
Reboot is required to apply the changes

----------------------------------------------------------------------------------------------------------------------------------
dtbo is created (on NanoPi Neo)
----------------------------------------------------------------------------------------------------------------------------------
root@npi-neo(192.168.6.24):/home/guido# ls -l /boot/overlay-user/
insgesamt 4
-rw-r--r-- 1 root root 1323 Dez  7 19:34 sun8i-h3-I2S-out.dtbo

----------------------------------------------------------------------------------------------------------------------------------
user-overlay is created in /boot/armbianEnv.txt (on NanoPi Neo)
----------------------------------------------------------------------------------------------------------------------------------

verbosity=1
logo=disabled
console=both
disp_mode=1920x1080p60
overlay_prefix=sun8i-h3
overlays=usbhost1 usbhost2
rootdev=UUID=33ca90d6-130b-4d5f-a8f4-95b3b97ef5c0
rootfstype=ext4
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u
user_overlays=sun8i-h3-I2S-out

----------------------------------------------------------------------------------------------------------------------------------
now REBOOT (on NanoPi Neo)

----------------------------------------------------------------------------------------------------------------------------------

root@npi-neo(192.168.6.24):~# lsmod|grep i2s

sun4i_i2s              16384  0
snd_soc_core          118784  2 sun4i_i2s,sun8i_codec_analog
snd_pcm                69632  3 sun4i_i2s,snd_pcm_dmaengine,snd_soc_core
 

----------------------------------------------------------------------------------------------------------------------------------
EDIT config-default.conf (on armbian-BuildSystem)
----------------------------------------------------------------------------------------------------------------------------------
cd /home/guido/build
nano ./config-default.conf

replace content /home/guido/build/config-default.conf with attached
config-default.conf_nanopineo

./compile

-> With this conf, script compilation will stop to overwrite kernel source to build patch
-> At that time, overwrite original Kconfig with the one you modified above

(at "Make changes to U-Boot" press ENTER to proceed)

wait for
"Make your changes to /home/guido/build/cache/sources/linux-mainline/linux-4.14.y then press ENTER"
BUT DONT PRESS ENTER YET

----------------------------------------------------------------------------------------------------------------------------------
EDIT/SAVE Kconfig in a 2nd shell-Window (on armbian-BuildSystem)
----------------------------------------------------------------------------------------------------------------------------------
nano /home/guido/build/cache/sources/linux-mainline/linux-4.14.y/sound/soc/codecs/Kconfig

the part FROM
 

config SND_SOC_PCM5102A
    tristate

TO
 

config SND_SOC_PCM5102A
    tristate "Texas Instruments PCM5102A CODEC - I2S"

----------------------------------------------------------------------------------------------------------------------------------
NOW PRESS ENTER in the 1st shell-Windows (.compile.sh) (on armbian-BuildSystem)

----------------------------------------------------------------------------------------------------------------------------------

-> Then script compilation will stop again to ask whether you want to add pcm5102a to compile
-> Default is N, so you need to enter m for module compilation
Texas Instruments PCM5102A CODEC - I2S (SND_SOC_PCM5102A) [N/m/?] (NEW) m = m for module compilation
 

After compile is complete
 

----------------------------------------------------------------------------------------------------------------------------------
copy (via SCP/FTP?) the .deb's from /home/guido/build/output/debs (on armbian-BuildSystem) 
to /home/guido/ (on the NanoPi Neo)

----------------------------------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------------------------------
INSTALL the .deb's (here only header and image - because it was already 5.67 (on NanoPi Neo)
----------------------------------------------------------------------------------------------------------------------------------
cd /home/guido 
dpkg -i ./linux-headers-next-sunxi_5.67_armhf.deb
dpkg -i ./linux-image-next-sunxi_5.67_armhf.deb
(image did include the .ko module for the pcm5102a)

----------------------------------------------------------------------------------------------------------------------------------

now REBOOT (on NanoPi Neo)
----------------------------------------------------------------------------------------------------------------------------------

=====================================================================================
=====================================================================================
!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ATTENTION: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
After reboot my NanoPi Neo show the following armbian-version:
ARMBIAN 5.65 stable Debian GNU/Linux 9 (stretch) 4.14.84-sunxi
and 2 upgrades for headers&image (without the PCM5102A support)

please keep in mind to freeze the kernel-updates in armbian-config
for not to loose the support (module) for the PCM5120A!
armbian-config -> system -> Freeze Disable kernel upgrades
=====================================================================================
=====================================================================================

----------------------------------------------------------------------------------------------------------------------------------
BE HAPPY about a successful i2s mapping in dmesg (on NanoPi Neo)
----------------------------------------------------------------------------------------------------------------------------------
root@npi-neo(192.168.6.24):~# dmesg|grep -i i2s
[    6.911751] asoc-simple-card sound_i2s: pcm5102a-hifi <-> 1c22000.i2s mapping ok

----------------------------------------------------------------------------------------------------------------------------------
I enabled also ananlog-Codec (on NanoPi Neo)
----------------------------------------------------------------------------------------------------------------------------------
root@npi-neo(192.168.6.24):/home/guido# aplay -l
**** Liste der Hardware-Geräte (PLAYBACK) ****
Karte 0: Codec [H3 Audio Codec], Gerät 0: CDC PCM Codec-0 []
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 1: I2Smaster [I2S-master], Gerät 0: 1c22000.i2s-pcm5102a-hifi pcm5102a-hifi-0 []
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0

----------------------------------------------------------------------------------------------------------------------------------
/etc/asound.conf (on NanoPi Neo) - later I2S did switch automatically to card 0
----------------------------------------------------------------------------------------------------------------------------------
 

pcm.!default {
    type hw
    card 1
    device 0
}

ctl.!default {
    type hw
    card 1
}

----------------------------------------------------------------------------------------------------------------------------------
Reference-Threads
----------------------------------------------------------------------------------------------------------------------------------

config-default.conf.mod_nanopineo

sun8i-h3-I2S-out.dts

I've created a tool to install Box86, Box64 and Wine onto Armbian Hirsute 5.13

I've tested it on RK3399. Should work on any device with panfrost drivers enabled.

Please let me know on what it works, or if it doesn't.

Here is the script.
https://github.com/NicoD-SBC/armbian-gaming

I also made a video where I show how to use it.

It is on https://github.com/pavlot-scriptec/scriptec-blog/blob/main/customize_armbian_image_using_extensions.md

Also I have created extension to enable Waveshare 3.5 TFT displays for RPi (and maybe other platforms).

Any feedback is wellcome

I wanted an as light as possible desktop environment so I'd have enough ram left to do video rendering with the NanoPi M4(2GB)
I had to try a lot of things to get things working fine. So I wanted to save others that hassle.

Setting up Display Manager

First we need a Display Manager. NODM is installed by default. I tried lightdm but couldn't get it to work. So I went for LXDM. With NODM installed I had problems, so I also removed NODM.
To be sure lxdm is configured right, I also manually configure it.

sudo apt install lxdm
sudo apt remove nodm
sudo dpkg-reconfigure lxdm

Install LXDE Desktop

Next step is to install the desktop environment you want. There is a problem with some Desktop Environments and LXDM what makes you can't login to some DE's out of the box. That we will resolve later. Easiest is to install lxdm first to be able to configure the others well. And reboot.

sudo apt install lxde
sudo reboot

Once booted you should be greeted by the Login screen. Here you can choose your different Desktop Environment. Choose LXDE and login.
If you'd try xfce4, then you'd see it doesn't work. To fix this we need to change the file /usr/share/xsessions/xfce.desktop. Use your favorite text editor. I use geany.
 

sudo geany /usr/share/xsessions/xfce.desktop

Somewhere at the top of the file you'll see "Name=Xfce Session". Replace that space with a hyphen to "Name=Xfce-Session" and save the file.
Now you can also login to the default XFCE4 Desktop.
With other desktops this can be the same. Go the the same directory and open the file with the desktop name that doesn't work. Again replace the space with a hyphen
 

Installing different Desktop Environments.

For the Mate desktop I also needed to install the applets, else I got errors at login because of these missing applets

sudo apt install mate-desktop-environment mate-applets

For KDE-Plasma

sudo apt install kde-full

For Gnome. Modify the file sudo geany /usr/share/xsessions/gnome...

sudo apt install gnome-session
sudo update-alternatives --config gdm3.css

I also tried LXQT. But this one didn't work. You can try others too.

Remove Desktop Environment

To remove a desktop environment you don't want anymore you do the remove instead of install.

sudo apt remove kde-full 
sudo apt remove mate-desktop-environment
.
.
.

Please let me know if there's mistakes made, or if you've got advice.
Source for changing the name to make them work @IgorS :

Greetings, NicoD

Is there anyone who tried to run Docker on armbian?

Ok, let's start from the beginning: I am from the Hypriot Team (we made Docker available on ARM) and recently saw some guys successfully playing with Docker on armbian. Meanwhile, we know, that our Docker runs at least on the Cubietrack and Lamobo R1/BananaPi R1 on top of armbian!

This is awesome because, you know, IoT is coming, and Docker on ARM helps get a grip on many challenges induced by IoT. However, we were only able to support Docker on Raspberry Pis so far...  Imagine if Docker would run on more than just a few ARM boards! Armbian seems an awesome platform to extend the family of Docker compatible boards.

So, I wonder if there is anyone who tried to run Docker on armbian?

If you are now curious about this topic and wanna get started, please see this blog post of how to install Docker on ARM within no time: http://blog.hypriot.com/post/family_arm_hardware_for_docker_more_children/

Looking forward to get in touch with you guys!

• Install armbian.gpg to /usr/share/keyrings/armbian.gpg  (mode 644)
  • You can use a copy from another one of your SBCs, or...
  • ... you can download and install like below (thanks @BrewNinja for the example)

touch /usr/share/keyrings/armbian.gpg
chmod 644 /usr/share/keyrings/armbian.gpg
wget https://apt.armbian.com/armbian.key -O - | gpg --dearmor >/usr/share/keyrings/armbian.gpg

• Edit /etc/apt/sources.list
  • Replace all instances of bullseye with bookworm
• Edit /etc/apt/sources.list.d/armbian.list

  • deb [signed-by=/usr/share/keyrings/armbian.gpg] http://apt.armbian.com bookworm main bookworm-utils bookworm-desktop

• Edit any other files in /etc/apt/sources.list.d as appropriate, to replace bullseye with bookworm

Step 2

apt update

Step 3

NOTE - WHEN RUNNING THE BELOW COMMANDS, DO NOT ACCEPT ANY INTERACTIVE PROMPTS FOR CHANGING /etc/initramfs-tools/initramfs.conf

• The default is not to accept the changes anyway - but I am noting this here to be extra careful
• I've checked - the changes may differ from what armbian has in the latest images

apt upgrade --no-new-pkgs
apt full-upgrade
apt dist-upgrade

Ever since the first 2 x gigabit ethernet devices came out, I've been thinking that there were a lot of potentially interesting networking use cases.

I happened to be re-configuring pihole on a new opi zero, and I had some hardware issues that caused my connection to be a bit flaky on a website that I "shouldn't" have been using. This gave me the inspiration to create a gateway that intentionally manipulates traffic in such a way that you train good usage habits of websites that can be addictive.

How does it work?

Nethadone leverages several eBPF programs to monitor and classify routed traffic as it passes through. Based on the configured policies, packets are slotted into a series of bandwidth classes.

For anyone not familiar with eBPF, it's a powerful capability of newer Linux kernels, that allows C and Rust code to be compiled and run in a sort of kernel-space sandbox and loaded in realtime. Due to the efficiency of JIT-optimized eBPF code running inside the kernel, features that were possible only with expensive networking equipment are now feasible on something like an Orange Pi R1Plus.

The flow of a packet through the moving parts of the system is here:

There are three eBPF modules at work:

• A traffic monitor captures (saddr, daddr) pairs from clients on the network to external IPs, counting the bytes used. These counters are exposed by the webapp and collected in a local prometheus instance.
• A DNS sniffer captures DNS requests passing through the router, in order to cache the likely domain of a given IP address
• A throttler eBPF is dynamically recompiled based on traffic patterns, and classifies traffic based on a policy.

Packets classified into one of the slower bandwidth classes ends up passing through a netem qdisc, which simulates a slower network connection. As "bad" usage continues, the policy is changed until traffic is passing through the equivalent of a 56k modem. I think most people here would probably get the hint and stop scrolling if they were forced to use a telephone-based modem again

Deployment Example

This diagram shows how I've installed it at home - any device connected to the nethadone AP is subject to throttling:

This setup was mainly to have an easy way to get back online if there were issues, but after a couple of weeks of general usage with both desktop and mobile clients, there have been no major issues, apart from the need to restart after 24h or so.

Armbian-related TODOs

While there are some things that could be better, the tool is working well enough that it has already had a positive impact on my and my wife's usage of a number of sites. My goal is to now make it as user-friendly to set up as possible.

One big issue is that Armbian understandably does not enable BTF in the images that ship. The dae project has been a life-saver, providing BTF-enabled kernel builds for a lot of devices for Armbian 23.08.

I tried to create a custom image with a BTF-enabled kernel, but had a lot of difficulty getting something bootable and set it aside. I also ran into some kernel configuration issues when attempting to make an older OPI R1 (not plus) work, even with the dae kernels.

My gratitude to everyone who helps maintain Armbian and helps on this forum. In the coming weeks as I try to work on making it easier to use this on other devices, I may seek out some advice from forum members on how to work through these issues.

For anyone interested in trying it out, or wants to find out more about how to use eBPF on an arm-based device, the code and documentation can be found here:

https://github.com/atomic77/nethadone

👋

-Alex

audio_output {
    type        "alsa"
    name        "BananaPi BuiltIn"
    device        "hw:0,0"
    mixer_type      "hardware"
    mixer_device    "default"
    mixer_control    "Power Amplifier"
}

I apologize in advance if I haven't put the topic in the right section.

I want to share my experience with NanoPC-T6 and two NVMe m.2 disk.
I use my NanoPC-T6 for a small server.
In the beginning I had 2 SSDs and an M.2 to 2 SATA adapter.
But I never found the right solution to power both the NanoPC-T6 and the SSDs from 1 place.
After some internet searching I was able to find a solution on how to put 2 NVMe drives on my NanoPC-T6

As you know NanoPC-T6 has 1 M.2 M-Key connector with PCIe 3.0 x4
There is also one PCIe which is M.2 E-key connector with PCIe 2.1 x1
With this adapter:
https://www.aliexpress.com/item/1005004762924052.html
I am using M.2 E-key to M.2 M-Key.

The version of the kernel I use is 6.1.43-vendor-rk35xx.

The speed that the NVMe disk on the adapter board can reach is about 400MB per second, which is quite good for my needs.

I am attaching some pictures.

I hope this is useful for you. If there are any questions, I'm at the meeting to answer them.

Regards,

This Guide is for a "client to client" setup of the box, we will internally switch Wifi to Eth, so a working computer can access internet from its eth port even if the router signal source is wireless.

Router AP -----> ARM BOX [WIFI internal or usb dongle] ===>> internal eth0 ------> ethernet cable --> client eth port

• Make sure WiFi in arm box is connected using nmtui command
  • FROM NOW ON <WIFI CARD> is the wifi adapter name es: replace "<WIFI CARD>" with "wlx0013eff301ee"
• Execute: sudo apt-get update && sudo apt-get install dnsmasq iptables iptables-persistent -y
  • say no to save actual iptables rules (we dont have any yet)
• Edit /etc/network/interfaces
  • comment if exist the part of eth0 "iface eth0" to "#iface eth0"
  • add those lines

  • allow-hotplug eth0
    	iface eth0 inet static
    		address 172.24.1.1
    		netmask 255.255.255.0
    		network 172.24.1.0
    		broadcast 172.24.1.255
    		dns-nameservers 1.1.1.1 1.0.0.1
    	#########{Static}###########
    	up ip addr add 172.24.0.1/24 dev eth0

• execute those commands
  • REMEMBER TO REPLACE <WIFI CARD>

  • ip addr add 172.24.0.1/24 dev eth0
    iptables -A FORWARD -o <WIFI CARD> -i eth0 -s 172.24.0.0/24 -m conntrack --ctstate NEW -j ACCEPT
    iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
    iptables -t nat -F POSTROUTING
    iptables -t nat -A POSTROUTING -o <WIFI CARD> -j MASQUERADE
    sh -c "iptables-save > /etc/iptables.ipv4.nat"
    sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward"
    /etc/init.d/dnsmasq stop
    cp /etc/dnsmasq.conf /etc/dnsmasq.conf-backup

• Edit /etc/dnsmasq.conf inserting

  • interface=eth0
    listen-address=172.24.1.1
    bind-interfaces
    server=1.1.1.1 
    domain-needed
    bogus-priv
    dhcp-range=172.24.0.100,172.24.0.250,72h

• Edit /etc/sysctl.conf inserting

  • net.ipv4.conf.default.forwarding=1
    net.ipv4.conf.all.forwarding=1

• Edit /etc/rc.local inserting before "exit 0"

  • iptables-restore < /etc/iptables.ipv4.nat

• execute those commands

  • systemctl enable dnsmasq
    systemctl enable iptables

Explainations:

We set static net to eht0 then we set routing in iptables [forward and back] wlan<->eth then we make this setup persistent so that will persist after reboot.

Working on my RK3318 Armbian bullseye 5.15 minimal and USB3 dongle RTL8814AU (also tested with a 8812au)

The pyA20 gpio library is quite famous when people start to play with gpios , spi or i2c on sunxi boards but mapping needs often adjustments to work on your own board. This situation is not really friendly for 'beginners'.  pyGPIO should help to make armbian a little bit more 'IoT friendly'. 

I didn't touch the 'backbone' of pyA20, so the syntax should be similar to its original (except pinname when using port instead of connector). 

How can I use this library:

Cause all of this boards have (more or less) the same pinheader (sometimes other pins are deployed on the pinheader) pyGPIO tries to unify the mappings, so that code can be shared and deployed on all boards without touching the code. The mapping follows the pin naming of the RaspberryPi (it's not because I think their naming is perfect, but it should be the easiest way to port code from the 'RPi world' to Armbian.

What is done:

-Initial support for:

• OrangePi Zero/PcPlus/Lite/Plus2E
• NanoPi Duo(with and without Minishield)/Neo
• Olimex Lime/Lime2/Micro (pins are not renamed PG10,PG11 etc. instead of GPIO2, GPIO3 etc. cause those boards doesn't have a 'RPi Pinheader'
• Templates for 24,26 and 40 'RPi compatible' pin header

-Board detection (when using Armbian) to check if your board is supported

-Manual assignment when your board is not supported (yet) or automatic board detection fails

What is not done:

• Testing
• testing
• testing!
• Documentation
• Meaningful examples (still the originals from olimex which wouldn't work anymore)

What do you need to test the Library:

You need python-dev and the Library which you'll find on my GitHub page. The installation should be easy, just follow the instructions... 

sudo apt-get install python-dev
git clone https://github.com/chwe17/pyGPIO.git
cd pyGPIO
sudo python setup.py install

Testing is the part where I need help. I don't have most of the boards which are supported (only OPi0 and OPi Pc Plus). I tested I2C and GPIO on the OPi0, for all the rest, I need you as testers, bug hunters, and feedback.

Here are two short python snippets which should do the exact same thing (once with connector, you have to run them as root or with sudo otherwise it would not work!):

import os, sys

if not os.getegid() == 0:
	sys.exit('start script as root')
	
from pyGPIO.gpio import gpio, connector
from time import sleep

gpio.init()
gpio.setcfg(connector.GPIOp7, 1)  #pin 7 as output

n = 0
while n < 5:
	gpio.output(connector.GPIOp7, 1)
	sleep(1)
	gpio.output(connector.GPIOp7, 0)
	sleep(1)
	n +=1

sys.exit('finished ;-)')

and once with port:

import os, sys

if not os.getegid() == 0:
	sys.exit('start script as root')
	
from pyGPIO.gpio import gpio, port
from time import sleep

gpio.init()
gpio.setcfg(port.GPIO4, 1)  #gpio4 as output

n = 0
while n < 5:
	gpio.output(port.GPIO4, 1)
	sleep(1)
	gpio.output(port.GPIO4, 0)
	sleep(1)
	n +=1

sys.exit('finished ;-)')

Annotation: When using NanoPi Duo you've to possibilities with or without Minishield. Pin name is the same on both possibilities but when using port but pin numbering when using connector:

Minishield:

3.3V			|1·|	5V
GPIO2 	I2C0_SDA	|3·|	5V
GPIO3	I2C_SCL		|5·|	GND
GPIO4			|··|	GPIO14	UART1_TX
GND			|··|	GPIO15	UART1_RX
GPIO17	SPI1_MOSI	|··|	GPIO18	
GPIO27	SPI1_MISO	|··|	GND	
GPIO22	SPI1_CLK	|··|	GPIO23	SPI1_CS
3.3V			|··|	NC (on mini shield)

Without (e.g. connector.J1p7 or connector.J2p5) :
				J1			J2 
(UART0_RX)			|1| microUSB 		 |1|	5V	
(UART0_TX)			|2|	 		 |·|	5V						
GND				|3|	 		 |·|	3.3V
GPIO3 (TWI_SCL)			|4|			 |·|	GND	
GPIO2 (TWI_SDA)			|5|			 |·| 	GPIO4 (IR_RX)
GPIO23 (SPI1_CS)		|6|			 |·|	GPIO18 (IOG11)	
GPIO22 (SPI1_CLK)		|7|			 |·|	DM3 D-
GPIO27 (SPI1_MISO)		|·|			 |·|	DM3 D+
GPIO17 (SPI1_MOSI)		|·|			 |·|	DM2 D-	
GPIO15(UART1_RX)		|·|			 |·|	DM2 D+
GPIO14 (UART1_TX)		|·|			 |·|	RDN
(CVBS)				|·|			 |·|	RDP	
(LINEOUT_L)			|·|			 |·|	TXN
(LINEOUT_R)			|·|			 |·|	TXP
(MICP)				|·|			 |·|	LED-LINK
(MICN)				|·|	microSD	 	 |·|	LED-SPD

Buttons (bigger orange pi boards) are mapped, but I didn't test if it works (mapping here, if somebody is interested in testing them, see mapping.h of your board):

{"BUTTON",
	{
		{   "BUTTON",  SUNXI_GPL(4),  1   },
		{
			{   0,  0,  0}
		},
	}
},

Greetings, NicoD

Apologies if this is dumb question.  I finally got my hands on some appropriate (64-bit) hardware, and ready to install software now.

I have read so many threads (in Kobol Club and elsewhere), Issues (at GitHub as well as Atlassian) and I think this is solved by now (on Armbian) but cannot confirm?

Official install instructions (on OpenZFS website) don't really seem applicable to Armbian (kernel headers will be different, etc.).

I guess what I am asking is, do I just do something like the following:

$ sudo apt install zfs-dkms zfsutils-linux

And it should "just work"?  Or is there more to it than that?

Looks like I should make sure backports are set up beforehand, as ZFS version is significantly newer there (2.0.3 vs 0.7.12).

Target device is ROCKPro64, on latest Armbian 21.02.3 Buster Current, which is kernel 5.10.21.

https://gist.github.com/ag88/05245121cce37cb8f029424a20752e35

Special thanks goes to
@Gunjan Gupta

 for the tip on PREFER_DOCKER=no

Did finally manage to get this working.   So lets make it simple clever.

Actually i did this on a 64bit raspian light kernel 6.1 but it must be the same on Armbian 

10 jan 24

    Sharing the Raspberry Pi's WiFi over the ethernet port

sudo apt get update && sudo apt install dnsmasq iptables iptables-persistent dhcpcd5
sudo vim /etc/dhcpcd.conf
    interface eth0
    static ip_address=192.168.4.1/24
-------
sudo mv /etc/dnsmasq.conf /etc/dnsmasq.conf.bk
sudo nano /etc/dnsmasq.conf -
 interface=eth0

dhcp-range=192.168.4.8,192.168.4.250,255.255.255.0,12h

server=8.8.8.8

bogus-priv
------

sudo systemctl restart dnsmasq.service

------
sudo vim /etc/sysctl.conf
    net.ipv4.ip_forward=1
-------
sudo systemctl start dnsmasq
-------
sudo sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward"
-------

sudo iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
sudo iptables -A FORWARD -i wlan0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o wlan0 -j ACCEPT
-------
sudo iptables -L -n -v
----------
sudo sh -c "iptables-save > /etc/iptables.ipv4.nat"
---------
sudo vim /etc/rc.local
    iptables-restore < /etc/iptables.ipv4.nat
exit0
---------
sudo reboot
--------

Did get a perfect internet connection on odroid n2+ through eth0 - so the rpi4b is now supplying wifi for that board and providing petitboot with netbooting images through netboot_default after exit to shell.

There's been a few guides around on how to get RDP working with Armbian so you can login from your Windows or other PC. Some solutions mentioned in various threads here were:

• Install tightvncserver instead + x2go bloat (i.e. use VNC)
• Only login as root - didn't seem to make any difference for me
• Change some permissions of a log file in your home directory.

Well, this is what I did on my Orange PI PC running Buster desktop with Kernel 5.4, as of April 2020.

sudo apt install xrdp xorgxrdp
sudo systemctl enable xrdp
sudo reboot

... and that was it. The missing piece of the puzzel appeared to be the install of xorgxrdp, this isn't installed automatically by 'xrdp' package, and it's useless without it.

Update June 2020: Also works with RetroOrangePi 4.3 super quickly (given this is based on Armbian Bionic 18.04). Can RDP in and use Armbian Desktop whilst Kodi plays a 4k movie on the TV from the same device... Awesome!

For those who rather read, here's my gathered data : 
https://docs.lane-fu.com/s/5IxGlf4gn

Greetings, NicoD

Instructions in this thread are oudated and superseded by the new experimental APT repository for hardware video decoding ffmpeg.

Please refer to this thread from now on!

Hello, recent upgrades to armbian are regarding kernel 5.15.

I noticed that many v4l2 fixes and enhancements went into this release, so I decided to compile ffmpeg using LibreELEC patched version and mpv over it.

mpv turns out to be statically linked with ffmpeg, so I propose it here for people who is interested in cutting edge kernel and wants to do some tests.

This has been tested on Debian Bullseye and Ubuntu Hirsute on following platforms:

• Rockchip RK3228/9 (kernel 5.10, 5.14)
• Rockchip RK3288 (kernel 5.14)
• Rockchip RK3318/28 (kernel 5.15)

It should work on allwinner platforms too, but I didn't test it there.

Binaries are built by me on developing boards.

The binary for armhf is available here

The binary for arm64 is available here

Copy the binary into /usr/local/bin directory of your system (mpv-armhf for 32 bit systems, mpv-arm64 for 64 bit systems):

sudo cp mpv-armhf /usr/local/bin/mpv

Install dependencies for Debian Bullseye and Ubuntu Hirsute:

apt install libass9 libbluray2 librubberband2 libsdl2-2.0-0 libva-drm2 libva-wayland2 libva-x11-2 libva2 libvdpau1 libx264-160 libx265-192 libxss1 libxv1 libfdk-aac2

I have had issues with dependencies on Debian Buster/Ubuntu Focal, in particular libx264-160 and libx265-192 are not available there.

I Solved the issue downloading the packages from Debian Bullseye web page and manually installing them.

There may be the need for some other dependency depending upon your actual installation.

Run mpv in a virtual terminal (videos up to 4K) with this CLI:

mpv --vo=gpu --hwdec=drm --gpu-hwdec-interop=drmprime-drm --drm-draw-plane=overlay --drm-drmprime-video-plane=primary <video.mp4>

Mpv can be run in X11 with this other CLI, but due to buffer copying it requires a good CPU - rk3228 and rk3328 won't even play 720p, rk3288 do 720p fine:

 mpv --vo=gpu --hwdec=auto-copy --gpu-context=x11egl --gpu-hwdec-interop=drmprime-drm <video.mp4>

This is an experiment and your mileage may vary a lot:

• H.264 codec should be well supported around the boards;
• H.265 has more limited support
• VP8 should be generally supported
• VP9 seems to still require some work.

This libs available only for x86. No way for direct compiling cnijfilter for ARM (and other architectures).

But we have qemu! We can transparently run x86 executables on any other host architectures.

Easy steps to run cnijfilter on ARM (or any other arch):
- Build https://github.com/endlessm/cnijfilter-common for x86

- Copy all needed x86 libs using recursive ldd. And copy it to /usr/lib/bjlib/

- Patch all executables: set interpreter to /usr/lib/bjlib/x86/ld-linux.so.2 and rpath to /usr/lib/bjlib/

- Install these patched packages to ARM system

- Install qemu-user and qemu-user-binfmt (or qemu-arm-static)

You do not need to do this manually. I have implemented an automated build system: https://github.com/Azq2/cnijfilter-arm-build

All you need is any x86 machine to do the build.

How to use

1. On any x86 machine:

# Install dependencies
sudo apt install debootstrap git util-linux

# Get build system
git clone https://github.com/Azq2/cnijfilter-arm-build

# Start building
cd cnijfilter-arm-build
sudo ./build.sh build

# Get .deb packages
ls -lah ./result/full
ls -lah ./result/light

After build we have two variants of packages: full and light

In most cases, a light package is completely sufficient:

- We don't need canon usb backend, because cups have builtin USB support

- We don't need canon network backend, because cups have builtin BJNP support (package cups-backend-bjnp)

- Other canon maintenance utils are useless (in my opinion)

2. Copy .deb from result/light or result/full to your ARM machine.

3. On your ARM machine:

# Install dependencies
sudo apt install qemu-user qemu-user-binfmt # or sudo apt install qemu-user-static

# Install common for all printers package
sudo dpkg -i cnijfilter-common.deb

# Install printer-specific package
# Choose right package for your printer! e400series only for reference!
sudo dpkg -i cnijfilter-e400series.deb

4. Done. You can now configure CUPS.

Security with apparmor (optional)

CUPS filters don't need any specific permissions.

Create file /etc/apparmor.d/cnijfilter-filters with contents:

#include <tunables/global>

/usr/bin/bjfilter* {
	#include <abstractions/base>
	@{PROC}/sys/vm/mmap_min_addr r,
}

/usr/bin/cif[a-z]*[0-9d]* {
	#include <abstractions/base>
	@{PROC}/sys/vm/mmap_min_addr r,
}

/usr/lib/cups/filter/{cmdtocanonij,pstocanonbj,pstocanonij} {
	#include <abstractions/base>
	@{PROC}/sys/vm/mmap_min_addr r,
}

Then restart apparmor:

sudo systemctl reload apparmor
sudo aa-enforce cnijfilter-filters

Note: this minimal file full coverage all executables in light package. For full package you need write additional rules by yourself.

For Windows users there's WSL2 you can use. Here my video about that.

Greetings, NicoD

Prerequisites:

We need an Terminal program to access the console. If you use Linux on your host system I prefer picocom (something like minicom will also do the job) which can be installed:

on debian a like systems:

sudo apt-get install picocom

from arch community repo:

https://www.archlinux.org/packages/community/x86_64/picocom/

on fedora systems:

yum install picocom

on Mac OS X:

brew install picocom

on Widows we use PuTTY:

https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html

UART USB Adapter:

There are various USB-UART bridges e.g FT232 (and fakes of them, cause FDTI is expensive ), CH340/1,PL2303 or CP2102

Normally it doesn't matter which one you use. I prefer the (probably fake) FDTI on the right side, but the CH341 does also a good job:

The only thing which is needed is that the signal-level matches with your SBCs needs (this is mostly 3.3V expect some Odroids e.g HC1 which has only 1.8V!).  Most of these USB-UART bridges have jumpers for 5V and 3.3V, make sure that you use the 3.3V.  

You've to figure out which pins on your SBC are debug UART (they've mostly a own 3 pin header, sometimes it's on the large pin header e.g. Tinkerboard) and then connect:

GND --> GND
RX  --> TX
TX  --> RX

You've to check dmesg (linux) or run devmgmt.msc (windows) to know which device you use. 

Linux:

[256597.311207] usb 3-2: Product: USB2.0-Serial
[256597.402283] usbcore: registered new interface driver ch341
[256597.402341] usbserial: USB Serial support registered for ch341-uart
[256597.402392] ch341 3-2:1.0: ch341-uart converter detected
[256597.404012] usb 3-2: ch341-uart converter now attached to ttyUSB0

--> Device will be /dev/ttyUSB0

Windows:

for windows 10 (https://www.google.ch/search?client=opera&amp;q=find+arduino+port+windows+10&amp;sourceid=opera&amp;ie=UTF-8&amp;oe=UTF-8)

Quote

Open the Device Manager window by right-clicking the Windows 10start button in the lower left of the screen and then selecting Device Manager on the menu that pops up. In Device Manager, expandPorts (COM & LPT) and you should see a COM port which will be your Arduino as shown in the image below.

Something like the picture in USB Gadget Mode part of the tutorial should show up)

Armbians default settings are (expect some RK devices):

For Picocom:

picocom -b 115200 -r -l /dev/ttyUSB0

and for some RK devices:

picocom -b 1500000 -r -l /dev/ttyUSB0

For PuTTY:

You've to set configuration in 'Serial'. COM11 is just an example and needs to be checked first, Speed (baud) needs to be changed when you deal with the few RK boards which need 1500000.

OS X:

TBD

should be similar to Linux whereas the naming differs a bit. See: https://forum.odroid.com/viewtopic.php?f=53&amp;t=841 as an example with minicom.

Normally you connect the USB-UART bridge to your host computer (and the SBC) and start picocom/putty before you power the board to ensure you get the full bootlog and not only parts of it. 

USB Gadget Mode

Several board (see list) for which official armbian images exist (or csc images can be built) have no HDMI display. On those boards there's USB gadget mode driver activated so that you can have console access to them via USB connection. The following short tutorial describes how you can access to console from Linux (don't have a windows machine here at the moment, I may check it later):

• install picocom
• connect your board via USB to your host computer (it should be one which is able to power an SBC via its USB port)
• check dmesg for the device showing up: 

  [184372.603816] usb 3-2: Product: Gadget Serial v2.4
  [184372.603818] usb 3-2: Manufacturer: Linux 4.14.65-sunxi with musb-hdrc
  [184372.660041] cdc_acm 3-2:2.0: ttyACM0: USB ACM device
  [184372.660402] usbcore: registered new interface driver cdc_acm
  [184372.660403] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters

   

• connect to it via picocom (in this case 'picocom /dev/ttyACM0'): 

  chwe@chwe-acer:~$ picocom /dev/ttyACM0
  picocom v2.2
  
  port is        : /dev/ttyACM0
  flowcontrol    : none
  baudrate is    : 9600
  parity is      : none
  databits are   : 8
  stopbits are   : 1
  escape is      : C-a
  local echo is  : no
  noinit is      : no
  noreset is     : no
  nolock is      : no
  send_cmd is    : sz -vv
  receive_cmd is : rz -vv -E
  imap is        : 
  omap is        : 
  emap is        : crcrlf,delbs,
  
  Type [C-a] [C-h] to see available commands
  
  Terminal ready
  Debian GNU/Linux 9 orangepizero ttyGS0
  
  orangepizero login: root
  Password: 
  You are required to change your password immediately (root enforced)
  Changing password for root.
  (current) UNIX password: 

   

I assume if you use the same settings in something like putty on windows and you check which 'serial' device shows up in *where windows shows connected devices - I forgot it* you should be able to access it from windows (someone motivated may confirm this).  

For Windows:

run devmgmt.msc and search for the serial device (in this case COM3) and connect to it via PuTTY (thanks to @hjc):

for windows 10 (https://www.google.ch/search?client=opera&amp;q=find+arduino+port+windows+10&amp;sourceid=opera&amp;ie=UTF-8&amp;oe=UTF-8):

Quote

Open the Device Manager window by right-clicking the Windows 10start button in the lower left of the screen and then selecting Device Manager on the menu that pops up. In Device Manager, expandPorts (COM & LPT) and you should see a COM port which will be your Arduino as shown in the image below.

(even the tutorial is for arduinos, it should be similar for every 'COM device')

Currently boards with USB gadget mode:

• bananapim2plus
• bananapim2zero
• nanopifire3
• nanopim3
• nanopineo2
• nanopineocore2
• nanopineoplus2
• orangepizeroplus
• nanopiair
• nanopiduo
• nanopineo
• olimex-som204-a20
• orangepilite
• orangepi-r1
• orangepizero
• orangepizeroplus2-h3
• orangepizeroplus2-h5
• tritium-h3

The silly approach

For those, who want to save 1$ for an USB-UART bridge, you can spend 10$ for an OrangePi Zero and use its spare UARTs to log into an other SBC...  SSH --> opi, ttl --> Tinkerboard

For those loving text more than videos:

• SSH to your SBC
• sudo armbian-config --> system --> hardware  to activate an spare UART (in this case it was UART2, will give you ttyS2)
• reboot

• picocom -b 115200 -r -l /dev/ttyS2

   

See:  https://asciinema.org/a/B87EOGhc0gx9oikMAGEG94lXR

Greetings, NicoD

after having a hard time getting the ILI9341 touchscreen working with the NanoPi Neo (Allwinner H3)  it seems to work now.

To have more GPIOs available for other stuff the touch and display need to share SPI0

I would like to upload it to github because there is basically nothing out of the box available but I'm a total noob with NanoPi, Armbian and overlays so maybe someone could look at it.

root@nanopineo:~# uname -a
Linux nanopineo 5.15.93-sunxi #23.02.2 SMP Fri Feb 17 00:00:00 UTC 2023 armv7l armv7l armv7l GNU/Linux

This is the wiring between ILI9341 and NanoPi Neo:

/*
   3.3v <-->  VCC & LED
   GND  <-->  GND
   PC2  <-->  SCK       & T_CLK
   PC1  <-->  SDO<MISO> & T_DO
   PC0  <-->  SDI<MOSI> & T_DIN
   PA1  <-->  DC
   PG8  <-->  RESET
   PC3  <-->  CS
   PA3  <-->  T_CS
   PG9  <-->  T_IRG
 */

This is the overlay:

/dts-v1/;
/plugin/;

/ {
	compatible = "allwinner,sun8i-h3";

	fragment@0 {
		target = <&pio>;
		__overlay__ {
			spi0_cs1: spi0_cs1 {
				pins = "PC3"; 
				function = "gpio_out";
				output-high;
			};

			spi1_cs1: spi1_cs1 {
				pins = "PA3"; 
				function = "gpio_out";
				output-high;
			};

			opiz_display_pins: opiz_display_pins {
                pins = "PA1", "PG8", "PA6";
                function = "gpio_out";
            };

            ads7846_pins: ads7846_pins {
                pins = "PG9";
                function = "irq";
            };


		};
	};

	fragment@1 {
		target = <&spi1>;
		__overlay__ {
			pinctrl-names = "default", "default";
			pinctrl-1 = <&spi1_cs1>;
			cs-gpios = <0>, <&pio 0 3 0>; /* PA3 */
		};
	};

	fragment@2 {
		target = <&spi0>;
		__overlay__ {
			#address-cells = <1>;
			#size-cells = <0>;
			status = "okay";

			pinctrl-names = "default", "default";
			cs-gpios= <&pio 2 3 0>, <&pio 0 3 1>;

			opizdisplay: opiz-display@0 {
			    pinctrl-1 = <&spi0_cs1>;
				reg = <0>; /* Chip Select 0 */
                compatible = "ilitek,ili9341";
				spi-max-frequency = <1000000>;
				status = "okay";
                pinctrl-names = "default";
                pinctrl-0 = <&opiz_display_pins>;
                rotate = <90>;
                bgr = <0>;
                fps = <33>;
                buswidth = <8>;
                dc-gpios = <&pio 0 1 0>;      /* PIN_22  GPIOA1 > */
                reset-gpios = <&pio 6 8 1 >; /*    GPIOG8> */
                /*led-gpios=<&pio 0 6 0>;        PIN_12  GPIOA6 > */
                debug=<4>;                        
			};

			ads7846: ads7846@1 {
				reg = <1>; /* Chip Select 1 */
				compatible = "ti,ads7846";
				spi-max-frequency = <1000000>;
				status = "okay";
                pinctrl-2=<&spi1_cs1 &spi1_cs1>;
                pinctrl-names = "default";
                pinctrl-3 = <&ads7846_pins>;
                interrupt-parent = <&pio>;
                interrupts = <6 9 2>; /* PG9 IRQ_TYPE_EDGE_FALLING */
                pendown-gpio = <&pio 6 9 0>; /* PG9 */
                /* driver defaults, optional */
                ti,x-min = /bits/ 16 <0>;
                ti,y-min = /bits/ 16 <0>;
                ti,x-max = /bits/ 16 <0x0FFF>;
                ti,y-max = /bits/ 16 <0x0FFF>;
                ti,pressure-min = /bits/ 16 <0>;
                ti,pressure-max = /bits/ 16 <0xFFFF>;
                ti,x-plate-ohms = /bits/ 16 <400>;
			};

		};

	};

};

This is the /boot/armbianEnv.txt

verbosity=1
bootlogo=false
console=serial
disp_mode=1920x1080p60
overlay_prefix=sun8i-h3
overlays=usbhost1 usbhost2 spi0
param_spidev_spi_bus=0
param_spidev_spi_cs=1
param_spidev_spi_cs=0
rootdev=UUID=XYZ-LONG-UUID-IS-LONG
rootfstype=ext4
user_overlays=ili-touch-spi
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

After connecting via ssh and starting evtest it shows this when touched ( not sure if it shows the correct coordinates yet )

Event: time 1682020476.763295, -------------- SYN_REPORT ------------
Event: time 1682020476.775286, type 3 (EV_ABS), code 0 (ABS_X), value 535
Event: time 1682020476.775286, type 3 (EV_ABS), code 1 (ABS_Y), value 3553
Event: time 1682020476.775286, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 65169

So it looks like everything is working but to be on the safe side I would like to wait until some pro reviewed the overlay.

Thanks.

  I've been running Octoprint on armbian for several months with good results of a couple of printers with good performance no relevant problems. Installation process is not complex but I decided to build a simple a plug&play meta-distribution like OctoPi for Rpi boards but based on armbian so it can be used potentially in any of the supported boards.  I started with the popular Opi Zero as it is really cheap and the four cores of the H2+ processor handle perfectly a 3d printer load and is 3 times cheaper than a typical RPI3B that octoPi requires.

You can find it here: https://github.com/ludiazv/octocitrico

Built-in features are:

Core (installed and enabled):

• Optimized armbian Debian buster.
• Latest stable octoprint version.
• Selection of top octoprint plugins.
• HAProxy with self signed keys for ssl access.
• Avahi service: Bonjur addvertisement (this enable to acces with host-name.local via ssh or http/s)
•  SSH console access.
• USB OTG console access (if available in the board)
• Enabled i2c-dev,spidev (if available on the board)

3D printer related software (installed but disabled):

• Klipper
• PlatformIo core for building 3D printer firmware.
• Marlin 1.1.x & Marlin 2.x.x firmware (bugfix versions)

Extras (installed but disabled):

• MPGStreamer USB camera support (experimental)
• SMB shares to remote edit configuration files from a remote PC.

Feedback and contributions are welcome.

Thanks armbian guys for the awesome work you do.

Greetings, NicoD

My gathered info :
 

RK3588(S) comparison
--------------------
RK3588(S) 8nm LP process
4 x A55 @ 1.8Ghz + 4 x A76 @ 2.4Ghz (Not the same for all boards, between 2.2Ghz and 2.4Ghz)
Mali-G610 MP4 "Odin"
6TOPs NPU
Up to 32GB memory theoretically (haven't seen any 32GB yet)
                              RK3588                            RK3588S 
PCIE3.0 	                  2x2 Lanes PCIe3.0 	            N/A 	
PCIe2.0/SATA3.0/USB3.0 MUX 	  3x1 Lane PCIE2.0 	                2x1 Lane PCIE2.0 	
                              3x SATA 3.0 	                    2x SATA 3.0 	
                              1x USB3.0 (refer USB section) 	1x USB3.0 (refer USB section) 


     Board                 SoC                   Memory                       eMMC        SD-Reader     NVMe/PCIe/SATA       Network               USB2    USB3         USB-C (dp)      HDMI-out          HDMI-in          DP         Active cooling                Powered with 
1.   Khadas Edge 2 Pro     Rockchip RK3588S      16 GB LPDDR4X 2112 MHz       64 GB       xxx           xxx                  xxx                   1 x     1 x          1 x DP          1 x               xxx              xxx        xxx (Case not out yet)        USB-C PD
2.   NanoPi R6S            Rockchip RK3588S      8 GB LPDDR4X 2133 MHz        32 GB       yes           xxx                  2 x 2.5GbE + 1GbE     1 x     1 x          xxx             1 x               xxx              xxx        Metal case                    USB-C PD 
3.   Radxa Rock5B          Rockchip RK3588       16 GB LPDDR4X 2112 MHz       Module      yes           2 x M.2 NVMe         2.5GbE                2 x     2 x          xxx             2 x               1 x micro-HDMI   xxx        XU4 heatsink no sufficient    USB-C PD (Issue with PD, I'm using 5V 4A PSU)
4.   Mekotronics R58 Mini  Rockchip RK3588       16 GB LPDDR4X                64 GB       xxx           SATA ribbon          1GbE                  2 x     1 x          1 x (no DP)     2 x               1 x full size    1 x        Big heatsink sufficient ***   12V barrel jack                                *** Case could also be used to cool with a thermal pad
5.   Mekotronics R58X-4G   Rockchip RK3588       8 GB LPDDR4X                 64 GB       xxx           SATA/NVMe/mini-PCIe  1GbE                  2 x     1 x          1 x DP          1 x               1 x full size    1 x        Big heatsink sufficient ***   12V barrel jack 
6.   Orange Pi 5           Rockchip RK3588S      4/8 GB LPDDR4(x)             xxx         yes           NVMe                 1GbE                  1 x     2 x          1 x DP          1 x               xxx              xxx        No                            USB-C 5V 

Other specs
Khadas Edge 2 Pro also has 3 x CSI + 2 x DSI, and can have an I/O board for SD-card and uart
Radxa Rock5B has 1 x CSI + 1 x DSI 
OPi5 has 2 x DSI + 3 x Camera port 


Benchmarks 
----------
Board              | OS                            | Kernel         | Clockspeeds             | 7z b all cores     | 7z b core small core    | 7z b big core   | NicoD Blender    | Supertuxkart        | SBC-Bench
Radxa Rock 5B        Armbian Jammy cinnamon          5.10.110         1.8Ghz A55/2.4Ghz A76     15996                1533 (core 0)             2651 (core 7)     3m25s              65fps (panfork)       http://ix.io/4jOb
Radxa Rock 5B        Radxa Bullseye xfce4            5.10.66-27       1.8Ghz A55/2.4Ghz A76     16138                1522 (core 0)             2649 (core 4/7)   4m35s V2.83.5      xxx                   
Khadas Edge2         Ubuntu 22.04 Gnome              5.10.66          1.8Ghz A55/2.35Ghz* A76   16901                1766 (core 0)             2930 (core 7)     3m25s              110fps (wayland)      http://ix.io/4e8w ****SBC-Bench broken big cores at 408Mhz
NanoPi R6S           Ubuntu 22.04 Gnome Headless     5.10.110         1.8Ghz A55/2.3Ghz * A76   16385                1449 (core 0)             2493 (core 7)     3m27s              110fps (wayland)      http://ix.io/4gSl
Mekotronics R58      Debian Bullseye wayland         5.10.110         1.8Ghz A53/2.2Ghz A76     16803                1777 (core 0)             2879 (core 1)     4m35s              110fps (wayland)      http://ix.io/4j40
Mekotronics R58      Ubuntu 20.04 x11                5.10.66          1.8Ghz A53/2.2Ghz A76     16477                1765 (core 0)             2897 (core 1)     5m53s V2.82        4fps (llvmpipe)
Mekotronics R58X-G4  Armbian Jammy Gnome             5.10.110         1.8Ghz A53/2.4Ghz A76     16421                1767 (core 0)             2852 (core 1)     3m28s              75fps (panfork)       SBC-bench broken 


Pros+++
-------
Khadas Edge2 Pro           Small and USB-C PD powered, so great for my trips but needs a metal case for that. Having the extra USB-C is great. It is either a 2nd fast access to the SoC, and can be used for 2nd HDMI display. OOWOW is great to install new software, no need for RKDevTool. The Khadas software is pretty good. Khadas has a great team that's active on their forum.
NanoPi R6S                 Metal case makes it awesome. It is limited, but for what I wanted it's doing the job better than expected(fast NAS and even watching video). USB-C PD powered, so if I don't find a case for Edge2 I can also use the R6S on my trips. SD-Reader is great for booting and installing software.
Mekotronics R58 mini       Full sized ports. For home use it's good to have a device that's not tiny. Great to have the display ports on back and side and USB on the front. Case is nice, but not used for cooling. Great for digital signage with 2x HDMI + 1 x DP. 
Mekotronics R58X-4G        mini-PCIe, NVMe and SATA. Full sized ports. USB-C with DP. Nice case, can be used to cool the board with a thermal pad but not needed. 
Rock5B                     Armbian support. Has dual M.2 sockets. SD-card reader and eMMC socket. Full sized HDMI-out ports. 2.5GbE.

Cons---
-------
Khadas Edge2 Pro           No metal case yet(March). Missing SD-card, IO board can add that but then doesn't fit in the case. Seems designed for use in a small kiosk/digital signage, so all small special connectors for additional devices like displays and camera's. 
NanoPi R6S                 Designed for networking and so missing a lot of other features(NVMe, PCIe, extra USB-C with DP, multiple USB3 ports...).  
Mekotronics R58 mini       Not the best I/O. No sd-reader what makes the use of RKDevTool needed. Expensive. Wouldn't be as good for me if I didn't know great Armbian devs(MonkaBlyat). 
Mekotronics R58X-4G        No sd-reader what makes the use of RKDevTool needed. Expensive. Wouldn't be as good for me if I didn't know great Armbian devs(MonkaBlyat). 
Rock5B                     Software not ready for my daily needs, seems the worst supported board. USB-C PD has issue's. No good cooling sollution comes with the board. 


My opinion on available software 
--------------------------------
1.   Khadas Edge2           Ubuntu 22.04 works great with panfork. You can also use the blob GPU driver if you start with the Gnome image. Almost everything works as it should. 
2.   Mekotronics R58(X-4G)  Armbian Jammy Gnome works great with panfork. The Mekotronics images aren't perfect. Works well for desktop/video/gaming. 
3.   NanoPi R6S             Ubuntu 22.04 gnome works well, but panfork doesn't work with it. It's very stable, did my desktop tasks as a champ. But I'm missing gaming on it with x11. 
4.   Radxa Rock5B           Armbian Jammy Gnome is buggy as hell. Only Armbian runs ok on it. The Debian image from Radxa is a mess, Android is unusable. DTB file seems badly hacked together.


My favorite ranking for now
---------------------------
1. Mekotronics R58X-4G            It has it all. Good cooling, nice it's not tiny, NVMe and SATA and mini-PCIe. 1 less full sized HDMI vs R58 but USB-C DP works too. Armbian thanks to MonkaBlyat brings this on top.
2. NanoPi R6S                     Limited but works well for what I wanted from it. The case is a big plus. Panfork not working. But the Ubuntu 22.04 Gnome image is great for desktop tasks. Stable, great video playback. Performs well as NAS too. Love that it has an SD-reader. I do not need dual 2.5GbE, so could have been better having NVMe instead of 2nd 2.5GbE port.
3. Khadas Edge 2                  Missing of a metal case brings this down, waiting for the case to be released. The software from Khadas is the best of all. No SD-card is also a big minor. Best board for travel laptop.
4. Mekotronics R58X               Works well. But has a lot less I/O than R58X-4G. Then again has 2 x full sized HDMI-out vs 1 x on R58X-4G. 
5. Radxa Rock5B                   Bit dissapointed by the software. It does have all the bells and whistles I want. But it isn't ready for daily use yet. Armbian is the only ok-working image for it. And that is a lot more buggy than all the others. 
 
***Don't have the OPi5*** 

I've been committing code to U8g2 that utilizes the same userspace code at the C level and dramatically improved the performance of HW/SW SPI and I2C in the arm-linux port. I also made the arm-linux port thread safe and multi display capable (you can use this in C as well obviously). It made sense to add modularization to the Java Periphery IO library since I can take advantage of the same code generation techniques. I will continue to wrap optimized C libraries moving forward in the same modular fashion.

So now you can develop against IO and small displays with one code base in Java.

Mekotronics download page :
https://www.mekotronics.com/h-msgBoard.html

Armbian from MonkaBlyat for R58-Mini :
https://monka.systemonachip.net/r58-mini/Armbian_23.05.0-trunk_r58-mini_jammy_legacy_5.10.110.AFM.img.xz

Armbian from MonkaBlyat for R58X (4G/Pro) :
https://monka.systemonachip.net/r58x/Armbian_23.05.0-trunk_r58x_jammy_legacy_5.10.110.AFM.img.xz

RKDevTool and SPI boot loader for Armbian :
https://drive.google.com/file/d/1Gg9So9nuVax_AC82UQJOq1mHBea3sQ4q/view?usp=share_link

Here all my gathered info :

Mekotronics R58X-4G

Armbian Jammy Gnome kernel 5.10.110-rockchip

Video flow

    Intro
    Open devices
    Go over specs
    Show how to install new image
    Benchmarks
    Termperatures
    Transfer rates
    remarks
    pros/cons
    closing

Benchmarks
7z decompression all cores : 16854
7z decompression small core : 1768 (core 0)
7z decompression big core : 2986 (core 1)

NicoD blender benchmark pro : 3m23s
NicoD blender benchmark 4G : 3m28s

Temperatures
R58-mini
Idle : 45C
Maxed out : 81C

R58X-4G
Idle : 41C
Maxed out : 65C

R58X-Pro
Idle : 47C
Maxed out : 80C

Transfer rates
eMMC 64GB read R58X-4G : 272.9 MB/s
eMMC 64GB write R58X-4G : 80-140 MB/s

eMMC 64GB read R58X-Pro/Mini : 325.8 MB/s
eMMC 64GB write R58X-Pro : 280-240 MB/s
eMMC 64GB write R58-Mini write : 320-280 MB/s

4G Samsung 980 NVMe read : 3.1 GB/s
4G Samsung 980 NVMe write : 623.2 MB/s

Pro Samsung 970 QVO USB3 -> SSD read : 395.5 MB/s
Pro Samsung 970 QVO USB3 -> SSD write : 374.9 MB/s

Pro USB-C with hub -> USB3 to SSD read : 391.3 MB/s
Pro USB-C with hub -> USB3 to SSD write : 375.6 MB/s

Mini SATA with ribbon read : 468.8 MB/s
Mini SATA with ribbon write : 521.3 MB/s

Power consumption

Remarks
!!! Core 0 is small, 1 - 4 big and 5 - 7 small | Other RK3588 devices have 0 - 3 small and 4 - 7 big
!!! HDMI ports can be buggy when waking up the device. Then need to replug the connector. The same switching with my HDMI switch. Using Armbian Jammy on R58X-4G
!!! External sound device needs to be selected every boot/reboot. Armbian Jammy R58X-4G

Instructions
Start with Armbian Jammy CLI/server
To install the wayland blob GPU driver
wget https://github.com/numbqq/mali-debs/blob/master/jammy/arm64/Edge2/wayland/linux-gpu-mali-wayland_1.0-g610-20220510_arm64.deb
and install it into the system with the command :
sudo dpkg -i --force-overwrite linux-gpu-mali-wayland_1.0-g610-20220510_arm64.deb

For panfork and VPU
sudo add-apt-repository ppa:liujianfeng1994/panfork-mesa
sudo add-apt-repository ppa:liujianfeng1994/rockchip-multimedia
sudo apt update
sudo apt dist-upgrade
sudo apt install mali-g610-firmware rockchip-multimedia-config libv4l-rkmpp

Install Gnome desktop
sudo apt install ubuntu-desktop

And additional packages from multimedia repo : https://forum.radxa.com/t/introduction-to-rockchip-multimedia-ppa-for-ubuntu-jammy/14537
sudo apt install chromium-browser gstreamer1.0-rockchip clapper ffmpeg kodi moonlight-embedded moonlight-qt obs-gstreamer obs-studio

Build Box86/64, install Wine/PPSSPP and build Xonotic
https://github.com/NicoD-SBC/armbian-gaming

Pros/Cons
+++ My favorite RK3588 devices by far. Easy to work with. I love the layout and metal case.
+++ 4G has good I/O with fast NVMe + SATA + 2 x USB3(USB3+USB-C)
+++ Armbian progress is going well. Will be in armbian-build to build your own images. Pro it’s new devices will take some time. 10GbE doesn’t work yet.
+++ Has GPU and VPU drivers
— Still in development. Not yet for a novice Linux user.
— Only GbE. The Pro comes with 10GbE but uses the M.2 slot, so it’s a choice in having fast NVMe or 10GbE
— Has to use dirty Rockchip kernel
— No forum or good wiki

Board              | OS                            | Kernel         | Clockspeeds             | 7z b all cores     | 7z b core small core    | 7z b big core   | NicoD Blender    | Supertuxkart 
Khadas VIM2          Ubuntu 20.04 Gnome              5.18.0           1.4Ghz A53/1Ghz A53       7728                 900 (core 7)              1235 (core 0)     18m26s 2.79b       5fps    
Khadas VIM2          Armbian Kinetic server          6.1.0-meson64    1.4Ghz A53/1Ghz A53       7867                                           1252 (core 0) 
Khadas VIM3          Ubuntu 20.04 Gnome              5.18.0           1.8Ghz A53/2.2Ghz A73     10300                1636 (core 0)             2417 (core 5)     9m38s  2.79b       19fps   
Khadas VIM4          Ubuntu 22.04 Gnome              5.4.125          2.2Ghz A73/2Ghz A53       14138                1775 (core 7)             2299 (core 0)     5m46s              52fps     
Khadas VIM4          Debian 10 xfce4                 5.4.125          2.2Ghz A73/2Ghz A53       15113                1830 (core 7)             2334 (core 0)     7m15s  2.79b                                  
Station P1           Armbian Jammy xfce4             5.18.19          1.4Ghz A53/1.8Ghz A72     7607                 1248 (core 0)             1843 (core 5)     10m10s             7fps       
Odroid N2+           Armbian Jammy xfce4             5.10.139         2Ghz A53/2.4Ghz A73       11755                1761 (core 0)             2518 (core 5)     5m53s              18fps    
Odroid N2+           Armbian Kinetic server          6.1.0-meson64    2Ghz A53/2.4Ghz A73       11807                1764 (core 0)             2520 (core 5)     xxx                18fps
Odroid C2            Armbian kinetic server          6.1.0-meson64    1.5Ghz                    5173                 1320 (core 0)                           
Khadas Edge2         Ubuntu 22.04 Gnome              5.10.66          1.8Ghz A55/2.35Ghz*** A76 16901                1766 (core 0)             2930 (core 7)     3m25s              110fps (wayland)                             
NanoPi R6S           Ubuntu 22.04 Gnome Headless     5.10.110         1.8Ghz A55/2.3Ghz *** A76 16385                1449 (core 0)             2493 (core 7)     3m27s              110fps (wayland)                  
Mekotronics R58 mini Debian Bullseye x11 xfce4       5.10.110         1.8Ghz A55/2.2Ghz A76     16241                1758 (core 0)             2839 (core 1)     4m50s V2.83.5
Mekotronics R58 mini Debian Bullseye wayland         5.10.110         1.8Ghz A55/2.2Ghz A76     16803                1777 (core 0)             2879 (core 1)     4m35s              110fps (wayland) 
Mekotronics R58 mini Ubuntu 20.04 x11                5.10.66          1.8Ghz A55/2.2Ghz A76     16477                1765 (core 0)             2897 (core 1)     5m53s V2.82        4fps (llvmpipe)
Mekotronics R58 mini Manjaro Gnome                   5.10.66-28rk     1.8Ghz A55/2.2Ghz A76     16153                1572 (core 0)             2568 (core 1)
Mekotronics R58X-Pro Armbian Jammy Gnome             5.10.110-rk      1.8Ghz A55/2.3Ghz A76     16854                1768 (core 0)             2986 (core 1)     3m23s              110fps (wayland)
Mekotronics R58X-4G  Armbian Jammy Gnome             5.10.110-rk      1.8Ghz A55/2.2Ghz A76     16497                1767 (core 0)             2874 (core 1)     3m28s              79fps (panfork) 

Start PUTTY and enter your Orange Pi's IP address or host name (orangepi5) into PUTTY's Host Name field, hit enter.

Accept any certificate popup screens.

Login with Armbian's default user and pass.

USER(logon): root
PASSWORD: 1234

You'll be prompted with your Orange Pi's IP address. Take note of that, you might want to use it to remote connect, though you can also use the Orange Pi default hostname (orangepi5).
Next, you'll be prompted to complete the following...create a root password, select bash or zsh, create a user and user password, enter real name, select timezone, and select locale.
Take note of the User Name and Password you created since you will use that to logon with the Windows Remote Desktop Client.
After completing account setup, you should be at a blank command prompt.
 

DO NOT RUN ANY UPDATE COMMANDS
 

enter the following commands...

sudo apt install xrdp xorgxrdp
sudo systemctl enable xrdp
sudo systemctl status xrdp

After entering the systemctl status xrdp command , you should see a listing showing "Active: active (running)". If Active shows "failed" then you will not be capable of connecting via Remote Desktop. **See below to try and resolve this issue.

If you get a successful status list then, press the Ctrl key and C key simultaneously to get back to the command prompt.

Reboot your Orange Pi by entering

sudo reboot

You should now be capable of accessing your OrangePi remotely by using Windows Remote Desktop.

Open your Windows Remote Desktop client.

You can adjust the size of the Remote Desktop screen session by clicking the "Show Options" located at the lower left corner of the Remote Desktop logon windows, then click the "Display" tab to set your preferred screen size, among other options.

In the Computer field, enter your Orange Pi's IP address or host name (orangepi5), hit Connect.

You should now be prompted with an XRDP logon screen. Enter the username and password you created when setting up Armbian during the PUTYY session.

**INSTRUCTION TO ATTEMPT TO RESOLVE A FAILED SYSTEMCTL STATUS.

If you haven't rebooted, and need to get back to the command prompt, then press the Ctrl key and C key simultaneously to get back to the command prompt.

Enter the following commands to uninstall xrdp...

sudo apt remove xrdp
sudo apt purge xrdp

Reinstall xrdp by following the same instructions at the start of this tutorial. Check the status again by entering the following command...

sudo systemctl status xrdp

Hopefully, this time it will show as "Active: active (running)".

Hope this helps.

Hi everybody,

Here is a tutorial to enable the Lemaker 7" Touchscreen on BananaPi Pro with Debian Buster and Mainline-Kernel 5.XX.XX.

Kernel: Mainline 5.4.6 / Buster
Board: BananaPi Pro

WebLinks:

    • https://forum.armbian.com/topic/1905-enabling-lcd-in-u-boot-kernel-472/
    • https://forum.armbian.com/topic/1849-touch-driver-banana-pi/
    • http://www.atakansarioglu.com/getting-started-bananapi-linux/
    • http://forum.lemaker.org/thread-15482-1-1.html
    • http://linux-sunxi.org/LCD

To make the 7"LCD and the Touchscreen working with BananaPi Pro we need to patch some files and change the kernel config to build the driver for the touchscreen.
To do this we need a working setup of the Armbian build tool chain (https://docs.armbian.com/Developer-Guide_Build-Preparation/)

/home/<USER>/build/cache/sources/u-boot/v201X.XX/configs/Bananapro_defconfig
/home/<USER>/build/cache/sources/u-boot/v201X.XX/arch/arm/dts/sun7i-a20-bananapro.dts
/home/<USER>/build/cache/sources/linux-mainline/linux-4.XX.y/arch/arm/boot/dts/sun7i-a20-bananapro.dts

1. U-Boot ( u-boot version that supports the LCD - must be compiled)

Start the build process with ./compile.sh CREATE_PATCHES=yes

When asked for:
[ warn ] Applying existing u-boot patch [ /home/[USER]/build/output/patch/u-boot-sunxi-current.patch ]
[ warn ] Make your changes in this directory: [ /home/[USER]/build/cache/sources/u-boot/v201X.XX ]
[ warn ] Press <Enter> after you are done [ waiting ]

a) edit /home/<USER>/build/cache/sources/u-boot/v201X.XX/configs/Bananapro_defconfig

add the following:

#7" LVDS LCD
CONFIG_VIDEO_LCD_MODE="x:1024,y:600,depth:24,pclk_khz:55000,le:100,ri:170,up:10,lo:15,hs:50,vs:10,sync:3,vmode:0"
CONFIG_VIDEO_LCD_PANEL_LVDS=y
CONFIG_VIDEO_LCD_POWER="PH12"
CONFIG_VIDEO_LCD_BL_EN="PH8"
CONFIG_VIDEO_LCD_BL_PWM="PB2"

b) edit /home/<user>/build/cache/sources/u-boot/v201X.XX/arch/arm/dts/sun7i-a20-bananapro.dts

 add after:

&i2c2 {
    ...
};

the following:

&i2c3 {
	status = "okay";
	pinctrl-names = "default";
	pinctrl-0 = <&i2c3_pins>;
	edt: edt-ft5x06@38 {
		compatible = "edt,edt-ft5x06", "edt,edt-ft5206";
		reg = <0x38>;
		pinctrl-names = "default";
		pinctrl-0 = <&edt_ft5x06_pins_a &edt_ft5x06_pins_b>;
		interrupt-parent = <&pio>;
		interrupts = <7 9 IRQ_TYPE_EDGE_FALLING>;
		touchscreen-size-x = <1024>;
		touchscreen-size-y = <600>;
	};
};

Add these two new sections to the end of the file:

&pio {
    edt_ft5x06_pins_a: ft5@0 {
        pins = "PH9";
        function = "irq";
        drive-strength = <20>;
        bias-pull-up;
    };
    edt_ft5x06_pins_b: ft5@1 {
        pins = "PH7";
        function = "gpio_out";
        drive-strength = <20>;
        bias-pull-up;
        output-high;
    };
};

&pwm {
      pinctrl-names = "default";
      pinctrl-0 = <&pwm0_pin>, <&pwm1_pin>;
      status = "okay";
};

Then save and press <Enter> to continue.

2. Kernel patches - DTB (Device Tree Blob) file that fits to your Kernel and supports pwm

When asked for:
[ warn ] Applying existing kernel patch [ /home/<USER>/build/output/patch/kernel-sunxi-current.patch ]
[ warn ] Make your changes in this directory: [ /home/<USER>/build/cache/sources/linux-mainline/orange-pi-5.XX ]
[ warn ] Press <Enter> after you are done [ waiting ]

c) edit /home/<USER>/build/cache/sources/linux-mainline/orange-pi-5.XX/arch/arm/boot/dts/sun7i-a20-bananapro.dts

add the same lines like section b)

Then save and press <Enter> to continue.

3. Compile Touchdriver

menuconfig > Device Drivers > Input Device Support > Touchscreens > EDT FocalTech FT5x06 I2C Touchscreen support

Exit and save the Kernel configuration.

This is the outcome. You probably have a newer version than 19.11.4:

Now you can flash the image to a SD-Card or you have to install the new DEBs.

dpkg -i linux-u-boot-current-bananapipro_19.11.4_armhf.deb
dpkg -i linux-dtb-current-sunxi_19.11.4_armhf.deb
dpkg -i linux-image-current-sunxi_19.11.4_armhf.deb

reboot

The result:

The LCD and the touchscreen are working.

Attention!
There is still the problem with the shutdown.
When the patches were made for the LCD, the board did not shut down completely during a shutdown (LCD still had voltage and the red LED on the board did not go out).
 

Workaround:

We need to disable the LCD before the shutdown is finished.

Therfore we have to create a script in the folder /lib/systemd/system-shutdown

e.g. (as root)

touch /lib/systemd/system-shutdown/lcd_off.sh

chmod +x /lib/systemd/system-shutdown/lcd_off.sh

nano /lib/systemd/system-shutdown/lcd_off.sh

add these lines:

#!/bin/bash

# LCD Power			PH12	H=8		(8-1)*32+12		= 236
# Backlight enable	PH8		H=8		(8-1)*32+8		= 232
# Backlight PWM		PB2		B=2		(2-1)*32+2		= 34

if [ ! -d "/sys/class/gpio/gpio34" ] 
then
    sudo sh -c 'echo "34" > /sys/class/gpio/export'
	sudo sh -c 'echo "out" > /sys/class/gpio/gpio34/direction'
	sudo sh -c 'echo "1" > /sys/class/gpio/gpio34/value'
fi
if [ ! -d "/sys/class/gpio/gpio232" ] 
then
    sudo sh -c 'echo "232" > /sys/class/gpio/export'
	sudo sh -c 'echo "out" > /sys/class/gpio/gpio232/direction'
	sudo sh -c 'echo "1" > /sys/class/gpio/gpio232/value'
fi
if [ ! -d "/sys/class/gpio/gpio236" ] 
then
    sudo sh -c 'echo "236" > /sys/class/gpio/export'
	sudo sh -c 'echo "out" > /sys/class/gpio/gpio236/direction'
	sudo sh -c 'echo "1" > /sys/class/gpio/gpio236/value'
fi

# LCD on/off
sudo sh -c 'echo "0" > /sys/class/gpio/gpio34/value'
sudo sh -c 'echo "0" > /sys/class/gpio/gpio232/value'
sudo sh -c 'echo "0" > /sys/class/gpio/gpio236/value'

The script will be executed right before the board powers off.

Measured power consumption:

PowerON (booting / lcd still off) = 0.4A - 0.5A

LCD turns on (still booting) = 0.85A - 1.05A

Boot process ended (LCD on) = 0.75A

Board on, LCD off = 0.35A - 0.45A ( -> LCD needs around 0.4A power )

shutdown -h now = 0.00A

4. Control the Power of the Backlight:

The backlight PWM is on PIN CON2 PB2.

Following the instructions on

http://linux-sunxi.org/GPIO#Accessing_the_GPIO_pins_through_sysfs_with_mainline_kernel

http://forum.lemaker.org/thread-10852-1-1.html

we have to export GPIO-PIN 34.

(position of letter in alphabet - 1) * 32 + pin number

position of letter in alphabet: B = 2
pin number: 2

( 2 - 1 ) * 32 + 2 = 34

echo 34 > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio34/direction

Power on the Backlight:
echo "1" > /sys/class/gpio/gpio34/value

Power off the Backlight:
echo "0" > /sys/class/gpio/gpio34/value

Now we could use a switch connected to a GPIO-IN to control the backlight.

Steffen

CH340-fan-control is a python script to only activate my TV boxes USB fan when required by using a USB relay module. I'd expect somebody (or several somebodies) have already wrote a similar script for the same device but I failed to find it so here is my effort at fixing this common TV box issue. Hopefully someone else will find it useful.

https://github.com/danboid/CH340-fan-control

 

Greetings, NicoD

I've finished my review of the PineBook Pro. I just love this thing. Runs great with Armbian.

Here my video.

Here all my gathered information:

Version                   Frequency        NicoD Belnder CLI    7-zip a/c      7-zip s/c     7-zip b/c     CPUMiner     SBC-Bench
-------                   ---------        -----------------    ---------      ---------     ---------     --------     ---------
Armbian Focal Mate 5.10   2Ghz/1.5Ghz      13m29s               8422           1347          2062          10.8         http://ix.io/3qsC
Armbian Focal Mate 5.10   1.8Ghz/1.4Ghz    14m20s               7906           1267          1855          10.3         http://ix.io/3qt9  
TwOS Armbian Focal 5.10   1.8Ghz/1.4Ghz    14m40s               
Armbian Buster xfce4 5.10 1.8Ghz/1.4Ghz    15m00s               8074           1303          1843          10.2         http://ix.io/3rdx
Armbian Hirsute cinamon 5.12 1.8/1.4Ghz    14m39s               7907           1264          1854          10.1         http://ix.io/3rjc   
Armbian Focal xfce4 5.10  1.8Ghz/1.4Ghz    14m52s               7764           1242          1843          10.1         http://ix.io/3rjx

Odroid N2+ Bionic 4.9     2Ghz/2.4Ghz       9m01s              11702           1756          2504          14

Transfer rates                                    access time
--------------                                    -----------
SD-card 128GB Sandisk Extreme read 68.8 MB/s      0.42 msec
                             write 58.2 MB/s
eMMC 64GB read                     187 MB/s       0.23 msec
eMMC 64GB write                    145 MB/s
NVMe 256GB read                    802 MB/s       0.03 msec
NVMe 256GB write                   423 MB/s                       #starts at 850 MB/s then goes down to 260 MB/s
SSD over USB3 read                 406 MB/s       0.21 msec
SSD over USB3 write                244 MB/s                       #starts at 220
SSD over USB2 read                 35.3 MB/s      0.51 msec
SSD over USB2 write                32.3 MB/s      

Temperatures 
------------
1.8Ghz/1.4Ghz
Idle          45C
Maxed out     75C on desk
              80C with back raised 
   
2Ghz/1.5Ghz
Idle          47C
Maxed out     86C (light throttling at 85C)

Power consumption
-----------------
Charging while on   2.6A  (max with 60 000mAh power bank, most PSU's don't go over 2A)
Charging while off  2.5A

Browsing and video playback
---------------------------
Vivaldi runs gpu accelerated browsing and perfect video playback up to 1080p30fps or 720p60fps
         download Vivaldi snapshot arm64
                 sudo apt install fonts-liberation
                 sudo dpkg -i vivaldi-snapshot..._arm64.deb
Firefox runs a bit smoother for browsing, but video playback isn't fully accelerated 
                
For video files kodi runs well
         sudo apt install kodi

+++
You can disable Microphone, wifi and camera with key combinations. Pine64 Logo + F10, F11 and F12
Can be powered with either barrel jack or USB type-C 5V !!!Not with both at the same time!!!
USB-C can be used for external display with USB-C to HDMI adapter
---
It can deplete the battery while being charged in heavy use and full brightness, cetainly when using an NVMe
USB-c hub not working
Delete key is backspace with function key
Very low volume in TwisterOS
Too many screws to open


Conclusion
----------
Awesome hardware. I love to have an ARM SoC in a laptop. The RK3399 is the best supported SoC software wise.
Tho a laptop with Amlogic S922x would have been great too. It is more powerful while consuming less.
I would not easily recommend it to people who are not used using ARM. But for me it is near perfect.
It looks great, and the keyboard feels good. 

TwisterOS upgrade problem fix from PtitSeb
sudo mv /usr/share/doc/linux-libc-dev/changelog.Debian.gz /usr/share/doc/linux-libc-dev/changelog.Debian.gz.old 
    to "solve" the conflict, and than the --fix-broken worked
    
Armbian Focal Mate 5.10 has some issue's with battery monitor applet. And power management isn't working as it should.
Armbian Focal xfce4 5.10 Doesn't always boot, black display.
TwisterOS Armbian Focal 5.10 power led only goes on after a while when default os. Speakers are very quiet.
Armbian Buster xfce4 5.10 Doesn't always boot. Black display. 

• mainline based u-boot 2021.07
• Ubuntu 22.04 Jammy LTS based (upcoming release, could have issues, currently in testing phase)
• kernel 5.10.y LTS or 5.15.y LTS
• ZSH with OhMyZSH addon or classic BASH
• ZFS 2.1.y support
• Wireguard
• fan and LCD support
• boot from SPI / HDD / USB

Tested on image (which comes with preinstalled headers, stable kernel):

https://redirect.armbian.com/odroidhc4/Jammy_current

https://redirect.armbian.com/odroidhc4/Jammy_current.torrent

apt update and upgrade

odroidhc4:igorp:# apt update 
Get:1 http://ports.ubuntu.com jammy InRelease [270 kB]
Hit:2 http://ports.ubuntu.com jammy-security InRelease                            
Hit:3 http://ports.ubuntu.com jammy-updates InRelease
Hit:4 http://ports.ubuntu.com jammy-backports InRelease
Get:6 http://ports.ubuntu.com jammy/universe arm64 Packages [16.7 MB]
Hit:5 https://stpete-mirror.armbian.com/apt jammy InRelease
Get:7 http://ports.ubuntu.com jammy/main armhf Packages [1,732 kB]
Get:8 http://ports.ubuntu.com jammy/main arm64 Packages [1,757 kB]
Get:9 http://ports.ubuntu.com jammy/universe armhf Packages [16.4 MB]
Fetched 36.9 MB in 3s (11.0 MB/s)                           
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
59 packages can be upgraded. Run 'apt list --upgradable' to see them.
odroidhc4:igorp:# apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  apt apt-utils automake binutils binutils-aarch64-linux-gnu binutils-common busybox-initramfs console-setup console-setup-linux
  cpp-11 ethtool g++-11 gcc-11 gcc-11-base keyboard-configuration libapt-pkg6.0 libasan6 libatomic1 libbinutils libbluetooth3
  libboost-iostreams1.74.0 libcc1-0 libctf-nobfd0 libctf0 libdw1 libelf1 libgcc-11-dev libgcc-s1 libgomp1 libhwasan0 libitm1
  liblsan0 libmm-glib0 libncurses6 libncursesw6 libnftnl11 libpcre2-8-0 libpython3.9 libpython3.9-minimal libpython3.9-stdlib
  libsasl2-2 libsasl2-modules-db libstdc++-11-dev libstdc++6 libtinfo6 libtsan0 libubsan1 ncurses-base ncurses-bin ncurses-term
  python3-distutils python3-launchpadlib python3-lib2to3 python3-software-properties python3-yaml python3.9 python3.9-minimal
  rsyslog software-properties-common
59 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 71.7 MB of archives.
After this operation, 385 MB disk space will be freed.
Do you want to continue? [Y/n] 
Get:1 http://ports.ubuntu.com jammy/main arm64 libncurses6 arm64 6.3-1 [108 kB]
Get:2 http://ports.ubuntu.com jammy/main arm64 libncursesw6 arm64 6.3-1 [142 kB]
Get:3 http://ports.ubuntu.com jammy/main arm64 libtinfo6 arm64 6.3-1 [104 kB]
Get:4 http://ports.ubuntu.com jammy/main arm64 ncurses-bin arm64 6.3-1 [183 kB]
Get:5 http://ports.ubuntu.com jammy/main arm64 ncurses-base all 6.3-1 [19.9 kB]
Get:6 http://ports.ubuntu.com jammy/main arm64 libcc1-0 arm64 11.2.0-12ubuntu1 [54.1 kB]
Get:7 http://ports.ubuntu.com jammy/main arm64 gcc-11-base arm64 11.2.0-12ubuntu1 [20.7 kB]
Get:8 http://ports.ubuntu.com jammy/main arm64 libgcc-s1 arm64 11.2.0-12ubuntu1 [39.3 kB]
Get:9 http://ports.ubuntu.com jammy/main arm64 libgomp1 arm64 11.2.0-12ubuntu1 [115 kB]
Get:10 http://ports.ubuntu.com jammy/main arm64 libitm1 arm64 11.2.0-12ubuntu1 [28.4 kB]
Get:11 http://ports.ubuntu.com jammy/main arm64 libatomic1 arm64 11.2.0-12ubuntu1 [10.8 kB]
Get:12 http://ports.ubuntu.com jammy/main arm64 libasan6 arm64 11.2.0-12ubuntu1 [2,228 kB]
Get:13 http://ports.ubuntu.com jammy/main arm64 liblsan0 arm64 11.2.0-12ubuntu1 [942 kB]
Get:14 http://ports.ubuntu.com jammy/main arm64 libtsan0 arm64 11.2.0-12ubuntu1 [2,232 kB]
Get:15 http://ports.ubuntu.com jammy/main arm64 libubsan1 arm64 11.2.0-12ubuntu1 [908 kB]
Get:16 http://ports.ubuntu.com jammy/main arm64 libhwasan0 arm64 11.2.0-12ubuntu1 [1,010 kB]
Get:17 http://ports.ubuntu.com jammy/main arm64 g++-11 arm64 11.2.0-12ubuntu1 [11.1 MB]
Get:18 http://ports.ubuntu.com jammy/main arm64 libstdc++-11-dev arm64 11.2.0-12ubuntu1 [2,099 kB]
Get:19 http://ports.ubuntu.com jammy/main arm64 libgcc-11-dev arm64 11.2.0-12ubuntu1 [1,150 kB]
Get:20 http://ports.ubuntu.com jammy/main arm64 gcc-11 arm64 11.2.0-12ubuntu1 [19.4 MB]
Get:21 http://ports.ubuntu.com jammy/main arm64 cpp-11 arm64 11.2.0-12ubuntu1 [9,734 kB]
Get:22 http://ports.ubuntu.com jammy/main arm64 libstdc++6 arm64 11.2.0-12ubuntu1 [623 kB]
Get:23 http://ports.ubuntu.com jammy/main arm64 libctf0 arm64 2.37-10ubuntu1 [102 kB]
Get:24 http://ports.ubuntu.com jammy/main arm64 libctf-nobfd0 arm64 2.37-10ubuntu1 [106 kB]
Get:25 http://ports.ubuntu.com jammy/main arm64 libbinutils arm64 2.37-10ubuntu1 [733 kB]
Get:26 http://ports.ubuntu.com jammy/main arm64 binutils-common arm64 2.37-10ubuntu1 [213 kB]
Get:27 http://ports.ubuntu.com jammy/main arm64 binutils arm64 2.37-10ubuntu1 [3,160 B]
Get:28 http://ports.ubuntu.com jammy/main arm64 binutils-aarch64-linux-gnu arm64 2.37-10ubuntu1 [3,214 kB]
Get:29 http://ports.ubuntu.com jammy/main arm64 libapt-pkg6.0 arm64 2.3.12 [864 kB]
Get:30 http://ports.ubuntu.com jammy/main arm64 apt arm64 2.3.12 [1,353 kB]
Get:31 http://ports.ubuntu.com jammy/main arm64 apt-utils arm64 2.3.12 [205 kB]
Get:32 http://ports.ubuntu.com jammy/main arm64 console-setup-linux all 1.205ubuntu3 [1,871 kB]
Get:33 http://ports.ubuntu.com jammy/main arm64 console-setup all 1.205ubuntu3 [110 kB]
Get:34 http://ports.ubuntu.com jammy/main arm64 keyboard-configuration all 1.205ubuntu3 [206 kB]
Get:35 http://ports.ubuntu.com jammy/main arm64 libpython3.9 arm64 3.9.9-1 [1,848 kB]
Get:36 http://ports.ubuntu.com jammy/main arm64 python3.9 arm64 3.9.9-1 [437 kB]
Get:37 http://ports.ubuntu.com jammy/main arm64 libpython3.9-stdlib arm64 3.9.9-1 [1,803 kB]
Get:38 http://ports.ubuntu.com jammy/main arm64 python3.9-minimal arm64 3.9.9-1 [2,121 kB]
Get:39 http://ports.ubuntu.com jammy/main arm64 libpython3.9-minimal arm64 3.9.9-1 [781 kB]
Get:40 http://ports.ubuntu.com jammy/main arm64 libpcre2-8-0 arm64 10.39-3 [201 kB]
Get:41 http://ports.ubuntu.com jammy/main arm64 libdw1 arm64 0.186-1 [246 kB]
Get:42 http://ports.ubuntu.com jammy/main arm64 libelf1 arm64 0.186-1 [51.1 kB]                                                    
Get:43 http://ports.ubuntu.com jammy/main arm64 python3-yaml arm64 5.4.1-1 [159 kB]                                                
Get:44 http://ports.ubuntu.com jammy/main arm64 rsyslog arm64 8.2110.0-3ubuntu1 [496 kB]                                           
Get:45 http://ports.ubuntu.com jammy/main arm64 libnftnl11 arm64 1.2.1-1 [64.4 kB]                                                 
Get:46 http://ports.ubuntu.com jammy/main arm64 automake all 1:1.16.5-1.1 [558 kB]                                                 
Get:47 http://ports.ubuntu.com jammy/main arm64 busybox-initramfs arm64 1:1.30.1-7ubuntu1 [176 kB]                                 
Get:48 http://ports.ubuntu.com jammy/main arm64 ethtool arm64 1:5.15-1 [206 kB]                                                    
Get:49 http://ports.ubuntu.com jammy/main arm64 libbluetooth3 arm64 5.62-0ubuntu2 [89.3 kB]                                        
Get:50 http://ports.ubuntu.com jammy/main arm64 libboost-iostreams1.74.0 arm64 1.74.0-13ubuntu1 [243 kB]                           
Get:51 http://ports.ubuntu.com jammy/main arm64 libmm-glib0 arm64 1.18.2-0ubuntu1 [230 kB]                                         
Get:52 http://ports.ubuntu.com jammy/main arm64 libsasl2-modules-db arm64 2.1.27+dfsg2-2 [21.2 kB]                                 
Get:53 http://ports.ubuntu.com jammy/main arm64 libsasl2-2 arm64 2.1.27+dfsg2-2 [55.6 kB]                                          
Get:54 http://ports.ubuntu.com jammy/main arm64 ncurses-term all 6.3-1 [268 kB]                                                    
Get:55 http://ports.ubuntu.com jammy/main arm64 python3-distutils all 3.9.9-2 [144 kB]                                             
Get:56 http://ports.ubuntu.com jammy/main arm64 python3-lib2to3 all 3.9.9-2 [77.8 kB]                                              
Get:57 http://ports.ubuntu.com jammy/main arm64 python3-launchpadlib all 1.10.15.1-1 [119 kB]                                      
Get:58 http://ports.ubuntu.com jammy/main arm64 software-properties-common all 0.99.16 [14.3 kB]                                   
Get:59 http://ports.ubuntu.com jammy/main arm64 python3-software-properties all 0.99.16 [32.2 kB]                                  
Fetched 71.7 MB in 6s (11.3 MB/s)                                                                                                  
Extracting templates from packages: 100%
Preconfiguring packages ...
(Reading database ... 67209 files and directories currently installed.)
Preparing to unpack .../libncurses6_6.3-1_arm64.deb ...
Unpacking libncurses6:arm64 (6.3-1) over (6.2+20201114-2build2) ...
Preparing to unpack .../libncursesw6_6.3-1_arm64.deb ...
Unpacking libncursesw6:arm64 (6.3-1) over (6.2+20201114-2build2) ...
Preparing to unpack .../libtinfo6_6.3-1_arm64.deb ...
Unpacking libtinfo6:arm64 (6.3-1) over (6.2+20201114-2build2) ...
Setting up libtinfo6:arm64 (6.3-1) ...
(Reading database ... 67209 files and directories currently installed.)
Preparing to unpack .../ncurses-bin_6.3-1_arm64.deb ...
Unpacking ncurses-bin (6.3-1) over (6.2+20201114-2build2) ...
Setting up ncurses-bin (6.3-1) ...
(Reading database ... 67209 files and directories currently installed.)
Preparing to unpack .../ncurses-base_6.3-1_all.deb ...
Unpacking ncurses-base (6.3-1) over (6.2+20201114-2build2) ...
Setting up ncurses-base (6.3-1) ...
(Reading database ... 67209 files and directories currently installed.)
Preparing to unpack .../libcc1-0_11.2.0-12ubuntu1_arm64.deb ...
Unpacking libcc1-0:arm64 (11.2.0-12ubuntu1) over (11.2.0-10ubuntu1) ...
Preparing to unpack .../gcc-11-base_11.2.0-12ubuntu1_arm64.deb ...
Unpacking gcc-11-base:arm64 (11.2.0-12ubuntu1) over (11.2.0-10ubuntu1) ...
Setting up gcc-11-base:arm64 (11.2.0-12ubuntu1) ...
(Reading database ... 67209 files and directories currently installed.)
Preparing to unpack .../libgcc-s1_11.2.0-12ubuntu1_arm64.deb ...
Unpacking libgcc-s1:arm64 (11.2.0-12ubuntu1) over (11.2.0-10ubuntu1) ...
Setting up libgcc-s1:arm64 (11.2.0-12ubuntu1) ...
(Reading database ... 67209 files and directories currently installed.)
Preparing to unpack .../00-libgomp1_11.2.0-12ubuntu1_arm64.deb ...
Unpacking libgomp1:arm64 (11.2.0-12ubuntu1) over (11.2.0-10ubuntu1) ...
Preparing to unpack .../01-libitm1_11.2.0-12ubuntu1_arm64.deb ...
Unpacking libitm1:arm64 (11.2.0-12ubuntu1) over (11.2.0-10ubuntu1) ...
Preparing to unpack .../02-libatomic1_11.2.0-12ubuntu1_arm64.deb ...
Unpacking libatomic1:arm64 (11.2.0-12ubuntu1) over (11.2.0-10ubuntu1) ...
Preparing to unpack .../03-libasan6_11.2.0-12ubuntu1_arm64.deb ...
Unpacking libasan6:arm64 (11.2.0-12ubuntu1) over (11.2.0-10ubuntu1) ...
Preparing to unpack .../04-liblsan0_11.2.0-12ubuntu1_arm64.deb ...
Unpacking liblsan0:arm64 (11.2.0-12ubuntu1) over (11.2.0-10ubuntu1) ...
Preparing to unpack .../05-libtsan0_11.2.0-12ubuntu1_arm64.deb ...
Unpacking libtsan0:arm64 (11.2.0-12ubuntu1) over (11.2.0-10ubuntu1) ...
Preparing to unpack .../06-libubsan1_11.2.0-12ubuntu1_arm64.deb ...
Unpacking libubsan1:arm64 (11.2.0-12ubuntu1) over (11.2.0-10ubuntu1) ...
Preparing to unpack .../07-libhwasan0_11.2.0-12ubuntu1_arm64.deb ...
Unpacking libhwasan0:arm64 (11.2.0-12ubuntu1) over (11.2.0-10ubuntu1) ...
Preparing to unpack .../08-g++-11_11.2.0-12ubuntu1_arm64.deb ...
Unpacking g++-11 (11.2.0-12ubuntu1) over (11.2.0-10ubuntu1) ...
Preparing to unpack .../09-libstdc++-11-dev_11.2.0-12ubuntu1_arm64.deb ...
Unpacking libstdc++-11-dev:arm64 (11.2.0-12ubuntu1) over (11.2.0-10ubuntu1) ...
Preparing to unpack .../10-libgcc-11-dev_11.2.0-12ubuntu1_arm64.deb ...
Unpacking libgcc-11-dev:arm64 (11.2.0-12ubuntu1) over (11.2.0-10ubuntu1) ...
Preparing to unpack .../11-gcc-11_11.2.0-12ubuntu1_arm64.deb ...
Unpacking gcc-11 (11.2.0-12ubuntu1) over (11.2.0-10ubuntu1) ...
Preparing to unpack .../12-cpp-11_11.2.0-12ubuntu1_arm64.deb ...
Unpacking cpp-11 (11.2.0-12ubuntu1) over (11.2.0-10ubuntu1) ...
Preparing to unpack .../13-libstdc++6_11.2.0-12ubuntu1_arm64.deb ...
Unpacking libstdc++6:arm64 (11.2.0-12ubuntu1) over (11.2.0-10ubuntu1) ...
Setting up libstdc++6:arm64 (11.2.0-12ubuntu1) ...
(Reading database ... 67211 files and directories currently installed.)
Preparing to unpack .../0-libctf0_2.37-10ubuntu1_arm64.deb ...
Unpacking libctf0:arm64 (2.37-10ubuntu1) over (2.37-9ubuntu1) ...
Preparing to unpack .../1-libctf-nobfd0_2.37-10ubuntu1_arm64.deb ...
Unpacking libctf-nobfd0:arm64 (2.37-10ubuntu1) over (2.37-9ubuntu1) ...
Preparing to unpack .../2-libbinutils_2.37-10ubuntu1_arm64.deb ...
Unpacking libbinutils:arm64 (2.37-10ubuntu1) over (2.37-9ubuntu1) ...
Preparing to unpack .../3-binutils-common_2.37-10ubuntu1_arm64.deb ...
Unpacking binutils-common:arm64 (2.37-10ubuntu1) over (2.37-9ubuntu1) ...
Preparing to unpack .../4-binutils_2.37-10ubuntu1_arm64.deb ...
Unpacking binutils (2.37-10ubuntu1) over (2.37-9ubuntu1) ...
Preparing to unpack .../5-binutils-aarch64-linux-gnu_2.37-10ubuntu1_arm64.deb ...
Unpacking binutils-aarch64-linux-gnu (2.37-10ubuntu1) over (2.37-9ubuntu1) ...
Preparing to unpack .../6-libapt-pkg6.0_2.3.12_arm64.deb ...
Unpacking libapt-pkg6.0:arm64 (2.3.12) over (2.3.11) ...
Setting up libapt-pkg6.0:arm64 (2.3.12) ...
(Reading database ... 67211 files and directories currently installed.)
Preparing to unpack .../archives/apt_2.3.12_arm64.deb ...
Unpacking apt (2.3.12) over (2.3.11) ...
Setting up apt (2.3.12) ...
Installing new version of config file /etc/cron.daily/apt-compat ...
(Reading database ... 67211 files and directories currently installed.)
Preparing to unpack .../0-apt-utils_2.3.12_arm64.deb ...
Unpacking apt-utils (2.3.12) over (2.3.11) ...
Preparing to unpack .../1-console-setup-linux_1.205ubuntu3_all.deb ...
Unpacking console-setup-linux (1.205ubuntu3) over (1.205ubuntu1) ...
Preparing to unpack .../2-console-setup_1.205ubuntu3_all.deb ...
Unpacking console-setup (1.205ubuntu3) over (1.205ubuntu1) ...
Preparing to unpack .../3-keyboard-configuration_1.205ubuntu3_all.deb ...
Unpacking keyboard-configuration (1.205ubuntu3) over (1.205ubuntu1) ...
Preparing to unpack .../4-libpython3.9_3.9.9-1_arm64.deb ...
Unpacking libpython3.9:arm64 (3.9.9-1) over (3.9.8-2) ...
Preparing to unpack .../5-python3.9_3.9.9-1_arm64.deb ...
Unpacking python3.9 (3.9.9-1) over (3.9.8-2) ...
Preparing to unpack .../6-libpython3.9-stdlib_3.9.9-1_arm64.deb ...
Unpacking libpython3.9-stdlib:arm64 (3.9.9-1) over (3.9.8-2) ...
Preparing to unpack .../7-python3.9-minimal_3.9.9-1_arm64.deb ...
Unpacking python3.9-minimal (3.9.9-1) over (3.9.8-2) ...
Preparing to unpack .../8-libpython3.9-minimal_3.9.9-1_arm64.deb ...
Unpacking libpython3.9-minimal:arm64 (3.9.9-1) over (3.9.8-2) ...
Preparing to unpack .../9-libpcre2-8-0_10.39-3_arm64.deb ...
Unpacking libpcre2-8-0:arm64 (10.39-3) over (10.37-0ubuntu2) ...
Setting up libpcre2-8-0:arm64 (10.39-3) ...
(Reading database ... 67211 files and directories currently installed.)
Preparing to unpack .../00-libdw1_0.186-1_arm64.deb ...
Unpacking libdw1:arm64 (0.186-1) over (0.185-2) ...
Preparing to unpack .../01-libelf1_0.186-1_arm64.deb ...
Unpacking libelf1:arm64 (0.186-1) over (0.185-2) ...
Preparing to unpack .../02-python3-yaml_5.4.1-1_arm64.deb ...
Unpacking python3-yaml (5.4.1-1) over (5.3.1-5) ...
Preparing to unpack .../03-rsyslog_8.2110.0-3ubuntu1_arm64.deb ...
Unpacking rsyslog (8.2110.0-3ubuntu1) over (8.2102.0-2ubuntu2) ...
Preparing to unpack .../04-libnftnl11_1.2.1-1_arm64.deb ...
Unpacking libnftnl11:arm64 (1.2.1-1) over (1.2.0-1) ...
Preparing to unpack .../05-automake_1%3a1.16.5-1.1_all.deb ...
Unpacking automake (1:1.16.5-1.1) over (1:1.16.5-1ubuntu1) ...
Preparing to unpack .../06-busybox-initramfs_1%3a1.30.1-7ubuntu1_arm64.deb ...
Unpacking busybox-initramfs (1:1.30.1-7ubuntu1) over (1:1.30.1-6ubuntu3) ...
Preparing to unpack .../07-ethtool_1%3a5.15-1_arm64.deb ...
Unpacking ethtool (1:5.15-1) over (1:5.9-1build1) ...
Preparing to unpack .../08-libbluetooth3_5.62-0ubuntu2_arm64.deb ...
Unpacking libbluetooth3:arm64 (5.62-0ubuntu2) over (5.62-0ubuntu1) ...
Preparing to unpack .../09-libboost-iostreams1.74.0_1.74.0-13ubuntu1_arm64.deb ...
Unpacking libboost-iostreams1.74.0:arm64 (1.74.0-13ubuntu1) over (1.74.0-8ubuntu9) ...
Preparing to unpack .../10-libmm-glib0_1.18.2-0ubuntu1_arm64.deb ...
Unpacking libmm-glib0:arm64 (1.18.2-0ubuntu1) over (1.16.6-2ubuntu1) ...
Preparing to unpack .../11-libsasl2-modules-db_2.1.27+dfsg2-2_arm64.deb ...
Unpacking libsasl2-modules-db:arm64 (2.1.27+dfsg2-2) over (2.1.27+dfsg-2.3) ...
Preparing to unpack .../12-libsasl2-2_2.1.27+dfsg2-2_arm64.deb ...
Unpacking libsasl2-2:arm64 (2.1.27+dfsg2-2) over (2.1.27+dfsg-2.3) ...
Preparing to unpack .../13-ncurses-term_6.3-1_all.deb ...
Unpacking ncurses-term (6.3-1) over (6.2+20201114-2build2) ...
Preparing to unpack .../14-python3-distutils_3.9.9-2_all.deb ...
Unpacking python3-distutils (3.9.9-2) over (3.9.8-1) ...
Preparing to unpack .../15-python3-lib2to3_3.9.9-2_all.deb ...
Unpacking python3-lib2to3 (3.9.9-2) over (3.9.8-1) ...
Preparing to unpack .../16-python3-launchpadlib_1.10.15.1-1_all.deb ...
Unpacking python3-launchpadlib (1.10.15.1-1) over (1.10.14-1) ...
Preparing to unpack .../17-software-properties-common_0.99.16_all.deb ...
Unpacking software-properties-common (0.99.16) over (0.99.15) ...
Preparing to unpack .../18-python3-software-properties_0.99.16_all.deb ...
Unpacking python3-software-properties (0.99.16) over (0.99.15) ...
Setting up automake (1:1.16.5-1.1) ...
Setting up cpp-11 (11.2.0-12ubuntu1) ...
Setting up apt-utils (2.3.12) ...
Setting up libpython3.9-minimal:arm64 (3.9.9-1) ...
Setting up libboost-iostreams1.74.0:arm64 (1.74.0-13ubuntu1) ...
Setting up python3-launchpadlib (1.10.15.1-1) ...
Setting up rsyslog (8.2110.0-3ubuntu1) ...
The user `syslog' is already a member of `adm'.
/usr/bin/which: this version of `which' is deprecated; use `command -v' in scripts instead.
/usr/bin/which: this version of `which' is deprecated; use `command -v' in scripts instead.
/usr/bin/which: this version of `which' is deprecated; use `command -v' in scripts instead.
Removing obsolete conffile /etc/init.d/rsyslog ...
Setting up binutils-common:arm64 (2.37-10ubuntu1) ...
Setting up libctf-nobfd0:arm64 (2.37-10ubuntu1) ...
Setting up python3-yaml (5.4.1-1) ...
Setting up libnftnl11:arm64 (1.2.1-1) ...
Setting up libgomp1:arm64 (11.2.0-12ubuntu1) ...
Setting up libasan6:arm64 (11.2.0-12ubuntu1) ...
Setting up libsasl2-modules-db:arm64 (2.1.27+dfsg2-2) ...
Setting up python3-software-properties (0.99.16) ...
Setting up libncurses6:arm64 (6.3-1) ...
Setting up libatomic1:arm64 (11.2.0-12ubuntu1) ...
Setting up libncursesw6:arm64 (6.3-1) ...
Setting up busybox-initramfs (1:1.30.1-7ubuntu1) ...
Setting up libsasl2-2:arm64 (2.1.27+dfsg2-2) ...
Setting up libubsan1:arm64 (11.2.0-12ubuntu1) ...
Setting up libmm-glib0:arm64 (1.18.2-0ubuntu1) ...
Setting up libhwasan0:arm64 (11.2.0-12ubuntu1) ...
Setting up libbluetooth3:arm64 (5.62-0ubuntu2) ...
Setting up keyboard-configuration (1.205ubuntu3) ...
Your console font configuration will be updated the next time your system
boots. If you want to update it now, run 'setupcon' from a virtual console.
update-initramfs: deferring update (trigger activated)
Setting up python3.9-minimal (3.9.9-1) ...
Setting up libbinutils:arm64 (2.37-10ubuntu1) ...
Setting up python3-lib2to3 (3.9.9-2) ...
Setting up libelf1:arm64 (0.186-1) ...
Setting up libcc1-0:arm64 (11.2.0-12ubuntu1) ...
Setting up liblsan0:arm64 (11.2.0-12ubuntu1) ...
Setting up libitm1:arm64 (11.2.0-12ubuntu1) ...
Setting up libpython3.9-stdlib:arm64 (3.9.9-1) ...
Setting up ethtool (1:5.15-1) ...
Setting up ncurses-term (6.3-1) ...
Setting up libtsan0:arm64 (11.2.0-12ubuntu1) ...
Setting up libctf0:arm64 (2.37-10ubuntu1) ...
Setting up python3-distutils (3.9.9-2) ...
Setting up libdw1:arm64 (0.186-1) ...
Setting up binutils-aarch64-linux-gnu (2.37-10ubuntu1) ...
Setting up binutils (2.37-10ubuntu1) ...
Setting up software-properties-common (0.99.16) ...
Setting up libpython3.9:arm64 (3.9.9-1) ...
Setting up libgcc-11-dev:arm64 (11.2.0-12ubuntu1) ...
Setting up gcc-11 (11.2.0-12ubuntu1) ...
Setting up console-setup-linux (1.205ubuntu3) ...
Setting up python3.9 (3.9.9-1) ...
Setting up console-setup (1.205ubuntu3) ...
update-initramfs: deferring update (trigger activated)
Setting up libstdc++-11-dev:arm64 (11.2.0-12ubuntu1) ...
Setting up g++-11 (11.2.0-12ubuntu1) ...
Processing triggers for man-db (2.9.4-2build1) ...
Processing triggers for dbus (1.12.20-2ubuntu2) ...
Processing triggers for libc-bin (2.34-0ubuntu3) ...
Processing triggers for initramfs-tools (0.140ubuntu8) ...
update-initramfs: Generating /boot/initrd.img-5.10.81-meson64
update-initramfs: Converting to u-boot format
odroidhc4:igorp:#

sudo apt install zfs-dkms zfsutils-linux

odroidhc4:~:% sudo apt install zfs-dkms
[sudo] password for igorp: 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Suggested packages:
  debhelper
Recommended packages:
  zfs-zed zfsutils-linux
The following NEW packages will be installed:
  zfs-dkms
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 2,282 kB of archives.
After this operation, 17.8 MB of additional disk space will be used.
Get:1 http://apt.armbian.com jammy/jammy-utils arm64 zfs-dkms all 2.1.1-0york0~21.04 [2,282 kB]
Fetched 2,282 kB in 1s (1,847 kB/s)
Preconfiguring packages ...
Selecting previously unselected package zfs-dkms.
(Reading database ... 67248 files and directories currently installed.)
Preparing to unpack .../zfs-dkms_2.1.1-0york0~21.04_all.deb ...
Unpacking zfs-dkms (2.1.1-0york0~21.04) ...
Setting up zfs-dkms (2.1.1-0york0~21.04) ...
Loading new zfs-2.1.1 DKMS files...
Building for 5.10.81-meson64
Building initial module for 5.10.81-meson64
Done.

zavl.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.10.81-meson64/updates/dkms/

znvpair.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.10.81-meson64/updates/dkms/

zunicode.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.10.81-meson64/updates/dkms/

zcommon.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.10.81-meson64/updates/dkms/

zfs.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.10.81-meson64/updates/dkms/

icp.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.10.81-meson64/updates/dkms/

zlua.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.10.81-meson64/updates/dkms/

spl.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.10.81-meson64/updates/dkms/

zzstd.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.10.81-meson64/updates/dkms/

depmod......
Processing triggers for initramfs-tools (0.140ubuntu8) ...
update-initramfs: Generating /boot/initrd.img-5.10.81-meson64
update-initramfs: Converting to u-boot format

odroidhc4:~:% modinfo zfs
filename:       /lib/modules/5.10.81-meson64/updates/dkms/zfs.ko
version:        2.1.1-0york0~21.04
license:        CDDL
author:         OpenZFS
description:    ZFS
alias:          devname:zfs
alias:          char-major-10-249
srcversion:     01ED8BF0BDE5F9A75644B3B
depends:        spl,znvpair,icp,zlua,zzstd,zunicode,zcommon,zavl
name:           zfs
vermagic:       5.10.81-meson64 SMP preempt mod_unload aarch64
parm:           zvol_inhibit_dev:Do not create zvol device nodes (uint)
parm:           zvol_major:Major number for zvol device (uint)
parm:           zvol_threads:Max number of threads to handle I/O requests (uint)
parm:           zvol_request_sync:Synchronously handle bio requests (uint)
parm:           zvol_max_discard_blocks:Max number of blocks to discard (ulong)
parm:           zvol_prefetch_bytes:Prefetch N bytes at zvol start+end (uint)
parm:           zvol_volmode:Default volmode property value (uint)
parm:           zfs_fallocate_reserve_percent:Percentage of length to use for the available capacity check (uint)
parm:           zfs_key_max_salt_uses:Max number of times a salt value can be used for generating encryption keys before it is rotated (ulong)
parm:           zfs_object_mutex_size:Size of znode hold array (uint)
parm:           zfs_unlink_suspend_progress:Set to prevent async unlinks (debug - leaks space into the unlinked set) (int)
parm:           zfs_delete_blocks:Delete files larger than N blocks async (ulong)
parm:           zfs_dbgmsg_enable:Enable ZFS debug message log (int)
parm:           zfs_dbgmsg_maxsize:Maximum ZFS debug log size (int)
parm:           zfs_admin_snapshot:Enable mkdir/rmdir/mv in .zfs/snapshot (int)
parm:           zfs_expire_snapshot:Seconds to expire .zfs/snapshot (int)
parm:           vdev_file_logical_ashift:Logical ashift for file-based devices (ulong)
parm:           vdev_file_physical_ashift:Physical ashift for file-based devices (ulong)
parm:           zfs_vdev_scheduler:I/O scheduler
parm:           zfs_arc_shrinker_limit:Limit on number of pages that ARC shrinker can reclaim at once (int)
parm:           zfs_abd_scatter_enabled:Toggle whether ABD allocations must be linear. (int)
parm:           zfs_abd_scatter_min_size:Minimum size of scatter allocations. (int)
parm:           zfs_abd_scatter_max_order:Maximum order allocation used for a scatter ABD. (uint)
parm:           zio_slow_io_ms:Max I/O completion time (milliseconds) before marking it as slow (int)
parm:           zio_requeue_io_start_cut_in_line:Prioritize requeued I/O (int)
parm:           zfs_sync_pass_deferred_free:Defer frees starting in this pass (int)
parm:           zfs_sync_pass_dont_compress:Don't compress starting in this pass (int)
parm:           zfs_sync_pass_rewrite:Rewrite new bps starting in this pass (int)
parm:           zio_dva_throttle_enabled:Throttle block allocations in the ZIO pipeline (int)
parm:           zio_deadman_log_all:Log all slow ZIOs, not just those with vdevs (int)
parm:           zfs_commit_timeout_pct:ZIL block open timeout percentage (int)
parm:           zil_replay_disable:Disable intent logging replay (int)
parm:           zil_nocacheflush:Disable ZIL cache flushes (int)
parm:           zil_slog_bulk:Limit in bytes slog sync writes per commit (ulong)
parm:           zil_maxblocksize:Limit in bytes of ZIL log block size (int)
parm:           zfs_vnops_read_chunk_size:Bytes to read per chunk (ulong)
parm:           zfs_immediate_write_sz:Largest data block to write to zil (long)
parm:           zfs_max_nvlist_src_size:Maximum size in bytes allowed for src nvlist passed with ZFS ioctls (ulong)
parm:           zfs_history_output_max:Maximum size in bytes of ZFS ioctl output that will be logged (ulong)
parm:           zfs_zevent_retain_max:Maximum recent zevents records to retain for duplicate checking (uint)
parm:           zfs_zevent_retain_expire_secs:Expiration time for recent zevents records (uint)
parm:           zfs_lua_max_instrlimit:Max instruction limit that can be specified for a channel program (ulong)
parm:           zfs_lua_max_memlimit:Max memory limit that can be specified for a channel program (ulong)
parm:           zap_iterate_prefetch:When iterating ZAP object, prefetch it (int)
parm:           zfs_trim_extent_bytes_max:Max size of TRIM commands, larger will be split (uint)
parm:           zfs_trim_extent_bytes_min:Min size of TRIM commands, smaller will be skipped (uint)
parm:           zfs_trim_metaslab_skip:Skip metaslabs which have never been initialized (uint)
parm:           zfs_trim_txg_batch:Min number of txgs to aggregate frees before issuing TRIM (uint)
parm:           zfs_trim_queue_limit:Max queued TRIMs outstanding per leaf vdev (uint)
parm:           zfs_removal_ignore_errors:Ignore hard IO errors when removing device (int)
parm:           zfs_remove_max_segment:Largest contiguous segment to allocate when removing device (int)
parm:           vdev_removal_max_span:Largest span of free chunks a remap segment can span (int)
parm:           zfs_removal_suspend_progress:Pause device removal after this many bytes are copied (debug use only - causes removal to hang) (int)
parm:           zfs_rebuild_max_segment:Max segment size in bytes of rebuild reads (ulong)
parm:           zfs_rebuild_vdev_limit:Max bytes in flight per leaf vdev for sequential resilvers (ulong)
parm:           zfs_rebuild_scrub_enabled:Automatically scrub after sequential resilver completes (int)
parm:           zfs_vdev_raidz_impl:Select raidz implementation.
parm:           zfs_vdev_aggregation_limit:Max vdev I/O aggregation size (int)
parm:           zfs_vdev_aggregation_limit_non_rotating:Max vdev I/O aggregation size for non-rotating media (int)
parm:           zfs_vdev_aggregate_trim:Allow TRIM I/O to be aggregated (int)
parm:           zfs_vdev_read_gap_limit:Aggregate read I/O over gap (int)
parm:           zfs_vdev_write_gap_limit:Aggregate write I/O over gap (int)
parm:           zfs_vdev_max_active:Maximum number of active I/Os per vdev (int)
parm:           zfs_vdev_async_write_active_max_dirty_percent:Async write concurrency max threshold (int)
parm:           zfs_vdev_async_write_active_min_dirty_percent:Async write concurrency min threshold (int)
parm:           zfs_vdev_async_read_max_active:Max active async read I/Os per vdev (int)
parm:           zfs_vdev_async_read_min_active:Min active async read I/Os per vdev (int)
parm:           zfs_vdev_async_write_max_active:Max active async write I/Os per vdev (int)
parm:           zfs_vdev_async_write_min_active:Min active async write I/Os per vdev (int)
parm:           zfs_vdev_initializing_max_active:Max active initializing I/Os per vdev (int)
parm:           zfs_vdev_initializing_min_active:Min active initializing I/Os per vdev (int)
parm:           zfs_vdev_removal_max_active:Max active removal I/Os per vdev (int)
parm:           zfs_vdev_removal_min_active:Min active removal I/Os per vdev (int)
parm:           zfs_vdev_scrub_max_active:Max active scrub I/Os per vdev (int)
parm:           zfs_vdev_scrub_min_active:Min active scrub I/Os per vdev (int)
parm:           zfs_vdev_sync_read_max_active:Max active sync read I/Os per vdev (int)
parm:           zfs_vdev_sync_read_min_active:Min active sync read I/Os per vdev (int)
parm:           zfs_vdev_sync_write_max_active:Max active sync write I/Os per vdev (int)
parm:           zfs_vdev_sync_write_min_active:Min active sync write I/Os per vdev (int)
parm:           zfs_vdev_trim_max_active:Max active trim/discard I/Os per vdev (int)
parm:           zfs_vdev_trim_min_active:Min active trim/discard I/Os per vdev (int)
parm:           zfs_vdev_rebuild_max_active:Max active rebuild I/Os per vdev (int)
parm:           zfs_vdev_rebuild_min_active:Min active rebuild I/Os per vdev (int)
parm:           zfs_vdev_nia_credit:Number of non-interactive I/Os to allow in sequence (int)
parm:           zfs_vdev_nia_delay:Number of non-interactive I/Os before _max_active (int)
parm:           zfs_vdev_queue_depth_pct:Queue depth percentage for each top-level vdev (int)
parm:           zfs_vdev_mirror_rotating_inc:Rotating media load increment for non-seeking I/O's (int)
parm:           zfs_vdev_mirror_rotating_seek_inc:Rotating media load increment for seeking I/O's (int)
parm:           zfs_vdev_mirror_rotating_seek_offset:Offset in bytes from the last I/O which triggers a reduced rotating media seek increment (int)
parm:           zfs_vdev_mirror_non_rotating_inc:Non-rotating media load increment for non-seeking I/O's (int)
parm:           zfs_vdev_mirror_non_rotating_seek_inc:Non-rotating media load increment for seeking I/O's (int)
parm:           zfs_initialize_value:Value written during zpool initialize (ulong)
parm:           zfs_initialize_chunk_size:Size in bytes of writes by zpool initialize (ulong)
parm:           zfs_condense_indirect_vdevs_enable:Whether to attempt condensing indirect vdev mappings (int)
parm:           zfs_condense_indirect_obsolete_pct:Minimum obsolete percent of bytes in the mapping to attempt condensing (int)
parm:           zfs_condense_min_mapping_bytes:Don't bother condensing if the mapping uses less than this amount of memory (ulong)
parm:           zfs_condense_max_obsolete_bytes:Minimum size obsolete spacemap to attempt condensing (ulong)
parm:           zfs_condense_indirect_commit_entry_delay_ms:Used by tests to ensure certain actions happen in the middle of a condense. A maximum value of 1 should be sufficient. (int)
parm:           zfs_reconstruct_indirect_combinations_max:Maximum number of combinations when reconstructing split segments (int)
parm:           zfs_vdev_cache_max:Inflate reads small than max (int)
parm:           zfs_vdev_cache_size:Total size of the per-disk cache (int)
parm:           zfs_vdev_cache_bshift:Shift size to inflate reads too (int)
parm:           zfs_vdev_default_ms_count:Target number of metaslabs per top-level vdev (int)
parm:           zfs_vdev_default_ms_shift:Default limit for metaslab size (int)
parm:           zfs_vdev_min_ms_count:Minimum number of metaslabs per top-level vdev (int)
parm:           zfs_vdev_ms_count_limit:Practical upper limit of total metaslabs per top-level vdev (int)
parm:           zfs_slow_io_events_per_second:Rate limit slow IO (delay) events to this many per second (uint)
parm:           zfs_checksum_events_per_second:Rate limit checksum events to this many checksum errors per second (do not set below zed threshold). (uint)
parm:           zfs_scan_ignore_errors:Ignore errors during resilver/scrub (int)
parm:           vdev_validate_skip:Bypass vdev_validate() (int)
parm:           zfs_nocacheflush:Disable cache flushes (int)
parm:           zfs_embedded_slog_min_ms:Minimum number of metaslabs required to dedicate one for log blocks (int)
parm:           zfs_vdev_min_auto_ashift:Minimum ashift used when creating new top-level vdevs
parm:           zfs_vdev_max_auto_ashift:Maximum ashift used when optimizing for logical -> physical sector size on new top-level vdevs
parm:           zfs_txg_timeout:Max seconds worth of delta per txg (int)
parm:           zfs_read_history:Historical statistics for the last N reads (int)
parm:           zfs_read_history_hits:Include cache hits in read history (int)
parm:           zfs_txg_history:Historical statistics for the last N txgs (int)
parm:           zfs_multihost_history:Historical statistics for last N multihost writes (int)
parm:           zfs_flags:Set additional debugging flags (uint)
parm:           zfs_recover:Set to attempt to recover from fatal errors (int)
parm:           zfs_free_leak_on_eio:Set to ignore IO errors during free and permanently leak the space (int)
parm:           zfs_deadman_checktime_ms:Dead I/O check interval in milliseconds (ulong)
parm:           zfs_deadman_enabled:Enable deadman timer (int)
parm:           spa_asize_inflation:SPA size estimate multiplication factor (int)
parm:           zfs_ddt_data_is_special:Place DDT data into the special class (int)
parm:           zfs_user_indirect_is_special:Place user data indirect blocks into the special class (int)
parm:           zfs_deadman_failmode:Failmode for deadman timer
parm:           zfs_deadman_synctime_ms:Pool sync expiration time in milliseconds
parm:           zfs_deadman_ziotime_ms:IO expiration time in milliseconds
parm:           zfs_special_class_metadata_reserve_pct:Small file blocks in special vdevs depends on this much free space available (int)
parm:           spa_slop_shift:Reserved free space in pool
parm:           zfs_unflushed_max_mem_amt:Specific hard-limit in memory that ZFS allows to be used for unflushed changes (ulong)
parm:           zfs_unflushed_max_mem_ppm:Percentage of the overall system memory that ZFS allows to be used for unflushed changes (value is calculated over 1000000 for finer granularity) (ulong)
parm:           zfs_unflushed_log_block_max:Hard limit (upper-bound) in the size of the space map log in terms of blocks. (ulong)
parm:           zfs_unflushed_log_block_min:Lower-bound limit for the maximum amount of blocks allowed in log spacemap (see zfs_unflushed_log_block_max) (ulong)
parm:           zfs_unflushed_log_block_pct:Tunable used to determine the number of blocks that can be used for the spacemap log, expressed as a percentage of the total number of metaslabs in the pool (e.g. 400 means the number of log blocks is capped at 4 times the number of metaslabs) (ulong)
parm:           zfs_max_log_walking:The number of past TXGs that the flushing algorithm of the log spacemap feature uses to estimate incoming log blocks (ulong)
parm:           zfs_max_logsm_summary_length:Maximum number of rows allowed in the summary of the spacemap log (ulong)
parm:           zfs_min_metaslabs_to_flush:Minimum number of metaslabs to flush per dirty TXG (ulong)
parm:           zfs_keep_log_spacemaps_at_export:Prevent the log spacemaps from being flushed and destroyed during pool export/destroy (int)
parm:           spa_config_path:SPA config file (/etc/zfs/zpool.cache) (charp)
parm:           zfs_autoimport_disable:Disable pool import at module load (int)
parm:           zfs_spa_discard_memory_limit:Limit for memory used in prefetching the checkpoint space map done on each vdev while discarding the checkpoint (ulong)
parm:           spa_load_verify_shift:log2 fraction of arc that can be used by inflight I/Os when verifying pool during import (int)
parm:           spa_load_verify_metadata:Set to traverse metadata on pool import (int)
parm:           spa_load_verify_data:Set to traverse data on pool import (int)
parm:           spa_load_print_vdev_tree:Print vdev tree to zfs_dbgmsg during pool import (int)
parm:           zio_taskq_batch_pct:Percentage of CPUs to run an IO worker thread (uint)
parm:           zio_taskq_batch_tpq:Number of threads per IO worker taskqueue (uint)
parm:           zfs_max_missing_tvds:Allow importing pool with up to this number of missing top-level vdevs (in read-only mode) (ulong)
parm:           zfs_livelist_condense_zthr_pause:Set the livelist condense zthr to pause (int)
parm:           zfs_livelist_condense_sync_pause:Set the livelist condense synctask to pause (int)
parm:           zfs_livelist_condense_sync_cancel:Whether livelist condensing was canceled in the synctask (int)
parm:           zfs_livelist_condense_zthr_cancel:Whether livelist condensing was canceled in the zthr function (int)
parm:           zfs_livelist_condense_new_alloc:Whether extra ALLOC blkptrs were added to a livelist entry while it was being condensed (int)
parm:           zfs_multilist_num_sublists:Number of sublists used in each multilist (int)
parm:           zfs_multihost_interval:Milliseconds between mmp writes to each leaf
parm:           zfs_multihost_fail_intervals:Max allowed period without a successful mmp write (uint)
parm:           zfs_multihost_import_intervals:Number of zfs_multihost_interval periods to wait for activity (uint)
parm:           metaslab_aliquot:Allocation granularity (a.k.a. stripe size) (ulong)
parm:           metaslab_debug_load:Load all metaslabs when pool is first opened (int)
parm:           metaslab_debug_unload:Prevent metaslabs from being unloaded (int)
parm:           metaslab_preload_enabled:Preload potential metaslabs during reassessment (int)
parm:           metaslab_unload_delay:Delay in txgs after metaslab was last used before unloading (int)
parm:           metaslab_unload_delay_ms:Delay in milliseconds after metaslab was last used before unloading (int)
parm:           zfs_mg_noalloc_threshold:Percentage of metaslab group size that should be free to make it eligible for allocation (int)
parm:           zfs_mg_fragmentation_threshold:Percentage of metaslab group size that should be considered eligible for allocations unless all metaslab groups within the metaslab class have also crossed this threshold (int)
parm:           zfs_metaslab_fragmentation_threshold:Fragmentation for metaslab to allow allocation (int)
parm:           metaslab_fragmentation_factor_enabled:Use the fragmentation metric to prefer less fragmented metaslabs (int)
parm:           metaslab_lba_weighting_enabled:Prefer metaslabs with lower LBAs (int)
parm:           metaslab_bias_enabled:Enable metaslab group biasing (int)
parm:           zfs_metaslab_segment_weight_enabled:Enable segment-based metaslab selection (int)
parm:           zfs_metaslab_switch_threshold:Segment-based metaslab selection maximum buckets before switching (int)
parm:           metaslab_force_ganging:Blocks larger than this size are forced to be gang blocks (ulong)
parm:           metaslab_df_max_search:Max distance (bytes) to search forward before using size tree (int)
parm:           metaslab_df_use_largest_segment:When looking in size tree, use largest segment instead of exact fit (int)
parm:           zfs_metaslab_max_size_cache_sec:How long to trust the cached max chunk size of a metaslab (ulong)
parm:           zfs_metaslab_mem_limit:Percentage of memory that can be used to store metaslab range trees (int)
parm:           zfs_metaslab_try_hard_before_gang:Try hard to allocate before ganging (int)
parm:           zfs_metaslab_find_max_tries:Normally only consider this many of the best metaslabs in each vdev (int)
parm:           zfs_zevent_len_max:Max event queue length (int)
parm:           zfs_scan_vdev_limit:Max bytes in flight per leaf vdev for scrubs and resilvers (ulong)
parm:           zfs_scrub_min_time_ms:Min millisecs to scrub per txg (int)
parm:           zfs_obsolete_min_time_ms:Min millisecs to obsolete per txg (int)
parm:           zfs_free_min_time_ms:Min millisecs to free per txg (int)
parm:           zfs_resilver_min_time_ms:Min millisecs to resilver per txg (int)
parm:           zfs_scan_suspend_progress:Set to prevent scans from progressing (int)
parm:           zfs_no_scrub_io:Set to disable scrub I/O (int)
parm:           zfs_no_scrub_prefetch:Set to disable scrub prefetching (int)
parm:           zfs_async_block_max_blocks:Max number of blocks freed in one txg (ulong)
parm:           zfs_max_async_dedup_frees:Max number of dedup blocks freed in one txg (ulong)
parm:           zfs_free_bpobj_enabled:Enable processing of the free_bpobj (int)
parm:           zfs_scan_mem_lim_fact:Fraction of RAM for scan hard limit (int)
parm:           zfs_scan_issue_strategy:IO issuing strategy during scrubbing. 0 = default, 1 = LBA, 2 = size (int)
parm:           zfs_scan_legacy:Scrub using legacy non-sequential method (int)
parm:           zfs_scan_checkpoint_intval:Scan progress on-disk checkpointing interval (int)
parm:           zfs_scan_max_ext_gap:Max gap in bytes between sequential scrub / resilver I/Os (ulong)
parm:           zfs_scan_mem_lim_soft_fact:Fraction of hard limit used as soft limit (int)
parm:           zfs_scan_strict_mem_lim:Tunable to attempt to reduce lock contention (int)
parm:           zfs_scan_fill_weight:Tunable to adjust bias towards more filled segments during scans (int)
parm:           zfs_resilver_disable_defer:Process all resilvers immediately (int)
parm:           zfs_dirty_data_max_percent:Max percent of RAM allowed to be dirty (int)
parm:           zfs_dirty_data_max_max_percent:zfs_dirty_data_max upper bound as % of RAM (int)
parm:           zfs_delay_min_dirty_percent:Transaction delay threshold (int)
parm:           zfs_dirty_data_max:Determines the dirty space limit (ulong)
parm:           zfs_dirty_data_max_max:zfs_dirty_data_max upper bound in bytes (ulong)
parm:           zfs_dirty_data_sync_percent:Dirty data txg sync threshold as a percentage of zfs_dirty_data_max (int)
parm:           zfs_delay_scale:How quickly delay approaches infinity (ulong)
parm:           zfs_sync_taskq_batch_pct:Max percent of CPUs that are used to sync dirty data (int)
parm:           zfs_zil_clean_taskq_nthr_pct:Max percent of CPUs that are used per dp_sync_taskq (int)
parm:           zfs_zil_clean_taskq_minalloc:Number of taskq entries that are pre-populated (int)
parm:           zfs_zil_clean_taskq_maxalloc:Max number of taskq entries that are cached (int)
parm:           zfs_livelist_max_entries:Size to start the next sub-livelist in a livelist (ulong)
parm:           zfs_livelist_min_percent_shared:Threshold at which livelist is disabled (int)
parm:           zfs_max_recordsize:Max allowed record size (int)
parm:           zfs_allow_redacted_dataset_mount:Allow mounting of redacted datasets (int)
parm:           zfs_disable_ivset_guid_check:Set to allow raw receives without IVset guids (int)
parm:           zfs_prefetch_disable:Disable all ZFS prefetching (int)
parm:           zfetch_max_streams:Max number of streams per zfetch (uint)
parm:           zfetch_min_sec_reap:Min time before stream reclaim (uint)
parm:           zfetch_max_distance:Max bytes to prefetch per stream (uint)
parm:           zfetch_max_idistance:Max bytes to prefetch indirects for per stream (uint)
parm:           zfetch_array_rd_sz:Number of bytes in a array_read (ulong)
parm:           zfs_pd_bytes_max:Max number of bytes to prefetch (int)
parm:           zfs_traverse_indirect_prefetch_limit:Traverse prefetch number of blocks pointed by indirect block (int)
parm:           ignore_hole_birth:Alias for send_holes_without_birth_time (int)
parm:           send_holes_without_birth_time:Ignore hole_birth txg for zfs send (int)
parm:           zfs_send_corrupt_data:Allow sending corrupt data (int)
parm:           zfs_send_queue_length:Maximum send queue length (int)
parm:           zfs_send_unmodified_spill_blocks:Send unmodified spill blocks (int)
parm:           zfs_send_no_prefetch_queue_length:Maximum send queue length for non-prefetch queues (int)
parm:           zfs_send_queue_ff:Send queue fill fraction (int)
parm:           zfs_send_no_prefetch_queue_ff:Send queue fill fraction for non-prefetch queues (int)
parm:           zfs_override_estimate_recordsize:Override block size estimate with fixed size (int)
parm:           zfs_recv_queue_length:Maximum receive queue length (int)
parm:           zfs_recv_queue_ff:Receive queue fill fraction (int)
parm:           zfs_recv_write_batch_size:Maximum amount of writes to batch into one transaction (int)
parm:           dmu_object_alloc_chunk_shift:CPU-specific allocator grabs 2^N objects at once (int)
parm:           zfs_nopwrite_enabled:Enable NOP writes (int)
parm:           zfs_per_txg_dirty_frees_percent:Percentage of dirtied blocks from frees in one TXG (ulong)
parm:           zfs_dmu_offset_next_sync:Enable forcing txg sync to find holes (int)
parm:           dmu_prefetch_max:Limit one prefetch call to this size (int)
parm:           zfs_dedup_prefetch:Enable prefetching dedup-ed blks (int)
parm:           zfs_dbuf_state_index:Calculate arc header index (int)
parm:           dbuf_cache_max_bytes:Maximum size in bytes of the dbuf cache. (ulong)
parm:           dbuf_cache_hiwater_pct:Percentage over dbuf_cache_max_bytes when dbufs must be evicted directly. (uint)
parm:           dbuf_cache_lowater_pct:Percentage below dbuf_cache_max_bytes when the evict thread stops evicting dbufs. (uint)
parm:           dbuf_metadata_cache_max_bytes:Maximum size in bytes of the dbuf metadata cache. (ulong)
parm:           dbuf_cache_shift:Set the size of the dbuf cache to a log2 fraction of arc size. (int)
parm:           dbuf_metadata_cache_shift:Set the size of the dbuf metadata cache to a log2 fraction of arc size. (int)
parm:           zfs_arc_min:Min arc size
parm:           zfs_arc_max:Max arc size
parm:           zfs_arc_meta_limit:Metadata limit for arc size
parm:           zfs_arc_meta_limit_percent:Percent of arc size for arc meta limit
parm:           zfs_arc_meta_min:Min arc metadata
parm:           zfs_arc_meta_prune:Meta objects to scan for prune (int)
parm:           zfs_arc_meta_adjust_restarts:Limit number of restarts in arc_evict_meta (int)
parm:           zfs_arc_meta_strategy:Meta reclaim strategy (int)
parm:           zfs_arc_grow_retry:Seconds before growing arc size
parm:           zfs_arc_p_dampener_disable:Disable arc_p adapt dampener (int)
parm:           zfs_arc_shrink_shift:log2(fraction of arc to reclaim)
parm:           zfs_arc_pc_percent:Percent of pagecache to reclaim arc to (uint)
parm:           zfs_arc_p_min_shift:arc_c shift to calc min/max arc_p
parm:           zfs_arc_average_blocksize:Target average block size (int)
parm:           zfs_compressed_arc_enabled:Disable compressed arc buffers (int)
parm:           zfs_arc_min_prefetch_ms:Min life of prefetch block in ms
parm:           zfs_arc_min_prescient_prefetch_ms:Min life of prescient prefetched block in ms
parm:           l2arc_write_max:Max write bytes per interval (ulong)
parm:           l2arc_write_boost:Extra write bytes during device warmup (ulong)
parm:           l2arc_headroom:Number of max device writes to precache (ulong)
parm:           l2arc_headroom_boost:Compressed l2arc_headroom multiplier (ulong)
parm:           l2arc_trim_ahead:TRIM ahead L2ARC write size multiplier (ulong)
parm:           l2arc_feed_secs:Seconds between L2ARC writing (ulong)
parm:           l2arc_feed_min_ms:Min feed interval in milliseconds (ulong)
parm:           l2arc_noprefetch:Skip caching prefetched buffers (int)
parm:           l2arc_feed_again:Turbo L2ARC warmup (int)
parm:           l2arc_norw:No reads during writes (int)
parm:           l2arc_meta_percent:Percent of ARC size allowed for L2ARC-only headers (int)
parm:           l2arc_rebuild_enabled:Rebuild the L2ARC when importing a pool (int)
parm:           l2arc_rebuild_blocks_min_l2size:Min size in bytes to write rebuild log blocks in L2ARC (ulong)
parm:           l2arc_mfuonly:Cache only MFU data from ARC into L2ARC (int)
parm:           zfs_arc_lotsfree_percent:System free memory I/O throttle in bytes
parm:           zfs_arc_sys_free:System free memory target size in bytes
parm:           zfs_arc_dnode_limit:Minimum bytes of dnodes in arc
parm:           zfs_arc_dnode_limit_percent:Percent of ARC meta buffers for dnodes
parm:           zfs_arc_dnode_reduce_percent:Percentage of excess dnodes to try to unpin (ulong)
parm:           zfs_arc_eviction_pct:When full, ARC allocation waits for eviction of this % of alloc size (int)
parm:           zfs_arc_evict_batch_limit:The number of headers to evict per sublist before moving to the next (int)





odroidhc4:igorp:# apt install zfsutils-linux
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  libnvpair3linux libuutil3linux libzfs4linux libzpool5linux
Suggested packages:
  nfs-kernel-server samba-common-bin zfs-initramfs | zfs-dracut
Recommended packages:
  zfs-zed
The following NEW packages will be installed:
  libnvpair3linux libuutil3linux libzfs4linux libzpool5linux zfsutils-linux
0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,931 kB of archives.
After this operation, 6,091 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://apt.armbian.com jammy/jammy-utils arm64 libnvpair3linux arm64 2.1.1-0york0~21.04 [60.3 kB]
Get:2 http://apt.armbian.com jammy/jammy-utils arm64 libuutil3linux arm64 2.1.1-0york0~21.04 [55.4 kB]
Get:3 http://apt.armbian.com jammy/jammy-utils arm64 libzfs4linux arm64 2.1.1-0york0~21.04 [218 kB]                      
Get:4 http://apt.armbian.com jammy/jammy-utils arm64 libzpool5linux arm64 2.1.1-0york0~21.04 [1,110 kB]
Get:5 http://apt.armbian.com jammy/jammy-utils arm64 zfsutils-linux arm64 2.1.1-0york0~21.04 [486 kB]
Fetched 1,931 kB in 1s (1,391 kB/s)                         
Selecting previously unselected package libnvpair3linux.
(Reading database ... 69123 files and directories currently installed.)
Preparing to unpack .../libnvpair3linux_2.1.1-0york0~21.04_arm64.deb ...
Unpacking libnvpair3linux (2.1.1-0york0~21.04) ...
Selecting previously unselected package libuutil3linux.
Preparing to unpack .../libuutil3linux_2.1.1-0york0~21.04_arm64.deb ...
Unpacking libuutil3linux (2.1.1-0york0~21.04) ...
Selecting previously unselected package libzfs4linux.
Preparing to unpack .../libzfs4linux_2.1.1-0york0~21.04_arm64.deb ...
Unpacking libzfs4linux (2.1.1-0york0~21.04) ...
Selecting previously unselected package libzpool5linux.
Preparing to unpack .../libzpool5linux_2.1.1-0york0~21.04_arm64.deb ...
Unpacking libzpool5linux (2.1.1-0york0~21.04) ...
Selecting previously unselected package zfsutils-linux.
Preparing to unpack .../zfsutils-linux_2.1.1-0york0~21.04_arm64.deb ...
Unpacking zfsutils-linux (2.1.1-0york0~21.04) ...
Setting up libnvpair3linux (2.1.1-0york0~21.04) ...
Setting up libuutil3linux (2.1.1-0york0~21.04) ...
Setting up libzfs4linux (2.1.1-0york0~21.04) ...
Setting up libzpool5linux (2.1.1-0york0~21.04) ...
Setting up zfsutils-linux (2.1.1-0york0~21.04) ...
insmod /lib/modules/5.10.81-meson64/updates/dkms/spl.ko 
insmod /lib/modules/5.10.81-meson64/updates/dkms/icp.ko 
insmod /lib/modules/5.10.81-meson64/updates/dkms/zavl.ko 
insmod /lib/modules/5.10.81-meson64/updates/dkms/znvpair.ko 
insmod /lib/modules/5.10.81-meson64/updates/dkms/zcommon.ko 
insmod /lib/modules/5.10.81-meson64/updates/dkms/zlua.ko 
insmod /lib/modules/5.10.81-meson64/updates/dkms/zzstd.ko 
insmod /lib/modules/5.10.81-meson64/updates/dkms/zunicode.ko 
insmod /lib/modules/5.10.81-meson64/updates/dkms/zfs.ko 
Created symlink /etc/systemd/system/zfs-import.target.wants/zfs-import-cache.service → /lib/systemd/system/zfs-import-cache.service.
Created symlink /etc/systemd/system/zfs.target.wants/zfs-import.target → /lib/systemd/system/zfs-import.target.
Created symlink /etc/systemd/system/zfs-mount.service.wants/zfs-load-module.service → /lib/systemd/system/zfs-load-module.service.
Created symlink /etc/systemd/system/zfs.target.wants/zfs-load-module.service → /lib/systemd/system/zfs-load-module.service.
Created symlink /etc/systemd/system/zfs.target.wants/zfs-mount.service → /lib/systemd/system/zfs-mount.service.
Created symlink /etc/systemd/system/zfs.target.wants/zfs-share.service → /lib/systemd/system/zfs-share.service.
Created symlink /etc/systemd/system/zfs-volumes.target.wants/zfs-volume-wait.service → /lib/systemd/system/zfs-volume-wait.service.
Created symlink /etc/systemd/system/zfs.target.wants/zfs-volumes.target → /lib/systemd/system/zfs-volumes.target.
Created symlink /etc/systemd/system/multi-user.target.wants/zfs.target → /lib/systemd/system/zfs.target.
zfs-import-scan.service is a disabled or a static unit, not starting it.
zfs-import-scan.service is a disabled or a static unit, not starting it.
Processing triggers for man-db (2.9.4-2build1) ...
Processing triggers for libc-bin (2.34-0ubuntu3) ...

Checking for ZFS pool status after drive pool import:
 

odroidhc4:~:% zpool status           
  pool: pool
 state: ONLINE
config:

	NAME        STATE     READ WRITE CKSUM
	pool        ONLINE       0     0     0
	  sda1      ONLINE       0     0     0
	  sda2      ONLINE       0     0     0
	  sda3      ONLINE       0     0     0

errors: No known data errors

odroidhc4:~:% df
Filesystem     1K-blocks    Used Available Use% Mounted on
tmpfs             390776    5908    384868   2% /run
/dev/mmcblk0p1  30371612 1616872  28407488   6% /
tmpfs            1953872       0   1953872   0% /dev/shm
tmpfs               5120       4      5116   1% /run/lock
tmpfs            1953872       0   1953872   0% /tmp
/dev/zram1         47960    2056     42320   5% /var/log
tmpfs             390772       0    390772   0% /run/user/1000
pool            27934208  524416  27409792   2% /pool

Enable LCD:

odroidhc4:~:% git clone https://github.com/rpardini/sys-oled-hc4.git
Cloning into 'sys-oled-hc4'...
remote: Enumerating objects: 99, done.
remote: Counting objects: 100% (2/2), done.
remote: Total 99 (delta 1), reused 1 (delta 1), pack-reused 97
Receiving objects: 100% (99/99), 54.83 KiB | 1.61 MiB/s, done.
Resolving deltas: 100% (33/33), done.
odroidhc4:~:% cd sys-oled-hc4
odroidhc4:sys-oled-hc4:% sudo ./install.sh                                                                                 <master>
Installing Dependencies
Hit:1 http://ports.ubuntu.com jammy InRelease
Hit:2 http://ports.ubuntu.com jammy-security InRelease
Hit:3 http://ports.ubuntu.com jammy-updates InRelease
Hit:4 http://ports.ubuntu.com jammy-backports InRelease
Hit:5 http://armbian.16z.eu/apt jammy InRelease   
Reading package lists... Done
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
build-essential is already the newest version (12.9ubuntu2).
The following additional packages will be installed:
  libbrotli-dev libexpat1-dev libfreetype-dev libfreetype6 libjpeg-turbo8 libjpeg-turbo8-dev libjpeg8 libjpeg8-dev libjs-jquery
  libjs-sphinxdoc libjs-underscore libpng-dev libpython3-dev libpython3.9-dev python-pip-whl python3.9-dev zlib1g-dev
Suggested packages:
  freetype2-doc python-psutil-doc python-setuptools-doc
Recommended packages:
  javascript-common libpng-tools
The following NEW packages will be installed:
  libbrotli-dev libexpat1-dev libfreetype-dev libfreetype6 libfreetype6-dev libjpeg-dev libjpeg-turbo8 libjpeg-turbo8-dev libjpeg8
  libjpeg8-dev libjs-jquery libjs-sphinxdoc libjs-underscore libpng-dev libpython3-dev libpython3.9-dev python-pip-whl python3-dev
  python3-pip python3-psutil python3-setuptools python3-wheel python3.9-dev zlib1g-dev
0 upgraded, 24 newly installed, 0 to remove and 0 not upgraded.
Need to get 10.7 MB of archives.
After this operation, 34.7 MB of additional disk space will be used.
Get:1 http://ports.ubuntu.com jammy/main arm64 libbrotli-dev arm64 1.0.9-2build4 [336 kB]
Get:2 http://ports.ubuntu.com jammy/main arm64 libexpat1-dev arm64 2.4.1-3 [131 kB]
Get:3 http://ports.ubuntu.com jammy/main arm64 libfreetype6 arm64 2.11.0+dfsg-1 [382 kB]
Get:4 http://ports.ubuntu.com jammy/main arm64 zlib1g-dev arm64 1:1.2.11.dfsg-2ubuntu7 [163 kB]
Get:5 http://ports.ubuntu.com jammy/main arm64 libpng-dev arm64 1.6.37-3build4 [194 kB]
Get:6 http://ports.ubuntu.com jammy/main arm64 libfreetype-dev arm64 2.11.0+dfsg-1 [555 kB]
Get:7 http://ports.ubuntu.com jammy/main arm64 libfreetype6-dev arm64 2.11.0+dfsg-1 [8,340 B]
Get:8 http://ports.ubuntu.com jammy/main arm64 libjpeg-turbo8 arm64 2.1.1-0ubuntu1 [129 kB]
Get:9 http://ports.ubuntu.com jammy/main arm64 libjpeg-turbo8-dev arm64 2.1.1-0ubuntu1 [246 kB]
Get:10 http://ports.ubuntu.com jammy/main arm64 libjpeg8 arm64 8c-2ubuntu8 [2,198 B]
Get:11 http://ports.ubuntu.com jammy/main arm64 libjpeg8-dev arm64 8c-2ubuntu8 [1,550 B]
Get:12 http://ports.ubuntu.com jammy/main arm64 libjpeg-dev arm64 8c-2ubuntu8 [1,546 B]
Get:13 http://ports.ubuntu.com jammy/main arm64 libjs-jquery all 3.5.1+dfsg+~3.5.5-7 [314 kB]
Get:14 http://ports.ubuntu.com jammy/main arm64 libjs-underscore all 1.9.1~dfsg-4 [103 kB]
Get:15 http://ports.ubuntu.com jammy/main arm64 libjs-sphinxdoc all 4.2.0-5 [137 kB]
Get:16 http://ports.ubuntu.com jammy/main arm64 libpython3.9-dev arm64 3.9.9-1 [4,798 kB]
Get:17 http://ports.ubuntu.com jammy/main arm64 libpython3-dev arm64 3.9.4-1build1 [7,402 B]
Get:18 http://ports.ubuntu.com jammy/universe arm64 python-pip-whl all 20.3.4-4 [1,897 kB]
Get:19 http://ports.ubuntu.com jammy/main arm64 python3.9-dev arm64 3.9.9-1 [508 kB]
Get:20 http://ports.ubuntu.com jammy/main arm64 python3-dev arm64 3.9.4-1build1 [25.5 kB]
Get:21 http://ports.ubuntu.com jammy/main arm64 python3-setuptools all 58.2.0-1 [336 kB]
Get:22 http://ports.ubuntu.com jammy/universe arm64 python3-wheel all 0.34.2-1 [23.8 kB]
Get:23 http://ports.ubuntu.com jammy/universe arm64 python3-pip all 20.3.4-4 [283 kB]
Get:24 http://ports.ubuntu.com jammy/main arm64 python3-psutil arm64 5.8.0-2 [157 kB]
Fetched 10.7 MB in 2s (6,051 kB/s)        
Selecting previously unselected package libbrotli-dev:arm64.
(Reading database ... 68180 files and directories currently installed.)
Preparing to unpack .../00-libbrotli-dev_1.0.9-2build4_arm64.deb ...
Unpacking libbrotli-dev:arm64 (1.0.9-2build4) ...
Selecting previously unselected package libexpat1-dev:arm64.
Preparing to unpack .../01-libexpat1-dev_2.4.1-3_arm64.deb ...
Unpacking libexpat1-dev:arm64 (2.4.1-3) ...
Selecting previously unselected package libfreetype6:arm64.
Preparing to unpack .../02-libfreetype6_2.11.0+dfsg-1_arm64.deb ...
Unpacking libfreetype6:arm64 (2.11.0+dfsg-1) ...
Selecting previously unselected package zlib1g-dev:arm64.
Preparing to unpack .../03-zlib1g-dev_1%3a1.2.11.dfsg-2ubuntu7_arm64.deb ...
Unpacking zlib1g-dev:arm64 (1:1.2.11.dfsg-2ubuntu7) ...
Selecting previously unselected package libpng-dev:arm64.
Preparing to unpack .../04-libpng-dev_1.6.37-3build4_arm64.deb ...
Unpacking libpng-dev:arm64 (1.6.37-3build4) ...
Selecting previously unselected package libfreetype-dev:arm64.
Preparing to unpack .../05-libfreetype-dev_2.11.0+dfsg-1_arm64.deb ...
Unpacking libfreetype-dev:arm64 (2.11.0+dfsg-1) ...
Selecting previously unselected package libfreetype6-dev:arm64.
Preparing to unpack .../06-libfreetype6-dev_2.11.0+dfsg-1_arm64.deb ...
Unpacking libfreetype6-dev:arm64 (2.11.0+dfsg-1) ...
Selecting previously unselected package libjpeg-turbo8:arm64.
Preparing to unpack .../07-libjpeg-turbo8_2.1.1-0ubuntu1_arm64.deb ...
Unpacking libjpeg-turbo8:arm64 (2.1.1-0ubuntu1) ...
Selecting previously unselected package libjpeg-turbo8-dev:arm64.
Preparing to unpack .../08-libjpeg-turbo8-dev_2.1.1-0ubuntu1_arm64.deb ...
Unpacking libjpeg-turbo8-dev:arm64 (2.1.1-0ubuntu1) ...
Selecting previously unselected package libjpeg8:arm64.
Preparing to unpack .../09-libjpeg8_8c-2ubuntu8_arm64.deb ...
Unpacking libjpeg8:arm64 (8c-2ubuntu8) ...
Selecting previously unselected package libjpeg8-dev:arm64.
Preparing to unpack .../10-libjpeg8-dev_8c-2ubuntu8_arm64.deb ...
Unpacking libjpeg8-dev:arm64 (8c-2ubuntu8) ...
Selecting previously unselected package libjpeg-dev:arm64.
Preparing to unpack .../11-libjpeg-dev_8c-2ubuntu8_arm64.deb ...
Unpacking libjpeg-dev:arm64 (8c-2ubuntu8) ...
Selecting previously unselected package libjs-jquery.
Preparing to unpack .../12-libjs-jquery_3.5.1+dfsg+~3.5.5-7_all.deb ...
Unpacking libjs-jquery (3.5.1+dfsg+~3.5.5-7) ...
Selecting previously unselected package libjs-underscore.
Preparing to unpack .../13-libjs-underscore_1.9.1~dfsg-4_all.deb ...
Unpacking libjs-underscore (1.9.1~dfsg-4) ...
Selecting previously unselected package libjs-sphinxdoc.
Preparing to unpack .../14-libjs-sphinxdoc_4.2.0-5_all.deb ...
Unpacking libjs-sphinxdoc (4.2.0-5) ...
Selecting previously unselected package libpython3.9-dev:arm64.
Preparing to unpack .../15-libpython3.9-dev_3.9.9-1_arm64.deb ...
Unpacking libpython3.9-dev:arm64 (3.9.9-1) ...
Selecting previously unselected package libpython3-dev:arm64.
Preparing to unpack .../16-libpython3-dev_3.9.4-1build1_arm64.deb ...
Unpacking libpython3-dev:arm64 (3.9.4-1build1) ...
Selecting previously unselected package python-pip-whl.
Preparing to unpack .../17-python-pip-whl_20.3.4-4_all.deb ...
Unpacking python-pip-whl (20.3.4-4) ...
Selecting previously unselected package python3.9-dev.
Preparing to unpack .../18-python3.9-dev_3.9.9-1_arm64.deb ...
Unpacking python3.9-dev (3.9.9-1) ...
Selecting previously unselected package python3-dev.
Preparing to unpack .../19-python3-dev_3.9.4-1build1_arm64.deb ...
Unpacking python3-dev (3.9.4-1build1) ...
Selecting previously unselected package python3-setuptools.
Preparing to unpack .../20-python3-setuptools_58.2.0-1_all.deb ...
Unpacking python3-setuptools (58.2.0-1) ...
Selecting previously unselected package python3-wheel.
Preparing to unpack .../21-python3-wheel_0.34.2-1_all.deb ...
Unpacking python3-wheel (0.34.2-1) ...
Selecting previously unselected package python3-pip.
Preparing to unpack .../22-python3-pip_20.3.4-4_all.deb ...
Unpacking python3-pip (20.3.4-4) ...
Selecting previously unselected package python3-psutil.
Preparing to unpack .../23-python3-psutil_5.8.0-2_arm64.deb ...
Unpacking python3-psutil (5.8.0-2) ...
Setting up python3-setuptools (58.2.0-1) ...
Setting up python3-wheel (0.34.2-1) ...
Setting up python3-psutil (5.8.0-2) ...
Setting up libexpat1-dev:arm64 (2.4.1-3) ...
Setting up libfreetype6:arm64 (2.11.0+dfsg-1) ...
Setting up libjpeg-turbo8:arm64 (2.1.1-0ubuntu1) ...
Setting up zlib1g-dev:arm64 (1:1.2.11.dfsg-2ubuntu7) ...
Setting up python-pip-whl (20.3.4-4) ...
Setting up libjs-jquery (3.5.1+dfsg+~3.5.5-7) ...
Setting up libbrotli-dev:arm64 (1.0.9-2build4) ...
Setting up libjs-underscore (1.9.1~dfsg-4) ...
Setting up libjpeg8:arm64 (8c-2ubuntu8) ...
Setting up libjpeg-turbo8-dev:arm64 (2.1.1-0ubuntu1) ...
Setting up libpng-dev:arm64 (1.6.37-3build4) ...
Setting up libpython3.9-dev:arm64 (3.9.9-1) ...
Setting up libfreetype-dev:arm64 (2.11.0+dfsg-1) ...
Setting up python3-pip (20.3.4-4) ...
Setting up libjs-sphinxdoc (4.2.0-5) ...
Setting up python3.9-dev (3.9.9-1) ...
Setting up libjpeg8-dev:arm64 (8c-2ubuntu8) ...
Setting up libpython3-dev:arm64 (3.9.4-1build1) ...
Setting up libjpeg-dev:arm64 (8c-2ubuntu8) ...
Setting up libfreetype6-dev:arm64 (2.11.0+dfsg-1) ...
Setting up python3-dev (3.9.4-1build1) ...
Processing triggers for man-db (2.9.4-2build1) ...
Processing triggers for libc-bin (2.34-0ubuntu3) ...
Installing GPIO library dependency in pip...
Collecting RPi.GPIO==0.7.1a4
  Downloading RPi.GPIO-0.7.1a4.tar.gz (29 kB)
Building wheels for collected packages: RPi.GPIO
  Building wheel for RPi.GPIO (setup.py) ... done
  Created wheel for RPi.GPIO: filename=RPi.GPIO-0.7.1a4-cp39-cp39-linux_aarch64.whl size=71613 sha256=53dfde6f104ca9f3546d35832487870d397234ea8122f28d67bfb595e1aa40e4
  Stored in directory: /root/.cache/pip/wheels/6f/1c/5c/113894ea5785c8856518ad0d88803c2ec7cbc6cb88e47f2e04
Successfully built RPi.GPIO
Installing collected packages: RPi.GPIO
Successfully installed RPi.GPIO-0.7.1a4
Installing luma.oled library
Collecting luma.oled
  Downloading luma.oled-3.8.1-py2.py3-none-any.whl (32 kB)
Collecting luma.core>=2.0.0
  Downloading luma.core-2.3.1-py2.py3-none-any.whl (71 kB)
     |████████████████████████████████| 71 kB 3.6 MB/s 
Collecting pillow>=4.0.0
  Downloading Pillow-8.4.0-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl (3.0 MB)
     |████████████████████████████████| 3.0 MB 16.0 MB/s 
Collecting deprecated
  Downloading Deprecated-1.2.13-py2.py3-none-any.whl (9.6 kB)
Collecting spidev
  Downloading spidev-3.5.tar.gz (10 kB)
Collecting cbor2
  Downloading cbor2-5.4.2.tar.gz (85 kB)
     |████████████████████████████████| 85 kB 2.4 MB/s 
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
    Preparing wheel metadata ... done
Requirement already satisfied: RPI.GPIO in /usr/local/lib/python3.9/dist-packages (from luma.core>=2.0.0->luma.oled) (0.7.1a4)
Collecting pyftdi
  Downloading pyftdi-0.53.3-py3-none-any.whl (141 kB)
     |████████████████████████████████| 141 kB 15.4 MB/s 
Collecting smbus2
  Downloading smbus2-0.4.1-py2.py3-none-any.whl (11 kB)
Collecting wrapt<2,>=1.10
  Downloading wrapt-1.13.3.tar.gz (48 kB)
     |████████████████████████████████| 48 kB 2.6 MB/s 
Collecting pyusb!=1.2.0,>=1.0.0
  Downloading pyusb-1.2.1-py3-none-any.whl (58 kB)
     |████████████████████████████████| 58 kB 2.9 MB/s 
Collecting pyserial>=3.0
  Downloading pyserial-3.5-py2.py3-none-any.whl (90 kB)
     |████████████████████████████████| 90 kB 4.7 MB/s 
Building wheels for collected packages: cbor2, wrapt, spidev
  Building wheel for cbor2 (PEP 517) ... done
  Created wheel for cbor2: filename=cbor2-5.4.2-cp39-cp39-linux_aarch64.whl size=165153 sha256=7cc7110c2bf4bf36ad78c8e2c3e8f48f3ecebb9b012bcac8254d6605e7ff5934
  Stored in directory: /root/.cache/pip/wheels/8f/73/f0/a47bd572f51ce2006f0df606036923f3c437f8b33e735472e2
  Building wheel for wrapt (setup.py) ... done
  Created wheel for wrapt: filename=wrapt-1.13.3-cp39-cp39-linux_aarch64.whl size=74011 sha256=0f76a47d495cfc1bdccae8d188476519326772a392e8517e6e91a452aeb3a296
  Stored in directory: /root/.cache/pip/wheels/f9/6e/ed/b9a64c8281ff2ee42402497ff3c67f4abd39f552efecc309a9
  Building wheel for spidev (setup.py) ... done
  Created wheel for spidev: filename=spidev-3.5-cp39-cp39-linux_aarch64.whl size=41256 sha256=56d77998f647774b49eaa3fbd10f58e1a0389c199cb27d3164021cc03ab107fc
  Stored in directory: /root/.cache/pip/wheels/af/4b/86/7f9af5f0c9fbcca1aa3279380b64bf55f323ba022485d9a041
Successfully built cbor2 wrapt spidev
Installing collected packages: wrapt, pyusb, pyserial, spidev, smbus2, pyftdi, pillow, deprecated, cbor2, luma.core, luma.oled
Successfully installed cbor2-5.4.2 deprecated-1.2.13 luma.core-2.3.1 luma.oled-3.8.1 pillow-8.4.0 pyftdi-0.53.3 pyserial-3.5 pyusb-1.2.1 smbus2-0.4.1 spidev-3.5 wrapt-1.13.3
Installing sys-oled files
'etc/sys-oled.conf' -> '/etc/sys-oled.conf'
'bin/sys-oled' -> '/usr/local/bin/sys-oled'
'share/sys-oled' -> '/usr/local/share/sys-oled'
'share/sys-oled/C&C Red Alert [INET].ttf' -> '/usr/local/share/sys-oled/C&C Red Alert [INET].ttf'
'share/sys-oled/helios4_logo.png' -> '/usr/local/share/sys-oled/helios4_logo.png'
'system/sys-oled.service' -> '/etc/systemd/system/sys-oled.service'
Enabling sys-oled at startup
Created symlink /etc/systemd/system/multi-user.target.wants/sys-oled.service → /etc/systemd/system/sys-oled.service.
Starting service...
odroidhc4:sys-oled-hc4:%

Enable FAN:

# create file /etc/fancontrol with the following content

INTERVAL=10
DEVPATH=hwmon0=devices/virtual/thermal/thermal_zone0 hwmon2=devices/platform/pwm-fan
DEVNAME=hwmon0=cpu_thermal hwmon2=pwmfan
FCTEMPS=hwmon2/pwm1=hwmon0/temp1_input
FCFANS= hwmon2/pwm1=hwmon2/fan1_input
MINTEMP=hwmon2/pwm1=50
MAXTEMP=hwmon2/pwm1=60
MINSTART=hwmon2/pwm1=20
MINSTOP=hwmon2/pwm1=28
MINPWM=hwmon2/pwm1=0
MAXPWM=hwmon2/pwm1=255

sudo systemctl restart fancontrol

Build from sources (build host must be Ubuntu Hirsute or Jammy):
 

apt-get -y install git
git clone https://github.com/armbian/build
cd build
sed "s/^#DOCKER_FLAGS+=(--privileged)/DOCKER_FLAGS+=(--privileged)/" -i config/templates/config-docker.conf
touch .ignore_changes
./compile.sh \
docker \
EXPERT="yes" \
BOARD="odroidhc4" \
BRANCH="current" \
RELEASE="jammy" \
KERNEL_ONLY="no" \
KERNEL_CONFIGURE="no" \
BUILD_DESKTOP="no" \
BUILD_MINIMAL="no"

Using this distro:

Armbian_22.05.4_Nanopim4v2_jammy_current_5.15.48_xfce_desktop

Baseline using built-in 1 Gigabit ethernet port on Nanopi M4V2 board:

iperf3 -t 60 -c faststore (1 stream)

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-60.00  sec  6.63 GBytes   949 Mbits/sec    0             sender
[  5]   0.00-60.00  sec  6.63 GBytes   949 Mbits/sec                  receiver

iperf3 -t 60 -P4 -c faststore (4 streams)

[SUM]   0.00-60.00  sec  6.63 GBytes   950 Mbits/sec  176             sender
[SUM]   0.00-60.00  sec  6.62 GBytes   948 Mbits/sec                  receiver

Sabrent NT-SS5G attached to 2.5 Gbe port:

iperf3 -t 60 -c faststore (1 stream)

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-60.00  sec  16.5 GBytes  2.36 Gbits/sec    0             sender
[  5]   0.00-60.01  sec  16.5 GBytes  2.36 Gbits/sec                  receiver

iperf3 -t 60 -P4 -c faststore  (4 streams)

[SUM]   0.00-60.00  sec  16.5 GBytes  2.36 Gbits/sec    0             sender
[SUM]   0.00-60.05  sec  16.5 GBytes  2.36 Gbits/sec                  receiver

2.36 Gbits/sec is about the best I ever see using the 2.5 Gbe port on this server from other machines, so this is quite good.

Note: as pointed out in several reviews of this Sabrent NT-SS5G, the USB 3 port (5 Gb max) limits the ethernet bandwidth to a lot less than 5 Gbe max.

Sabrent NT-SS5G attached to 5 Gbe port:

iperf3 -t 60 -c faststore (1 stream)

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-60.00  sec  17.3 GBytes  2.47 Gbits/sec    0             sender
[  5]   0.00-60.01  sec  17.3 GBytes  2.47 Gbits/sec                  receiver

iperf3 -t 60 -P4 -c faststore  (4 streams)

[SUM]   0.00-60.00  sec  17.7 GBytes  2.53 Gbits/sec    0             sender
[SUM]   0.00-60.03  sec  17.7 GBytes  2.53 Gbits/sec                  receiver
 

This is as expected, the USB3 (5 Gb max) interface of the Sabrent NT-SS5G limits the throughput.  It is better than when connected to a 2.5 Gbe port, but not by much.

It does seem to be pretty stable though.  And the drivers were already included, I just plugged the device into a USB3 port and it autoconfigured, connection information showed 2.5 or 5 Gbe based on the speed of the port it was plugged into.

Since this only gives a marginal improvement over the 2.5 Gbe USB adapters, probably save your money and buy a USB3 to 2.5 Gbe adapter, there are several on the market.

we have developed a script to create an SD image for Odroid HC4. With this method you can use Armbian without erase Petitboot partition.

https://github.com/TheLillo/generate-image-hc4-armbian

URL: https://www.dropbox.com/s/ya3expllg1bqgfg/fructify.20211011.sh.gz

To install the script, please run these commands:-

# sudo wget https://www.dropbox.com/s/ya3expllg1bqgfg/fructify.20211011.sh.gz -O /usr/local/bin/fructify.sh.gz

# sudo gunzip /usr/local/bin/fructify.sh.gz

# sudo chmod +x /usr/local/bin/fructify.sh

Oh, and install ZFS on your own OS installation.

To use the script, either download an existing Armbian image or use your own system as the basis for the new installation. Next, please make sure (i) there is a blank micro-SD card in an adapter, (ii) the adapter is plugged into a USB port, and (iii) you know which /dev entry refers to that adapter’s USB port. It will probably be /dev/sda; please do not assume so. In the below commands, replace sdX with sda (or whatever).

Method 1: Download and use an existing Armbian image

# wget https://mirrors.netix.net/armbian/dl/nanopineo3/archive/Armbian_21.08.1_Nanopineo3_focal_current_5.10.60.img.xz -O /root/npneo3_focal.img.xz

# xz -d /root/npneo3_focal.img.xz

# fructify.sh /root/npneo3_focal.img.xz zfs /root/out.img

# dd status=progress bs=1024k if=/root/out.img of=/dev/sdX

Method 2: Use your existing filesystem as the basis

# fructify.sh / zfs /dev/sdX

In either case, please take care not to write the image to the wrong device.

This script can also work with btrfs, ext4, or xfs.

The script assumes that you have only one partition on your boot drive. That drive is usually /dev/mmcblk0; the boot/root partition is expected to be /dev/mmcblk0p1. It may be that the script also works if the boot drive is /dev/mmcblk1 and the boot/root partition is /dev/mmcblk1p1; I do not know. In any case, the script shrinks partition #1 (for boot) and allocates approximately 4GB to a newly created partition #2 (for root).

If you create a ready-to-install Armbian image and boot it on a micro-SD card, the OS will expand partition #2 to fill the remainder of the micro-SD card. If you create a ZFS-ified (or whatever) copy of your existing installation, the SD card’s second partition will already have been expanded by the script itself.

All feedback is welcome. I am new at this. Thank you.

Greetings,
NicoD

Greetings, NicoD

For those interested, here are all my benchmarks of the last weeks.

Board                  | SBC-Bench              | Distro                             | Clockspeeds         | 7z all cores  | 7z small core   | 7z big core   | CPU-Miner   | NicoD-Blender      | Max temp         
Radxa Zero               http://ix.io/3PlT        Radxa Buster xfce4 5.10              1.8Ghz                6348            1641                              6.75          26m31s                 66c
Radxa Zero               http://ix.io             Manjaro XFCE 5.16.9  22.02.04        1.8Ghz                6303            1631                                            15m39s                 69C
Radxa Zero               http://ix.io/3PMy        Armbian Jammy xfce 5.15              1.8Ghz                6296            1646                                            15m52s                 70c
Radxa Zero               http://ix.io/3TX3        Armbian Jammy xfce4 5.15             1.8Ghz                6014            1634                                            16m05s                 70c

Board                  | SBC-Bench              | Distro                             | Clockspeeds         | 7z all cores  | 7z small core   | 7z big core   | CPU-Miner   | NicoD-Blender      | Max temp      
NanoPi M4 2GB            http://ix.io/3xnJ        Armbian Hirsute xfce4 5.13.12        1.4Ghz/1.8Ghz         7760            1267              1857            10.05         14m41s                 78C    
NanoPi M4 2GB            http://ix.io/3xv3        Armbian Hirsute xfce4 5.13.12        1.5Ghz/2Ghz           8288            1348              2070            10.95         13m21s                        
NanoPi M4 2GB            http://ix.io/3xs3        Armbian Hirsute cinnamon 5.13.12     1.4Ghz/1.8Ghz         7766            1267              1851            10            14m33s                 78C      
NanoPi M4 2GB            http://ix.io/3xt0        Armbian Hirsute budgie 5.13.12       1.4Ghz/1.8Ghz         7941            1272              1863            10.05         14m24s/14m18s          78C      
NanoPi M4 2GB            http://ix.io/3xtR        Armbian Buster xfce4 4.4.213         1.5Ghz/2Ghz           8383            1359              1982            10.8          14m17s                         
NanoPi M4 2GB            http://ix.io/3xuf        Armbian Buster xfce4 4.4.213         1.4Ghz/1.8Ghz         7879            1278              1807            10            15m20s                                  
NanoPi M4 2GB            http://ix.io/3xux        Armbian Focal xfce4 5.10.60          1.4Ghz/1.8Ghz         8028            1286              1859            10.27         13m29s                        
NanoPi M4 2GB            http://ix.io/3xuL        Armbian Focal xfce4 5.10.60          1.5Ghz/2Ghz           8427            1351              2076            11.2          12m53s                         
NanoPi M4 2GB            http://ix.io/3EDB        Ubuntu Xenial armhf 4.4 xfce4        1.4Ghz/1.8Ghz         7069            1140              1695                                                              
NanoPi M4 2GB            http://ix.io/3TXE        Armbian Jammy xfce4 5.15             1.4Ghz/1.8Ghz         7749            1317              1929                          9m50s                   69c

Board                  | SBC-Bench              | Distro                             | Clockspeeds         | 7z all cores  | 7z small core   | 7z big core   | CPU-Miner   | NicoD-Blender         | Max temp
Odroid C4/HC4            http://ix.io/2LaP        Ubuntu Mate 4.9                      1.91Ghz               7000            1769                              7.2 kH/s                                         
Odroid C4/HC4            http://ix.io/3F6z        Armbian Buster 5.9                   2.10Ghz               7971            2030                              7.9           23m02s                              
Odroid HC4                                        Armbian Jammy xfce4 5.16             2.10Ghz               7342            1929                                            17m08s                  69C
Odroid HC4               http://ix.io/3TVX        Armbian Jammy xfce4 5.10             2.10Ghz               7350            2008                                            16m35s                  70C

Khadas VIM3                                       Armbian Hirsute cinnamon 5.13.12                                                                                           12m55s

Board                  | SBC-Bench              | Distro                             | Clockspeeds         | 7z all cores  | 7z small core   | 7z big core   | CPU-Miner   | NicoD-Blender         | Max temp
Raspberry Pi4            http://ix.io/3F6o        Armbian Jammy 5.13                   2Ghz                  8047                              2070             Didn't work  Blender doens't work                
Raspberry Pi4            http://ix.io/3F6K        Armbian Jammy 5.13                   1.5Ghz                6239                              1572                                                                   
Raspberry Pi4                                     Armbian Hirsute edge xfce4 5.11      1.5Ghz                5832                              1534                          18m11s                   60C
Raspberry Pi4            http://ix.io/3Euw        Armbian Hirsute edge xfce4 5.11      2Ghz                  7747                              2037             9.8          14m26s                   68C       
Raspberry Pi4            http://ix.io/3FbW        Armbian Hirsute 5.11 OC GPU+CPU      2.1Ghz                8168                              2147                          Blender crash                       
Raspberry Pi4            http://ix.io/3EU7        Armbian Impish edge headless 5.13    1.5Ghz                6251                              1584                          15m39s                              
Raspberry Pi4            http://ix.io/3Ewi        Armbian Impish edge headless 5.13    2Ghz                  8171                              2093                          12m41s                              
Raspberry Pi4            http://ix.io/3EPQ        Armbian Bullseye edge headless 5.13  1.5Ghz                6328                              1594             7.3          Blender doesn't work              
Raspberry Pi4            http://ix.io/3EK9        Armbian Bullseye edge headless 5.13  2Ghz                  8242                              2096             9.7          Blender doesn't work            
Raspberry Pi4            http://ix.io/3ECd        Raspberry Pi OS Bullseye 32-bit      1.5Ghz                7577                              1933                          21m09s                              
Raspberry Pi4            http://ix.io/3ECt        Raspberry Pi OS Bullseye 32-bit      2Ghz                  9746                              2533                          17m05s                            
Raspberry Pi4            http://ix.io/3EIe        Raspberry Pi OS Bullseye 64-bit      1.5Ghz                6174                              1567             7.2          17m01s                             
Raspberry Pi4            http://ix.io/3EJs        Raspberry Pi OS Bullseye 64-bit      2Ghz                  8026                              2053             9.65         Blender unstable at 2Ghz            
Raspberry Pi4            http://ix.io/3EGZ        Ubuntu 21.10 (Impish) 5.13 arm64     1.5Ghz                6160                              1563                          16m50s                            
Raspberry Pi4            http://ix.io/3EHA        Ubuntu 21.10 (Impish) 5.13 arm64     2Ghz                  7965                              2038             Didn't work  Blender unstable at 2Ghz          

Board                  | SBC-Bench              | Distro                             | Clockspeeds         | 7z all cores  | 7z small core   | 7z big core   | CPU-Miner   | NicoD-Blender         | Max temp
RPi400                   http://ix.io/3HLw        Armbian Jammy Edge 5.15.7 cinnamon   2Ghz o.v. 6           7913                              2085                          19m34s                  69C        
RPi400                   http://ix.io/3HSI        Armbian Impish current 5.13.0 cin    2Ghz o.v. 6           7869                              2104                          14m20s                  63C       
RPi400                   http://ix.io/3HTx        Armbian Impish current 5.13.0 cin    2.1Ghz + 700GPU o.v.6 6930                              2069                          13m27s                  65C        
RPi400                   http://ix.io/3HTR        Armbian Impish current 5.13.0 cin    2.1Ghz o.v.6          8188                              2205                          14m03s                  65C      
RPi400                   http://ix.io/3HMm        RPiOS bullseye armhf 5.10.63         1.8Ghz                8705                              2350                          18m46s                  55C       
RPi400                   http://ix.io/3HRl        RPiOS bullseye armhf 5.10.63         2Ghz o.v. 4           9834                              2601                          17m07s                  61C       
RPi400                                            Manjaro KDE 5.10                     1.8Ghz                7426                              1886                          14m28s                  58C
RPi400                   http://ix.io/3IgG        Manjaro KDE 5.10                     2Ghz                  8156                              2092                          13m16s                  65C        
RPi400                   http://ix.io/3U13 ***    Armbian Jammy xfce4 5.15             1.8Ghz                7166                              1882                          13m15s

Board                  | SBC-Bench              | Distro                             | Clockspeeds         | 7z all cores  | 7z small core   | 7z big core   | CPU-Miner   | NicoD-Blender         | Max temp
Odroid N2+               http://ix.io/3EwQ        Armbian Impish xfce4 5.14            2Ghz/2.4Ghz           11714           1765              2517                           8m51s                            
Odroid N2+               http://ix.io/3TDQ        Armbian Impish xfce4 5.10            2Ghz/2.4Ghz           11743           1817              2626                           8m43s                  60C
Odroid N2+               http://ix.io/3TEq        Armbian Jammy xfce4 5.10             2Ghz/2.4Ghz           11801           1818              2646                           5m54s * Blender 3.0.1

Board                  | SBC-Bench              | Distro                             | Clockspeeds         | 7z all cores  | 7z small core   | 7z big core   | CPU-Miner   | NicoD-Blender         | Max temp
I5 2500K OC              http://ix.io/3SkY        Armbian Focal 5.15                   4Ghz                  16029                             4059            50            3m31s                   95C ++Throttle with CPUMiner
I5 2500K PowerSaving                              Armbian Focal 5.15                   3.4Ghz                13544                             3691                          4m10s                   69C 200W

I show what's new. Mostly the feel and look are a bit more modern.
Here is my video.

Some other notes I've got :

 

Memory usage
buster < focal < hirsute
xfce4 < budgie < cinnamon

CPU performance
buster < hirsute < focal
xfce4 < cinnamon < budgie

So Buster xfce uses the least memory. And is also the slowest.

Hirsute is quite a bit slower than Focal, and uses more memory. I do find the newer looks worth the price.

Here my benchmarks :

Fix missing network 
sudo apt install gvfs-backends

Download SBC-Bench
	wget https://raw.githubusercontent.com/ThomasKaiser/sbc-bench/master/sbc-bench.sh
Execute SBC-Bench
	sudo /bin/bash ./sbc-bench.sh -c
7zip all cores
	7z b
7zip small core
	taskset -c 0 7z b
7zip big core 
	taskset -c 5 7z b
NicoD Blender
	blender -b NicoD.xx.blend -f 0
SuperTuxKart	
	1080p full screen, show fps, choose soccer game with tux and grassfield. Average frames.
Max temp
	Maximum temperature during blender NicoD render


Board                  | SBC-Bench              | Distro                             | Clockspeeds         | 7z all cores  | 7z small core   | 7z big core   | CPU-Miner   | NicoD-Blender     | SuperTuxKart   | Memory used at boot  | Max temp
NanoPi M4 2GB            http://ix.io/3xnJ        Armbian Hirsute xfce4 5.13.12        1.4Ghz/1.8Ghz         7760            1267              1857            10.05         14m41s              8fps             693MB                  78C    ***
NanoPi M4 2GB            http://ix.io/3xv3        Armbian Hirsute xfce4 5.13.12        1.5Ghz/2Ghz           8288            1348              2070            10.95         13m21s              8fps             693MB                         ***
NanoPi M4 2GB            http://ix.io/3xs3        Armbian Hirsute cinnamon 5.13.12     1.4Ghz/1.8Ghz         7766            1267              1851            10            14m33s              8fps             809MB                  78C
NanoPi M4 2GB            http://ix.io/3xt0        Armbian Hirsute budgie 5.13.12       1.4Ghz/1.8Ghz         7941            1272              1863            10.05         14m24s/14m18s       8fps             757MB                  78C
NanoPi M4 2GB            http://ix.io/3xtR        Armbian Buster xfce4 4.4.213         1.5Ghz/2Ghz           8383            1359              1982            10.8          14m17s                               530MB     
NanoPi M4 2GB            http://ix.io/3xuf        Armbian Buster xfce4 4.4.213         1.4Ghz/1.8Ghz         7879            1278              1807            10            15m20s                               530MB                                    
NanoPi M4 2GB            http://ix.io/3xux        Armbian Focal xfce4 5.10.60          1.4Ghz/1.8Ghz         8028            1286              1859            10.27         13m29s              8fps             586MB                         ***
NanoPi M4 2GB            http://ix.io/3xuL        Armbian Focal xfce4 5.10.60          1.5Ghz/2Ghz           8427            1351              2076            11.2          12m53s              8fps             638MB                         ***

NicoD

This tutorial is for the Orange Pi Zero, but will probably work for other boards.

I couldn't easily do a comprehensive hardware and software tutorial on this forum, so I've published it on my web server and linked from here and attached a PDF.
Link to the Tutorial - http://schwartzel.eu3.org/ntp-stratum1.html

Tutorial PDF
ntp-stratum1.pdf

If you spot any typo's or errors please let me know.

After successful boot runned nand-sata-install to ADATA SP 550NS38 SSD connected using VL817 SATA Adaptor (2109:0715).
Upgraded the Debian to Bullseye and installed Mesa 21.2.0 packages from experimental repositories, arm64 firefox-esr and armhf Chromium via multiarch to use widevine extracted from ChromeOS images (local err.ee web broadcasts some programs with widevine encryption). This was in the end of august. It mostly worked, but had 3 weird problems that I think to have solved now having some free time.

1. The USB boot hanged up about half of times after kernel detected the SATA drive. Turns out that UAS is culprit, disabling UAS with usb-storage.quirks=2109:0715:u made it now boot every time without problems (modified /boot/boot.ini).
2. About 2-3 minutes after boot the compositor froze (no matter which - tried Xorg compton, wayland Weston and Wayfire (self compiled). Turns out armbian has /etc/udev/rules.d/hdmi.rules which runs /usr/local/bin/hdmi-hotplug. For some reason the hdmi-hotplug script stalls on my Odroid installation and when systemd finally killed it, something went wrong and the compositors froze. Diverting the hdmi.rules fixed it.
3. This was/is weirdest - when TV connected via HDMI was off and turned on, then sometimes the board would shutdown. Found from auth log "auth.log.1:Dec 25 19:04:59 piix systemd-logind[1641]: Power key pressed." Like WTF, i don't have any "power key" and why it gets invoked when TV is turned on. Set the *Key=ignore in /etc/systemd/logind.conf and it seems fine now, no idea what went wrong there. The kernel even don't have CEC enabled (CONFIG_CEC_MESON_AO and CONFIG_CEC_MESON_G12A_AO are not set for some reason in the armbian kernels).

A bit later I also saw 5.15.8-meson64 kernel OOPS "Unable to handle kernel execute from non-executable memory" at regmap_update_bits_base+0x74/0x98, meson_clk_cpu_dyndiv_set_rate+0xf4/0x118. As I hadn't seen this before, downgraded to 5.13.12-meson64. I plan to report the OOPS with full kernel dmesg output, when I'll have a bit more time (probably the https://bugzilla.kernel.org/ would be right place?).

Currently it seems to work fine, with the 5.13.12-meson64 kernel and mesa/panfrost 21.2.1-2 (from snapshot.debian.org). Weston is used as Wayland compositor. It is important to note that I have 1080p TV, and all video decoding is done on CPU without using the Amlogic VPU acceleration, as the VPU driver is currently both broken in the kernel and unsupported in unpatched userspace. I expected this when choosing the board. Fortunately the 4xA73@2.4GHz is fast enough for decoding most 1080p videos and panfrost is fine for doing the video output after decoding. AFAIK playing 4K videos is currently not possible on Odroid N2 with mainline kernel and the vendors proprietary VPU decoder isn't supported by any software in open source distributions like Debian. Interesting is that Firefox seems to handle the video decoding pathway better for Youtube in this configuration,
while Chromium occasionally stutters on some Youtube videos, these seem to be fine with Firefox. Luckily this seems to not affect the site where I needed widevine (that works only with Chromium in practice). In september widevine upgraded to version needing patched libc. I got patched armhf libc6 package from apt.xbian.org repository.

The ALSA configuration is weird, amixer scontrols | wc gives 50 controls, and if misconfigured, then the thing doesn't give any audio output. I found the following script from somewhere that "fixes" it into working state:

amixer sset 'FRDDR_A SINK 1 SEL' 'OUT 1'
amixer sset 'FRDDR_A SRC 1 EN' 'on'
amixer sset 'TDMOUT_B SRC SEL' 'IN 0'
amixer sset 'TOHDMITX I2S SRC' 'I2S B'
amixer sset 'TOHDMITX' 'on'
amixer sset 'FRDDR_B SINK 1 SEL' 'OUT 2'
amixer sset 'FRDDR_B SRC 1 EN' 'on'
amixer sset 'TDMOUT_C SRC SEL' 'IN 1'
amixer sset 'TOACODEC SRC' 'I2S C'
amixer sset 'TOACODEC OUT EN' 'on'
amixer sset 'TOACODEC Lane Select' '0'
amixer sset 'ACODEC' '255'
amixer sset 'FRDDR_C SINK 1 SEL' 'OUT 3'
amixer sset 'FRDDR_C SRC 1 EN' 'on'
amixer sset 'SPDIFOUT SRC SEL' 'IN 2'

After that ALSA pcm "hw:0,1" output works. I configured dmixed and removed pulseaudio, as it seemed to complicate things with no benefit when mpc and browser run as different users.

Armbian is great (couldn't have the board working so well without armbian) and merry holidays for you

Hoping this helps others having Odroid N2(+) board.

Long story short.
Jammy xfce 5.16 performs better. And has the better performing browser.
Focal xfce 5.15 firefox is not HW-acc. Chromium is, but performs badly. Also bad blender result. Not all cores are used to the max. I've never seen this behaviour.

So I would use the Jammy xfce 5.16 image. But I'm still using an older image that work. So I'm not upgrading.
Greetings, NicoD

In the simplest case, you could attach almost any drive to almost any board, by any number of ways, and you have yourself 'a file server.'  However with even a small amount of effort, there are so many better ways to do things nowadays.  We have a lot more interesting hardware choices, advanced filesystems, etc. and so those are mostly what I want to talk about.

But first, some context.

Dedicated distros vs simple directory sharing

Personally I am not a fan of dedicated distros like FreeNAS, OMV, etc. as I consider them to be too 'heavy weight' and single solution specific.  I mean, if you need some/all of those features, or you like them or whatever, then great, use them.

However, a 'file server' is one of the simplest use cases of a 'server' and I am sure one which almost everyone buying a SBC will do at some point.  IMO, all one needs to do is simply share some folder(s) via either NFS (if your network is mostly GNU/Linux machines) or Samba/SMB (if your network is mostly Windows machines).  And that's it, you're done!  Simple, lightweight, and using standard protocols (well, a little less 'standard' in case of Windows, but I digress ).

You could also add any of the software included in the 'all in one' solutions in first paragraph on a 'piece by piece' basis, if/when you need them.  Personally I am more of a fan of starting small (vanilla Armbian base) and then adding things you need one by one.  But you are of course free to do whatever you want.

Setting any of that up, or debating about it, is considered off-topic for this thread, as there are tons of resources already around the Internet about those things.  So I want to focus on other, (IMO) more interesting, aspects.  You are welcome to make your own thread with a different focus, of course.

Important note about hardware RAID

RAID, in case you were unaware, means "Redundant Array of Independent Disks."

For a looooooong time, I (and I think many others with SOHO NAS perspective) thought that 'hardware RAID was the only proper way to do it' but in the course of researching ZFS I eventually became convinced otherwise.  In fact, apparently, historically 'big-iron' filesystems (Solaris, others) were always run with software RAID in the enterprise as there are a lot of advantages to that.

Just think about it.  If your hardware RAID card dies, you need to replace it with exactly the same model, before you can even begin to recover your data.  With software RAID, you just re-connect drives and you are back in business (with ZFS, you can even connect them in any random order, amazing!).

In particular if you are using ZFS, hardware RAID controllers are not recommended.  I am not sure how much this applies to other similar software RAID systems, but it would stand to reason that it does (IMO).

Hardware controllers are also typically very expensive and proprietary.  Where software RAID uses readily available and inexpensive commodity hardware (while actually increasing reliability).  All of which is why I have become such a big fan of it, whether we are talking about ZFS (which I like) or some other software RAID solution you may prefer instead.

Now, with that out of the way, onward!

Filesystem

Assuming you came to similar conclusions as I did in previous section already, this is where our decision making process really begins in earnest IMO.  As the way I see it, choice of file system will dictate topology, which will in turn dictate choice of hardware (which SBC to buy).

Of course if you already bought some SBC, you are in a different boat (and working backwards, from my point of view ).  Anyway, you will have to adapt accordingly (and/or buy different hardware).  However, if you are already there, go to 'Historical Overview' section, and maybe you can find some solution there which will work with the hardware you already have.

Now, back on track, we are really lucky nowadays, thanks to F/LOSS, to have some industrial grade, software based filesystems available to us mere mortals! 

I like ZFS, but certainly, opinions will differ.  Some people like btrfs, in fact I got into a lengthy (but IMO informative) debate with @tkaiser about that.

Then there are other distributed things like Ceph (and others) which I will admit to knowing less about.  If you do, kindly add your thoughts to the thread when you have a moment.

Point being, hardware setup for someone like me (using ZFS) or even someone using btrfs will be perhaps quite different than someone using something distributed like Ceph.  Just keep that in mind.

Historical Overview (SBC Hardware)

I want to cover some of things which came before, as I think they are relevant to understanding where we are today.

In the beginning, there was darkness.  Wait, let me fast forward a bit. 

I will start with the creation of Armbian.  Which happened, in fact, because Igor was trying to set up a file server on a cubietruck.  True story (and like I said, you are not alone, this is a common use-case)!    Anyway, many of us bought (A20 based) cubietruck back then, because they sold a small power adapter board which made this easy and they also had a SATA connector right on the board.  I think they were one of first to do this in fact (I could be wrong).

After that, a lot of us used (more powerful Samsung Exynos5 based octo-core) ODROID-XU4, along with a good quality USB to SATA adapter with UASP.  That one in particular was recommended by tkaiser a long time ago, however -- as of time of writing this post -- PINE64 still sell it in their store(!).  And it may be an 'okay' solution if you have some (especially, USB3 capable) board laying around that you just want to use.  Some people are still using this today.  But we have a lot better options now.

Then RK3399 came on the scene.  Which was very exciting, because these support not only PCIe, but they are also 64-bit (which is required for ZFS).  Unfortunately, it took literally years for these to become really stable.  Lucky for you, this is all in the past by now.  And so, currently, many people will probably recommend RK3399 as a file (or other) server.

There are a lot of other boards out there, which I do not have as much experience with.  But I also try to note only historically significant developments here (at least the way I see them).  If you have any to add, please comment below or contact me somehow (PM or IRC) and I will edit this post and add them.

Usage (other than file server)

As I already stated, almost any cheap board can be a (minimal) 'file server.'  From that point of view, more powerful boards (like RK3399, or others) are overkill.  However maybe you want better throughput.  Or more disks.  Or, like me, you want to run advanced filesystem like ZFS (also with more disks).

Another thing which happens is that, once you handle the simple case of serving files, before you know it you will probably want to start doing more than that.  You may already have some more demanding requirements in mind beforehand.

For all these reasons, a slightly more powerful (and more expensive) board may be a better choice, as you will not be limited in the future.  But if you are very sure about your needs and wants, and have perhaps other boards on your network to handle processing intensive tasks, this may not apply to you.  Just something to consider.

Hardware Recommendations (RK3399 based)

For reasons mentioned at end of 'Historical Overview' section, many of us are fans of RK3399 based devices nowadays.

Within this subset, you will get a lot of opinions.    I know because I spent literally years asking people (including developers), while I was waiting for RK3399 to mature.  Some developers think certain vendors make crappy hardware (and maybe they are right).  Or they prefer the boards they know and develop on (naturally, IMO).  Some vendors support the project a lot more than others (PINE64, notably, do not support Armbian at all to my knowledge).  So you will have to do some amount of your own research, and form your own opinion here.

I don't want to discount any of the above criteria too much.  However, in the end, at least for me, one criteria bubbled to the top.  And that was direct PCIe (or SATA) support.  Since we are talking about RK3399 here, this means PCIe support.  Which of course is in the SoC, but that is not what I am talking about.  I am talking about putting a standard PCIe physical interface directly on the board.

This way, you can buy any standard cheap/dumb PCIe to SATA adapter card.  You can keep spares.  You will be able to obtain them for the foreseeable future.

By contrast, you can certainly rig up your own adapters, cables, etc. from GPIO.  But personally, I find that fiddly and it doesn't strike me as the most reliable.  I know some people are doing this just fine though.

Another way, is that many vendors sell some sort of HAT, which provides SATA connectivity.  However I find this short-sighted and -- quite frankly -- self-serving.  What if they are out of stock, or stop making them?  You are out of luck.  Or you would need to revert to the above option (rigging up cables and adapters).  It's good for them selling add-on hardware though I guess -- hence my 'self-serving' comment -- but maybe not the best for you and me in terms of keeping our important data available and up and running, on a long term basis.

Therefore I say, skip all of that and go with a board that has a standard physical PCIe right on the board.

ROCKPro64

And AFAIK, there is only one (standalone SBC) RK3399 that meets that description, which is ROCKPro64.  Of course, I am not the first to come to same conclusion, in fact there is a whole thread where myself and some other like-minded folks discuss using ROCKPro64 as NAS.

I say 'standalone SBC', because I almost forgot...

Helios 64

These of course are no longer made, and Kobol, our once partners, have unfortunately closed up shop.  However they still come up for sale on the forums from time to time (usually in Kobol Club (subforum is no more) but could be anywhere).

Here you would be getting a more integrated solution, often including a nice case, for perhaps a bit more money.

Some people have had problems with stability though, which I am not sure were ever fully worked out.  As of mid-2024, it seems the community have finally got this device stable.  Which I personally find pretty remarkable, given the circumstances.

Having said that, I am sure these devices are only getting harder and harder to come by, especially now.  Not only that, but keeping it that way is always going to require ongoing maintenance, as the Linux kernel (and other parts of the OS) never stop moving forward.

Hardware Recommendations (not RK3399 based)

ODROID HC4

ODROID HC4 was also brought up today, when this subject came up in IRC, by @rpardini as that is what he uses.  This is an interesting alternative to the above, except Amlogic (S905X3) based (like a lot of TV boxes).  Which to me means two things:

1. It almost certainly requires blobs.

2. It's probably cheaper than RK3399.

Well in fairness ROCKPro64 probably requires some blobs, too.  But somehow I get the impression that Amlogic are really obnoxious with their blobs, and I am not a fan of them as a company because of this.  Surely a developer will need to correct me here. 

Anyway, I am not sure how it compares in processing power.  I suspect less than RK3399(?).  However for media transcoding, it may actually be better (perhaps hardware decoders(?), speculation on my part).

Also for simple 'file server' use-case, in particular with Ceph or something like that, it becomes more interesting IMO.  Again, quoting rpardini from IRC today: "scale out, not up."

Future

There are newer SoCs, like RK3566 and others.  At this time, they are a lot like RK3399 was early on.  Very exciting, but not able to realize their full potential due to lack of (software/Linux) development.

The consensus among developers seems to be that RK3566 development should go faster/easier than RK3399 development, because of all the ground work that was laid in the course of the latter.  Maybe that's true, but we are still talking about some time.  Maybe less years, but still significant time.

If/when this changes, I will try and remember to update the post.  Feel free to ping me by posting, I should get notified.

Others?

Possibly anything in NAS category.  Which I mostly covered already (above, in more detail) but can always change in future.

Certainly I forgot (or don't know about) some others.  I have shared what I learned from my research the last several years while looking for solution for myself.  However I do want to make this a more general resource that we can all point to, so please discuss, and I will be happy to edit this post later on and add relevant info.

To clarify, I am not talking about 'any SBC which can be made into a file server' which is almost any of them, but rather particular hardware which is interesting for some specific reason(s), especially currently (or perhaps historically, which I would add to that section).

Cheers!

Greetings.
NicoD

It ain't perfect. It needs some fixes to be workable. I show what to do to install and fix.
Here's the video. Greetings.

alguem pode me ajudar.

At the moment, I have working mocp from root user, which able to play mp3 and online radio.

I am not sure if all steps are necessary. So if You know a shorter version of this, please post a reply.

Lets begin.

1. Insert USB sound card, Boot Orange Pi, and login via SSH.

Цитата

 

mocp output:

Running the server...
Trying JACK...
Trying ALSA...
Trying OSS...

FATAL_ERROR: No valid sound driver!

FATAL_ERROR: Server exited!

 

alsamixer not work without arguments ( It may print something like: cannot open mixer: No such file or directory ). But this works: alsamixer -c 1

2. I am not sure if this step is necessary, but I installed
apt install pulseaudio ( https://wiki.debian.org/PulseAudio )

3. amixer able to find usb sound card

4. lsmod | grep snd_usb_audio ( just making sure that snd_usb_audio is loaded )

5. We need to add our user ( root and other if You want ) to audio group

usermod -a -G audio root

6. Setting the default device

https://www.alsa-project.org/wiki/Setting_the_default_device

Цитата

 

Find your desired card with:

   cat /proc/asound/cards

and then create /etc/asound.conf with following:

   defaults.pcm.card 1
   defaults.ctl.card 1

Replace "1" with number of your card determined above.

 

and reboot the system. Then login again via SSH.

7. Type in console

modprobe snd-pcm-oss

Then add to  /etc/modules ( from new line ) snd-pcm-oss
or to /etc/rc.local

modprobe snd-pcm-oss

8. At this moment You should have /dev/dsp or /dev/dsp1
You can type

ln -s /dev/dsp1 /dev/dsp

to make available sound card for cmus
 ( otherwise cmus answer with error: opening audio device: No such device  ) You can also, if You want, add to /etc/rc.local ln -s /dev/dsp1 /dev/dsp
by doing this, it will add a link from /dev/dsp1 to /dev/dsp during boot process

At this moment, your mocp should play.

9. Next step is copy config from /usr/share/doc/moc/examples/config.example
to ~./.moc/config
and then edit this file to this proposed setting:

Цитата

OSSDevice = /dev/dsp1 ( or whatever it is, it can be also a /dev/dsp )
InputBuffer = 1024
OutputBuffer = 1024
Prebuffering = 170

Save and close the file.

Now you can run mocp and play some file or radio.
Also, from this moment alsamixer works without arguments.

I am trying to use a Waveshare e-Paper (2.9") with an Orange Pi Zero LTS. To enable the SPI interface, I have added this to /boot/armbianEnv.txt:

overlays=spi-add-cs1 spi-spidev
param_spidev_spi_bus=1
param_spidev_max_freq=10000000

and installed WiringPI from Github. The e-Paper module is connected to the following GPIO pins:

VCC: 3.3V
GND: GND
DIN: 19(phys)/11(wPi)
CLK: 23(phys)/14(wPi)
CS: 24(phys)/15(wPi)
DC: 22(phys)/13(wPi)
RST: 3(phys)/0(wPi)
BUSY: 5(phys)/1(wPi)

I have checked the connections by using the gpio command line tool to set all 6 ports above to low and to high, and verifying the output with a multimeter.

Then I downloaded the e-Paper software from Github, and made it compatible with the Orange Pi via the following changes to lib/Config/DEV_Config.c:

1. In DEV_Equipment_Testing(void), comment out the code that checks if the file /etc/issue contains the string "Raspian"
2. Set EPD_RST_PIN=0, EPD_DC_PIN=13, EPD_CS_PIN=15, EPD_BUSY_PIN=1.
3. Uncomment "if(wiringPiSetup() < 0)", add a curly open brace, and comment out the line after.
4. Change "wiringPiSPISetup(0,10000000);" into "wiringPiSPISetup(1,10000000);" to use spidev1.0

When I run this e-Paper example, nothing happens on the e-Paper display, although I can detect voltage changes on the GPIO ports with a multimeter. The same software works on a Raspberry Pi without problems. Any hints are appreciated!

Benchmarks

Board                  | SBC-Bench              | Distro                             | Clockspeeds         | 7z all cores  | 7z small core   | 7z big core   | CPU-Miner   | NicoD-Blender      | Max temp      | C copy backwards      
NanoPi M4 2GB            http://ix.io/3xnJ        Armbian Hirsute xfce4 5.13.12        1.4Ghz/1.8Ghz         7760            1267              1857            10.05         14m41s                 78C    ***    1782.9 MB/s
NanoPi M4 2GB            http://ix.io/3xv3        Armbian Hirsute xfce4 5.13.12        1.5Ghz/2Ghz           8288            1348              2070            10.95         13m21s                        ***    1806.7 MB/s
NanoPi M4 2GB            http://ix.io/3xs3        Armbian Hirsute cinnamon 5.13.12     1.4Ghz/1.8Ghz         7766            1267              1851            10            14m33s                 78C           1742.6 MB/s
NanoPi M4 2GB            http://ix.io/3xt0        Armbian Hirsute budgie 5.13.12       1.4Ghz/1.8Ghz         7941            1272              1863            10.05         14m24s/14m18s          78C           1738.3 MB/s
NanoPi M4 2GB            http://ix.io/3xtR        Armbian Buster xfce4 4.4.213         1.5Ghz/2Ghz           8383            1359              1982            10.8          14m17s                               1377.3 MB/s
NanoPi M4 2GB            http://ix.io/3xuf        Armbian Buster xfce4 4.4.213         1.4Ghz/1.8Ghz         7879            1278              1807            10            15m20s                               1392.3 MB/s           
NanoPi M4 2GB            http://ix.io/3xux        Armbian Focal xfce4 5.10.60          1.4Ghz/1.8Ghz         8028            1286              1859            10.27         13m29s                         ***   1765.3 MB/s
NanoPi M4 2GB            http://ix.io/3xuL        Armbian Focal xfce4 5.10.60          1.5Ghz/2Ghz           8427            1351              2076            11.2          12m53s                         ***   1759.9 MB/s
NanoPi M4 2GB            http://ix.io/3EDB        Ubuntu Xenial armhf 4.4 xfce4        1.4Ghz/1.8Ghz         7069            1140              1695                                                               1387.1 MB/s

Board                  | SBC-Bench              | Distro                             | Clockspeeds         | 7z all cores  | 7z small core   | 7z big core   | CPU-Miner   | NicoD-Blender         | Max temp
Odroid C4/HC4            http://ix.io/2LaP        Ubuntu Mate 4.9                      1.91Ghz               7000            1769                              7.2 kH/s                                           2087.5 MB/s
Odroid C4/HC4            http://ix.io/3F6z        Armbian Buster 5.9                   2.10Ghz               7971            2030                              7.9           23m02s                               2020.0 MB/s
Khadas VIM3                                       Armbian Hirsute cinnamon 5.13.12                                                                                           12m55s

Board                  | SBC-Bench              | Distro                             | Clockspeeds         | 7z all cores  | 7z small core   | 7z big core   | CPU-Miner   | NicoD-Blender         | Max temp
Raspberry Pi4            http://ix.io/3F6o        Armbian Jammy 5.13                   2Ghz                  8047                              2070             Didn't work  Blender doens't work                 2054.3 MB/s
Raspberry Pi4            http://ix.io/3F6K        Armbian Jammy 5.13                   1.5Ghz                6239                              1572                                                               2556.8 MB/s      
Raspberry Pi4                                     Armbian Hirsute edge xfce4 5.11      1.5Ghz                5832                              1534                          18m11s                   60C
Raspberry Pi4            http://ix.io/3Euw        Armbian Hirsute edge xfce4 5.11      2Ghz                  7747                              2037             9.8          14m26s                   68C         2382.2 MB/s
Raspberry Pi4            http://ix.io/3FbW        Armbian Hirsute 5.11 OC GPU+CPU      2.1Ghz                8168                              2147                          Blender crash                        2445.0 MB/s  
Raspberry Pi4            http://ix.io/3EU7        Armbian Impish edge headless 5.13    1.5Ghz                6251                              1584                          15m39s                               2618.0 MB/s
Raspberry Pi4            http://ix.io/3Ewi        Armbian Impish edge headless 5.13    2Ghz                  8171                              2093                          12m41s                               2713.7 MB/s
Raspberry Pi4            http://ix.io/3EPQ        Armbian Bullseye edge headless 5.13  1.5Ghz                6328                              1594             7.3          Blender doesn't work                 2680.5 MB/s
Raspberry Pi4            http://ix.io/3EK9        Armbian Bullseye edge headless 5.13  2Ghz                  8242                              2096             9.7          Blender doesn't work                 2505.4 MB/s
Raspberry Pi4            http://ix.io/3ECd        Raspberry Pi OS Bullseye 32-bit      1.5Ghz                7577                              1933                          21m09s                               2511.7 MB/s
Raspberry Pi4            http://ix.io/3ECt        Raspberry Pi OS Bullseye 32-bit      2Ghz                  9746                              2533                          17m05s                               2263.0 MB/s
Raspberry Pi4            http://ix.io/3EIe        Raspberry Pi OS Bullseye 64-bit      1.5Ghz                6174                              1567             7.2          17m01s                               2463.5 MB/s
Raspberry Pi4            http://ix.io/3EJs        Raspberry Pi OS Bullseye 64-bit      2Ghz                  8026                              2053             9.65         Blender unstable at 2Ghz             2326.1 MB/s
Raspberry Pi4            http://ix.io/3EGZ        Ubuntu 21.10 (Impish) 5.13 arm64     1.5Ghz                6160                              1563                          16m50s                               2421.2 MB/s
Raspberry Pi4            http://ix.io/3EHA        Ubuntu 21.10 (Impish) 5.13 arm64     2Ghz                  7965                              2038             Didn't work  Blender unstable at 2Ghz             2501.9 MB/s

Board                  | SBC-Bench              | Distro                             | Clockspeeds         | 7z all cores  | 7z small core   | 7z big core   | CPU-Miner   | NicoD-Blender         | Max temp
RPi400                   http://ix.io/3HLw        Armbian Jammy Edge 5.15.7 cinnamon   2Ghz o.v. 6           7913                              2085                          19m34s                  69C          2224.5 MB/s 
RPi400                   http://ix.io/3HSI        Armbian Impish current 5.13.0 cin    2Ghz o.v. 6           7869                              2104                          14m20s                  63C          2443.5 MB/s 
RPi400                   http://ix.io/3HTx        Armbian Impish current 5.13.0 cin    2.1Ghz + 700GPU o.v.6 6930                              2069                          13m27s                  65C          1500.0 MB/s
RPi400                   http://ix.io/3HTR        Armbian Impish current 5.13.0 cin    2.1Ghz o.v.6          8188                              2205                          14m03s                  65C          2450.4 MB/s
RPi400                   http://ix.io/3HMm        RPiOS bullseye armhf 5.10.63         1.8Ghz                8705                              2350                          18m46s                  55C          2390.5 MB/s 
RPi400                   http://ix.io/3HRl        RPiOS bullseye armhf 5.10.63         2Ghz o.v. 4           9834                              2601                          17m07s                  61C          2455.0 MB/s 
RPi400                                            Manjaro KDE 5.10                     1.8Ghz                7426                              1886                          14m28s                  58C
RPi400                   http://ix.io/3IgG        Manjaro KDE 5.10                     2Ghz                  8156                              2092                          13m16s                  65C          2473.3 MB/s

Board                  | SBC-Bench              | Distro                             | Clockspeeds         | 7z all cores  | 7z small core   | 7z big core   | CPU-Miner   | NicoD-Blender         | Max temp
Odroid N2+               http://ix.io/3EwQ        Armbian Impish xfce4 5.14            2Ghz/2.4Ghz           11714           1765              2517                           8m51s                               2053.0 MB/s

Additional info

Power consumption
-----------------
No wifi/on-board sd-card reader idle               0.45A
Wifi-on-board sd-card reader idle 2Ghz ov 6        0.5A
Wifi-on-board sd-card reader maxed out 2Ghz ov 6   1.3A
Wifi-USB3SD idle 2Ghz ov 6                         0.75A-0.9A
Wifi-USB3SD idle 1.8Ghz                            0.75A-0.9A
Wifi-on-board sd-card reader idle 1.8Ghz           0.5A
Wifi-on-board sd-card reader maxed out 1.8Ghz      1.1A
Wifi-USB3SD maxed out 1.8Ghz                       1.3A 

 
Official Armbian Jammy Nightly 5.15 has no GPU acceleration
Images from RPardini do have GPU acceleration, but no sound

Manjaro KDE is nice. Works well, except video playback in browser. Max 720p.

++ Good cooling solution, doesn't overheat even at high overclocks
++ the Pi 400 is the first in the line of Raspberry Pi products to have an on/off power button
   This is done by pressing Fn+F10. To restore power, you press the pair of buttons for two seconds
++ Default clock of 1.8Ghz vs 1.5Ghz on RPi4 performs 20% better. OC to 2Ghz 30% more performance than 1.5Ghz

-- Bad keyboard
-- Bad arrangement of the cursor keys
-- SD-card reader still rather slow with max 45MB/s. Better to use a sd->USB3 adapter for fast sd-cards
-- Still the undervoltage problem as with all other RPi devices when using a normal PSU. PSU's that deliver 5.3V perform best.

*** GPU overclock makes it perform worse
*** SD-card slot isn't very fast 45MB/s vs 90MB/s with the same card in sd->USB3 adapter

This is my first topic here. To help myself in the future I did a guide to adjust armbian configuration and settings. This guide contains topics like:

• Maintaining the board updated
• Adjusting personal settings (keyboard, timezone, locale)
• Setting the sound output (default sound output to HDMI)
• Disable the desktop environment
• Setting the numlock to "ON" at start up
• Dealing with 4k video resolution

It was based on my experience dealing with Orangepi PC (H3), but many things could be reused to others boards.

I hope this guide may be helpful: https://github.com/lbmendes/armbian-settings/blob/main/README.md

In this episode @lanefu explains what he does for Armbian, what gear he uses, and why. It is a must see video.
Enjoy

We do need to find someone who wants to take the task on him/her to be maintainer for RaspberryPi4 at Armbian.
For this you need one spare board that can be used for testing when new release are made.
Here some info I gathered.

 

Raspberry Pi 4 cooled with big heatsink on SoC and fan on-top

Board                  | SBC-Bench              | Distro                             | Clockspeeds         | 7z all cores  | 7z small core   | 7z big core   | CPU-Miner   | NicoD-Blender      | Max temp      | C copy backwards      
NanoPi M4 2GB            http://ix.io/3xnJ        Armbian Hirsute xfce4 5.13.12        1.4Ghz/1.8Ghz         7760            1267              1857            10.05         14m41s                 78C    ***    1782.9 MB/s
NanoPi M4 2GB            http://ix.io/3xv3        Armbian Hirsute xfce4 5.13.12        1.5Ghz/2Ghz           8288            1348              2070            10.95         13m21s                        ***    1806.7 MB/s
NanoPi M4 2GB            http://ix.io/3xs3        Armbian Hirsute cinnamon 5.13.12     1.4Ghz/1.8Ghz         7766            1267              1851            10            14m33s                 78C           1742.6 MB/s
NanoPi M4 2GB            http://ix.io/3xt0        Armbian Hirsute budgie 5.13.12       1.4Ghz/1.8Ghz         7941            1272              1863            10.05         14m24s/14m18s          78C           1738.3 MB/s
NanoPi M4 2GB            http://ix.io/3xtR        Armbian Buster xfce4 4.4.213         1.5Ghz/2Ghz           8383            1359              1982            10.8          14m17s                               1377.3 MB/s
NanoPi M4 2GB            http://ix.io/3xuf        Armbian Buster xfce4 4.4.213         1.4Ghz/1.8Ghz         7879            1278              1807            10            15m20s                               1392.3 MB/s           
NanoPi M4 2GB            http://ix.io/3xux        Armbian Focal xfce4 5.10.60          1.4Ghz/1.8Ghz         8028            1286              1859            10.27         13m29s                         ***   1765.3 MB/s
NanoPi M4 2GB            http://ix.io/3xuL        Armbian Focal xfce4 5.10.60          1.5Ghz/2Ghz           8427            1351              2076            11.2          12m53s                         ***   1759.9 MB/s
NanoPi M4 2GB            http://ix.io/3EDB        Ubuntu Xenial armhf 4.4 xfce4        1.4Ghz/1.8Ghz         7069            1140              1695                                                               1387.1 MB/s

Board                  | SBC-Bench              | Distro                             | Clockspeeds         | 7z all cores  | 7z small core   | 7z big core   | CPU-Miner   | NicoD-Blender         | Max temp
Odroid C4/HC4            http://ix.io/2LaP        Ubuntu Mate 4.9                      1.91Ghz               7000            1769                              7.2 kH/s                                           2087.5 MB/s
Odroid C4/HC4            http://ix.io/3F6z        Armbian Buster 5.9                   2.10Ghz               7971            2030                              7.9           23m02s                               2020.0 MB/s
Khadas VIM3                                       Armbian Hirsute cinnamon 5.13.12                                                                                           12m55s

Raspberry Pi4            http://ix.io/3F6o        Armbian Jammy 5.13                   2Ghz                  8047                              2070             Didn't work  Blender doens't work                 2054.3 MB/s
Raspberry Pi4            http://ix.io/3F6K        Armbian Jammy 5.13                   1.5Ghz                6239                              1572                                                               2556.8 MB/s      
Raspberry Pi4                                     Armbian Hirsute edge xfce4 5.11      1.5Ghz                5832                              1534                          18m11s                   60C
Raspberry Pi4            http://ix.io/3Euw        Armbian Hirsute edge xfce4 5.11      2Ghz                  7747                              2037             9.8          14m26s                   68C         2382.2 MB/s
Raspberry Pi4            http://ix.io/3FbW        Armbian Hirsute 5.11 OC GPU+CPU      2.1Ghz                8168                              2147                          Blender crash                        2445.0 MB/s  
Raspberry Pi4            http://ix.io/3EU7        Armbian Impish edge headless 5.13    1.5Ghz                6251                              1584                          15m39s                               2618.0 MB/s
Raspberry Pi4            http://ix.io/3Ewi        Armbian Impish edge headless 5.13    2Ghz                  8171                              2093                          12m41s                               2713.7 MB/s
Raspberry Pi4            http://ix.io/3EPQ        Armbian Bullseye edge headless 5.13  1.5Ghz                6328                              1594             7.3          Blender doesn't work                 2680.5 MB/s
Raspberry Pi4            http://ix.io/3EK9        Armbian Bullseye edge headless 5.13  2Ghz                  8242                              2096             9.7          Blender doesn't work                 2505.4 MB/s
Raspberry Pi4            http://ix.io/3ECd        Raspberry Pi OS Bullseye 32-bit      1.5Ghz                7577                              1933                          21m09s                               2511.7 MB/s
Raspberry Pi4            http://ix.io/3ECt        Raspberry Pi OS Bullseye 32-bit      2Ghz                  9746                              2533                          17m05s                               2263.0 MB/s
Raspberry Pi4            http://ix.io/3EIe        Raspberry Pi OS Bullseye 64-bit      1.5Ghz                6174                              1567             7.2          17m01s                               2463.5 MB/s
Raspberry Pi4            http://ix.io/3EJs        Raspberry Pi OS Bullseye 64-bit      2Ghz                  8026                              2053             9.65         Blender unstable at 2Ghz             2326.1 MB/s
Raspberry Pi4            http://ix.io/3EGZ        Ubuntu 21.10 (Impish) 5.13 arm64     1.5Ghz                6160                              1563                          16m50s                               2421.2 MB/s
Raspberry Pi4            http://ix.io/3EHA        Ubuntu 21.10 (Impish) 5.13 arm64     2Ghz                  7965                              2038             Didn't work  Blender unstable at 2Ghz             2501.9 MB/s

Odroid N2+               http://ix.io/3EwQ        Armbian Impish xfce4 5.14            2Ghz/2.4Ghz           11714           1765              2517                           8m51s                               2053.0 MB/s

Raspberry Pi4 SD->USB3 with SandDisk Extreme                           89.7 MB/s read     
              SD with on-board sd-card reader Sandisk Extreme          45.4 MB/s read (rather slow compared to 70MB/s for M4)

RPi4 fastest memory, then N2+, then M4(lpddr3)

Armbian Impish                                 2.93.5
Raspberry Pi OS Bulsseye 32-bit/64-bit blender 2.83.5
Ubuntu 21.10 Blender                           2.93.3
Armbian Jammy Blender goesn't work / bug 

*** Ubuntu 21.10 unstable when installing ubuntu-mate-desktop, Unity very slow

Armbian on RPi4 pro's
+ Having the same platform for RPi and other Armbian supported boards
+ Reliability/ stable
+ ARM64 vs armhf of RaspberryPiOS/Ubuntu unstable at high clocks and a lot of bugs and hangs
+ Ubuntu and Debian images and all their versions
+ Great for server tasks
+ Customizable
+ You can build your own RPi4 images with whatever modules you need

Armbian on RPi4 con's
- Not great for desktop use (yet)
- No VPU drivers, video playback firefox ok up to 720p
- Audio glitchy, no audio on some images like Jammy 
 
*** For audio install pavucontrol
*** On-board wifi and dongles don't work with the Armbian Impish and Bullseye images. Dongles work on Hirsute. I guess kernel issue 5.13 -> 5.11
*** Armbian Bullseye 5.13 USB not always working

Install desktops
sudo apt install xfce4 (ubuntu-mate-desktop, kubuntu-desktop, lubuntu-desktop, ubuntu-desktop, ...)
sudo apt install lightdm
sudo apt install lightdm-gtk-greeter
sudo apt install pavucontrol
sudo apt install xinit

Power draw at 5.3V headless 
1.5Ghz with fan maxed out        0.95A 
2Ghz with fan maxed out          1.10A

To do 
- M4 Impish
- Gather the info I've got from other boards and my pc's

And for those who don't like watching a video, here a short text of what I talk about.

 

What is Armbian? What is the Armbian build framework which is one of the valued pro's compared to RPiOS?
Why Armbian for RPi4? For software compatibillity with other Armbian supported SBCs, Reliabillity, ARM64, Ubuntu and Debian and their versions, great for server tasks... 
Accentuate this is only a preview, not full release or supported
Show Armbian download page
Show the NanoPi M4 and Odroid N2+, talk about their specs(short)
Difference between other SBCs and RPi/ThreadX - Under Voltage problems/eMMC and NVMe possible on others(better I/O)
What doesn't work yet on Armbian for RPi4. Wifi, BT and HDMI sound
Show Armbian Impish, show htop, install desktops, 
Benchmarks between different OS's. Explain they aren't worth much since, different versions of software, different architecture armhf vs arm64, 7zip multicore doesn't play well on different sized clusters, and doesn't always give exact the same result...
!!!Test the performance of the software you use to know if this is the correct tool for you!!!
Show different desktop environments installed on Armbian - Not the Armbian default desktops - mate doesn't work great, xfce4 works ok, kde works but is slow(newer version should improve that soon)Change openGL2->OpenGL3, ...
Performance of I/O. Better to use a good but cheap usb3 sd-card reader than on-board sd-card reader. ssd/NVMe->USB3 even better.
???Would you like to become RPi4 Armbian maintainer??? Or for another board???
Conclusion. Good for RPi community to have even more choice. Good for Armbian community to be able to use the same software on their RPi devices as on their others. Good for Armbian to reach more people and have more awareness about other boards. Having a good build environment to build your own images/kernels/patches for the RPi4.

I test mine on orange pi zero. The one I am able to get working is ili9341 and st7735 based lcd.

I'll add more detail later but for now I'd like to get this out.

edit 1 :
Adding ssd1306 and nokia 5110 overlay to the repo

device tree overlay

So never quite got my 3.5 mm audio jack working properly on my M4V2 (though others reportedly did). But did find a way to get audible tones from the PWM fan control by playing with the PWM period, so decided to see if I could get music out of my M4V2 in another way ...

What follows is interesting exploration of:

• Finding interesting ways to repurpose NanoPi M4 Cases
• Loading MIDI files in python3
• Brushing up on music theory
• Finding some free and appropriate Halloween Music

$ sudo install pip3
$ sudo pip3 install MIDIFile
$ sudo ./fanplay.py Bach.\ Johann\ Sebastian\ -\ Toccata\ And\ Fugue\ \(Bwv\ 565\)___WWW.MIDISFREE.COM.mid

This little diversion brought to you by:

• Armbian
• FriendlyElec
• Python
• A few spare hours on a weekend

Might try to play around with this a bit more at some point. Notably does not play Backstreet Boys (was asked to try). But does more or less work, at least on this one track.

Enjoy

fanplay.py

• ESP32
• KOB electronic lock
• Relay
• STONE STWI070WT-01 display
• MFRC522 module

Realized function

1. card registration.
2. username and password registration.
3. card swipe to unlock the electronic lock.
4. User name and password to unlock the electronic lock.

Connection diagram

GUI design

Code sharing

import mfrc522
import time
import _thread
from os import uname
from machine import Pin, UART
#from pyb import UART
#import machine

suos = Pin(32,Pin.OUT)
uart2 = UART(2, baudrate=115200, rx=16,tx=17,timeout=10)

ESP32_HSPI_CLOCK = 14
ESP32_HSPI_SLAVE_SELECT = 15
ESP32_HSPI_MISO = 12
ESP32_HSPI_MOSI = 13
ESP32_MFRC522_RST = 5

rx3 = []
rx_name = []
user_id_flag = False
password_flag = False
temp_id = ''
temp_mima = ''
personnel_id = {'zbw':[236,230,169,47],'lbw':[19,165,93,4]}
personnel_ps = {'zbw':'zbw3366','lbw':'lbwnb'}
admin_password = ('yyds')
button_cmd = [16,1]
edit1_cmd = [16,112]
edit2_cmd = [16,113]
edit3_cmd = [16,114]

if uname()[0] == 'esp32':
	rdr = mfrc522.MFRC522(ESP32_HSPI_CLOCK, ESP32_HSPI_MOSI, ESP32_HSPI_MISO, ESP32_MFRC522_RST, ESP32_HSPI_SLAVE_SELECT)

def do_write():
	try:
		(stat, tag_type) = rdr.request(rdr.REQIDL)
		if stat == rdr.OK:
			(stat, raw_uid) = rdr.anticoll()
			if stat == rdr.OK:
				print("New card detected")
				print("  - tag type: 0x%02x" % tag_type)
				print("  - uid : 0x%02x%02x%02x%02x" % (raw_uid[0], raw_uid[1], raw_uid[2], raw_uid[3]))
				print("")
				if rdr.select_tag(raw_uid) == rdr.OK:
					key = [0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF]
					if rdr.auth(rdr.AUTHENT1A, 8, key, raw_uid) == rdr.OK:
						stat = rdr.write(8, b"\x00\x53\x00\x54\x00\x4F\x00\x4E\x00\x45\x0a\x0b\x0c\x0d\x0e\x0f")
						rdr.stop_crypto1()
						if stat == rdr.OK:
							print("Data written to card")
						else:
							print("Failed to write data to card")
					else:
						print("Authentication error")
				else:
					print("Failed to select tag")

	except KeyboardInterrupt:
		print("write error")


def do_read():
	while True:
		try:
			(stat, tag_type) = rdr.request(rdr.REQIDL)

			if stat == rdr.OK:
				(stat, raw_uid) = rdr.anticoll()
				if stat == rdr.OK:
					print("New card detected")
					print("  - tag type: 0x%02x" % tag_type)
					print("  - uid   : 0x%02x%02x%02x%02x" % (raw_uid[0], raw_uid[1], raw_uid[2], raw_uid[3]))
					print (raw_uid[0], raw_uid[1], raw_uid[2], raw_uid[3])
					print("")
					if rdr.select_tag(raw_uid) == rdr.OK: 
						key = [0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF]
						if rdr.auth(rdr.AUTHENT1A, 8, key, raw_uid) == rdr.OK:
							print("Address 8 data: %s" % rdr.read(8))
							for ps in personnel_id:
								if raw_uid[0:4:1] == personnel_id.get(ps):
									suos.value(1)
									print(ps)
									uart_write(ps, *raw_uid[0:4:1])
									time.sleep(3)
									uart2.sendbreak()
									break
							rdr.stop_crypto1()
							time.sleep(3)
							suos.value(0)
						else:
							print("Authentication error")
					else:
						print("Failed to select tag")
			if uart2.any()>1:
				rx2 = []
				data_name2 = ''
				bin_data = uart2.read(40)
				uart2.sendbreak()
				rx1 = list(bin_data)
				for item in rx1:
					rx2.append(chr(item))
				print(rx2)
				if rx1[3:5:1] == button_cmd:
					data_name_len = rx1[6] - 1
					data_name = rx2[7:data_name_len+7:1]
					data_name2 = ''.join(data_name)
					print(data_name2)
					if data_name2 == 'back3':
						return
		except KeyboardInterrupt:
			print("read error")

def do_read2 (idd):
	print(idd)
	while True:
		try:
			(stat, tag_type) = rdr.request(rdr.REQIDL)

			if stat == rdr.OK:
				(stat, raw_uid) = rdr.anticoll()
				if stat == rdr.OK:
					print("New card detected")
					print("  - tag type: 0x%02x" % tag_type)
					print("  - uid   : 0x%02x%02x%02x%02x" % (raw_uid[0], raw_uid[1], raw_uid[2], raw_uid[3]))
					print (raw_uid[0], raw_uid[1], raw_uid[2], raw_uid[3])
					print("")
					if rdr.select_tag(raw_uid) == rdr.OK: 
						key = [0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF]
						if rdr.auth(rdr.AUTHENT1A, 8, key, raw_uid) == rdr.OK:
							print("Address 8 data: %s" % rdr.read(8))
							personnel_id[idd] = raw_uid[0:4:1]
							uart_write3(*raw_uid[0:4:1])
							rdr.stop_crypto1()
						else:
							print("Authentication error")
					else:
						print("Failed to select tag")
			if uart2.any()>1:
				rx2 = []
				data_name2 = ''
				bin_data = uart2.read(40)
				uart2.sendbreak()
				rx1 = list(bin_data)
				for item in rx1:
					rx2.append(chr(item))
				if rx1[3:5:1] == button_cmd:
					data_name_len = rx1[6] - 1
					data_name = rx2[7:data_name_len+7:1]
					data_name2 = ''.join(data_name)
					print(data_name2)
				if data_name2 == 'back1':
					return

		except KeyboardInterrupt:
			print("read error")

def uart_write(text, *ids):
#	print(text, *ids)
	uart2.write('ST<{"cmd_code":"set_text","type":"label","widget":"cardname1","text":"'+str(text)+'"}>ET')
	uart2.write('ST<{"cmd_code":"set_text","type":"label","widget":"cardid1","text":"'+str(ids)+'"}>ET')
	uart2.write('ST<{"cmd_code":"set_visible","type":"widget","widget":"lock1","visible":true}>ET')
	time.sleep(3)
	uart2.write('ST<{"cmd_code":"set_text","type":"label","widget":"cardname1","text":"''"}>ET')
	uart2.write('ST<{"cmd_code":"set_text","type":"label","widget":"cardid1","text":"''"}>ET')
	uart2.write('ST<{"cmd_code":"set_visible","type":"widget","widget":"lock1","visible":false}>ET')

def uart_write2(text,text2):
	uart2.write('ST<{"cmd_code":"set_text","type":"label","widget":"cardid","text":"'+text+'"}>ET')
	time.sleep(3)
	uart2.write('ST<{"cmd_code":"set_text","type":"label","widget":"cardid","text":"'+text2+'"}>ET')
	uart2.write('ST<{"cmd_code":"set_text","type":"label","widget":"edit2","text":"''"}>ET')

def uart_write3(*id2):
	uart2.write('ST<{"cmd_code":"set_text","type":"label","widget":"cardid","text":"'+str(id2)+'"}>ET')
	time.sleep(3)
	uart2.write('ST<{"cmd_code":"set_text","type":"label","widget":"cardid","text":"''"}>ET')

def uart_write4(text,text2):
	uart2.write('ST<{"cmd_code":"set_text","type":"label","widget":"login","text":"'+text+'"}>ET')
	time.sleep(1)
	uart2.write('ST<{"cmd_code":"set_text","type":"label","widget":"login","text":"'+text2+'"}>ET')
	time.sleep(1)
	uart2.write('ST<{"cmd_code":"set_text","type":"label","widget":"edit3","text":"''"}>ET')
	uart2.write('ST<{"cmd_code":"set_text","type":"label","widget":"edit4","text":"''"}>ET')
	uart2.write('ST<{"cmd_code":"set_text","type":"label","widget":"edit7","text":"''"}>ET')

def uart_write5():
	uart2.write('ST<{"cmd_code":"set_text","type":"label","widget":"cardid","text":"'+str(id2)+'"}>ET')
	time.sleep(3)
	uart2.write('ST<{"cmd_code":"set_text","type":"label","widget":"cardid","text":"''"}>ET')

def card_zhuce():
	while True:
		if uart2.any():
			user_id = ''
			password = ''
			rx2 = []
			rx_num = 0
			bin_data = uart2.read(40)
			uart2.sendbreak()
			rx1 = list(bin_data)
			for item in rx1:
				rx2.append(chr(item))
				rx_num += 1
			data_end = rx_num-5
			data_id_st = rx2[8:13:1]
			data_id_st2 = ''.join(data_id_st)
			print(data_id_st2)
			if data_id_st2 == 'edit1':
				data_id_st3 = rx2[15:data_end:1]
				data_id_st4 = ''.join(data_id_st3)
				print(data_id_st4)
				if data_id_st4 != '':
					name = True
			elif data_id_st2 == 'edit2':
				data_id_st5 = rx2[15:data_end:1]
				data_id_st6 = ''.join(data_id_st5)
				if data_id_st6 == admin_password:
					admin = True
					uart_write2('Verification passed!','Please place the card!')
					do_read2(data_id_st4)
					return

def mima_zuce():
	temp_id3 = ''
	temp_mima3 = ''
	while True:
		if uart2.any():
			user_id = ''
			password = ''
			rx2 = []
			rx_num = 0
#			data_end = 0
			bin_data = uart2.read(40)
			uart2.sendbreak()
			rx1 = list(bin_data)
			for item in rx1:
				rx2.append(chr(item))
				rx_num += 1
#				if (rx2[rx_num] == 'T') and (rx2[rx_num-1] == 'E') and (rx2[rx_num-2] == '>'):
#					break
			data_end = rx_num-5
			data_id_st = rx2[8:13:1]
			data_id_st2 = ''.join(data_id_st)
			print(data_id_st2)
			if rx1[3:5:1] == button_cmd:
				data_name_len = rx1[6] - 1
				data_name = rx2[7:data_name_len+7:1]
				data_name2 = ''.join(data_name)
				print(data_name2)
				if data_name2 == 'back2':
					return
			if data_id_st2 == 'edit3':
				data_id_st3 = rx2[15:data_end:1]
				data_id_st4 = ''.join(data_id_st3)
				print(data_id_st4)
				user_id_flag = True
				temp_id3 = data_id_st4
#				personnel_ps[temp_id] = raw_uid[0:4:1]
			elif data_id_st2 == 'edit4':
				data_id_st5 = rx2[15:data_end:1]
				data_id_st6 = ''.join(data_id_st5)
				print(data_id_st6)
#				if personnel_ps.get(temp_id) == data_id_st6:
				password_flag = True
				temp_mima3 = data_id_st6
#					personnel_ps[temp_id] = password_flag

#			print(rx2,user_id_flag,password_flag)

			elif data_id_st2 == 'edit7':
				data_id_st5 = rx2[15:data_end:1]
				data_id_st6 = ''.join(data_id_st5)
				if (data_id_st6 == admin_password) and (password_flag == True) and (user_id_flag == True):
					admin = True
					personnel_ps[temp_id3] = temp_mima3
					password_flag = False
					user_id_flag = False
					uart_write4('Verification passed!','login was successful!')


def password_loin():
	temp_id2 = ''
	temp_mima = ''
	while True:
		if uart2.any():
			user_id = ''
			password = ''
			rx2 = []
			rx_num = 0
#			data_end = 0
			bin_data = uart2.read(40)
			uart2.sendbreak()
			rx1 = list(bin_data)
			for item in rx1:
				rx2.append(chr(item))
				rx_num += 1
#				if (rx2[rx_num] == 'T') and (rx2[rx_num-1] == 'E') and (rx2[rx_num-2] == '>'):
#					break
			data_end = rx_num-5
			data_id_st = rx2[8:13:1]
			data_id_st2 = ''.join(data_id_st)
			print(data_id_st2)
			if rx1[3:5:1] == button_cmd:
				data_name_len = rx1[6] - 1
				data_name = rx2[7:data_name_len+7:1]
				data_name2 = ''.join(data_name)
				print(data_name2)
				if data_name2 == 'back4':
					return
			if data_id_st2 == 'edit5':
				data_id_st3 = rx2[15:data_end:1]
				data_id_st4 = ''.join(data_id_st3)
				print(data_id_st4)
				if data_id_st4 in personnel_ps:
					user_id_flag = True
					temp_id2 = data_id_st4
			elif data_id_st2 == 'edit6':
				data_id_st5 = rx2[15:data_end:1]
				data_id_st6 = ''.join(data_id_st5)
				print(data_id_st6)
				print(temp_id2)
				print(personnel_ps)
				if personnel_ps.get(temp_id2) == data_id_st6:
					password_flag = True

#			print(rx2,user_id_flag,password_flag)
					print(user_id_flag,password_flag)
					if (password_flag == True) and (user_id_flag == True):
						uart_write(temp_id2,temp_id2)
						password_flag = False
						user_id_flag = False
						suos.value(1)
						uart2.write('ST<{"cmd_code":"set_visible","type":"widget","widget":"lock2","visible":true}>ET')
						uart2.write('ST<{"cmd_code":"set_text","type":"label","widget":"edit5","text":"''"}>ET')
						uart2.write('ST<{"cmd_code":"set_text","type":"label","widget":"edit6","text":"''"}>ET')
						time.sleep(3)
#						uart_write('student','')
						suos.value(0)
						uart2.write('ST<{"cmd_code":"set_visible","type":"widget","widget":"lock2","visible":false}>ET')
						uart2.sendbreak()

while True:
	if uart2.any()>1:
		rx2 = []
		data_name2 = ''
		bin_data = uart2.read(40)
#		time.sleep(1)
		uart2.sendbreak()
#		time.sleep(1)
		rx1 = list(bin_data)
		for item in rx1:
			rx2.append(chr(item))
		print(rx2)
		if rx1[3:5:1] == button_cmd:
			data_name_len = rx1[6] - 1
			data_name = rx2[7:data_name_len+7:1]
			data_name2 = ''.join(data_name)
			print(data_name2)
			if data_name2 == 'card1':
				card_zhuce()
			elif data_name2 == 'password1':
				mima_zuce()
			elif data_name2 == 'card2':
				do_read()
			elif data_name2 == 'password2':
				password_loin()

Video demo

First afore, allow me to express my gratitude to all developers working on Armbian tirelessly.

It is amazing how much I can achieve nowadays on these little Arm-based boxes, either SBC or repurposed Android TV box.

This in my first tutorial submitted on Armbian forum, as I would like to contribute something back.

I will update this post further when I am getting more familiar w/ Armbian & running LibreOffice on it.

===========

Platform running:

SOC:         Allwinner H6

Device:      Tanix TX6 compatible TV box - UPDATE Apr 2022

                  ( Please check out the Allwinner H6 build by @awawa )

                    https://www.hyperhdr.eu/2022/02/tv-box-mania-ii-part-tanix-tx6.html )

See also discussion:

                  Ubuntu Hirsute XFCE Desktop 22.02.00 trunk build for Tanix TX6     

                  ( No End-user support ) 

===========

With the Panfrost GPU driver getting mainlined & become more and more mature ( eg, see this Collabora blog ),  my interest in using Armbian as my daily desktop driver has increased.   

So I would like to use this thread to post some tips I found related to desktop use on Armbian.

1.  Checking opensource panfrost driver is loaded:

See:  http://docs.linuxfactory.or.kr/guides/gpu_panfrost.html

lsmod | grep panfrost

panfrost               69632  3
gpu_sched          32768  1 panfrost
 

If you see "panfrost" as in above, then the opensource GPU driver is already loaded

2. LibreOffice screen artifact & fix

I discovered that on default setting:  LibreOffice on Armbian would exhibit screen overlay artifact, for instance, when another display window was in front of LibreOffice UI window (for example: a Terminal window displaying  htop ).  

Solution:    Enable Skia rendering support in LibreOffice

Tools > Options  ||  LibreOffice > View

      Check the box "Use Skia for all rendering".   

Click OK and relaunch LibreOffice.   Now all screen overlay artifact on LibreOffice would disappear.  This always makes LibreOffice usable under RDP connection [ see point 3 below ]

PS:   This tip probably would work on multiple SOC using Mali GPU chipset

         (See GPU with Panfrost support:  https://docs.mesa3d.org/drivers/panfrost.html )

3.  You can use armbian-config to enable RDP access from Windows or another Linux PC (running XRDP client).

      Just select

      Software > RDP

             (Enable remote desktop access from Windows)

     See more from this discussion thread:

I will update this post further if I find any additional tips, while playing with LibreOffice on Armbian.

Any advice and feedback is appreciated.

Recently I tried to use CC1101 Radio-boards to access with spidev0.0; this works after some research:

1. activate spidev in the /boot/armbianEnv.txt (important)

2. in armbian-config hardware activate spidev

in the downloaded test routines the speed of the spi is set too high (8000000)

3. set this down to 4000000

In addition: I need the interurpt functions of GDO0 and GDO2 in the next test program.

As Interrupts on wiringOP seems to work not on all GPIO-Pins you have to select PAxx for example

After the change of the code for this PA21 wPI-Pin 11, it works as expected

Michael

To activate panfrost :

 sudo add-apt-repository ppa:oibaf/graphics-drivers  
 sudo apt update
 sudo apt upgrade
 sudo reboot

Khadas VIM3 support is in the making. This also works on any other mainline image.
Greetings.
 

I thought, my requirements for a media server would be quite low/easy to fulfill:

• smooth playback of 1080p movies
• clean multichannel sound
• access to firefox

After testing all avaliable images on the rockpi, it was clear, that actually only LE offers exciting movie enjoyment. I had to realize, that my ideas are quite demanding after all.

So it was clear, I had to get the driver from radxa working on LE.

Why?

well, hardware design of rockpi4 with extension HATs is somehow stupid. The flat cable needs to go from plugged board below systemboard to HAT above system board, so sdcard could not be changed any more.

and as shown here:

sd-card cannot be used together with the tower. Only emmc-support for boot. But emmc module is not exchangeable.

That is why I had to start this odyssey.

I tested the driver with officially supported images:

• on debian (linaro) the driver could be installed and the fan runs. Neither button nor display works.
• on ubuntu driver install scripts tells, that nothing has to be done, but nothing works ootb. No fan, no button, no display
• on armbian or LE the install script reffers to the git archive.

I started with self compiled LE, but I'm not skilled to port lowlevel libraries to unknown system. Quite hard going

Then I discovered posting of PetrozPL and JackR. Both scripts worked on armbian - well, I had some problems, getting into it, but ...

anyway: trying the scripts on LE showed - no way. LE has no bash and busybox does not support arrays ...

So I researched, how I could drive the fan using only tools avaliable at LE. Unfortunately LE has no reasonable interpreter for scripting. Only python :(

I never wrote a line in python before!

I first had to check, whether the kernel of LE supports fan control. LE has no dtb-overlay support for rockpi. So had to change dtb manually like this:

• copy dtb-file to writable location
• decompile with dtc -I dtb -O dts -o rk3399-rock-pi-4a.dtb rk3399-rock-pi-4a.dts
• find sections named pwm@ff420000 and pwm@ff420010
• change status "disabled" into status = "okay"
• recompile dts with dtc -O dtb -o rk3399-rock-pi-4a.dtb -b O -@ rk3399-rock-pi-4a.dts
• copy dtb file back to original location (/flash)

After reboot, fan works as with armbian - so I could write my fan-driver. Now system was ready to assemble the tower.

I tested the driver with all other test images. Had to change code to work with older python releases and had some troubles with the button. But now driver runs stable and - as far as I can judge so far, where my driver does not run, other drivers will fail too.

Well, my work with LE had the background, that I could get multiboot into play. But that seems pretty impossible.

So I startet again researching, what could fulfill my ideas.

• Multimedia legacy - kodi works, movies are enjoyable. But no button support
• armbian current - no kodi, vlc works fine. Fan control works with button support
• debian/ubuntu - Fancontrol works with button support, but video playback is disgusting
• twisterOS - kodi works, movies are enjoyable, but no fan, no button

I like twisterOS and the gimmick with the circles, but the text was unreadable for me. So I tweaked the gimmick and now I have it usable on my desktop as well on plain armbian. Using armbian instead of twisterOS has the benefit, that I don't have to flood the boot media with rubbish I never use (like openoffice and all that gaming stuff)

Actually my armbian current looks like this:

or a bit busy with firefox:

So the open jobs (next steps) are:

• get multiboot into play (then I could use LE together with armbian)
• get another kernel on twisteros, that supports pwm - then I could use twisteros
• get a recent kodi on current armbian, then I could forget about all others

To enable the armbianmonitor to show information on the running system on the serial console, I used to have a custom startup script, called from /etc/rc.local. After some time, I thought it was more neat to have this automatically started (and stopped) for login sessions that are started on serial consoles/terminals.

This lead (led?) me to the following systemd unit file:

[Unit]
Description=armbianmonitor on ttyS2
Requires=serial-getty@ttyS2.service
After=serial-getty@ttyS2.service 
After=getty.target
BindsTo=serial-getty@ttyS2.service 

[Service]
Type=idle
ExecStartPre=-/bin/sleep 10
ExecStart=/usr/bin/armbianmonitor -m
TTYPath=/dev/ttyS2
StandardInput=null
StandardOutput=tty
StandardError=syslog
KillSignal=SIGKILL
SendSIGHUP=yes

[Install]
WantedBy=serial-getty@ttyS2.service

File goes into /usr/lib/systemd/system/armbianmonitor@ttyS2.service. To 'activate' it, perform the following after creating the file at the specified location:

sudo systemctl daemon-reload
sudo systemctl enable armbianmonitor@ttyS2
sudo systemctl stop armbianmonitor@ttyS2
sudo systemctl start armbianmonitor@ttyS2

This is currently working for me on OrangePi Zero, NanoPi R2S, Helios4 (@ttyS0) and Helios64.

If you do not have serial-getty services started on ttyS2 - like in the example unit file - you will need to modify the 'ttyS2' with the serial console matching your situation.

Note that the new armbianmonitor@ttyX service will auto-start when seial-getty@ttyX is started and it will also stop when serial-getty@ttyX is stopped. This is to prevent orphaned armbianmonitors. Fun thing to try is to stop and start serial-getty@ttyX and also see the armbianmonitor service for that tty stop/start in tandem.

Hope this helps anyone out there, it's always nice to have serial output available in case things happen (and they always happen unexpectedly).

Groetjes,

p.s. See below spoiler for auto-adding these unit files based on your currently enabled serial-getty services.

#!/bin/bash

systemctl list-units --type=service --state=active,inactive --full --no-pager --no-legend --plain "serial-getty@*" |
    while read _UNIT _DONTCARE
    do
        _DEVICE="${_UNIT%.service}"
        _DEVICE="${_DEVICE##*@}"
        _FILE="/lib/systemd/system/armbianmonitor@${_DEVICE:?}.service"
        
        {
            cat << EOF
[Unit]
Description=armbianmonitor on ${_DEVICE:?}
Requires=${_UNIT:?}
After=${_UNIT:?} 
After=getty.target
BindsTo=${_UNIT:?} 

[Service]
Type=idle
ExecStartPre=-/bin/sleep 10
ExecStart=/usr/bin/armbianmonitor -m
TTYPath=/dev/${_DEVICE:?}
StandardInput=null
StandardOutput=tty
StandardError=syslog
KillSignal=SIGKILL
SendSIGHUP=yes

[Install]
WantedBy=${_UNIT:?}
EOF
        } | sudo tee "${_FILE:?}" > /dev/null

        sudo chown root:root "${_FILE:?}"
        sudo chmod 0644 "${_FILE:?}"
        sudo systemctl daemon-reload
    done
    
# EOF

@Werner and I have been working on an instruction video on how to install Armbian headless on your SBC.
Here it is.

Greetings,
NicoD

I startet with conky-grapes from TwisterOS, which I wanted to tweak to show cpu frequency for every core.

But that showed, that conky is not able to do consistent text formatting, so I startet to write my own theme.

As I like the armbian title font, I asked for the font, but it turned out, that it did not look as good as expected. So I discarded that variant and stayed with the previous selected fonts.

Main purpose is to use that monitor in home cinema, therefore I used bigger fonts, which are readable from distance.

Feedback is welcome.

I again got private SSH access. So I opened 3 terminals. One with HTop, another to check sensors. And the 3th to execute my benchmarks.
First thing I saw were the 128-threads. Being used to seeing 6, this was almost unbelievable.

With light loads it turbo's up to 4.3Ghz. All cores maxed out @ 3Ghz while consuming 400W.
Reaching a single core 7zip decompression score of 4545MIPS @ 4.3Ghz.
The Ampere 32-core ARM server at 3.3Ghz reached 2763.
This again shows the Ampere server doesn't use high performance cores. It doesn't perform great per clock.

Coming soon is a benchmark of an AWS server. This uses high performance cores based on the ARM N1 cores. A derivative of the A76.
This reaches 3393. This clocked at only 2.5Ghz. So this does perform better per clock. Do know this is comparing peers with bananas(don't want to confuse with apples).

And scoring 391809MIPS with 7zip multi-core decompression with default settings.

Then with an overclock to 3.9Ghz all cores it consumed +600W. With a 7zip decompression score of 433702MIPS

7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,128 CPUs AMD Ryzen Threadripper 3990X 64-Core Processor  (830F10),ASM,AES-NI)

AMD Ryzen Threadripper 3990X 64-Core Processor  (830F10)
CPU Freq: - 64000000 64000000 - - - - - -

RAM size:  257677 MB,  # CPU hardware threads: 128
RAM usage:  28240 MB,  # Benchmark threads:    128

                       Compressing  |                  Decompressing
Dict     Speed Usage    R/U Rating  |      Speed Usage    R/U Rating
         KiB/s     %   MIPS   MIPS  |      KiB/s     %   MIPS   MIPS

22:     272228 11672   2269 264824  |    5112130 12467   3499 435912
23:     165008 11150   1508 168123  |    5086525 12595   3496 440122
24:     121378 11578   1128 130506  |    4972483 12594   3467 436364
25:     103873 11805   1005 118599  |    4746979 12362   3419 422410
----------------------------------  | ------------------------------
Avr:           11551   1478 170513  |            12505   3470 433702
Tot:           12028   2474 302107

This is again so many levels better than the Ampere 32-core ARM server which got 85975MIPS. 32-cores of the AWS graviton2 does 110628.
So this AMD server is up to 5 x more powerful when overclocked, than the Ampere 32-core server. Consuming 6 x as much. 
With normal configuration they both perform almost as well in performance/watt.

7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,32 CPUs LE)
Ampere 32-core ARM Server
LE
CPU Freq: - - - - - - - - -

RAM size:  128285 MB,  # CPU hardware threads:  32
RAM usage:   7060 MB,  # Benchmark threads:     32

                       Compressing  |                  Decompressing
Dict     Speed Usage    R/U Rating  |      Speed Usage    R/U Rating
         KiB/s     %   MIPS   MIPS  |      KiB/s     %   MIPS   MIPS

22:      58550  2735   2082  56958  |    1027823  3151   2782  87652
23:      56799  2761   2096  57872  |    1002539  3141   2762  86751
24:      54973  2821   2096  59107  |     976406  3142   2728  85702
25:      52913  2838   2129  60414  |     941588  3120   2685  83795
----------------------------------  | ------------------------------
Avr:            2789   2101  58588  |             3139   2739  85975
Tot:            2964   2420  72281

In idle the Threadripper sonsumed 100W, what is a lot for doing nothing.
The 32-core ARM server only consumed a bit more than 100W maxed out. And about 20W in idle.

The BMW Blender benchmark, which takes 29m23s on the fastest ARM SBC the Odroid N2+. The Ampere ARM server did it in 8m27s.

For the Threadripper this was a way too light load, it did it in 30s. 

Even when doing this render 10 x after each other it didn't raise the temperatures much. The maximum I've seen was 50C.

To try a heavier load I downloaded the Barber Shop Blender render. This was 6912 tiles to render. But again the Threadripper wasn't impressed by this load. 2m18s79. The AWS with 32-cores (of 64) done this in 8m28s. So this ARM server does compete well per clock for a floating point task with TR.

ARM may be great, but AMD is mighty. Intel does not have anything to compete with this. Certainly not performance/watt. 
It was a pleasure benchmarking this server. 
I learned a lot, like that I need to find better tools for these amazing machines.  

The specs of this monster :
 

• ASRock Rack TRX40D8-2N2T
• AMD Ryzen Threadripper 3990x
• 256GB memory (8 x 32Gb) ECC
• 2 x 1TB PCI 4.0 Nvme SSD
• Water Cooling

The specs of the Threadripper 3990x

• 64-cores 128-threads AMD64
• Zen2 Matisse
• 2.9Ghz - 4.3Ghz
• 4-channel DDR4-3200 MHz
• 256GB RAM
• 88 lanes PCIe4
• TSMC's 7nm process node
• 280W - +400W
• 32 KB L1 per core (64x)
• 64 x 512 KB L2
• 256 MB L3 cache shared

You can see my full review video here, greetings.
NicoD

although I'm using Armbian a lot, I never had to submit anything to this forum (fortunately, because it works so well :-)),

On my PC I've experienced lags on heavy IO operations. After a short dig into available information,

I found a useful Cloudflare article on Kernel queues together with dm-crypt.

A good & short summary on possible actions for users can be found here:

https://wiki.archlinux.org/index.php/Dm-crypt/Specialties#Disable_workqueue_for_increased_solid_state_drive_(SSD)_performance

Enabling the no-read-workqueue & no-write-workqueue options helped a lot!

As I'm using a RockPi4 with the NVMe SSD with encryption, I thought this should apply to my SBC as well.

Unfortunately, Armbian/Debian Buster uses cryptsetup v2.1.0

which does NOT support these options.

According to the changelog, this option was introduced in v2.3.4:

https://gitlab.com/cryptsetup/cryptsetup/-/blob/master/docs/v2.3.4-ReleaseNotes

As Armbian uses a kernel > 5.9, the kernel infrastructure should be available.

Fortunately, crypsetup v2.3.4 exists in the buster-backports repo:

https://packages.debian.org/buster-backports/cryptsetup

Solution:

# sudo apt install cryptsetup/buster-backports

I like it a lot. Does Blender great, and works well as light desktop. Loving the graphics drivers and hoping soon the other SBC's can have simular good drivers. 
It is close to being my favorite. If only the cpu had more power...
Here my gathered data.
 

Check power mode        : sudo nvpmodel -q
Set 5W mode             : sudo nvpmodel -m1
Set 10W mode            : sudo nvpmodel -m0
config file             : sudo nano /etc/nvpmodel.conf

5W Mode clocks to 921Mhz and disables 2 cores 

Show clocks mode        : sudo jetson_clocks --show
Set everything to max   : sudo jetson_clocks          (turns back to normal after reboot)

Youtube Playback
----------------
All browsers up to 1080p. Some 1440p.

Video Playback
--------------
No 4K GUI player/Even not KODI in 4k - 1440p ok
4K in terminal : nvgstplayer -i <video-filename> 

Blender NicoD GPU render
------------------------
23m42s  1440p
17m14s  1080p    
17m00s   720p
CPU
---
17m22s   10W
35m24s @1.43Ghz   5W   1080p gpu 27m53s
19m for both CPU and GPU render

Blender NicoD Armbian Bionic CPU 
25m45s



SBC-Bench default 10W    : http://ix.io/22sS
SBC-Bench default 5W     : http://ix.io/22uy
SBC-Bench armbian Bionic : http://ix.io/22uc

USB3 Camera
-----------
git clone https://github.com/ksv1986/luvcview
cd luvcview
sudo apt-get install libsdl2-dev
sudo make

Check options           : ./luvcview -h
Preview 1920x1080@30fps : ./luvcview -d /dev/video0 -i 30 -s 1920x1080
                          ./luvcview -d /dev/video0 -i 30 -s 1920x1080 -o testVideo.mp4

Install PPSSPP
--------------
sudo add-apt-repository ppa:ppsspp/stable
sudo apt-get update
sudo apt install ppsspp
su   (if no superuser password has created yet, first make one with sudo passwd)
ppsspp

Storage Speeds
--------------
SD-card reader read   : 88 MB/s       0.42 ms
               write  : 70 MB/s
USB3-SSD       read   : 410 MB/s      0.26 ms
               write  : 380 MB/s               
ZRAM           read   : 1.7GB/s       0.01 ms      

Temperatures
------------
max No fan   : 78C
max 3V fan   : 43.5C

Problems
--------
USB seems unreliable. Not all USB3 devices are mounted as USB3 but as USB2. Problems with USB2 devices not being recognized at all.

Well here is what I came up with to solve this struggle

https://zuckerbude.org/cloud-nas-with-local-cache/

This little and inexpensive ($35) board is fully compatible to discontinued NanoPi M3. From a software point of view both boards are identical (though Wi-Fi is missing on the Fire3) and as such identical OS images can be used for both boards. The good news: compared to the last time I looked at the M3 kernel support has improved a lot. Back then we had to run a smelly 3.4.39 (32-bit only) while we can now run mainline on it.

I gave it a try using our Armbian Stretch nightly running with 4.14.40 (full armbianmonitor -u output) and did a couple of tests. The Samsung/Nexell S5P6818 SoC consists of 8 A53 cores running at up to 1.4GHz with default settings (can be slightly overclocked up to 1.6 GHz according to Willy Tarreau -- see the reviews at the product page). All cores behave like one big cluster (so adjusting /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq affects all 8 CPU cores at once, this is no artificial pseudo big.LITTLE as Amlogic does it with their S912).

Now with a recent 64-bit kernel with the CPU cores brought up in ARMv8 mode we can also make use of ARMv8 Crypto Extensions making the S5P6818 to one of the most powerful boards when it's about AES crypto and stuff can run on all 8 cores in parallel (33 times faster than a RPi 3 and still 28 times faster than a RPi 3+). While the octa-core config sounds interesting for CPU intensive workloads one should keep in mind that this board has only 1 GB DRAM which is simply not enough for many such workloads (or you would need to make massive use of zram instead which performs better than swap on slow storage but of course bottlenecks a lot).

Talking about a somewhat powerful CPU we also have to talk about temperatures and consumption. The board is always part of a kit so FriendlyELEC sells it together with a heatsink and a high quality Micro USB cable that solves a lot of the Micro USB related powering problems. In idle I measured 2.6W with Armbian (PSU included at the wall) while Willy Tarreau reported 'It consumes 400mA/5V in idle, and 1.2A/5V under openssl RSA with 8 cores at 1.6 GHz' (most probably using FriendlyELEC's OS image). So I tested for consumption with worst case workloads and used cpuburn-a53 for this. Since I knew from last time when I tested that the board deadlocks when starting cpuburn-a53 at 1.4 GHz I increased max cpufreq in steps (consumption always with PSU included):

1000 MHz: 9.3W
1100 MHz: 10.7W
1200 MHz: 12.2W
1300 MHz: 13.8W
1400 MHz: 14.7W

After a short time with cpuburn-a53 running at 1.4 GHz the board deadlocked again which is not a surprise since my PSU is rated for 2A (10W) and Micro USB itself is only rated for 1.8A (9W). As usual with FriendlyELEC boards there's a 4 pin header for serial debug console that can also be used to power the board more reliably so even demanding tasks that increase consumption to 15W are possible when powering through the header.

Talking about temperatures: After applying the heatsink I did a simple compile test (Arm Compute Library) with -j8 and after a minute the board did an emergency shutdown since CPU temperature reached 100°C. So all following tests were done with a huge fan blowing air over the heatsink laterally. IMO for demanding tasks improved airflow / heat dissipation is a must and the small heatsink simply not sufficient.

What other hardware is there? The usual 40 pin GPIO header, Gigabit Ethernet (with Armbian's settings and mainline kernel we're talking about iperf3 numbers of ~925 Mbits/sec in both directions), a mini HDMI port (most probably supported by Armbian), a camera and a LCD port (both not supported by Armbian as far as I know), the Micro USB OTG port and a single USB2 type A port. USB Attached SCSI (UAS) is yet not available with mainline kernel so storage performance is a little lower as it could be. This is a Samsung EVO840 in an ASM1153 enclosure connected to the USB2 port:

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     7544     9889    10098    10117     7996     9770
          102400      16    16143    20165    20365    20260    19858    20172
          102400     512    33138    33659    33120    33373    33417    33321
          102400    1024    33511    33663    33429    34020    34119    33521
          102400   16384    32731    34012    36483    36750    36674    34291

I also did a quick test as NAS and got numbers as expected: everything a little bit slower compared to those USB2 platforms that can make use of UAS -- so if NAS is the use case some of the cheaper Allwinner boards with Gigabit Ethernet are a better idea.

As usual FriendlyELEC did a great job documenting the board: http://wiki.friendlyarm.com/wiki/index.php/NanoPi_Fire3 -- they also provide OS images that make full use of all hardware features (camera, LCD displays auto-detected by u-boot, GPU/VPU acceleration, HDMI resolution switching in Linux sounds a bit like PITA though).

Still not sure for which use cases this board applies. The octa-core CPU would better be accompanied by more DRAM (though then you need to get the NanoPC-T3 Plus -- same SoC but 2 GB DRAM) and I fear making use of the processor power almost always requires a fan blowing in addition to the heatsink (without a fan I measured in idle always +60°C after a few minutes)

But then I found this rather interesting link from the Kobol guys: https://wiki.kobol.io/helios4/pwm/. Apparently the Linux kernel has built-in thermal control and user space scripting isn't even required, just editing the Device Tree.

But as we have easy user overlays for the RK3399, let's go ...

tparys@m4v2:~$ sudo armbian-add-overlay nanopi-m4-fan.dts 
Compiling the overlay
Copying the compiled overlay file to /boot/overlay-user/
Reboot is required to apply the changes

... or manually compile via DTC and copy to /boot/overlay-user, update /boot/armbianEnv.txt. Whichever makes you happy.

Seems to work well with the metal case I have for my M4V2 and NVME hat. Don't have a SATA hat, but if uses the same PWM pins, it should work there as well. No separate userspace package or SystemD service, and it should even kick in if the system gets stuck in boot (SystemD emergency mode).

Probably several improvements that could be made:

1. Fan is currently triggered only by CPU temperature, not GPU.
2. The fan replaces the first CPU trip point, which looks like it scales back the two big CPU cores. Not sure if this still needed.
3. PWM frequency (40000) is a total guess. Better period to use?
4. I don't see a much fan speed difference between cooling states 1-3. They should be 25, 50, and 100%, but all sound the same. Might have missed something.

Would be interested to hear any thoughts/feedback or if it's useful to anyone else.

nanopi-m4-fan.dts

$ uname -a
Linux nanopineo 5.10.13-sunxi #trunk SMP Mon Feb 8 21:56:43 CET 2021 armv7l armv7l armv7l GNU/Linux

$ dmesg | grep Machine
[    0.000000] OF: fdt: Machine model: FriendlyARM NanoPi NEO

# Baked current kernel. Configuration ... CIR module appears to NOT be enabled by default for NanoPI NEO.
$ grep -iE  "^CONFIG_IR_.*(CIR|SUN)" /boot/config-5.10.13-sunxi
CONFIG_IR_GPIO_CIR=m
CONFIG_IR_SUNXI=m

# Connected Vishay TSOP4838 IR Receiver to 3V3 (via 100R, with C100nF to GND), GND, OUT -> PL11
#              +----------+
# 1 --- OUT ---!     /--\ !
# 2 --- GND ---!     |  | !
# 3 --- 3V3 ---!     \__/ !
#              +----------+

# Get DTS and install as user overlay (commit 0ff3217)
$ wget -O sun8i-h3-cir.dts https://raw.githubusercontent.com/armbian/sunxi-DT-overlays/master/sun8i-h3/sun8i-h3-cir.dts
# Fix pin reference
# from     ir_pins_a             (from DTS file)
#   to               r_ir_rx_pin (from dtc -I fs -O dts /proc/device-tree)
$ sed -e "s/ir_pins_a/r_ir_rx_pin/" sun8i-h3-cir.dts > sun8i-h3-cir-nanopineo.dts

$ cat sun8i-h3-cir-nanopineo.dts
/dts-v1/;
/plugin/;

/ {
        compatible = "allwinner,sun8i-h3";

        fragment@0 {
                target = <&ir>;
                __overlay__ {
                        pinctrl-names = "default";
                        pinctrl-0 = <&r_ir_rx_pin>;
                        status = "okay";
                };
        };
};

$ armbian-add-overlay sun8i-h3-cir-nanopineo.dts
Compiling the overlay
Copying the compiled overlay file to /boot/overlay-user/
Reboot is required to apply the changes

$ shutdown -r now

$ dmesg | grep sunxi-ir
[   10.653323] rc rc0: sunxi-ir as /devices/platform/soc/1f02000.ir/rc/rc0
[   10.653692] rc rc0: lirc_dev: driver sunxi-ir registered at minor = 0, raw IR receiver, no transmitter
[   10.653883] input: sunxi-ir as /devices/platform/soc/1f02000.ir/rc/rc0/input3
[   10.665297] sunxi-ir 1f02000.ir: initialized sunXi IR driver

# Protocols file is there == driver present and overlay loaded OK.
$ cat /sys/class/rc/rc0/protocols
rc-5 nec rc-6 jvc sony rc-5-sz sanyo sharp mce_kbd xmp imon rc-mm [lirc]

# Enable "nec" protocol.
# I tried them all to find out what encoding is used by the remote that I happened to have here.
# There may be a smarter way where the IR subsystem tells you what encoding an incoming signal has.
$ echo "+nec" > /sys/class/rc/rc0/protocols

# The bracketed items appear to be [enabled]
$ cat /sys/class/rc/rc0/protocols
rc-5 [nec] rc-6 jvc sony rc-5-sz sanyo sharp mce_kbd xmp imon rc-mm [lirc]

# Test:
$ apt-get install ir-keytable

$ ir-keytable
Found /sys/class/rc/rc0/ with:
        Name: sunxi-ir
        Driver: sunxi-ir
        Default keymap: rc-empty
        Input device: /dev/input/event3
        LIRC device: /dev/lirc0
        Attached BPF protocols: Operation not supported
        Supported kernel protocols: lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp imon rc-mm
        Enabled kernel protocols: lirc nec
        bus: 25, vendor/product: 0001:0001, version: 0x0100
        Repeat delay = 500 ms, repeat period = 125 ms

$  ir-keytable -t
Testing events. Please, press CTRL-C to abort.
147.355171: lirc protocol(necx): scancode = 0xe31947
147.355225: event type EV_MSC(0x04): scancode = 0xe31947
147.355225: event type EV_SYN(0x00).
^C


# Test using event system (adjust Input device, cf. above):
$ evtest /dev/input/event3
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100
Input device name: "sunxi-ir"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 152 (KEY_SCREENLOCK)
  Event type 2 (EV_REL)
    Event code 0 (REL_X)
    Event code 1 (REL_Y)
  Event type 4 (EV_MSC)
    Event code 4 (MSC_SCAN)
Key repeat handling:
  Repeat type 20 (EV_REP)
    Repeat code 0 (REP_DELAY)
      Value    500
    Repeat code 1 (REP_PERIOD)
      Value    125
Properties:
  Property type 5 (INPUT_PROP_POINTING_STICK)
Testing ... (interrupt to exit)
Event: time 1612923728.916182, type 4 (EV_MSC), code 4 (MSC_SCAN), value e31948
Event: time 1612923728.916182, -------------- SYN_REPORT ------------
Event: time 1612923728.967737, type 4 (EV_MSC), code 4 (MSC_SCAN), value e31948
Event: time 1612923728.967737, -------------- SYN_REPORT ------------
^C

# From here on, use LIRC and/or adjust /etc/rc_maps.cfg et al. to map scan
# codes to key codes. This makes the IR receiver compatible with media player
# software. For the IoT device that I am building currently the scan codes
# suffice, so I won't describe this here.

(I am not really sure if that name change is a bug in the DTS repository, or if that name "ir_pins_a" refers to an older kernel, or if one is supposed to have another DT fragment somewhere that maps "ir_pins_a" to "r_ir_rx_pin", please comment if above is not the _right solution_.)

Device that I used for this guide: https://www.aliexpress.com/item/3-5-Inch-TFT-LCD-Moudle-For-Raspberry-Pi-2-Model-B-RPI-B-raspberry-pi/32707058182.html

Pinout: http://www.waveshare.com/3.5inch-rpi-lcd-a.htm (Yes, the device is a waveshare knockoff)

How to place the device? For Orange pi lite/one it is reversed. For the rest, it should be normal.

Refer to https://forum.armbian.com/index.php?/topic/724-quick-review-of-orange-pi-one/ for more info.

There are two sections to this guide.

Legacy / Mainline

Legacy Kernel [You can only EITHER use touch or LCD due to issues with spi chip select]

LCD

1) Load fbtft and fbtft_device on boot

sudo nano /etc/modules-load.d/fbtft.conf 
fbtft
fbtft_device

2) Load fbtft_device options

nano /etc/modprobe.d/fbtft.conf 
options fbtft_device rotate=90 name=piscreen speed=16000000 gpios=reset:2,dc:71 txbuflen=32768 fps=25

3) Make sure X11 loads to the correct framebuffer (fb8 for legacy)

nano /etc/X11/xorg.conf.d/50-fbturbo.conf
find fb0 and change to fb8

4) Reboot your device (sudo reboot) and you screen should be lit up

============================================

TOUCH

1) Download ads7846 touch driver (compatible with xpt2046)

mkdir ds7846 
cd ds7846 
wget https://raw.githubusercontent.com/raspberrypi/linux/rpi-3.6.y/drivers/input/touchscreen/ads7846.c

2) Create a makefile (Take note that it is TABS instead of spaces before the $(MAKE))

nano Makefile
Insert the below in without the -----
--------------------------------
obj-m := ads7846.o 
KDIR := /lib/modules/$(shell uname -r)/build 
PWD := $(shell pwd) 
all:
	$(MAKE) -C $(KDIR) M=$(PWD) modules 
clean:
	$(MAKE) -C $(KDIR) M=$(PWD) clean 
install:
	$(MAKE) -C $(KDIR) M=$(PWD) modules_install
--------------------------------

3) Exit nano and run the following

sudo make
sudo make install
sudo depmod

4) Download and compile and install ads7846_device

cd .. 
git clone https://github.com/notro/fbtft_tools/
cd fbtft_tools/ads7846_device 
make 
sudo make install 
sudo depmod 

5) Load ads7846 and ads7846_device on boot

sudo nano /etc/modules-load.d/ads7846.conf 
ads7846 
ads7846_device

6) Load ads7846_device options

nano /etc/modprobe.d/ads7846_device.conf 
options ads7846_device model=7846 cs=0 gpio_pendown=1 keep_vref_on=1 swap_xy=1 pressure_max=255 x_plate_ohms=60 x_min=200 x_max=3900 y_min=200 y_max=3900

7) Reboot your device and run evtest

sudo reboot
sudo evtest

Find your touch device and happy touching. Every touch should generate an event.

My M1 has 2GB ram and 16GB emmc but variants with 4GB ram and more emmc storage can be bought. Currently, an armbian CSC image can be downloaded (bullseye or focal) or built using armbian buiding system.

I tried several images and all boots fine with almost everything working out of the box for a server use case. Here is the log of armbianmonitor with a buster build from the end of january 2021 with kernel 5.10.9: http://ix.io/2Nol

Idle the temperature goes under 40°C in a room where the temperature is about 21°C and the metal case is not warm. Running sbc-bench in this context produces these results: http://ix.io/2NoL

The temperature never goes over 61°C without any throttling. Compared to some other rk3328 SBCs, the M1 is cooler and this is mainly due to its metal case.

After general configuration with armbian-config, installing openmediavault and docker were as easy as possible, since they are also available through armbian-config in the softy menu.

After connecting an usb3 drive, I got an efficient nas system for a personal use. It can also be considered as a home-server while running several additional services thanks to docker (home-assistant, zigbee2mqtt, pyload, etc.). With this use case, the 4 A53 cores and 2 GB of ram are more than enough and all is running smoothly.

I also use other similar arm boards and here is my comparison:

- an amlogic S912 TV box with 3GB ram and GBit ethernet using armbianTV: 2GB is enough in my case and rk3328 is better supported than s912. Moreover, s912 is not officially supported by armbian, and latest armbianTV images are not compatible. The USB3 port on M1 is also a great improvement over USB2 for s912. TV boxes may also have unrecognized wifi chips whereas M1 has working wifi (and bluetooth ? not tested).

- Librecomputer lafrite 1GB: it is officially supported by armbian and it works well. Its main drawbacks compared to M1 is only 1GB, USB2 and only 100MBits ethernet, but it is much cheaper.

- Pine64 Pineh64 model B: IMO it is the real competitor to the M1. It has similar features with USB3 and GBE. It is officially supported by armbian and it has a more powerful SoC (Allwinner H6: 1.8Ghz 4xA53 with mali 720 gpu). However, this board is much warmer than M1 since in the same room its temperature is greater than 60°C while idle and throttling may occur on moderate to heavy loads. For moderate use case M1 is enough.

What to expect in the future:

- We can hope that this SBC becomes quickly officially supported, since the CSC release is already very mature (in my opinion).

- The main element that can be missing with mainline kernel for some use cases is the GPU (for desktop use) and VPU, but they are available on 4.4 kernel.

Another review of the M1 (using also armbian): https://www.thanassis.space/stationm1.html

Official forum: https://www.stationpc.com/forum-60-1.html

sbc-bench is now on Github: https://github.com/ThomasKaiser/sbc-bench

I'll link from the README there to this thread for further discussion about the tool and proper benchmark methodology.

• !!!! I made a script that does all this, check a few posts later for the script !!!!!

This tutorial explains how to build an Armbian image with panfrost. And what else you need to make it work.

These are early drivers. Many things don't work yet. Only OpenGL 2.1 works now.

You need to build an image with kernel 5.2 or later.
For this you need an x86 pc with Ubuntu 18.04 or a virtual Ubuntu 18.04 x86 image.

First install git, then clone the build folder from Armbian, and enter the build directory.

apt-get -y -qq install git
git clone --depth 1 https://github.com/armbian/build
cd build

Now run the script with EXPERT=yes so you can choose to build a dev image.

sudo ./compile EXPERT=yes

• Choose "Full OS image for flashing"
• Then "Show a kernel configuration menu before compilation"
• Choose your board. If it's not in the regular list, look in "Show SCS/WIP/EOS/TVB".
• Choose Development version
• kernel configuration -> device drivers -> graphic drivers -> panfrost

Let it run until it's finished. The image will be in the /build/output/images

Burn it to an SD-card/eMMC/...

Now we need to install all the needed software

sudo apt install flex bison python3-mako libwayland-egl-backend-dev libxcb-dri3-dev libxcb-dri2-0-dev libxcb-glx0-dev libx11-xcb-dev libxcb-present-dev libxcb-sync-dev libxxf86vm-dev libxshmfence-dev libxrandr-dev libwayland-dev libxdamage-dev libxext-dev libxfixes-dev x11proto-dri2-dev x11proto-dri3-dev x11proto-present-dev x11proto-gl-dev x11proto-xf86vidmode-dev libexpat1-dev libudev-dev gettext glmark2 glmark2-es2 mesa-utils xutils-dev libpthread-stubs0-dev ninja-build bc python-pip flex bison cmake git valgrind llvm llvm-8-dev python3-pip  pkg-config zlib1g-dev wayland-protocols

Download and install meson

wget http://ftp.de.debian.org/debian/pool/main/m/meson/meson_0.55.3-1_all.deb
sudo dpkg -i meson_0.55.3-1_all.deb

Download and install mesa DRM

git clone git://anongit.freedesktop.org/mesa/drm
cd drm
meson build --prefix=/usr
ninja -C build
sudo -E ninja -C build install
cd ..

Download and install mesa graphics

git clone git://anongit.freedesktop.org/mesa/mesa
cd mesa
meson -Ddri-drivers= -Dvulkan-drivers= -Dgallium-drivers=panfrost,kmsro -Dlibunwind=false -Dprefix=/usr build/
ninja -C build/
sudo ninja -C build/ install

REBOOT

Optionally, update sdl (recommended)

git clone https://github.com/SDL-mirror/SDL.git
cd SDL
mkdir build
cd build
cmake ../  
make -j6
sudo make install

REBOOT

Only thing that works ok with it is supertuxkart, to install it.

sudo apt install supertuxkart

Panfrost - Linux games working from repo
SuperTuxKart - Works well
ExtremeTuxRacer - lots of glitches
AssaultCube - lots of glitches

Instructions by Salvador Liébana & NicoD

All have a jolly good Christmas or other holiday or normal day. 

Setup as Virtual Desktop Server ( remotely access headless OPI ONE desktop )

OPI ONE  : install xrdp and tightvncserver

<clients>  : install and configure remote desktop  ( rdesktop on linux, aRDP on android - not yet tested on OS-X or WIN )

Setup as Virtual Desktop Client ( OPI ONE securely accesses a remote linux desktop )

OPI ONE  : install x2goclient

<server>  : install x2goserver on linux server ( physical or virtual ) of choice

This document explains the experiment ( you have to click/enlarge pictures in your browser .. sorry )

And here is a screenshot of the actual session :

Red : Linux server desktop connecting to OPI ONE via rdesktop / xrdp

Orange : OPI ONE desktop connecting to UK virtual server via x2goclient/x2goserver

Purple : virtual server (UK) desktop running libreoffice

White : actual document being edited ( incl. drawings ! ) in window

( Headline : Italian guy in Switzerland abuses OPI ONE to edit nerd stuff in the UK )

Remote desktop access from smartphone ( cheap Wiko Lenny 2 ) for touch-fumbling nano-fingers

Remote desktop access from tablet ( Galaxy Note 8.0  ) using pen

There are numerous use cases covered with the simple techniques employed.Thanks to the Armbian team and the forum buddies for their excellent job in making OPI ONE usable.

Have fun !

I loved EC500 MACH3 Ethernet port 6 axis Motion Controller as it can support 16 optical-isolated digital output ports along with 18 optical-isolated digital input ports. It has a 24-36v dc power input for its IO power supply offering efficient anti-interference ability. Also, the latest EMC design makes it easy to work with the CNC motion controller. 

Here all the info I've gathered.
 

AWS Server 32-cores 128GB
-------------------------

NEOVERSE N1 64-core AWS Graviton2
ARMv8.2 aarch64
Arm’s Neoverse N1 cores -> based on A76 -> almost identical to Arm’s 64-core reference N1 platform -> CPU cores are clocked a bit lower 2.5GHz and only 32MB instead of 64MB of L3 cache
Max speed 2500Mhz
8-channel DDR-3200
128GB ram
64 PCIe4 lanes
TSMC’s 7nm process node
~1W per core at the 2.5GHz frequency
between 80W as a low estimate to around 110W estimation. This info is not disclosed by AWS

7z single core
Ampere 32-core     : 2763
AWS 32-core        : 3393
Threadripper 3990x : 4545


7z quad core   :  
Raspberry Pi 4 @ 1.5Ghz :  6307
Odroid N2+ 4xA73@2.4Ghz :  9900
Ampere 32-core          : 11145
AWS 32-core             : 13733
Threadripper 3990x      : 18060

7z all cores   : 
Ampere 32-core     :  85975
AWS 32-core        : 110628
Threadripper 3990x : 391809   433702 OC



Blender BMW CPU
Odroid N2+         : 30m
Ampere 32-core     :  8m27s
AWS Server 32-core :  2m08s
ThreadRipper 3990x :    30s

Blender Barber shop CPU 
AWS Server 32-core : 8m28s
Threadripper 3990x : 2m18s79

CPU Miner
Odroid N2+         :   14
Ampere 32-core     :   87
AWS Server 32-core :  154.20
ThreadRipper 3990x : 1310

SBC bench : http://ix.io/2FrG

Internet speed test between 1500 Mbit/s and 2000 Mbit/s both up- and download (up to 250MB/s)

I had 32-cores of the 64-cores. It is expected to perform a bit worse per core with 64-cores vs 32-cores since less cache available per core.

There's a newer Ampere 80-core N1 at 3Ghz SoC.  

https://www.anandtech.com/show/15578/cloud-clash-amazon-graviton2-arm-against-intel-and-amd/6

Thank you to @lanefu for giving me access to this.

I often use Htop to monitor the health of my boards and servers (amd64). It is a good tool for the sys admin to monitor the servers in real-time without much resources and it is not very intrusive.

Recipe

1 - Clone shellinabox

root@cubieboard2:~# git clone https://github.com/shellinabox/shellinabox
Cloning into 'shellinabox'...
remote: Enumerating objects: 3073, done.
remote: Total 3073 (delta 0), reused 0 (delta 0), pack-reused 3073
Receiving objects: 100% (3073/3073), 4.31 MiB | 1.89 MiB/s, done.
Resolving deltas: 100% (2418/2418), done.
root@cubieboard2:~# cd shellinabox/

2 - Build and install shellinabox

shellinabox makefile is outdated for OpenSSL 1.1.y, so we need to bypass the linking process and do it manually.

During the config process you get some errors, bypass the error by doing like so:

root@cubieboard2:~/shellinabox# apt-get install libtool

root@cubieboard2:~/shellinabox# autoreconf -i
root@cubieboard2:~/shellinabox# autoconf
root@cubieboard2:~/shellinabox# autoreconf -i

root@cubieboard2:~/shellinabox# ./configure

root@cubieboard2:~/shellinabox# make

3 - Bypass the linking error

During the link process you get a missing openssl 1.1 lib, we then manually link shellinabox:

root@cubieboard2:~/shellinabox#  gcc -g -std=gnu99 -Wall -Os -o shellinaboxd shellinabox/shellinaboxd.o shellinabox/externalfile.o shellinabox/launcher.o shellinabox/privileges.o shellinabox/service.o shellinabox/session.o shellinabox/usercss.o  ./.libs/liblogging.a ./.libs/libhttp.a -ldl -lutil -lssl -lcrypto

4 - Running Htop on the Browser

I choose not to install shellinabox, just run a service to be able to run and make Htop available on the Browser.

Tested on Google Chromium and FireFox (linux).

root@cubieboard2:~/shellinabox# ./shellinaboxd -t -b -p 8888 --no-beep -s '/htop_app/:alex:alex:/:htop -d 10'

where 8888 is the port.

alex:alex is the user:group to run Htop with. Use yours [user] and [group].

Note: for security reason if you run with nobody:nogroup you wont be able to add or change any config on the Htop.

Now fire the browser at http://ip_address:8888/htop_app/ and that's it, enjoy.

5 - Credits

stackverflow, user ofstudio.

Screenshot:

Basically, its a python Flask application that captures frames from the camera using a GStreamer pipeline. It runs them through a Tensorflow object detection model and spits out the same frame with extra metadata about objects it found, and renders a box around them. Using all four cores of the H2 it can do about 2-3 fps. The app keeps track of the count of all object types it has seen and exposes the metrics in prometheus format, for easy creation of graphs of what it sees over time with Grafana

I'll explain some of the more interesting aspects of how I got this to work here in case anyone else wants to try to get some use out of this very inexpensive hardware, and I am grateful to the many posts on this forum that helped me along the way!

Use a 3.4 kernel with custom GC2035 driver

Don't bother with anything new - the GC2035 was hopeless on any newer builds of Armbian I tried. The driver available at https://github.com/avafinger/gc2035.git provided far better image quality. After installing the updated GC2035, I run the following to get the camera up and running:

sudo sunxi-pio -m "PG11<1><0><1><1>"
sudo modprobe gc2035 hres=1
sudo modprobe vfe_v4l2

Install Tensorflow lite runtime

Google provides a tensorflow runtime as a binary wheel built for python 3.5 armv7. When pip installing, expect it to take 20 minutes or so as it will need to compile numpy (the apt repo version isn't recent enough)

wget https://github.com/google-coral/pycoral/releases/download/release-frogfish/tflite_runtime-2.5.0-cp35-cp35m-linux_armv7l.whl
sudo -H pip3 install tflite_runtime-2.5.0-cp35-cp35m-linux_armv7l.whl

Build opencv for python 3.5 bindings

This was something I tried everything I could to avoid, but I just could not get the colour conversion from the YUV format of the GC2035 to an RGB image using anything else I found online, so I was dependent on a single color-conversion utility function.

To build the 3.4.12 version for use with python (grab lunch - takes about 1.5 hours :-O )

cmake -DCMAKE_INSTALL_PREFIX=/home/atomic/local -DSOFTFP=ON \
    -DBUILD_TESTS=OFF -D BUILD_PERF_TESTS=OFF -D BUILD_opencv_python2=0 \
    -D BUILD_opencv_python3=1 -D WITH_GSTREAMER=ON \
    -D PYTHON3_INCLUDE_PATH=/usr/include/python3.5  ..
make -j 4
make install

# Check that ~/local/lib/python3.5/dist-packages should now have the cv2 shlib
export PYTHONPATH=/home/atomic/local/lib/python3.5/dist-packages

Build gstreamer plugin for Cedar H264 encoder

This is required to get a working gstreamer pipeline for the video feed:

git clone https://github.com/gtalusan/gst-plugin-cedar
./autogen.sh
sudo make install
# When trying against a pipc I had to copy into .local to get gstreamer to recognise it
cp /usr/local/lib/gstreamer-1.0/libgst* ~/.local/share/gstreamer-1.0/plugins/
# Confirm that plugin is installed:
gst-inspect-1.0 cedar_h264enc

Processing images

The full app source is on github, but the more interesting parts that took me some time to figure out were about getting python to cooperate with gstreamer:

Frames from the camera arrive to python at the end of the pipeline as an appsink. The Gstreamer pipeline I configured via python was:

    src =  Gst.ElementFactory.make("v4l2src")
    src.set_property("device", "/dev/video0")
    src.set_property("do-timestamp", 1)
    filt = Gst.ElementFactory.make("capsfilter")
    filt.set_property("caps", Gst.caps_from_string("video/x-raw,format=NV12,width=800,height=600,framerate=12/1"))
    p1 = Gst.ElementFactory.make("cedar_h264enc")
    p2 = Gst.ElementFactory.make("h264parse")
    p3 = Gst.ElementFactory.make("rtph264pay")
    p3.set_property("config-interval", 1)
    p3.set_property("pt", 96)
    p4 = Gst.ElementFactory.make("rtph264depay")
    p5 = Gst.ElementFactory.make("avdec_h264")
    sink = Gst.ElementFactory.make("appsink", "sink")
    pipeline_elements = [src, filt, p1, p2, p3, p4, p5, sink]

    sink.set_property("max-buffers", 10)
    sink.set_property('emit-signals', True)
    sink.set_property('sync', False)
    sink.connect("new-sample", on_buffer, sink)