This is seriously awesome. I take special care to upvote these kinds of projects, as they embody the hacker spirit: hack something that has never been done before in an awesome way, and to hell with practical value!
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...
All that's left is that pesky 32-bit CPU & MMU requirement. Well the AVR has no MMU and is 8-bit. To conquer this obstacle, I wrote an ARM emulator.
So technically it's Linux running on a 32-bit "macro", just one which happens to be implemented in some seriously inefficient manner.
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).
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.
> 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).
I meant the external DRAM thing - this chip would never be able to run Ubuntu without external RAM and bit-banging DRAM in software is more akin to "crawling" than "running" to be honest.
But yes, in a sense, you can run Linux on 8-bit micro or even a sufficiently long Lego brick Turing Machine.
So? It's not the first system to rely on software support for memory refresh. And many 8bit and even 16 bit systems relied on the CPU for other tasks that are usually offloaded to external chipset these days.
The ZX-81 ran the display. The C64 controlled the tape drive directly. The Amiga, which had a long list of support chips, still had the CPU directly handle decoding of data from the floppy.
It affects performance, sure, but if you're trying to shoehorn Linux onto an 8bit embedded CPU in the first place, you're not doing it for speed.
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.
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?
I started writing one in Dart a couple of days ago, but I know others already exist, including ones that port existing emulators (such as QEMU) using Emscripten.
Oh, absolutely. It's not like I'll use it for anything other than saying, "Hey, look at RISC OS running (slowly) in a browser!", which is the end goal.
I think it would be more trouble than it's worth to take an x86 emulator and try to make it do ARM as well, unless it was written with multiple CPU types in mind in the first place.
But more importantly, it's written in JavaScript -- this is an exercise in learning Dart.
I do refer to various C-based implementations from time to time, though.
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."
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?
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.
I've done plenty of practical things a while back (palmpowerups in PalmOS days) but nowadays I am relaxing (I work at Google and I fly planes for fun). I'll go back to doing practical things with a purpose in a year or two :)
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.
I was puzzled at first when I saw the license. Who would be interested in this commercially?
Then I realized the interesting thing isn't to run Linux, but some other more lightweight code that depends on the 32 bit arm architecture, but would run just fine on an 8-but micro, performance-wise.
What were the limitations and hacks involved in this? I mean, parts of W95 (certainly including explorer.exe) were 32-bit so either they had to be disabled/replaced or the kernel extended with an 80386 emulator.
Awesomely cool project, but I was somewhat dismayed by the choice of GNOME, as GNOME is quite bloated and a smaller window manager, instead of a DE, seems to make more sense while not detracting from usability.
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.
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.
I'd get rid of the non-commercial requirement, but I guess you have a reason for choosing it. But it causes incompatibilities with GPL'ed software for example, since the GPL requires commercial to be allowed.
Creative Commons has a nice license chooser, if you want a proper licence with the restrictions you currently have: http://creativecommons.org/choose/ For example the BY-NC-SA (attribution, non-commercial, share-alike) license is pretty much what you have currently. It is still GPL incompatible, however.
Given a choice between the fun of 8-bit programming and the stodgy functionalism of a mere OS? hmmm... let me think. (1MHz @ 4 cycles/instruction = 250K instructions.)
