debootstrapping m68k-coldfire

[Michael Casadevall <sonicmctails@gmail.com>]

Well, it's been discussed time and again. It's overdue; its time we 
bootstrap the coldfire port. Roman convienced me in his email that having 
coldfire as a seperate binary distrubution is without a shadow of a doubt 
the only SANE way we can support both coldfire and classic m68k. I'm 
willing to do the grunt work on bootstrapping the port. I figure I should 
try and point out why not old a seperate port is a better way to go, why 
it won't kill classic m68k.

Reasons for having a seperate port:
	* We can optimize to each specific architecture
	* It can be done now; we don't need to keep monkeying around with
	  binutils.
	* We don't need to worry about any weird errors come from the
	  binaries due to the different opcodes and such

Reasons why the seperate port won't kill us:
	* Almost all work done on coldfire can easily be used on classic
	  m68k; including kernel TLS and glibc porting (assuming CS ever
	  comes through for us)
	* By generating interest in the coldfire port, we can probably
     	  find more people who can fix gcc bugs in not only
	  coldfire, but classic m68k (the backend code for GCC is pretty
	  similar; 90% of it is more or less shared, with a few minor
	  differences).
	* Freescale probably going to point to the fact that Debian runs
	  on coldfire (they did give us evalution boards), and might end
	  up commiting things towards the project once it gets off the
	  ground.

If someone will give me access over SSH to one of the coldfire boards, I 
will work on cross-building the entire userland for coldfire, and applying 
the patches APT will need to recongize coldfire as a seperate 
architecture. Any board would need a real linux kernel, busybox, and 
dropbear; I can cross-build everything else (and considering I spent most 
of the day (attempting) to cross-build the ada compiler, this is trival in 
comparsion :-)).
Michael