With this change applied to my config.txt, my core voltage goes up to 0.95V from 0.880V under load.

Hm, interesting, it seems Raspberry PI folks do not 100% trust that it won't have side effects though, since it is behind a flag and only gets deployed with new installations, at least that is how I interpret this sentence:

New Raspberry Pi OS images from Bullseye onwards come with this setting by default.

Now, config.txt is also not updated in our case, so this change would affect only new installations. On a quick glance, I lean towards merging this, but I'd like to do some more research.

It seems that the CM4 does not receive the booost. From Eben Uptons response it seems not really a technical limitation, more because of a more conservative approach (from comments in https://www.raspberrypi.com/news/bullseye-bonus-1-8ghz-raspberry-pi-4/):

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.

I any case, I am fine to enable this for Raspberry Pi 4. It could lead to some Pis to get a bit warmer than usual if they are under load, but the Pi seems to behave well when thermally limited.

So how to enable on rp4 in HA os? Is it yaml config or something else?

So how to enable on rp4 in HA os? Is it yaml config or something else?

No it's deep in the system and hidden by default (for good reasons!). People (really) knowing what they do might have a look at https://community.home-assistant.io/t/how-to-access-config-txt-in-hassio/139330/28 topic.

@mhaas @agners I'm wondering if this is really needed for getting a Pi 4 to run at 1.8 GHz. Do you see any advantage of using this compared to arm_freq and a proper over_voltage?

• On the one hand, using

[pi4]
arm_freq=1800
over_voltage=4

in the config.txt always worked, even for HA OS versions prior to 9.0.

• On the other hand, I am quite sure the 1.8 GHz (300 MHz bonus) already came with an quite earlier HA OS update I think somewhere in 2021. Searched for 10 minutes, couldn't find the release notes/PR. Anyway, so 1.8 GHz already was possible with earlier HA OS versions and without the arm_boost=1.

Mine (Pi 4 8 GB version) is running right from the beginning (~ January 2021) at 1.8 GHz max, having above mentioned changes applied to config.txt.

My assumption: using arm_freq=1800 and over_voltage=4 is somewhat similar to using arm_boost=1.

Hardware revision decides if arm_boost is safe to use/working:
This change should be safe for all such boards where "such" refers to All Raspberry Pi 400s and newer revisions of the Raspberry Pi 4B. https://www.raspberrypi.com/news/bullseye-bonus-1-8ghz-raspberry-pi-4/ explains:

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

The comments section reveals that the arm_boost has been added in hardware revision v1.2.
The actual hardware revision can be checked with cat /proc/cpuinfo | grep Model.

If that is equal to or higher than v1.2, arm_boost should be safe to use / work, otherwise using the arm_freq=1800 along with a proper over_voltage is the way to go (according to https://www.raspberrypi.com/news/bullseye-bonus-1-8ghz-raspberry-pi-4/).

Raspberry Pi's before v1.2 only got validated for 1.5GHz. Setting arm_freq=1800 is overclocking. Means, it might work, but if you are unlucky, your particular device is not capable to do it. So setting that by default in HAOS is a no-go.

The arm_boost=1 is a new flag, which enables "smarts" in the Raspberry Pi firmware: Essentially it checks if the system is running on a newer RPi 4, and only if so, enables 1.8GHz. That is not overclocking, but just clocking at the highest validated speed...

Good summary, thank you. So arm_boost=1 does not require a over_voltage setting as the firmware takes automatically care of it, which is end the end quite "safe" to use. I think I'll replace my two "old-style overclocking" lines with the arm_boost flag.

It is a installed/running system with hardware revision 1.4 (8 GB version) so it always was safe to use arm_freq.

After shutting down my RPi 4B (running Home Assistant), I removed the SD Card and mounted all partitions on a Linux system - I was easily able to access and modify the HASSOS-Boot partitions' "config.txt", however the arm_boost=1 does not work for me (checked via HA's Terminal using the command cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq).

After 3 "Reboots" (not "Restarts") of Home Assistant, I was not able achieve the 1.8GHz objective. However, after adding arm_freq=1800 and over_voltage=4 overlays, I was able to achieve the 1.8GHz speeds. My RPi 4B 4GB board is in-fact a v1.2 board, so I am not certain as to why I was not able to use arm_boost=1 - maybe because I am using a Home Assistant 32bit, but normally that doesn't really matter - at least as far as I know. I am also NOT seeing any increase in temperature, even running a Genie Server and multiple other resource-intensive Add-On's.

Oh well - objective achieved either way.

Quick follow-up:

Since switching from arm_freq=1800 and over_voltage=4 to arm_boost=1 compared to this screenshot I noticed the clock very rarely (for some days never) clocks down but stays at 1.800 MHz:

I don't know if that results in a speed increase or power usage increase as I didn't notice the first and don't monitor the power usage of the Pi 4.
Just want to say: both methods seem to achieve the same thing, but things are different in the end though.

I also noticed that ghe CPU frequency seems to be stuck at 1.8 GHz. But this is not the case when you check the statistics of the scaling governor:

Perhaps the cpu now ramps up very quickly to 1.8GHz so the script that checks the frequency only sees 1.8GHz.

I can share my script to get the distribution tomorrow if desired.

I can share my script to get the distribution tomorrow if desired.

@mhaas Yes, please! That would be great.