Add RPi Zero 2 W overclocking defaults

[MichaIng]

Additionally incorrect over_voltage defaults and ranges have been fixed.

On RPi 4/400, if default maximum voltage (over_voltage=0) means 0.88V, is it adjusted in 0.025V steps as well? And what is the default minimum voltage (over_voltage_min=0)? As well 0.15V below the max (= 0.73V), like for the other RPi models (aside of RPi 1)? And what about the SDRAM voltage? I would like to merge the two voltage tables to show the resulting relating voltage for RPi 1, RPi 4 variants, and all others in separate columns. Currently both tables contradict because of RPi 4 variants. Probably it makes even sense to merge all three tables: Even that all voltage integer values are the same on all RPi models, the table could additionally contain the related voltage [V] value, which is different. Having everything in one tables should increase overview and reduce scrolling up and down to find information.

[aallan]

Ping @ghollingworth or maybe @pelwell ?

[ghost]

I would put the new Pi Zero 2 W column immediately after the exisiting 0/W column, and rename that Pi Zero, Zero W for consistency. (The products are called Zero and Zero W, not 0 and 0W). And tweak the other columns so there's spaces in between, e.g. Pi2 -> Pi 2.

[JamesH65]

@popcornmix is the go to person here.

[pelwell]

The default values for Pi Zero 2 W are correct. If the maximum voltage chance were in a separater PR I'd have approved this already.

[pelwell]

I think that 1.35V is closer to the truth than 1.3125V for the 2837-based devices, but it's not clear from the software what would prevent it from being higher - there's a hard-coded upper limit of 1.4V, which is then limited further because the PMICs only go up to 1.393735V - but physics and the limits of silicon variability may play a part.

I don't object to this change, but I can't confidently say it is definitively correct.

[MichaIng]

The voltage value has been corrected here already and the table removed: #1698
But I didn't know that the RPi 4 has different voltages and it wasn't part of the table. So with a later commit the table has been restored to include RPi 4 values, including its errors for the other models.

The voltage stays at over_voltage_min (its related actual voltage) only on absolute idle (CPU frequency at minimum) and jumps to over_voltage as fast as the frequency raises to any higher value. So it should be pretty easy to verify it on RPi 4 via vcgencmd measure_volts.

I just did that on RPi 2 to verify the behaviour we observed on this and other RPi models before, and surprisingly it seems to have changed:

2021-11-01 12:58:49 root@micha:/var/log# vcgencmd get_config over_voltage
over_voltage=4
2021-11-01 12:59:21 root@micha:/var/log# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
performance
2021-11-01 12:59:28 root@micha:/var/log# vcgencmd measure_volts core
volt=1.3938V

~1.4V != 1.35V + 4*0.025V (=1.45V)

there's a hard-coded upper limit of 1.4V, which is then limited further because the PMICs only go up to 1.393735V - but physics and the limits of silicon variability may play a part.

Ah, and this explains it pretty well, as I simply hit your limit, with over_voltage=4 (!) and it is hit with over_voltage=2 already. Since this setting has no effect on the min/idle voltage, does this mean that currently all the pretty guides stating to reach stable overclocking profiles with over_voltage=6 and more are all wrong, and stating a range up to over_voltage=8 is nonsense? Strange only that I made some tests just yesterday which seem to have shown that higher voltage was required for higher clock rates, but I didn't try to reduce over_voltage too systematically to be true 😅.

For over_voltage_min all is correct:

2021-11-01 12:59:31 root@micha:/var/log# echo powersave > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
2021-11-01 13:01:13 root@micha:/var/log# vcgencmd get_config over_voltage_min
over_voltage_min=-2
2021-11-01 13:01:18 root@micha:/var/log# vcgencmd measure_volts core
volt=1.1500V

1.15V == 1.2V - 2*0.025V

I'll repeat these on RPi Zero W.

As we are already on fixing values. I recognised before that sdram_p is at 1.225V by default instead of at 1.2V like the others:

2021-11-01 12:56:09 root@micha:/var/log# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
powersave
2021-11-01 12:56:30 root@micha:/var/log# vcgencmd measure_volts sdram_c
volt=1.2000V
2021-11-01 12:56:39 root@micha:/var/log# vcgencmd measure_volts sdram_i
volt=1.2000V
2021-11-01 12:56:41 root@micha:/var/log# vcgencmd measure_volts sdram_p
volt=1.2250V

[JamesH65]

This area is quite a moving target, as this area of code does get tweaked both for existing and new products as time goes by, and of course the various numbers can be different on various devices. When I created the original table I tried to encompass as much as I could from talking with @popcornmix who is the font of all knowledge on this as he is the engineer who deals with the various clock and voltage changes. Simplifying it wasn't an option given the variability of the numbers over different products.

[MichaIng]

When I created the original table I tried to encompass as much as I could from talking with @popcornmix who is the font of all knowledge on this as he is the engineer who deals with the various clock and voltage changes. Simplifying it wasn't an option given the variability of the numbers over different products.

Then it is probably easiest to merge it into the large table which differentiates between all models, and I'd also vote for merging "This table gives defaults for options that are the same across all models." into the large one. It doesn't hurt when there are more lines, even when the values are mostly the same for all models. That way we can list the over_voltage settings value (always 0) together with the resulting voltage (different at least on RPi 1 and RPi 4) together in one cell.

But makes sense to do this in a separate PR and do only the RPi Zero 2 W addition here. To not loose track of the resulting voltage corrections. @Joulinar do you find time for testing this on Raspberry Pi 4?

echo powersave > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
vcgencmd measure_volts
echo performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
vcgencmd measure_volts

Once with over_voltage=0, with over_voltage=2 and with over_voltage=6?

I just verified on RPi 2 1.3938V is the absolute maximum, reached with over_voltage=2, hence using any higher value has no further effect. On RPi 1 over_voltage=0 == 1.2V, hence up to over_voltage=8 should be effective, which matches the range given in the first table which describes the available settings. If only the ~1.4V is the upper limit, then on RPi 4 much higher values should be possible. I found overclocking guides with over_voltage=16 and was already wondering whether this has any effect (ignoring wither reasonable or not 😉).

On RPi Zero (1) W with over_voltage=0:

2021-11-01 21:02:42 root@Amizero:~# vcgencmd measure_volts
volt=1.2000V
2021-11-01 21:02:42 root@Amizero:~# vcgencmd measure_volts
volt=1.4000V

So while the minimal voltage is the same, the default maximum voltage is 1.4V 🤔. With over_voltage=2/over_voltage_min=-2:

2021-11-01 21:05:04 root@Amizero:~# vcgencmd measure_volts
volt=1.1500V
2021-11-01 21:05:05 root@Amizero:~# vcgencmd measure_volts
volt=1.4000V

So the minimum voltage is reduced as expected and the maximum voltage capped. Hence the letter cannot be raised at all on RPi Zero (1) models.

[popcornmix]

On RPi Zero (1) W with over_voltage=0:

2021-11-01 21:02:42 root@Amizero:~# vcgencmd measure_volts
volt=1.2000V
2021-11-01 21:02:42 root@Amizero:~# vcgencmd measure_volts
volt=1.4000V

This was actually a bug. Pi0/Pi0w should run at 1.35V when in turbo mode, so there is a little headroom for overvoltage.
Latest rpi-update firmware fixes this and you should see 1.35V again.

[MichaIng]

Latest rpi-update firmware fixes this and you should see 1.35V again.

Ah that is good to know, thanks for the clarification.

[aallan]

Sorry, but I'm sort of unclear what the status of the original PR is after the discussion?

[MichaIng]

@popcornmix could you verify that 1.35V is the correct over_voltage=0 max voltage on RPi 3/3+/Zero 2 W as well, so that we should keep this correction?

I like the suggestions of... now @ghost (removed account) above: #2255 (comment)
Anyone else for/against it? Or shall I do this in a separate PR?

I'll open separate PRs for the sdram_p voltage correction and merging of the tables as suggested above.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[aallan]

I think this one is waiting for @popcornmix to verify that 1.35V is the correct over_voltage=0 max voltage on RPi 3/3+/Zero 2 W?

[popcornmix]

No, I believe only 2708 (Pi0/Pi1) uses a fixed voltage for turbo mode (with over_voltage=0).
All newer processors use dvfs (i.e. it is board specific what voltage will be chosen for turbo mode).
I think the only limit here is what the PMIC can produce (which is typically 1.4V or very close).

[aallan]

Thanks @popcornmix

[aallan]

Looking at the resulting table there does seem to be other problems with this PR, looks like the asciidoc formatting isn't correct as the first column shouldn't look like this?

[aallan]

I'm going to close this one. If the OP wants to resubmit with a cleaner update I'm happy to look at that.

[MichaIng]

@popcornmix
I do not understand, what does "fixed voltage" and "dvfs" have to do with it? The question is, in case of over_voltage=0 and a dynamic scaling governor, which maximum (not fixed) voltage these boards have. The docs currently state its 1.3125V for RPi 2 and RPi 3, which is wrong according to own checks on RPi 2 and checking back via users for RPi 3. vcgencmd measure_volts instead shows 1.35V as maximum voltage for those models. Furthermore the docs currently state that RPi Zero has a fixed voltage of 1.35V and a default over_voltage=6, which is both wrong as well: My RPi Zero W (1) has over_voltage=0 by default like every other model and vcgencmd measure_volts shows that the voltage scales between 1.2V and 1.35V, matching the behaviour of RPi 2/3. 1.4V is only ever reached with over_voltage=2 or higher, and never crossed indeed as this is the firmware cap. Only the RPi 1 variants really have a fixed voltage of 1.2V, at least when not changing over_voltage and over_voltage_min.

@aallan
Format fixed: https://github.com/MichaIng/documentation/blob/patch-1/documentation/asciidoc/computers/config_txt/overclocking.adoc#overclocking

[popcornmix]

Pi0w used a very basic dvfs, so on any board with default settings you will get 1.2V at idle, and 1.35V at turbo.
Boards with newer processors use a more advanced dvfs, so the turbo voltage varies with silicon. It could be anywhere between 1.2V and 1.4V. It's not necessarily 1.35V.

[MichaIng]

@popcornmix
So the fix in this PR regarding Pi0 is correct. For Pi2 I verified, for Pi3/3+/Zero W 2 at least users report the same: a turbo/max voltage reported by vcgencmd measure_volts of 1.35V (not 1.3125V), 1.4V only with over_voltage=2 or higher (which is not what this table covers). If you say that for 1.4V can be reached with over_voltage=0 on any of these boards, then vcgencmd measure_volts at least never reports it (neither does it ever report 1.3125V), even when stressing the CPU 🤔. In any case, the table currently is wrong, so how do you suggest to fix it?

[JamesH65]

I'd remove the voltage table completely. It's been a nightmare to maintain as the underlying code changes often, and all the numbers change.

[MichaIng]

They didn't change since this PR is open at least, aside of on RPi Zero (1) due to a bug, fixed in the meantime. But I agree to better remove the table than to have wrong values in it. I thought about adding over_voltage and over_voltage_min to the defaults table above, only stating the config.txt value (which is 0 in both cases on all boards), skipping the resulting voltage range then.

[aallan]

You're proposing to just remove this one? Or this one and the preceding one..?

[MichaIng]

Only this one (from my end), but adding the default config.txt values to the preceding one, which I assume won't change.

[aallan]

Okay, lets move to #2433.

[MichaIng]

@aallan
I rebased this commit so that it now adds only the RPi Zero 2 overclocking defaults: https://github.com/MichaIng/documentation/commit/e504792
May you reopen the PR?

[lurch]

@MichaIng There's so much confusing information in the comments in this PR, it's probably better to create a new PR, rather than make this one even more confusing?

[MichaIng]

Valuable information about still open issues with the docs, I'd say 😄. Do the comments hurt for reviewing the changes which finally need to be reviewed? But I can open a new one, of course.

[MichaIng]

New PR: #2436

[lurch]

Valuable information about still open issues with the docs, I'd say

If this now-closed PR still contains "valid issues", then IMHO you should open new separate issues for those.

[MichaIng]

Will do.