Call for testing: NextBSD on the Raspberry Pi 5 family

[pkgdemon]

This is the first NextBSD image for Raspberry Pi. It boots to a graphical console on HDMI, takes a USB keyboard, gets an address over Ethernet, and installs itself to internal NVMe. We would like people to try it on hardware we do not have.

Which boards

One image covers the whole BCM2712 family. It ships all eight device trees and lets the Pi firmware pick by board revision, so there is nothing to configure:

• Raspberry Pi 5 (including the D0 stepping)
• Raspberry Pi 500 and 500+
• Compute Module 5 and CM5 Lite, on either the CM4IO or CM5IO carrier

Only the Pi 500+ has actually been tested. The rest should work — same SoC, same drivers, and the firmware selects the device tree — but "should" is exactly what we are asking you to check. If you have a Pi 5 or a CM5, you are testing something nobody has run yet.

This image does not cover the Pi 4 or earlier. Different SoC, different southbridge; that is separate work.

What works

• Video — HDMI console at the mode your display reports, 32-bit colour
• USB — keyboard and mouse on the built-in ports
• Ethernet — the on-board gigabit NIC, with DHCP
• NVMe — both as an install target and to boot from
• SSH — once it is on the network
• The installer — installs to internal NVMe and boots unattended afterwards

What does not work yet

Worth reading before you start, so you know what is a known gap and what is a real bug worth reporting.

	Status	Follow
Wi-Fi	not yet — the SDIO path for the BCM43455 is unported	kernel#99
Bluetooth	not yet — NextBSD has no Bluetooth stack at all	nextbsd#412
microSD slot	not driven — see below	kernel#100
GPU acceleration	none; the console is an unaccelerated framebuffer and the mode is fixed at boot	kernel#111
Cooling fan (Pi 5 B)	not driven — a fitted Active Cooler never spins	kernel#112
CPU temperature	cannot be read from inside NextBSD — no sensor driver	kernel#112

Those tickets are where the work actually happens, so they are the honest place to watch. Use Subscribe on any of them and GitHub will tell you when it closes.

One caveat so nobody is misled: an open ticket is a statement of intent, not a date. None of these carry a schedule, and some are explicitly deferred — Wi-Fi and the SD controller are both parked until the first milestone lands. If you need a feature to exist by a particular time, say so on the ticket rather than assuming it is queued.

The microSD slot matters for how you boot this. The SD host controller has no driver yet, so although the firmware can read the card, the NextBSD kernel cannot — it will boot partway and then fail to mount root. Write the image to a USB stick, not a microSD card. Install to NVMe from there.

Cooling, if you have a Pi 5 B

The Active Cooler and the official case fan are driven by the operating system on this hardware rather than by the firmware, and NextBSD does not drive them yet — so a fitted fan will not spin. Tracked as kernel#112.

This is safe. Thermal protection on BCM2712 lives in the firmware, which throttles the clocks on its own at around 80 °C no matter what the OS knows about it. The board looks after itself and nothing is at risk of damage. What you will notice instead is a machine that gets slower under sustained load, because it is cooling passively through a heatsink that was sized on the assumption a fan is running.

So please do not report "the Pi 5 gets slow under load" as a bug — that is #112, and it is expected for now. Do report it if a board becomes unstable, hangs, or powers itself off, which would be something else.

NextBSD cannot currently read the SoC temperature either — the sensor has no driver, and vcgencmd is not available because the /dev/vcio device it talks to is not compiled in yet. So there is no way to check the temperature from inside the OS, and no need to report that as a bug; both halves are part of the same ticket. If you want a number today, boot Raspberry Pi OS on the same board and run vcgencmd measure_temp.

The Pi 500 and 500+ are unaffected: they have no fan, and cool passively through the heatsink plate in the chassis by design. On a CM5 it depends on your carrier board and whatever heatsink your integrator fitted — worth watching if you are running one hard.

Writing the image

Grab the NextBSD-arm64-rpi5-*.img.zip asset from the continuous release:

https://github.com/nextbsd-redux/nextbsd/releases/tag/continuous

The build at the time of writing is NextBSD-arm64-rpi5-20260825-041445.img.zip (160 MB). That release is rebuilt continuously, so the date in the filename will move — take whichever rpi5 asset is there when you look.

Verify and unzip:

shasum -a 256 -c NextBSD-arm64-rpi5-*.img.zip.sha256
unzip NextBSD-arm64-rpi5-*.img.zip

macOS — find the disk, unmount it but leave it attached, then write to the raw device (rdisk, not disk; it is far faster):

diskutil list
diskutil unmountDisk /dev/diskN
sudo dd if=NextBSD-arm64-rpi5-*.img of=/dev/rdiskN bs=4m

Press Ctrl-T during the write for a progress report.

Linux:

sudo dd if=NextBSD-arm64-rpi5-*.img of=/dev/sdX bs=4M status=progress conv=fsync

Raspberry Pi Imager works too — choose "Use custom" and select the .img.

Double-check the device name. dd will happily overwrite the wrong disk.

First boot

Plug the stick into a USB port, connect HDMI and a keyboard, and power on. You should get kernel messages on the display within a few seconds and a login prompt shortly after.

Log in as root, no password.

To install to internal NVMe, run:

nextbsd-installer

It does not create a user or set a hostname — the installed system also boots to a passwordless root, and you set things up from there.

Optionally: the Gershwin desktop

Once installed and on the network, this builds and installs the Gershwin desktop. It compiles a fair amount from source, so give it time and do it on an NVMe install rather than on the USB stick.

pkg update
pkg install -y xlibre git
git clone -b dev https://github.com/gershwin-desktop/gershwin-developer.git /Developer
/Developer/Library/Scripts/bootstrap.sh
BRANCH=dev /Developer/Library/Scripts/checkout.sh
cd /Developer && make install
. /System/Library/Makefiles/GNUstep.sh
dscli init
cd /System/Library/LaunchDaemons/
REPO=https://raw.githubusercontent.com/gershwin-desktop/gershwin-desktop/main
BASE=$REPO/targets/nextbsd/overlays/System/Library/LaunchDaemons
fetch $BASE/org.gnustep.gdomap.plist
fetch $BASE/org.freedesktop.dbus-system.plist
fetch $BASE/io.github.gershwin-desktop.dshelper.plist
fetch $BASE/io.github.gershwin-desktop.loginwindow.plist
reboot

Gershwin on the Pi 500+ — captured from the board itself, not a mock-up. 16 GB, Cortex-A76, NextBSD 15.1.

After the reboot completes you can log in as admin with no password. Passwords can be set and users managed with sudo dscli.

Remember there is no GPU acceleration yet, so the desktop is drawing entirely on the CPU. Judge it accordingly.

If it does not boot

Almost everything on this board fails as silence rather than as an error message, so a blank screen is not very diagnostic on its own. Useful things to tell us:

• Which board, and the revision — cat /proc/cpuinfo under Raspberry Pi OS gives it
• How far it got: no display at all? firmware rainbow splash then nothing? kernel messages then a stop?
• Where it stopped, if you got any text

If you can, a serial console is worth far more than a description. Use the debug UART on the 3-pin JST-SH connector at 115200 8N1 — not the 40-pin header, which is behind the PCIe southbridge and goes quiet early in boot. Paste whatever it prints, even if it looks like nothing.

If you get no video

A blank screen and a dead board look identical here, so establish first whether the machine booted at all — the serial console above answers that, and so does checking whether it picked up a DHCP lease on your network.

If it did boot and you simply have no picture, you can change the video settings without rebuilding anything. The first partition of the image is FAT32, labelled NEXTBSD, and any desktop OS will mount it: write the stick, plug it back into your computer, and config.txt is at the top level. Edit it, save, eject, boot.

This is the video block we ship:

max_framebuffers=2
display_auto_detect=1
hdmi_force_hotplug=1
framebuffer_depth=32

• max_framebuffers=2 — makes the firmware allocate a framebuffer at all. Without it there is no display and the console comes up with no driver.
• display_auto_detect=1 — lets the firmware probe your monitor and configure whatever it finds.
• hdmi_force_hotplug=1 — drive the output even if hotplug detect says nothing is attached. This was needed on the Pi 500+ with a micro-HDMI adapter that does not wire pin 19: the monitor's EDID read perfectly over DDC, but the firmware still reported no display.
• framebuffer_depth=32 — 32-bit colour.

Things to try, roughly in order:

Use the HDMI port nearest the power connector. On a Pi 5 B that is HDMI0, and the firmware brings it up first.

Try 24-bit colour. Change the depth line to:

framebuffer_depth=24

On the Pi 500+, 32 is the value that works, and 24 produced a smeared, dim console — 24bpp packs three bytes per pixel where the driver writes four, so every pixel lands a byte out of alignment. But the 500+ is the only board anyone has run, and "no picture at all" is a different failure from the one we measured. If 24 gives you a working console where 32 gave you nothing, please say so — that is a genuinely useful data point, and it would point at a driver bug rather than a setting anyone should keep.

Try ignoring the alpha channel. Keep the depth at 32 and add:

framebuffer_ignore_alpha=1

Worth a go if your monitor reports a valid signal but the screen stays black. Untested on this family — tell us either way.

If the picture is fine but the resolution is wrong, that is the firmware's choice, made from your monitor's EDID. Forcing a mode with hdmi_group/hdmi_mode or framebuffer_width/framebuffer_height was measured to be ignored on this board, so there is no setting to change — just report what it picked and what you expected.

Whatever you change, tell us what you changed and whether it helped. Half the value of this section is finding out which of these matter on boards nobody has tested.

Reporting

Reply here for anything that is a question or a "worked on my Pi 5" data point — those are genuinely useful, positive results included, since most of these boards are untested.

Open an issue for reproducible bugs: https://github.com/nextbsd-redux/nextbsd/issues

One known cosmetic thing, already fixed and landing in a later image: every board comes up with the same hostname, because the hostname is derived from SMBIOS and the Pi has none. No need to report it.