How Can I Undervolt the CPU using Device Tree on H6?

[hcac]

Armbianmonitor:

http://ix.io/33Dj

Hello everyone.

I've been struggling with the temperature of my Orange Pi Lite 2. Based on what I saw in the forums, undervolting might fix this issue.

I know how to undervolt the CPU by editing script.bin, however, it seems that script.bin is deprecated and now I need to change the device tree.

I looked into DTS config in armbian-config, I couldn't find any voltage related parameters. I need to edit something like the dvfs_table in script.bin.

Does anyone know how I can edit the device tree in order to modify voltage values? Especially voltage-frequency values.

Any help is much appreciated.

[Werner]

Moved to Common issues / peer to peer technical support

Unsupported/outdated packages

 

[tparys]

Unless your board somehow doesn't support it, usually the best approach is to use dynamic CPU frequency scaling, or cpufreq.

 

https://www.kernel.org/doc/html/v4.14/admin-guide/pm/cpufreq.html

 

Though it's not ideal for big.little architectures, The best place to start is /etc/default/cpufreq. On my NanoPi M4V2, it looks like this:

 

ENABLE=true
MIN_SPEED=408000
MAX_SPEED=2016000
GOVERNOR=ondemand

 

Which says that the Kernel is free to scale the CPUs up to 2.016 GHz whenever it needs it, and leaves it at 408 MHz when it doesn't.

 

If you need more control, you can poke these values directly via the sysfs interface. For example my RK3399 has two policies, one for each CPU cluster. And I can set parameters for each one via scaling_{min,max}_freq.

 

tparys@hobbes:/sys/devices/system/cpu/cpufreq$ ls */
policy0/:
affected_cpus               related_cpus                   scaling_max_freq
cpuinfo_cur_freq            scaling_available_frequencies  scaling_min_freq
cpuinfo_max_freq            scaling_available_governors    scaling_setspeed
cpuinfo_min_freq            scaling_cur_freq               stats
cpuinfo_transition_latency  scaling_driver
ondemand                    scaling_governor

policy4/:
affected_cpus               related_cpus                   scaling_max_freq
cpuinfo_cur_freq            scaling_available_frequencies  scaling_min_freq
cpuinfo_max_freq            scaling_available_governors    scaling_setspeed
cpuinfo_min_freq            scaling_cur_freq               stats
cpuinfo_transition_latency  scaling_driver
ondemand                    scaling_governor

 

[XFer012]

The OP asked for undervolting, not underclocking.

 

@hcacIt's strange that the DTS lacks the OPP with the microvolts for each frequency step. Could you post it?

[tparys]

17 hours ago, XFer012 said:

The OP asked for undervolting, not underclocking.

 

@hcacIt's strange that the DTS lacks the OPP with the microvolts for each frequency step. Could you post it?

 

You're not wrong, but does the voltage not determine the CPU frequency? I suppose I'm unclear at what else was requested.

 

And there does seem to be OPP data in the DTS, though not in a format I typically see. As well as a series of thermal trip points, which might be a better option to edit, as that will set off the Kernel's built-in controls to self-regulate temperature. It'd be pretty straightforward to make a DTS patch to drop all these values by 10 C.

 

	cpu_hot {
		temperature = <0x14c08>; // 85000 mC
		hysteresis = <0x7d0>;
		type = "passive";
		phandle = <0x4c>;
	};

 

[Werner]

2 hours ago, tparys said:

, but does the voltage not determine the CPU frequency

No. Some CPUs can run on lower voltage with same frequency to reduce their power loss but most will become unstable this way. There is only one way to find out if it works.

[XFer012]

Indeed.

For example, my Rock64 and my Neo3 are stable at 1.3 GHz with -25mV and -50mV respectively vs. default OPP values. Silicon lottery.

It's still strange that H6 DTS lacks a proper OPP. Maybe with Unstable kernel, based upon 5.11 mainline? Some patches for H6 were included in 5.11 and accompaining DTS.