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).
am pleased with this turn of events. To this day, m68k remains an important architecture; not every application needs multi-gigaFLOP/second performance or even an integrated FPU.
"not every application needs multi-gigaFLOP/second performance or even an integrated FPU"
Well yeh, not everybody does. But do they even sell cheap 68k chips? And if they do, don't they sell *cheaper* ARM chips! Just because you don't need it, doesn't mean there's any advantage in using this.
If they make it will they come? Because if nobody uses it, it isn't properly tested, and if it isn't properly tested, nobody will use it.
68k has had it's day, it's dead, let it go.
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.
besides the obvious "because we can" that is ?
You'll have to ask them for sure.
Something I know, that hasn't been mentioned, is freescale released at least some cores under an at least sorta-free license near a decade ago, so I would think it amusing to make a multi-machine build farm out of a big FPGA (or board full of FPGAs...) At least way back then, there were not many options for running linux on a (official released) FPGA soft core. I would imagine there are more options now if you want to run linux on a (official) soft core.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
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.
CodeSourcery was paid to implement TLS for the coldfire. Debian wasn't paid to resurrect the m68k port.
Do you even lift?
These aren't the 'roids you're looking for.
I'm still curious if 386 support would be accepted back in if it was done as a separate arch to keep it from mucking up the regular/later x86 branch?
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; }
As a matter of fact, I do have gear in use that is affected by the removal of 386 support. (The linux terminal server project crowd in particular is affected by this also.) If I was trying to troll I think I'd have been a bit more... obnoxious with my wording? Back to the topic at hand, my understanding was that it wasn't the 386's shortcomings that doomed it, it was that they had to invoke workarounds in the x86 branch for them, and THAT was where the hardship came from when trying to move the ball forward over time. In theory, a separate arch shouldn't trigger the same pain as x86 would be free to grow, dead86 would then have to deal with issues as they cropped up separately, without impacting the other arches any more.
June 2010, Freescale announced the ColdFire+ line, which is a ColdFire V1 core using a 90 nm TFS technology
90nm? In 2010? That should be enough to tell you that Freescale doesn't care. A chip announced in 2010 (no idea when, or even if, it actually shipped), using a process that was state of the art in 2002. Cheap parts were using 65nm in 2010. 90nm is the stuff you stick in the fabs that you don't have the spare capital to refurbish and want to keep ticking over. Followed by:
The future of the ColdFire architecture is uncertain given that Freescale has been focusing on ARM-based cores in this market segment
Exactly.
I am TheRaven on Soylent News
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.
I'm not familiarized with ColdFire, but the grid size on the manufacturing process is no way of measuring the relevance of a given product. There are a ton of applications that actually require reliable processors instead of "latest tech". Some embedded applications may require 10-20yr lifespan under radiation, extreme heat, magnetic interference, and so on and so on. Just because they aren't the best choice to create handheld devices to play Angry Birds, or to create desktop computers, doesn't mean they aren't useful.
I'm not good with details on Amiga, but I think the procedure is:
You boot some sort of Kickstart/Workbench, then run an AmigaOS program which is the Linux bootloader and pass it the kernel and, if needed, the initrd from the AmigaOS filesystem, it will load them and make them usable, then jump into Linux. From then onwards, that one will be the OS in charge, making ext4 available etc.
Sadly, no kexec yet. Having to copy out the kernel instead of being able to load it directly from ext4 (or whatever you choose) would be cool.
AFAIHH some of the emulation projects have made available Free (as in Freedom) ROMs for TOS (EmuTOS) and Kickstart, which contain enough code to run this without needing the proprietary Amiga stuff. But, like I said, I'm nowhere near knowledgeable about this part of those architectures, plus I mostly worked on (emulated and a few real) Ataris, not Amigas, while doing this. (And even there, I did as few as possible on the "native" side.)
My Karma isn't excellent, damn it! (And