[OE-core] [PATCH 2/3] Add basic Mips core tune config

[Mark Hatle]

On 8/11/11 6:25 AM, 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. 

My understanding of MIPS and how everything should have been configured.

canonical arch = mips = big endian -- mipsel = little endian.  Anything else is
incorrect.

As for the CCARGS, the versions of gcc that I am used to, little endian is the
default tuning.  But we still want to provide -mel to ensure we've got the right
one.

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

The TUNE you should be using is "mipsel" instead of "mips".  (The DEFAULTTUNE)
parameter.  The TUNE_ARCH, made up of
"mips${MIPSPKGSFX_BYTE}${MIPSPKGSFX_ENDIAN}", should result in mipsel.

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

TARGET_ARCH is results from TUNE_ARCH, which should be encoding the right values.

The default tune of mipsel sets the values of: TUNE_FEATURES_tune-mipsel = "o32
fpu-hard"

Which is expected to work, for mips, little endian, o32, with hard-float.

--Mark


> p.
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core