snakekick

mind the voltage changes I am uneasy to push to main until I either get no more crashes for a long long time or the issue is nailed down to its cause.
I might revisit this choice.
I plan to have the emmc hs400 fix in Armbian and vanilla linux. Probably not for the august Armbian release but I expect for the next one.

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.

Started work on syncing the helios64 dts to upstream for 6.9: https://github.com/prahal/build/tree/helios64-6.9 .
 
I removed the overclock disabling patch as the overclock as it disables an overclock that is at least nowadays not in the included rk3399-opp.dtsi (ie cluster0 has no opp6 and cluster no opp8). It was not a high priority beforehand but as the helios64 dts starts to change, thus carries unnecessary work.
 
The pachtset applies. The helios64 dts compile fine to dtb.
Kernel built and booted. (see below for network connection, ie ethernet MAC fixup)
 
There are not many functional changes on my side (there are in upstream dts). There are a few differences with upstream dts I did not bring as I don't know if they are leftover from the initial patch set or new fixups. But this could already have been an issue before 3.9 for most of these changes (there is at least a new upstream change 93b36e1d3748c352a70c69aa378715e6572e51d1  "arm64: dts: rockchip: Fix USB interface compatible string on kobol-helios64") I brought forward.
I also brought in vcc3v0_sd node "enable-active-high;"  and "gpio = <&gpio0 RK_PA1 GPIO_ACTIVE_HIGH>;".
 
 
Beware.
ethernet MAC change (now working as designed). The fact I kept the aliases from upstream fixes the ability for the eth0 (then renamed to end0 by armbian-hardware-optimization) ethernet mac - grabbed from OTP via SPI in u-boot to be applied. Thus if you bound the MAC address that was generated by the kernel instead of from the hardware to a host and IP, you will have to find the new IP assigned by the DHCP server to connect to the helios64.
I believe this is fine for edge even if not for current (so should be good for 6.9?).

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

@ebin-devI discussed with on IRC #u-boot and I believe one board designer told me that there could be issue with the regulatorh hardware design  (CPU big). He suggested me to up the voltage to max after looking at the schematics (that are available in the wiki in the left pane documents section) to try if it fixed my crashes and this indeed fixed lost of them. That is I first tried every opp-table-1 ie cpu-b at 1.2V then I tried with voltage closer to the vanilla rk3399 ones. In the end I was able to run the cpufreq switching test I gave you 100 times without a crash with upping all the opp voltages for cpu-b by 75mV. Any of the opp  run mostly stable with only 50mV but in I still had crashes. So up 75mV looks fine.
I still have crash around once a day but not with my cpufreq test case as far as I know. I am now on on demand cpufreq governor with freq from 408MHz to 1.8GHz.
 
Still I would really like to be able to be able to reproduce the crashes I still get. They might be from gpu opp voltages as they have the same  hardware design as the CPU-big. Or something else. But I doubt the kernel is involved except that any kernel version might stress the board less.
But for one I had added a big delay between CPU-b frequent switching and still had crashes, so I doubt the speed has anything to do with it.
And in my test I tried with all cpu-b OPP voltages to 1.2V except even the lowest one and was still able to get random crashes with my cpufreq test case, so I doubt this had anything to do with high freq. Only that 1.6GHz was the one the most sensible to a voltage without 75mV up from upstream rk3399 OPP voltage values. And 408/600 were the less likely to crash but still crashed from time to time.
 
I don't know if you know how to redefine the opp voltage values for cpu-b. I will try to post you my patch asap ( currently on my phone).

@FlolmI am currently also reinstalling a Helios64 and following the instructions of  @ebin-dev from here.
As soon as i'm done i'll share a more detailed tutorial for dummies
 
edit:
thx to @ebin-dev for your instructions, I was able to run it successfully on my Helios64 and have written down the individual steps in more detail so that others can also do it without major problems.
 
1. image Armbian_23.5.4_Helios64_bookworm_current_6.1.36 flashing:
Download and flash the image on your microSD with balenaEtcher or something similar...
https://fi.mirror.armbian.de/archive/helios64/archive/Armbian_23.5.4_Helios64_bookworm_current_6.1.36.img.xz
 
2. set CPU limits:
Run armbian-config
-> System
-> CPU
And set:
Min CPU speed = 408000 MHz
Max CPU speed = 1200000 MHz
CPU governor = on demand
 
3. disable Armbian Updates:
you can either rename the source file or deactivate the line in the file with # at the beginning...
root@helios64:~# cd /etc/apt/sources.list.d root@helios64:/etc/apt/sources.list.d# ls -l total 4 -rw-rw-r-- 1 root root 117 Jun 30 2023 armbian.list root@helios64:/etc/apt/sources.list.d# mv armbian.list armbian.list.disabled root@helios64:/etc/apt/sources.list.d# ls -l total 4 -rw-rw-r-- 1 root root 117 Jun 30 2023 armbian.list.disabled root@helios64:/etc/apt/sources.list.d# cat armbian.list.disabled # deb [signed-by=/usr/share/keyrings/armbian.gpg] http://apt.armbian.com bookworm main bookworm-utils bookworm-desktop  
4. Download and copy rtl_nic firmware files:
Download this 9 files...
rtl8125b-2.fw rtl8153a-2.fw rtl8153a-3.fw rtl8153a-4.fw rtl8153b-2.fw rtl8153c-1.fw rtl8156a-2.fw rtl8156b-2.fw rtl8168h-2.fw ... from here...
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/rtl_nic
... and copy & replace the files to the directory /lib/firmware/rtl_nic on your helios64.
 
5. Upgrade kernel to 6.6.8:
Download the 6.6.8 deb files from here...
https://www.dropbox.com/scl/fi/9s2saibn9oezqmhfwyu3i/debs-6.6.8.zip?rlkey=hkkrxjelitsto0f0zw6wft6pq&dl=1
... and copy the 3 files to your helios64.
Execute these 4 commands one after the other...
apt install libelf-dev dpkg -i linux-dtb-edge-rockchip64_24.2.0-trunk.225_arm64__6.6.8-S4c96-Dbc51-Pb65c-C891dHfe66-HK01ba-Vc222-B1743-R448a.deb dpkg -i linux-image-edge-rockchip64_24.2.0-trunk.225_arm64__6.6.8-S4c96-Dbc51-Pb65c-C891dHfe66-HK01ba-Vc222-B1743-R448a.deb dpkg -i linux-headers-edge-rockchip64_24.2.0-trunk.225_arm64__6.6.8-S4c96-Dbc51-Pb65c-C891dHfe66-HK01ba-Vc222-B1743-R448a.deb  
6. update bootloader on eMMC:
Download the deb file from here...
https://imola.armbian.com/apt/pool/main/l/linux-u-boot-helios64-edge/linux-u-boot-edge-helios64_22.02.1_arm64.deb
... and copy the file to your helios64.
Execute these 6 commands one after the other...
dpkg -x linux-u-boot-edge-helios64_22.02.1_arm64.deb linux-u-boot-edge-helios64_22.02.1_arm64/ cd linux-u-boot-edge-helios64_22.02.1_arm64/usr/lib/linux-u-boot-edge-helios64_22.02.1_arm64/ dd if=idbloader.bin of=/dev/mmcblk1 seek=64 conv=notrunc dd if=uboot.img of=/dev/mmcblk1 seek=16384 conv=notrunc dd if=trust.bin of=/dev/mmcblk1 seek=24576 conv=notrunc reboot now  
7. Set nic offload options:
Select the LAN port you are using...
For end0 - 1 GB Port: ethtool -K end0 tso on gso on gro on
For eth1 - 2,5 GB Port: ethtool -K eth1 tso on gso on gro on
... and change the value in the ethtool command after the "-K".
Execute the command ...
root@helios64:~# ethtool -K end0 tso on gso on gro on Actual changes: tx-tcp-segmentation: off [requested on] tx-tcp-ecn-segmentation: off [requested on] tx-tcp-mangleid-segmentation: off [requested on] tx-tcp6-segmentation: off [requested on]  
8. Fix hs400 support and L2 cache information:
Download the dtb file from here...
https://www.dropbox.com/scl/fi/nif2k0027whxky25djqll/rk3399-kobol-helios64.dtb-6.6.8-L2-hs400.zip?rlkey=zq7zw91oem4ugmgmaqfyuxqsa&dl=1
... extract the rk3399-kobol-helios64.dtb-6.6.8-L2-hs400.zip
... rename rk3399-kobol-helios64.dtb-6.6.8-L2-hs400 to rk3399-kobol-helios64.dtb 
... copy & replace the rk3399-kobol-helios64.dtb into /boot/dtb/rockchip
 
9. execute sbc-bench script:
Execute these 3 commands one after the other...
wget https://raw.githubusercontent.com/ThomasKaiser/sbc-bench/master/sbc-bench.sh chmod +x sbc-bench.sh ./sbc-bench.sh -r  
sbc-bench output..
 
10. boot from eMMC:
Run armbian-config
-> System
-> Install
-> 2 Boot from eMMC
-> erase eMMC: Yes
-> 1 ext4
-> poweroff
-> remove microSD
-> boot hopefully from eMMC
 
11. update Debian packages:
apt update && apt upgrade  

The 6.6.8 debs were downloaded from an Armbian mirror and are not modified. Everything you need is explained here: in particular that NFS causes trouble with 6.6.x kernels and that 6.1.71 should be used instead or 5.15.93.
 
To implement hs400 and L2 cache information you can use 'dtc'. For your convenience I attached the dtb for 6.6.8 and 5.15.93 (just copy the matching one to /boot/dtb/rockchip/rk3399-kobol-helios64.dtb).
 
It is essential to flash the bootloader to emmc after you have installed the kernel debs, to perform a cold boot and to run 'sbc-bench -r' at least once.
rk3399-kobol-helios64.dtb-5.15.93-L2-hs400 rk3399-kobol-helios64.dtb-6.6.8-L2-hs400

@prahal Current helios64-u-boot-edge (2023-Dec-28 08:32) is supposed to include the rockchip DDR blob, but unfortunately stable operation of helios64 is still not possible with it: the r8152 is reset very frequently if this bootloader is used (contrary to linux-u-boot-edge-helios64_22.02.1_arm64.deb, were the r8152 is reset only occasionally under load).

One solution to this would be to merge both the old and the new rule into the same file (like I ended up doing above), but I would highly suggest that we package a new version of the bsp with the correct rule in a 21.05.3 version to avoid issues with non-spinning fans. Let me know if I can assist by any means.

Mine is still crashing like a clockwork every 24 hours and leaves me generally with a corrupted OS and data.
 
I know you are a small team and you had to takle many obstacles to release the Helios64, believe me im a fan of your work, product and armbian in general, i m aware of the effort every involved person puts into this project.
 
But i would appreciate a bit more news about the current status of developement.
 
As far as i can see there is no status or developement overview on the current issues, not on your blog nor on twitter.
 
The only information we get are in various topics across the forum on armbian.
 
Is there a possibility to let us know more about the ongoing research and inform us about the progress and persued assumed solutions?
 
Also I wonder if those issues are genreal rk3399 gonvernor etc. problems, or if it applies specifically for the Helios64?
 
Thank you in advance for your reply.

Like many others, I get constant reboots with my Helios.  I'm not sure it's worth me posting logs as a number of people already seem to be doing that.  My question is, does anyone have a stable system?  If so what OS and kernel are you using?  I don't care about latest and greatest features, I just want it to stop hard rebooting.

I seem to have freezes as well. I stayed on the recommended release with zero updates from the default installation. I'm running Sonarr, Radarr, Jackett, Transmission, Samba, NFS server and Zram swap.
 
Linux muzzy 5.8.14-rockchip64 #20.08.10 SMP PREEMPT Tue Oct 13 16:58:01 CEST 2020 aarch64 aarch64 aarch64 GNU/Linux I've also changed the cpufreq config to avoid issues. Locked at 1,2ghz min/max, performance govenor.
It seems like when I do a lot of I/O and put a high load on the cpu, the system just freezes. There's nothing in the syslog but I haven't looked in the serial console.
I'm only running SSD's in this machine, so there's no shortage of bandwidth on the drives. If there's no load, I haven't had one freeze at all. Medium load doesn't seem to be an issue either.
Has anyone tried adding active cooling on the cpu?
I'm guessing this is the same issue that was posted about on the 27th of October in the blog, why hasn't there been an update on it?
 
And for the mods: how can I remove this forum posting limitation, like one post per week or something?

is there any way to send audio through displayport? i installed kodi, just as a database updater, but it fills the log with errors related to the audio system, and i see that aplay doesn't show any audio device, so another question is, is there any way to emulate an audio device?
 
thanks

Hi @snakekick,
USB HDD for snapraid parity, sounds like my setup! You can check with vm_block_dump what is waking up your device: 
 
echo 1 | sudo tee /proc/sys/vm/block_dump Above will enable logging of block device accesses into syslog.
 
If you want to see it happen without flooding your /var/log/syslog:
sudo service rsyslog stop while true ; do dmesg -cT ; done sudo service rsyslog start  
See: Documentation for /proc/sys/vm/* and How to conserve battery power using laptop-mode.
 
You should also check if you have enabled SMART offline auto testing on your HDD; that might also wake up your drive, but this is done by the drive itself:
sudo smartctl -a /dev/sdX | egrep 'offline' sudo smartctl --offlineauto=off /dev/sdX  
Other things that will wake up your drive: temperature monitoring services like hddtemp, you should check if it offers options to not access the drive if it's in standby/sleep mode.  Other things like blkid when used as root, will also check all blockdevices, even if you think it is using cache.
 
What is the brand of USB dock you are using? Perhaps your dock is doing something to the drive to wake it up regularly.
 
Hope that helps,
Groetjes,

IT'S FINALLY HERE...

THE OFFICIAL ROCKCHIP-LEGACY MULTIMEDIA INTEGRATION
 
After two years of using a separate script to enable the multimedia features in RK3399 Legacy Kernel, the whole framework has been incorporated to the official Armbian packaging system. The choice distro for this integration is Debian Buster (see FAQ at the end of this post about the reasons).
 
I. Installation
Download a Armbian Buster Legacy Desktop image for your board, and install it with the standard Armbian method. Install the complete multimedia solution with sudo apt update && sudo apt upgrade sudo apt install media-buster-legacy-rk3399 --install-recommends The switch "--install-recommends" will add the whole Kodi binary addons collection (retro-gaming cores, music visualizations, screensavers, additional media decoders/encoders, vfs, etc.), plus the GLES-to-OpenGL wrapper "gl4es".
 
II. Features
Accelerated GLES/EGL X desktop: No action needed. Accelerated Chromium, with WebGL and video display acceleration: No action needed Desktop video player capable of smooth 4K HEVC-HDR: Use the "Rockchip Gst Player" from the Multimedia menu, or choose it with right-click on the media file. Command-line 4K playing is also possible with "gst-play-1.0 --videosink=kmssink". RKMPP-accelerated MPV: Use normally for standard operation (windowed with mouse-operated GUI). For fullscreen, keyboard-operated mode, use the command line switch "--gpu-context=drm" (this will allow you to play smooth 4K).
        - See instructions below, in the next post, for playing YouTube videos up to 4K with this MPV.
ISP Camera with real-time h.264/1080p HW encoding: Using the Gstreamer Plugin. Check this wiki for instructions on how to use it. Most of it applies to Armbian, except for the selection of ov5647/imx219 camera, which must be done using DT overlays. OpenCL 1.2 support: It will be fully functional, no further action needed. You can download some tests and examples from this link. Kodi 18.9 Leia with full RKMPP+GBM acceleration, 4K-HDR capable: You can start it from LightDM menu as your user account: 


Alternatively, you can also run it as a system service with these command lines: sudo systemctl disable lightdm sudo systemctl enable kodi-gbm sudo reboot Full collection of Kodi binary add-ons: Includes retrogaming cores, media encoders and decoders, PVR, screensavers, vfs and audio visualizations. They are all installed with the package "kodi-addons-full", but are disabled by default. They need to be enabled individually within the Kodi GUI. OpenGL 2.1 support through the gl4es wrapper: It is installed with the package "gl4es", with no further action needed.  
III. Sources
This is the list of the sources used for the packages:
 
IV. FAQ
¿Why did you use Debian Buster as a base for this implementation?
It was the most appropriate for several reasons. Upstream Rockchip-Linux developers use Debian buster, so the software could be ported with less modifications than if we chose a different distro. Besides, it is a completely stable distro, unlike Bullseye, which is a moving target as of today. It also has Chromium as a package, unlike Focal that uses snap instead. For last, it has a good backports repo, with several libs that would otherwise need to be compiled and maintained if we chose, for example, Focal.
  ¿Why Legacy instead of Mainline?
This is an implementation based on the vendor's BSP kernel. It has been tested and is reliable, which many people will prefer rather than having a bleeding-edge, less stable implementation. In addition to that, Mainline upstream multimedia support is still a WIP, and lacks many features that are only present on Legacy kernels.
  ¿Will you add new features to this implementation?
No, this implementation will only receive bug fixes if necessary. From now on, all multimedia work will be focused on Mainline and recent distros (like Focal or Bullseye). All new features will go there.

Hello,

I am quite new to this topic, and I have found it to be quite complex. I primarily work with tiny MCUs and RTOSes, but I am enjoying the Linux space so far.
 
In essence I would like to use the Mali GPU that is embedded within the RK3399 of the Helios64 for hardware transcoding. This isn't a novel idea, as shown by these sources:
https://forum.armbian.com/topic/9272-development-rk3399-media-script/
https://emby.media/community/index.php?/topic/66675-36078-transcoding-rockpro64/
 
I am using Jellying, and in so FFMPEG to decode/encode the data streams. It seems that V4L2 is supported for hardware ecoding/decoding in the FFMPEG package, but in my experience doesn't appropriately work with the Mesa Panfrost drivers (https://wiki.debian.org/PanfrostLima) and the ARM drivers fail to compile with the kernel headers provided by the armbian-config script. I like the idea of having hardware accelerated transcoding, and I'm not even interested in 4K content, but my helios64 fails to transcode h265 (HEVC) to h264 at a playable rate. Secondly I like to have watch-togethers with my friends and I have to use my power-hungry PC for this. Of course I can introduce new hardware to do this like an arm64 laptop, but I like the all-in-one solution, and I simply can't be the only one that feels this way.

Has anyone had success with hardware acceleration? Any ROE or ongoing efforts?

Thanks,
Victor