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.
Isn’t ESP32 supposed to have an actual MMU? Or is the datasheet just misleading?
It has a very simple MMU that allows doing things like MMAPs. But it does not support paging, and paging is required for Linux to work.
Is µClinux (port of Linux for microcontrollers without a MMU) still a thing?
I wish I knew. I remember running that on a Palm V with 8 MB of RAM. I think it even had an X server.
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.
Interesting. And how do things like Copy on Write, mmaps, etc (virtual memory in general) work without MMU? Is it somehow emulated by the kernel in that mode?
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.
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!
I know! It’s still faster than most of my windows machines ever did… 😭
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!
Was this easier than using the Xtensa architecture support in the kernel?
https://www.kernel.org/doc/html/v5.17/xtensa/index.html
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.
Max still maintains it upstream though (the nommu kc705 variant), and he has an updated branch for native esp32 support, see:
https://github.com/jcmvbkbc/linux-xtensa/tree/xtensa-5.19-esp32
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 ):
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.
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.
Just release complete docs about HW, no need to open the blobs (unless there’s a hidden coprocessor): someone will write the needed sw. Way less effort than reversing the blobs.
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.
The ESP32-C3 has a RISC-V core, so it should be possible to port Linux to it withour the RISC-V emulation layer
The question is whether such a Linux will use less power
linux device working on AA for example week
(i dreaming)
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.
no.
What about using ESP32-C3 ? It Is already Risc-V, so no emulation needed 🙂
Related (MIPS on CM0 instead of RV on Xtensa) https://dmitry.gr/?r=05.Projects&proj=33.%20LinuxCard
Hi,
You can try a 8086 Linux derivative called ELKS https://github.com/jbruchon/elks . It can run with 500 kb of RAM. I use it on my IBM 5160.
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.
By using our website and services, you expressly agree to the placement of our performance, functionality and advertising cookies. Learn more