Linux on an 8-bit micro? (2012) | Hacker News Reader

Linux on an 8-bit micro? (2012)

dmitry.gr

152 pointsbootload53 comments

See also ELKS, which can run an (extremely stripped down and extensively rewritten) Linux kernel on a 16-bit 8086:

http://elks.sourceforge.net/

Also Fuzix, which can run a Unix-like on a variety of tiny, ancient processors like the Z80 and 6809; I've ported it to the MSP430, a modern micontroller, and I also have a half-finished port to the Raspberry Pi that I must get round to fixing one day (hilariously, the Pi has more RAM than Fuzix can handle)...

https://github.com/EtchedPixels/FUZIX

Both of those run natively, of course.

Considering that the first Unix was on a PDP-7 with roughly the same computing power, and many embedded systems are of similar capacity yet also run Unix-likes, it's not all that surprising. (Depending on what you call "Unix-like" --- I'd say any OS with a unified hierarchical filesystem and devices-as-files to varying extents qualify.)

My final project for college grad was a unix-like 8-bit OS called picix, it worked in PIC18 and supported tcp/ip via uIP

https://sourceforge.net/projects/picix/

Hey at least it doesn't take 2 hours to boot :)

I did something very similar, way back in '92, on a 68000 SBC. I pretty much copied the important bits of the Unix kernel, but all in assembler!

Cool project.

Personally I like the idea behind RetroBSD [1] - port of 2.11BSD Unix intended for microcontrollers.

I was thinking if a system like this powered by solar panel would be a good idea for poor countries. The idea is to have computing of the past in sustainable form available for poor. The main problem is probably to have a cheap and low energy display. Maybe epaper made in bulk would be enough? But probably such a computer can only be cheap if made in bulk. Maybe it could be cheaper than RaspberryPi? The question that remains is what about networking? Maybe they could function in similar fashion to BBS, but using shortwave radio?

[1] http://retrobsd.org/

It sounds like you're about to re-invent the failures of "One Laptop Per Child".

The one thing people in poor countries do not want is special weird incompatible systems designed for the poor. They want a solution which is adequately close to the western ones, just cheaper. Look at cellphones: http://qz.com/451844/africas-smartphone-market-is-on-the-ris...

I also think that smartphone will get there faster. Maybe Chromebooks if Google will play it nice, because of Android apps support and normal keyboard.

However I think OLPC is different from what I have in mind. OLPC targeted children with OS designed for children. I am thinking about something more like RaspberryPi with integrated power and display systems, but with external keyboard. Also I think about it to be extremely cheap. $100 laptop is already done by Chromebooks, but it is not cheap enough. It would have to be around $25 or less. It should expose GPIOs like RaspberryPi so it could be used in more settings. It would be black and white and mostly text only. Basically my pipe dream. Maybe I would just like to go back in time sometimes and I am just projecting?

It is just a loose idea, but outside of people's preferences economics of scale are certainly supporting smartphones.

Sure, that's what you'd want; is it what the target market wants? Would people be happy limited to B&W text?

For something like what you've described, the cost is driven by casework, screens, touchscreen components and batteries. Not the processing electronics. It sounds like something halfway between a Kindle with a keyboard and one of the cheap Windows tablets, now below $100. (http://www.dx.com/p/onda-8-v820w-quad-core-dual-os-tablet-pc...)

Maybe something like a PocketChip (https://getchip.com/pages/pocketchip). But cheaper.

Perhaps a cheap phone combined with a cheap, keyboard accessory and bundled software would be better? Definitely include Wikipedia app on homescreen and Python w/ learning guide somewhere on there.

Something about this just gives me joy. It's so ridiculous that it's beautiful.

>Something about this...

I reckon it's probably the SIMM soldered to the breadboard.

It's perfboard. Now, a SIMM soldered to breadboard, that would be something ;)

"It is common to see newbies asking in microcontroller forums if they can run Linux on their puny little 8-bit micro. The results are usually laughter..."

The reason why...

"uARM is certainly no speed demon. 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)."

It is so slow. Btw if you ever ask about system compiles of Elm on RaspberryPi which requires Haskell, you'll get similar responses.

Well, it's not so much that as the fact that Linux requires a 32-bit architecture (and preferably an MMU).

One is better using a programming language with a rich runtime when targeting such processors, but newbies aren't going to search for programming languages with bare metal toolchains.

I wonder if you could write parallelization routines that make this slightly faster with a few more atmels...

Multiprocessor AVR running Linux would be the next step, definitely.

Yea, imagine a Beow....ah, never mind.

Reminded me of Part 4 of https://www.inf.ethz.ch/personal/wirth/FPGA-relatedWork/Comp... . Intellasys/GreenArrays are kind of similar but only with tiny local memory.

Previous HN discussions :

https://news.ycombinator.com/item?id=8791812

https://news.ycombinator.com/item?id=5581851

https://news.ycombinator.com/item?id=3767410

Chrome gives some ssl-shaming for this site that I haven't seen before. An angry red warning and text that says "This site uses a weak security configuration (SHA-1 signatures), so your connection may not be private."

I'll take a look.

Didn't mean to throw shade, was just intrigued by the new blinkenlights on my screen.

https://security.googleblog.com/2014/09/gradually-sunsetting...

> That’s why Chrome will start the process of sunsetting SHA-1 (as used in certificate signatures for HTTPS) with Chrome 39 in November. HTTPS sites whose certificate chains use SHA-1 and are valid past 1 January 2017 will no longer appear to be fully trustworthy in Chrome’s user interface.

was reading about instruction sets a couple of hours ago, the performance bottleneck is often the memory pipeline not so much the size of the instructions

Can you give more information on that?

it takes longer studies - but possibly this is a good start https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-...

I don't know if it's a joke, but it's hilarious.

More like Linux on 32-bit ARM, but running in an emulator on an 8-bit processor. I don't think this qualifies as “Running” Linux on an 8-bit processor.

I voiced the same complaint when somebody claimed to “run” Windows 3 on an Apple watch (IIRC), which also was achieved by running a standard PC-hardware emulator, and running Windows 3 on that.

These are somewhat interesting accomplishments, but the click-bait factor is high.

So Linux isn't 'running' on your x86_64 cpu because cpu is microcoded... or transmeta? Or... Linux is written in C.. so it's not running on your computer because it doesn't execute C directly?

Come on. There is a 8-bit microcontroller running a linux system, the rest is implementation details and semantics.

I think the argument is that one would expect "Linux running on architecture Foo" to imply support in Linux for Foo, rather than support in Foo for Linux that allows Linux to run unmodified. I certainly expected, when I clicked, to read about someone's effort to rewrite a minimal subset of the Linux kernel to use exclusively 8-bit registers and no MMU.

Linux can already run on MMU-less systems (CONFIG_NOMMU). GCC already supports AVRs, though you may have to tweak the backend a bit so ints are 32-bit wide etc.

These are not the big issues in porting the Linux kernel to an AVR. The major problem is that AVR is Harvard architecture and there's probably tons of assumptions in the kernel that code and data resides in the same memory space.

- also ATmega1284P and ATmega644A mentioned in the article doesn't support external code memory nor changing the code memory after boot. However they do support a boot loader that can load code initially. So you would have to implement some sort of paging by resetting the cpu to give control to the bootloader to load the new code. Sound like fun. Also the kernel itself is far too large to fit in code memory, so it would constantly have to page parts in and out through this mechanism.

Fair enough, I didn't read the comment in terms of adding arch specific support in linux.

I wouldn't exactly call it click-bait.

The crux of both the article and the accomplishment is writing an 32-bits ARM emulator that works on an 8-bit machine.

Definitely not child's play, and a valid route to run Linux on 8-bit.

Rhetorical question: If writing the emulator was the “crux”, then why doesn’t the headline mention it? Why isn’t the whole article about it? I would certainly have upvoted and whole-heartedly lauded a story entitled “An 32-bit ARM emulator for an 8-bit CPU”.

Instead, they used the headline and article content to heavily imply to actually have ported Linux to an 8-bit processor. It’s not until into about half the article that they reveal the emulation bit. Therefore, click bait, pure and simple.

There is some wonderousness that they completed the emulation enough to run something complicated like linux.

Its very easy to use something limited, say a HP48 in RPN mode and some arrays as "memory" and variables as registers to implement a couple opcodes of say a 68hc11. I did that around '93 or so when the 'hc11 was contemporary (its ancient history now, but it was kind of a 6809-like microcontroller with pretty good specs for the era)

On the other hand its hard to get a complete emulator working of everything, or at least close enough to everything to boot a major software project on top of it.

Sort of like implement a system/360 emulator that only does opcode ADD, well, ok cool, but when you can boot MVS/360 thats a whole nother level of wow.

Sure it’s a cool emulator. Which is why they should have led with that. But they implied they did something else and waited until half the article to even mention the emulator.

I think it's actually more impressive that this runs linux by emulating a 32-bit ARM on an 8-bit processor!

Indeed! It is also a nice real-world analogy to the idea of a Turing machine. As long as the machine can advance and rewind the tape, and read and write to the tape, it can accomplish any computational task...

I'm with you on the title and such. I thought it was a port of Linux to 8-bit with something like uCLinux. Then I saw it was a project emulating a 32-bit CPU to spend 4 hours booting Ubuntu. A cool accomplishment but not what title made me think.

Just because you can, doesn't mean you should..

Very cool (TL;DR: it's an ARM emulator for 8-bit AVR which can slowly boot Linux). Could do with a [2012] tag in the title.

done.

Why are people TL;DRing a lot of posts recently? Surely on HN, the joy is in discovering the linked content themselves surely?

If you don't have time to read HN, and need TL:DRs then you should question why you are here in the first place.

Vote down if you like, I joined HN to get away from inane commentary and TL:DR nonsense that's so prevalent on other sites.

as much as tl;dr is increasingly irritating when used in this way, baiting downvotes is also not cool.

could you explain why is it irritating?

I'm not baiting down-votes. Far from it. Just voicing that TL;DR is annoying. There's a reason you can't have both text AND a url in a HN submission - it's to encourage people to actually visit the link.

Next, we'll have people just copy-pasting the entire article body as a comment ... :(

> it's to encourage people to actually visit the link.

You read the links? I'm just here for the commenting. If the comments imply the article is good enough I'll read it.

(This effect used to be very strong on the Guardian's commentisfree site, where the top comments often contained valuable correction/context to the tritness of the article)

> Next, we'll have people just copy-pasting the entire article body as a comment

I've seen that done a few times; it's useful if it's paywalled/adwalled/unusuable-crashy-javascript-walled.

I find tl;dr to be extremely useful to find out if the article is worth reading or not.

There is no joy in being fooled by a clickbaity title. Also, HN is not a novel book, therefore I do not feel spoiled. I always silently thank people that write tl;dr. They try to save my time.

Exactly. I would happily read about some working 8bit port of Linux, but this thing here is just useless gimmick, compared to what it claims to be.

I somewhat agree; TL;DR can seem dismissive and certainly discards most of the value of the actual article.

In this case I did it because the title made me wonder if this was the article I read years ago about implementing an ARM emulator for AVR to boot linux. I clicked through, confirmed it was, and that it was a 2012 article. I figured I'd leave the TL;DR as a shortcut for others to confirm they've already read it, not as a replacement of the article for those that haven't.

Reply on news.ycombinator.com