Every generation of ESP32 has prompted someone to ask whether it can run Linux, and the answer has always been no — not because the chips were slow, but because they lacked the memory-management hardware an operating system needs.
The ESP32-S31 changes that, and Adam Conway’s write-up at XDA Developers, picked up by Adafruit, puts the reason in the right place: it’s in the data sheet, not the benchmark.
The spec sheet
- Two 32-bit RISC-V cores at up to 320 MHz, plus a 40 MHz low-power core
- Gigabit Ethernet MAC over RGMII
- USB 2.0 High-Speed OTG controller
- Two SDIO slots
- Camera input
- Parallel LCD controller
Impressive, and none of it is why Linux boots.
The part that matters
The cores implement:
- Sv32 two-level page-table address translation
- Machine, supervisor and user privilege modes
That is the definition of a RISC-V machine capable of running Linux. Page-table translation gives you a memory management unit — virtual addresses, per-process address spaces, memory protection. Privilege modes give you the separation between kernel and userspace that an OS is built on.
Without those, you can run an RTOS — FreeRTOS, Zephyr, bare metal — where everything shares one flat address space and any task can scribble on any other. That’s what every previous ESP32 did, and it’s genuinely fine for most embedded work. What it can’t do is run a general-purpose OS, because Linux fundamentally assumes an MMU.
Espressif published a Linux BSP in August, built on Buildroot and U-Boot, with a kernel and device tree. So this isn’t a community heroics project — the vendor shipped the board support package.
What it means for creative hardware, honestly
The Adafruit headline calls it “uncomfortably close to a Raspberry Pi,” and the useful thing is to be precise about where that’s true and where it isn’t.
Where it genuinely helps: a piece that needs one Linux-shaped capability and otherwise belongs on a microcontroller. Real filesystems with real libraries. A proper network stack with TLS that you didn’t have to hand-roll. Python, or anything else that expects an OS. Standard Linux drivers for peripherals. Gigabit Ethernet and USB High-Speed on the same die is a genuinely useful combination for an installation node that has to move data.
Where the Pi still wins: RAM, storage, GPU, video output, and an enormous software ecosystem that assumes all of those. This is not going to drive a 4K projector or run TouchDesigner.
The real advantage is the boundary it erases. The current decision — microcontroller or single-board computer — forces an architectural commitment early, and the cost of getting it wrong is a rewrite. A part that boots Linux and has the power profile, boot time and deterministic peripherals of a microcontroller makes that decision less consequential. For battery or always-on installation work, instant boot and low idle draw have always been the reasons to choose a microcontroller and accept the software pain. Getting both is new.
The caution worth keeping: Linux on a part this size means a very constrained Linux. Expect to care about kernel configuration, and expect Buildroot rather than apt.