ESP32-S3 Runs Linux 6.11 With 3.7MB of RAM to Spare

The Release Where the Board Stops Crashing

Running a real Linux kernel on a microcontroller is a well-worn stunt. Running one that boots reliably fifty-five times in a row, joins WiFi, and leaves you enough RAM to do something afterwards is a different exercise entirely. Version 0.8 of Paulneja's native ESP32-S3 Linux port, published to GitHub on September 14, 2026 and picked up by Hackaday the following morning, is the release that crosses that line. This is Linux 6.11 executing on the chip's own Xtensa LX7 cores — not an emulator, not a remote shell.

• Free RAM after boot: about 3.7MB, up sharply from the previous 0.7 release
• Boot time: roughly 14 seconds from reset to a login prompt
• Hardware: an ESP32-S3 in the N16R8 configuration — 16MB flash, 8MB octal PSRAM
• Install: a single 16MB image flashed to offset zero, containing bootloader, WiFi firmware, kernel, rootfs and an empty home partition

What Was Actually Causing the Crashes?

This is the good part, and it is a properly instructive bug. On version 0.7, roughly one factory boot in ten took a kernel fault within the first few seconds. The suspicion had been memory corruption in the fork backend. It was not.

The ESP32-S3 has a single flash cache shared by both cores. Linux reads the jffs2 filesystem straight through that cache, while writes are handed to core 0 over IPC. Nothing invalidated the cache after a write, so the kernel went on reading stale pages — occasionally stale pages of its own code. The fix is four lines in the firmware.

The more useful lesson is in how it was found. The old test harness counted a silent console as a pass, which is why nobody noticed a 10% failure rate. The new runner reads dmesg and the kernel taint flags back instead of trusting silence. Fifty-five consecutive factory boots came up clean on the fixed firmware. The author is careful to note what that does and does not prove: the corruption that used to appear in one boot of ten is no longer reproducible, which is not the same as a guarantee.

Why fork() Is the Hard Part on a Microcontroller

The ESP32-S3 has no Memory Management Unit, so this is NOMMU Linux, and NOMMU Linux has no fork(). That single missing call rules out a shell pipeline, a parallel make, or a server that accepts a connection — which is to say, most of what makes a Unix system useful.

Version 0.7 added a fork backend built on private software memory banks, at a cost of roughly 552KB per Bash fork. In 0.8, with the flash-cache bug out of the way, the backend's page-set exchange ships properly: N processes now share N−1 page sets, which halves the memory cost of every forking program. Make and the job queue pay nothing at all, because they spawn through vfork instead.

The userspace is genuinely a userspace. Bash 5.2.37 is the login shell with BusyBox behind /bin/sh, alongside GNU Make 4.4.1, MicroPython 1.26.0 with working fork and pipe IPC, socat and nc. Only one of the two cores is available to Linux; the other keeps running the FreeRTOS ESP-IDF stack that provides WiFi and Bluetooth.

How Does This Compare to Other Tiny Linux Boards?

It is a different kind of achievement than the small Linux-capable single board computers we normally cover. Espressif's own ESP32-S31 Linux BSP is a vendor effort on newer silicon with hardware designed to cooperate, and the YuzukiNeko RISC-V board has an MMU. This project is a community port onto a five-year-old microcontroller that was never meant to host a kernel, and it works.

The author frames it as a research project rather than a product, while noting the obvious adjacent use case: a BusyBox-class embedded Linux target — a small router, a logger, a network appliance — on a chip that costs a fraction of what an application processor does. Anyone who wants to try it needs an N16R8 module, esptool, and one flash command. More embedded Linux coverage lives in our mini computers section.

Sources: Hackaday — September 15, 2026; Linux-on-esp32-S3 release 0.8 on GitHub — September 14, 2026.