The first thirteen essays are war stories. This one is the table of contents to those wars, in the present tense. If you opened the project today and asked “what’s actually running,” this is the answer. Nothing in this essay is new work — every claim links back to the essay where it was earned.
Overall
Working: boot, build pipeline, USB networking, DWC3 gadget, touchscreen, MIPI DSI display, GPU at light/medium load, full Bluetooth pairing + AES-CCM encryption, A2DP audio out to a speaker.
Partial / flaky: GPU under sustained heavy load (rare freezes), Bluetooth orchestration script (fragile, sleep-and-grep based), display first-frame flicker on resume.
Blocked: on-device audio (RT5640 + I2S — silence), WiFi (BCM43455 SDIO — firmware loads but the chip’s CR4 won’t execute).
Not started: modem voice/data (Quectel EG25-G — USB enumerates, GPIO power sequencing not done), accelerometer, proximity, magnetometer, volume buttons, camera, suspend/resume, battery management.
By subsystem
Boot — ● working
Honeyguide image plus Megi’s U-Boot 2024.04 plus rk2aw on SPI, SD-first boot. Graphical boot menu on the EFI framebuffer, serial console at 1500000 baud on the headphone jack. From cold power to login prompt: about 30 seconds.
Build pipeline — ● working
Cross-build aarch64 kernels on honor (FreeBSD 15.0-RELEASE amd64). Honeyguide overlay + our src/ overlay + patches/ directory layered by mise run patch. Full buildkernel ≈ 5 minutes; incremental ≈ 18 seconds. Must use stable/15 + clang (not main, not gcc14).
See essay 03 — Building from source.
USB networking — ● working
if_cdce + usb_template_cdce configures the phone as a CDC-Ethernet device on the OTG port. Plug into a laptop, get an IP, SSH in. TX watchdog auto-recovery handles transient stalls. This is the bring-up lifeline — every kernel since has been deployed by ssh honor 'cat kernel' | ssh pinephone 'sudo tee /boot/kernel/kernel'.
See essay 04 — USB-Ethernet up.
DWC3 gadget — ● working
The Synopsys DWC3 USB controller in gadget mode, written largely from the chip programming guide because the in-tree FreeBSD driver was host-mode only. Inline EP0 handling (the usb_template callback timing made the kthread-deferred path too slow for control transfers).
See essay 05 — DWC3 gadget from scratch.
Touchscreen — ● working
Goodix GT917S on i2c1, 720×1440, 5-touch. Initially polling; now interrupt-driven, multitouch in X11 and Wayland. See essay 06.
Display — ● working
Full MIPI DSI pipeline: VOP → DW MIPI DSI → HX8394 panel, 720×1440 at 60 Hz. EFI framebuffer for boot, then DRM/KMS. X11 / Sway / Hyprland all run. Residual: occasional first-frame tearing on resume, intermittent green flash on mode change. See essay 07.
GPU — ◐ partial
Mali-T860 MP4 via Panfrost. OpenGL ES 3.1, GPU-accelerated compositing, glmark2 runs. Four reset-path patches (essay 08) fixed the “any timeout freezes the system” class. Sustained heavy load (Hyprland animations + WebGL benchmarks) still wedges the chip rarely. Hunt continues. See essay 08.
Bluetooth — firmware load — ● working
BCM4345C5 in the AzureWave AP6255 module, HCI over UART2 at 1500000 baud with hardware flow control. From-scratch netgraph H4 framing node (ng_h4frame), patchram uploader, UART RX trigger fix. See essay 09.
Bluetooth — HOST_WAKE — ◐ partial
GPIO HOST_WAKE armed as a real interrupt; pairing flows reliable since. The optional ng_h4frame tickler is still on by default — empirically redundant but not proven safe to disable. See essay 10.
Bluetooth — SSP and Murata — ● working
SSP with Just Works, AES-CCM confirmed (Encryption_Change enabled=0x02). Required swapping the BCM4345C0 patchram from the SC-disabled Raspberry Pi build to a Murata 1MW build. The blob is committed but the build pipeline doesn’t refuse the wrong build. See essay 11.
Bluetooth — A2DP — ● working
mpg123 → /dev/dsp → virtual_oss → SBC → AVDTP → L2CAP → ACL → speaker. Two netgraph patches, one userland patch, one orchestration script. Fragile but plays. See essay 12.
On-device audio — ○ blocked
RT5640 attaches, registers configure, MCLK enabled, BCLK/LRCK on the scope, ISR draining the FIFO. Every word written to the FIFO is zero. PCM vchan mixer is the leading suspect. See essay 13.
WiFi — ○ blocked
Native bwfm(4) driver ported from OpenBSD. SDIO bus methods work, chip enumeration works, firmware downloads and verifies, ARM core reset sequence runs. The BCM43455 CR4 core never starts executing — CHIPCLKCSR shows FORCE_HT set but HT_AVAIL never asserts, MBDATA and shared_ptr stay zero. Likely a chip-internal config specific to the AP6255 module (possibly a Thumb-mode enable). Months of work remaining; structural blocker is that FreeBSD’s mmc(4) doesn’t expose an SDIO-function abstraction the way Linux does.
Modem — · not started
Quectel EG25-G enumerates as USB once kill switch #1 is on (essays 4 and 5 made this possible — VBUS regulators always-on, USB2PHY suspend init, selective CRU write filter). AT commands work over /dev/cuaU*. SIM not detected because we have a nano SIM in a micro SIM slot with no adapter. GPIO power sequencing isn’t scripted yet. Once the SIM is mechanically present and the power-on sequence is automated, cellular data is mostly userspace work.
Sensors — · not started
All on I2C, all unstarted:
- Accelerometer: MPU-6500 at 0xd0 on i2c
- Proximity: STK3311
- Magnetometer: AK09911 / AF8133J
- Volume buttons: SARADC
Mostly straightforward driver work. None of it is on the critical path for “phone you can take a call on.”
Camera — · not started
Sony IMX258 rear, OV8858 front. No drivers. Phase 4+.
PineTab2 (RK3566) — · not started
Phase 3 of the project. Quartz64 RK3566 foundation needs to come up first (headless, USB serial console). Then BES2600 WiFi (skip — use a USB dongle). Then BOE TH101MB31IG002-28A MIPI DSI panel, touchscreen, RK817 PMIC, battery.
What changed since the start of the year
Six months ago this project had a Honeyguide image that booted to a login prompt and USB-Ethernet that mostly worked. Today it has GPU-accelerated Hyprland on the panel, touch-driven Wayland, A2DP music playback to a Bluetooth speaker, and a kernel tree we can rebuild and redeploy in under a minute. That’s tier-one (essay 1’s framing) and most of tier-two. Tier three — calls, SMS, on-device audio — is the next arc.
The honest balance: the things that work, work reasonably well. The things that don’t work, don’t work for understood reasons we haven’t fixed yet. There are no “we have no idea what’s going on” subsystems left, with one exception: why the BCM43455 CR4 won’t execute its loaded firmware. Everything else is a concrete next step away from green.