Thanks! I will attempt after bullseye.

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?

Raspberry Pi official 7 inch display is no more compatible ?

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?

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!

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.

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

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

How about the cm4？

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

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

Eben is the MAN!!
RaRRRR!

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.

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

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.

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.

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.

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

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…)?

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

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.

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