ebin-dev

Hi!
 
If I remove the patches that don't compile and adapt the other ones, the resulting kernel is having issues with eMMC or unbootable kernel (u-boot does bootloops).
 
I even tried some older versions that did work (i.e. recompile one of my ancient kernels with vanilla sources + gentoo patches +  armbian patches) and it fails. But I didn't do it with method, I wanted to have a stable kernel to have back my "production" home server.
 
The kernel I run is now " 5.10.34-gentoo #1 SMP Mon May 3 10:47:06 CEST 2021 aarch64 GNU/Linux", the version I had in one backup. After May 3 2021 I had issues with u-boot (kernel did not boot) or not compiling patches.
 
I can help you (armbian poeple) to point the problems. In fact, I would like to rebuild all the provides binaries (u-boot, kernel) myself in order to understand how they are working and configured.
 
 

There is a possibility discussed in the parallel thread link.
 
You also could boot a fresh Armbian 21.05.4 off  SD and rsync with it the content from emmc to another bootable SD. Then you continue to downgrade linux on that second SD (booted)  ... and rsync the result back to emmc.
 
Maybe somebody else could explain how to downgrade the kernel on emmc using a chrooted environment.

This was already answered in this thread.
 
 

The easiest way to downgrade linux on emmc now would be to copy those files to /mnt/system (root directory of your emmc) - and then change root with  'chroot /mnt/system' and install the packages with 'dpkg -i *.deb'   (while your active system is on SD).
 
You can leave the chrooted environment by typing 'exit'. emmc should now be bootable again. If not, you need to update the bootloader on emmc as described earlier in this thread.

The easiest way to downgrade linux on emmc now would be to copy those files to /mnt/system (root directory of your emmc) - and then change root with  'chroot /mnt/system' and install the packages with 'dpkg -i *.deb'   (while your active system is on SD).
 
You can leave the chrooted environment by typing 'exit'. emmc should now be bootable again. If not, you need to update the bootloader on emmc as described earlier in this thread.

First I would downgrade the system on SD to 21.05.4 (you can access emmc again without i/o errors), then format the partition on emmc 'mkfs.ext4 /dev/mmcblk2p1' (to get rid of potentially corrupt content) and rsync the content from sd to emmc (assuming that the sd contains a valid copy of your system on emmc).
For the last step you can adapt the script I use (it is a modified Armbian script). I did no use any armbian-config routines this time.
You may need to update the bootloader on emmc too.
 
# cat copytoemmc.sh #!/bin/bash # Check if user is root if [ $(id -u) != "0" ]; then echo "Error: You must be root to run this script." exit 1 fi cat > install-exclude <<EOF /dev/* /proc/* /sys/* /media/data1/* /media/data2/* /media/data3/* /media/data4/* /media/data5/* /mnt/sd/* /mnt/emmc/* /mnt/ssd/* /mnt/usb/* /mnt/hd/* /run/* # /tmp/* # /root/* EOF exec 2>/dev/null umount /mnt/emmc exec 2>&1 mount /dev/mmcblk2p1 /mnt/emmc rsync -avxSE --delete --exclude-from="install-exclude" / /mnt/emmc # change fstab sed -e 's/UUID=< insert uuid of sd >/UUID=< insert uuid of emmc >/g' -i /mnt/emmc/etc/fstab sed -e 's/UUID=< insert uuid of sd >/UUID=< insert uuid of emmc >/g' -i /mnt/emmc/boot/armbianEnv.txt umount /mnt/emmc rm install-exclude echo "All done."  

@bunducafe dpkg -i *.deb did the job;  @IcerJo I would not trust a "temporary" fix I don't really understand. Helios64 saves your data...
 

In order to roll back the kernel you just need to install those packages (on sd): http://armbian.hosthatch.com/apt/pool/main/l/linux-5.10.43-rockchip64/
 

In order to roll back the kernel you just need to install those packages (on sd): http://armbian.hosthatch.com/apt/pool/main/l/linux-5.10.43-rockchip64/
 

You are using kernel 5.10.60 (Armbian 21.08.1).  Several Armbian patches did not compile with this version of the kernel - it is therefore unstable (see the parallel thread - upgrading to Bullseye). The kernel panic occurred after 150372 seconds = 41.77 hours of operation !
 

The next thing I would buy is a drop in replacement board for the helios64 with:
rk3588 ECC RAM  nvme PCI-e port 10GBase-T port

I am using the following script to backup my root partition to sd (it is just a slightly modified Armbian script - please adapt the device name if necessary):
 
# cat backuptosd.sh #!/bin/bash # Check if user is root if [ $(id -u) != "0" ]; then echo "Error: You must be root to run this script." exit 1 fi cat > install-exclude <<EOF /dev/* /proc/* /sys/* /media/data1/* /media/data2/* /media/data3/* /media/data4/* /media/data5/* /mnt/sd/* /mnt/ssd/* /mnt/usb/* /mnt/hd/* /run/* # /tmp/* # /root/* EOF exec 2>/dev/null umount /mnt/sd exec 2>&1 mount /dev/mmcblk1p1 /mnt/sd rsync -avxSE --delete --exclude-from="install-exclude" / /mnt/sd # change fstab sed -e 's/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx3c/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx2d/g' -i /mnt/sd/etc/fstab sed -e 's/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx3c/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx2d/g' -i /mnt/sd/boot/armbianEnv.txt umount /mnt/sd rm install-exclude  
The UUIDs need to be inserted (blkid is your friend) - the leftmost is the one of your root system, the other one is the UUID of the sd in this example.
If you need a bootable system on sd - the easiest way would be to start with a fresh Armbian image flashed to the sd card and to boot from it at least once in order to expand the filesystem.
Then you may boot from your main root partition and simply sync it to the sd card using the above script.
 

I am using the following script to backup my root partition to sd (it is just a slightly modified Armbian script - please adapt the device name if necessary):
 
# cat backuptosd.sh #!/bin/bash # Check if user is root if [ $(id -u) != "0" ]; then echo "Error: You must be root to run this script." exit 1 fi cat > install-exclude <<EOF /dev/* /proc/* /sys/* /media/data1/* /media/data2/* /media/data3/* /media/data4/* /media/data5/* /mnt/sd/* /mnt/ssd/* /mnt/usb/* /mnt/hd/* /run/* # /tmp/* # /root/* EOF exec 2>/dev/null umount /mnt/sd exec 2>&1 mount /dev/mmcblk1p1 /mnt/sd rsync -avxSE --delete --exclude-from="install-exclude" / /mnt/sd # change fstab sed -e 's/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx3c/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx2d/g' -i /mnt/sd/etc/fstab sed -e 's/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx3c/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx2d/g' -i /mnt/sd/boot/armbianEnv.txt umount /mnt/sd rm install-exclude  
The UUIDs need to be inserted (blkid is your friend) - the leftmost is the one of your root system, the other one is the UUID of the sd in this example.
If you need a bootable system on sd - the easiest way would be to start with a fresh Armbian image flashed to the sd card and to boot from it at least once in order to expand the filesystem.
Then you may boot from your main root partition and simply sync it to the sd card using the above script.
 

I am using the following script to backup my root partition to sd (it is just a slightly modified Armbian script - please adapt the device name if necessary):
 
# cat backuptosd.sh #!/bin/bash # Check if user is root if [ $(id -u) != "0" ]; then echo "Error: You must be root to run this script." exit 1 fi cat > install-exclude <<EOF /dev/* /proc/* /sys/* /media/data1/* /media/data2/* /media/data3/* /media/data4/* /media/data5/* /mnt/sd/* /mnt/ssd/* /mnt/usb/* /mnt/hd/* /run/* # /tmp/* # /root/* EOF exec 2>/dev/null umount /mnt/sd exec 2>&1 mount /dev/mmcblk1p1 /mnt/sd rsync -avxSE --delete --exclude-from="install-exclude" / /mnt/sd # change fstab sed -e 's/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx3c/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx2d/g' -i /mnt/sd/etc/fstab sed -e 's/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx3c/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx2d/g' -i /mnt/sd/boot/armbianEnv.txt umount /mnt/sd rm install-exclude  
The UUIDs need to be inserted (blkid is your friend) - the leftmost is the one of your root system, the other one is the UUID of the sd in this example.
If you need a bootable system on sd - the easiest way would be to start with a fresh Armbian image flashed to the sd card and to boot from it at least once in order to expand the filesystem.
Then you may boot from your main root partition and simply sync it to the sd card using the above script.
 

I can confirm that the following procedure updates u-boot on emmc without any issues:
 
# cd /usr/lib/linux-u-boot-current-helios64_21.02.3_arm64 # ls -la total 8404 drwxrwxr-x 2 root root 4096 Mar 9 11:01 . drwxr-xr-x 80 root root 4096 Mar 9 11:01 .. -rw-rw-r-- 1 root root 206844 Mar 8 15:55 idbloader.bin -rw-rw-r-- 1 root root 4194304 Mar 8 15:55 trust.bin -rw-rw-r-- 1 root root 4194304 Mar 8 15:55 uboot.img # dd if=idbloader.bin of=/dev/mmcblk2 seek=64 conv=notrunc # dd if=uboot.img of=/dev/mmcblk2 seek=16384 conv=notrunc # dd if=trust.bin of=/dev/mmcblk2 seek=24576 conv=notrunc # reboot now  

I am using the following modified version of an Armbian Script to rsync emmc to sd (replace UUIDs to match yours):
 
# cat backuptosd.sh #!/bin/bash # Check if user is root if [ $(id -u) != "0" ]; then echo "Error: You must be root to run this script." exit 1 fi cat > install-exclude <<EOF /dev/* /proc/* /sys/* /media/data1/* /media/data2/* /media/data3/* /media/data4/* /media/data5/* /mnt/sd/* /mnt/ssd/* /mnt/usb/* /mnt/hd/* /run/* # /tmp/* # /root/* EOF exec 2>/dev/null umount /mnt/sd exec 2>&1 mount /dev/mmcblk0p1 /mnt/sd rsync -avxSE --delete --exclude-from="install-exclude" / /mnt/sd # change fstab sed -e 's/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx3c/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx2d/g' -i /mnt/sd/etc/fstab sed -e 's/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx3c/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx2d/g' -i /mnt/sd/boot/armbianEnv.txt umount /mnt/sd rm install-exclude  

The next thing I would buy is a drop in replacement board for the helios64 with:
rk3588 ECC RAM  nvme PCI-e port 10GBase-T port

The next thing I would buy is a drop in replacement board for the helios64 with:
rk3588 ECC RAM  nvme PCI-e port 10GBase-T port

@NickSYou just need to change a single digit from 0 to 1 - see here.
 
Unfortunately you need to repeat that if /lib/systemd/system-shutdown/disable_auto_poweron is updated by Armbian.

I am using the following modified version of an Armbian Script to rsync emmc to sd (replace UUIDs to match yours):
 
# cat backuptosd.sh #!/bin/bash # Check if user is root if [ $(id -u) != "0" ]; then echo "Error: You must be root to run this script." exit 1 fi cat > install-exclude <<EOF /dev/* /proc/* /sys/* /media/data1/* /media/data2/* /media/data3/* /media/data4/* /media/data5/* /mnt/sd/* /mnt/ssd/* /mnt/usb/* /mnt/hd/* /run/* # /tmp/* # /root/* EOF exec 2>/dev/null umount /mnt/sd exec 2>&1 mount /dev/mmcblk0p1 /mnt/sd rsync -avxSE --delete --exclude-from="install-exclude" / /mnt/sd # change fstab sed -e 's/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx3c/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx2d/g' -i /mnt/sd/etc/fstab sed -e 's/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx3c/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx2d/g' -i /mnt/sd/boot/armbianEnv.txt umount /mnt/sd rm install-exclude  

Some of you may be interested to not only store your data on Helios64 but to also run other services on it - such as home automation. One of the popular platforms for home automation in Europe - and in Germany in particular - is "Homematic". They opened up their ecosystem some time ago and allow others to implement their own components (some excellent examples from Jérôme are here). 
 
As of yesterday - with the latest commit - it is possible to run a virtualised "ccu3" base station for that platform, called pivccu, with support for a detached antenna module (RPI-RF-MOD) coupled to Helios64 (and Armbian 20.11 kernel 5.9.10) through a tcp/ip network using a dedicated circuit board developed by Alex Reinert (HB-RF-ETH). All of these projects are in the open domain. Actually not only Helios64 but also most of the SBCs running Armbian and a recent mainline kernel should now also be supported.
 
There is a logic layer built into the pivccu system, but actions can also easily be automated using i.e. Node-Red or OpenHab2.
 
Just to let you know: If you don't want to build stuff yourself, components could be purchased in Germany from i.e. elv and smartkram.
 

Armbian 20.08.10 has been released with eMMC boot fixed.
Please do a fresh install. If you want to boot from eMMC, you can transfer using armbian-config > System > Install > 2 Boot from eMMC - system on eMMC

The current Armbian buster image with kernel 5.8.6 (thanks to @Igor) works nicely in combination with the current Armbian bootloader - at least with CPU_DDR=800_800 on a V5_0_1 EspressoBin 1GB. 7Zip correctly reports a CPU frequency of 800 MHz:
root@espressobin:~# cat /proc/version Linux version 5.8.6-mvebu64 (root@desktop) (aarch64-none-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025, GNU ld (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 2.33.1.20191209) #20.08.2 SMP PREEMPT Fri Sep 4 22:39:30 CEST 2020 root@espressobin:~# 7za b 7-Zip (a) [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,2 CPUs LE) LE CPU Freq: 794 794 794 794 794 794 794 794  
I also tried the bootloader with CPU_DDR=1000_800. Armbian launches without issues, cpufreq-info correctly reports the maximum CPU frequency of 1000MHz, but 7zip still reports a CPU frequency of about 800 MHz:
root@espressobin:~# cat /proc/version Linux version 5.8.6-mvebu64 (root@desktop) (aarch64-none-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025, GNU ld (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 2.33.1.20191209) #20.08.2 SMP PREEMPT Fri Sep 4 22:39:30 CEST 2020 root@espressobin:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 200 MHz - 1000 MHz available frequency steps: 200 MHz, 250 MHz, 500 MHz, 1000 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 200 MHz and 1000 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 200 MHz (asserted by call to hardware). cpufreq stats: 200 MHz:87.38%, 250 MHz:1.61%, 500 MHz:0.12%, 1000 MHz:10.89% (309) analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 200 MHz - 1000 MHz available frequency steps: 200 MHz, 250 MHz, 500 MHz, 1000 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 200 MHz and 1000 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 200 MHz (asserted by call to hardware). cpufreq stats: 200 MHz:87.38%, 250 MHz:1.61%, 500 MHz:0.12%, 1000 MHz:10.89% (309) root@espressobin:~# 7za b 7-Zip (a) [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,2 CPUs LE) LE CPU Freq: 612 794 794 794 794 794 794 794  

No issues so far with Buster on EspressoBin.
Nextcloud is faster with PHP 7.3.4 -- I am thrilled.
 
_____ _ _ | ____|___ _ __ _ __ ___ ___ ___ ___ | |__ (_)_ __ | _| / __| '_ \| '__/ _ \/ __/ __|/ _ \| '_ \| | '_ \ | |___\__ \ |_) | | | __/\__ \__ \ (_) | |_) | | | | | |_____|___/ .__/|_| \___||___/___/\___/|_.__/|_|_| |_| |_| Welcome to Debian Buster with Armbian Linux 4.19.57-mvebu64 System load: 0.06 0.12 0.15 Up time: 8:04 hours Memory usage: 42 % of 990MB IP: 12.34.56.78 Usage of /: 18% of 908G  

@Jens Bauer @ManoftheSea @anubisg1
The MAC address of the bridge can be specified in 10-br0.netdev. This works without any issues in Stretch and in Buster (at least on a V5_0_1 EspressoBin). If you have problems with Ubuntu Bionic, then their implementation of systemd-networkd may be the reason.
 
# cat 10-br0.netdev [NetDev] Name=br0 Kind=bridge MACAddress=XX:XX:XX:XX:XX:XX # networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 eth0 ether degraded configured 3 wan dsa degraded configured 4 lan0 dsa no-carrier configuring 5 lan1 dsa no-carrier configuring 6 br0 bridge routable configured _____ _ _ | ____|___ _ __ _ __ ___ ___ ___ ___ | |__ (_)_ __ | _| / __| '_ \| '__/ _ \/ __/ __|/ _ \| '_ \| | '_ \ | |___\__ \ |_) | | | __/\__ \__ \ (_) | |_) | | | | | |_____|___/ .__/|_| \___||___/___/\___/|_.__/|_|_| |_| |_| Welcome to Debian Buster with Armbian Linux 4.19.57-mvebu64 System load: 0.15 0.13 0.11 Up time: 17:54 hours Memory usage: 37 % of 990MB Zram usage: 36 % of 495Mb Usage of /: 18% of 908G