Overview
My phone lab brings together hardware recovery and systems programming. I turn old, sometimes screenless phones and tablets into remotely accessible devices, then use them to explore what useful computation looks like with limited memory, older processors, and imperfect connectivity.
How the pieces fit together
- Devices & Hardware Ports: per-board hardware bring-up pages covering Device Trees, bootloaders, kernel configs, and recovery protocols across 9 ARMv7 and AArch64 targets.
- Phone Revival Lab: recovering devices, booting Linux, bypassing battery/thermistor lockouts, and establishing repeatable remote access.
- Printed holders: organizing bare boards with parametric OpenSCAD trays and ventilated rack designs.
- Fleet Orchestrator: assigning work, collecting results, supervising services, and testing recovery after interruptions.
- armrx: exploring AArch64 execution and performance through a RandomX miner.
- Mergen: distributed C++20/GGML inference runtime splitting 1.1B to 27B language models across multiple phones over USB and Wi-Fi.
These projects share hardware and engineering lessons. Their integration is ongoing: a working node, a validated workload, and a fully unattended deployment are different milestones.
Starting with working nodes
- The Xiaomi Mi 8 (
dipper) boots mainline Linux 7.1.0-rc1 (sdm845) with 6 GB RAM, 128 GB UFS, Samsung EA8074 AMOLED DRM/KMS, Adreno 630 Freedreno GPU, ST FTS5 touch, and WCD9340 + TAS2557 audio. - The Exper Easypad 8 (Model T8E) and Piranha Business II Tab boot mainline Linux 7.2 and 6.6 LTS from MicroSD with Alpine Linux.
- The General Mobile GM8 and Xiaomi Redmi 7A run headless
aarch64Alpine / postmarketOS setups with USB networking, SSH, Wi-Fi, and services that return after reboot. - The Vestel Venus 5.5X provides an ARMv7 Alpine target running entirely in RAM (
initramfs), while the Samsung Galaxy S8 serves as a 1080p60 DeX appliance and the Samsung Galaxy J7 Prime and LG G4 Stylus document screenless recovery and bootloader reverse-engineering.
I document what is verified for each board, including the kernel, boot path, networking, and remaining faults on the Devices page.
Giving the hardware useful work
armrx provides a demanding workload for investigating native code generation and memory tradeoffs. Mergen v1.0 splits modern language models (Qwopus3.5-9B, Qwen3.8-27B, LFM3, Xing4.0) across a 3-phone USB fleet with exact llama.cpp parity and automatic USB fault recovery.
Fleet Orchestrator adds device enrollment, jobs, results, and operational visibility. Its GM8 recovery drills exposed issues involving clock recovery, script isolation, and interrupted jobs. Those findings are part of making a recovered board useful beyond its first successful boot.
A lab with explicit limits
Different devices offer different kernel features and levels of reliability. Some experiments have passed physical-device tests; others still need longer runs or wider hardware coverage. I keep those boundaries visible rather than treating the collection as a finished appliance.
Technologies: Linux, Alpine Linux, postmarketOS, ARM, Rust, C++, OpenSCAD
Project Tags: