Linux on an 8-bit micro (2012) | Hacker News Reader

Linux on an 8-bit micro (2012)

dmitry.gr

125 pointspant44 comments

This is from 2012. Previous discussion: https://news.ycombinator.com/item?id=5581851

While this is amazing, this does prove that it is probably impossible to run Linux in 8-bit micro without such contortion. Any Turing-complete machine with enough storage and memory can simulate ARM, and also ARM Linux. So don't use this as an argument for using a normal Linux in such platforms :)

And here's the previous previous discussion: https://news.ycombinator.com/item?id=3767410

That's amazing. I wouldn't even know where to start on something like this:

"As you can see, there is an antique 30-pin SIMM memory module on the board. These were in use for 80286-based PCs. It is interfaced to the ATmega, and I wrote the code to access it as well as refresh it within spec (SDRAM requires constant refreshing to avoid losing data)."

Though 300kb/s is (much) slower than a hard disk, which is hard to imagine...and the result: "It takes about 2 hours to boot to bash prompt"

It's been a while since I last saw a boot take longer than a split second on "Uncompressing Linux..." :)

This is probably one of the crazier projects I've ever seen. I've often contemplated what running a "true os" on an 8 bit CPU would entail, and TBH the idea of an emulator never struck me.

On top of that, a hand-wired linux computer with hand-written arm emulator? Ridiculous.

Well, you could run CP/M on an 8-bit system, which would have been called a "true OS" at the time it was written and sold ...

Or if that's not "true" enough, Xenix was a Unix for 8-bit systems.

Xenix ran on 16-bit systems.

Oops! Yes. 16 bit. I was thinking of the 8 bit data bus of the 16 bit 8088.

What about Micronix? http://www.retrotechnology.com/herbs_stuff/mnix_micronix.htm... - "As far as I know, Micronix was the only Unix-like multiuser system ever to run on an 8 bit processor."

FUZIX and UZIX runs on an Z80

Cool! And it meets the 'multiuser' qualifier too: "UZI180 is a multi-tasking, multi-user operating for the Zilog Z180 family of microprocessors.", from https://github.com/EtchedPixels/FUZIX/tree/master/Kernel .

Wow, great find! Thanks!

Hah, I've actually run CP/M on a DEC Robin! I wouldn't call that a "true os" by my (own, flawed, unspecified) definition because it doesn't have memory protection or preemptive multitasking.

What about RIOT [1], Contiki [2] or TinyOS [3]?

[1] http://riot-os.de/ [2] http://www.contiki-os.org/ [3] http://www.tinyos.net/

Of those, it seems like only TinyOS would qualify (a full userland stack that you can develop from) under the same qualifications that netbsd might qualify....

To be clear, by "true os", I mean a posix runtime, preemptive multitasking with threads and processes, memory protection.

Still, cool links (I'll save that TinyOS for later this week), and I like the username.

Most 8 bit micros don't have an MMU, so you can't have memory protection or virtual memory. That's a hardware limitation.

> so you can't have memory protection

You can if you emulate all memory.... I had never considered that solution before, that was my original point :)

I think you will like NuttX [1] even more :)

[1] http://www.nuttx.org/

I'm not an expert but AFAIK it makes sense: he's using an AVR and that's Harvard architecture, meaning code and data use different buses so all you can run must be in the flash of the microprocessor.

So emulation is a way to workaround that "limitation".

Edit: on mobile, typos

This guy is amazing, look at his projects! Really inspiring.

Related (you may know it already): https://github.com/EtchedPixels/FUZIX

Implementing a VM is an interesting way to workaround some Harvard architecture's limitations as long as speed is not a factor.

> uARM is certainly no speed demon. It takes about 2 hours to boot to bash prompt

Because he's emulating a 32 bit system on an 8 bit system, which certainly takes some brilliant hacking skills, but takes it completely out of the realm of something practical.

https://en.m.wikipedia.org/wiki/Contiki

Runs on 6510(6502) with 64kb on a Commodore 64. While is is cool it would be more interesting to have it run native and not via an ARM emulation layer.

Contiki already runs natively on AVR. https://github.com/contiki-os/contiki/wiki/Avr-platforms

I am not talking about Contiki running on this platform. If your read the story you will see the author wrote an ARM emulator to run on the CPU to the. Run the code. I was staying it would be more interesting if it was native and using Contiki as an example that you can run on an 8 bit Cpu without and MMU.

Well, you can run many things without an MMU, the question is whether it will be at all pleasant to use without an MMU. What makes linux nice is not the fact that it allows you to run code, but it allows you to run thousands of pieces of code at once, stably.

That also worked just fine on Amiga OS 3.1 without and MMU :)

I haven't seen software-based DRAM refresh in a long time. Well done!

Unbelievable proof of concept. It is just genius that this guy made this. But what do you think that we can get out of this? Are there any practical reasons to run Linux on Micro-controller?

> But what do you think that we can get out of this?

One can learn that sometimes it's worthwhile, or even the prudent thing to do, to emulate the hardware instead of porting code. Emulating a 32bit CPU on a 8bit µC is certainly a little over the edge, but it's not unheard of to emulate a legacy/antique CPU on a newer one to make use of proven code.

See for example the ancient HP48 calculators, where the obsolete original device (HP48) is emulated on the contemporary ARM CPU (HP50) to be able to reuse the proven old codebase.

Or you might invent your own bytecode that isn't as intricate as implementing a full ARM computer, but maybe give you amenities like high precision math, or better sting handling, or portability between different microcontrollers (if you are a company supporting several generations of platforms)...

> Are there any practical reasons to run Linux on Micro-controller?

If you don't restrict yourself to 8-bit microcontrollers, you can run Linux on MMU-less Cortex-M3/M4: You loose all the convenience of memory-protection (apps can crash each other by writing in foreign memory space), have severe restrictions in your API (no mmap, restrictions on fork(), memory fragmentation issues, ...), but you gain a very powerful networking stack, filesystems, a LOAD of existing device drivers, ... that you would otherwise have to rewrite for yourself.

> it's not unheard of to emulate a legacy/antique CPU on a newer one to make use of proven code.

It's probably less to do with using proven code and more to do with maintaining perfect bug-for-bug compatibility. You can't even reimplement the bugs you haven't discovered yet. Also, writing an interpreter for most microcode is fairly methodical. Depending on what level of detail you need to emulate (clock timings, interrupts etc) it could be quicker and simpler than digging up an old fossil of a developer who knows enough about the original software to port it for you.

For something like this with fewer layers:

http://en.wikipedia.org/wiki/OS-9

Yes, it's nice, but I only tried it on the Co-Co ver 1 which I thought was pretty terrible hardware.

ucLinux gets you around the MMU problem... Was Linux ever built on 16-bit? The PDP-11 (the origin of Unix) was 16..

ELKS, the Embeddable Linux Kernel Subset, targeted the 16-bit 8086 without an mmu.

That one was one of the best myth buster in tech (not considering the time taken to boot the system!)

Does anyone know why these 8-bit processors are so expensive? The two he listed ATmega1284p and ATmega644a cost like $9.07 (qty 1) to $4.88 (qty 2.5k), and $7.08 (qty 1) to $3.79 (qty 2.5k) on Mouser.

I would have thought we're talking like a $1.30 chip.

Meanwhile look at what you get for $6 - http://linuxgizmos.com/quad-core-allwinner-soc-targets-low-c...

Am I missing something? Or are his 8-bit microcontrollers actually in the exact same price range as an SOC that runs Linux natively?

Looks like 8-bit microcontrollers are actually in the same price range as SOC's that run Linux natively. They have something going for them: easier to understand and use for hobbyists and lower-tech projects, probably easier to interface electrically (are those $6 chips 5V tolerant? Oops, they are not released yet), but otherwise that's another example of an older tech that was left behind. Keep in mind that those Atmel chips were released a while ago, and Allwinner has been the leader of low prices and this is the newest, unreleased chip; also I'm not sure that you and I will be able to buy it, in quantities of 1 (or even 100), when it will be released.

NB: ODROID is been selling a $35 Raspberry Pi-beating board with an Amlogic Cortex-A5 1.5Ghz quad core CPU (Amlogic M805, http://www.amlogic.com/product02.htm, apparently) but I can't find it on Octopart.

They're nice parts; 8-bit micros with a lot of Flash. ATtiny20 is the cheap end with hardly any Flash.

sure, but he didn't get it working on attiny20 :) ($0.57 @ qty 5k) which is what the project kind of looks/sounds like...

The ATMega128... parts are the second-to-largest 8-bit micro that Atmel sells, I think they already have a strange combination of a lot of flash & RAM (for a 8-bit CPU), but not that many, or that complex, peripherals. So they might only be used in (comparatively) low volume in fringe applications.

As an example for "embedded, non Linux" microcontrollers, the lpc1227 (32bit Cortex-M0 @ 45MHz, 128k Flash) is only half the cost (~$2 @ 10k units) at much more CPU power and more versatile peripherals. Probably a much more balanced (and maybe more popular) choice for applications of a comparable complexity...

The part the author is using here is especially odd: it's on the large side for AVR microcontrollers (128 KB flash, 16 KB SRAM), and comes in a DIP package. That's an unusual combination; most microcontrollers that size nowadays are ARM, and are often only available as surface-mount parts.

>>To conquer this obstacle, I wrote an ARM emulator.

So, its still running on an ARM!

No, it's running on a 8-bit microcontroller. Just as a SNES emulator that plays SNES games doesn't magically transform your computer into a SNES.

Tell that to the emulated system :-)

Reply on news.ycombinator.com