Linux on an 8-bit micro

Tried running this on a Toshiba T1100 Plus [1], never did get it working...

[1] http://en.wikipedia.org/wiki/Toshiba_T1100

The intro paragraph of that 2003 FAQ looks eerily like a comparison of smartphones/tablets to laptops might look today!

Well, getting Linux working on a laptop was more a case of exciting driver wrangling, rather than performance limiting.

What does ELKS have in common with Linux? Will it emulate 32-bit for the user-land? If not, I guess it's not binary compatible. So ELKS is not Linux itself (FAQ says so) and it won't run Linux apps? I don't see how they're related...

Does anybody have a copy of the original ELKS homepage with the quote from Linus about Linux not being portable?

It seems not to be in IA.

So you're saying you can't compile Linux to an 8-bit CPU, but you can run an emulator of a much larger chip on that CPU and run linux on that? Are you sure?

> which BTW proves again that Linux doesn't fit onto 8-bit micros.

How in the world does it "prove" that, when not only does it "fit", it fits in addition to an emulator? I don't see that it only runs _under_ an emulator proves any such thing.

While this is obviously a "hah, you think it's impossible? I'll show you," type achievement, and running Linux on an 8-bit is never going to be more than a curiosity, it's a neat proof of concept and could trivially be made much faster (through a hybrid approach: a lot of the Linux code could likely be ported quite easily, and a lot of it could probably also be jit'ed relatively easily (especially kernel-land - a special purpose jit whose only purpose is to jit the kernel would be vastly easier than a general purpose jit, not least because you can take a boatload of shortcuts (e.g. manual translation) in cases where a simple/trivial jit doesn't do well.

I think it's a fascinating solution - people have talked about doing ports to limited systems without MMU's etc. before, and it has usually meant severe tradeoffs that means lots of userland won't work (e.g. vfork instead of fork). This is a d'oh moment in that the "solution" if your goal is only to get a port running (rather than for it to be practically usable) has stared us in the face "forever" (there's been virtualization solutions using emulated CPU's since before Linux was around).

> There are some real ports of Linux for "limited" architectures, like uClinux

reginaldo (a guy who posted his emulator (jslm32) last time this was on HN) actually uses uClinux on LatticeMico32.

[1]: https://github.com/ubercomp/jslm32

I'm considering trying to get this to compile on Emscripten. It's so self-contained that I think it will be fairly unproblematic. Emscripten's 64-bit math emulation surely won't be needed.

Does anyone know if a ARM emulator in JavaScript exists already?

Microcontrollers currently supported by uClinux cost >$5.

One interesting option to reduce the cost is to use a new microcontroller , the psoc 4(starting $1, 32 bit) which includes programmable logic, which might enable implementing the dram interface in hardware and to achieve good memory performance.

> There are some real ports of Linux for "limited" architectures, like uClinux (supporting few 32-bit micros, including some MMU-less ones) and ELKS (for 16-bit x86 CPUs).

But is it actually Linux, or something that was based on Linux but is now so divergent as to be its own kind of thing?

"Oh, it's Linux. It doesn't have most of the APIs, including the ones 99+% of the application software depends on, most of the code is gone, what's left has been greatly re-written, and it will never contribute code back into the mainline kernel."

It's the Ship of Theseus: "This is the original ship. Every plank has been replaced at least once, the sails are all new, and all of the rope was replaced last month."

I was impressed by it.

    This project is "only" a cool ARM emulator with
    software DRAM controller, which BTW proves again that
    Linux doesn't fit onto 8-bit micros.

But it does, for practical purposes. I'll try to put into context with a practical story -

There's a global apocalypse happening tomorrow.

There's a sealed bunker beneath my author's house that will survive. It contains one of these microcontrollers, a keyboard, specifications for a daisy wheel printer that hooks into the debug port and a big stack of paper, and a row of bicycles connected to a alternator to power it all.

There is a post-it note stuck to the controller that says "pwd; /usr/bin/ls; cd /; /usr/bin/ls; man man; man ls; man ed;".

Decades from now and by chance, Benedictine monks will build a monastery, and the bunker will be within its generous grounds. In time they will discover the bunker, and take turns getting fit while others they learn to use the system. They're a disciplined, careful bunch, particularly around commands like rm.

Out of concern for the reliability of storage media, one of the hackers will set up a RAM disk and migrate the system over to this. The abbot will declare that pedalling is a leisure activity so that they system will never again need to reboot.

Though their diligence, the art of unix hacking will live on.

A thousand years later, an opaque glass bottle will break free of the ocean, and wash up on a beach. Bizarrely, it will contain well-preserved code printouts from an entry in the 2013 7-day roguelike competition. It will be marked up in pen, to highlight the author's flamboyant use of obscure system calls, particularly those that are specific to the linux kernel. A convenient novelty of the game is that (unlike rogue) it is one-dimensional - a player can walk left or right on a line, and a new line prints out each time they move.

A copy of the source will eventually find its way to the monks - still pedaling furiously to keep their RAM disk alive - as they take an interest in anything that refers to linux. They will type in the code, and then throw it at a compiler. It will all work. This is the last computer left on the planet, and the reason that the code can be compiled to run on the computer with no modifications is because - for practical purposes - it's linux that's running on this 8-bit micro.

Second this. And this probably also speaks a lot for Linux - okay, he emulated a supported system, but given the problems that one sometimes experience when trying to run the same application on different machines with slightly different hardware or software installed, I find it quite amazing that Linux actually boots on this device.

He's more on the side of genius, but less on the side of practical. I think he'd do really well if he tried a startup with someone who could help push him in the direction of building things with more practical use.

This is nothing unusual for W95.

http://support.microsoft.com/kb/138349

Slightly closer to the original topic, here's Windows 95 running on a Nokia N900: http://www.youtube.com/watch?v=TxMYuCHxBgE

I personally remember running Windows 95 on a 33MHz laptop, although it had a Math Co-processor to be fair. :P

Back in the time, there were even hacks to run Windows 95 in safe mode on 286 machines. 386 with 4 megs was the official minimal requirement.

An 8088 was a 16-bit cpu with an 8-bit bus, so it was slower (and cheaper) but ran exactly the same code.

I don't think there's any graphical usability whatsoever, as the only output is a serial line. He only mentioned X and GNOME to emphasize the fact that it can be started.

hahaha, this comment is hilarious. The guy got an 8-bit tiny little 55 cent chip (8 bits means an isntruction is between 0-255) to slowly crawl its way through pretending to be a real mdoern CPU by pretending to execute a real modern desktop CPU instruction every few cycles.

He got it to starting up x in a day and you're like, "Cool project bro but I'm dsmayed by the choice of GNOME".

saying it, "detracts from usability." this is just hilarious.

such as?

- dmitrygr

For that you have UZIX (http://uzix.sourceforge.net/) or the predecessor UZI.

just compile, hook up ram, and run :)