> > I gather from the
> > mailing list that the 1.2.x port is more stable, but the
> > 1.3.x port is more MIPS compliant (and is 'where the action
> > is'). Which would you recommend we use? Is one definitely
> > better than the other for starting out or are there some
> > tradeoffs? I'm sure we want to be running 1.3.x eventually
> > - is it a waste of time to consider 1.2.x (i.e. will waste a
> > lot of effort having to start over again)? Any views you
> > have on this will be greatly appreciated.
> It depends... If I got things right, 1.3.x is tested *only* on
> the Acer box, whereas 1.2.x already runs user code on 3 platforms
> and halfway works on two other platforms. Anyway, there is still
> a migration path from 1.2.x to 1.3.x, ie. if you work on 1.2.x
> we'll find a way to integrate your patches into 1.3.x.
I've tested 1.3.35 or so successfully on Stoned's Oily.
> > A related question - is the cross development
> > environment mentioned above good for both 1.2.x and 1.3.x
> > Linux/MIPS kernels, or is it built to handle one of them
> > only?
> So far I understood Ralf right, you can build 1.3.x kernels with
> the old gcc too. However, gcc-2.7.0-2 together with binutils
> 2.5.2-6 is recommended since the devkit you have turned out to
> be a bit buggy. Really only a bit, but it might lead you into
> trouble. Ralf will release the new devkit this week. You can start
> with the kit you have, but you should upgrade soon.
Just to explain the bugs in binutils - upto and including binutils 2.6
ar writes the armap in the byteorder of the format that is configured
as default format for the binutils. For mipsel-linux this is always
little endian, for mips-linux always big endian. This is normally
correct, unless you use ar to archive files of the other byte order.
This results in incompatible archives ...
Another funny bug in binutils 2.6 ruins relocatable linking for all
a.out targets using extended reloc. This are MIPS, AM29000 and Sparc.
(David, interested in a patch?).