It’s Linux. On An ESP32

By today’s standards, the necessities for running a Linux-based operating system are surprisingly meagre in terms of RAM and processor power. Back in the day we ran earlier Linux versions on Intel 386 and 486 machines with tiny quantities of memory compared to the multi-gigabyte many-core powerhouses we do today.

So it stands to reason that many of the more powerful microcontrollers should also run Linux, but of course they are often unable because the lack a memory management unit. The original ESP32 is just such a candidate, plenty of power but unable to run Linux. Not so fast, because [Dror Gluska] has managed to boot a Linux kernel on Espressif’s dual-core chip. How on earth? By emulating a RISC-V processor on it and booting a RISC-V version of the kernel.

The emulator in question is [Fabrice Belard]’s TinyEMU, a piece of software that brings both RISC-V and x86 to limited-spec platforms, and the write-up describes the extensive optimization and tracing of ESP32 bottlenecks which was finally able to get a Linux kernel booting in 1 minute and 35 seconds. Of course it’s simply an exercise to prove it can be done and we won’t be seeing Linux-based ESP projects any time soon, but it’s still an impressive piece of work.

This isn’t the lowest-spec microcontroller we’ve seen run Linux, back in 2012 we saw it on emulated ARM running on an 8-bit AVR.

30 thoughts on “It’s Linux. On An ESP32

      1. Linux does not need a mmu. The J2 core (a sh2 clone) does not have a mmu and does run Linux.
        If you run Linux in nommu mode, 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.

          1. There is no virtual memory and no Copy on Write. mmap uses the get_unmapped_area hook to ask the driver which address to use for the mapping, so the first parameter of mmap has no effect.

  1. Taking into account the relatively slow device and the many emulation layers, I find quite impressive that the kernel boots in 1 minute and 35 seconds. I find these useless projects pretty fun and interesting!

      1. Things were slow back in the day, for sure. SSDs have been a miracle, Win10 computers I built for my kids both go from fully shut down to Windows desktop in 7 seconds, counting time to enter the PIN; mine is only a hair slower, but it’s also older.

        Seems like only a few years ago when it was normal to hit the power button, and then go get a drink while the computer warms itself up to being usable!

        1. Yes! It was normal for me to have to wait 30 min for my win 10 pc to start. I switched to Linux, that sped up boot alot (but still relatively slow), and now with an SSD i’m running arch and it’s up in seconds.

  2. I was involved in a port of Linux to a nommu Xtensa in 2009. Nobody ever used that port, so I requested removal from the mainline kernel five years later. It had 512 MB of RAM though IIRC.

    1. We’ve removed the s6000 platform, but not the entire noMMU support.
      I was able to boot v5.19 linux kernel built for XIP on ESP32 with 8MB PSRAM, but to run useful userspace on it the FDPIC support in the toolchain is needed, because AFAIU it isn’t possible to run code from the PSRAM ):

  3. The main issue with the ESP platform is that it’s too closed source. You may not notice if you’re just writing applications using the Arduino environment, but its binary blobs for the WiFi driver actually contain a FreeRTOS kernel so if you want to run any other OS, sucks to be you.
    I still hope sooner or later the community will reverse engineer the WiFi driver and make a binary-blob-free firmware. Only then it will be possible to run Linux or any RTOS natively on the ESP.

    1. They are improving (moving codes from binary to ESP-IDF as much as they can, AFAIK, they can’t disclose the code due to their contract to IP vendor) and AFAIK, it is not impossible to use it with other OS.

      Though I agree it is hard to use the driver in other OS tho.

        1. Like perillamint said if it is a contract with another vendor that stops them from releasing the code then the same vendor probably would stop them from releasing documents about the hardware too, it’s not as simple as just release the documentation.

  4. They are improving (moving codes from binary to ESP-IDF as much as they can, AFAIK, they can’t disclose the code due to their contract to IP vendor) and AFAIK, it is not impossible to use it with other OS.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.