Hey everyone just wanted to say that my RPi4 doesn’t boot anymore with over_voltage=6 arm_freq=2147 gpu_freq=750 whereas it was totally stable before the last firmware update. Should I disable DVFS manually or something ?

This is a known side effect. I'm not going to say it's an issue, because overclocks are non-standard anyway.

If you have time go back to standard clock settings, and work your way back up again to see where the overclocks breaks. Would be a useful datapoint.

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

This is a known side effect. I'm not going to say it's an issue, because overclocks are non-standard anyway.

Are they non-standard? Yes of course but this has no relevance here because this new firmware is unnecessarily limiting functionality/capabilities which were working previously. If you/the dev team don't want to fix this "issue" just include a config option to revert to old behavior for power users.

Are they non-standard? Yes of course but this has no relevance here because this new firmware is unnecessarily limiting functionality/capabilities which were working previously. If you/the dev team don't want to fix this "issue" just include a config option to revert to old behavior for power users.

The DVFS firmware is only available via rpi-update. rpi-update prints the following warning to the console:

#############################################################
WARNING: 'rpi-update' updates to pre-releases of the linux
kernel tree and Videocore firmware.
'rpi-update' should only be used if there is a specific
reason to do so - for example, a request by a Raspberry Pi
engineer.
DO NOT use 'rpi-update' as part of a regular update process.
##############################################################

Why did you ignore it?

As it stands, current rpi-update firmware breaks overclocked configurations. You can revert to firmware versions prior to the DVFS implementation by doing sudo rpi-update afbea38042fbb73149ad8c5688c011742fb3ff8a - or by using git hashes from this repo: https://github.com/Hexxeh/rpi-firmware

This is a known side effect. I'm not going to say it's an issue, because overclocks are non-standard anyway.

Are they non-standard? Yes of course but this has no relevance here because this new firmware is unnecessarily limiting functionality/capabilities which were working previously. If you/the dev team don't want to fix this "issue" just include a config option to revert to old behavior for power users.

Why do you think it's unnecessarily limiting, it could be entirely necessary!

Of course overclocks are non-standard. That why they are called "Over" clocks. Over the standard clock speed.

We will of course look in to it, but more slowly than any issues that arise at standard clocks speeds. They are more important. A config option might work, depends on how pervasive this new code is through the system, might not be simple to 'comment' it out. It goes without saying that reducing temperatures for everyday users is more important than retaining overclock options for extreme users, given normal users outnumber overclocking by orders of magnitude.

Meanwhile, don't use rpi-update if you want to keep your overclocks.

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

I didn't use rpi-update because this came with a thirdparty kinda-bleeding edge distribution (namely Manjaro ARM). So i knew and accepted the risk of things breaking.

It triggers me if someone says "non-standard anyway" to justify loss/limitation. Freedom of choice and modification of software/hardware is getting rarer these days so i would appreciate if this will be added again one or another way in the future. The other points are fair.

To me there is no possible benefit, only possible dis-benefit, to overclockers of using dynamic voltage scaling. (And dynamic frequency scaling). Overclockers are generally running with good cooling systems, so throttling should not be an issue. (If throttling was going to be an issue, then why overclock?) Given dynamic changes are liable to negatively impact stability, I believe the best solution is to simply lock the voltages if there are any overvoltages or undervoltages specified in config.txt.

There's also the issue of trying not to break setups that already work, although of course it has not yet been proven that these two failures were the result of applying dynamic voltage scaling.

pica200 wrote:
I didn't use rpi-update because this came with a thirdparty kinda-bleeding edge distribution (namely Manjaro ARM). So i knew and accepted the risk of things breaking.

Welp, it's broken - so why are you requesting support on our forums for a third-party distribution?

This question is orthogonal to whether or not there is a bug in the latest firmware if you request overclocked settings - if you can take a default Raspbian image, edit your config.txt to overclock, then run rpi-update and end up with a non-functional system then that warrants investigation.

Just so everyone knows, CPU overclock works fine. The only issue is with GPU overclock with the latest rpi-update. Leave out the GPU overclock until sorted and it will be fine. You can of course always revert back as well. Not very hard.

Just so everyone knows, CPU overclock works fine. The only issue is with GPU overclock with the latest rpi-update. Leave out the GPU overclock until sorted and it will be fine. You can of course always revert back as well. Not very hard.

Not much benefit with a GPU overclock anyway.

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

Just so everyone knows, CPU overclock works fine. The only issue is with GPU overclock with the latest rpi-update. Leave out the GPU overclock until sorted and it will be fine. You can of course always revert back as well. Not very hard.

Not much benefit with a GPU overclock anyway.

So your "firmware" should detect the overclocking settings, disable any DVFS settings and write a debug message to note that it's done that.

Note: Any requirement to use a crystal ball or mind reading will result in me ignoring your question.

I'll do your homework for you for a suitable fee.

Any DMs sent on Twitter will be answered next month.
All non-medical doctors are on my foes list.

Just so everyone knows, CPU overclock works fine. The only issue is with GPU overclock with the latest rpi-update. Leave out the GPU overclock until sorted and it will be fine. You can of course always revert back as well. Not very hard.

Not much benefit with a GPU overclock anyway.

So your "firmware" should detect the overclocking settings, disable any DVFS settings and write a debug message to note that it's done that.

That would be a good option, but I don't know how feasible it is. It depends how pervasive the dvfs code changes are.

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

I was also having issues with the Pi not booting with gpu_freq=600 with the DVFS firmware, I removed it and now it runs like a charm, had to up the voltage by 1 point but the temps have fallen considerably during medium loads, like a mix of writing forum posts and watching youtube, by as much as 6-7 C.

Thanks for another great update! You've been doing a tremendous job with the updates since the Pi 4B released.