GNU/Linux Running On An 8-Bit Processor

dartttt writes, quoting Ubuntu Vibe: "Dmitry Grinberg has successfully booted Ubuntu 9.04 on an 8 bit micro machine with 6.5 KHz CPU and 16 MB RAM. Grinberg did this experiment on a ATmega1284p, 8-bit RISC microcontroller clocked at 24MHz and equipped with 16KB of SRAM and 128KB of flash storage. Since the RAM was too low, he added 30-pin 16MB SIMM to the machine and a 1 GB SD card to host Ubuntu image. ... To get the world's slowest Linux Computer running, he had to write an ARMv5 emulator which supports a 32bit processor and MMU. A similar machine can be made very easily and everything should come in about $20." There is source code available, but it's under a non-commercial use only license. Just how slow is it? "It takes about 2 hours to boot to bash prompt ('init=/bin/bash' kernel command line). Then 4 more hours to boot up the entire Ubuntu ('exec init' and then login). Starting X takes a lot longer. The effective emulated CPU speed is about 6.5KHz, which is on par with what you'd expect emulating a 32-bit CPU & MMU on a measly 8-bit micro. Curiously enough, once booted, the system is somewhat usable. You can type a command and get a reply within a minute." If you like watching a whole lot of nothing, there's a video of the boot process below the fold.

Comments

Re:Ultimate tech hipsters

[Anonymous Coward]

You mean, you bought the latest nokia?

Reminder: this is /. , all people will want to know is: but does it run linux. Since your nokia apparently is unable to do so, this article proves the 8-bit processor superior.

Have a nice day.

Sometime tomorrow...

[Anonymous Coward]

They'll submit "FIRST POST"

We could ...

[PPH]

... build a Beowulf cluster of these!

Re:We could ...

[jd]

Already done. One of the earliest supercomputer-grade clusters was a gigantic mesh of 65C02 processors. You'll need to come up with something better.

Geoworks

[Daniel Phillips]

Nice trick. However, let me point out that in 1990 Geoworks GEOS was capable of running a preemptive multitasking GUI looking much like QT but with better automatic widget layout, on an 8 MHz 8088. I will just heave a great sigh in the name of the lost art of tight coding. No, Linux is not tightly coded. I should know. The best you can say about it is, the other guys are worse.

Re:Geoworks

[Ichijo]

No, Linux is not tightly coded. I should know. The best you can say about it is, the other guys are worse.

Not MenuetOS. It's an operating system with a graphical UI, pre-emptive multitasking, and USB and TCP/IP stacks that boots from a single floppy.

Re:Geoworks

[david.given]

I wrote some code for it: see here (including a Linux86 execution environment, that would allow you to directly run Linux86 binaries from GEOS, that I was really rather proud of).

I can sum up the coding experience with the phrase: THE HORROR, THE HORROR.

In order to write code for GEOS you needed a monster, badly written and badly documented SDK and a copy of Borland C. The actual code you wrote was in a C superset called GOC, which was compiled via a buggy preprocessor into incredibly cryptic C, which was then compiled with Borland and linked with a custom linker. Alternatively, if C wasn't your thing, there was an object-oriented dialect of 8086 assembler available. The OO system was bizarre, and allowed for classes to have unspecified superclasses, where the superclass was determined at run time: the system used this to great effect in the UI, where the app author's generic UI was turned into a specific UI implementation for the device. The C bindings were full of bugs, too, including function calls which didn't save all the registers properly...

The actual architecture exploited the hell out of the 8086 segmentation architecture. Memory was organised as a set of relocatable blocks which were referred to by handles (which, under the hood, were usually segment descriptors). To dereference the memory, you had to lock the block, do your manipulation, then mark the block as dirty if you had changed it, and unlock it. The lock/unlock procedure allowed the system to ensure that the block was in memory, by paging it in if necessary, either from EMS RAM or disk. It was incredibly, utterly, un-Posix, and a complete pain to do anything in. The learning curve was insane.

Where GEOS really did well was the application stack, which was subtle and elegant. There was a mechanism to allow you to use a file as a heap backing store (using a very similar but annoyingly different API to the block API described above, but that's not really important). The system automagically loaded and saved data from the file as you locked and unlocked blocks. There were standard components for everything up to and including a complete bitmap paint package, a vector drawing package, and a word processor --- and these all used these file heaps as storage. And, of course, you could have multiple components in the same file. OLE! But done right.

By today's standards, of course, it's all a huge pile of incomprehensible, unmaintainable cruft, all inextricably linked to 16-bit 8086 code. It wasn't just utter mismarketing that killed GEOS: it was the inexorable march of time. It was simply unable to adapt to the 32-bit world. All the clever tricks they did to get decent performance out of an 8086 were liabilities on more modern hardware.

That said, towards the end, when Geoworks was in its death spiral, they did produce two different attempts to rewrite GEOS for 32-bit RISC processors: GEOS-SE and GEOS-SC. I know absolutely nothing about these other than on the wikipedia page, and if anyone has any info, I'd be fascinated to hear about it.

Re:Why?

[Penguinisto]

Why not?

Seriously... the skills and knowledge can come in handy someday.

Maybe someone desperately needs to retrofit modern code to crappy old equipment? Maybe the ultra low power requirements of an extreme low-end machine makes this a fit somewhere?

Most importantly though, he did it because he could. Doing it puts his skill set far above that of most people, and having that on the resume would get him in good with nearly any semiconductor corp on the planet that needs a software or firmware developer.

No it won't.

[pavon]

No version of windows ever ran on an 8-bit processor. Windows 1.0-3.0 would run on an 8086, but that is still 16-bit, and Windows 3.1 won't even run on that, it needs a 286 or higher.

Re:75 MHz 286

[kwark]

What 286 ran at 75Mhz? Only 486 cpus ran at those speeds. And AFAIK Debian never had a kernel for non 386 80x86 CPUs.

Re:Ultimate tech hipsters

[wagnerrp]

That's simply not true. Those little 8-bit microcontrollers are used all over the place. You probably have several in your desktop, some in your monitor, more in your TV, a whole bunch in your car. You just never see anyone trying to run one as the primary CPU on an interactive computer these days.

Re:Why?

[Captain Spam]

You are aware that the 80386 processor (what Windows 3.1 was designed for), which was 32-bit, was first released in '85, right?

Note to a specific age group of Slashdot readers: You are aware exactly how old that fact I just presented makes us feel, right? *sigh*

But does it run...

[Qubit]

...oh wait, I see what you did there.

DMV

[j00r0m4nc3r]

Let me guess, the DMV ordered 1000 copies..?

2 Hours? That is fast!

[DarthVain]

"slowest Linux Computer running"...

I beat that score by a large margin. Years ago I took an old 386 Laptop that ran at 25Mhz, I don't recall how much ram it had, but I am going to go with "not much", and booted DSL (Damn Small Linux) in just over 21 hours. Which is over 10x as slow as the one in the article! So technically I think I had the "slowest Linux computer".

Why did it boot so slow? Well it was also the reason I used DSL, because it was less than 50MB, and I could fit it on a Zip drive. Attached via a parallel cable. It did work, and it did eventually boot, however I had to leave it over night (I thought it would eventually just crash), but it worked its way through. Also on a fun note, when typing and executing commands it was like telneting to the moon, there was like a 4-5 second delay between typing any command hitting execute, and any sort of result. I really just wanted to see if it was possible to install and run an OS on a zip drive connected via a parallel port. The answer is yes, but not very well.

Re:Why?

[SomePgmr]

Just ignore the trolls. ;)

"Why do you want to climb Mount Everest?"

"Because it's there" ~ George Mallory

Re:Why?

[jd]

Alternatively, someone might want to design a new 8-bit CPU for certain embedded tasks where it's essential for there to be low power consumption and a high-end sophisticated OS. There are plenty of extremely slow mechanical operations (combine harvesting, for example) where millisecond responses are not going to be useful but where the complexity of the problem (varying evenness of the ground, varying field shapes, etc) mean you do want to be able to handle many different types of sensor, sophisticated algorithms, etc, within something that needs to be extremely cheap to build/replace and extremely low power to run to be more cost-efficient than having a farmhand (who is likely to be earning minimum wage or below).

Another option is a System-on-a-Chip. At present, SoC runs into all kinds of problems because of the compromises you have to make to fit everything into one die. If you can reduce the transistors of the CPU component, you can increase the transistors somewhere else, which means this knowledge increases your flexibility in such systems. That's extremely valuable to know, even if you never go to this extreme.

For deep space probes, radiation is a major concern. Well, for anything in space it's a major concern, but the deeper you go into space the nastier the radiation. It's why the highest-end space-rated CPUs are so primitive compared to commercial CPUs. Being able to reduce the complexity of the CPU and utilize the extra space for redundancy, without reducing the sort of complexity of software the CPU will run, is great news for anyone wanting to rival the Pioneer 10 & 11/Voyager 1 & 2 missions in terms of longevity whilst equally wanting to match Deep Space 1 or the Mars Rovers in terms of flexibility. Knowing that you don't strictly need a 32-bit architecture to run Linux and that you can slice out huge chunks of the architecture gives you tremendous power.

Re:I'm almost scared to ask

[fliptout]

If your hobby is 'waiting for stuff to happen', then this is a great project to undertake.

Re:Why?

[dmitrygr]

I was bored :)

Re:Why?

[dmitrygr]

It's up to 10 KHz now that i've optimized RAM access (new code up later today)

Re:Why?

[icebraining]

There's an objective valuation of time that I'm not aware of? Or are you just saying that because you don't find it a valuable use of time?

Re:My 0.02

[dmitrygr]

I do plenty of other things (flying planes, collecting speeding tickets, etc). This was just for fun. And it was quite fun. I never expected it to be fast enough to use, and am still quite amazed that it is usable (for some definitions of "usable")

Re:Ultimate tech hipsters

[Dzimas]

I design musical synthesizers using Atmega MCUs. They work really well as controllers in price-sensitive consumer applications, but booting linux on one is about as sensible as fixing your car with a spoon.

Re:How much more...

[dmitrygr]

I don't use a SIMM for the JVM project - but I am going to release a fully working(threads, synchronization, exceptions, interfaces, all the datatypes, etc) JVM for AVRs soon

Re:Funky specs... 6.5KHz? Really that slow?

[dmitrygr]

1. the emulated cpu *effective clockspeed* averages 6.5 KHz in released code (10KHz with better RAM code, that i am releasing later today)
2. Site is still up (it occasionally hic-ups with a 4xx ot 5xx HTTP error, but mostly it is still up
3. the linux ram is a 30-pin SIMM of 16MB capacity, the interface to which (incl. refresh) I bit-banged using 3 8-bit IO ports. The AVR's internal RAM is used for emulator SoC state, AVR stack, and the icache

Re:Why?

[batkiwi]

The question is not "why make an 8-bit cpu and run stuff on it". The question is "why load linux on an 8-bit cpu where it's unusable?".

There are tons of embedded 8 bit processors, and all can run very complex software written in c/c++/etc.

I think this is cool, but the answer is simply "as a challenge." The microcontroller problem, and making it either powerful or easy to use, has been solved for years and is evolving. Running linux on them was never what was holding them back.

Re:Why?

[hamster_nz]

He was waiting for his Raspberry Pi to arrive, so had time to kill.

Re:Why?

[martas]

And waiting for 4 hours for ubuntu to boot solved that? ;)
Interesting project, BTW.