Linux on an 8-Bit Micro? (2012) | Hacker News Reader

Linux on an 8-Bit Micro? (2012)

dmitry.gr

192 pointsWoodenChair60 comments

Open articleView on HN

For the curious—2017: https://news.ycombinator.com/item?id=15841241

2016: https://news.ycombinator.com/item?id=12537653

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

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

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

It's a good example of a minimal system, but it's more academic than an example of something that illustrates a useful system. It's arguable whether much could be done with it in real time. There's no TCP/IP stack, and even if networking did exist, most connection types would time out.

I'm interested in the minimal computing resource needed to run a full network stack and recent software. So far, I've run an m68030 with 10 megs of memory and a 16 bit memory bus (Mac LC II) multiuser with networking. 24 megs in a VAXstation VLC is enough to compile plenty of real software. Even a real 11/780 from 1977 can still run sshd and negotiate a connection before a timeout.

I found even a Vaxstation 3100 with the m42 cpu and 12MB of RAM was enough to work with. Sometime within the last five years, I installed NetBSD by netbooting from a Linux mopd server (because I didn't have a working 512-byte block SCSI cdrom). As a computer, it was quite reasonably usable. Not fast by any means. I didn't have anything but a serial console to work with, so no gui. I thought the best thing in the world would have been to browse the Internet on the machine, but I gave up on it because I couldn't Lynx to work.

All of this seems under-powered today, but was actually more horsepower than a comparable PC capable of running Windows 95.

If you ever want to put VMS on that VAXstation 3100 m42, it's pretty neat to play around with. DEC people were sharp, like the Bell Labs and Berkeley people, and did a lot of things differently than Unix did. VMS was perhaps less agile, but more consistent. If you can get hold of VAX C for it, you might be amused to find that some of the documentation for system libraries has examples in BLISS instead.

BTW, don't underestimate an old workstation with only 12MB of RAM: they were often used for technical software that today people might write to require machines with 100x that much RAM.

(I did a little work on the VAXstation, for technical software. I also kludged up a gateway to one, from a TCP/IP LAN, through an Ultrix box that was also on DECnet, since no one had paid for a TCP/IP stack. A lot of important software was optional, little was free, and the printed manuals you could find were precious.)

I fully intend to do so. I have the VAX VMS ISO and hobbyist license around somewhere and have spent a little time fooling with it under emulation. I first used it nearly 30 years ago, and have been missing versioning filesystems ever since. For all of the strengths of Unix-like systems, notably their longevity and versatility, as I think I've written elsewhere on this forum, VMS just seems so much more fully engineered, designed and deliberate in contrast.

(It seems you had a great hack to get VMS connected. Was that used for file sharing only, or could you do more with it?)

.iso is perfect -- TK50 drives are scary in how they operate, and I'd be scared to put a rare tape into one.

I gatewayed remote logins from arbitrary hosts, and I probably used a stock DECnet facility to transfer/share files between a VAX/VMS and Ultrix MIPS box, possibly direct to NFS volume mounted from a SPARCserver onto Ultrix. I think there was at least one NFS implementation (TGV?) for VMS at the time, but didn't have it.

My apprenticeship life in the 1980s was full of TS11 and TK50 goodness - I looked after an 11/750 and a couple of MicroVAXes all running VMS.

I have this bucket list idea of getting the lowest-powered chip I can find that's still fast enough to give me a nice little *nix environment in which I can use Vim, Tmux, and also SSH into things, then sticking it into a laptop shell and filling the rest of the space with batteries.

I wonder if one could achieve like a month of battery life for such a glorified typewriter/thin client.

On a recent project I played around with some SoCs that could do something like this.

I wound up using a Renesas RZ/A1L, it's an ARM-A9 core with 3MB of SRAM on the die. You attach it to an inexpensive quad-lane SPI NOR flash part and it will boot Linux with just those two parts. The flash serves as a filesystem and I believe you can also XIP the kernel off the NOR part if you choose.

We even ran Qt on it with an XGA LCD and it was poky but it worked. It could probably do what you're looking to do.

https://www.renesas.com/us/en/doc/products/mpumcu/doc/rz/r01...

That's probably the lowest-end part I'd say would work for something like this. You can run Linux off a cheaper Cortex-M with some amount of work, but it's not pleasant. The iMXRT1050 does look interesting, though.

https://www.emcraft.com/imxrt1050-evk-board

Stack batteries on the back of a jailbroken Kindle 3G running Debian? Not sure how far you'll get with power management on it. Or using it.

Just curious, what would you use vim for on a device like that? Presumably it won’t be able to do much beyond what you outlined so unless you plan on using it as just a not taking device/typewriter, why not just have an embedded ssh client with tmux?

Pretty much just what you said - when offline, it's just a fancy typewriter that I can also run a simple shell script or two on.

I guess it also needs an e-ink screen, otherwise the screen would still draw a lot of the power.

How fast are eInk displays nowadays? Like what kind of refresh rate are we looking at?

Not much more than a few Hertz, AFAICT. It should be enough to use a terminal - someone even installed X and ran XFCE on a Kindle, but it looks pretty weird.

They actually run X by default. They use the Awesome window manager.

I've been messing around with an Arduino this week to make my own IoT device. It has enough power to negotiate a https connection, so presumably it could run SSH and Vim. I think they are very efficient in terms of power usage.

There's the Vocore2. Five volts, 74ma draw when idle. https://vocore.io/v2.html

No video though.

For people interested in this, another thing to be aware of is uClinux: https://en.wikipedia.org/wiki/%CE%9CClinux

Another easy way to play around with Linux fit onto very modest hardware (but not 8-bit microcontrollers), which is very popular and very useful, is OpenWrt on a cheap old home WiFi router: https://en.wikipedia.org/wiki/OpenWrt

(If you want to pick up an old router for $20, WNDR3700v2, WNDR3700v4, WNDR3800, and select later ones in that family are a good starting point. The OpenWrt wiki pages for them will give specs and suggest what hardware revs are better.)

This is impressive.

Myself and several project mates used an Atmel AVR in early 2003 to build an mp3 player. We didnt bother with the storage integration instead to just opt to stream the mp3 file from a host PC over a UART. IIRC, we only had 32k RAM & 32k ROM to work with (we werent using a Mega chip, I'd have to dig through notes to find the model).

Knowing what we went through to get that mp3 player working (which we delegated the actual decoding to a dedicated chip) with just the AVR, what Dmitry accomplished with this is amazing. Many props.

Edit: this was a senior level college project for a BSEE, not work related.

Very impressive.

Kinda reminds me of Linux running on JavaScript: https://bellard.org/jslinux/vm.html?url=https://bellard.org/...

They’re both hacks for running Linux in ways it was not intended to run, by exploiting other technology, so there’s certainly some connection.

You are literally on a site called hacker news.

How was linux intended to run?

It’s in the article:

“The common answer is that it requires a 32-bit architecture and an MMU and at least a megabyte of ram to fit the kernel.”

He gets around the 32 bit + MMU requirement by emulation. It’s a cool hack, but it really is a hack.

According to him it takes about 5 hours to get to the command prompt which is kinda funny but interesting project nevertheless

I'd imagine that a modern kernel has a lot of pointless fat in it and that the 5-hours figure could be reduced if perhaps only slightly, with appropriate optimization effort. It might even be useful to deliberately have such a super-slow (but reliable, since it runs on highly deterministic microcontroller-class HW) benchmark in the mix, as you would be able to make very precise and fine-grained measurements about how even seemingly-unrelated changes might impact performance within the kernel, whether for the better or worse.

I believe that the idea would not be relevant in "general purpose benchmarking improvements" due to the vast differences in micro architecture between this CPU and modern CPU's.

The pipelining and internal optimizations differ greatly.

On a 386 with AT hard drives.

On a PC.

I have probably commented this before, but the nommu support was merged all the way back in 2.5.46, so a mmu is certainly not a requirement for running Linux.

A 32-bit architecture is not really a requirement either, you just need a compiler that can be told to use 32-integer types and pointers. You probably also have to modify the compiler to generate accesses to your external ram for loads and stores.

The real thing preventing you from running Linux on 8-bit micros is the requirement of a von Neumann architecture (or something that looks like it). These small MCUs usually don't even have a way of loading code at runtime which makes it impossible to run any sort multitasking without interpretation.

Maybe CP/M would be an easier type of operating system for that type of computer..if a bit dated.

https://spritesmods.com/?art=avrcpm

https://hackaday.com/2017/03/25/cpm-8266/

https://github.com/toyoshim/cp-mega88

Or FUZIX

https://github.com/EtchedPixels/FUZIX

Yep, definitely http://www.fuzix.org/ . It works on a whole lot of 8 bit machines.

I had an 8-bit micro, the Tandy (i.e. Radio Shack) Color Computer ("CoCo"), made in the mid 80s.

I got an optional OS for it, called "OS9" but unrelated to Apple's OS9 (which came later).

OS9 had capabilities very similar to (and modeled on)Unix. Clearly, Linux or something a lot like it could also have run on the CoCo.

But the 8069 is a microprocessor (CPU). This is a microcontroller. Radically different architecture and (typical) use case.

They don't have MMUs because they are designed to directly address a much smaller ram space. On an the micro in the article, this is only 16K. They are also designed to execute machine code directly, and automatically from an on-board or external ROM, whether a masked ROM (rare these days), an EPROM, or an EEPROM/NVRAM of various kinds. They are not designed to use an OS at all.

That's what makes this so impressive.

Trs80 Coco series used the 6809 CPU that is 16 bits. The article talks about Linux on 8 bit systems.

I'd say the Mega65 might be a good 8 bit machine to port Linux to. http://mega65.com

The 6809 was 8 bits, in the same way Z80 and 6502 and 6800 were: 8 bit data bus, 16 bit address bus.

It had a few 16 bit instructions: arithmetic on data in registers, or loading/storing a 16 bit register (8 bits at a time). I think the Z80 did as well.

Here's Wikipedia: https://en.wikipedia.org/wiki/Motorola_6809

It also had an 8x8 mul with 16 bit result.

One 16-bit feature doesn't make a CPU where every other feature is 8-bit a 16-bit CPU.

I don't think I claimed it was a 16 bit CPU.

Needs (2012)

Spoiler: they wrote an ARM emulator.

Very impressive project, but if you were hoping to run Linux on an 8-bit microcontroller for anything real you'll be disappointed.

Well, it will run Linux on an 8-bit microcenter for real, just sloooowly :)

All they have to do fix that is set LS_COLORS appropriately.

I dunno if a factor of 40 is going to cut it.

Not really... Linux is running on the ARM... its just the ARM that is emulated.

Subtle difference, granted.

Was not disappointed...other than the comment section. Oy.

I wonder what would be the ideal Linux compile target for running on interpreter style emulators (as contrasted to binary translation style).

I guess the machine instructions should be as high level as possible, to reduce the interperter dispatch overhead. Of course then you'd need to port Linux and gcc to your hyper-CISC...

Interesting. Making it run RISC-V rather than ARM would provide slightly quicker emulation, I believe. (And indeed, more generally, running a RISC-V VM provides a quick way of enabling modern 64-bit code to run even on hardware that's restricted to a 32-bit address space. Given that there's a lot of such hardware around, even of quite recent vintage, this can be practically helpful.)

Riscv didn't exist when I wrote this. Even now it doesn't exist (it will "exist" when someone ships a billion somethings with it in it)

I absolutely love your 8-bit Linux and plan on building one after I finish my relay computer.

The billion cores mark for RISC-V will be somewhere around the middle of 2020 thanks to Western Digital and Microsemi.

https://www.forbes.com/sites/tiriasresearch/2017/12/06/weste...

> What many do not realize is that the company ships over 1 billion processor cores within its products each year and is moving toward 2 billion per year.

https://hackaday.com/2019/02/13/western-digital-releases-the...

> Last year, Western Digital made the amazing claim that they will transition their consumption of silicon over to RISC-V, putting one Billion RISC-V cores per year into the marketplace.

https://www.microsemi.com/product-directory/mi-v-embedded-ec...

Oh, I do realize it. But it is 2019 so my statement holds as true :)

Yup, of course. Today it "exists" as a supported architecture in Linux, however... so it makes sense as a suggestion to whoever may want to try something broadly similar, but in a way that can even be practically useful. (Almost all current ISAs other than RV itself have historical warts that can slow down not just hardware implementations but emulation a lot... that's one of the reasons RV was made in the first place!)

> Almost all current ISAs other than RV itself have historical warts

RISC-V doesn't have historical warts only because it's too new for any warts it has to be considered historical.

> that can slow down not just hardware implementations but emulation

RISC-V shuffles the immediate bits on its instruction encoding to speed up decoding the immediate in hardware, but this slows down decoding the immediate in software. This will in the future probably be considered one of RISC-V's "historical warts".

> RISC-V shuffles the immediate bits on its instruction encoding to speed up decoding the immediate in hardware

You're right that this might be a problem, in principle. Surprisingly enough, however, RV is actually more than competitive as a system-level virtual ISA. People have experimented with this on existing emulation platforms, and that was the result they got.

It exists, even without a billion somethings.

Reminded me of this XKCD:

https://xkcd.com/505/

Sadly the software is proprietary. Indicating for "commercial use" means it is proprietary.

When already doing something for Linux kernel, it would be advisable to promote the same license as the Linux kernel, such as GNU General Public License 2.

Promote free software and advance of free software.

Give it a rest. The project is really impressive and quite a feat. Leave the militant piggy-backing out of it.

Reply on news.ycombinator.com