5kft

Does dpkg-divert not work for some reason?
dpkg-divert --add /etc/default/cpufrequtils

Hi @cmoski, in case it is helpful to you:  If you are using the "nanopifire3" board configuration ("next" target), you can build the kernel, specifying the "CREATE_PATCHES=yes" option, and then modify the generated DT in "cache/sources/linux-4.14.y/arch/arm64/boot/dts/nexell/s5p6818-nanopi-fire3.dts".  Look for "dvfs-tables" in this DT file and edit/add the higher frequency:
dvfs:dynamic-freq@bb000 { supply_name = "vdd_arm_spu"; supply_optional = "vdd_arm_axp"; vdd_arm_spu-supply = <&VCC1P1_ARM_SPU>; vdd_arm_axp-supply = <&VCC1P1_ARM_PMIC>; status = "okay"; dvfs-tables = < 1400000 1200000 1300000 1140000 1200000 1100000 1100000 1040000 1000000 1040000 900000 1000000 800000 1000000 700000 980000 600000 980000 500000 940000 400000 940000>; }; In this table the first column is the frequency, and the second is the voltage provided by the SPU1705 regulator for that frequency.  Note that the maximum voltage that this regulator can output is 1.265v (please see ".../drivers/regulator/spu1705.c" for details).
 
My Fire3 could run fine at 1.5GHz using 1.265v, but 1.6GHz was too unstable (random crashes).  The original FriendlyELEC kernel tree sets the maximum to 1.4GHz at 1.2v, so this is what I brought over to Armbian.
 
I hope this helps...!
 

Hi @cmoski, in case it is helpful to you:  If you are using the "nanopifire3" board configuration ("next" target), you can build the kernel, specifying the "CREATE_PATCHES=yes" option, and then modify the generated DT in "cache/sources/linux-4.14.y/arch/arm64/boot/dts/nexell/s5p6818-nanopi-fire3.dts".  Look for "dvfs-tables" in this DT file and edit/add the higher frequency:
dvfs:dynamic-freq@bb000 { supply_name = "vdd_arm_spu"; supply_optional = "vdd_arm_axp"; vdd_arm_spu-supply = <&VCC1P1_ARM_SPU>; vdd_arm_axp-supply = <&VCC1P1_ARM_PMIC>; status = "okay"; dvfs-tables = < 1400000 1200000 1300000 1140000 1200000 1100000 1100000 1040000 1000000 1040000 900000 1000000 800000 1000000 700000 980000 600000 980000 500000 940000 400000 940000>; }; In this table the first column is the frequency, and the second is the voltage provided by the SPU1705 regulator for that frequency.  Note that the maximum voltage that this regulator can output is 1.265v (please see ".../drivers/regulator/spu1705.c" for details).
 
My Fire3 could run fine at 1.5GHz using 1.265v, but 1.6GHz was too unstable (random crashes).  The original FriendlyELEC kernel tree sets the maximum to 1.4GHz at 1.2v, so this is what I brought over to Armbian.
 
I hope this helps...!
 

one more and you can set up a punk band.. 
 
still think that putting something like this in rc6.d just asks for trouble.. 

Now FriendlyARM has a wiki page for NEO4.

Yes, that change introduced the problem...  I just pushed a fix:  https://github.com/armbian/build/commit/c1530db4820320a1e837901196d846b0ef71ee4c

Yes, that change introduced the problem...  I just pushed a fix:  https://github.com/armbian/build/commit/c1530db4820320a1e837901196d846b0ef71ee4c

Yes...+1 to what Igor said...  Unfortunately as much as I wished wasn't the case I don't have any spare time to help with this currently...  My advice right now is that you take a look at my overlay additions for these two overlays (in the DEV branch now) - they are very small - and you could try manually building them for your 4.14 kernel.  This should be fairly straightforward (e.g., take a look at "armbian-add-overlay" on-device).  I hope this helps - good luck!

I have done a simple openssl benchmark for Allwinner H5 @ 816Mhz vs 1296MHz.
Just for all your information, I saw huge performance improvement @ 1296MHz.
 
Command: openssl speed -elapsed -evp aes-128-cbc
 
Thanks, 5kft bring us such useful information again.

Hi @rusatch - yes, however this is actually even easier to enable now; no patching and custom kernels should be needed   If you build Armbian from the latest top-of-tree for a sunxi device (starting with the 4.17.y kernel), two new DT overlays are provided that you can load via "/boot/armbianEnv.txt" that provide this regulator and will enable higher clock speeds to be used.  The original thread regarding this (with instructions) can be found here:  https://forum.armbian.com/topic/5051-nanopi-neo2-cpu-frequency-issue/?do=findComment&comment=58181.  I'll repeat these instructions here for others:
 
If you would like to try to run your board at 1.3GHz, and your board has a regulator on GPIO PL6 that supports 1.3v (e.g., Orange Pi Zero Plus2 H5 with Q5 MOSFET present, Orange Pi Zero Plus with Q5 MOSFET present, etc.), then all you would have to do is the following:
 
1.  Make sure that you know what you are doing (!).  If you enable the following on a board that does not properly have access to the CPU regulator - i.e., unmodified OrangePi board with missing Q5 MOSFET, or a board that does not have a compatible 1.1v/1.3v regulator controlled via GPIO PL6 - then your board will almost certainly crash on boot!
 
2.  Edit /boot/armbianEnv.txt, and add these lines:
overlay_prefix=sun50i-h5 overlays=gpio-regulator-1.3v cpu-clock-1.3GHz If you have other overlays specified in your /boot/armbianEnv.txt, simply append these two new ones following them, for example:
overlay_prefix=sun50i-h5 overlays=spi-spidev usbhost2 usbhost3 gpio-regulator-1.3v cpu-clock-1.3GHz  
3.  Edit /etc/default/cpufrequtils, and set the MAX_SPEED definition to 1300000:
# WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=408000 MAX_SPEED=1300000 GOVERNOR=ondemand  
4.  Reboot the board
 
That should be it!  Following reboot, you can verify proper operation at the higher CPU clock speeds using "cpufreq-info" (for example).

Hi! Just wanted to share my experince.
I received Orange Pi Zero Plus and it was a board without Q5 FET soldered.
I could not find BSN20 FET, so I tried to check for an alternative.
 - First one to try and solder it was a SI2302 N-channel FET with marking A2SHB. This one was a failure. I could boot Armbian with nightly kernel 4.17.14, but  armbianmon utility showed "---" instead of the CPU clock. And I was unable to boot kernel with "gpio-regulator-1.3v" "cpu-clock-1.3GHz" overlays, it just hanged soon after loading kernel modules.
 - The second one I found was 2N7002 N-channel FET with marking K72-P2 (this one I salvaged out of an old MoBo). And it was a success! Board was able to boot with overlays enabled and it runs fine with clocks up to 1300MHz, yay! Now my board works just fine, but it heats like hell under stress, even with a good heat sink. Thanks that throttling works just fine too.
I think the diffrence in FETs is that we need one with lower Vgs threshold voltage than the one with higher drain current.
 
Hope this could be useful to somebody.
Thanks to everyone who made this tweak possible!

Hi @guidol, yes I found with 4.17 that the HDMI-related shutdown/restart issues no longer occur.  I.e., you should not have to patch out these entries in the DT - it works fine by default (which is nice!).

Yes - here's an example:  https://i.imgur.com/ynC6IiP.jpg.  Very simple, and perfect for fitting on a tiny perfboard 

No needs, we understand that
Since I've some A20, I'll probably take care of that when I get chance/time ...

@rusatch, I am very glad to hear this!!  Thank you!

@5kft Hi, seems the genius in you found the right way ?
root@192.168.0.39's password: 
 _   _                   ____  _   _   _              ____  
| \ | | __ _ _ __   ___ |  _ \(_) | \ | | ___  ___   |___ \ 
|  \| |/ _` | '_ \ / _ \| |_) | | |  \| |/ _ \/ _ \    __) |
| |\  | (_| | | | | (_) |  __/| | | |\  |  __/ (_) |  / __/ 
|_| \_|\__,_|_| |_|\___/|_|   |_| |_| \_|\___|\___/  |_____|
                                                            
Welcome to ARMBIAN 5.54.180730 nightly Debian GNU/Linux 9 (stretch) 4.17.11-sunxi64   
System load:   0.00 0.04 0.02      Up time:       4 min        
Memory usage:  11 % of 481MB      IP:            192.168.x.xx
CPU temp:      33°C               
Usage of /:    7% of 15G        
[ General system configuration (beta): armbian-config ]
Last login: Sun Jul 29 16:57:57 2018 from 192.168.x.xx
root@nanopineo2:~# ls -al /sys/class/leds/
total 0
drwxr-xr-x  2 root root 0 Jul 29 16:59 .
drwxr-xr-x 53 root root 0 Jan  1  1970 ..
lrwxrwxrwx  1 root root 0 Jan  1  1970 nanopi:blue:status -> ../../devices/platform/leds/leds/nanopi:blue:status
lrwxrwxrwx  1 root root 0 Jan  1  1970 nanopi:green:pwr -> ../../devices/platform/leds/leds/nanopi:green:pwr
 

Hi @reverend_t, it's not quite done yet; but it's almost there   At this point I am still cleaning a few things up and am starting to submit PRs for this (e.g., PR #1064 and PR #1065 to start).  I'll keep you posted!

Hi @rusatch - yes, however this is actually even easier to enable now; no patching and custom kernels should be needed   If you build Armbian from the latest top-of-tree for a sunxi device (starting with the 4.17.y kernel), two new DT overlays are provided that you can load via "/boot/armbianEnv.txt" that provide this regulator and will enable higher clock speeds to be used.  The original thread regarding this (with instructions) can be found here:  https://forum.armbian.com/topic/5051-nanopi-neo2-cpu-frequency-issue/?do=findComment&comment=58181.  I'll repeat these instructions here for others:
 
If you would like to try to run your board at 1.3GHz, and your board has a regulator on GPIO PL6 that supports 1.3v (e.g., Orange Pi Zero Plus2 H5 with Q5 MOSFET present, Orange Pi Zero Plus with Q5 MOSFET present, etc.), then all you would have to do is the following:
 
1.  Make sure that you know what you are doing (!).  If you enable the following on a board that does not properly have access to the CPU regulator - i.e., unmodified OrangePi board with missing Q5 MOSFET, or a board that does not have a compatible 1.1v/1.3v regulator controlled via GPIO PL6 - then your board will almost certainly crash on boot!
 
2.  Edit /boot/armbianEnv.txt, and add these lines:
overlay_prefix=sun50i-h5 overlays=gpio-regulator-1.3v cpu-clock-1.3GHz If you have other overlays specified in your /boot/armbianEnv.txt, simply append these two new ones following them, for example:
overlay_prefix=sun50i-h5 overlays=spi-spidev usbhost2 usbhost3 gpio-regulator-1.3v cpu-clock-1.3GHz  
3.  Edit /etc/default/cpufrequtils, and set the MAX_SPEED definition to 1300000:
# WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=408000 MAX_SPEED=1300000 GOVERNOR=ondemand  
4.  Reboot the board
 
That should be it!  Following reboot, you can verify proper operation at the higher CPU clock speeds using "cpufreq-info" (for example).

Ooh. With overlays its very usefull. Thank you very much. Its very cool!
Today i recieve mosfets from aliexpress, used link that was in this thread. Tomorrow i will include mosfet on board and try use overlays.
 
update: Found additional overlay named cpu-clock-1.4GHz. Is this experemental overlay?

Excellent!!!  @guidol, thank you so very much for your time and effort in testing this, I truly appreciate it!!! 

@5kft it did work! -  
U-Boot 2018.05-armbian (Jul 29 2018 - 01:32:58 +0000) Allwinner Technology CPU: Allwinner H5 (SUN50I) Model: FriendlyARM NanoPi NEO 2 DRAM: 512 MiB MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 Loading Environment from EXT4... ** File not found /boot/boot.env ** ** Unable to read "/boot/boot.env" from mmc0:1 ** Failed (-5) In: serial Out: serial Err: serial NanoPi NEO2 v1.0 detected Net: No ethernet found. 230454 bytes read in 25 ms (8.8 MiB/s) starting USB... No controllers found Autoboot in 1 seconds, press <Space> to stop Welcome to ARMBIAN 5.54.180730 nightly Debian GNU/Linux 9 (stretch) 4.17.11-sunxi64 root@nanopineo2:~# ls -l /sys/class/leds total 0 lrwxrwxrwx 1 root root 0 Jan 1 1970 nanopi:blue:status -> ../../devices/platform/leds/leds/nanopi:blue:status lrwxrwxrwx 1 root root 0 Jan 1 1970 nanopi:green:pwr -> ../../devices/platform/leds/leds/nanopi:green:pwr  

@5kft: like @Pat my 2 Neo2 v1.0 are identified at u-boot as Neo2 v1.1
So I also see the wrong led-color-names
 
I did test it with my 2 Neo2 v1.0 and also get them out of the case to see they are real v1.0 (non-popup-sdslot, the v1.0 Ethernet-port, unsoldered audio):
 
IP22 Neo2: ========================================================================== U-Boot 2018.05-armbian (Jul 21 2018 - 07:20:45 -0700) Allwinner Technology CPU: Allwinner H5 (SUN50I) Model: FriendlyARM NanoPi NEO 2 DRAM: 512 MiB MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 Loading Environment from EXT4... ** File not found /boot/boot.env ** ** Unable to read "/boot/boot.env" from mmc0:1 ** Failed (-5) In: serial Out: serial Err: serial NanoPi NEO2 v1.1 detected Net: No ethernet found. 230454 bytes read in 24 ms (9.2 MiB/s) starting USB... root@nanopineo2:~# ls -al /sys/class/leds/ total 0 drwxr-xr-x 2 root root 0 Jul 21 14:26 . drwxr-xr-x 53 root root 0 Jan 1 1970 .. lrwxrwxrwx 1 root root 0 Jan 1 1970 nanopi:green:status -> ../../devices/platform/leds/leds/nanopi:green:status lrwxrwxrwx 1 root root 0 Jan 1 1970 nanopi:red:pwr -> ../../devices/platform/leds/leds/nanopi:red:pwr IP23 Neo2: ========================================================================== U-Boot 2018.05-armbian (Jul 21 2018 - 07:20:45 -0700) Allwinner Technology CPU: Allwinner H5 (SUN50I) Model: FriendlyARM NanoPi NEO 2 DRAM: 512 MiB MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 Loading Environment from EXT4... ** File not found /boot/boot.env ** ** Unable to read "/boot/boot.env" from mmc0:1 ** Failed (-5) In: serial Out: serial Err: serial NanoPi NEO2 v1.1 detected Net: No ethernet found. 230454 bytes read in 25 ms (8.8 MiB/s) starting USB... root@nanopineo2:~# ls -al /sys/class/leds/ total 0 drwxr-xr-x 2 root root 0 Jul 21 14:28 . drwxr-xr-x 53 root root 0 Jan 1 1970 .. lrwxrwxrwx 1 root root 0 Jan 1 1970 nanopi:green:status -> ../../devices/platform/leds/leds/nanopi:green:status lrwxrwxrwx 1 root root 0 Jan 1 1970 nanopi:red:pwr -> ../../devices/platform/leds/leds/nanopi:red:pwr  

Hi @guidol, @Pat - thanks again for the testing!  I dug into this and as-is in the current u-boot the driver code for the second GPIO bank doesn't appear to be working, so I can't properly read the "board ID" GPIO line.  Unfortunately as I am completely unfamiliar with this implementation in u-boot I need to debug this and figure out what is going on.  The good news is that I found another exposed GPIO line in that same bank that I can use to debug and test, so I won't bother you with trying this until I have the new implementation   (It may be a few days for me to find enough time to work on this, however...but I will keep you posted!)

maybe @Pat is this time faster, because my 2 Neo2 v1.0 are installed inside the silver NAS case....
I have to open the case and install MicroSD and serial converter...and every time I unscrew the case it wouldn't get better

It works!  Thanks again!