The ESP32-S31 gets a real Sv32 MMU after years of misleading "MMU" labels
Espressif has used the word "MMU" for a long time, which is why the S31 news is easy to miss. On older parts such as the ESP32-S3 and ESP32-P4, XDA Developers explains, the MMU was a block that maps external flash and PSRAM to address space, nowhere near the complexity of a modern MMU that can also do things like process isolation and page tables. Hackaday commenters said the same about the original ESP32 years ago: it had a simple MMU that handled mapped memory, but it does not support paging, and paging is required for Linux to work.
The S31 is different. Espressif's preliminary datasheet (revision 0.5) lists "Sv32 two-level page-table address translation" among the CPU features. According to XDA, it also says the cores implement Machine, Supervisor and User privilege modes. Sv32 is the actual RISC-V paging scheme, and having all three privilege modes is what enables a regular kernel to run in supervisor mode with firmware underneath it in machine mode. That layered setup is how standard RISC-V Linux systems are built. Firmware such as OpenSBI runs in machine mode, the kernel runs in supervisor mode, and applications run in user mode.
The difference is practical. Earlier Linux-on-ESP32 projects used "NOMMU" kernels, which is still the approach on the S3: Hackaday's recent coverage of a Linux 6.11 port to that chip notes the S3 lacks certain amenities that spoiled OSes like Linux have come to take for granted, such as a Memory Management Unit (MMU). Without paging, as one commenter put it, every program is running like it is run by root and has no protection of its memory. In other words, a MMU with paging is required for security. On the S31, a single faulty process no longer has to take down the whole system.
The rest of the compute block is modest by SBC standards and generous by microcontroller standards. The datasheet lists two 32-bit RISC-V high-performance cores at up to 320 MHz, each with a single-precision FPU, and a 128-bit SIMD data path on one of them. It adds a separate low-power RISC-V core at up to 40 MHz, 512 KB of high-performance SRAM, and a dual-core CoreMark score of 2,195.20 at 320 MHz. Espressif's Jeroen Domburg, writing in a Hackaday comment thread, said the core derives from the P4's, and he estimated the S31 at almost 2x as fast as the -S3.
Espressif's esp-linux-bsp is a developer preview for the S31
Official Linux support arrived quickly. Adafruit reported in late August that Espressif had posted a Linux BSP for the S31. The package lives in Espressif's esp-linux-bsp repository on the integration/v1.0-esp32s31 branch. It is built on Buildroot and U-Boot. Its packaging script wraps a U-Boot SPL (the small first-stage loader) in Espressif's image format and combines it with a U-Boot FIT image, a Linux device tree, an execute-in-place (XIP) kernel and a cramfs root filesystem into one flash image, s31_full_flash.bin.
The repository's warnings are direct. The branch is labelled a developer preview that is "not yet recommended for production use." Espressif describes it as meant for evaluation, testing and technical validation. It supports the S31 only, has no scheduled release cadence, may introduce breaking changes without notice, fixes bugs on a best-effort basis and makes no API/ABI compatibility guarantees. The repository lists early adopters, hardware evaluation and prototyping as suitable uses. It lists production deployments, long-term projects that need stability, and critical systems as unsuitable.
It is also unclear how much hardware the official BSP drives today. When the repository appeared, Adafruit noted that it's also unclear what's implemented so far — whether WiFi works, for one. The repository documents image layout and packaging. It does not publish a peripheral support matrix. Anyone evaluating the official BSP should treat Wi-Fi, Bluetooth and the more unusual peripherals as unknown until they confirm them on their own board.
Community ports bring Linux 6.18 and Linux 7.1 to the ESP32-S31 Korvo-1
Community developers have gone further than the official preview. GrieferPig's project, described as MMU RV32 Linux running natively on an ESP32-S31 microcontroller. Module tested: ESP32-S31-WROOM-3 E1H16R16V (ESP32-S31 Core Board/Korvo). It began on Linux 6.12. In August, Adafruit described that version as Buildroot-based and stable across reboots, with poweroff not implemented and Wi-Fi, dual-mode Bluetooth and dual-core support still experimental. The project has since moved on: Linux runs in S-mode with native S-mode IPI and SYSTIMER paths, while OpenSBI retains M-mode boot, HSM and reset services. Linux 6.18 executes its XIP text from flash and keeps writable state in RAM. Its userspace uses wpa_supplicant/wpa_cli for Wi-Fi, a BTstack A2DP sink plus BLE GATT peripheral over /dev/s31-hci for Bluetooth, and libgpiod 2.x for GPIO character devices.
The port took real reverse engineering. The S31 routes interrupts through CLIC, a controller Linux does not expect. The project's documentation says S31 uses CLIC and CLINT similar to P4. Linux expects PLIC. Therefore a custom CLIC driver is needed. The author also found that S31's supervisor mode is not standard and has absolutely no usage in ESP-IDF so a lot of these CSR uses were mostly guessed from either P4's TRM or CSR probing. The author openly says the work is heavily AI-agent-assisted, and warns that it is Experimental Definitely not something you want for production. Early write-ups of the 6.12 build reported that the system boots to a shell with ~15MB usable RAM and achieves a CoreMark score of ~1059.
A second project, maintained by annoyedmilk, targets Linux 7.1 with OpenSBI 1.9 on the ESP32-S31 Korvo-1 multimedia board. It uses 16 MiB of octal PSRAM as system memory. Its README describes an unusual split. One core never leaves machine mode and keeps running the ESP-IDF loader as firmware that owns the Wi-Fi modem, while Linux gets the other core to itself. Linux sees Wi-Fi as a wlan0 device that passes frames to that firmware through shared-memory rings. The Korvo-1's 800×480 RGB LCD shows up as /dev/fb0 with a text console. The board's Type-A port works as a high-speed USB host, so a keyboard and mouse appear under /dev/input, and USB flash drives mount as /dev/sda. The microSD slot runs through the stock dw_mmc driver with FAT and ext4 root filesystems.
The README is just as candid about the compromises. There is no hardware cache coherency for DMA, and PSRAM has no uncached alias, so coherent DMA buffers have to come from a 64 KiB pool in internal SRAM. The board has no real-time clock, so an init script restores the last known time to keep TLS working. A swap file of up to 64 MiB is created on the SD card because, in the README's words, 16 MiB of PSRAM "is the whole machine." The LCD and the native USB Serial/JTAG interface share GPIO33 and GPIO34, so you can have the display or JTAG debugging, not both. The documented build host is macOS with Homebrew, ESP-IDF and Apple's container CLI. Windows users should not expect a supported path for this particular port.
Gigabit Ethernet, USB host and radios give the ESP32-S31 an SBC-like feature list
The chip's peripherals explain why the Raspberry Pi comparison comes up at all. The datasheet lists a 1000 Mbps Ethernet MAC, USB 2.0 High-Speed OTG, an SDIO host controller with two slots, an LCD and camera controller, two I²S interfaces with hardware-level Bluetooth audio support, a CAN FD controller, four motor-control PWM units and 60 GPIOs. It also includes a JPEG codec, a pixel-processing accelerator and a 2D-DMA controller. Hackaday's launch coverage in April noted that the Ethernet MAC got a bump from the 100 Mbit RMII MAC in previous MCUs and is now gigabit-rated, while the number of GPIO is significantly higher at 60 instead of 45 on the -S3.
Much of this depends on the board, not the chip. The Ethernet block is a MAC that connects over MII, RMII or RGMII to an external PHY chip, and gigabit operation needs RGMII. An RJ45 jack exists only if the board designer adds the PHY and connector. The same goes for USB: the full-size Type-A host socket and its current-limited 5 V supply are features of boards like the Korvo-1, not of the S31 silicon.
The radio side is where the S31 goes beyond many SBCs. The datasheet lists single-stream 2.4 GHz Wi-Fi 6 (20 MHz-only in 802.11ax mode), Bluetooth 5.4 LE with LE Audio, Bluetooth Classic, and 802.15.4 with Thread 1.4 and Zigbee 3.0. Matter is listed among supported protocols. Hackaday called Wi-Fi 6 and Bluetooth Classic plus LE 5.4 the most obvious improvements over the S3. Bluetooth Classic matters for anyone building audio receivers that need to work with older headsets and speakers.
Power draw is still microcontroller-class. XDA's reading of the datasheet puts Wi-Fi receive at roughly 110–117 mA and peak transmit at 265 mA (802.11b at 15 dBm). By the same reading, both cores in modem-sleep at 320 MHz draw 91 mA with peripheral clocks off and 147 mA with them on. For a battery-powered or PoE-constrained device, that profile is the S31's real selling point.
16 MB of PSRAM keeps the ESP32-S31 a microcontroller
The weak spot is memory. Both S31 parts named in the datasheet, the ESP32-S31NRV16 and ESP32-S31NRV32, carry PSRAM in the package, and the datasheet's memory interface is a 250 MHz 8-bit DDR PSRAM link described as "in-package only." There is no DRAM controller. XDA compares this with the Milk-V Duo S and its 512 MB of RAM. The comparison with any Raspberry Pi is even more one-sided. Hackaday commenters were blunt at launch: Using linux with only half a GB/s memory bandwidth and less than 16MB of memory will likely prove suicidal. The ports that exist show it is not suicidal. They do show how much work it takes to fit.
That constraint explains the design choices in both community ports. The kernel runs in place from flash so its code does not use up PSRAM. Swap goes to the SD card. The framebuffer takes a fixed slice at the top of PSRAM. One port hands a whole core to firmware that runs Wi-Fi. There is no GPU and no NPU, so a graphical desktop is out of reach. A text console on an 800×480 panel is about the limit.
Networking throughput is another open question. XDA did the arithmetic: at 320 MHz the CPU gets roughly 3,900 cycles per maximum-size Ethernet frame and about 215 per minimum-size frame at gigabit line rate. The numbers check out. A 1,538-byte frame on the wire takes about 12.3 microseconds at 1 Gbps, and a minimum 84-byte slot takes about 0.67 microseconds. Large bulk transfers may get reasonably close to gigabit. Workloads with many small packets almost certainly will not. Nobody has published Linux throughput figures for the S31's Ethernet yet, so the gigabit MAC is a capability, not a measured result.
The documentation is still settling too. The datasheet carries a PRELIMINARY watermark at version 0.5, and XDA notes it lists an 80 MHz maximum PSRAM clock in one place while the feature summary says 250 MHz. The naming adds some confusion. Hackaday noted that the ESP32-S series was always the one based on Tensilica Xtensa LX7 cores, while the ESP32-C series was the one using RISC-V cores. Domburg responded that Espressif "actually never intended the CPU architecture to be part of the name." The practical result: code and toolchains for Xtensa S3 parts do not carry over to the S31 without change.
What this means for embedded developers weighing the ESP32-S31
If you want Linux on an S31 today, you are signing up for evaluation and prototyping, not deployment. Linux is interesting on this chip when a product needs standard Linux networking, filesystems and userspace tools alongside microcontroller-style I/O, radios and a low power budget. If you need a Linux box with real RAM, a graphical desktop or predictable long-term support, a conventional SBC is still the right choice. The S31 running plain ESP-IDF firmware, with no Linux at all, is still the lower-risk way to use its gigabit MAC and radios in a product.
- The ESP32-S31 is the first ESP32 with Sv32 page tables and supervisor mode, so it can run a standard MMU Linux kernel with process isolation instead of a NOMMU build.
- Espressif's
esp-linux-bsp(integration/v1.0-esp32s31) is a developer preview with no API/ABI guarantees, and Espressif explicitly advises against production and critical-system use. - Community ports boot Linux 6.18 and Linux 7.1 on Korvo-class boards with Wi-Fi, USB host, SD storage and an LCD console. Their authors label them experimental, and the documented Linux 7.1 build host is macOS.
- Shipping S31 parts carry 16 MB or 32 MB of in-package PSRAM and no DRAM controller, so plan for a serial or framebuffer console and headless services, not a desktop.
- Features like an RJ45 jack, a full-size USB-A host port and a microSD slot depend on the specific development board, so check the exact module and board before designing around them.
- The gigabit Ethernet MAC has no published Linux throughput figures yet, and small-packet workloads are unlikely to reach line rate on 320 MHz cores.
The ESP32-S31 is the first ESP32 where running Linux is a real engineering option rather than a party trick. It has proper paging hardware, an official BSP and working community ports that drive a display, USB and wireless. It is also memory-starved and backed by a preliminary datasheet and preview-grade software. For now, this is a prototyping platform. The next milestones are a final datasheet, a Linux BSP that moves beyond developer-preview status, and the first published network and memory benchmarks.