Raspberry Pi 5 cannot overclock beyond 3.0GHz due to firmware limit(?)

[youmukonpaku1337]

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, but vcgencmd measure_clock arm reports 3000 MHz, while software like Geekbench and btop detect it as the clock set by arm_freq, e.g. 3.1GHz

To reproduce

1. Set arm_freq beyond 3000, and an according over_voltage_delta
2. Reboot, and run vcgencmd measure_clock arm
3. Check with something else, like btop or Geekbench
4. Clocks will be mismatched and vcgencmd will only report 3.0GHz

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

• Which model of Raspberry Pi? Pi 5
• Which OS and version (cat /etc/rpi-issue)? Raspberry Pi reference 2023-12-05 Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 70cd6f2a1e34d07f5cba7047aea5b92457372e05, stage4
• Which firmware version (vcgencmd version)? 2024/02/16 15:28:41 Copyright (c) 2012 Broadcom version 4c845bd3 (release) (embedded)
• Which kernel version (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

[youmukonpaku1337]

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

[popcornmix]

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.

[youmukonpaku1337]

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

[popcornmix]

rpi-eeprom-recovery.zip

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. Let me know if you succeed in going above 3GHz.

I could boot at 3.1GHz (and vcgencmd measure_clock arm confirmed that) but my Pi would crash when stressed.

[youmukonpaku1337]

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?

[popcornmix]

Yes - use a spare card.

[youmukonpaku1337]

alright, thanks, will test asap

[geerlingguy]

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).

[youmukonpaku1337]

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

[Mauker1]

Petition to make 3.14GHz the new upper limit in the firmware.

[geerlingguy]

So I've been trying to get a Geekbench 6 run to complete at 3.14 GHz, testing higher and higher over_voltage_delta (with force_turbo off and on), and so far can't quite hack it.

I wound up capturing this from dmesg:

[  326.258634] ------------[ cut here ]------------
[  326.258637] Firmware transaction timeout
[  326.258646] WARNING: CPU: 3 PID: 31 at drivers/firmware/raspberrypi.c:67 rpi_firmware_property_list+0x204/0x270
[  326.258654] Modules linked in: algif_hash algif_skcipher af_alg bnep vc4 snd_soc_hdmi_codec binfmt_misc aes_ce_blk drm_display_helper cec aes_ce_cipher drm_dma_helper drm_kms_helper hci_uart ghash_ce snd_soc_core btbcm gf128mul snd_compress sha2_ce snd_pcm_dmaengine brcmfmac sha256_arm64 sha1_ce bluetooth snd_pcm brcmutil snd_timer snd rpivid_hevc(C) cfg80211 v4l2_mem2mem pisp_be videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 ecdh_generic fb_sys_fops ecc syscopyarea sysfillrect sysimgblt rfkill libaes videobuf2_common v3d videodev raspberrypi_hwmon mc gpu_sched drm_shmem_helper raspberrypi_gpiomem rp1_adc pwm_fan nvmem_rmem uio_pdrv_genirq uio fuse drm drm_panel_orientation_quirks backlight dm_mod ip_tables x_tables ipv6 spidev i2c_brcmstb spi_bcm2835 gpio_keys
[  326.258699] CPU: 3 PID: 31 Comm: kworker/3:0 Tainted: G         C         6.1.0-rpi7-rpi-2712 #1  Debian 1:6.1.63-1+rpt1
[  326.258702] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT)
client_loop: send disconnect: Broken pipe

And the cursor blinks on the external display, but SSH goes away.

Checking the actual voltage:

$ vcgencmd measure_volts
volt=1.0000V

So I'm wondering if there's any way to boost that further, or if 1.0000V is the hard limit for the cores?

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 (pinctrl FAN_PWM op dl — for some reason my custom setting for fan_temp0 through 4 to run the speed at 255 doesn't seem to make a difference).

[geerlingguy]

Yay! Got one run in at 3.14 GHz with:

over_voltage=8
arm_freq=3140
force_turbo=1

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

[youmukonpaku1337]

HELL YEAH!!!

[senothechad]

I've tried flashing, but I just see the boot menu. I tried two different drives with the bootloader but nothing happens?

[Cgamess]

rpi-eeprom-recovery.zip

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. Let me know if you succeed in going above 3GHz.

I could boot at 3.1GHz (and vcgencmd measure_clock arm confirmed that) but my Pi would crash when stressed.

How was it made?

[pelwell]

With a C compiler, mostly. @popcornmix is a Raspberry Pi engineer.

[youmukonpaku1337]

Yay! Got one run in at 3.14 GHz with:

over_voltage=8
arm_freq=3140
force_turbo=1

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

i might try breaking 1k singlecore >:)

[ThomasKaiser]

Here's the result: https://browser.geekbench.com/v6/cpu/5314274

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 cpufreq driver thinks and on any RPi it has no clue about real clockspeeds. Geekbench on ARM with Linux starting from v4.2 on measures and also reports the clockspeeds in the warmup phase: https://browser.geekbench.com/v6/cpu/5312673.gb6 (you need a GB browser account to access these raw data files)

  "processor_frequency": {
    "frequencies": [
      2994,
      2992,
      2992,
      ...    
      2993,
      2997,
      2991
    ]

So what's different on that system? Maybe simply the user switched to performance cpufreq governor prior to firing up Geekbench? Maybe memory access is faster compared to @geerlingguy's run where the CPU cores were being measured at ~3133 MHz which is to be expected at the configured 3140 MHz?

[ThomasKaiser]

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:

arm_freq=3000:

  1500 MHz    720.0 mV
  1600 MHz    760.0 mV
  1700 MHz    775.0 mV
  1800 MHz    790.0 mV
  1900 MHz    800.0 mV
  2000 MHz    815.0 mV
  2100 MHz    830.0 mV
  2200 MHz    845.0 mV
  2300 MHz    855.0 mV
  2400 MHz    870.0 mV
  2500 MHz    885.0 mV
  2600 MHz    900.0 mV
  2700 MHz    910.0 mV
  2800 MHz    925.0 mV
  2900 MHz    940.0 mV
  3000 MHz    955.0 mV

arm_freq=3000 combined with over_voltage=4:

  1500 MHz    720.0 mV
  1600 MHz    860.0 mV
  1700 MHz    875.0 mV
  1800 MHz    885.0 mV
  1900 MHz    900.0 mV
  2000 MHz    915.0 mV
  2100 MHz    930.0 mV
  2200 MHz    940.0 mV
  2300 MHz    955.0 mV
  2400 MHz    970.0 mV
  2500 MHz    970.0 mV
  2600 MHz    970.0 mV
  2700 MHz    970.0 mV
  2800 MHz    970.0 mV
  2900 MHz    970.0 mV
  3000 MHz    970.0 mV

arm_freq=3000 combined with over_voltage_delta=50000:

  1500 MHz    720.0 mV
  1600 MHz    805.0 mV
  1700 MHz    820.0 mV
  1800 MHz    835.0 mV
  1900 MHz    850.0 mV
  2000 MHz    860.0 mV
  2100 MHz    875.0 mV
  2200 MHz    890.0 mV
  2300 MHz    905.0 mV
  2400 MHz    915.0 mV
  2500 MHz    930.0 mV
  2600 MHz    945.0 mV
  2700 MHz    960.0 mV
  2800 MHz    970.0 mV
  2900 MHz    985.0 mV
  3000 MHz   1000.0 mV

It always starts at 720 mV for the lowest OPP (and this even when you adjust this with for example arm_freq_min=1000) and then some algorithm 'draws' a straight line up to the highest OPP except for the over_voltage setting where things get really weird since overvolting low OPP while keeping the same supply voltage for the 'overclocked' OPP is quite the opposite of what's expected when having silicon behaviour in mind.

Also the 'line drawing' behaviour starting at the lowest OPP ends up with strange behaviour. When not adjusting any of the arm_freq ThreadX settings the 1500 MHz OPP gets 720 mV. But when setting arm_freq_min=1000 the line gets drawn with a similar algorithm but now the 1500 MHz OPP is at 775 mV and not 720 mV any more:

  1000 MHz    720.0 mV
  1100 MHz    730.0 mV
  1200 MHz    740.0 mV
  1300 MHz    750.0 mV
  1400 MHz    765.0 mV
  1500 MHz    775.0 mV
  1600 MHz    785.0 mV
  1700 MHz    795.0 mV
  ...

One would expect that

• the supply voltage of a certain clockspeed being a HW property and based on silicon testings with some safety headroom. Each cpufreq OPP has an ideal supply voltage (as low as possible to save energy and also as high as needed to allow for stable operation) that shouldn't 'move around' when adjusting arm_freq settings
• ideally the SoC manufacturer allows for AVS due to 'silicon lottery' and as such 'lower quality' chips will automagically be driven with slightly higher supply voltages and optionally top cpufreq OPP denied if the supply voltage would exceed a critical limit
• the DVFS OPP painting a curve (linear/flat on the left side and then exponentially growing for the higher/highest OPP) and not a straight line

@popcornmix are the 1st and 3rd issue somewhat addressed with the new ThreadX/firmware version you provided above?

[popcornmix]

A few comments. The idle point of 0.72V is fixed for all boards. Below that voltage internal RAMs become unreliable, so you can't go lower than that however low the clock go.

Each chip has a unique base voltage (vpred), determined by querying ring oscillators. This is added to a fixed slope that increases with frequency. True, the real curve may not be flat, but over the non-overclocked range, it's pretty close to flat.

We don't characterise the overclocked range - you are on your own and can manually adjust with over_voltage_delta.

over_voltage is deprecated. It doesn't take into account vpred. over_voltage_delta is preferred.

There is a 1V ceiling that currently can't be exceeded.

[youmukonpaku1337]

interesting. anyway, gotta break 1k in geekbench for the sillies, will see if i can manage maaaaybe 3.3ghz?

[ThomasKaiser]

Edit: haven't seen the answers above before firing up this comment

@popcornmix are the 1st and 3rd issue somewhat addressed with the new ThreadX/firmware version you provided above?

Nope, just tested with arm_freq=3100 and over_voltage_delta=100000. The upper voltage limit with ThreadX build 4d574a2e is (still?) 1000mV and the algorithm 'drawing' a linear line is also still in place:

  1500 MHz    720.0 mV
  1600 MHz    855.0 mV
  1700 MHz    870.0 mV
  1800 MHz    885.0 mV
  1900 MHz    900.0 mV
  2000 MHz    910.0 mV
  2100 MHz    925.0 mV
  2200 MHz    940.0 mV
  2300 MHz    955.0 mV
  2400 MHz    965.0 mV
  2500 MHz    980.0 mV
  2600 MHz    995.0 mV
  2700 MHz   1000.0 mV
  2800 MHz   1000.0 mV
  2900 MHz   1000.0 mV
  3000 MHz   1000.0 mV
  3100 MHz   1000.0 mV

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 :)

[geerlingguy]

@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.

[youmukonpaku1337]

i wonder, is there no way to OC memory on a pi? i saw some firmware opts for it but havent checked much

[ThomasKaiser]

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'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 sbc-bench -G there's always memory latency measurement also done and I see here variations. My first try with 3050 MHz showed these ramlat scores:

Executing ramlat on cpu0 (Cortex-A76), results in ns:
   size:  1x32  2x32  1x64  2x64 1xPTR 2xPTR 4xPTR 8xPTR
     4k: 1.350 1.313 1.312 1.312 1.312 1.312 1.312 2.498 
     8k: 1.312 1.312 1.312 1.312 1.312 1.312 1.316 2.561 
    16k: 1.319 1.313 1.314 1.315 1.312 1.313 1.314 2.556 
    32k: 1.312 1.312 1.312 1.312 1.312 1.315 1.312 2.577 
    64k: 1.312 1.313 1.315 1.312 1.312 1.312 1.313 2.558 
   128k: 3.935 3.935 3.944 3.935 3.938 4.412 5.722 9.945 
   256k: 4.247 3.961 4.250 3.952 4.110 4.489 5.622 9.955 
   512k: 7.360 7.278 7.052 7.280 7.034 8.428 9.196 13.87 
  1024k: 13.22 12.90 12.87 12.88 13.05 13.45 15.19 22.17 
  2048k: 17.04 15.88 16.77 15.88 25.23 16.79 18.92 26.45 
  4096k: 67.59 61.33 67.46 61.59 68.93 68.06 80.18 101.3 
  8192k: 93.54 106.5 97.65 87.53 94.22 90.86 101.5 126.8 
 16384k: 104.1 101.3 103.9 101.8 103.6 104.9 126.2 127.4 
 32768k: 116.2 113.8 114.5 113.6 115.3 114.5 115.7 119.3 
 65536k: 118.7 117.5 127.3 117.3 118.6 117.7 118.7 121.1 
131072k: 120.0 118.9 119.9 118.8 120.0 128.6 119.4 120.2 

While now again testing with 3050 MHz I'm getting both worse latency and GB scores (955/1948 on average):

Executing ramlat on cpu0 (Cortex-A76), results in ns:
   size:  1x32  2x32  1x64  2x64 1xPTR 2xPTR 4xPTR 8xPTR
     4k: 1.324 1.314 1.312 1.312 1.312 1.312 1.312 2.500 
     8k: 1.312 1.312 1.312 1.312 1.312 1.312 1.312 2.555 
    16k: 1.318 1.312 1.313 1.312 1.312 1.312 1.312 2.555 
    32k: 1.312 1.312 1.312 1.312 1.312 1.312 1.312 2.579 
    64k: 1.312 1.312 1.312 1.312 1.313 1.313 1.312 2.558 
   128k: 3.935 3.936 3.936 3.935 3.935 4.468 5.765 9.939 
   256k: 3.939 3.936 3.962 3.976 4.007 4.437 5.633 9.944 
   512k: 7.443 7.492 7.521 7.490 7.456 8.786 8.990 13.97 
  1024k: 14.53 13.29 13.76 13.28 13.25 13.76 15.46 23.43 
  2048k: 26.47 27.03 26.91 26.98 41.58 25.73 27.83 34.22 
  4096k: 69.95 61.53 68.19 61.56 70.88 68.41 79.23 100.5 
  8192k: 94.90 107.5 100.6 88.62 96.38 96.22 105.3 135.3 
 16384k: 105.1 101.9 104.2 101.5 104.8 105.9 117.9 144.4 
 32768k: 117.5 115.9 116.9 115.7 117.1 115.6 119.2 129.1 
 65536k: 119.7 118.7 128.3 118.5 119.9 118.9 120.4 125.6 
131072k: 121.9 121.1 121.8 121.1 121.9 128.1 120.9 123.8 

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: https://browser.geekbench.com/v6/cpu/compare/5326061?baseline=5324484

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 sbc-bench will already do it). And as a side note: with more recent ThreadX versions memory access seems to be faster than in the beginning.

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 sbc-bench -G (always executing GB twice for a reason) ends up with the same picture: standard deviation way too high or in other words: Geekbench 6 on ARM and especially RISC-V sucks:

First run:

   Single-Core Score     949              
   Multi-Core Score      1960              

Second run:

   Single-Core Score     973              
   Multi-Core Score      2010              

https://browser.geekbench.com/v6/cpu/compare/5326624?baseline=5326716

[youmukonpaku1337]

interesting..

[popcornmix]

with more recent ThreadX versions memory access seems to be faster than in the beginning.

Actually there is no ThreadX on a Pi5. The bootloader code runs with no RTOS. ThreadX is used by start*.elf on pi0-4.

SDRAM performance has been improved recently by scaling back refresh with (sdram) temperature See: https://github.com/raspberrypi/firmware/issues/1854#issuecomment-1924141212

[youmukonpaku1337]

with more recent ThreadX versions memory access seems to be faster than in the beginning.

Actually there is no ThreadX on a Pi5. The bootloader code runs with no RTOS. ThreadX is used by start*.elf on pi0-4.

SDRAM performance has been improved recently by scaling back refresh with (sdram) temperature See: #1854 (comment)

is it possible to use both the test bootloader and the patched firmware?

[pelwell]

@ThomasKaiser You keep referring to ThreadX, but there is no ThreadX running on a Pi 5.

[youmukonpaku1337]

nevermind, looks like the sdram change was merged

[nosoul78]

Actually there is no ThreadX on a Pi5. The bootloader code runs with no RTOS. ThreadX is used by start*.elf on pi0-4.

@popcornmix Then what's servicing mailbox requests?

[pelwell]

The bootloader code with no RTOS.

[ThomasKaiser]

gotta break 1k in geekbench for the sillies, will see if i can manage maaaaybe 3.3ghz?

Nope, my board scored 1k already at 3080 MHz. In case of interest I'll share the recipe (but it's really simple, since all you need is a) setting the cpufreq governor to performance and b) patience since Geekbench on ARM and especially on RISC-V is such an unbelievable nonsense).

[ThomasKaiser]

This is what I've done (setting arm_freq=3080 and over_voltage_delta=100000, rebooting, setting cpufreq governor to performance, bringing my 12 bucks 'monster cooler' into position and then simply executing the benchmark 10 times in a row):

echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor for i in 1 2 3 4 5 6 7 8 9 10 ; do geekbench6 ; done

Worst vs. best GB score as follows:

https://browser.geekbench.com/v6/cpu/compare/5329465?baseline=5330184

While we all (should) know that Geekbench has a standard deviation way too high the interesting bit in this series is that the scores generally got better over time (6% more over time is a lot).

On other platforms I experienced stuff like display controller not detecting a display as such shutting down the whole display/GPU IP blocks after 10 minutes which ended up with way higher memory bandwidth for the CPU after that amount of time. But here I'm clueless what's happening...

[youmukonpaku1337]

gotta break 1k in geekbench for the sillies, will see if i can manage maaaaybe 3.3ghz?

Nope, my board scored 1k already at 3080 MHz. In case of interest I'll share the recipe (but it's really simple, since all you need is a) setting the cpufreq governor to performance and b) patience since Geekbench on ARM and especially on RISC-V is such an unbelievable nonsense).

:despair: how about 1100

[ThomasKaiser]

My board (at 3080 MHz) also outperforms the best GB5 score (at 3100 MHz) so far in this mode (headless and uptime +1 hour): https://browser.geekbench.com/v5/cpu/compare/22321360?baseline=22322650

This former best score must also use @popcornmix's latest 'bootloader' release since exceeding 3.0 GHz (though I don't understand how something can be called a bootloader that sits permanently in the background and is accessible via vcgencmd – I really hope we're not dealing with UEFI running in the background now?!)

While GB5 numbers are a bit more related to real-world workloads (hey, a quad-core A76 scores multi-threaded almost 3 times as much as single-threaded and not just ~2 times as with GB6) I still don't understand what's going on.

Using sbc-bench in the same scenario numbers remain the same (with passive benchmarking everything that differs by not at least 5% has to be considered identical):

uptime	Clockspeed	7-zip multi	7-zip single	AES	memcpy	memset
few minutes	3080 MHz	13670	3980	1756000	5990	17260
+1 hour	3080 MHz	13760	3998	1755570	6120	17290

[youmukonpaku1337]

:despair: seems like my pi crashes at multi-core photo library in geekbench at 3.2ghz, i get "hwmon undervoltage detected" although my power supply is fine and is supplying enough..

[youmukonpaku1337]

is it not enough overvoltage? i have overvoltage delta set to 500000 (since it can't use that much anyway i think)

[youmukonpaku1337]

oh yeah... i should set governor to perf as well hmm

[ThomasKaiser]

how about 1100

How about understanding that 'overclocking' an ARM SoC is almost always nonsense?

There's a sweet spot wrt energy efficiency (though IMHO not on RPI 5 with actual firmware DVFS settings) and while a quad-core A76 like BroadCom's Muskoka platform might be able to operate at or above 3.0 GHz it makes absolutely no sense other than generating silly benchmark scores.

Disclaimer: when we were able to buy RPi 5 (vaporware here in Germany for almost half a year) I thought setting arm_freq=3000 would be the way to go on every RPi 5. Not knowing back then that we're winners of the 'silicon lottery' since majority of BCM2712 can't cope with even lower clockspeeds.

And the most important part (people eager to get 'scores' always forget) is: you're entering 'data loss / data corruption' territory. There's a fixed 1000mV limit and I personally achieved already zram filesystem corruption issues with latest 'firmware' above 3.0 GHz.

[ThomasKaiser]

i get "hwmon undervoltage detected" although my power supply is fine and is supplying enough..

No, it obviously is not and you (like vast majority of RPi users – 101%) confuse voltage with amperage.

And BTW: use sbc-bench -G instead since this will monitor benchmark execution and reports your RPi 5 not running at 3.x GHz as you might think but just 1500 MHz once 'undervoltage detected'. It's really funny how every RPi from day one suffered from this 5V undervoltage drama since users don't understand the 5V cable resistance problem (called Ohm's law) :)

[youmukonpaku1337]

i get "hwmon undervoltage detected" although my power supply is fine and is supplying enough..

No, it obviously is not and you (like vast majority of RPi users – 101%) confuse voltage with amperage.

considering that this power supply is the single one that ran this pi for weeks at 3.0GHz with no undervoltage (others spammed that message quite frequently), i'd consider it to be fine, besides, it's PD and has a max output of 30w (15v 2a) or 27w (9v 3a)

[youmukonpaku1337]

okay this happens at 3150mhz as well, on geekbench multicore photo library I get 2 "hwmon undervoltage detected" and then the pi crashes... it's only specifically that benchmark, cpuburn and the other geekbench benches do not have issues

[ThomasKaiser]

has a max output of 30w (15v 2a) or 27w (9v 3a)

Who cares? At least not your RPi 5 since only negotiating 5V modes with whatever USB PD power brick you own. And at 5V it becomes crucial whether the power brick has a fixed cable (allowing it to compensate voltage drops) or not (undervoltage danger). Am out now since too much spam for this issue already...

[youmukonpaku1337]

fixed cable? huh, never heard of that, maybe that might be the issue

[geerlingguy]

@youmukonpaku1337 - There are a few power supplies capable of supplying the clean 5V/5A the Pi 5 requires. Having a cable soldered straight into the power adapter reduces a tiny amount of insertion loss you get with any adapter with a detachable cable. And the longer the cable, the greater the voltage drop (that's why Pi's own 27W adapter has a slightly shorter cable now).

The Pi 5 only negotiates at 5V, nothing higher, so to get the best performance you need a good power adapter that supplies at least 3A (ideally 5A), has a short-ish cable, is permanently attached, and has thick enough individual copper wires to cause as little voltage drop as possible. With all that, you'll have better stability—and can run more off the USB ports if you desire.

Some of those things aren't a big concern when running the Pi 5 at the default 2.4 GHz clock, but when you push limits, it's best to start from the best foundation (power-wise) possible, just like no heatsink is fine for many use cases, but overclocking, you should add a fan and/or good heatsink.

[youmukonpaku1337]

yeah i get that, i thought PD power supplies could negotiate most amp/volt setups as long as its under total wattage... hm ill take a look at whether i can find another one

[youmukonpaku1337]

looks like there are no power supplies with 5v5a support here outside of >100w chargers (20v5a and such) which i unfortunately cannot afford... not fun, why does the pi use out of spec pd lmao

[youmukonpaku1337]

looks like with an acefast a45 charger i got past geekbench without the pi undervolting so, guess im lucky :p

[youmukonpaku1337]

https://browser.geekbench.com/v6/cpu/5344754 managed a 3.175GHz run with a new power supply - unfortunately get undervoltage at 3.2GHz and a kernel panic at 3.3, it'd be great to go past 1v