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