Runs everywhere
From the 5-euro chip to the server: anything with a CPU, some memory and a storage medium should be able to run NULLos.
| What | Examples | Memory | MMU |
| Microcontrollers | ESP32, ESP32-C3/C6, RP2040 | 320–520 KB | no |
| Single-board computers | Raspberry Pi 3/4/5, RISC-V boards | 512 MB – 8 GB | yes |
| Phones, tablets | unlocked Android devices (ARM64) | 2–16 GB | yes |
| PCs, laptops, servers | anything with UEFI | from 64 MB | yes |
| Old PCs | BIOS machines | from 16 MB | yes |
The order
x86_64 (QEMU, then real PC) → ESP32-C5 (RISC-V, no MMU) → ARM64 (QEMU, Raspberry Pi) →
RISC-V 64 → Xtensa (ESP32). Running in QEMU today: x86_64, ARM64 (also as a guest in Apple's virtualization on the Mac), RISC-V 64 and the Raspberry Pi 4 up to the prompt. Real devices, ESP32 and Xtensa: coming soon
The compiler is already further along: it generates code for x86_64, ARM64 and RISC-V 64, tested in QEMU.
The hardware plan
| Device | Priority | What's still missing |
| Guest on Max's MacBook (Apple M5) | 1 | boots to the shell (QEMU and Apple guest) – missing: one last test failure, keyboard layout |
| Real PCs and laptops | 1 | USB, NVMe, network cards (e1000e, igb, USB Ethernet), sound and power-off via ACPI work in QEMU – missing: trying it on the device |
| Raspberry Pi 4/5 | 2 | Pi 4 in QEMU up to the prompt (own loader, device tree) – missing: multiple cores, real Pi, Pi 5 |
| RISC-V 64, ESP32-C5 | 2 | RISC-V 64 in QEMU done (4 CPUs, network, all tools) – ESP32: no MMU, coming soon |
| Intel Macs, phones | 3 | Phones: plan is ready, device still open |
| Apple Silicon directly | 4 | no UEFI, Apple's own hardware |
Principle: everything built ourselves from the specifications – Asahi, Linux & co. only read, never copied.
Plan with work packages H1–H15. Status Oct 30 in the morning, everything in QEMU, real devices still unchecked: done are USB (H2), NVMe (H3), virtio 1.x including the Apple guest (H4), network cards (H5), Mac keyboards (H7), RISC-V (H9), sound (H11) and USB device approval (H15); partly ARM64 (H1), ACPI (H6), Raspberry Pi 4 (H8) and mouse/tablet/touchpad (H12). Planned: phone (H10), IOMMU against foreign DMA (H13), CPU bugs and side channels (H14). Wi-Fi needs vendor firmware and is therefore left out for now. coming soon
First small device: ESP32-C5
Max's idea: NULLos on an ESP32-C5 – and you only get onto it via SSH. The chip: one RISC-V core
up to 240 MHz, 384 KB SRAM, Wi-Fi on 2.4 and 5 GHz, no MMU. Tip: buy a board with PSRAM, otherwise it gets tight.
The path: compile → flash over USB → own startup code → prompt over USB → kernel without MMU →
network → TCP/IP and SSH server → operate only via SSH. The plan is ready, nothing has been started yet.
coming soon
Open question: Wi-Fi. The radio part isn't openly documented, it would only work with Espressif's closed
library. Suggestion: start with an SPI Ethernet module (e.g. W5500) – then everything stays self-written.
Max decides.
How it's supposed to work
- A thin machine layer. Everything CPU-specific lives in its own layer, everything board-specific in a second one,
the rest is plain C.
- Even without an MMU. The ESP32 has no virtual memory – so the kernel can do both.
Programs are position-independent.
- Tiny. Goal for the smallest kernel with shell: under 64 KB of code, under 32 KB of RAM.
Everything can be switched off at build time.
- All in one file when it gets tight. On microcontrollers all tools are linked into one
program (like BusyBox).
- Measure, don't guess. Boot time, free memory, context switches – every session measures its part.
- Flash-proof. Our own file system should even out wear and survive power failures.