Run linux on the ESP32?

[mharizanov]

Actually there is already an ESP32 linux port, it was announced here: https://www.reddit.com/r/esp32/comments ... ime_video/
It is far from practical, but cool factor is A+

[ESP_Sprite]

FWIW, that is not a port, that is an Arm emulator that boots a more-or-less stock Linux kernel. It's an interesting proof of concept, but not something that I'd expect to blossom into something useful.

[winter]

You'd be stretching yourself to thin in doing so, not to mention what real gain would you get by doing so.

Bragging rights?

[rudi ;-)]

hi

Linux 5.5-rc1

Just in time there is a work on RC1 ..
by Max Filippov : "Xtensa updates"
 

kernel git torvalds linux git - Linux kernel source tree.png (56.35 KiB) Viewed 21491 times

 

add support for execute in place (XIP) kernels

 

best wishes
rudi

[mikronauts]

Take a look at Minix it should fit and does not need an mmu.

[copercini]

There is a curious branch in official linux-xtensa repo, called xtensa-5.6-esp32 with the following description:
Configured with FLASH and PSRAM it is capable of running noMMU Linux

it's here: https://github.com/jcmvbkbc/linux-xtens ... af8a5d20aa

[PeterR]

Call me a philistine but I don't see this as achieving a practical benefit.
The ESP is RAM (and also ROM) constrained which end up becoming CPU bound. Cannot see adding a (larger) linux stack as helping.
Even with dual SPI we end up with 20MB/S or 5MHz CPU out of cache worse case.
I think the reality is that ESP needs a tight stack. I am somewhat amazed over ESP's approach e.g. linux style I2C driver given the processor's constraints.
I would better appreciate a FatFs which does not steal 10KB (and/or better documentation/defaults).

[systemBuilder]

I got program on a PDP-11/70 in middle school and remember the dreaded "Bus Error. Core Dumped." error message which means your C program tried to use an invalid address and the kernel terminated your program. This was the memory management unit stopping your code from reading or writing protected memory.

The very earliest versions of UNIX could work without an MMU. All they needed was a disk drive and enough memory so that the operating system could be resident along with your program. Indeed, you could overwrite the OS and crash the computer, but that did not happen very often. The kernel would swap your program into RAM (from disk), run it for maybe 10-100 milliseconds, and then save the results back onto disk and continue with another process. This is why UNIX has "cooked" mode of input - so the kernel could display and edit the characters you typed while your program was actually sitting on the disk drive, not being executed. Shell pipes were implemented by storing intermediate results on files. So yes, you can actually run UNIX without any sort of an MMU, it's just safer and more robust if you have some sort of memory protection, especially for the kernel. It's the scalability of UNIX which made it completely unique.

When I was fresh out of college I programmed a Xerox 8010 Dandelion Workstation and it had every program co-resident in 768KB of RAM, including a black-and-white window system (1120x768 I think - enough for 2 wyswyg sheets of paper @ 75dpi). All programs shared the same address space and if one crashed, everything went down. It was multi-threaded but not pre-emptive, so if you wrote an infinite loop you'd be reaching for the reset switch pretty quickly.

[jcmvbkbc]

I have mixed news on the topic.

First: I was able to run linux + buildroot-built minimal rootfs based on busybox on esp32s3 with 8MB FLASH and 8MB PSRAM. The kernel runs directly from FLASH (XIP), the userspace runs directly from FLASH (FDPIC ELF binaries on cramfs with XIP support), PSRAM is used only for data and stacks. Currently there's no NPTL support in the toolchain (but I'm going to implement it). Minimal kernel image is ~1.6MB, with basic networking (only software side, like IP support, no drivers for the hardware and no integration with wifi so far) it's ~2.5MB. Minimal rootfs size is ~1.8MB, but since it's dynamically linked it's not going to grow significantly as new features will get added. Kernel boots to init in ~3 seconds and to login prompt in less than 10 seconds. Details, including repo branches, commands and used scripts are available here.

Second: I wasn't able to run linux + userspace on esp32 with PSRAM, it's blocked by the failure to map the complete rootfs image into memory. The issue is reported here. Even with that issue resolved there seems to be too little space available for the FLASH mapping to do anything useful.

[rudi ;-)]

feedback & update
================
picture says more as 1000 words

limit1.png (874.96 KiB) Viewed 9679 times

just in time i tuned up the things little more psram ... #psrambank
i am on this (limited) way to figure it out for more use cases

best wishes
rudi