# Odroid N2+ min. CPU frequency now 1000 instead of 500 Mhz?

**URL:** <https://dietpi.com/forum/t/odroid-n2-min-cpu-frequency-now-1000-instead-of-500-mhz/13558>\
**Category:** Troubleshooting\
**Created:** [29 June 2022 10:54 UTC](https://dietpi.com/forum/t/odroid-n2-min-cpu-frequency-now-1000-instead-of-500-mhz/13558 "2022-06-29T10:54:41Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![lep](https://dietpi.com/forum/letter_avatar_proxy/v4/letter/l/96bed5/32.png) [@lep](https://dietpi.com/forum/u/lep)\
**Post date:** [29 June 2022 10:54 UTC](https://dietpi.com/forum/t/odroid-n2-min-cpu-frequency-now-1000-instead-of-500-mhz/13558/1 "2022-06-29T10:54:41Z")

</div>

Hi,

after the latest updates on my Odroid N2+, I noticed that the CPUs no longer idles down to 500 Mhz but 1000 Mhz. A freshly installed latest N2+ bullseye image has that new, higher minimum, too.

Both /sys/devices/system/cpu/cpu0/cpufreq/scaling\_available\_frequencies and  
/sys/devices/system/cpu/cpu2/cpufreq/scaling\_available\_frequencies used to contain minimum values of 500000 and 667000, but now start with 1000000.

I was wondering, is there a particular reason why **not** to let the N2+ go down to 500 Mhz and save some energy?

And is there a way to allow 500 Mhz in my existing installation? My googling didn’t get me there.

Thanks for your help!

#### Required Information

- DietPi version | `cat /boot/dietpi/.version`  
G\_DIETPI\_VERSION\_CORE=8  
G\_DIETPI\_VERSION\_SUB=5  
G\_DIETPI\_VERSION\_RC=1  
G\_GITBRANCH=‘master’  
G\_GITOWNER=‘MichaIng’
- Distro version | `echo $G_DISTRO_NAME $G_RASPBIAN`  
bullseye
- Kernel version | `uname -a`  
5.10.123-meson64 #22.05.3 SMP PREEMPT Wed Jun 22 07:23:04 UTC 2022 aarch64 GNU/Linux
- SBC model | `echo $G_HW_MODEL_NAME` or (EG: RPi3)  
Odroid N2 (aarch64)

---

<div class="post-metadata">

**Author:** ![Joulinar](https://dietpi.com/forum/user_avatar/dietpi.com/joulinar/32/57_2.png) [@Joulinar](https://dietpi.com/forum/u/Joulinar)\
**Post date:** [29 June 2022 20:02 UTC](https://dietpi.com/forum/t/odroid-n2-min-cpu-frequency-now-1000-instead-of-500-mhz/13558/2 "2022-06-29T20:02:09Z")

</div>

probably @MichaIng could answer this.

---

<div class="post-metadata">

**Author:** ![MichaIng](https://dietpi.com/forum/user_avatar/dietpi.com/michaing/32/7_2.png) [@MichaIng](https://dietpi.com/forum/u/MichaIng)\
**Post date:** [30 June 2022 05:55 UTC](https://dietpi.com/forum/t/odroid-n2-min-cpu-frequency-now-1000-instead-of-500-mhz/13558/3 "2022-06-30T05:55:51Z")

</div>

I’ll verify whether it’s the same in my case. Must be due to latest firmware/kernel upgrade. I couldn’t find a hint on Armbian forum or GitHub, so I guess an upstream change. Probably 500 MHz caused some issues.

Note that the power consumption difference between 500 MHz and 1000 MHz will be marginal only. The first half is what usually leads to significant power consumption.

There is no way to change this without patching and recompiling the kernel.

---

<div class="post-metadata">

**Author:** ![lep](https://dietpi.com/forum/letter_avatar_proxy/v4/letter/l/96bed5/32.png) [@lep](https://dietpi.com/forum/u/lep)\
**Post date:** [1 July 2022 11:31 UTC](https://dietpi.com/forum/t/odroid-n2-min-cpu-frequency-now-1000-instead-of-500-mhz/13558/4 "2022-07-01T11:31:46Z")

</div>

Thank your for your answer!

I guess you’re right about power consumption. I just measured ~2 Watts in idle at 1000 Mhz, so probably close enough to as low as the N2+ gets. Thanks!

---

<div class="post-metadata">

**Author:** ![usual-user](https://dietpi.com/forum/letter_avatar_proxy/v4/letter/u/3be4f8/32.png) [@usual-user](https://dietpi.com/forum/u/usual-user)\
**Post date:** [6 July 2022 18:09 UTC](https://dietpi.com/forum/t/odroid-n2-min-cpu-frequency-now-1000-instead-of-500-mhz/13558/5 "2022-07-06T18:09:34Z")

</div>

> [@MichaIng](#):
>
> I couldn’t find a hint on Armbian forum or GitHub, so I guess an upstream change.

[This](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/boot/dts/amlogic?id=6c4d636bc00dc17c63ffb2a73a0da850240e26e3) is the causative fix.

> [@MichaIng](#):
>
> There is no way to change this without patching and recompiling the kernel.

If you insist on having it back, it can simply be reapplied through an overlay, no patching and kernel recompilation required.
