ebin-dev

PR https://github.com/armbian/build/pull/4480

I can understand that you are disappointed.
 
But I think that Kobol had to pull the plug, in the context of the current chip shortage - with limited (sometimes even no) availability of components and SOCs and rising prices. That is not the right environment for a small start-up to grow. - it is a rather toxic environemnt that will lead to insolvency, as profitable growth is impossible to achieve. Without growth (no new/further products to offer) you are just faced with fixed costs and without income. Not sustainable at all.
 
All three of the founding members of Kobol deserve our full respect. They only drew a logical conclusion. Hopefully it can be reversed some time.

Some Helios64 had issues with CPU freezes or other instabilities. If you buy one you should make sure that you can give it back if it is one of those.
 
Cheers
ebin-dev
 

Hi,
 
updating Helios64 (Armbian Bullseye) to the latest kernel (Armbian 22.02.1 with Linux 5.15.25-rockchip64) went flawlessly - it seems to be stable so far (Thanks!).
However, emmc read/write speed is still reduced by a factor of 2 compared to linux 5.10.43.
 
@piter75 Do you know if there is anybody trying to re-enable high emmc read/write speeds in newer kernels  ?

I can understand that you are disappointed.
 
But I think that Kobol had to pull the plug, in the context of the current chip shortage - with limited (sometimes even no) availability of components and SOCs and rising prices. That is not the right environment for a small start-up to grow. - it is a rather toxic environemnt that will lead to insolvency, as profitable growth is impossible to achieve. Without growth (no new/further products to offer) you are just faced with fixed costs and without income. Not sustainable at all.
 
All three of the founding members of Kobol deserve our full respect. They only drew a logical conclusion. Hopefully it can be reversed some time.

I can understand that you are disappointed.
 
But I think that Kobol had to pull the plug, in the context of the current chip shortage - with limited (sometimes even no) availability of components and SOCs and rising prices. That is not the right environment for a small start-up to grow. - it is a rather toxic environemnt that will lead to insolvency, as profitable growth is impossible to achieve. Without growth (no new/further products to offer) you are just faced with fixed costs and without income. Not sustainable at all.
 
All three of the founding members of Kobol deserve our full respect. They only drew a logical conclusion. Hopefully it can be reversed some time.

I can understand that you are disappointed.
 
But I think that Kobol had to pull the plug, in the context of the current chip shortage - with limited (sometimes even no) availability of components and SOCs and rising prices. That is not the right environment for a small start-up to grow. - it is a rather toxic environemnt that will lead to insolvency, as profitable growth is impossible to achieve. Without growth (no new/further products to offer) you are just faced with fixed costs and without income. Not sustainable at all.
 
All three of the founding members of Kobol deserve our full respect. They only drew a logical conclusion. Hopefully it can be reversed some time.

Some Helios64 had issues with CPU freezes or other instabilities. If you buy one you should make sure that you can give it back if it is one of those.
 
Cheers
ebin-dev
 

On emmc (/dev/mmcblk2p1) you just need to replace the root UUID in /etc/fstab and in /boot/armbianEnv.txt to match the UUID of your emmc (e4e3bcd6-3f03-4362-bbe0-f1654138c5d8). Then reboot without microsd in the slot...

A fresh Bullseye image is stable on Helios64 - just like the upgraded Buster image.

YEAH !
I can compile and boot linux-5.10.63, I only had to disable the rk3328 patches because some patches were rejected.
 
I booted from sdcard, updated the /boot folder, then rebooted from eMMC and I can again run and write on the eMMC :-)
 
 
EDIT: and upgraded to 5.10.64 this weekend without any issue
 

@piter75 commited the emmc fix into Armbian and built Armbian 21.08.2 which is already available through the Armbian mirrors (via 'apt update && apt upgrade').
 
It is save to upgrade your Buster or Bullseye installation to Armbian 21.08.2 - but emmc read speed will be about 50% what it used to be.
 
You can roll back to the previous linux 5.10.43 kernel if you don't like that - just install those files with 'dpkg -i *.deb'.
 

@piter75 commited the emmc fix into Armbian and built Armbian 21.08.2 which is already available through the Armbian mirrors (via 'apt update && apt upgrade').
 
It is save to upgrade your Buster or Bullseye installation to Armbian 21.08.2 - but emmc read speed will be about 50% what it used to be.
 
You can roll back to the previous linux 5.10.43 kernel if you don't like that - just install those files with 'dpkg -i *.deb'.
 

@piter75 commited the emmc fix into Armbian and built Armbian 21.08.2 which is already available through the Armbian mirrors (via 'apt update && apt upgrade').
 
It is save to upgrade your Buster or Bullseye installation to Armbian 21.08.2 - but emmc read speed will be about 50% what it used to be.
 
You can roll back to the previous linux 5.10.43 kernel if you don't like that - just install those files with 'dpkg -i *.deb'.
 

Really ?
If you are on macOS Big Sur all the drivers and apps are already there. If you need to access the serial console of your Helios64, just connect your mac to the USB-C port of your Helios64. A device such as  /dev/tty.usbserial-XXXXXXXX will be recognised by macOS. All you need to do then is to enter the following into the Terminal of your mac (X to be replaced):
 
screen /dev/tty.usbserial-XXXXXXXX 1500000 -L  
Edit: If the 'screen' command on macOS does not show the output of the bootloader (scrambled characters) you could use the app serial. The only thing you need to configure is to set the serial speed manually to 1500000 bps.
 
If someone would like to contribute in kernel testing - the Armbian build system is very easy to install and use. All you need is an Ubuntu 21.04 (amd64) installation. All the rest is explained here. To compile your own kernel is then as simple as this:
./compile.sh BOARD=helios64 BRANCH=current KERNEL_ONLY=yes RELEASE=bullseye  

@piter75 commited the emmc fix into Armbian and built Armbian 21.08.2 which is already available through the Armbian mirrors (via 'apt update && apt upgrade').
 
It is save to upgrade your Buster or Bullseye installation to Armbian 21.08.2 - but emmc read speed will be about 50% what it used to be.
 
You can roll back to the previous linux 5.10.43 kernel if you don't like that - just install those files with 'dpkg -i *.deb'.
 

Really ?
If you are on macOS Big Sur all the drivers and apps are already there. If you need to access the serial console of your Helios64, just connect your mac to the USB-C port of your Helios64. A device such as  /dev/tty.usbserial-XXXXXXXX will be recognised by macOS. All you need to do then is to enter the following into the Terminal of your mac (X to be replaced):
 
screen /dev/tty.usbserial-XXXXXXXX 1500000 -L  
Edit: If the 'screen' command on macOS does not show the output of the bootloader (scrambled characters) you could use the app serial. The only thing you need to configure is to set the serial speed manually to 1500000 bps.
 
If someone would like to contribute in kernel testing - the Armbian build system is very easy to install and use. All you need is an Ubuntu 21.04 (amd64) installation. All the rest is explained here. To compile your own kernel is then as simple as this:
./compile.sh BOARD=helios64 BRANCH=current KERNEL_ONLY=yes RELEASE=bullseye  

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.

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.