Hacker News Reader

Comment by rbanffy | Hacker News Reader

I remember Linux (and NetBSD) running on outrageously low-end hardware (even hardware without an MMU). While modern Linux is a no-go, would there any existing and relatively popular OS be viable?

View on HN

You can run uC Linux without an MMU, but you won't get memory safety. Better microcontrollers (that includes the RP2040 and RP2350) have an MPU (memory protection unit) to implement memory safety, but almost no microcontroller has a real MMU (only the MIPS derived PIC32 come to mind). An MPU is far more visibly exposed to the programmer than a paging MMU that combines access control with address space virtualisation. To make it even more annoying the ARMv6M architecture isn't intended to recover from memory usage faults. You have to use really dirty tricks to "fake it" (return from the hard fault into an unimplemented exception, infer the address and cause the fault before you can recover), but it's possible. It's not even that slow. Depending on your usecase a fast warm-start of the whole chip may be preferable to restarting single tasks (e.g. just set the hardware watchdog countdown timer to 1 and spin until it happens).

Guess it depends on your definition of popular. There's various RTOS products, some of which have POSIX APIs.

If you're fine with obscure and retro, there's things like RISC-OS (ARM). Or EmuTOS (68k/ColdFire). Or FreeDOS etc (x86)

I wouldn’t say RISC-OS or EmuTOS would be sensible options for new development unless the point is to develop for them (I wrote a couple programs to use Tektronix 4014 graphics the other day in order to use Tektronix 4014 graphics). I was thinking about reusing existing OSs and their stacks.

You can run modern Linux without an MMU! But other popular embedded OSes I've heard about are FreeRTOS and Zephyr.

And someone has in fact managed to get MMU-less Linux running on the newer Pico 2:

https://github.com/Mr-Bossman/pi-pico2-linux

That's with an 8MB external PSRAM though, fitting modern Linux in the internal SRAM is probably a step too far.

I used to work with a Cortex-M3 port of uCLinux, but it was kind of a pain to manage. The biggest problem being every executable had to be statically linked to all of its dependencies.

Reply on news.ycombinator.com