The previous essay catalogued where we are. This one catalogs where we’re going. Some of these sections are weeks of work; others are months. A couple are pull-requests-from-anyone-with-the-hardware. None of them are speculative — every one has been read into deep enough to know roughly what the shape is.
WiFi: BCM43455 over SDIO — ○ blocked
The hardest open work. The AP6255 module is a Broadcom BCM4345 die exposing WiFi over SDIO and Bluetooth over UART. Bluetooth is solved (essays 9–12). WiFi is not.
We have a complete native bwfm(4) driver ported from OpenBSD. It loads, enumerates the chip (rev 6, rambase 0x198000, ramsize 800 KB), downloads the firmware and NVRAM, and runs the ARM core reset sequence byte-for-byte matching OpenBSD and Linux, with readback verification. None of that is the bug.
The bug: after reset, for 30+ seconds, CHIPCLKCSR = 0x5a (FORCE_HT set, HT_AVAIL never asserts), IOR = 0x02 (fn2 never ready), MBDATA = 0, shared_ptr = 0. The first 16 bytes at rambase are unchanged from what we wrote. The CR4 is unhalted (IOCTL=0x1, RESET_CTL=0x0) but isn’t executing. The loaded reset vector 0xb83ef198 decodes as Thumb2 B.W rambase+0x80 (real branch) or ARM stmltda sp!, ... (LT-conditional, skipped on cold reset). Current best guess: the AP6255 needs an explicit Thumb-mode enable written before unhalt. OpenBSD and Linux don’t do that on other BCM boards, suggesting a chip-ROM default this module doesn’t share.
Next debug attempts: byte-compare our NVRAM against Linux brcmfmac’s converted output; read CR4 debug regs (DSCR, DCR, WFAR) via the AI backplane to see actual PC; check SICF/SICTRL wrapper regs for a Thumb-enable bit; try the alternate brcmfmac43455-sdio-pine64,pinephonepro.txt NVRAM. In the meantime, a USB Ralink RT5370 dongle via run(4) is the daily-use workaround.
Modem: Quectel EG25-G — ▸ next
Mostly upstream of us. The hard part — USB enumeration — was solved as a side effect of the DWC3 / USB2PHY / VBUS-regulator work (essays 4 and 5). The modem appears as multi-interface USB CDC once kill switch #1 is on. AT commands work over /dev/cuaU*.
What’s missing: GPIO power sequencing as an rc.d script (currently manual gpioctl); a nano-to-micro SIM adapter (mechanical, $1); APN setup and ECM mode (AT+QCFG="usbnet",1) for a cdce(4) interface; a ModemManager-equivalent — sxmo’s shell scripts (sxmo_modemcall.sh, sxmo_modemsms.sh) are portable with minor changes. Estimated effort once the adapter is in hand: a week for cellular data, a week for SMS, a couple weeks for a usable call UI. All userspace.
Sensors — ▸ next
All on I2C, all have datasheets, each is a small driver:
- Accelerometer (MPU-6500, addr 0xd0). Standard InvenSense part with a Linux driver to crib from.
- Proximity (STK3311). Used to blank the screen when held to the face. Trivial; real impact.
- Magnetometer (AK09911 / AF8133J). Compass.
- Volume buttons (SARADC). Rockchip SARADC driver exists; needs a small evdev shim that emits
KEY_VOLUMEUP/KEY_VOLUMEDOWN.
A weekend each. Sequencing is “whoever wants the feature most, builds it next.”
PineTab2 (RK3566) — · not started
Phase 3. Different SoC (RK3566), different WiFi (BES2600 — use a USB dongle), different panel (BOE TH101MB31IG002-28A MIPI DSI). Headless bringup first: USB-C serial, kernel boot, USB networking. Then panel, touch, battery. The Quartz64 community has a reasonable RK3566 base in FreeBSD ports — we start there. Phone work is reusable for bus / clock / power / GPIO infrastructure; chip-specific clock tables and DT diffs are the bulk of the port.
On-device audio — ○ blocked
Continued from essay 13. Current theory: the PCM vchan mixer isn’t delivering bytes to the hardware play buffer. Next session opens with prints in sys/dev/sound/pcm/vchan.c, a comparison against snd_hda, and a bypass-vchan-entirely test. Best estimate: a week of focused work once we sit down to read the PCM framework end to end. Could be a one-line format mismatch.
GPU under heavy load — ◐ partial
The four panfrost reset patches (essay 8) fixed the “any timeout freezes” class. Sustained heavy load can still wedge the chip rarely. Probably an MMU page-table race or a two-overlapping-timeouts scheduler corner. GPU-vendor-grade debugging — days of bisection per repro.
Smaller follow-ups
- Upstream the CRU selective write filter — replace our allowlist with
CLK_IS_CRITICALindev/clk/. - fusb302 USB-C controller driver — for PD fast charging, orientation, USB3 superspeed.
- Upstream virtual_oss path-buffer patches to FreeBSD ports
audio/virtual_oss. - Upstream
ng_h4frameto FreeBSD’s netgraph tree. - Replace
bt_a2dp.sh’s sleep-and-grep polling with an event-driven C tool over the raw HCI socket. - rk_tsadc calibration — currently disabled because of false shutdown-level alarms.
What we want from anyone reading this
The PinePhone Pro is the most porting-friendly phone in existence. Hardware kill switches let you debug WiFi without the radio on. Serial console is a 3.5 mm jack. U-Boot is open. SPI flash is reprogrammable. Every interesting peripheral has a public datasheet or a Linux driver to reverse-engineer. If you have the phone, an SD card, and a FreeBSD machine to cross-build on, you can be running the kernel from this tree by lunchtime tomorrow.
The work that’s left isn’t waiting for hardware vendors or firmware blobs (with the partial exception of BCM4345C0.hcd, and even there the right blob is freely distributable). It’s waiting for engineers willing to read source code and write drivers. WiFi, modem call control, sensors, the PineTab2 — every one is a contained project with a clear scope. None require all of the rest to be done first.