I saw this one on Hackaday and had to read it twice. Someone got mainline-ish Linux, kernel 6.11, booting on an ESP32-S3. Not a Linux-capable SoC with a beefy Cortex-A core hiding in there. An actual ESP32-S3, the same Xtensa LX7 chip you’d normally throw FreeRTOS or Arduino code at.

The project, built by a developer going by Paulneja and covered by Hackaday, boots Linux on a chip that has no Memory Management Unit. That’s the part that made me sit up. Linux without an MMU isn’t new, the NOMMU config has existed for embedded ARM chips for years, but getting it to boot reliably on an ESP32-S3 with a custom fork() implementation is a different kind of stubborn.

What it actually does

The ESP32-S3 has twin Xtensa LX7 cores at 240 MHz and up to 16 MB of PSRAM. That’s genuinely enough horsepower to run a stripped-down Linux, at least on paper. The problem is that Linux, like basically every modern OS, assumes it has an MMU to give each process its own virtual address space. No MMU means no fork-and-copy-on-write, no proper process isolation, none of that. So the project uses NOMMU Linux, which handles memory very differently, plus a homemade fork() that works around the missing hardware feature.

The earlier 0.7 release of this project sort of worked but wasn’t reliable. Version 0.8 is the one that actually boots consistently and leaves you with about 3.7 MB of usable RAM afterward, which, compared to the earlier build, is described as a “massive” improvement in both stability and available resources. Only one of the two CPU cores runs Linux; the other stays on FreeRTOS via ESP-IDF to keep WiFi and Bluetooth working, since those stacks are tightly coupled to Espressif’s RTOS.

The hardware used was an N16R8 variant: 16 MB flash (doing double duty as writable storage) and 8 MB of octal PSRAM. Paulneja is upfront that this is a research project rather than a shipping product, though the obvious application people are already floating in the comments is something like a tiny embedded Linux router running BusyBox.

My take

This is a great case of “because it’s there” engineering, and I mean that as a compliment. Getting Linux to boot on hardware never meant to run it is a rite of passage for a certain kind of hacker, and the technical constraints here are real, no MMU is not a small obstacle, it’s the kind of thing that changes how you think about the whole memory model.

What I find clever: reusing the existing NOMMU infrastructure instead of trying to reinvent memory management from scratch. That’s the pragmatic move. A lot of hobby OS ports try to do too much themselves and end up fighting years of kernel assumptions. Building on NOMMU means you inherit decades of Linux compatibility work instead of reinventing it.

What’s questionable, at least from a “would I ship this” standpoint: 3.7 MB of usable RAM after boot is extremely tight. You can run something small, a shell, maybe a lightweight web server, definitely BusyBox, but you’re nowhere near running a real application stack. And single-core Linux with the other core locked to WiFi/Bluetooth duty means you’re not getting much parallelism even for the tasks Linux can theoretically help with. I’d call this a proof that it’s possible more than a foundation you’d want to build a product on today.

The alternative nobody’s arguing against: just use an SoC that already has an MMU

If your actual goal is “small embedded Linux device,” there are chips built for exactly that, an ESP32 paired with an external Linux-capable SoC, or something like an Allwinner or Rockchip part with a real MMU and mainline kernel support. You’d get proper process isolation, way more headroom, and none of the NOMMU workarounds. The tradeoff is cost and board complexity: you’re now designing around two processors instead of one, and you lose the single-chip simplicity that makes the ESP32 series so appealing in the first place.

The NOMMU-on-ESP32-S3 approach only makes sense if you specifically want Linux userland tools on a board you’ve already committed to for other reasons, WiFi stack, existing PCB, existing supply chain relationship, and you’re willing to live inside a very small memory box to get there. For most embedded router or gateway projects I’d reach for a purpose-built Linux SoC. But I get why someone did this anyway. Sometimes the point isn’t the destination, it’s proving the door was never actually locked.

Full writeup and comment thread worth reading over at Hackaday.