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?

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?

and so continues the noble *nix tradition of supporting new hardware... well, some of it anyway

• p1necone

  yesterday at 11:37 PM

  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.

  • brynet

    today at 1:23 AM

    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.

    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

    • hugo1789

      today at 8:57 AM

      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.

  • reactordev

    yesterday at 11:53 PM

    Different chip I would assume.

    Yup, a different BCM2712 chip

• SlowTao

  today at 2:04 AM

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

  • grg0

    today at 3:04 AM

    You're gonna need those fans at max speed to compile the kernel at record speed.

    QED.

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

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

• yc-kraln

  today at 7:38 AM

  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.

The actual commit referred to in the mailing list:

https://github.com/openbsd/src/commit/ee2db53800abe0382657ec...

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.

• raddan

  yesterday at 10:04 PM

  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!

• daneel_w

  today at 12:08 AM

  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.

  • brynet

    today at 1:40 AM

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

    https://marc.info/?l=openbsd-cvs&m=175395733802655&w=2

    • daneel_w

      today at 11:03 AM

      Then I stand corrected. Seems I've had the misfortune of buying only the Arm SoCs/boards where OpenBSD so far cannot control the CPU frequency.

• bilegeek

  yesterday at 11:00 PM

  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.

• accrual

  today at 3:13 AM

  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

• snvzz

  today at 12:01 AM

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

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

  - UEFI.

Out of curiosity, why would you prefer OpenBSD over Linux on a Pi?

• irusensei

  today at 9:34 AM

  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.

• accrual

  today at 3:05 AM

  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.

>The active cooler (fan) doesn't work because of missing pwm/clock drivers (some work is in-progress).

Wait what? How is this the OS's sole role?

What is the mcu the rpi5 has onboard even for?

• dragontamer

  today at 12:22 AM

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

  • bri3d

    today at 2:16 AM

    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.

    • ggm

      today at 3:57 AM

      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.

    • snvzz

      today at 5:57 AM

      Most importantly, even if control was delegated to the CPU, it could still take over in the event of temperature exceeding some safety threshold.