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).
what about a linux kickstart rom??
besides the obvious "because we can" that is ?
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.
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.
I have fond memories of 68k hardware but I am surprised people even bother with stuff like this in 2012.
As a former m68k user, I can tell you this is a very good distro.
You can really breath new life into older computers. The results are often startling and better than their intel cousins from the same era. Not to say that this is a good "production environment" strategy, but if you have old macs collecting dust, and you'd like to learn some real linux-fu, install m68k linux on them. You will end up with useful computers, sometimes even useful for light desktop. Definitely useful for low-volume web servers, mail, ssh, etc.
This is a lot of fun and there are plenty of old macs available for almost nothing. Get out there and learn!
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.
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; }
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 have a stash of retrocomputers and consoles, and for everyone of them that i can get to run *nix it's always cool. Amiga now has DebianM68k and NetBSD in new versions, PS2 has the kernelloader live cd, My old Mac PPC has Linux Minut, and my Sam460 has Debian too. As for the Speccy - well at least it got esxdos:)
There was no meaningful software level difference between 386SX and 386DX - it was basically just a difference in hardware bus width that normal programs, even kernel level, wouldn't care about.
In 486 land, the SX/DX was there to show whether the 486's internal math coprocessor was allowed to be used or not.
Stop. Just stop.
Please put your time into something more constructive than yet another implementation of the standard slashdot "work on a project I like, not that thing you find interesting" post that serves no purpose aside from trolling.
0 1 - just my two bits
Not too long ago, WinUAE added MMU support. And it didn't take the community long to get Linux running on it.
It's nice seeing Linux run in WinUAE, but the distro is rather dated. It would be nice to have something recent running in WinUAE. And before you ask, I have no idea why this is so cool to me and why I want this so much. I just know that I do. Having a recent distro running in WinUAE is for some odd reason very nifty.
Can't explain it. Still though, I'm just very happy about this news.
Weaselmancer
rediculous.
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've always taken the slogan differently. That if it's "news for nerds", then it falls in the "stuff that matters" category.
There's a big difference between being a hobbyist developer for an old platform and maintaining a ported operating system for it. It's time to let it go, folks. I have quite a bit of nostalgia for my old 8088, but it doesn't mean I'm going to put weeks or months of my life into writing code for it anymore. There's quite a lot of low-power modern architectures out there that a person could spend their time porting software to instead.
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.
FWIW, latest NetBSD 6.0 still supports mac68k fine, and has never ceased to do.
It also had ultra advanced sprite scaling chips to allow me to play outrun, powerdrift, galaxy force and space harrier as seen in the arcades.
Unfortunately, it never happened.
In one of the linked articles they mention that a decent Atari (ST presumably) emulator was instrumental in allowing them to work on m68k without having direct access to the hardware.
Right, but we are doing this âoethe Debian wayâ, that is, running a native compilation and package generation in clean throw-away chroots. Debian package generation is not just compilation, itâ(TM)s a bunch of other stuff (dependency management, shared library management, etc.) and, personally *and* from my experience with the BSDs and FreeWRT, I am of the opinion that cross-compiling is only good for initially bootstrapping a port.
Besides, natively compiling forced us to fix lots of bugs in the kernel, eglibc and gcc, and backport other stuff to gcc, and to eat our own dogfood.
My goal with this was *not* just to have a system running Linux/m68k, but to have the process of auto-building packages working. (If you research, youâ(TM)ll find out that Iâ(TM)m a die-hard x86 and GW-BASIC fan, so I have no history with m68k other than eyeing them strangely for having the wrong endianness.) Also, I learned a lot of how Debian works in the process ;-)
My Karma isn't excellent, damn it! (And
Finding bugs in Debian, gcc, eglibc, the Linux kernel, by running it on minority systems is a decent outcome of this, Iâ(TM)d say.
The purpose of having bragging rights that mksh works on all platforms, no matter what obscure, is personal, so you canâ(TM)t measure relevance anyway. Iâ(TM)ve even done DEC ULTRIX and Haiku successfully. Oh, and Plan 9â¦
Besides, it was a nice project to learn about how Debian works ;-)
You should learn to think outside of the box. What makes you think reviving ancient hardware ever was the purpose?
Besides this, I think the other replies already said everything needed.
My Karma isn't excellent, damn it! (And
By the way, if you get AMIX running and with an ANSI C compiler, join the IRC channel #!/bin/mksh (yes, that's really its name) on Freenode, so we can port mksh to it ;-)
If you are interested, that is.
My Karma isn't excellent, damn it! (And
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.
ColdFire is a line of microcontrollers. Microcontrollers are not built on state of the art CMOS processes, partly to keep the cost down, partly to keep the power consumption down, and partly because they need high-quality embedded NOR flash, making them not pure CMOS anymore. This means you're making a whole separate, specialized process for your MCUs. In that context, 90nm is pretty good. I think the absolute top of the line for flash MCUs right now is 55nm, which might not even be in production yet. There are plenty of MCUs still in production at 180nm.
TL;DR: Embedded processing and desktop CPUs are Not The Same Thing.
Visit the