Bullseye bonus: 1.8GHz Raspberry Pi 4

Yesterday we released our first Raspberry Pi OS image built on top of Debian Bullseye. Alongside the usual package upgrades that accompany every major Debian release, this provides a more modern composited desktop environment on Raspberry Pi 4 boards with 2GB or more of memory, and retires our legacy display and camera support in favour of KMS and libcamera respectively.

1.5GHz to 1.8GHz

But some of you may have noticed another upgrade. Users with recent Raspberry Pi 4 devices will find that their default turbo-mode clock has increased from 1.5GHz to the 1.8GHz used on Raspberry Pi 400. “Recent” in this case means any 8GB Raspberry Pi 4, or a 2GB or 4GB board with the extra components circled in the image below. This is the dedicated switch-mode power supply (“switcher”) for the SoC core voltage rail, and was introduced when we shuffled the allocation of switchers to rails to support 8GB.

Through extensive testing on the production line, we have qualified an operating voltage for 1.8GHz, and satisfied ourselves that the new switcher is able to supply enough current to run even the heaviest workloads at that speed.

Overclocking older Raspberry Pi devices

What about older devices? Even the launch-variant Raspberry Pi 4 has gained a reputation for overclockability, and most units will run most workloads at well over 1.5GHz with a little extra core voltage. The latest firmware (included in the Bullseye image) will even do its best to figure out the best voltage to apply for a given overclock. To manually replicate the new operating point on an older board, just add the following line to your config.txt file:

arm_freq=1800

If you encounter stability issues, you can try backing off the frequency in 50MHz steps, or manually setting an overvoltage. But remember: playing with clocks and voltages can render your SD card (temporarily) unbootable, so make sure you have another card (or another computer) on hand that you can boot with to restore your config.txt to good sense.

49 comments

Avatar

Thanks! I will attempt after bullseye.

Avatar

Thank u. It worked for me. I set it over_volatge=2. This best for me.

Avatar

I wonder if it is possible to see from SW readout, whether the HW is using new “dedicated switch-mode power supply”. E.g. hw revision readout or similar?

Eben Upton

I believe the relevant revision codes are b03114, c03114, d03114, for 2GB, 4GB, and 8GB respectively. More here: https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#raspberry-pi-revision-codes

Avatar

It doesn’t work with 8GB. It is still blanking all times.

Avatar

Raspberry Pi official 7 inch display is no more compatible ?

Eben Upton

It is. If you’re seeing issues, can you report them either in the comments to yesterday’s post, or on the forum.

Avatar

No sorry it was just a bad translation of the post and an error of understanding

Avatar

ewery HDMI display working, i use my pi 4 10 inch hdmi, 17 inch old laptop hdmi, 22 inch display and new 24 inch wide display all working fine whit raspi.

Avatar

Will the change to enable this be fed into Debian for their native RPi support? Is it possible to enable it on native Debian today?

Avatar

Yes. Add `arm_boost=1` to config.txt.

Avatar

Thanks. It didn’t work for me, but I see e.g. https://www.reddit.com/r/raspberry_pi/comments/qpb7yl/comment/hjte0hr saying the firmware needs to be updated for this to work, so I’ll try that.

Avatar

Based on my own testing with a few Pi 4s, which happened to have SoCs with the ‘C0’ stepping versus the ‘B0’ stepping, I had assumed (incorrectly) that that was the difference that led to the boost being applied or not. But after hearing from people with newer Pi 4s with B0 chips getting the boost, and seeing that the CM4 isn’t getting the boost automatically, I realize that it’s the Revision of the Pi 4 board, as mentioned in this post.

Good to know, and it would be interesting to read more sometime about the power circuit design for the Pi 4 and how it evolved from that early revision with the USB-C charging issue to today!

Avatar

I’ve had my Pi 4 8GB (bought on launch day back in 2020) running at 2.36GHz stable, with temps usually hovering between 46C to 56C (e.g. after binge watching Netflix for 8 hours or more).
I house it in an Argon One M.2 case with a 500GB SSD. Boots up in 4+ seconds (Ethernet only, no WiFi/BT, static IP, so no DHCP wait time at startup).
Besides Netflix, we use the unit to watch Disney+, HBO Go and YouTube. And all this on Buster. Have yet to test how much smoother the KMS driver in Bullseye is for streaming video, compared to the Fake KMS driver in Buster. Also wondering if the switch to the Mutter window manager causes any loss in frame rates compared to Openbox.

If you would like to see how far you can push your own Pi 4 8GB, below are the relevant settings I use in my config.txt. Note that these settings are tweaked for my Pi 4 8GB B0T revision of the SoC (with USB SSD boot w/o WiFi or BT) for use as a streaming video player. You could probably go even higher than 2.36GHz with your unit, but the goal is stability under load:
———-
[all]
boot_delay=0 # remove this if you boot from a micro SD card, USB HDD or have a slow SSD adapter
initial_turbo=60 # sets the ARM cores to max speed for just 60 seconds, to help speed up boot time a bit.
dtoverlay=disable-wifi #turns off WiFi (for those who use Ethernet only)
dtoverlay=disable-bt # turns off Bluetooth
arm_64bit=1 # puts the kernel into 64-bit mode (but userland remains 32-bit on armhf versions of RPi OS)
hdmi_enable_4kp60=1 # enables 4K mode. Also boosts the base GPU core speed to 550Mhz
over_voltage=12 # increases power to the SoC. Try from 6 to 12. Max value is 15.
arm_freq=2360 # sets the ARM core’s frequency (in MHz).
arm_freq_min=100 # allows the ARM cores to step down to a low 100MHz during idle, so less heat produced. (Disable this if you do timing-sensitive stuff like retro-gaming).
gpu_mem=256 # sets the memory split (in MB) between the ARM and GPU cores, out of the first 1GB of memory. I find that 256MB to be the sweet spot for smooth video streaming.
gpu_freq=900 # Sets the GPU’s frequency (in MHz)
h264_freq=900 # Sets the H.264 block’s frequency. (H.264 decoding is used in HBO GO video streaming and Youtube (if the h264ify Chrome extension is used)
v3d_freq=900 # Sets the 3D core’s frequency
hevc_freq=900 # Sets the HEVC (High Efficiency Video Coding) block’s frequency. Used heavily for Netflix and Disney+ video streaming.
———-
To run reliably at these speeds, you need good cooling (preferably active cooling, as found in the Argon One cases with their built-in fans). Without sufficient cooling, your unit will throttle itself once it hits 80C or it may even hang during heavy processing loads. Your unit may require more voltage to reach 2.36GHz. If needed, the over_voltage setting can go as high as 15, but try to get stable max speeds at the lowest over_voltage setting you can. I used to set over_voltage=10 but then needed a bit more oomph to run stably at 2.36GHz, so I now use over_voltage=12. Your unit may be different. Try at your own risk.

Avatar

Thanks – really useful if I ever want to test this out one day!

Avatar

8GB version, 2.35GHz, over_voltage=10, 550MHz core, 750MHz GPU. Stable. force_turbo=1 (main reason – lower latency in desktop). At idle, hovering around 14˚C above ambient temp. At load, about 21˚C. The 14˚C can be 11˚C if I don’t force turbo.
CooliPi heatsink/coolercase.

Avatar

Thanks. I will attempt this after I upgraded to openCV4.5.4.

Avatar

Hi, Are you running bullseye on you pi in the Argon one M2 case ? When I booting from the SD card I see a bit of text on initial boot then nothing. If I remove the pi form the case I have no issue over micro HDMI.

Avatar

Great config- works flawlessly for me too (same Argon SSD case!). Thanks for sharing

Avatar

You wrote: “arm_freq_min=100 # allows the ARM cores to step down to a low 100MHz during idle”.
Does the kernel allow a clock-frequency below 600MHz? I though that the current kernel ignores the settings of arm_freq_min due to stability issues. Can you please confirm that with your settings the frequency really goes below 600MHz?

Avatar

Thank you very much for the tip. I’ll be using that on my own system. However, I’d like to make you aware of the fact that Disney+ and Netflix are important proponents of DRM on streaming video and were in fact responsible for adding requirements for its support in web standards (there have also been several occasions that both companies have blacklisted Linux devices from their service). This technology generally worsens the user experience, greatly limits what you’re allowed to do with your computer or media (both legally and physically) and is generally a giant pain in the rear considering that as a paying user you’re probably not one to pirate their stuff anyway. If you’ve got any other entertainment options, since you’re already using a (mostly) open-software system, can you consider alternatives that aren’t as damaging to our Internet freedoms?

Avatar

I’m trying to place a bulk order of Raspberry Pi 4. Does anyone have any trusted partners they’d recommend?

Alasdair Allan

Our lovely Approved Resellers should have you covered. If you scroll down to the bottom of product page and select your country you should get a list of Approved Resellers in your country. You should contact them directly via email if you’re looking to bulk order.

Avatar

Ok. Rest of the world – any kind af ram.
So. Where?!

Avatar

.. the pi hat..

Avatar

This page: https://www.raspberrypi.com/software/operating-systems/#raspberry-pi-os-32-bit
says the kernel version is 5.10. Is that correct?

Avatar

5.10.63 in Bullseye, 5.10.17 in Buster

Avatar

A fully updated Buster will be running the exact same kernel as a new Bullseye installation. I’ve just done a side-by-side check on two Pi4s, and they are both running kernel 5.10.63 compiled by gcc 8.4 – although the Bullseye toolchain itself is obviously based on the newer gcc 10.2.

Avatar

5.10.73 Bullseye

Avatar

How about the cm4?

Eben Upton

CM4 remains at 1.5GHz by default. With Compute Module we are much more focused on providing a stable, consistent, platform for our industrial customers than on pushing the performance envelope.

Avatar

I’m probably reading too much into what you posted about the CM4 here, but can we expect 1.8GHz to be stable on the regular Pi 4? I had assumed that’s what “qualified” meant, until that word “stable” popped up. 🙂

Avatar

Nothing like a free performance upgrade to make my day. Thank you!

Avatar

Can’t wait to test the performance. Hope old 4GB rpi4 is compatible with it.

Avatar

Eben is the MAN!!
RaRRRR!

Avatar

How do you detect the proper hardware via software? I do not want to dismantle all the hardware builds to identify if my hardware is supported – you know – without updating to it to find out the hardware.

Avatar

when will the MB for the pi 400 8gb ram be out ??

Avatar

Hi, I know you’ve updated to Bullseye and want people to use it. Also, I see you want folks to use the Raspberry Pi Imager. It would be great if you had the choice to download recent Buster from the Imager – Bullseye just aint up for the task for many applications yet. The camera libraries in particular. Any chance Buster can be added to the imager? Digging up the right ISO via https://downloads.raspberrypi.org/raspios_lite_armhf/images/raspios_lite_armhf-2021-05-28/ is all well and good. But not so simple. Thanks, and btw, love everything you do.

Avatar

Interesting post. When I investigated cofig.txt on my Pi4 I found arm_freq set to 800 (with a reference to the default being 700). I’ve set the value at 1800 with no immediate issues. The processor temperature has increased slightly (55 to 57) and everything feels snappier. So I am happy but puzzled.

Avatar

A fully updated Buster will be running the exact same kernel as a new Bullseye installation. I’ve just done a side-by-side check on two Pi4s, and they are both running kernel 5.10.63 compiled by gcc 8.4 – although the Bullseye toolchain itself is obviously based on the newer gcc 10.2.

Avatar

I’m putting his here for the benefit of partially competent Pi users such as myself, and because there’s a similar ‘setup’ report above. I have just installed Bullseye- I waited for a while, for more expert users to sort most of the problems. It’s on a Revision 1.1 4 GB Pi4B using SD card boot. It is powered as an Ethernet gadget through the dual role enabled USB-C power/ data port. It is connected through Bonjour/ PuTTY and RealVNC via a mains-connected Atom powered HP small laptop USB-A. I continued the same overclocking I have used on Buster for a year or so. Over_voltage 4 and arm_freq 2000 with gpu_freq 700. I just ran the 4B stress test described on the blog and MagPi, including glxgears. Using this tenuous power supply it ran at 2 GHz for just over 15 minutes on its side, until it crashed at 79 degrees- according to the apparently unreliable panel CPU temperature monitor. It didn’t give the lightning bolt low voltage indicator, and by the time I had restarted PuTTY it seemed to have rebooted itself so that I could login again and restart VNC. I understand this Ethernet Gadget/ dwc2 method is rather deprecated, but it suffices for routine tasks and is simple

Avatar

Nice work, but not applicable for me, since there are no Raspberry Pi 4 / 8GB available on the market (germany) since several month. The so called “chip crises” has hit the bull’s eye (attention! wordplay…), my beloved Raspberry. Or was it the BREXIT?
A lot of projects are endangered because of the lack of the RPi. The foundation should better take care for it’s supply chain. Oh, wasn’t SONY involved (PS5…)?

Avatar

Was this added on revision 1.4 or on revision 1.2?
Is the “arm_boost=1” option ignored on older revisions?

Avatar

I found the answer. The table that shows the “arm_freq” values per model has a specific note for RPi 4 revision 1.2.

Avatar

How do you detect the proper hardware via software? I do not want to dismantle all the hardware builds to identify if my hardware is supported – you know – without updating to it to find out the hardware.

Liz Upton

Command line:

cat /proc/cpuinfo

Avatar

Does anybody know what type the circled (BGA20?) PMU is.
The main PMU is MxL7704(-P4). But the CPU (VDD_CORE – TP15) is no longer connected directly to the MxL7704 in Rev1.4.
So how is this new IC called? (And where can I get a replace).

@Mr. Upton: Perhaps some future eeprom-release can contain a bit of code reprogramming the MxL7704 right after boot. When replacing a broken MxL7704 with some “buyable” Version, the Pi4 will boot: But during eeprom phase (scanning for devices …etc…), DRAM and CPU unnecessarily get higher voltages (until the SD-Card boot kicks in and reprograms the I2C registers of the PMU)…

Thanks and BR

Leave a Comment

Comments are closed