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 :)
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"
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.
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.
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".
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.
> 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.
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.
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.
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.
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.
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.
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.
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 :)