“WiFi on the Raspberry Pi 5 Model B "d0" boards doesn't work.”
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.
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.
Nice to see BSDs up and working on new RPi hardware. Is there even (mainline) linux support for RPi5 and CM5 nowadays? For what seemed like ages they were unsupported (no usable IO) and I avoided using any of the newer boards for projects as a result, but it's years after the hardware release now so I assume most things must finally be upstreamed?
And involves a proprietary boot blob that gets loaded by the GPU. Though I do not know if this asinine method is still present in the Pi 5. It was inherited from the original Pi's SoC being designed for STB (Set top box for TVs) use. So I assume the GPU boot was meant to possibly enforce some secure DRM boot method.
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.
NVMe hats work in OpenBSD, it's NVMe boot that doesn't work at present. It still needs support added to the U-Boot firmware, which OpenBSD uses here. Raspbian and other Linux distros are typically booted differently on this hardware (Linux kernel image is loaded directly by the GPU, not joking.)
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.
Linux kernel image or another stage of bootloader loaded by the GPU is pretty normal in mobile SOCs like the one that is used here. At least they did not enable secure boot so that it's still possible to execute something else.
I don't remember U-boot support being missing for so long on Raspberry Pi 4. Is there something unique about the Raspberry Pi 5 that makes U-boot support harder?
Neat! I didn't know OpenBSD had any Raspberry Pi support, anyone around with any experience? I have an extra 4 or to and "do stuff with OpenBSD" has been on my list for a while.
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.
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.
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.
Not true, CPU frequency scaling (apmd, cpu.setperf/perfpolicy) is supported on many ARM machines, including the ThinkPad X13s, Apple M1/M2 Silicon, Raspberry Pi 4 (but may depend on whether using EDK2 or U-Boot firmware).
Support for Snapdragon X Elite machines was added as recently as last month, even..
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.
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).
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.
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.
Sure, I think the OP knows this, but another (arguably much more common) way to do fan control is to have a secondary control system (be it a separate management processor, fan IC, management core on the same SoC, whatever) know about temperature curves/thresholds and have that IC handle sensor input to set the PWM.
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.
Not wanting to tell on them, my intel SBC super lightweight cigarette-box board has non-PWM risers. you can add a fan, it's always-on. The BIOS doesn't do anything smart it just volts the fan.
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.
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 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.
The d0 stepping boards I have with wifi work with the linux kernel, still.
https://github.com/openbsd/src/commit/ee2db53800abe0382657ec...
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.
Pretty excited about Pi 5 support!
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.
Support for Snapdragon X Elite machines was added as recently as last month, even..
https://marc.info/?l=openbsd-cvs&m=175395733802655&w=2
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.
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
- Latest firmware installed (much easier to upgrade them from Linux)
- UEFI.
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.
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.