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

debootstrapping m68k-coldfire

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
	* 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
	* 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

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 :-)).

Reply to: