-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Raspberry Pi 5 cannot overclock beyond 3.0GHz due to firmware limit(?) #1876
Comments
I'm pretty sure the Pi 5 can handle clocks beyond 3.0GHz as it's extremely stable at that clock, so that as well |
That's what we've been told is the limit of the PLL by Broadcom. I've got a todo item to investigate what happens when this is exceeded, but it's not high on the priority list. |
ah i see, that's sad, hope it gets fixed soon! would love to run my pi at absurd clocks |
I've removed the 3GHz limit, and attached a zip file (you can flash it to an sdcard with rpi-imager) you can test. Make sure you have no critical (unbacked up) data on the Pi you are testing. I could boot at 3.1GHz (and |
that's actually awesome, tysm, i assume i just flash it to an sd card that isnt the one i have raspbian on and boot? |
Yes - use a spare card. |
alright, thanks, will test asap |
Dangit how did I not see this issue before now :) Going to see if I accidentally nuke my 'blessed' Pi 5 (the only one I've been able to get to 3.0 GHz so far). |
LMAO |
Petition to make 3.14GHz the new upper limit in the firmware. |
So I've been trying to get a Geekbench 6 run to complete at 3.14 GHz, testing higher and higher I wound up capturing this from dmesg:
And the cursor blinks on the external display, but SSH goes away. Checking the actual voltage:
So I'm wondering if there's any way to boost that further, or if I should note I have an Argon THRML 60-RC and an additional giant 140mm Noctua fan blowing over everything, fan set to full blast ( |
Yay! Got one run in at 3.14 GHz with:
Honestly not sure if the over_voltage vs over_voltage_delta made a difference or if I just got lucky on this run and unlucky on the other runs. Here's the result: https://browser.geekbench.com/v6/cpu/5314274 And a video! https://www.youtube.com/watch?v=TTIkZBsVJyA |
HELL YEAH!!! |
I've tried flashing, but I just see the boot menu. I tried two different drives with the bootloader but nothing happens? |
How was it made? |
With a C compiler, mostly. @popcornmix is a Raspberry Pi engineer. |
i might try breaking 1k singlecore >:) |
That's your single/multi scores: 967 / 1793 (does really nobody notice how wrong this benchmark is when a quad core CPU scores multi-threaded not even twice as much as single-threaded?) And here's one outperforming your setup at 972 / 1847 clocking the cores only at 3.0 GHz: https://browser.geekbench.com/v6/cpu/5312673 Forget about the displayed 3.2 GHz, that's just what the
So what's different on that system? Maybe simply the user switched to |
BTW: when talking about overclocking it's also a lot about DFVS since 'usually' higher clockspeeds need significantly higher supply voltages. One would expect to see a curve like this (but more exponentially growing at the right side in case of 'overclocking'): With RPi 5 (at least with latest ThreadX/firmware 30cc5f37 / 2024/01/05 15:57:40) it looks either linear or funny:
It always starts at 720 mV for the lowest OPP (and this even when you adjust this with for example Also the 'line drawing' behaviour starting at the lowest OPP ends up with strange behaviour. When not adjusting any of the
One would expect that
@popcornmix are the 1st and 3rd issue somewhat addressed with the new ThreadX/firmware version you provided above? |
A few comments. The idle point of 0.72V is fixed for all boards. Each chip has a unique base voltage (vpred), determined by querying ring oscillators. We don't characterise the overclocked range - you are on your own and can manually adjust with over_voltage_delta.
There is a 1V ceiling that currently can't be exceeded. |
interesting. anyway, gotta break 1k in geekbench for the sillies, will see if i can manage maaaaybe 3.3ghz? |
Edit: haven't seen the answers above before firing up this comment
Nope, just tested with
As such results as expected: when 1.0V can't be exceeded (most probably for a good reason) allowing for higher clockspeeds is just asking for trouble :) |
@ThomasKaiser - Yeah, sadly it looks like 1V is the upper limit, but maybe some fancy (highly destructive) hacking around can surpass it. Regarding that other 3.0 GHz score beating my Geekbench 6 run, I wonder if it running the 4GB RAM part has anything to do with it (I think that was a 4 GB model). I know in some microbenchmarks, at least at some point the 4 GB boards ran faster than the 8 GB boards, when memory was important to the run. I only have two 4 GB Pi 5s, and neither goes beyond 2.8 GHz reliably, so I can't confirm much. |
i wonder, is there no way to OC memory on a pi? i saw some firmware opts for it but havent checked much |
I'm currently testing around with my own RPi 5B (also 4 GB) and got an even better score at 3050 MHz: 975/2022. Since I'm also starting GB only through
While now again testing with 3050 MHz I'm getting both worse latency and GB scores (955/1948 on average):
Some of the individual benchmarks are rather sensitive to memory speed, some not (I tested this with a RK3588 board where one can easily adjust memory clock between 528 and 2112 MHz from userspace though forgot where I documented the results – maybe on your site somewhere in the comments). At least with my tests it looks like this comparing both runs: Asides different temperatures (in the first run my 'monster cooler' kept temperatures below/around 40°C and then I tried higher temps as per your recommendation wrt stability) I don't see any settings that might have changed and affect the behaviour... As such would be interesting if you could compare memory bandwidth between 4GB/8GB models (an Edit: my conclusions wrt memory speed affecting fluctuating GB scores were BS since the first run ('with lower memory latency') also produced scores that vary substantially: https://browser.geekbench.com/v6/cpu/compare/5324361?baseline=5324484 – unfortunately GB also has some sort of random number generator in place when generating scores. Edit 2: confirmed. Another run at 3050 MHz with
|
interesting.. |
Actually there is no ThreadX on a Pi5. The bootloader code runs with no RTOS. SDRAM performance has been improved recently by scaling back refresh with (sdram) temperature |
is it possible to use both the test bootloader and the patched firmware? |
@ThomasKaiser You keep referring to ThreadX, but there is no ThreadX running on a Pi 5. |
nevermind, looks like the sdram change was merged |
Pro tip: wait a bit after rebooting and do it in a loop w/o display connected. Curious whether you're able to 'beat' https://browser.geekbench.com/v6/cpu/5389240 :) BTW: score generated passively cooled at ~21°C ambient temp standing upright w/o any throttling after running several benchmarks in a row: |
Very nice; looks like you have the score to beat! I'm still wondering why the multicore multiplier is a bit low, would be nice to unlock a little more performance when running all four cores hard. |
@geerlingguy currently all GB6 scores above 1000/2000 single/multi are my setup. I call it 'setup' and not board for a number of reasons:
Easy, just use another benchmark! For example GB5! Or check only the A76 cores online on an RK3588 with DRAM clock 528 vs. 2112 MHz. Now checking whether connecting a display makes a difference or not (finally found my 'Micro-HDMI adapter' that is in fact a cable, as such I searched for the wrong thing for quite some time): another run of One execution failed, As for the question whether high GB6 scores are the domain of 4GB boards I made a different test with Rock 5B since there we can adjust the DRAM clockspeed simply from userspace (adjustable between 528 and 2112 MHz). On the left comparing RK3588 at 528/2112 MHz DRAM clock (with the A76 clocking in at ~2340 MHz and all A55 killed) and on the right my 4GB RPi 5 at 3080 MHz vs. your 8GB board at 3140 MHz. The 'bigger picture' seems to hint at differences in DRAM access speed between the 4GB and 8GB model with GB6 (as explained by @popcornmix already) as such I once again ask for |
A new player has entered the chat: https://browser.geekbench.com/v6/cpu/5556526 I'd like to see if I can apply a few different tricks to a 4GB model to see if it can be nudged further. It does seem the RAM makes a difference there. @ThomasKaiser - I can run it on my Pi 5 8GB in a bit... |
Really funny how one setup at 3250 MHz is 'as fast' (as in 'generates same scores') as my setup at 3000 MHz: https://browser.geekbench.com/v6/cpu/compare/5365900?baseline=5556526
I hope you don't mean by that tweaking the clockspeeds further since with the 1000mV ceiling I highly doubt any BCM2712 is stable at 3000 MHz (at least mine is not while being able to generate silly GB6 scores at up to 3080 MHz). And it's easy to test for reliabilty as explained above: ThomasKaiser/sbc-bench@8183b18#commitcomment-139927301 Still interested in getting a plain |
There's a way to go beyond 1V, though I haven't tried it yet, and am going to test a few different cooling / thermal control setups (try to get it chilled, then also try to hold temps at around 50 or 60°C to see if that fares better than cold).
I'll be doing it at 2400 soon, if not today then tomorrow—just have been busy today doing Monday stuff :) |
I managed to get a couple of runs at 3300 MHz, the better one was https://browser.geekbench.com/v6/cpu/5559357 . Run 5556526 was at 3250 MHz . I haven't shared the voltage limit remover publicly because I have no idea at what point it'll blow up. I have an explosion containment pi fridge and geerlingguy said he wasn't concerned about fire or breaking chips. I can't iterate very fast with geekbench, I'll look at switching to something else to push further. |
@ThomasKaiser - Default clocks Pi 5 https://sprunge.us/7JUWFT It gave me one of those "Too much other background activity: 0% avg, 6% max" warnings, but it's literally running nothing else and I rebooted twice after running all updates. Not sure what's up there. And I am concerned about breaking chips, but I set a budget for broken Pis per quarter, and so far I'm only up to 1 this quarter of the 2 I normally allocate :) |
Thank you! So let's compare 4GB and 8GB boards at exactly same software versions: Bandwidth comparison:
Latency (tinymembench):4GB
8GB
Latency (ramlat):4GB
8GB
Well, it is running something else in the background (with all the single-threaded benchmarks on an absolutely idle system
...and most probably that's the reason why you can't get highest Geekbench scores with official Bookworm image (applies to both single and multi scores since with the former there's a |
…install and enable over-clocking to > 3GHz (latest) * bootloader: clock_2712: Remove restriction on arm_freq <= 3000 See: raspberrypi/firmware#1876 * arm_dt: Update max_current to match HAT value * arm_dt: Remove unused legacy parameters (core_freq, arm_freq, uart0_clkrate and cache_line_size) * Add support for custom CA cert for network install You need to specify HTTP_HOST=myhost.com HTTP_PATH=/path/to/files HTTP_CACERT_HASH=<hash> where <hash> is a sha256 hash of the der encoded ca certificate. CA cert is added using rpi-eeprom-config. * Optimise Vbat current draw with charging disabled * Display OTP boot status in UART log messages. * Preliminary support for secure-boot OTP provisioning. * Update PCIE DET_WAKE pinmux for D0 products
…install and enable over-clocking to > 3GHz (latest) * bootloader: clock_2712: Remove restriction on arm_freq <= 3000 See: raspberrypi/firmware#1876 * arm_dt: Update max_current to match HAT value * arm_dt: Remove unused legacy parameters (core_freq, arm_freq, uart0_clkrate and cache_line_size) * Add support for custom CA cert for network install You need to specify HTTP_HOST=myhost.com HTTP_PATH=/path/to/files HTTP_CACERT_HASH=<hash> where <hash> is a sha256 hash of the der encoded ca certificate. CA cert is added using rpi-eeprom-config. * Optimise Vbat current draw with charging disabled * Display OTP boot status in UART log messages. * Preliminary support for secure-boot OTP provisioning. * Update PCIE DET_WAKE pinmux for D0 products
…install and enable over-clocking to > 3GHz (latest) * bootloader: clock_2712: Remove restriction on arm_freq <= 3000 See: raspberrypi/firmware#1876 * arm_dt: Update max_current to match HAT value * arm_dt: Remove unused legacy parameters (core_freq, arm_freq, uart0_clkrate and cache_line_size) * Add support for custom CA cert for network install You need to specify HTTP_HOST=myhost.com HTTP_PATH=/path/to/files HTTP_CACERT_HASH=<hash> where <hash> is a sha256 hash of the der encoded ca certificate. CA cert is added using rpi-eeprom-config. * Optimise Vbat current draw with charging disabled * Display OTP boot status in UART log messages. * Preliminary support for secure-boot OTP provisioning. * Update PCIE DET_WAKE pinmux for D0 products
Interesting changes since the last automatic update: * Enable network install * Enable over-clocking frequencies > 3GHz See: ttps://github.com/raspberrypi/firmware/issues/1876 * Adjust SDRAM refresh rate according to temperature and address a performance gap between 4GB and 8GB parts in benchmarks. See: raspberrypi/firmware#1854 * Support custom CA certs with HTTPS boot * Move non Kernel ARM stages back to 512KB raspberrypi/firmware#1868 * Assorted HAT+ and NVMe interop improvements. * Fix TRYBOOT if secure-boot is enabled. * Preliminary support for D0 and CM5.
Interesting changes since the last automatic update: * Enable network install * Enable over-clocking frequencies > 3GHz See: ttps://github.com/raspberrypi/firmware/issues/1876 * Adjust SDRAM refresh rate according to temperature and address a performance gap between 4GB and 8GB parts in benchmarks. See: raspberrypi/firmware#1854 * Support custom CA certs with HTTPS boot * Move non Kernel ARM stages back to 512KB raspberrypi/firmware#1868 * Assorted HAT+ and NVMe interop improvements. * Fix TRYBOOT if secure-boot is enabled. * Preliminary support for D0 and CM5.
Interesting changes since the last automatic update: * Enable network install * Enable over-clocking frequencies > 3GHz See: ttps://github.com/raspberrypi/firmware/issues/1876 * Adjust SDRAM refresh rate according to temperature and address a performance gap between 4GB and 8GB parts in benchmarks. See: raspberrypi/firmware#1854 * Support custom CA certs with HTTPS boot * Move non Kernel ARM stages back to 512KB raspberrypi/firmware#1868 * Assorted HAT+ and NVMe interop improvements. * Fix TRYBOOT if secure-boot is enabled. * Preliminary support for D0 and CM5.
BTW Jeff, the real benefit of a fixed cable is that the feedback wires can be connected to the outer plug and measure the voltage at the USB connector (compensating for cable losses) instead of measuring it before the cable. This requires to pass two extra thin wires (+ and -) and the power adapter needs to be properly designed so that it takes the reference ground from that thin wire instead of the internal ground. |
In the old days of Cyrix 6x86, the right way to offset the regulator voltage was to draw with a pencil on one of the resistors of the feedback divider. That would deposit some graphite that lowered the resistor value. It very likely continues to work, provided that you find either the divider that sets the reference voltage or find the feedback divider. If there's a direct measurement, graphite between the feedback pin and GND may help but it's tricky since you don't know how much is needed, and it's easy to fry everything. |
Btw, for anyone following this issue, @jonatron posted a nice summary of his testing up to 3.3 GHz, hitting a voltage of |
hello can you overclock your raspberry pi 4? |
Please use the forum for this sort of question. forums.raspberrypi.com |
FYI I've been able to run stable beyond 1.1V... though running into some stability issues at 1.2V. https://browser.geekbench.com/v6/cpu/7058700 - more to come :) |
Here's a blog post and a video going through the overclock. I published a GitHub repo, pi-overvolt, collaborating with jonatron on the code. And in the course of today, I also found out SkatterBencher has an even more in-depth OC/overvolt guide!. Next question, of course: is there any way to hack the PMIC to allow even greater voltages? ;) |
Quite impressive... since when looking at https://browser.geekbench.com/v6/cpu/search?dir=desc&q=Raspberry+Pi+5+Model+B&sort=multicore_score it seems the most important part of you getting better GB6 scores was adopting the 'NUMA emulation' patch. In a quick conversation with the patch author I mentioned the 'usual' GB6 behaviour (on RPi 5) of producing lower scores directly after boot but higher ones after e.g. a Since I kinda lost interest in this GB6 score tweaking nonsense I didn't give it a try so the question is: did you see this variance with the NUMA emulation patch? |
Also keep in mind that the memory bus is only 32-bit wide, so scores (especially multi-threaded ones) will not continue to grow indefinitely with CPU frequency as memory is a bottleneck for many multi-threaded/multi-proc workloads. |
@ThomasKaiser - I tried replicating what you noticed with and without the NUMA patch (firmware and OS both at latest release), and couldn't — I ran one geekbench6 run immediately after reboot, then waited at 5 minute intervals and ran four more, they were all within about 1% of each other. (These runs were about a week ago) |
Yeah - I also fact checked that comment. Let me find the email:
|
bootloader not installing |
Is this the right place for my bug report?
This issue seems to be firmware-related, as the clocking is done through it.
Describe the bug
Setting
arm_freq
beyond 3000 works fine, butvcgencmd measure_clock arm
reports 3000 MHz, while software like Geekbench and btop detect it as the clock set by arm_freq, e.g. 3.1GHzTo reproduce
arm_freq
beyond 3000, and an according over_voltage_deltavcgencmd measure_clock arm
Expected behaviour
The Pi is actually clocked beyond 3.0GHz and both vcgencmd and other software report it as such
Actual behaviour
The Pi is only clocked to 3.0GHz, and vcgencmd reports it as such, but software sees it as set in arm_freq
System
https://pastebin.com/U2KCBBnD
Pi 5
cat /etc/rpi-issue
)?Raspberry Pi reference 2023-12-05 Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 70cd6f2a1e34d07f5cba7047aea5b92457372e05, stage4
vcgencmd version
)?2024/02/16 15:28:41 Copyright (c) 2012 Broadcom version 4c845bd3 (release) (embedded)
uname -a
)?Linux q-raspi5 6.6.17-v8-16k+ #1735 SMP PREEMPT Wed Feb 21 14:45:17 GMT 2024 aarch64 GNU/Linux
Logs
dmesg output is in the raspinfo paste
Additional context
If this is relevant, I used rpi-update to update to latest kernel and firmware version, no change
I have also set debian sources in sources.list to testing/trixie
The text was updated successfully, but these errors were encountered: