Yes. I run my mail server on a Raspberry Pi 4 on OpenBSD. Aside from having to flash an SD card (and having the install program install the sets to… itself) everythhing works exactly as you expect on any other OpenBSD install. You can’t really stray far outside the list of supported hardware unless you plan to roll things yourself, however. Eg, I’ve discovered that Waveshare carrier boards for the CM4 are hit or miss. NetBSD has much more comprehensive support for Raspberry Pis and the various accoutrements.

Pretty excited about Pi 5 support!

Couple of caveats:

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.

Besides reading documentation, before installing, you should ensure you have:

- Latest firmware installed (much easier to upgrade them from Linux)

- UEFI.

Heads-up: OpenBSD does not yet support power-saving on anything Arm64. The CPU will be running at full throttle the entire time, which will be a showstopper in some cases.

Current release (7.7) and previous (7.6) worked great on my Pi 4. There were a few extra setup steps due to the unique firmware boot setup, but after it works exactly like any other OpenBSD system. I rarely think about it being ARM64.

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

I have used OpenBSD on first a Raspberry Pi 3 and then 4. I liked it, until one day the system stopped responding on either SSH and the serial port, so I had to cut the power to reboot. That's fine, these things happen, but I lost several system files in the process and I couldn't figure out which ones. I only noticed because some things no longer worked and there were some files in /usr's lost+found.

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.

I found it funny that the missing pcie storage hat support had a reason, but the wifi issue is just 'doesn't work'. I wonder if it's a totally unexplored problem.

Can compile the kernel at record speed! Fan speed support... nope!

And so continues the noble hardware vendors' tradition of not documenting their stuff.

> How is this the OS's sole role?

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.

I use OpenBSD on a Pi 4 because hardware support is good and it's a fun device - rarely can I stuff a running OpenBSD system into my pocket.

One thing cool about OpenBSD is that the base OS has a lot of things out of the box. I think a lot of OpenBSD-fied tools like httpd, spamd are part of the base OS. You can even setup wireguard tunnels using nothing but ifconfig.

For starters, Linux is messy. Each distro is different from each other with little consistency. There are even distros specific to device families, like the Raspberry Pi.

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.

The stepping didn't kill wifi, the boards they ran with the d0 stepping have likely a different wifi chip (it's connected externally) or similar (maybe the wifi chip has a different stepping?), unrelated board-level changes.

The d0 stepping boards I have with wifi work with the linux kernel, still.

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

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.

In the absence of other information I'd just say that this feels like something that will probably be fixed pretty quickly in OpenBSD.

Apparently they have a strange boot chain that starts with the GPU.