There are many possible answers to the question of what the lowest-powered hardware on which Linux could run might be, but it’s usually a pre-requisite for a Linux-capable platform to have a memory management unit, or MMU. That’s not the whole story though, because there are microcontroller-focused variants of the kernel which don’t require an MMU, including one for the Xtensa cores found on many Espressif chips. It’s this that [Naveen] is using to produce a computer which may not be the Linux computer with the lowest processor power, but could be the one consuming the least electrical power.
The result is definitely not a Linux powerhouse, but with its Arduino-sourced ESP32 board stacked on an UNO and I2C keyboard and display, it’s an extremely lightweight device. The question remains, though, is it more than a curiosity, and to what can it do? The chief advantage it has over its competitors such as the Raspberry Pi Zero comes in low power consumption, but can its cut-down Linux offer as much as a full-fat version? We are guessing that some commenters below will know the answer.
If you’re curious about the Xtensa version of Linux, it can be found here,
Reminds me of those rootable SD cards with wifi that allow sharing pictures from a camera that turned out to be running linux. Those have to be in the running for lowest power, lowest hardware linux.
I played with one of those (PQI Air Card). It had a SOC with a ARM Core running a full-on busybox-based Linux out of a RAM disk and you’re right about lowest hardware. Two chips in an area about the size of your thumbnail. And it was surprisingly hackable.
Cool, I did not know that!
Nice, I have been musing about this possibility before. Nice to see someone actually do it.
(my brain would not let me but I will gladly cheer on)
With some sort of bigger terminal this would make a great typewriter/wordprocessor core.
Ps. Without a MMU, all programs have essentially root access to memory, something to think about.
All programs having root access to memory was the norm not so long ago. Think about MS-DOS, Amiga OS, Windows 3.x 95, 98 and ME, all Apple computers before MAX OS X…
All the OSes you mention could not use a MMU since there where none on the original hardware. I don’t know why powerpc macos didn’t use the MMU but I have a feeling it is about compatibility. Probably the same for windows shells.
Oh nice, so total freedom
On some architectures (like ARMv7/8-M) kernel can use MPU to isolate the memory allocated for the particular process. Absolute address is still used but you get a “poor man’s MMU”
I’m not sure what processors they use, but I believe the Keurig coffee machines use embedded Linux. I was asked if I was interested in a job there, but was doing more interesting work elsewhere.
DSLinux functioned without a real MMU iirc.
uclinux too.
But as far as I know the project has been mostly dead for quite a bunch of years.
https://en.wikipedia.org/wiki/%CE%9CClinux
uclinux appears dead since it is now in the mainline kernal, it was merged around 2.6
I’d be happy for a Linux board with deep sleep like the ESP32, or even better light sleep between DTIM polls for a quick reconnect. That’d save _tons_ of battery power. As it is you have to add an external chip to power them off and on as needed.
It’s certainly not the Linux system with the least processing power. The ESP32-S3 is, in most ways, a more powerful CPU than the 80386 systems I was running Linux on in 1994. (Those did have an MMU). One big limitation of the Nano ESP32 is that it only has the 512 KB of RAM on chip to work with. It does have 16 MB of flash to run programs from; that doesn’t have to serve as storage because the Adafruit display shield has a Micro SD slot.
The Uno R4 WiFi that is used in this project is an odd duck, in that the ESP32-S3 that is on the board just to provide WiFi and Bluetooth is in many ways a more capable processor than the Renesas RA4M1 main microcontroller. The RA4M1 is a Cortex-M4, which means hardware floating point among other things, but it’s clocked at a leisurely 48 MHz and has less flash and RAM than the ESP32. It was chosen because it’s fully 5V capable, a rarity among 32-bit microcontrollers, making it a better drop-in replacement for the Uno R3 than a 3.3V processor would be. Lack of 5V capability caused previous Arm-based boards in the Uno form factor like the Arduino Zero to not be widely accepted.
Doesn’t the ESP32-S3 have a still-rudimentary but more capable MMU than the original ESP32? I thought I remember reading it can perform some virtual to physical translations. I wondered if that could be used for a version of linux or some RTOS that would allow dynamic loading of [probably very small] IRAM-resident application programs. That would take the ESP32 to a whole new level of capability.
Technically speaking mainline linux already has support for the xtensa architecture when an MMU is available (https://www.kernel.org/doc/html/v5.17/xtensa/mmu.html) as well as support for MMU-less operation that’s been merged for use on the RISC-V K210 SoC (work done by WD). It wouldn’t be all that surprising if someone adapted the kernel for MMU-less operation on xtensa, though you’d have to go through a fair bit of work to get it upstream.
That said, the usual stability and reliability caveats apply for MMU-less systems.
We had support for MMU-less Stretch s6000 Xtensa chips in mainline Linux, but nobody used the code, so we removed it in 2014 – long after the chips went out of production. Actually the chips did have an MMU, but you had to load the entries manually, so it was used only to provide a static second view of the RAM with different caching behavior.
There is some level of support for MMU-less systems in the mainline linux kernel on m68/Coldfire, Arm Cortex-M, Xtensa, SuperH and RISC-V processors, though most of the work on these seems to have stopped around 2017 and these are largely on life support.
There was some recent work to add another Arm SoC family (NXP i.MXRT) and to convert all architectures to the ELF-FDPIC binary format to replace the flat binaries.
Running in 512KB of RAM with XIP-kernel and XIP filesystem is extremely impressive, the smallest configuration that I’m aware of actually having worked in the past using an unpatched kernel was an STM32 with 2MB SRAM, and to actually run anything useful on a modern kernel, even 64MB is tricky.
I would expect that the version of Linux for the ESP32 separates out code and data areas of the kernel. Code goes in the 16 MB external flash memory on the Nano board, data goes in the RAM. The 384 kB ROM in the chip is only used for the bootloader and the wireless stack supplied by Espressif.
The amount that you can reduce Linux has become quite impressive. There is a guide “Linux Kernel Tinification” which can memory usage to work with system that have a mere 256KB of RAM!
Vitaly Wool talked about his experiments with a 256KB SRAM Linux on STM32 back in 2014, but that was a heavily patched kernel and I don’t think much of that work went upstream. Nicolas Pitre tried to to revive the tinyfication around 2016, but again very little came of that, and I’m fairly sure the bloat only got worse since he stopped.
On Arm kernels (also riscv and xtensa), one can now use XIP_KERNEL again for most platforms, which would certainly be a requirement, but in turn the MTD_XIP option (running a XIP kernel on the same MTD device that holds a writable filesystem) got lost in the meantime, and was never available for the microcontroller platforms.
An Arm tinyconfig kernel today uses only 40KB of .data, plus around 600kb of read-only .rodata and .text,, but this also doesn’t do anything and is about 20% larger than the same config on a 4.0 kernel.
Also https://tiny.slitaz.org/ can run on 4MB but on x86.
I’m curious if FatFS would have any advantages over cramFS :https://en.wikipedia.org/wiki/FatFs
not sure if it is POSIX compliant, but it uses a different license.
Also,
https://topic.alibabacloud.com/a/comparison-of-file-systems-in-embedded-systems-jffs2-yaffs-cramfs-romfs-ramdisk-ramfstmpfs_8_8_31786050.html
> It wouldn’t be all that surprising if someone adapted the kernel for MMU-less operation on xtensa, though you’d have to go through a fair bit of work to get it upstream.
Would it be surprising if I said that the mainline linux kernel is used in this project and only the esp32s3-specific drivers and configuration files and really dirty hacks for dealing with the Harvard-style instruction/data address spaces split are added on top of it?
We’ve come a long way! The person who created linux-xtensa is also the one who ported GCC that made it possible to run code on ESP8266 in 2014.
https://hackaday.com/2014/10/02/gcc-for-the-esp8266-wifi-module/
At that point GCC had already been supporting Xtensa for several years. What was missing was support for Xtensa cores where the register window feature had been disabled during synthesis, IIRC. Without register windows you need different calling conventions for function calls.
What Daniel says above about gcc is right. In addition to that I did not create linux-xtensa, AFAIK it was created by Piet Delaney, Marc Gauthier, Joe Taylor and Chris Zankel. I joined that project in 2012, more than 7 years after it’s been merged to the linux mainline.
ELKS is a 16 bit embedded x86 Linux. It does not need a MMU. You can run it on esp32 with an IBM PC emulator. You have a nice 16 bit compiler to code for ELKS. Btw, ELKS is well supported and in active development.
This is a fascinating post. I just wanted to share it with Distrowatch’s readers — alas to no avail, as Dostrowatch’s comments section is closed until the publication of its weekly newsletter in few days.
I no need all this nerd texts ;-)
I need working computer with ssh,bash, gcc, mc, git,make,vi
with keyboard, screen minimal 25×80 , maksimum 500 grams and longest as possible working time on battery
Please make chalenge. every years. every value increase points, more screen size more points, more baterry time == more points, faster system == more points etc.
Sure, but you’ll have to donate about $5,000 per point :D
Or, in the words of the wise one, if you want it done right, do it yourself.
Meh! That’s still more CPU than a dead badger!
http://strangehorizons.com/non-fiction/articles/installing-linux-on-a-dead-badger-users-notes/