ebin-dev

The voltage values were changed in opp-table-1 - the values used can be found (here) earlier in this thread. The dtb for the 6.6 branch still works fine with them (cache awareness and emmc HS400 speed is also enabled in it). I am currently using it with linux-6.6.79 as it provides the best performance and stability. rockchip64-current was bumped from kernel branch 6.6 to 6.12 (on Dec. 21st) and rockchip64-edge bumped to branch 6.13. These kernel versions are available on beta.armbian.com and any issues with them could be reported here. The downside is that linux-6.6 rockchip64 kernel versions are not built anymore by the current armbian build system. rk3399-kobol-helios64.dtb-6.6.xx-L2-hs400-opp rk3399-kobol-helios64.dtb-6.12.xx-L2-hs400-opp

You can further tune your system (see here). I am on linux 6.6.56 now and use the 6.6.34 dtb with the fixes.

Well, the dtbs contain fixes for the 6.6 and 6.10 branch respectively (see i.e. here). If the 2.5G port of your Helios64 is connected to a device (via a 2.5G switch), where that device is connected using a 2.5G USB-C adapter instead of a standard 1G ethernet plug, the transmission rates between the two devices rise to 2.5Gbit/s full duplex.

These timeout issues are actually linux kernel related (see i.e. here). To get rid of those issues, disable scatter/gather offloading (just execute 'ethtool -K <iface> sg off' ; replace <iface> by your interface name like eth0). But transmission speed will suffer ! With some optimizations the timeout issues also disappear. Dealing with 2.5G traffic is quite a burden on the CPUs! Use jumbo frames. I am using the following content in /etc/rc.local to bind the tasks involved to the big cores (sata (cpu 4) and 2.5g network traffic (cpu 5)). How is your PC connected to your Helios64 ? If you are using an 2.5G USB-C adapter it should contain the latest version of the rtl8156 chip (31.04) (i.e. like this one). #!/bin/sh -e # # rc.local # # This script is executed at the end of each multiuser runlevel. # Make sure that the script will "exit 0" on success or any other # value on error. # # In order to enable or disable this script just change the execution # bits. # # By default this script does nothing. cd /sys/devices/system/cpu/cpufreq for cpufreqpolicy in 0 4 ; do echo 1 > policy${cpufreqpolicy}/ondemand/io_is_busy echo 25 > policy${cpufreqpolicy}/ondemand/up_threshold echo 10 > policy${cpufreqpolicy}/ondemand/sampling_down_factor echo $(cat policy${cpufreqpolicy}/cpuinfo_transition_latency) > policy${cpufreqpolicy}/ondemand/sampling_rate done for i in $(awk -F":" "/ahci/ {print \$1}" < /proc/interrupts | sed 's/\ //g'); do echo 10 > /proc/irq/$i/smp_affinity done for i in $(awk -F":" "/xhci/ {print \$1}" < /proc/interrupts | sed 's/\ //g'); do echo 20 > /proc/irq/$i/smp_affinity done exit 0 rk3399-kobol-helios64.dtb-6.10.2-L2-hs400-opp rk3399-kobol-helios64.dtb-6.6.34-L2-hs400-opp

Download a new system image with linux 6.6.y, flash it to another sd card (just use etcher) and boot from it. I would recommend to copy the dtb from my post (for the 6.6 branch) and execute 'update-initramfs -u'. If you are using the 2.5G interface, replace the rtl firmware in /lib/firmware/rtl_nic. No need to install a new r8152 driver. You can then copy the system from sd to emmc using armbian-config (this also changes the bootloader on emmc) and boot from emmc. (If there are issues with the new bootloader installed on emmc, flash the following u-boot to emmc (linux-u-boot-edge-helios64_22.02.1_arm64) (see here).)

Here is my backup script - it copies the content from the running system - emmc (/) in my case - to sd (/mnt/sd). (create the mount point on emmc if it does not exist: 'mkdir /mnt/sd') As you can see the UUID that starts with 87654321... corresponds to the sd card, and the UUID starting with 12345678... corresponds to emmc. Type 'blkid' to get the UUIDs of your devices and insert them into the script accordingly. Check that the script can be executed (chmod +x backup.sh), insert a formatted sd card (ext4) and let the script run. That`s it. # cat backup.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/* /mnt/sd/* /mnt/ssd/* /mnt/usb/* /mnt/hd/* /run/* # /tmp/* # /root/* EOF exec 2>/dev/null umount /mnt/sd exec 2>&1 mount --uuid 87654321-5709-4000-91ac-099eeefe4685 /mnt/sd rsync -avxSE --delete --exclude-from="install-exclude" / /mnt/sd # change fstab sed -e 's/UUID=12345678-3e1b-4e01-a6be-9ee203b1b54f/UUID=87654321-5709-4000-91ac-099eeefe4685/g' -i /mnt/sd/etc/fstab sed -e 's/UUID=12345678-3e1b-4e01-a6be-9ee203b1b54f/UUID=87654321-5709-4000-91ac-099eeefe4685/g' -i /mnt/sd/boot/armbianEnv.txt umount /mnt/sd rm install-exclude echo "SD - done."

MAC address changed in edge kernels to native hardware address (see here).

Did you update the r8152 firmware (link)? # dmesg | grep r8152 [ 5.245881] usbcore: registered new device driver r8152-cfgselector [ 5.460956] r8152-cfgselector 2-1.4: reset SuperSpeed USB device number 3 using xhci-hcd [ 5.741177] r8152 2-1.4:1.0: load rtl8156a-2 v2 04/27/23 successfully [ 5.795083] r8152 2-1.4:1.0 eth0: v1.12.13

With the voltage changes proposed by @prahal (see 'opp-table 1' earlier in this thread) my system is 100% stable, absolutely reliable (using linux 6.6.x or 6.10.y). There are also others observing this. Attaching drives is handled by the kernel. If that is not working, it may be that the relevant (hotplug) options are not configured.

It seems that the patches are still missing. Until this is fixed you can use my dtb attached for the kernel 6.6.x branch (just copy it to /boot/dtb/rockchip/rk3399-kobol-helios64.dtb). The linux files (linux-image, linux-header, linux-dtb) can be downloaded from beta.armbian.com (to be installed with 'dpkg -i linux*). Copy the attached 6.6 dtb to its location and run 'update-initramfs -u' and reboot. Thats it. I am on 6.10.2 right now - I also include the dtb for the 6.10 branch below. rk3399-kobol-helios64.dtb-6.6.34-L2-hs400-opp rk3399-kobol-helios64.dtb-6.10.2-L2-hs400-opp

To install the latest kernel 6.6.69 just load the three files (image, dtb, headers) into a single folder, and execute 'dpkg -i linux*' inside that folder and reboot.

Current kernel versions (linux, dtb, headers) for helios64 can be downloaded from beta.armbian.com. I am currently using 6.6.39 ...

You may have noticed that Helios64 was moved to the supported section again about two weeks ago: thanks to @prahal who volunteers as a maintainer ! I think this should be appreciated i.e. by reacting to his last message two postings earlier.

@prahal Current kernel 6.9.6 works just fine on Helios64 (headless) thanks to your PR. I am still using linux-u-boot-edge-helios64_22.02.1_arm64. Level2 cache-info is now included: # lscpu -C NAME ONE-SIZE ALL-SIZE WAYS TYPE LEVEL SETS PHY-LINE COHERENCY-SIZE L1d 32K 192K 4 Data 1 128 64 L1i 32K 224K 2 Instruction 1 256 64 L2 512K 1.5M 16 Unified 2 512 64 The modified dtb (hs400, modified opp-table-1) is attached below (copy to /boot/dtb/rockchip/rk3399-kobol-helios64.dtb ; execute 'update-initramfs -u'). P.S.: sata performance needs to be addressed and helios64-heartbeat-led.service is not working rk3399-kobol-helios64.dtb-6.9.6-L2-hs400-opp

Since linux-u-boot-edge-helios64_22.02.1_arm64 does'nt seem to be downloadable anymore from Armbian servers, I added a download link to it from my dropbox account.

@prahal There are two versions of the bootloader in the repository (edge and current). I just tried the current u-boot from the repository. It works but dmesg outputs seven of the following messages: [ 9.674633] rockchip-i2s ff8a0000.i2s: Could not register PCM This note mentions that such error messages could mean that DMA and sound are missing in the linux kernel, could this be ignored ? P.S.: Those messages are not thrown if the recommended bootloader (linux-u-boot-edge-helios64_22.02.1_arm64) is flashed to emmc.

Checking that note reveals: Note: at the current status, helios64 board patches have been disabled because the base device tree does not apply on kernel 6.9. So helios64 is cancelled as of linux 6.9.x until someone takes care of the issue. Thank you very much.

MergerFS is on github - there is a section 'systemd mount' in the ReadMe with an mergerfs.service example...

You probably just have to change the systemd service file nfs-server.service: in its [UNIT] section add the mergerFs service file (see also here) : # nfs-server.service # replace 'mergerfs.service' by the name of your MergerFS service file [Unit] After=mergerfs.service Requires=mergerfs.service

@specs A current 6.9.0 edge kernel (collabora version) is availale on beta.armbian.com (linux-dtb and linux-headers are available too). They can be downloaded to the filesystem using 'wget <URL>' and installed via 'dpkg -i linux*' (without armbian-config). After updating Armbian 24.2.1 (minimal) from linux 5.10.160 to 6.9.0: (system on emmc, data on a 4TB sata ssd (m.2)) ____ _ ____ ____ | _ \ ___ ___| | __ | ___|| __ ) | |_) / _ \ / __| |/ / |___ \| _ \ | _ < (_) | (__| < ___) | |_) | |_| \_\___/ \___|_|\_\ |____/|____/ Welcome to Armbian 24.2.1 Bookworm with Linux 6.9.0-collabora-rockchip-rk3588 No end-user support: community creations System load: 1% Up time: 27 min Memory usage: 3% of 7.35G IP: 192.168.xx.31 CPU temp: 45°C Usage of /: 33% of 14G I tried a network performance benchmark and it rocks: 2x 2.34 Gbits/s (bidirectional) ! (armbian-hardware-optimize disabled) # ./iperf3 -c 192.168.xx.31 -p 5201 (client -> rock 5b) Connecting to host 192.168.xx.31, port 5201 [ 5] local 192.168.xx.54 port 63943 connected to 192.168.xx.31 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.01 sec 284 MBytes 2.37 Gbits/sec [ 5] 1.01-2.00 sec 280 MBytes 2.35 Gbits/sec [ 5] 2.00-3.00 sec 280 MBytes 2.35 Gbits/sec [ 5] 3.00-4.00 sec 281 MBytes 2.35 Gbits/sec [ 5] 4.00-5.00 sec 281 MBytes 2.35 Gbits/sec [ 5] 5.00-6.01 sec 282 MBytes 2.35 Gbits/sec [ 5] 6.01-7.00 sec 280 MBytes 2.35 Gbits/sec [ 5] 7.00-8.00 sec 281 MBytes 2.35 Gbits/sec [ 5] 8.00-9.00 sec 281 MBytes 2.35 Gbits/sec [ 5] 9.00-10.00 sec 280 MBytes 2.35 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 2.74 GBytes 2.36 Gbits/sec sender [ 5] 0.00-10.01 sec 2.74 GBytes 2.35 Gbits/sec receiver # ./iperf3 -c 192.168.xx.31 -p 5201 -R (rock 5b -> client) Connecting to host 192.168.xx.31, port 5201 Reverse mode, remote host 192.168.xx.31 is sending [ 5] local 192.168.xx.54 port 63945 connected to 192.168.xx.31 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.01 sec 279 MBytes 2.33 Gbits/sec [ 5] 1.01-2.01 sec 281 MBytes 2.35 Gbits/sec [ 5] 2.01-3.01 sec 280 MBytes 2.35 Gbits/sec [ 5] 3.01-4.01 sec 281 MBytes 2.35 Gbits/sec [ 5] 4.01-5.00 sec 280 MBytes 2.35 Gbits/sec [ 5] 5.00-6.01 sec 281 MBytes 2.35 Gbits/sec [ 5] 6.01-7.01 sec 280 MBytes 2.35 Gbits/sec [ 5] 7.01-8.01 sec 281 MBytes 2.35 Gbits/sec [ 5] 8.01-9.01 sec 280 MBytes 2.35 Gbits/sec [ 5] 9.01-10.01 sec 281 MBytes 2.35 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.01 sec 2.74 GBytes 2.35 Gbits/sec 2 sender [ 5] 0.00-10.01 sec 2.74 GBytes 2.35 Gbits/sec receiver #./iperf3 -c 192.168.xx.31 -p 5201 --bidir (bidirectional) Connecting to host 192.168.xx.31, port 5201 [ 5] local 192.168.xx.54 port 63948 connected to 192.168.xx.31 port 5201 [ 7] local 192.168.xx.54 port 63949 connected to 192.168.xx.31 port 5201 [ ID][Role] Interval Transfer Bitrate [ 5][TX-C] 0.00-1.00 sec 278 MBytes 2.33 Gbits/sec [ 7][RX-C] 0.00-1.00 sec 273 MBytes 2.29 Gbits/sec [ 5][TX-C] 1.00-2.01 sec 280 MBytes 2.34 Gbits/sec [ 7][RX-C] 1.00-2.01 sec 281 MBytes 2.35 Gbits/sec [ 5][TX-C] 2.01-3.00 sec 278 MBytes 2.34 Gbits/sec [ 7][RX-C] 2.01-3.00 sec 279 MBytes 2.35 Gbits/sec [ 5][TX-C] 3.00-4.01 sec 280 MBytes 2.34 Gbits/sec [ 7][RX-C] 3.00-4.01 sec 281 MBytes 2.35 Gbits/sec [ 5][TX-C] 4.01-5.01 sec 279 MBytes 2.34 Gbits/sec [ 7][RX-C] 4.01-5.01 sec 280 MBytes 2.35 Gbits/sec [ 5][TX-C] 5.01-6.01 sec 279 MBytes 2.34 Gbits/sec [ 7][RX-C] 5.01-6.01 sec 280 MBytes 2.35 Gbits/sec [ 5][TX-C] 6.01-7.01 sec 279 MBytes 2.34 Gbits/sec [ 7][RX-C] 6.01-7.01 sec 280 MBytes 2.35 Gbits/sec [ 5][TX-C] 7.01-8.00 sec 278 MBytes 2.34 Gbits/sec [ 7][RX-C] 7.01-8.00 sec 279 MBytes 2.35 Gbits/sec [ 5][TX-C] 8.00-9.01 sec 280 MBytes 2.34 Gbits/sec [ 7][RX-C] 8.00-9.01 sec 281 MBytes 2.35 Gbits/sec [ 5][TX-C] 9.01-10.01 sec 279 MBytes 2.34 Gbits/sec [ 7][RX-C] 9.01-10.01 sec 280 MBytes 2.35 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID][Role] Interval Transfer Bitrate Retr [ 5][TX-C] 0.00-10.01 sec 2.72 GBytes 2.34 Gbits/sec sender [ 5][TX-C] 0.00-10.01 sec 2.72 GBytes 2.34 Gbits/sec receiver [ 7][RX-C] 0.00-10.01 sec 2.73 GBytes 2.35 Gbits/sec 1 sender [ 7][RX-C] 0.00-10.01 sec 2.73 GBytes 2.34 Gbits/sec receiver

Sorry - I am probably the only one who is interested in network performance of the 2.5G interface (theoretical max 2.35Gbit/s). (iperf 3.17.1 measurements attached)

Just a remark: setting MIN_SPEED to 600 MHz would have NO effect on power consumption but required frequency switching would be less: switching between 408 and 600MHz would be avoided and the system could transition directly from 600 MHz to the highest frequency (essentially switching only between two states for each cpu). The huge power savings are impressive!

Due to its current status I have disabled armbian-hardware-optimization (some 'volunteers' are needed to fix it) and run the following code in /etc/rc.local instead. Alternatively you could seek the line 'echo 200000' in armbian-hardware-optimization and change the lines around it accordingly. @SIGSEGV Yes - thereby you set the sampling_rates per cpu cluster to 40000 and 51000 on the current kernel (actually by the line starting with 'echo $(cat ...' ). #!/bin/sh -e # # rc.local # # This script is executed at the end of each multiuser runlevel. # Make sure that the script will "exit 0" on success or any other # value on error. # # In order to enable or disable this script just change the execution # bits. # # By default this script does nothing. cd /sys/devices/system/cpu/cpufreq for cpufreqpolicy in 0 4 ; do echo 1 > policy${cpufreqpolicy}/ondemand/io_is_busy echo 25 > policy${cpufreqpolicy}/ondemand/up_threshold echo 10 > policy${cpufreqpolicy}/ondemand/sampling_down_factor echo $(cat policy${cpufreqpolicy}/cpuinfo_transition_latency) > policy${cpufreqpolicy}/ondemand/sampling_rate done for i in $(awk -F":" "/ahci/ {print \$1}" < /proc/interrupts | sed 's/\ //g'); do echo 30 > /proc/irq/$i/smp_affinity done for i in $(awk -F":" "/xhci/ {print \$1}" < /proc/interrupts | sed 's/\ //g'); do echo 20 > /proc/irq/$i/smp_affinity done exit 0

Actually the changes to the dtb were figured out and were proposed by @prahal and therefore it would be up to Prahal to submit a PR. From my perspective there is nothing against a PR right now as the changes are sufficiently tested and have a very positive effect on stability.

There are new Armbian 24.05 images available on the Helios64 download page: both images Bookworm minimal and Jammy Desktop are based on linux 6.6.30 (download them !). Again, the rtl_nic firmware (in /lib/firmware/rtl_nic) should be replaced by the version downloaded from git.kernel.org, such that the 2.5G LAN interface works correctly. I would also recommend to copy the dtb attached below to /boot/dtb/rockchip/rk3399-kobol-helios64.dtb (execute 'update-initramfs -u' after that). It includes the 75mV bump of the opp states for the fast cores as suggested by @prahal, it enables the L2 cache info and it enables hs400 speed on emmc again. In particular the 75mV bump has a very positive effect on stability. The bootloader that comes with it would appear to contain the Rockchip DDR blob. It should be fine. If you have an issue with u-boot, just flash linux-u-boot-edge-helios64_22.02.1_arm64 as recommended before. The cpufreq ondemand governor is still the best choice. Good settings are # cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=600000 MAX_SPEED=1800000 GOVERNOR=ondemand Enjoy. P.S.: If you like a system more responsive to server tasks or push the 2.5G interface to the limits, some fine tuning is helpful. rk3399-kobol-helios64.dtb-6.6.30-L2-hs400-opp