Odroid C2 CPU overclock

I’m running 8.90.5 on an Odroid C2. In the past with Libreelec, I’ve been able to change the config.ini located in /flash and uncomment:

1.752GHz

max_freq=‘1752’

cat /proc/cmdline shows:

console=ttyS0,115200 BOOT_IMAGE=KERNEL boot=LABEL=COREELEC disk=LABEL=STORAGE no_console_suspend logo=osd1,loaded,0x3f800000,1080p60hz vout=1080p60hz,enable hdmimode=1080p60hz cvbsmode=nocvbs mac=00:1e:06:33:dd:90 consoleblank=0 max_freq=1752 maxcpus=4 hdmitx=cec17 quiet console=tty0 systemd.show_status=auto ssh

so the max_freq parameter is being passed at boot.

cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq still shows 1536000.

Is there any way to overclock the CPU on the C2 with Coreelec?

1 Like

You could replace u-boot with the one from LE that supports it.

Ok, just wanted to confirm that the behavior I’m seeing is expected.

According this u-boot for C2 still supports overclocking.
But HK had to change the DVFS implementation within the latest u-boot, as there were some boot issues with mainline kernels not supporting kernel-arg “max_freq”, resulting in failing bootup @2GHz.
Therfore they implemented two DVFS tables, a default one with 1,5GHz, and a second one with 2GHz for kernels which can handle “max_freq” (see Commit)
So it seems that CE is only missing this Commit, to make it working again for C2.
Hopefully this can be implemented in CE :hugs:

Try the following test build out link, it contains the patch above.

Let me know how it goes.

Version shows as U-Boot 2015.01 (Aug 10 2018 - 04:53:12)

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
1752000

Seems to be working quite well for me. Thanks!

after update my library connection is lost. Overclock 1752 ok.

Edit: had to switch on wait for network again… my bad…

Sorry for late reply. Testversion works for me on C2.:+1:
Have seen you just transferred the linux commit to CE patch. Good practice to keep the kernel source clean…

This was done as it caused problems booting on some other devices.

Weird. After a deeper look, it seems all AML targets are built with “CONFIG_ARCH_MESON64_ODROIDC2=y” defined?!?
Then it’s clear that the commit will cause bootfail on all other AML boards.
Maybe in this case it’s better to transfer this Commit also to a device dependend patch.
Not sure what the additional GPIO toggle may cause on other boards…