ESP32-S31: new Espressif microcontroller runs Linux with a real MMU

Espressif launched the ESP32-S31, and the chip's peripheral list is too strange for a microcontroller: gigabit Ethernet MAC, USB 2.0 High-Speed host controller, two SD interfaces, and a camera input. According to a report from XDA Developers published on September 23, 2026, the reason is simple: for the first time, an ESP32 has a real MMU, with support for Machine, Supervisor, and User privilege modes, exactly what a Linux kernel needs to run in supervisor mode with firmware underneath in machine mode.

From an I/O-packed MCU to a near-SBC

The S31 brings two SD interfaces (SDIO host), a full USB Type-A connector capable of supplying 500 mA in OTG host mode, an 8-to-16-bit DVP camera input, and a parallel LCD controller with support for up to 24-bit RGB (I8080 and MOTO6800 panels). Add to that two I2S controllers with hardware Bluetooth audio synchronization, fourteen capacitive touch channels, a CAN FD controller, and four MCPWM units. On the CPU side, there are two 32-bit RISC-V cores running at up to 320 MHz, each with its own floating-point unit, one of which gains a 128-bit SIMD data path; there is also a separate low-power core at 40 MHz. Each core has 32 KB of instruction L1 cache, and the two share 64 KB of data cache.

On the memory side, the S31 supports up to 64 MB of PSRAM through an 8-bit DDR interface at 250 MHz and up to 256 MB of flash, with the two interfaces separated: in the earlier ESP32-S3, PSRAM and flash shared the same bus, which made everything slower.

Sv32: the MMU that is finally an MMU

Espressif had already used the term "MMU" in chips like the S3 and the P4, but there the block only mapped external flash and PSRAM into the address space, without anything resembling process isolation or page tables. In the S31 datasheet, the company describes something different: address translation through a two-level page table in RISC-V's Sv32 scheme, with all three privilege modes fully implemented. It's this combination that allows a real kernel to run in supervisor mode, with firmware underneath in machine mode, the way RISC-V-based Linux machines work.

The community already got Linux running

Espressif itself published a Linux BSP (board support package) in August 2026 based on Buildroot and U-Boot, with a ready kernel, device tree, and root filesystem, although the company warns that it "is not yet recommended for production use." The community didn't wait: there's already a port running Linux 6.18 in supervisor mode with working drivers for practically all of the chip's hardware, and another, based on Linux 7.1, that drives an 800x480 LCD panel connected to the chip, displaying a real console. Plugging in a monitor, using wired Ethernet, and connecting a mouse and keyboard to a chip sold as a microcontroller is quite a leap.

Where the S31 still loses to an SBC

Memory is the weak point. The chip carries 512 KB of on-chip SRAM, with 16 MB or 32 MB PSRAM package variants (the theoretical maximum is 64 MB), and there's no DRAM controller. That's why Linux builds run the kernel directly from flash, to save the scarce PSRAM. There's also no embedded GPU or NPU: the chip only brings a JPEG codec, a 2D pixel accelerator, and 2D DMA, enough for simple tasks but nowhere near sustaining a full Linux desktop. For comparison, the XDA article cites the Milk-V Duo S, which has 512 MB of RAM, eight times more than the S31's top-of-the-line variant.

Gigabit Ethernet also deserves skepticism in real-world scenarios. At 320 MHz, the chip has about 3,900 CPU cycles per maximum-size Ethernet frame and only 215 cycles per minimum-size frame. With a theoretical limit of 500 MB/s on the PSRAM, it's possible to get close to gigabit throughput on large, continuous transfers, but saturating the link with many small packets is another story.

In exchange, the radio package is generous for the price: Wi-Fi 6 at 2.4 GHz, Bluetooth 5.4 with LE and Classic BR/EDR, and an 802.15.4 radio for Thread and Zigbee, alongside the gigabit MAC. That covers Matter (which runs over Wi-Fi and Thread) and still allows connecting older Bluetooth Classic audio peripherals. Power consumption follows a microcontroller profile: Wi-Fi reception between 110 mA and 117 mA, transmission with a peak of 265 mA on 802.11b at 15 dBm, and both cores in modem-sleep at 320 MHz consuming 91 mA with peripheral clocks off or 147 mA with them on.

The name is confusing, and so is the documentation

Calling the chip "S31" suggests a revision of the S3, but the two have little in common: the S3 uses Xtensa LX7 cores, and the S31 uses RISC-V, like the P4. Jeroen Domburg, Espressif's technical marketing manager, commented in a Hackaday discussion (cited by XDA) that "we never intended the CPU architecture to be part of the name," and stated that the core derives from the P4, at nearly double the speed of the S3. The datasheet, incidentally, is still at version 0.5 with a "PRELIMINARY" mark on the cover, and it carries a clear inconsistency: it lists the PSRAM with a maximum clock of 80 MHz, when Espressif itself has already disclosed 250 MHz in other materials.

What this unlocks for those building IoT and edge

For those developing today with ESP-IDF or FreeRTOS, the S31's practical promise isn't running a desktop, it's shortening the distance between prototyping on Linux (with SSH, a standard toolchain, kernel drivers) and then porting to a more constrained MCU environment, or vice versa. Teams that today use a Raspberry Pi Zero as a bridge between sensors and the cloud, just because they need a full Linux shell, gain an option with the cost, power draw, and footprint of a microcontroller, with built-in radios (Wi-Fi, BLE, Thread/Zigbee) that most competing SBCs in this price range don't ship with out of the box. That matters for industrial automation projects, Matter/Zigbee gateways, and edge devices that today pay the power and physical space price of an SBC just to get a complete network stack.

The caveat that Espressif's own technical material makes is important: the Linux BSP is experimental, with no production recommendation, and the available memory (at most 64 MB of PSRAM, with no dedicated DRAM) blocks any ambition of running heavy runtimes like Node.js or a full Python stack inside the embedded Linux. In practice, the more realistic path for now is to use the S31's Linux for debugging, quick driver prototyping, and hardware testing, keeping the final application in C over ESP-IDF or bare-metal RISC-V, the way it's already done today with the rest of the ESP32 family. The architectural leap, though, is real, and it opens the door for the next generation of these chips to finally close that gap.