ebin-dev

Armbian "current" (5.10.y) compiles without issues.
I second @Igor's opinion that a change somewhere in this diff broke the eMMC.
I tried reverting a few obvious parts of it, like the mmc driver changes, but without success.
 
However I did find that with the unit I have the issue happens only in hs400{,es} modes.
With those disabled my unit works fine and I can use nand-sata-install to transfer os from SD to eMMC successfully which is not possible with 5.10.60+ and hs400 enabled on eMMC.
 
If anyone wants to check if switching eMMC to hs200 mode works also on their unit, here is how:
Upgrade the kernel to 5.10.60, but don't reboot yet.
Run:
curl -o rk3399-kobol-helios64.dtb https://users.armbian.com/piter75/helios64/rk3399-kobol-helios64.dtb sudo cp rk3399-kobol-helios64.dtb /boot/dtb/rockchip/rk3399-kobol-helios64.dtb sudo reboot  
If this workaround works I will disable hs400{,es} (again) in Armbian until the underlying issue is found.
There will be a performance penalty to that change but keep in mind that Helios64 was originally released with hs200 and only recently gained hs400 back ;-)
Below you can find the comparison between hs400 and hs200 modes using iozone.
 

I own a Helios64  too and I store data on it I really do not want to loose.  I love this thing !
But It is in fact ridiculous if updates are provided having the potential to render your setup unusable or even to loose your data.
 
After Kobol stopped operations my immediate reaction a was to close the Armbian update channel and to test potential Armbian updates myself -  and not on my main system.
 
Instead of turning away from Armbian I try to support Helios64 on this platform. As long as Kobol operations are stopped we need to build and test linux kernels ourselves before updating to any new linux version.
 
However, there is a stable kernel 5.10.43 for Helios64 (in particular with the ondemand governor active) and it is the kernel branch Debian Bullseye is using.
With this setup it should be already possible to operate Helios64 for the next 2-5 years in a stable manner by just receiving updates through the Debian Bullseye channel - with occasional linux updates compiled and tested by members of this forum.
 
Everybody is invited to contribute.

Hi @lanefu - do you mean whether or not a buster or bullseye system on emmc that is updated from Armbian 21.05.4 to 21.08.1 has non matching UUIDs in the three locations ?
 
What I can tell is that boot.scr does not contain a UUID at all. The device /dev/mmcblk0p1 is specified instead (in boot.cmd) - also in the fresh Buster image on the download page.
 
UUIDs are present in /boot/armbianEnv.txt and /etc/fstab. If they are correctly set to the UUID of the root filesystem, a previous Buster 21.05.4 installation was running fine on SD and on emmc.
 
The "emmc issue" occurs after the update from 21.05.4 to 21.08.1 even if the UUIDs in /boot/armbianEnv.txt and /etc/fstab are correctly set to the UUID of the root file system on emmc.
 

I own a Helios64  too and I store data on it I really do not want to loose.  I love this thing !
But It is in fact ridiculous if updates are provided having the potential to render your setup unusable or even to loose your data.
 
After Kobol stopped operations my immediate reaction a was to close the Armbian update channel and to test potential Armbian updates myself -  and not on my main system.
 
Instead of turning away from Armbian I try to support Helios64 on this platform. As long as Kobol operations are stopped we need to build and test linux kernels ourselves before updating to any new linux version.
 
However, there is a stable kernel 5.10.43 for Helios64 (in particular with the ondemand governor active) and it is the kernel branch Debian Bullseye is using.
With this setup it should be already possible to operate Helios64 for the next 2-5 years in a stable manner by just receiving updates through the Debian Bullseye channel - with occasional linux updates compiled and tested by members of this forum.
 
Everybody is invited to contribute.

Armbian is a community driven project. This is not about trying to find someone to blame, but trying to solve issues by pointing to alleged sources of the trouble.
 
And indeed community support is there as you can see in this thread - it could be stronger though.
 

For info, my MMC device includes 2 partitions. mmcblk2p1 includes /boot, and mmcblk2p2 contains linux folders.
As I performed the steps above by mounting mmcblk2p2 on /mnt/system, new linux image 5.10.43 was actually available in /mnt/system/boot.
However, I had to copy the files to mmcblk2p1 partition. Otherwise, my system starts on MMC without any change in linux version.
After generated the image, I apply the instructions below:
root@helios64:~# mkdir -p /mnt/boot root@helios64:~# mount /dev/mmcblk1p2 /mnt/boot root@helios64:~# cp -r /mnt/system/boot/* /mnt/boot/boot root@helios64:~# reboot  

Armbian is a community driven project. This is not about trying to find someone to blame, but trying to solve issues by pointing to alleged sources of the trouble.
 
And indeed community support is there as you can see in this thread - it could be stronger though.
 

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