We’re used to running Linux on CPUs where it belongs, and the consensus is that RP2040 just isn’t up for the task – no memory controller, and nowhere near enough RAM, to boot. At least, that’s what you might believe until you see [tvlad1234]’s Linux-on-RP2040 project, reminding us there’s more than one way to boot Linux on a CPU like this! Just like with the “Linux on AVR” project in 2012 that emulated an ARM processor, the pico-rv32ima project emulates a RISC-V core – keeping up with the times.
Initially, the aforementioned “Linux on AVR through ARM” project was picked as a base – then, a newer development, [cnlohr]’s RISC-V emulator, presented itself and was too good to pass up on. Lack of RAM was fully negated by adding an SD card into the equation – coupled with a small caching layer, this is a crucial part for the project’s not-so-secret sauce. A fair amount of debugging and optimization later, [tvlad1234] got Linux to run, achieving boot times in 10-15 minutes’ ballpark – considering the emulation layer’s presence, this is no mean feat.
At this point, the boot process stalls as you enter a login shell. If Linux on RP2040 is within your area of interest, feel free to pick up the effort from here, as the project is fully open-source – you only need a Pi Pico board and a throwaway SD card! Now, if pairing a RP2040 with some classic software is your definition of an evening well-spent, you can’t go wrong with DOOM! However, if you’d rather play with something else *nix-like, we’ve seen someone port Fuzix onto the RP2040 before.
Someone had to do it…
“The boot process takes 10 to 15 minutes, after which a login shell will be presented.”
LOL
yeah that’s how it goes with such emulation, and, given the extra layers like “SD card as RAM”, this is seriously impressive! the Linux-on-AVR project had 3-hour long boot, if I’m not mistaken – at least, that’s how long the video goes.
Too bad ROM technology is no longer available.
Back in the 80s, it was possible to execute an operating system like TOS (Atari ST) or MS-DOS (DIP DOS, Atari Portfolio) directly from ROM.
The main difference here is, that no copy operations were required.
TOS did directly access the memory locations in ROM, no files had to be loaded through a file system.
Settings could be stored on a mass storage medium, though. External drivers could be loaded, too.
If Linux wasn’t such a static, monolithic something, it could be executed directly from ROM, too.
Without needing much RAM for operaton.
Again, the ingenious difference is the ability of direct execution of code from ROM vs copying stuff from an image onto a RAM drive.
It might be possible to start Linux in a virtual machine, take image of all executable pages and store them in ROM. Anything that gets modified after boot would have to be remapped to RAM using MMU (real or virtual)
XIP it’s called (Execute In Place):
https://james-hui.com/2021/07/09/building-another-small-uboot-xip-linux-for-arm-cortex-m4/
You don’t know what modern ROM technology looks like (memory mapped SPI NOR etc), don’t know how Linux works or that it actually supports running in-place… but TOS, an OS that could do almost nothing is totally awesome.
The problem with some dinosaurs, is the lack of update features + their loud certainty then still are up to the game.
I do know that Linux doesn’t work as elegant and modular as Minix, which is good enough for me know. 😉
Seriously, though, why do you guys constantly assume to know something about strangers? Or go down on a personal level? Or talk about people in third-person if you reply to them? I don’t understand why you guys enjoy this so much.
For the sake of it, I mentioned old TOS here because it’s not file based, at least not the ROM code. It can use files, of course. In Unix and unixoide systems, “everything is a file” by contrast. And using “to ram command” was often used for booting from live CDs, too.
Have a nice day, everyone. And don’t get old and grumpy. 😇
>For the sake of it, I mentioned old TOS here because it’s not file based,
>at least not the ROM code.
you wot bruv?
“you wot bruv?”
Um, you’re okay, man? 😟
I meant to say: OSes like TOS looked for their code / for their sub routines at specific memory locations, rather than opening a file on a storage medium first each time and then executing them from there.
There was no memory fragmentation, also, because free memory didn’t have to be allocated first. The code/the sub routine simply was “there” – fixed, right from the start.
That way, no to little RAM was involved. The code ran directly from ROM itself.
Like the PC BIOS and its option ROMs, did, originally – later on, in the Pentium era, AT BIOSes were compressed and had to decompress themselves in RAM first. But since they were comparably small (vs Linux), it didn’t cause much of a delay.
Briefly we used to use NOR flash for booting because you could could execute out of it like ROM and support useful features like XIP (execute in-place). But NAND densities skyrocketed compared to NOR and in practice having to buy two chips is more expensive than doing everything on one chip.
As a stop gap, there have been NAND flash backed devices that appeared as SRAM or ROM. They fill a niche for embedded, but in volume they aren’t worth the price. If you really want to, you can take an RP2040 or Teensy, and bit-bang your old ROM socket to have a nice SD card backed in-circuit ROM emulator. Would be a fun project that I don’t think would be all that difficult to pull off. I’m tempted to do it myself to make developing a new ROM for this old Z80 word processor I have. I hate the original OS because it has a terrible user interface, but the hardware is nice. (Tandy WP-2)
Under the hood, both the microcontroller emulation and the products that mentioned above are doing the same thing. Load blocks of NAND into a RAM based cached. Serve data out of RAM. And optionally write back if that is a feature requirement.
Thank you very much! Your explanation of the matter was excellent, I think! 🙂👍
>I meant to say: OSes like TOS looked for their code / for their
>sub routines at specific memory locations,
Run nm on a vmlinux file and see what it looks like…
>rather than opening a file on a storage medium first each
>time and then executing them from there.
Ya wot? Linux itself it just a blob that is in memory somewhere because a bootloader put it there. Applications are mmap and whatever filesystem they are stored on is responsible for making sure the pages are filled before the CPU gets there. If the pages are accessible from the CPU address space you can do XIP there too (see AXFS)
>There was no memory fragmentation, also, because free memory didn’t
>have to be allocated first.
wot?
>The code/the sub routine simply was “there” – fixed, right from the start.
wot?
>That way, no to little RAM was involved. The code ran directly from ROM itself.
Like XIP. I mean .. wot?
>Like the PC BIOS and its option ROMs, did, originally – later on,
whaaaaaaat?
I’m sorry, my friend, but I don’t understand your English.
Likely, because I’m not a native speaker and thus not up to your level of skills. My dearest apologies. -Your humble servant.
You seem to know stuff, but you don’t seen keen on explaining…
This is not my field of expertise, and I wouldn’t mind some explanation on what the other commenter said.
I suspect that comparing a multi decade old os to a modern Linux is not pertinent, and that if Linux had the capabilities of such a vintage os, it could do similar stuff, but I don’t get why booting from rom would be bad?
Don’t hesitate to elaborate, even if in a succinct form, we all gain from sharing knowledge, friend!
>You seem to know stuff, but you don’t seen keen on explaining…
You know when someone is so wrong that they are beyond wrong and into a whole new extreme of wrongness? Those people are impossible to explain anything too. The fact that they are comparing Linux to TOS like they are even in the same universe is a big hint that we aren’t dealing with normal levels of wrongness here. TOS was literally a piece of crap when it was released in the 80s.
>I suspect that comparing a multi decade old os to a modern Linux is
>not pertinent, and that if Linux had the capabilities of such a vintage os,
>it could do similar stuff, but I don’t get why booting from rom would be bad?
They seem to have convinced themselves that TOS running from ROM (ROM was just a block of data mapped in the CPU address space so running code from there isn’t anything space) is something TOS can do but Linux can’t when if Linux couldn’t run from somewhere in the CPU address space it wouldn’t work at all.
They seem to think the Linux kernel itself runs as a file from a disk. Potentially your Linux kernel could be stored on disk as a file but it gets loaded into memory and runs just like TOS running from ROM. Even modules (loadable parts of the kernel i.e. drivers) are not loaded as files in the kernel. An external tool loads the file and gives the kernel a blob of memory. The kernel itself seems to try avoid dealing with files as much as possible and mostly delegates dealing with smelly files to userspace processes if possible.
Ok, so Linux can run as a blob of memory. Can it do the magic thing that TOS does and run from a read-only memory… yeah it can. You can configure it to run in place from ROM only memory if you really really want to do that. You still need to have writable memory somewhere else but TOS also needed that.
Some ARM SoCs even have support for memory mapped SPI NOR flash (CPU reads data, hardware turns it into SPI commands transparently). So if you really really wanted you could run Linux directly out of SPI NOR.
If you have more than a few megabytes of memory you put the kernel there as it makes your life easier.
Should have used my mips emulator instead (uMIPS). it is written in thumb assembly, with SPI SRAM it achieves a 1-minute boot on a 80 MHz cpu. on an RP2040 wirth PIO for mem access and those fast RP2040 CPUs i had it booting in ~10 sec. 10-15 min is criminally inefficient.
Hi! Thank you for your feedback. I have considered using uMIPS but I wasn’t very comfortable with using assembly straight away, I will try to use it in the future though. As for the RAM, I didn’t have an easily accessible source of SPI RAM, hence the SD card hack.
How big can these SPI RAMs get? Because a modern kernel easily eats ~12 MBytes from that and then complains about not enough memory for the userland.
Background why i ask, i toyed around with Open Computers 2, a Minecraft Mod that adds computers with RiscV emulation that runs a real Linux inside that emulation. And with just 16 MB in the system it refused to boot.
You can get 8MB 133 MHz SPI SRAMs for under $2 when they’re in stock.
Yeah, but what is the maximum? I know of 16 MByte, are there higher ones available or would one need to cheat with multiplexing for getting at least 32 MByte?
For a generic 3.3V SPI as I seen – maximum is 512MBit(W25Q512JV).
If you want something cheaper – get modern motherboard from scrapyard, they mostly have 1.8v 256MBIt ICs. But you want spend money on new parts and deal with custom PCB for BGA – you can get S79FL01GS, thats 1024MBits for your needs. Also comes with some neat security features as well as hardware 1bit-ECC(You will need it for 128MB).
I thought about doing something similar, but using multiple Pico’s. One pico to be the registers, one to be the ALU, etc. Then use a Pi4 to just pretend to be memory and I/O. I’ll probably never do it, but it was a fun thought.
Sipeed Maixduino MCU with ESP32 Module on Board for RISC-V AI + IoT runs 64-bit RISC-V for ~$ 50. Anazon.
Yep, one can throw money at a problem to solve this.
Or have fun doing the impossible with hardware for under 10€.
Speaking of throwing money at a problem, Ox64, 8$, runs Linux natively.
Why don’t you have the option for a light theme? White on black really hurts my eyes. I have to use a plugin to read your website.