DVFS Firmware

[Gabigol]

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 ?

[jamesh]

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.

[Gabigol]

Well gpu_freq is definitely the issue here but changing it to core_freq and v3d_freq avoids to boot as well...

[graphicw]

I get the same symptoms as well with the update. You can run an overclock on the ARM but not on GPU or it fails to boot.

[pica200]

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.

[jdb]

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:

Code: Select all

#############################################################
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

[jamesh]

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.

[jahboater]

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

A mild overclock, in my case 1.6GHz is fine, completely stable after rpi-update.

[pica200]

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.

[andrum99]

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.

[jdb]

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.

[Gavinmc42]

Two Pi4's next to each other.
One a new copy of Buster, updated, upgraded and rpi-updated.
One is running at 41C, the other at 53C.

Well done.

[graphicw]

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.

[jamesh]

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.

[DougieLawson]

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.

[jamesh]

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.

[Gavinmc42]

Build in auto overclock to DVFS?
If the temp is low up the overclock.

[DougieLawson]

Build in auto overclock to DVFS?
If the temp is low up the overclock.

Down that twisty passage all alike lies function creep. You can get it to answer the phone, answer the doorbell and make tea while you're there.

[Gavinmc42]

You can get it to answer the phone, answer the doorbell and make tea while you're there.

And mow the lawn and pickup legos and vacuum the floor.........
Why else would I be learning Pi's?

Was thinking about OpenCV/AI/ML/NN stuff, process that data as fast as possible in bursts.
That short time it is overclocked should not drive the temp up much?

[DougieLawson]

It's the upturned square pin plugs that I need it to detect.

[goodburner]

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.

[davidcoton]

You can get it to answer the phone, answer the doorbell and make tea ....

Will it make coffee too? Far more demand for that around here than tea.
Oh, and iced coffee, and hot chocolate...
Looks like another project to add to my queue.

(Don't some of our North American cousins go for Raspberry flavoured coffee, and similar absurdities?)

[sparkyhall]

DVFS firmware working fine here.

I normally run with a CPU overclock of 1800MHz and overvolt=2, this works fine with DVFS although I get 5 frequency steps (600, 720, 900, 1200 & 1800) I assume this is correct?

The idle power consumption at the mains plug is now 3.0W instead of 3.3W, that's a 10% reduction. It was 3.7W when I first got the Pi4, this is with the official USB-C RPi PSU.

Well done all.

[pica200]

There we go. We have a possible workaround now:
https://github.com/raspberrypi/firmware ... -557923066

[sparkyhall]

I just had a hard lock on mine after just over 2 hours of use., never done this before and I have been using this a few hours a day since July. This was with CPU overclock = 1800MHz and overvolt=2.

Will drop to default clock and overvolt and see how it goes.