Mobile Linux exists in every shape: postmarketOS, Mobian, Sailfish, Ubuntu Touch, GrapheneOS on the high end, and the bare upstream Megi tree on the PinePhone family. Mobile BSD is a rounding error. There’s a NetBSD port that boots on a Nokia 770. There’s the OpenBSD-on-Pinebook-Pro work that gets close to a phone but isn’t one. There’s Honeyguide, which is the first FreeBSD port to anything you can hold against your ear. That’s it. That’s the field.
The interesting question isn’t “why isn’t there a FreeBSD phone?” — the answers there are obvious: no driver pipeline for mobile SoCs, no userland for cellular state machines, no GPU stack worth speaking of until panfrost landed in DRM. The interesting question is “is the gap finally closeable?” Because in 2026 the answer might actually be yes. FreeBSD has Linux KPI shims good enough that the Mali stack runs. The DRM subtree tracks Linux 6.x. SDIO works. Bluetooth has netgraph. The kernel boots arm64 LPAE with multi-cluster scheduling. The pieces are on the table; nobody has put them together for a phone.
That’s the project. Port FreeBSD to two devices: the Pine64 PinePhone Pro (RK3399S, the daily-driver candidate) and the PineTab2 (RK3566, the headless-bringup candidate). Use Honeyguide as the starting point — it boots, it has gadget-mode USB-Ethernet, it has a framebuffer console — and grind through the long tail: WiFi, Bluetooth audio, modem, touch, display, suspend, the modem’s terrible AT command set. Get to a state where I can use this thing as a phone, with all its inputs and outputs alive, on a system whose source tree I can read end-to-end in an afternoon.
The hardware hand
The PinePhone Pro was designed by people who wanted it to be hackable, and it shows in places that matter and in places that hurt. The good news first: every interesting peripheral is a known commercial part with a public datasheet or a Linux driver to reverse-engineer. There’s a UART exposed on the headphone jack — a 3.5 mm jack with a hardware kill switch — that gives you a serial console at 1500000 baud the moment power-on completes. There’s an SPI flash you can reprogram from u-boot. Boot order is software-controllable: SD-first if you flash rk2aw + Megi’s U-Boot. None of this is normal in a 2024-era smartphone.
The bad news is that “every peripheral” includes a Broadcom BCM4345 combo chip that handles WiFi over SDIO and Bluetooth over UART, a Quectel EG25-G modem that talks USB, a Goodix GT917S touchscreen on i2c1, an RT5640 audio codec on i2c0, a Rockchip RK818 PMIC on i2c2, a FUSB302 USB-C controller on i2c3, an ARM Mali-T860 GPU, and a Sony IMX258 camera. Each of those is its own small bring-up project. Each of those has a Linux driver of varying quality that we either need to LinuxKPI-shim or rewrite from the chip-vendor public datasheet (when the datasheet exists, which it doesn’t always).
The PineTab2 trades the RK3399S for an RK3566, a BES2600 WiFi chip we’re not going to touch (use a USB dongle), a BOE TH101MB31IG002-28A panel hanging off MIPI DSI, an RK817 PMIC. Phase 3 territory. Phase 1 and 2 are the phone.
What success looks like
Concretely, the success bar is layered. Tier one: boots, gives a console, does USB-Ethernet so you can SSH it from a laptop. ● working as of essay 4. Tier two: WiFi associates, Bluetooth pairs, audio plays — the laptop-replacement bar. Tier three: cellular calls, SMS, a working on-screen keyboard, touch input, and the modem doesn’t deadlock when you suspend. Tier four: a usable phone with battery life that isn’t embarrassing, where the GPU doesn’t crash under sustained load, and where I can use it for a week without an SSH session open.
We’re past tier one and most of tier two. Bluetooth A2DP is playing music to a speaker. WiFi is loaded but the firmware-handshake hangs at BCDC timeout — needs an SDIO IRQ. Modem hasn’t been tried. Touch attaches in polling mode. The DRM stack is up but drm_atomic_helper.c has a NULL-deref crash that recurs under load. Tier three is the next six months.
What we’re standing on
Honeyguide is the project that made any of this thinkable. Maintained by a single committed person who built FreeBSD 14 images for the PinePhone Pro, contributed back the early DTB and bus-attach work, and put together a build pipeline in setup.sh / patch.sh / dtb-build.sh that takes a stock FreeBSD source tree and overlays the phone-specific bits. The pre-built image at pppfreebsd.honeyguide.net is what you dd to an SD card on day one. Our work sits on top: a src/ overlay and a patches/ directory that get layered onto the Honeyguide base by mise run patch.
Without Honeyguide, this would be a year of bring-up before you saw a login prompt. With Honeyguide, it’s an afternoon to first boot and then the real work begins.
The journey from here
The next three essays walk the boot path. Essay 2 gets you from a downloaded image to a serial console. Essay 3 gets you a kernel built from source on the FreeBSD amd64 build host (ssh honor) — and explains why you have to use clang, not gcc14, and stable/15, not main. Essay 4 wires up USB-Ethernet so you can SSH the phone over the same USB-C cable that’s charging it, which becomes the keystone for everything after.
Then the war stories start. The DWC3 EP0 SETUP infinite loop. The BCM4345 firmware-load BCDC timeout. The Bluetooth HostWake IRQ saga. The HFP audio path. The DRM atomic crash. Each of those is its own essay, written after the bug was caught.
Drop in.