68 Katy – 68000 Linux on a Solderless Breadboard

That's peculiar that a pre-baked linux distro for Amiga would require an FPU to boot. Off the top of my head I can't think why that would be :S

Your post just brought back a flood of memories for me about the frustration I went through as a kid trying to port free software to 68k BSD. I started out running MachTen [1] which ran under System 7 on the Mac. There was something odd about the way it did dynamic linking, I can’t remember now, but it just turned any port into a nightmare. I don’t know why it took me so long to figure out there was a mac68k NetBSD, which had a much better/compatible toolchain for building stuff. I don’t remember ever trying to get linux going on 68k, but I can sympathize.

[1] https://www.tenon.com/products/machten/23-info.shtml

68008 it's a 68000 with a 8 bit external data bus and limited address bus. It's like the 8088 of the 68000 family. It was used on the Sinclair QL. If a Linux can run on a 68008, can run on any 680X0, that includes old Macs, QL, Amigas, Ataris (not the 8 bit family), etc...

I built almost the same thing as a senior final project in digital electronics in 2000. It took me 7 months and I never even troubled myself to go beyond simple assembly programs.

I am humbled.

Wasn't uClinux merged into mainline a long time ago?

Well...68020+68851 PMMU chip. Regular Linux won't run on just an '020.

Either that and/or really experienced.

I actually had to go back and check, and it seems you're correctly quoting his mis-quoting of the startup log.

It's "delay loop", which at least gives some clue that it has to do with timing. I'm sure the OP at least knows this, but just had a typo in his blog post.

Not-genius here: I've actually come across this problem trying to boot Linux on enigmatic hardware. If you look in the Linux code it's actually reasonably simple to work out what it's waiting for.

This guy is definitely a genius for other reasons, though!

> Unsurprisingly for this level of library code, it's not 100% super-obvious or easy to understand.

Sounds like you visit the wrong libraries. Try plan9's

The whole putenv()/setenv()/unsetenv()/environ API is inconsistent hack that is essentially impossible to implement without introducing memory leak in at least one of these operations without introducing some complex additional book keeping. The good news is that there aren't that many reasons to actually use these functions, as only reasonable usecase for modifying environment is changing environment of spawned subprocesses, which can be done by constructing your own environ and passing it as envp argument to exec().

On the other hand the memory leak is mostly negligible and one would assume that for reasonable program that calls setenv (ie. does not call setenv in a loop) probably smaller than cost of the aforementioned extra book keeping.

A lot of newer CPUs aren't available in DIP packaging which means they won't be usable with a breadboard; the M68k is one of the more unusual ones in that it's available in a 64-pin DIP, the longest common DIP package. E.g. all the x86 processors moved to square packages starting with the 80186/80188, only the 8086/8088 were in DIP.

DIP packages are problematic for high-speed operation since the leads to the pins near the ends are longer than the ones in the middle, creating signal skew; hence the move to square/BGA packages.

That being said, there are microcontrollers with a relatively powerful ARM core and in DIP, but they usually have internal memory and use the pins for peripherals, not as a full memory data/address bus.

userbinator's comments are good, and to extend his remarks obviously the solution to clock skew is to simply lower the clock rate. Good luck using a solderless breadboard at 500 MHz digital LOL. But breadboards work just fine at single digit MHz rates.

There is a problem. Many processors use dynamic registers and require a clock above a certain rate to refresh the registers. Yes, no kidding, dynamic ram cells as CPU registers. I know for a fact that the first 386 was dynamic and onlyrated down to 10 or 15 or so MHz (was fooling around with low power ops, if the thing sleeps 90% of the time at 25 MHz, you can't run the chip at 100% utilization at 3 MHz...). You can see a slight mismatch if your CPU registers are only rated down to 15 MHz and you can't reliably breadboard above maybe 5 MHz ... Of course this is analog world and a chip rated to run down to 12 Mhz will almost certainly run at 10 Mhz, maybe even 5 at least sometimes, if you're careful not to run at max temp or min power supply voltage or whatever. And adding to the fun, after (sometimes long after) the first dynamic versions of a CPU come out, someone (often a licensed competitor) makes a fully static version of the chip, sometimes pin compatible. As you can imagine, early on in development, being able to troubleshoot logic by running at a tenth of a Hz is very convenient. If you've ever wondered what "fully static" means on a microcontroller data sheet, well, now you know. And you know why you can't breadboard a classic 80386 but maybe a more recent fully static clone would work.

userbinator's comments about packages are also correct and there is a low speed workaround of carrier to DIP converter boards and proto boards. I've hand soldered many a surface mount TQFP, its very easy. There are many companies selling SMD proto boards, some cheaper, some fancier, but a realistic place to start is googling for "schmartboard", as pretty much if the SMD package exists, they sell a proto board for it, ready for projects like this.

Unfortunately the industry is moving toward BGA packages and the official new hardware to mount those is like $5K although I'm sure I could rig something up much cheaper.

The hardware is remarkably simple. It's the software that's tricky. It's nowhere near the level of insanity (all for good reason) you find on modern PCs where you boot without knowing how exactly you'll get to your RAM.