[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Preparing the m68k port for the future.

Hello World,

Yes, 'm68k' and 'future' in one sentence. Amazing, isn't it? Surely we
must be joking?

Well, no. The m68k port, for a port built for hardware that hasn't been
manufactured anymore for about 10 years now, is still amazingly active.
The linux-m68k (upstream kernel development) mailinglist isn't LKML or
debian-devel, but does see a few post per day, on average; the port has
more active porters than some of the other ports with more recent
hardware, and on debian-68k and comp.os.linux.m68k we still rather
regularly see people asking how to install Debian/m68k on their
hardware--clearly people who haven't done so before.

On the other hand, supporting Debian/m68k requires more and more effort.
Newer compilers, when compared to older ones, typically require more RAM
and more CPU power to compile the same source code; also, the Debian
project has always been in constant growth, and it does not look as if
this is going to change any time soon. Which obviously is good, but also
means that any port will need to increase its cumulative buildd power
from time to time.

For a port such as m68k, one that is based on hardware which is not
being actively developed anymore, that's a problem. We can continue to
increase our buildd park, but at some point we'll have to give up
because it won't be reasonable or practical anymore.

Some may say we've reached that point already :-)

Anyway. To cope with the above issues, the m68k port's developers have
been looking for alternatives for quite a while now. It has been
suggested that we start employing distcc or similar things so that we
would be able to use cross-compilers on much faster hardware, but for
various reasons this is not practical. We have fairly recently acquired
some 66Mhz 68060-based hardware, which clearly outperform our previous
50Mhz "fast" machines. This did help, but it is not nearly enough; and
in any case, it's only postponing the inevitable. For a real solution,
we would need hardware that is still actively being developed.

Now although the m68k architecture has not seen any significant updates
since halfway the 1990s, Motorola (who, in the mean time, split off
their semiconductor business into a different company called Freescale)
did use the m68k architecture as a starting point to develop two other
lines of processors; one was the (now defunct) dragonball line that has,
amongst others, been used in Palm PDA's; the other was the ColdFire line
which is still very popular as an embedded target.

Since the ColdFire architecture is based on the m68k one, they share a
lot of instructions; i.e., in many cases it is possible to compile
something for a ColdFire target and run it on m68k hardware, or vice
versa; indeed, there is no difference between a simple "hello world"
application in C, one compiled for m68k and one for ColdFire. That being
said, there are differences between both architectures; most notably,
the ColdFire instruction set lacks a lot of instructions that are
present in "classic" m68k hardware (those that are least often used),
and adds some of its own (mostly in support of hardware accelerated
cryptography, and hardware-accelerated vector math). Additionally, there
are some infrastructural differences in the FPU, making compatibility
a bit awkward. Finally, and this was the real showstopper, the ColdFire
processors did not have an MMU, making virtual memory and paging
impossible--something a decent Debian port could not live without.

Since about two years now, however, the ColdFire family has been
extended with the V4e cores. These do have an MMU and exist in various
versions, including a 266Mhz one. While 266Mhz is still not lightning
fast by today's standards, it is about 4 times faster than our two
fastest build daemons, and about 6 to 8 times faster than the average
m68k processor.

In addition, the Linux support for this processor class is starting to
mature, with patches just having been merged into upstream binutils and
gcc, and patches for the kernel being worked on.

For these reasons, we've considered making sure Debian/m68k will run on
ColdFire hardware. Because of the reduced instruction set and the
differences in the FPU hardware, it is still not 100% sure that a hybrid
port (which will run on both "classic" m68k processors and the newer
ColdFire ones) will be at all possible; however, at first glance the
differences do not seem to be unsurmountable, and we are hopeful that it
should be possible to turn the m68k into something that will run on both
classic m68k hardware and ColdFire hardware.

With the above information I have contacted Freescale, and they've
graciously agreed to donate five ColdFire evaluation board to us; these
are being shipped now. There is one for each of Stephen Marenka,
Christian Steigies, Adam Conrad and myself (all m68k porters) and,
additionally, one to Sven Luther who's also interested in this project.

Exciting times these are.

If we succeed, this will mean that we will be able to replace our
current buildd park by a much faster ColdFire-based one, and that we
will again be running a port on hardware that is being actively
developed, all without dropping support for our current users.

The porting effort will start as soon as the boards arrive at their
respective destinations; it is not yet know if and when this will result
in something useful.

.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ ..../ / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ ..../ -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/

Attachment: signature.asc
Description: Digital signature

Reply to: