Re: [PATCH 2/3] Add basic Mips core tune config

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2011-08-11 at 12:25 +0100, Phil Blundell wrote:
> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
> > +# MIPS Architecture definition
> > +# 12 defined ABIs, all combinations of:
> > +# *) Big/Little Endian
> > +# *) Hardware/Software Floating Point
> > +# *) o32, n32, n64 ABI
> > +
> > +DEFAULTTUNE ?= "mips"
> > +
> > +# Endianess
> > +TUNEVALID[bigendian] = "Enable big-endian mode"
> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "-meb", "-mel", d
> 
> I've just been trying to do a mips build for the first time since these
> patches were landed and I'm a little bit unclear about what the "right"
> way to declare endianness is nowadays.
> 
> The new tuning system has introduced the idea of endianness as an ABI
> tune parameter and, by implication, if I don't have "bigendian" in
> TUNE_FEATURES then presumably this is meant to mean little-endian.
> However, there seem to be at least some places in OE which are still
> expecting endianness to be encoded into TARGET_ARCH, i.e. a
> little-endian system would be TARGET_ARCH=mipsel rather than mips. 
> 
> Right now, building a little-endian MIPS32 doesn't seem to work either
> way around.  If I set TARGET_ARCH=mips and exclude bigendian from
> TUNE_FEATURES then (among other issues) uclibc-config.inc decides that
> my system is bigendian and sticks -Wl,-EB back into LDFLAGS.
> Conversely, if I set TARGET_ARCH=mipsel then I don't get "mips" in
> OVERRIDES and I end up with the wrong uClibc.machine and associated
> -mips1 lossage.
> 
> That latter failure is at least relatively easy to work around and so
> that's what I'm doing at the moment.  But I don't know whether this is
> the "right" way to proceed or whether TARGET_ARCH is expected to be
> endian-agnostic in this newly tuned-up world.

You sound like you're doing this backwards. Pick a tune that either sets
TUNE_FEATURES to either contain or not contain "bigendian". TARGET_ARCH
then should get set appropriately and things that look at TARGET_ARCH
should work as before.

Ultimately we might want to consider if things like siteconfig should
use TUNE_FEATURES rather than TARGET_ARCH but it should work as things
stand now...

Cheers,

Richard