Gammel

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