ebin-dev

@mrjpaxton Dist-upgrade(ing) from bullseye to bookworm did finally complete successfully. However, one should consider that device names have changed (otherwise your system may end up offline 🙂) the new interface names are: # interface names (bookworm) sd: /dev/mmcblk0 emmc: /dev/mmcblk1 eth0: end0 (1GBase-T ethernet) eth1: end1 (2.5GBase-T ethernet) P.S.: I am currently setting up bookworm from scratch starting from the fresh image to get rid of the stuff that accumulated during the last years.

@mrjpaxton I am about to upgrade linux from 5.10 to 6.1 now and if that works to dist-upgrade bullseye to bookworm. Just to prevent someone from telling us that this is not supported by Armbian - we already know that. Just in case you would like to try, here is a link to the most recent Armbian 23.08.0 - 6.1.45 bookworm image including all the linux-6.1.45 deb packages. You could also start with the fresh bookworm image, in case dist-upgrade to bookworm does not complete successfully with your installation. Armbian 23.08.0 - 6.1.45 bookworm image was compiled for Helios64 using the Armbian build system as mentioned in the parallel thread .

@prahal@balbes150 I just gave it a try and built a complete bookworm image (Armbian_23.08.0-trunk_Helios64_bookworm_current_6.1.49.img and corresponding linux 6.1.49 deb packages). The bookworm image boots without any issues. Thank you very much for your contributions! Now there should be an upgrade path from Debian bullseye to bookworm once linux is upgraded to 6.1.49. If that does not complete successfully I will set up the whole system starting from the fresh bookworm image. git clone https://github.com/armbian/build.git cd build ./compile.sh BOARD=helios64 BRANCH=current RELEASE=bookworm KERNEL_CONFIGURE=no P.S.: There is a more recent update on armbian.com/helios64

@privilegejunkie I am still on Linux 5.10.43-rockchip64 #21.05.4 SMP PREEMPT Wed Jun 16 08:02:12 UTC 2021 aarch64 GNU/Linux / debian bullseye 11.7. Would you provide a download link to the kernel you are using ? I could easily test it with debian bullseye. However, debian bookworm is about to be released and it comes with linux 6.1 LTS. So it would make some sense to test 6.1 kernels too for the ones who intend to upgrade.

@prahal Thanks for fixing this bug ! You mentioned, that you are investigating the emmc hs400 issue. Once you (or someone else) found a solution to it, please let us know. We could then try to test newer versions of the linux kernel and see what remains to be done.

not necessary - not even desired by most of the helios64 users

Just put a # in front of the line in armbian.list (should have the same effect as freeze kernel in armbian-config): cat /etc/apt/sources.list.d/armbian.list # deb http://apt.armbian.com bullseye main bullseye-utils bullseye-desktop Regarding a new kernel: the new ones (newer than 5.10.43) do not support emmc speed HS400, seem to have issues with the 2.5Gb/s interface (transfer rates are about half the speed), and the switch to the new mainlined bootloader is essentially untested... Would be wise to focus on this - besides the general stability.

@bunducafe I am still running this system: Armbian 21.08.2 Bullseye with Linux 5.10.43-rockchip64. The Armbian image should still be available in the archive and I downgraded linux to 5.10.43, since this is the last version able to access emmc with hs400. Since there is no maintainer I have disabled any updates through the Armbian channel (in /etc/apt/sources.list.d/armbian.list). Debian Bullseye updates are not affected in any way by this and still arrive from time to time. That is fine for now.

@grek Would you have the possibility to test the speed of the 2.5 Gb/s Ethernet Interface with your system ?

Rock 5 B (Pico ITX - 8-core) is really powerful and power efficient (8nm lithography). I have preordered one.

I just had an issue with the 2.5G interface after the latest update to Armbian Bullseye 22.02.01 (linux 5.15.25): The 2.5G Interface would not appear to work as expected anymore. A 12.225 GB test file was transferred from Helios64 to a client via a 2.5G switch using netatalk with only about 120 MB/s. The system I am normally using ( Armbian 21.08.2 Bullseye, linux downgraded to 5.10.43), transfers the file with 271 MB/s (as expected). Here are the related dmesg messages : [ 11.159252] r8152 2-1.4:1.0: Direct firmware load for rtl_nic/rtl8156a-2.fw failed with error -2 [ 11.159293] r8152 2-1.4:1.0: unable to load firmware patch rtl_nic/rtl8156a-2.fw (-2) [ 11.199745] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): netif_napi_add() called with weight 256 [ 11.215517] r8152 2-1.4:1.0 eth1: v1.12.12 [ 11.215734] usbcore: registered new interface driver r8152 [ 14.606490] r8152 2-1.4:1.0 eth1: Promiscuous mode enabled [ 14.606732] r8152 2-1.4:1.0 eth1: carrier on Is there anyone observing the same issue ?

Interesting ! I tried again with a fresh Armbian Bullseye Image (Armbian_21.08.2_Helios64_bullseye_current_5.10.63.img.xz) on SD and used apt update && apt upgrade to install the latest kernel 5.15.25. After a reboot, an rsync from SD to another SD attached to the USB port worked perfectly. I have noticed today that SD and emmc device names have changed between linux 5.10.xx and linux 5.15.yy from /dev/mmcblk2p1 (emmc) and /dev/mmcblk1p1 (SD) to /dev/mmcblk1p1 and /dev/mmcblk0p1 respectively. Since my backup scripts use the device names they could not work correctly anymore with kernel 5.15.yy. MEA CULPA. All device names are now replaced by their corresponding UUIDs in the backup scripts - so that this can't happen again. So you can update your buster or bullseye installation to the latest Armbian kernel (no rsync issues) - but be aware that there are still some other issues to be resolved, in particular if you are using zfs-dkms (see the parallel threads).

You can downgrade linux from 5.10.63 to 5.10.43: just install those files with dpkg -i *.deb (headers included, full emmc speed).

Hi there, the emmc issues were solved by reducing read/write speed by a factor of 2 (thanks to @piter75). Unfortunately this is still the case with newer kernels 5.15.xx. I am still using linux 5.10.43 without any issues and without the emmc speed limitation (Armbian 21.08.2 Bullseye with Linux 5.10.43-rockchip64). Upgrading from Buster to Bullseye should work, but your mileage may vary depending on your specific Buster installation. The upgrade will install the newest kernel 5.15.25. I had troubles at least with rsync in this context. Alternatively you can grab the latest Armbian Bullseye Image (Armbian_21.08.2_Helios64_bullseye_current_5.10.63.img.xz) from the archive and downgrade to linux 5.10.43. To do that you just need to download those files and install them with 'dpkg -i *.deb' and disable any further Armbian updates in /etc/apt/sources.list.d/armbian.list . Debian updates will still arrive ... The system on SD can be transferred to emmc. Cheers!

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.

Kobol stopped operations (partly due to the chip shortage) and @gprovost himself did not exclude that Kobol may resume operations some time again. I am still hoping that we will see a follow-up of Helios64 based on a successor of the rk3399 developed by Kobol.

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

@flowerThe 2.5G interface (eth1) indeed operates absolutely reliable if connected to a 2.5G switch - even without the hardware mod and using current Armbian Bullseye (kernel downgraded to 5.10.43). My interfaces are managed by systemd-networkd - the config files for the bridged setup are attached below. With this configuration the interfaces receive ipv4 and link local ipv6 addresses. Net transfer rates are around 255 MBytes/s (a nice alternative to bonding two 1Gig Ethernet interfaces). Armbian 21.08.6 Bullseye with Linux 5.10.43-rockchip64 # cd /etc/systemd/network/ # ls -la total 20 drwxr-xr-x 2 root root 4096 Nov 16 14:42 . drwxr-xr-x 6 root root 4096 Nov 26 07:00 .. -rw-r--r-- 1 root root 30 Nov 26 2020 br0.netdev -rw-r--r-- 1 root root 233 Oct 10 19:27 br0.network -rw-r--r-- 1 root root 40 Nov 16 14:42 eth0.network # cat br0.netdev [NetDev] Name=br0 Kind=bridge # cat br0.network [Match] Name=br0 [Network] IPForward=yes DHCP=no Address=192.168.xxx.xxx/24 Gateway=192.168.xxx.xxx DNS=192.168.xxx.xxx # cat eth0.network [Match] Name=eth1 [Network] Bridge=br0 # networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 eth0 ether off unmanaged 3 br0 bridge routable configured 4 eth1 ether enslaved configured 5 lxcbr0 bridge no-carrier unmanaged 6 vethpivccu ether degraded unmanaged 6 links listed.

Just recently I purchased a 2.5G switch to improve network bandwidth (and latency). I am really thrilled regarding the performance and stability of Helios64 using the 2.5G interface (eth1). I am currently on Armbian 21.08.3 Bullseye with Linux 5.10.43-rockchip64 (no errors at all). With netatalk as a file server I can access now large files with 255 MByte/s. This is clearly enough to work on files stored on the Helio64 (i.e. accessing RAW images on the remote ssd, processing them on a laptop and writing back the resulting dng and jpg images). Does anyone know if there is a power save state that could be configurerd for eth1 - or is this something that depends entirely on the switch ? Helios64 rocks ! I really hope that the Kobol team will resume operations once the chip shortage is overcome. EDIT: I am using the default cpufreq settings: # cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=408000 MAX_SPEED=1800000 GOVERNOR=ondemand

If you followed the example given by werner it should be mounted to /mount ... Try this: sudo vim /mount/boot/armbianEnv.txt

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

Actually I am currently just exploring. Using Kodi as a headless server to stream to DLNA enabled devices turned out to be suboptimal :-)) . Meanwhile I switched to Plex on the server. For all clients (SmartTV, Computers and iOS Devices) a native Plex app is available for free (except for iOS - a one time fee of 4.99 Euros is required for each device) and I am astonished about the performance and professional look of the system. The installation is configured as non-accessible from the outside - nonetheless the media can be streamed to remote devices coupled to the home network via VPN. Setting up a client-server system with Plex is a "no-brainer". You just have to make sure that the required ports are not used by other servers (port 9090 was used by another media server in my case). I would strongly recommend Plex if you wish to stream content from a (headless) server to various client devices in your home network.

Thank you very much for the hint. Installation of the packages went smoothly on the headless server. After messing around with the configuration files guisettings.xml and advancedsettings.xml I could access the web interface on port 8080 and change the settings, configure some addons etc. However, it would not appear to be possible to add a media library or addons using the web interface - the required functionality is not displayed. Is this a known limitation of the web interface or is this due to a mistake on my side ? As there is no access to any other Kodi GUI on the headless server I am stuck at that point. I am looking forward to test Kodi 19 packages once you found some time to build them.

I am looking for an easy way to install Kodi on a headless server (Helios64 - rk3399). I am not using a legacy kernel but 5.10.43 and Armbian Bullseye. The intention is just to stream videos and display pictures with Kodi to a DLNA enabled smart TV. Any help would be greatly appreciated !