Gammel

Thanks for the initiative with the PR. 
 
Here is what happens:
The cpufreqpolicy sets a generic value for the sampling_rate of 200000 (this is how often the governor’s worker routine should run, in microseconds). The sampling_rate should be set to a nominal value close to the cpuinfo_transition_latency (49000 and 40000 nanoseconds for the clusters of rk3399) such that it is effectively about 1000 times as large. 
For rk3399 boards the cluster sampling_rates of 49000 (big) and 40000 (little) are very responsive and not too demanding for the cpus. In that case no problems occur if io_is_busy is set to 1 !
 
I added a comment to PR6507 and requested that the sampling_rate should be a parameter (per cpu cluster) and be set to the value of the cpuinfo_transition_latency of that cpu.
 
The fine tuned values for Helios64 are those (io_is_busy set to 1 again, sampling_rate set to more responsive values):
 
for cpufreqpolicy in 0 4 ; do echo 1 > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/io_is_busy echo 25 > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/up_threshold echo 10 > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/sampling_down_factor echo $(cat /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/cpuinfo_transition_latency) > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/sampling_rate done  
Edit: With these changes the timeout issues of the 2.5G interface are resolved for 6.6.29 and 6.6.30 too.
Helios64 is one of the best arm based NAS systems I have seen so far. I am not going to replace it anytime soon.

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

Seeing how well the voltage hacks works on your boards I will include them in armbian (even though I still get crashes on my own board with only this 75mV hack, even though way less).
But not upstream (I am close to sending the eMMC fix upstream, I only need to read the backlog there anew to avoid too much back and forth so the patch is up to the standard). at least until I sort out why they work (I was told to try them by a board designer that told me there was a design issue with the voltage regulator which I am not up to sort out. But I checked other rk3399 armbian boards'schematics and as far as I understand they have the same design. So either all of these boards are broken and are somewhat stable for an unknown reason (maybe less stress on the big CPUs) or I misunderstood what was wrong with helios64 hardware. I need to talk to an hardware engineer.
Also I try to sort out a few other issues with other softwares and hardwares. And a few other issues. But I expect to have those in for mid October, maybe 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?).

si it can help you for a nanopi neo3
you can write a script like 
sudo nano extract_mac.sh
#!/bin/bash # Extraire l'adresse MAC de l'EEPROM mac_address="" mac_address+="$(sudo i2cget -y -f 0 0x51 0xfa c):$(sudo i2cget -y -f 0 0x51 0xfb c)" mac_address+=:"$(sudo i2cget -y -f 0 0x51 0xfc c):$(sudo i2cget -y -f 0 0x51 0xfd c)" mac_address+=:"$(sudo i2cget -y -f 0 0x51 0xfe c):$(sudo i2cget -y -f 0 0x51 0xff c)" # Supprimer les préfixes "0x" mac_address="${mac_address//0x/}" mac_address=$(echo $mac_address | tr '[:lower:]' '[:upper:]') echo "MAC address: $mac_address" # Extraire l'adresse MAC du fichier de configuration NetworkManager configured_mac_address="$(sudo grep "mac-address=" /etc/NetworkManager/system-connections/Wired\ connection\ 1.nmconnection | cut -d "=" -f 2)" # configured_mac_address="${configured_mac_address//:/}" echo "configured mac address: $configured_mac_address" # Comparer les adresses MAC if [[ "$mac_address" != "$configured_mac_address" ]]; then echo "Les adresses MAC sont différentes. Mise à jour nécessaire." # Mettre à jour le fichier de configuration NetworkManager avec la nouvelle adresse MAC sudo sed -i "s/mac-address=.*/mac-address=$mac_address/" /etc/NetworkManager/system-connections/Wired\ connection\ 1.nmconnection # Redémarrer NetworkManager pour prendre en compte les modifications sudo service NetworkManager restart echo "Adresse MAC mise à jour et redémarrage du systeme." # Redémarrer complètement le système pour prendre en compte les modifications sudo reboot else echo "Les adresses MAC sont identiques." fi  and
and to start script

it's working well for me
 
best regards

Added to Armbian build system https://github.com/armbian/build/commit/fd6a6dec66839b8ceeea22fc3792a9fce1df9fde

Ever since I read through THIS POST a while back, I started digging through the cpufrequtils init script, and was a more or less disappointed with what I found. It's largely a product of the CPUs that were available around that time (eg - Pentium 3). Namely that all cores in the system are the same, and there's should be only one master policy that controls everything.
 
Of course ARM big.LITTLE totally breaks these assumptions, and leaves the script with no viable way to specify different schedulers or frequency ranges for each CPU cluster. It still runs, but not really correctly. For example, you can't set the RK3399 little cores above 1.4 GHz, but that's basically what it attempts to do on every boot.
 
Also it needs use "cpufreq-set" to do it's job, which seems too hard when the sysfs interface is already pretty simple. Really, that extra complexity isn't buying you a single thing. Maybe it made more sense 10-15 years ago.
 
So I took a crack at doing a far simpler, stupid version of that script (on perhaps smarter depending on perspective). It can generate it's own config, and I think that it comes across much more readable and accessible.
 
### # CPUFreq policy for CPUs: 0 1 2 3 # # CPU Frequency Governor # Avail: conservative ondemand userspace powersave performance schedutil POLICY0_GOVERNOR=ondemand # Min/Max Frequency Selection # Avail: 408000 600000 816000 1008000 1200000 1416000 POLICY0_MIN_FREQ=408000 POLICY0_MAX_FREQ=1416000 ### # CPUFreq policy for CPUs: 4 5 # # CPU Frequency Governor # Avail: conservative ondemand userspace powersave performance schedutil POLICY4_GOVERNOR=conservative # Min/Max Frequency Selection # Avail: 408000 600000 816000 1008000 1200000 1416000 1608000 1800000 POLICY4_MIN_FREQ=408000 POLICY4_MAX_FREQ=1800000  
And using it isn't too hard ...
 
cp cpufrequtils-bl /etc/init.d/ sudo /etc/init.d/cpufrequtils-bl save sudo vi /etc/default/cpufrequtils-bl sudo systemctl disable cpufrequtils sudo systemctl enable cpufrequtils-bl  
I know that this is probably pretty far down on the list of priorities, but does anyone thing that this would be useful to others?
 
cpufrequtils-bl

Armbian have historically been much more geared towards "server/headless" usage, for many different reasons.  It has taken a much longer time not only for upstream development of underlying graphical libraries / drivers to mature, but also for us (the Armbian project itself) to come up with a sensible implementation that would fit nicely into our existing build framework.
 
However, this work has been going on in the background for quite some time already. 
 
Announcement
 
Finally, the time is right to announce we are publishing our initial implementation of these "desktop" features!
 
Warning!

We are only announcing this here on our own forums for the time being, as this is still early days.  In fact, at this point we are still mainly looking for testers. You should consider this an alpha quality release at this time!
 
What works so far?

Features we plan to develop works, we are already hunting bugs for months, but they are certainly still present. Remember, we are not looking for bugs that are tied to specific hardware feature, but bugs that are linked to the build process, userland and basic desktop functionality. 
 
Report bugs in Armbian build framework section: https://forum.armbian.com/forum/12-armbian-build-framework/
 
Currently, the following Desktop Environments (DEs) are considered to have early "support":
 

 

 
In addition, there are more DEs which should be considered very much WIP, in other words, not really fully working (yet), but we designed a system that can have unlimited variants.
 
Help Wanted!
 
These changes are wide ranging and touch many parts of the code.  Therefore even if you don't plan on using any "desktop" features, your testing can help to find bugs, even in "server" versions (as eventually this code will be merged with master in matter of weeks).
 
If you have been looking for some opportunity to help the project by getting involved a bit more, this could be your chance!

When you notice a problem make a pull request: https://github.com/armbian/build/pulls ( currently sits on a branch "desktop" )
 
Going forward we will be looking for additional desktop maintainers.  Currently the plan is for the Armbian core team to maintain the framework and perhaps settle on 2-3 DE options.  Any which are to be considered in addition to that, will need to come with some commitment to ongoing maintenance by whoever is interested in those additional desktops.
 
Join #armbian-devel IRC channel for development level chat and strengthen the desktop team. Welcome!
 
Getting Started
 
If this is your very first time using the build scripts, start with general instructions. If you are already familiar with the basics of building, some additional detailed instructions pertaining to desktop features can be found here.  You will also need to add:
 
./compile.sh LIB_TAG=desktop EXPERT=yes  
If you don't have option or desire to build from sources, you can also check if your board has nightly images - we are compiling them from this new development branch for a few weeks now - for the desktop you want to try / see:


 
Documentation
 
For end users, if you just want to build image interactively and by choosing supported OS variants, things hasn't changed much and should just work while advanced documentation has changed significantly. Its pretty much WIP and is scattered around in those files:
 
https://github.com/armbian/build/blob/desktop/config/desktop/README.md
https://github.com/armbian/documentation/pull/125
https://github.com/armbian/documentation/pull/98
 
Additional
 
During this change we also added most recent userland(s):
 

Inspired by this topic https://forum.odroid.com/viewtopic.php?t=29069 I installed a shutdown script in /lib/systemd/system-shutdown:
#!/bin/bash case "$1" in kexec) # Do not park disks when switching kernels. ;; *) for disk in /sys/block/sd* ; do echo 1 > /sys/class/block/${disk##*/}/device/delete done sleep 1 ;; esac this works for my needs.
 
I don’t know if this problem is Helios64 specific, if not please move this topic to armbian common issues..

sudo insmod /lib/modules/5.9.11-rockchip64/kernel/drivers/leds/trigger/ledtrig-netdev.ko sudo systemctl restart helios64-heartbeat-led.service  

To activate the network activity led load kernel module ledtrig-netdev and restart helios64-heartbeat-led.service.
 
 

To strengthen the symbiosis between Kobol and Armbian a new dedicated club has been created for Kobol products with Armbian support. It will be maintained directly by Kobol associates @gprovost and @aprayoga.
Check it out:
 

you could re-enable auto power on by removing /lib/systemd/system-shutdown/disable_auto_poweron . You can check the file to see how to control the gpio pin for the auto power on feature.
The auto power on is always enabled by bootloader.
 
 
As @flower answered,  SPI boot is not yet working. Theoretically after boot from SPI  you could change boot target to first SATA drive