PlanarOS: A Slim, Comprehensible Operating System for Single-Board Computers

For the last several months, alongside my work on local genomics tooling and systems languages, I have been bringing up a new operating system from scratch. It is called PlanarOS, and while it is still in its early development phases, the core kernel, single-address-space memory subsystem, SMP scheduler, and zero-copy inter-process communication (IPC) are now booting and passing conformance suites on QEMU (riscv64 and aarch64) and on real RISC-V silicon.

The goal of PlanarOS is simple to state and ruthless in what it leaves out: turn a modern 64-bit Single-Board Computer (SBC) into a machine that feels as direct, responsive, and comprehensible as a classic Amiga, without giving up hardware fault isolation.

This post introduces what PlanarOS is, why modern SBCs are begging for a lighter software stack—especially during the current AI-driven RAM crunch—who it is built for, where its security boundaries lie on the modern internet, and how you can get involved.

What Is a Single-Board Computer (SBC)?

If you have ever worked with a Raspberry Pi, an Orange Pi 5 Plus, or a StarFive VisionFive 2, you already know the form factor. A Single-Board Computer integrates an entire computer onto a single palm-sized circuit board: a System-on-Chip (SoC) housing multiple 64-bit CPU cores, an integrated GPU, a dedicated Neural Processing Unit (NPU) or vector engine, soldered LPDDR4x/LPDDR5 memory, storage interfaces (SD, eMMC, NVMe over PCIe), Ethernet, USB, and low-level GPIO/I²C/SPI headers.

What makes the current generation of 64-bit SBCs fascinating is how genuinely capable the silicon has become while drawing only 5 to 20 watts at the wall. PlanarOS is being designed and measured against four representative boards right on my workbench:

Board	SoC	CPU Cores	ISA	GPU	NPU / Accelerator
Orange Pi RV2	SpacemiT K1	8× X60 @ 1.6 GHz	RV64GCV (RVA22, RVV 1.0)	IMG BXE-2-32	In-core AI extensions (Cluster 0)
Orange Pi 5 Plus	Rockchip RK3588	4× A76 + 4× A55	Armv8.2-A	Mali-G610 (Valhall CSF)	3× RKNN cores (6 TOPS)
Orange Pi 6 Plus	CIX P1 (CD8180)	8× A720 + 4× A520	Armv9.2-A (SVE2)	Immortalis-G720 MC10	Zhouyi X2 (30 TOPS)
Radxa Dragon Q8B	Qualcomm SC8280XP	4× X1C + 4× A78C	Armv8.2-A	Adreno 690	Hexagon v68 HTP

On paper, these boards are heterogeneous compute powerhouses. Eight to twelve 64-bit cores, 256-bit RISC-V vector units or Arm SVE2, command-stream GPUs, and dedicated neural accelerators should make them fly.

Yet if you boot a standard desktop Linux distribution on one, the machine rarely feels fast. And when you try to run serious workloads—whether bioinformatics pipelines or local edge inference—you hit a wall much sooner than the hardware specs suggest you should.

Doing More with Less in the Era of the AI RAM Shortage

We are living through a strange hardware moment. The explosion of AI data centers and high-bandwidth memory demand has created a persistent RAM shortage and pricing squeeze. Memory manufacturers have shifted wafer capacity toward HBM and high-margin server DRAM, driving up the cost of LPDDR4x and LPDDR5 on consumer and embedded boards. A 16 GB or 32 GB SBC now carries a steep premium, which pushes hobbyists, embedded builders, and indie developers back toward 2 GB, 4 GB, and 8 GB boards. On these machines—especially where CPU, GPU, and NPU all carve their buffers out of the same unified physical DRAM—every megabyte of RAM and every memory-bus cycle is precious.

Meanwhile, our mainstream operating systems were designed under the assumption that RAM and CPU cycles are effectively free. Boot a typical Linux image on an SBC and look at what happens before your application executes a single instruction:

Per-process virtual address translation and TLB churn. Every process gets its own virtual address space. Passing data from a network or storage daemon to an application, or from an application to a display compositor or accelerator driver, means translating addresses, maintaining deep per-process page tables, and copying or remapping buffers across boundaries.
Kernel-mediated IPC and syscall taxes. Even when two processes sit on adjacent cores of the same SoC, talking over sockets or pipes requires trapping into supervisor mode, copying payloads into kernel buffers, running scheduler logic, and copying them back out into the receiver’s address space.
Middleman layers in front of GPUs and NPUs. Modern GPUs (like Arm’s Valhall/Immortalis Command Stream Frontend) and NPUs are designed around ring buffers and doorbells. Yet a traditional stack routes every submission through massive userspace runtimes, kernel ioctl validation, buffer-object managers, and kernel-side command schedulers.
Background sprawl. Swap daemons, overcommit heuristics, complex service managers, multi-tenant security hooks, and sprawling runtimes quietly eat hundreds of megabytes to gigabytes of RAM just sitting at idle.

PlanarOS attacks all four bottlenecks at the architectural root:

1. One Address Space, Universal Pointers, and Hardware Protection

In PlanarOS, every process shares a single 64-bit address space. A pointer means the exact same thing in every process, in every server, in the kernel, and—wherever the hardware allows—to every DMA-capable device on the board.

Sharing a 64 MiB tensor, an audio buffer, or a framebuffer between two programs does not involve serializing it, copying it through a pipe, or remapping virtual addresses. You pass the 64-bit pointer.

Crucially, sharing an address space does not mean giving up memory protection. PlanarOS separates protection from translation. Every process runs inside its own hardware protection domain (backed by ASID-tagged Sv39/VMSAv8-64 page tables on MMU systems, or physical memory protection regions on PMP/MPU targets). A process can only read or write the memory Areas explicitly granted to its domain. A context switch is a single satp or TTBR0_EL1 register write with no cache flush.

Right now in Phase V1/V2, we are running head-to-head hardware benchmarks (VQ3) comparing an identity-mapped layout (VA = PA, where every user pointer is already a physical DMA address) against a global virtual allocator on the 8-core Orange Pi RV2. On an 8 GiB RV2 under heavy allocation pressure, the identity layout uses ~8% fewer page-table pages while keeping physical pointers zero-translation for DMA. Every architectural decision in PlanarOS is settled this way: write the probe, run it on the board, and read the serial console numbers.

2. Exec-Style Zero-Copy IPC

If you ever programmed the Amiga, PlanarOS’s IPC will feel like coming home. Inspired by Carl Sassenrath’s exec.library, programs communicate through named Ports, Connections, and Messages (PutMsg, GetMsg, ReplyMsg, WaitPort, DoMsg) that travel by reference.

When a client opens a connection to a server (OpenPort), the kernel allocates a shared ConnArena mapped read-write into just those two protection domains, containing lockless single-producer, single-consumer (SPSC) request and reply rings.

Streaming path (zero traps): As long as the receiving server is awake and draining its ring, the client writes message pointers into the ring in user space with release/acquire atomics. The kernel is never entered. In our V2 conformance runs streaming 20,000 messages across 4 cores, the system averages fewer than 30 kernel calls per 1,000 messages—trapping only on the 0 → 1 edge when a ring runs completely dry and a sleeping peer needs a wakeup signal.
Synchronous path (DoMsg): When a client sends a request and immediately waits for the reply, PlanarOS performs direct handoff scheduling, lending the client’s priority and handing the CPU straight to the server. On the SpacemiT K1’s X60 cores, our target budget for a full protected DoMsg round trip is under 3,400 cycles (~2 microseconds at 1.6 GHz).

3. Queue Leases: Putting the GPU and NPU Straight into the App’s Hands

In the AI boom, an 8 GB board running a local model or vision pipeline cannot afford to bounce megabytes of activations through kernel drivers. PlanarOS treats modern coprocessor firmware as hardware through a single abstraction called the queue lease.

A driver server (gpu-panthor on the RK3588 and CIX P1, or the NPU servers) handles power-on sequencing, loads firmware, and configures the IOMMU/GPU-MMU context to match the application’s memory grants. It then hands the application a lease: a shared command ring, a 64-bit sync sequence object, and a hardware doorbell page mapped directly into user space. From that moment on, the application writes jobs straight into the ring and rings the doorbell itself. Neither the kernel nor the server sits in the data path.

4. Determinism and a 10–15k Line Kernel

PlanarOS has no demand paging, no memory overcommit, and no swap. When you call AllocArea, physical pages are committed immediately; when a process exits, every handle, memory Area, in-flight message, and hardware lease it owned is reclaimed deterministically. The entire portable kernel targets 10,000 to 15,000 lines of C23 across roughly 40 system calls. Almost every megabyte of DRAM on the board belongs to your code and your data.

Built for Hackers, Makers, and Indie Developers

Modern operating systems have grown so large that no single human being can understand the path from a button press to a pixel on screen. Linux is an extraordinary engineering achievement, but when a maker wants to write a low-latency driver for a custom sensor array, or an indie developer wants to build a dedicated synth, cyberdeck, retro-inspired workstation, or local AI appliance, they are forced to fight millions of lines of kernel abstractions and userland plumbing.

PlanarOS is built around the premise that one person should be able to hold the entire system in their head.

C23 Without the `#ifdef` Maze

The entire system—kernel, boot stubs, libraries, drivers, and servers—is written in freestanding C23 plus small .S assembly files. Why C23 instead of Rust, C++26, or Odin? Because in an OS built on universal pointers, lockless shared-memory rings, and zero-copy DMA arenas, a borrow checker fights the core architecture on every line, forcing almost the entire IPC and driver surface into unsafe blocks anyway. C23 gives us modern ergonomics (constexpr, nullptr, typeof, fixed-width enums, <stdckdint.h>, [[nodiscard]], #embed) while keeping a 1:1 mental map between a line of source code and the emitted RISC-V or Arm64 instructions.

Portability comes from directory structure, never preprocessor soup:

Portable code lives in kernel/, lib/, servers/, and drivers/, and exists once.
ISA specifics live in arch/rv64/ and arch/aarch64/.
SoC specifics live in plat/ky-x1/, plat/rk3588/, plat/cix-p1/, and plat/sc8280xp/.
Zero #ifdefs on architecture or platform are permitted in portable code—enforced automatically by make check.

Public libraries use clean AmigaOS-style interface tables (IExec->PutMsg(), IDos->Open()), and every milestone ships alongside Planar’s own version of the Amiga ROM Kernel Reference Manuals (manuals/): complete with Library guides, Device specs, and function-by-function Autodocs that are checked in lockstep with the code.

User-Mode Drivers and “Let It Crash” Fault Tolerance

For a hardware hacker or maker, the worst part of writing kernel drivers on traditional embedded Linux is that one bad pointer dereference panics the kernel and forces a power cycle.

In PlanarOS, device drivers, filesystems, display servers, and network stacks all run in user mode, each inside its own hardware protection domain. We combine our single-address-space hardware domains with an Erlang-style “Let It Crash” supervision model:

If your experimental SPI, NVMe, or GPU driver hits a null pointer or corrupts an internal structure, it faults into process_fault and calls ExitProcess.
The kernel immediately masks the device’s IRQs, closes its client connections with ERR_PORT_DIED, quarantines its DMA memory Areas until the hardware stop/reset method runs, and reclaims its domain.
The hardware database supervisor (hwdb) logs the crash address and PC to the serial console and spawns a fresh copy of the driver in milliseconds.

You can develop, crash, edit, and restart real hardware drivers on a live board without ever taking down the core system.

A Natural Home for Indie Games and the Demoscene

There is another reason the Amiga still holds such a legendary place in computing history: games and the demoscene. When you know the exact cycle cost of a message, when nothing swaps behind your back, and when you can talk directly to the display and graphics hardware without seven layers of compositor and driver middleware, a machine becomes a joy to push to its limits.

PlanarOS brings that exact ethos to modern 64-bit RISC-V and Arm SBCs:

Cycle-predictable frame budgets: With a tickless kernel, direct user-mode cycle/time counter reads (rdtime on RISC-V, CNTVCT_EL0 on Arm64), no demand paging, and no background daemon jitter, a 16.6 ms (60 Hz) or 8.3 ms (120 Hz) frame budget actually belongs to your code from first scanline to last.
Direct hardware scanout, planes, and vblank flips: Rather than forcing every pixel through a bloated desktop window manager, the PlanarOS display server exposes hardware display controllers (the SpacemiT K1 DPU, Rockchip VOP2, CIX Linlon, and Qualcomm MDSS) directly as screens, hardware overlay planes, and sprite planes synchronized to vertical blank—already proven in our early RV2 bring-up from Omega.
Bare-metal GPU rings and full vector/SIMD: Through queue leases, a game engine or 64k intro writes command packets straight into the GPU’s ring buffer and rings the hardware doorbell with zero syscall overhead, while user-space code gets unrestricted access to 256-bit RISC-V Vector (RVV 1.0), Arm NEON, and SVE2 instructions (with the kernel compiled scalar-only so it never dirties vector registers).
Modern “Copper and Blitter” possibilities: On an 8- or 12-core SBC, you can even dedicate an entire CPU hart as a software-driven Copper or blitter provider behind the standard queue-lease API—chasing the raster or streaming procedural geometry and audio across zero-copy shared arenas at hardware speeds.

Whether you want to build a dedicated retro-modern fantasy console, code a real-time shader and vector demo on a $60 RISC-V board, or write a tight 2D/3D indie game that boots to title screen in a fraction of a second, PlanarOS gives you the whole machine.

The Security Model: Threats on the Modern Internet and Best Practices

Every honest systems design has to state what it is not trying to be. PlanarOS’s very first architectural principle is P1: One user, no adversary model.

On a classic personal computer, the machine belonged to the person sitting in front of it. PlanarOS adopts that same stance: hardware protection domains exist to contain bugs and crashes, not to defend against a hostile multi-tenant adversary.

Specifically, you should know what PlanarOS omits by design:

No multi-user logins or privilege tiers in user space—the owner of the board owns the machine.
No ASLR (Address Space Layout Randomization) or stack canaries. When every process shares a single address space so pointers can be passed directly in messages, memory layouts are intentionally visible and deterministic (W^X write-xor-execute is enforced by default, with explicit opt-out).
No browser-grade sandboxes. Modern web engines (Chromium, Firefox, WebKit) are multi-million-line operating systems of their own that demand full POSIX semantics, Linux-style GPU stacks, and deep process sandboxing to safely execute untrusted JavaScript from strangers. None of those are design goals for PlanarOS.
Trusted DMA on boards without full IOMMUs. On SoCs like the RK3588 and CIX P1, PlanarOS programs the IOMMU/SMMUv3 with identity mappings to confine device DMA to a lease holder’s memory grants. On boards where blocks lack an IOMMU (such as the SpacemiT K1 display unit) or where a vendor hypervisor locks down the SMMU (such as the Qualcomm SC8280XP), drivers run with unconfined DMA.

Best Practices When Connecting PlanarOS to the Network

When you connect a single-address-space, no-ASLR machine to the modern internet, the threat model changes from “a buggy driver” to “active remote exploitation.” An unpatched buffer overflow in a network-facing parser on a system without ASLR or sandboxing gives a remote attacker a predictable memory map.

If you are building networked appliances, homelab nodes, or edge compute boxes with PlanarOS, follow these best practices:

Never expose a PlanarOS board directly to the public internet. Do not put a PlanarOS node in a router DMZ or forward public ports straight to it. Keep it behind a trusted local network (LAN), a hardware firewall, or an authenticated tunnel (such as a WireGuard gateway on your router).
Use outbound client connections or a reverse proxy. When the net server lands on the roadmap, its sweet spot is deterministic local-network communication and curl-class outbound HTTPS requests to endpoints you control or trust—pulling jobs, publishing telemetry, or talking to a local API server. If you need to reach a PlanarOS service from outside your home or lab, terminate TLS and authentication on a hardened reverse proxy first.
Isolate untrusted parsing in dedicated worker domains. Even though PlanarOS does not hide address layouts, its hardware protection domains still enforce strict read/write/execute grants per process. Keep parsers that handle external wire data in minimal, short-lived worker processes that map only the input buffer Area and a single connection ring—never granting them device leases or broad memory Areas.
Treat it like an instrument, not a general-purpose web desktop. Use PlanarOS for what it excels at: dedicated compute nodes, indie games and demoscene productions, robotics, hardware workbenches, local AI/NPU runners, custom human-machine interfaces, and distraction-free systems programming.

Where PlanarOS Stands Today—and How to Contribute

PlanarOS is young, moving fast, and built out in the open. Every phase on the roadmap is gated by automated serial-transcript conformance tests (make test-all) that must pass on both QEMU and real hardware, backed by mutation testing to prove the tests actually catch bugs.

Here is where we are right now:

V0 (Tree & Early Boot) — Done: Unified build tree (llvm@22), portable no-#ifdef enforcement, FDT parser, early serial console, and EL2 → EL1 drop booting cleanly on qemu-virt-rv64, qemu-virt-a64, and hosted.
V1 (Single-Address-Space Core & SMP) — Done: Zoned physical memory manager, both identity and global-VA protection domain back ends, tasks, multi-core SMP scheduler with per-CPU run queues, signals, and system-wide generation handles booting across all 8 harts on the Orange Pi RV2.
V2 (Exec-Style Zero-Copy IPC) — Done: Named ports, per-connection shared arenas, lockless SPSC rings with the waiting protocol, zero-trap streaming, DoMsg handoff scheduling with priority boosting, and bilateral peer-death notices (ERR_PORT_DIED), verified across 250+ multi-architecture soak boots.
Up Next (V3 & V4): Bringing up our first Armv9 board (Orange Pi 6 Plus / CIX P1) via UEFI and ACPI, settling the VQ3 memory-layout decision with cross-architecture TLB and fragmentation data, and building out hwdb, power, block storage (sdhci/nvme), FAT32, and framebuffer scanout.

How You Can Get Involved

Because PlanarOS is intentionally small and documented to the metal, you do not need six months of ramp-up time to understand the codebase—you can read the entire design spec and kernel in an afternoon.

Read the Design Docs and Open Questions: The docs/ directory lays out the entire architecture—from memory protection and IPC rings to queue leases and Erlang-style driver supervision. Open engineering trade-offs are tracked as numbered questions (VQ1–VQ30) in docs/questions.md.
Boot It in QEMU in Two Minutes: If you have macOS or Linux with Homebrew llvm@22 and QEMU installed, cloning the repo and running make test-all will build and boot PlanarOS on both 64-bit RISC-V and Arm64 virtual machines right in your terminal.
Run Hardware Probes on Target SBCs: If you have an Orange Pi RV2, Orange Pi 5 Plus (RK3588), Orange Pi 6 Plus (CIX P1), Radxa Dragon Q8B, or a SpacemiT K3 board on your desk with a UART serial cable, hardware measurements, ACPI/DTB dumps, and board-quirk reports are gold.
Help Build Servers, Drivers, and Manuals: As V4 and V5 open up, there is plenty of greenfield C23 work in user-mode drivers (NVMe, xHCI/USB HID, RTL8125 Ethernet, display planes, Mali CSF / NPU queue providers) and in expanding the ROM Kernel-style reference manuals.

Check out the repository on GitHub at github.com/JamesKane/PlanarOS, open an issue or discussion on any of the VQ design questions, or reach out on Bluesky (@jameskane.blog). Let’s build an operating system we can actually hold in our heads again.