It’s something of an article of faith, that to run Linux your computer must include a hardware memory management unit, or MMU. To an extent it’s true, in that for a Linux-based system to shine it must have that hardware, but in fact there has been support for MMU-less Linux for many years now. Prolific hacker [cnlohr] has created an emulated simple RISCV processor without an MMU, and not only does it run Linux, it also runs DOOM.
The videos below the break go into significant depth on writing and debugging an emulator not to mention the inner workings of DOOM, but fear not if it’s not your thing. Everything can be found in a GitHub repository, and there are straightforward instructions should you wish to try it yourself.
All this is entertaining stuff, but it becomes of much more interest when viewed as part of an ongoing chain of projects working on no-MMU Linux for low-end RISC-V microcontrollers. Imagine the prospect of running Linux on a CPU costing relative pennies, and you can see why that’s an interesting prospect. Even if it’s not the most unexpected way to run Linux without an MMU.
I get really angry when people confuse MMU with virtual memory. Sometimes I want to take my Makita and SDS through my monitor in rage when I see stupidity.
I wasn’t at all familiar with the RISC-V architecture when I read this article, but was extremely suspicious of the claim that there was no MMU. I found architecture diagrams for the RISC-V that clearly show an MMU, and it only took about a 30 seconds of searching on Google. 🤦
Okay, the thing is most riscv32 processors only have a very basic MMU (not enough for the Linux kernel). So in order to run Linux on it you run, guess what, MMU-less Linux with uClibc (a standard library intended for systems without MMUs)!
Wow! If the author here did the smallest bit of research, they would have realized that RISC-V has an MMU. I knew nothing of the architecture, but was very suspicious of the claim of no MMU. I was able to find an architecture diagram in less than 2 minutes of searching. It most definitely has an MMU.
Most of the RISC-V MCUs available on the market do not have an MMU. Only the high-end Linux-capable ones have an MMU. More so, it’d be exceptionally stupid to have an MCU with an MMU, as it opens an entire can of latency worms.
It’s not that dumb though – the original Doom on MS-DOS didn’t use virtual memory but it did run in protected mode – which uses an MMU.
I use the term in the scope of what the rest of the software world calls an MMU. A bus interface with memory is not an MMU according to Linux, musl or libc. I side with their definitions.
Exactly, MMU does page address calculation and optionally page protection checks. MCUs don’t have such MMUs and should not have them.
MMU, by definition, does paging. If it does not, it’s not an MMU. And you don’t wany any address translation and page faults on your MCU, your memory access latency must be deterministic.
Amazing my man. The last line of the Doom video caught me off guard and had me laughing.
Do you think it would be possible to get Linux running on an STM32F411 ?
It’s an ARM CPU with a decent amount of RAM and EPROM.
That is possible, though would be very difficult. It doesn’t seem like the Kernel understands different data/code bus rules.
So there’s ARMs and ARMs?
Linux runs on a lot of server based ARM CPUs now. Perhaps the SoC ARMs run differently (other than just not having an MMU).
Of course there is a massive difference between tiny MCU cores that only support some Thumb subset and no priviledged modes whatsoever, not to mention the absence of MMU, and fully functional high-end cores with a full ISA support, with priviledged modes, with MMU, with instruction and data caches, with an ability to use an external DRAM.
There is very little in common between, say ARM Cortex-R5 and ARM Cortex-A15.
The only STM32’s I’m aware of it supporting (outside the completely different MP1 series) are ones with external memory interfaces. Unless there’s a really big ‘F411, I don’t think it has that. Even the couple hundred KB just isn’t enough and you **need** at least a couple MB of external SDRAM or SRAM to get a linux kernel booting (even with XIP flash).
A few years back someone got Linux running on an Arduino Uno wired to an SD card. The Arduino was emulating a larger CPU with more memory. It wasn’t the fastest.
The stm32f413 can and the EVK does have 1MB of PSRAM via QSPI as well as 16MB of Flash QSPI+1.5MB of internal Flash. So you should adapt Linux to this SoC and run in MMU-less mode(ucLinux) but the speed won’t be that much even if yes, it should work.
The point is that you can find SoCs that cost less and are more powerful than it.
But done as an ex recise is a great way to learn. I’ve added basic support to Linux for i.MXRT1050 that has parallel sdram and sd-card and it works.
Of course using QSPI PSRAM will slow things down and you need to use a bigger PSRAM.
To run Doom over it at least 8MB and then shrinking down busybox, sdl and its dependencies. Take a look to Buildroot pending patches for i.MXRT so you can try to build and see the needed resources. But it takes a lot of time and effort.
I miss Guru Meditation Errors :)
There’s also ReGIS for vectorial output to a terminal: https://en.wikipedia.org/wiki/ReGIS — I remember I had a VT220 connected to my Linux machine in the late 90s so that I would always know where my text console was. I knew of a VT340 stashed in one of the lab’s cupboards however (colour output, but too big for my desk). But when I read the language I was using at the time (IDL) could output ReGIS, of course I swapped my VT220 for the VT340, and to my amazement, the graphical output just worked! All I remember is that painting shapes pixel by pixel was very slow. Way slower than LOGO on my Amstrad CP6128, but maybe my Baudrate was set too low, I don’t know. Probably not fast enough for Doom, but if I ever did see a “vector doom” running on a VT340, I think I would really grin ear to ear… So *this* is how it’s done, huh? ;-)
Sixel is probably better suited for this (and also supported by VT340).
Time for a proper uClinux distribution with binary packages :-)
I guess that’s easier than porting Linux to 80286 and 16-Bit segmented protected-mode.
There’s an 8028 version, but still no native, specific port for the 80286.
The 80286 had a full-fledged MMU and supported virtual memory, it merely lacked a paging unit.
This didn’t stop OS/2 1.3 from fully supporting virtual memory, though.
*8086 version.
I was coming here to say, Microrport System V/AT ran on a 286 quite nicely back in the day, but I didn’t think the 286 had an MMU. I shall have to google it (or altavista it!)
Wikepedia – computer says “yes”!
The 286 has a very sophisticated MMU, but lacks paging. And the first run on i286 chips and the BIOS that IBM shipped with the AT made getting out of protected mode difficult and made using BIOS and option ROM from pmode almost impossible.
Many years ago, my friend wrote a nice article on one of the undocumented tricks for 286 pmode (the undocumented 286 LOADALL instruction) as well as some history and detail and comparison to the better know 386+ LOADALL. http://rcollins.org/articles/loadall/
A more interesting article of his is on “Protected Mode Basics.” I guess nobody else tried to figure out 286 Protected Mode from scratch. http://rcollins.org/articles/pmbasics/tspec_a1_doc.html
always a trip to see text-mode doom again! gonna toot my own horn because i’m old enough to want to tell stories
when the quake source was leaked, i got ahold of it and noticed an incomplete svgalib port, so i completed that and sent a patch file to John Carmack, who hired David Kirsch (Zoid) to support that port. and a few months after that, i stumbled onto aalib (ascii art). and just on a lark, i spent an evening making the thinnest shim so that a program linked against svgalib could render to aalib. so i was playing doom and quake in ascii. i called it aavga and uploaded it to sunsite in 1997. then Bob Zimbinski (bobz) cleaned it up and packaged it better and called it ttyquake. it had enough wow factor that slashdot rediscovered it at least 3 times. seemed like they were running an annual article on it for the first half of the aughts. and now, everyone has seen it and even though i think my tiny contribution isn’t being used anymore, the idea has become a part of the “but will it run doom” movement.
really the story just goes to show how easy it was 25 years ago to be the first one to do something unique on a computer