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.
Linux on an 8-bit micro (2012)
11–20 of 47 posts
Re: Linux on an 8-bit micro (2012)
#12Related (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.
Re: Linux on an 8-bit micro (2012)
#13While 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 :)
Re: Linux on an 8-bit micro (2012)
#14Because 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.
Re: Linux on an 8-bit micro (2012)
#15Re: Linux on an 8-bit micro (2012)
#16I 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?
Re: Linux on an 8-bit micro (2012)
#17This 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 :)
Re: Linux on an 8-bit micro (2012)
#18https://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.
Re: Linux on an 8-bit micro (2012)
#19Does 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 act…
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.
Re: Linux on an 8-bit micro (2012)
#20Unbelievable 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?
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.