Build a custom PinePhone firmware from the kernel up

An embedded developer used Claude Code for nine days and 744 commits to build a fast PinePhone firmware with calls, SMS, maps and Doom, plus 72 new kernel and LVGL patches.

Done withClaude Code· Nov 10, 2026

What they did

The poster, who works in embedded, had a PinePhone sitting unused because its apps were slow. Treating it as an embedded device, they worked with Claude Code, mostly on Opus 5.5 and later Fable 5.2 for hard bugs such as VoLTE, to build a firmware: a single LVGL program on Buildroot and a mainline kernel, with calls, SMS, contacts, notes, music, camera, an ePub reader, maps, a Telegram client, Doom and a Genesis emulator written from scratch. The loop was profile on the phone, form a guess, patch, rebuild, flash and measure. Claude was allowed to build and flash by itself because updates are A/B and roll back on a failed boot, and a headless suite of 1,892 UI tests with faked hardware ran on the PC first. A long CLAUDE.md carried what each session learned.

How it went

Most screens run at the display's full 66 FPS. The project carries 81 patches, 72 written for it, 46 of them in Linux (USB-C, cameras, charging, waking from sleep on a call) and 23 in LVGL's GPU renderer. In comments the poster put it at 9 days, 744 commits, 187 sessions, about 5 billion tokens and an estimated $1,750 of API usage, on a Max plan. Early on the agent tapped through menus blind and overwrote their Genesis saves, and RAM overclocking tests hung the phone until rollback saved it.

Worth knowing

The poster reviewed every change by hand and tested it on the device. Two rules made agent flashing safe: automatic A/B rollback, and a failing test written before every fix. After the save-file accident the agent takes a screenshot after every tap. A commenter asked how such a large firmware will be kept up to date.

Try it

With Claude Code· 6 parts to fill in

Help me build and tune firmware for [device] on [Buildroot or my build system] with [UI toolkit]. Before touching the device, run the headless test suite in [tests folder] and add a failing test for each bug before you fix it. For performance work, profile on the device, state a hypothesis, patch, rebuild and measure again. You may flash only to the inactive A/B slot, and take a screenshot after every UI action. Record why each patch exists in [notes file]. Stop and ask me before any change to [bootloader, modem or other risky part].

Square brackets are the parts to fill in. The prompt is ours; the story is theirs.

Where they said it

Related