Power & Source of Big Ideas

(Solved) Nanopi Neo2 set max Freq

Moderators: chensy, FATechsupport

Good day!


I've had the Nanopi Neo2 v1.0 for sometime now, used for mostly for NAS solution.
the v1.0 is the one being carried by my supplier here. No v1.1 yet

Lately I installed armbian monitor to monitor system resources.
Then I stumbled upon the min and max frequency
when I checked using

Code: Select all

# cpufreq-info -p
408000 816000 ondemand


I've read on some internet writeups that one can set the max frequency to 1008000

tried editing the

cpufrequtils
scaling_max_freq
scaling_available_frequencies
scaling_setspeed


I was able to lower the minimum frequency to 120000 using the following entry at cpufrequtils

Code: Select all

# WARNING: this file will be replaced on board support package (linux-root-...) upgrade
ENABLE=true
#MIN_SPEED=408000
#MAX_SPEED=816000
MIN_SPEED=0
MAX_SPEED=1008000
GOVERNOR=ondemand


but the output of cpufreq-info -p remains as

Code: Select all

# cpufreq-info -p
120000 816000 ondemand


I'd really like to be able to set the max frequency higher than it is now.
This cannot be set using Armbian. Is this possible with FriendlyElect UbuntuCore?
Any info, pointers, procedures (much better) will be much appreciated


Thanks in advance!
when you use cpufreq-info (without a -p) then you could should read:

hardware limits: 120 MHz - 1.01 GHz
available frequency steps: 120 MHz, 240 MHz, 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz
available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
current policy: frequency should be within 120 MHz and 1.01 GHz.
The governor "ondemand" may decide which speed to use
within this range.

So the minimum is 120000 (120Mhz) and the maximum is 1010000 (1.01Ghz).
But many do say for memory-access you shouldnt use less than 480000 (480Mhz) because it take longer to switch to a higher rate and there isnt more power to save with 120000/240000 as with 4800000

Your /etc/default/cpufrequtils could look like

Code: Select all

# WARNING: this file will be replaced on board support package (linux-root-...) upgrade
ENABLE=true
# MIN_SPEED=408000
# MAX_SPEED=816000
MIN_SPEED=120000
MAX_SPEED=1010000
GOVERNOR=ondemand

but MIN_SPEED should be set to 480000 (408000 is a mistype from armbian :) )

If GOVERNOR=ondemand wouldnt switch down (see armbian-monitor -m ) then try to use GOVERNOR=conservative
thanks for the reply.

posting the results of the command cpufreq-info

Code: Select all

root@NPiN2Armb:~# cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 5.44 ms.
  hardware limits: 120 MHz - 816 MHz
  available frequency steps: 120 MHz, 240 MHz, 480 MHz, 648 MHz, 816 MHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
  current policy: frequency should be within 120 MHz and 816 MHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 816 MHz (asserted by call to hardware).
  cpufreq stats: 120 MHz:45.55%, 240 MHz:1.18%, 480 MHz:0.00%, 648 MHz:0.00%, 816 MHz:53.28%  (25716)
analyzing CPU 1:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 5.44 ms.
  hardware limits: 120 MHz - 816 MHz
  available frequency steps: 120 MHz, 240 MHz, 480 MHz, 648 MHz, 816 MHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
  current policy: frequency should be within 120 MHz and 816 MHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 816 MHz (asserted by call to hardware).
  cpufreq stats: 120 MHz:45.55%, 240 MHz:1.18%, 480 MHz:0.00%, 648 MHz:0.00%, 816 MHz:53.28%  (25716)
analyzing CPU 2:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 5.44 ms.
  hardware limits: 120 MHz - 816 MHz
  available frequency steps: 120 MHz, 240 MHz, 480 MHz, 648 MHz, 816 MHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
  current policy: frequency should be within 120 MHz and 816 MHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 816 MHz (asserted by call to hardware).
  cpufreq stats: 120 MHz:45.55%, 240 MHz:1.18%, 480 MHz:0.00%, 648 MHz:0.00%, 816 MHz:53.28%  (25716)
analyzing CPU 3:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 5.44 ms.
  hardware limits: 120 MHz - 816 MHz
  available frequency steps: 120 MHz, 240 MHz, 480 MHz, 648 MHz, 816 MHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
  current policy: frequency should be within 120 MHz and 816 MHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 816 MHz (asserted by call to hardware).
  cpufreq stats: 120 MHz:45.55%, 240 MHz:1.18%, 480 MHz:0.00%, 648 MHz:0.00%, 816 MHz:53.28%  (25716)


as I can see it the max frequency is capped to 816MHz on this NanoPi Neo2 v1.0 running the latest armbian stretch.
can this be changed?
LTolledo wrote:
Good day!


I've had the Nanopi Neo2 v1.0 for sometime now, used for mostly for NAS solution.
the v1.0 is the one being carried by my supplier here. No v1.1 yet

Lately I installed armbian monitor to monitor system resources.
Then I stumbled upon the min and max frequency
when I checked using

Code: Select all

# cpufreq-info -p
408000 816000 ondemand


I've read on some internet writeups that one can set the max frequency to 1008000

tried editing the

cpufrequtils
scaling_max_freq
scaling_available_frequencies
scaling_setspeed


I was able to lower the minimum frequency to 120000 using the following entry at cpufrequtils

Code: Select all

# WARNING: this file will be replaced on board support package (linux-root-...) upgrade
ENABLE=true
#MIN_SPEED=408000
#MAX_SPEED=816000
MIN_SPEED=0
MAX_SPEED=1008000
GOVERNOR=ondemand


but the output of cpufreq-info -p remains as

Code: Select all

# cpufreq-info -p
120000 816000 ondemand


I'd really like to be able to set the max frequency higher than it is now.
This cannot be set using Armbian. Is this possible with FriendlyElect UbuntuCore?
Any info, pointers, procedures (much better) will be much appreciated


Thanks in advance!


Please read this document very carefully: https://forum.armbian.com/guidelines Starting from:

"We are not 'SBC Whisperers' or mind-readers! ...
LTolledo wrote:
thanks for the reply.
as I can see it the max frequency is capped to 816MHz on this NanoPi Neo2 v1.0 running the latest armbian stretch.
can this be changed?


the 1.01.Ghz (or 1.08) are from my Neo2 LTS v1.1 (1GB Ram) as I did see now.

My two Neo2 v1.0 (512MB) are also capped to 816Mhz in armbian, but running fine.
armbian did capped this - as I know - for security reasons for not to cook the CPU because the volting switching module for the cpu isnt as goog as it should be.

The v1.1 is a little better, but I think the difference between 816Mh and 1.08Ghz arent that much to fry your cpu.
OK now I understand

Will give up the stupid idea to max out cpu freq for v1.0 :D

Hope my local supplier switches its stock to v1.1 soon....
Update:

Just a final test before actually giving up, I did try to install UbuntuCore from the Friendly Elec software download section
and after installing checked the max CPU freq using lscpu

Code: Select all

~# lscpu
Architecture:          aarch64
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    1
Core(s) per socket:    4
Socket(s):             1
CPU max MHz:           1008.0000
CPU min MHz:           120.0000
Hypervisor vendor:     horizontal
Virtualization type:   full


verifying using

Code: Select all

~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
1008000


am quite happy with these results. Will port my NanoPi Neo2 v1.0 NAS system to this OS installation instead. :D
LTolledo wrote:
Update:

Just a final test before actually giving up, I did try to install UbuntuCore from the Friendly Elec software download section
and after installing checked the max CPU freq using lscpu

Code: Select all

~# lscpu
Architecture:          aarch64
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    1
Core(s) per socket:    4
Socket(s):             1
CPU max MHz:           1008.0000
CPU min MHz:           120.0000
Hypervisor vendor:     horizontal
Virtualization type:   full


verifying using

Code: Select all

~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
1008000


am quite happy with these results. Will port my NanoPi Neo2 v1.0 NAS system to this OS installation instead. :D


Slightly higher CPU numbers which gave you virtually nothing but add instability and generate more heat. On top of OS/image that receives virtually no support/updates/bugfixes.

Bad choice :)
DietPi also is able to set max freq to 1008000

I'd probably go to an OS that satisfies my requirements and has support/updates/bugfixes...
OS that cannot satisfy my requirement I will not use.

bad choice or not, its still my choice. :)
LTolledo wrote:
has support/updates/bugfixes...


Nope. It doesn't. Debian packages update is irrelevant.

It's demo/proof of concept image and (Dietpi) is a rebranding (with some user space mods) of the same creation. Without any low level change.

Yes, you have all rights to be wrong :)
from that statement it would seem

"All non-armbian users are wrong."

...well....thanks anyway....
LTolledo wrote:
from that statement it would seem

"All non-armbian users are wrong."

...well....thanks anyway....


Undo my relation to Armbian and think, explore and make your own conclusion based on science, facts. There was a lot of research on this topic and if you would invest some time to find that, you would not asking those questions in first place.

I only provide you basic info and a few clues what to look for. What is truly important.

I don't care what you will use.

Who is online

In total there are 9 users online :: 0 registered, 0 hidden and 9 guests (based on users active over the past 5 minutes)
Most users ever online was 5185 on Wed Jan 22, 2020 1:44 pm

Users browsing this forum: No registered users and 9 guests