Slashdot Mirror
Debian m68k Port Resurrected
After two years of work, Debian m68k has working build servers, and is slowly working through the backlog of stale packages. "Contrary to some rumours which I've had to debunk over the years, the m68k port did not go into limbo because it was kicked out of the archive; instead, it did because recent versions of glibc require support for thread-local storage, a feature that wasn't available on m68k, and nobody with the required time, willingness, and skill set could be found to implement it. This changed a few years back, when some people wrote the required support, because they were paid to do so in order to make recent Linux run on ColdFire processors again. Since ColdFire and m68k processors are sufficiently similar, that meant the technical problem was solved. However, by that time we'd fallen so far behind that essentially, we needed to rebootstrap the port all over again. Doing that is nontrivial, and most of the m68k porters team just didn't have the time or willingness anymore to work on this; and for a while, it seemed like the m68k port was well and truly dead."
The tales of acquiring the needed hardware are pretty interesting (one machine is an Amiga in a custom tower case).
I doubt I'll *ever* make use of this project myself, but I'm inspired by the tale of how it went from "left for dead" to a full-on revival, based on something as unexpected as a rather unrelated 3rd. party software project (Atari emulator that happened to allow the m68k developers to work on their code from any laptop computer they happened to be using), as well as a single motivated individual bent on making his shell run on all known variants of Debian.
The metaphor is all wrong. It's Christmas, not Easter. You're supposed to say that an updated version of the Debian m68k port was delivered by Santa, or that Rudolph helped them find their way back to the main branch, or that wise men brought Debian gifts of gold, frankincense, and m68k ports.
Check out my sci-fi/humor trilogy at PatriotsBooks.
ARM isn't always the right choice and it does have its problems. Additionally if you have to interface with an old system it's often easier to just grab a M68K or an old Intel 8xxx series device. The interface was already designed in a lot of cases for the older devices. And the M68K is advanced and fast enough to easily interface with modern hardware. So it actually does make for a pretty good bridge when you have to make two incompatible systems work together and don't want to go through the trouble of starting from scratch. Not to mention that the M68K is a great device to introduce people to the hardware side of embedded system design. Fairly cheap, comes in easy to solder packages unlike most ARM processors, robust, well documented, loads of software has been written for it, ...
Totally worth the effort! It's not because something is old that it's not worth using anymore. Look at the Intel 8051 architecture. You'll find several microcontrollers based on that architecture in your house on this very moment. Sure it's an ancient 8 bit CISC architecture, but most designers are very familiar with it and it's one of the cheapest microcontrollers available so it still sees quite a lot of use. Fun fact is that it's commonly used as USB host controller.
Like anything - if someone does the hard work, and it's supported enough, and it doesn't break OTHER architectures, there's no reason why not.
It just seems that m68k (and other projects along the same lines) have people willing to do all that work, whereas the 386 architecture doesn't (yet?).
This is the thing I actually quite like about Linux. MCA support? Few used it, fewer wanted it enough to do the so, so bye-bye. But other buses? They are still around. Applies to buses, architectures, drivers, features, even "helper code" of one type or another.
If someone's willing to put in the back-breaking to get it up to standard, there's no reason to NOT let it in. Unfortunately, that standard has to be high for a number of reasons (e.g. legal obligations like licensing, coding quality, support, ongoing maintenance etc.). And for some, it's so high it doesn't justify the work.
Linux is a meritocracy, like more open-source code. If there's a reason to do so, and it's done well, it happens. If not, it doesn't. If only parts of law and government were like that.
Perhaps because you are more of an "appliance operator" you don't appreciate the science and engineering behind the scenes.
Working with old hardware, like new hardware, presents a lot of challenges. The learning that takes place is very useful.
Unlike new hardware, old hardware is cheap and plentiful. Yard sales, garages, surplus stores... this is the place to go. For new hardware, you are looking at some money.
The learning that takes place on the old hardware is useful on problems beyond this "ancient platform". The folks that accomplished this port have flexed their brains around complicated problems, and are thus able to process other complicated problems more efficiently.
Bottom line, some people are passionate about engineering and science, and do it because they enjoy the learning process.
The specific reasons to drop 386 support from the kernel were because 1) its MMU is substandard compared to 486 and later and causes a lot of complications in the kernel, 2) it doesn't have CMPXCHG which is used for semaphores (in glibc, not just the kernel), and 3) it doesn't have the byte swap instruction which makes a big difference in network code.
Dropping 386 support is like dropping 68000 and 68010 support. It's the oldest sub-architecture, lacking a lot of good improvements that came in the next generation. Guess what? Debian dropped 386 years ago, and this m68k port doesn't work with anything less than a 68020+MMU. For all I know, the kernel doesn't support 68000 or 68010 either.
Nobody uses anything anymore that won't work a 486 build and thus requires 386, aside from someone with a 20-year old PC. But m68k is a whole architecture (like x86), and Coldfire is still Not Dead Yet. Seriously, do YOU have anything that requires a 386 build or know anybody who does? If not, why the hell do you even care, other than just to be a troll?
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Ever hear of Coldfire? It isn't nostalgia (not yet, at least), it's still a viable embedded CPU architecture, less than 10 years old. It's a RISC-ified 68K, with a few instructions removed (they can be implemented via the illegal instruction trap) to make the RISC work. If you had bothered to read TFS, you would see that was what started all this.
Maybe you should put your time into something more constructive instead of trolling for no useful purpose at all.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
I keep hoping someone will take the 6809 architecture, extend it to 64 bits wide per register, add an MMU, implement underneath a modern microcoded engine (the original was random logic), and throw an FPU on-board. Maybe add a few megs of register pages for context switching, a few instructions to give it supervisor/user smarts.
It was *so* easy to write code for that thing; it had pretty much the perfect mix of instructions -- way better than the 68000, for instance. The 6809 was the best 8 bit uP ever from a programming POV. I wrote a couple of compilers for it over the years, it felt like the uP designers totally knew what I was going to need.
Probably never happen.
Pffftbt.
I've fallen off your lawn, and I can't get up.