Raspberry Pi 5 Support (openbsd)
Posted4 months agoActive4 months ago
marc.infoTechstory
supportivepositive
Debate
40/100
OpenbsdRaspberry Pi 5BsdOperating System Support
Key topics
Openbsd
Raspberry Pi 5
Bsd
Operating System Support
The OpenBSD operating system has added support for the Raspberry Pi 5, sparking discussion among users about its capabilities, limitations, and comparisons to Linux.
Snapshot generated from the HN discussion
Discussion Activity
Moderate engagementFirst comment
32m
Peak period
8
0-3h
Avg / period
4.5
Comment distribution36 data points
Loading chart...
Based on 36 loaded comments
Key moments
- 01Story posted
Sep 1, 2025 at 5:03 PM EDT
4 months ago
Step 01 - 02First comment
Sep 1, 2025 at 5:36 PM EDT
32m after posting
Step 02 - 03Peak activity
8 comments in 0-3h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 3, 2025 at 3:34 AM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45096585Type: storyLast synced: 11/20/2025, 3:22:58 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Support for Snapdragon X Elite machines was added as recently as last month, even..
https://marc.info/?l=openbsd-cvs&m=175395733802655&w=2
- Latest firmware installed (much easier to upgrade them from Linux)
- UEFI.
1. Last I tried about 9mo. ago on a Pi 4, you still need 3rd party firmware to make use of >3gb RAM. Unfortunately, I couldn't get that to work.
2. Even though the full image has the complete software set, the installer can't see it; you have to either use the network (I have a datacap, it's a pain point with FOSS sometimes), or load another drive with the sets.
Pretty excited about Pi 5 support!
Runs great even in a passive enclosure. It's gotten it quite hot before when left it running in a backpack by mistake... but it remained perfectly stable and I could SSH into it (though I didn't dare touch it).
https://www.openbsd.org/arm64.html
OpenBSD's file system does not have journalling. Their closest equivalent, soft updates, was removed some versions ago, so that they can add journalling later. Until that happens, I will install OpenBSD anywhere again.
That's a shame because apart from that, it really is a good operating system. The documentation is excellent and there are some great services in base. I much prefer OpenSMTPD over Postfix, for example, because it's just a lot simpler and I don't feel unsure if I've missed some option that I really needed to change for the system to be secure.
Also, Wi-Fi is supported on some Raspberry Pi 5 models, with the bwfm(4) Broadcom driver. It's just the later D0 hardware stepping that doesn't, C1 works fine.
https://marc.info/?l=openbsd-cvs&m=175526487704135&w=2
I believe Ethernet may also be working via the cad(4)/Cadence driver, but I don't have the hardware to test it.
https://marc.info/?l=openbsd-cvs&m=175561863928051&w=2
Yup, a different BCM2712 chip
QED.
Wait what? How is this the OS's sole role?
What is the mcu the rpi5 has onboard even for?
Embedded Design.
A PWM driver (or a hardware timer) will handle the nanosecond-to-nanosecond wait states and counts, but the OS has to still setup the hardware timer to send the right PWM wave down to the system.
Besides, the OS should have some degree of custom fan controls for any modern computer, embedded or not. My PC can control all of my fans for example.
This is the usual way things are done on x86 with ACPI, for example - unless the OS or some userland fan manager elects to take over via the OSPM fan objects, the fans control is delegated to the BIOS/platform firmware. If I boot an OS with no notion of a fan on a common x86 motherboard, it will still cool reasonably well (usually). Same deal for Macs with SMC - unless the OS tells the SMC explicitly to quit handling the fan, the SMC deals with all the thermals with no intervention.
I think it's not that unusual for people to delete things they hoped they didn't need, the device targets passive cooling deployments: Turns out a lot of us run them in hot locations.
Sometimes we don't want to have to keep around a cheat sheet so we can have commands we're accustomed to, then we have the corresponding ones we need to know for a separate device.
The BSDs are much cleaner and more consistent. You can run the same OS on your desktop and your Arm machine. Tinkering is fine, but there's a time and a place for everything, and sometimes we just want to run stuff and tinker with what we're running, not necessarily with the underlying OS.
OBSD reports
> “The 4GB and 8GB variants of Raspberry Pi 5 are built around two key chips: the RP1 I/O controller, developed here at Raspberry Pi and providing the interfacing capabilities of the platform; and BCM2712C1, a 16nm application processor built by our friends at Broadcom. BCM2712C1 is a hugely complex and powerful device, with a quad-core Arm Cortex-A76 application processor running at 2.4GHz, and the latest iteration of the VideoCore multimedia platform. Alongside the features required to power a Raspberry Pi, it also contains functionality intended to serve other markets, which we don’t need. This ‘dark silicon’ is permanently disabled in the chips we use, but takes up die space, and therefore adds cost. The new D0 stepping strips away all that unneeded functionality, leaving only the bits we need.”
This is what Eben Upton reported on 19th Aug 2024. [0] and Geoff Geerling makes a comment on chip revisions. [1]
> “Steppings are basically chip revisions where they don't change functionality, and usually just fix bugs, or tweak the layout. But even tiny design changes could have unintended consequences.”
So the dark silicon removal step from BCC1 to BCD0, a cost cutting measure, killed wifi? Damn, I was hoping to use this for a obsd firewall.
Cf:
[0] <https://www.raspberrypi.com/news/2gb-raspberry-pi-5-on-sale-...>
[1] < https://www.jeffgeerling.com/blog/2024/new-2gb-pi-5-has-33-s...>
The d0 stepping boards I have with wifi work with the linux kernel, still.
“WiFi is still via SDIO on the Broadcom chip, IIRC.”
<https://www.jeffgeerling.com/comment/34061#comment-34061>
And
“Ran a quick search on Raspberry Pi's github linux repo and found where I got my info from re the stuff they took out on D0. From what I can see, they actually removed device tree support for parts of the chip they don't use on C0/C1 that are not present on D0, and folded these changes into the same DTS file. They also seem to have added a DTS specifically for the D0 stepping, which seems to be register changes, i.e. stuff that is present in both variants of the chip but has moved or needs to otherwise be handled differently between C1 and D0. See https://github.com/raspberrypi/linux/pull/5847, specifically for the bits removed see <https://github.com/raspberrypi/linux/pull/5847/commits/8be08...>“
<https://www.jeffgeerling.com/comment/34061#comment-34061>
Something broke. Without going through the obsd code it remains unknown. Unless there is reference to uart3 & uart4?
The boards that have the D0 parts have other changes as well.
Lack of WiFi shouldn’t be a problem for a firewall board, unless you’re planning to make it a WiFi router/AP as well.
https://github.com/openbsd/src/commit/ee2db53800abe0382657ec...