68 Katy – 68000 Linux on a Solderless Breadboard(bigmessowires.com)
bigmessowires.com
68 Katy – 68000 Linux on a Solderless Breadboard
http://www.bigmessowires.com/2014/11/17/68-katy-68000-linux-on-a-solderless-breadboard/
39 comments
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
[1] https://www.tenon.com/products/machten/23-info.shtml
[deleted]
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...
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
The kernel is required to support FP instructions, either through emulation (processor would trap them) or an FPU. Early on, no one had ported the emu code to Linux 68k, but even later emulation (done by Roman Zippel) could be hit-or-miss, so it was pretty common to not be able to boot without a real FPU.
Amazing, he did in 3 weeks and that seems like 3 weeks of part time work, that's amazing. It's amazing how much work we can put out in a small time if we are focused. I lost it during the video when he got tangled up in vi. In 1998, I got a Sun 3 workstation which has a 68000 cpu, the only thing I could get to run on it then was NetBSD. It's amazing that a single person can now build such a computer and run Unix on it within 3 weeks. Just amazing, how time changes things.
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.
I am humbled.
Great project! Good hustle with the multiple attempts...
I smile at the use of a 555 as an interrupt timer... I did the same thing in my 8088 senior project in 1996... Typically one wants the interrupts to be accurate and periodic (hence hardware dividers to adjust the rate), but the 555 is (typically) based on RC time constants and as such is subject to heat changes :)
So your operating system runs differently at different times of the day :)
Also, mine had potentiometers to control the two external interrupts (556), so you could change the interrupt rate in hardware and there was plenty of pot noise which was easily detectable in the output audio stream... tee hee memories.
I smile at the use of a 555 as an interrupt timer... I did the same thing in my 8088 senior project in 1996... Typically one wants the interrupts to be accurate and periodic (hence hardware dividers to adjust the rate), but the 555 is (typically) based on RC time constants and as such is subject to heat changes :)
So your operating system runs differently at different times of the day :)
Also, mine had potentiometers to control the two external interrupts (556), so you could change the interrupt rate in hardware and there was plenty of pot noise which was easily detectable in the output audio stream... tee hee memories.
Steve of BMOW has done several amazing hardware projects including a homemade CPU from logic chips and CLPDs, Mac floppy emulators, and more. Rather than link them here, browse the links on his sidebar and read the descriptions of each project.
>Schematics? Forget it. Everything was built incrementally, one wire at a time, while staring at chip datasheets. It’s an organic creation.
Yeah, that's real hardware hacking right there.
>Schematics? Forget it. Everything was built incrementally, one wire at a time, while staring at chip datasheets. It’s an organic creation.
Yeah, that's real hardware hacking right there.
To clarify the article's text, uClinux is not (just) a distribution, but a version of the kernel that rus on MMU-less hardware.
The full Linux kernel does have m68k support, but it needs a 68020 or better CPU. This gets you real memory protection, VM etc.
The full Linux kernel does have m68k support, but it needs a 68020 or better CPU. This gets you real memory protection, VM etc.
Wasn't uClinux merged into mainline a long time ago?
You can build it from the mainline git repo, but what you get is a version of the kernel with defining features of Linux/Unix missing.
What's missing?
I haven't used uClinux before but I consider it on a cortex m4 - what should I be wary of?
Well...68020+68851 PMMU chip. Regular Linux won't run on just an '020.
"...hung at calibrating display loop. Aha, I needed a timer interrupt...."
He must be a true genius, to be able to infer the second from the first.
He must be a true genius, to be able to infer the second from the first.
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!
This guy is definitely a genius for other reasons, though!
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.
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.
Either that and/or really experienced.
2MHz on a breadboard is good going. Getting linux into half a meg of Flash is also extremely good going, even if it is uClinux.
[deleted]
The article spoke about a suspected memory leak in setenv(), I assume it uses uClibc but it was a bit light on the details (no source code links in the article, that I could find).
I dug up this link: http://git.uclibc.org/uClibc/tree/libc/stdlib/setenv.c?id=30... which I believe is the relevant function.
Unsurprisingly for this level of library code, it's not 100% super-obvious or easy to understand. Especially the details on the in-library memory management are unknown to me, but I thought it might be interesting.
I dug up this link: http://git.uclibc.org/uClibc/tree/libc/stdlib/setenv.c?id=30... which I believe is the relevant function.
Unsurprisingly for this level of library code, it's not 100% super-obvious or easy to understand. Especially the details on the in-library memory management are unknown to me, but I thought it might be interesting.
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.
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.
I used the older uC-libc, not the newer uClibc (no dash in the name). You're right. There's a tiny leak in this version of setenv(), when you set a value for an environment var that already exists. It leaks the old value, which seems to be an intentional design choice, in case anything was holding on to a pointer to it.
> 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
Sounds like you visit the wrong libraries. Try plan9's
I built a 68008 breadboard 'computer' as a student with 6522 VIA, an EPROM of 'code', some RAM and some LED lights to show if anyone was home. It took a lot of work to get that far. And that was a long time ago. The benefits of the 68008 were the same - minimal pins to wire up, more chance of it actually working.
Anyway I am impressed that someone can get a distro working on 68008, getting to the start line of that project is a big deal, going the extra miles - very impressive!
Anyway I am impressed that someone can get a distro working on 68008, getting to the start line of that project is a big deal, going the extra miles - very impressive!
[deleted]
I would never be able to keep all these wires straight in my head. And that's even a step-down in terms of wiring from the BOMW1 project...
Kudos for wiring this (and also for the rest). I can't seem to succeed wiring much simpler circuits on the first attempt, and get mad going through all the connections to see what's wrong.
This is amazing! It's pretty surprising to me how little there is on the board. It looks comprehensible.
I wonder if you could do this with a modern CPU and RAM. What would it look like?
I wonder if you could do this with a modern CPU and RAM. What would it look like?
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.
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.
A lot? Make that pretty much all. The only things you still find in DIP format are very low-end micro-controllers.
Not ARM microcontrollers, which the OP specifically references. NXP’s LPC810 & LPC1114 are really the only game there, and they don't support external memory AFAIK (and it's an M0). Of course, there are a lot of shops bonding an QFP ARM or similar to a slip of PCB that's DIP form factor, but that's not exactly the same.
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.
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.
Cheapest possible toaster oven + cheap multimeter thermocouple for manual temperature control + {paste flux, solder paste+stencil} works better than you'd think for soldering BGAs. Even honest-to-goodness reflow ovens can be had on eBay for $300-$400 (search "T962"), which would give you another one or two nines of reliability by circulating the air and having more precise temperature control.
Schmartboard also makes 1.0mm pitch BGA adapter boards, but a lot of the high-end stuff these days is moving to 0.8/0.5/0.4mm pitch. Of course, for those kinds of things, the extra parasitics of an adapter board are probably a no-no in any case.
Schmartboard also makes 1.0mm pitch BGA adapter boards, but a lot of the high-end stuff these days is moving to 0.8/0.5/0.4mm pitch. Of course, for those kinds of things, the extra parasitics of an adapter board are probably a no-no in any case.
For prototyping you can also solder BGAs with any hot air rework station. Even if you don't already have one, Atten 858D only costs around $60. Here's an example (not my video): https://www.youtube.com/watch?v=L8EWqWj2srg
Reminds me of the days when the 680x0 series was still a Mac thing and Yellow Dog Linux was a compatible distro.
I remember when I was a kid, trying to just get a pre-made Linux-image boot on my Amiga. I had a 68020 CPU, but due to no MMU and no FPU (neither being "normal" accessories at the time) I just couldn't get the thing to boot at all. Later, when I acquired a 68030 CPU, I at least had the MMU covered, but I was still a kid and didn't have a budget for a FPU. So I still couldn't get things booting.
Granted, back then I wouldn't know my way around Unix if I had been handed a booting system, but I was curious about this "Linux" thing which was supposed to be superior if you wanted to run BBSes, multitask and do stuff like that.
But despite all those resources I had, I couldn't get things going. And here this guy gets Linux running on a home-built 68008-based system of all things.
That is seriously cool!
Edit: I may be mixing up my 68k models. I also had a plain 68000 earlier, which was definitely not up for the task. If I'm mixing things up, please forgive me. It was a long time ago :)