Patchwork [2/3] Add basic Mips core tune config

login
register
mail settings
Submitter Richard Purdie
Date July 26, 2011, 12:44 p.m.
Message ID <b270e42da9fef8715c84054fc968ee7fe2492eab.1311683981.git.richard.purdie@linuxfoundation.org>
Download mbox | patch
Permalink /patch/8553/
State New, archived
Headers show

Comments

Richard Purdie - July 26, 2011, 12:44 p.m.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
 meta/conf/machine/include/mips/arch-mips.inc |   64 +++++++++++++++++++++++++-
 meta/conf/machine/include/tune-mips32.inc    |   10 +++-
 2 files changed, 71 insertions(+), 3 deletions(-)
Mark Hatle - July 26, 2011, 2:41 p.m.
Few quick items here:

On 7/26/11 7:44 AM, Richard Purdie wrote:
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
>  meta/conf/machine/include/mips/arch-mips.inc |   64 +++++++++++++++++++++++++-
>  meta/conf/machine/include/tune-mips32.inc    |   10 +++-
>  2 files changed, 71 insertions(+), 3 deletions(-)
> 
> diff --git a/meta/conf/machine/include/mips/arch-mips.inc b/meta/conf/machine/include/mips/arch-mips.inc
> index f7f4eed..071e6b5 100644
> --- a/meta/conf/machine/include/mips/arch-mips.inc
> +++ b/meta/conf/machine/include/mips/arch-mips.inc
> @@ -1 +1,63 @@
...

> +# Floating point
> +TUNEVALID[fpu-hard] = "Use hardware FPU"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "-mhard-float", "-msoft-float", d)}"
> +TARGET_FPU = "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "", "soft", d)}"
> +
> +# Package naming
> +MIPSPKGSFX_ENDIAN = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "", "el", d)}"
> +MIPSPKGSFX_BYTE = "${@bb.utils.contains("TUNE_FEATURES", "n64" , "64", "", d)}"

n32 is also MIPS64.

so a:

MIPSPKGSFX_BYTE .= "${@bb.utils.contains("TUNE_FEATURES", "n32" , "64", "", d)}"

should fix the issue.

> +TUNE_ARCH = "mips${MIPSPKGSFX_BYTE}${MIPSPKGSFX_ENDIAN}"
> +
> +# Base tunes
> +AVAILTUNES += "mips mips64-n32 mips64 mipsel mips64el-n32 mips64el mips-nf mips64-nf-n32 mips64-nf mipsel-nf mips64el-nf-n32 mips64el-nf"
> +TUNE_FEATURES_tune-mips = "o32 bigendian fpu-hard"
> +BASE_LIB_tune-mips = "lib"
> +TUNE_FEATURES_tune-mips64-n32 = "n32 bigendian fpu-hard"
> +BASE_LIB_tune-mips64-n32 = "lib32"
> +TUNE_FEATURES_tune-mips64 = "n64 bigendian fpu-hard"
> +BASE_LIB_tune-mips64 = "lib64"
> +TUNE_FEATURES_tune-mipsel = "o32 fpu-hard"
> +BASE_LIB_tune-mipsel = "lib"
> +TUNE_FEATURES_tune-mips64el-n32 = "n32 fpu-hard"
> +BASE_LIB_tune-mips64el-n32 = "lib32"
> +TUNE_FEATURES_tune-mips64el = "n64 fpu-hard"
> +BASE_LIB_tune-mips64el = "lib64"
> +TUNE_FEATURES_tune-mips-nf = "o32 bigendian"
> +BASE_LIB_tune-mips-nf = "lib"
> +TUNE_FEATURES_tune-mips64-nf-n32 = "n32 bigendian"
> +BASE_LIB_tune-mips64-nf-n32 = "lib32"
> +TUNE_FEATURES_tune-mips64-nf = "n64 bigendian"
> +BASE_LIB_tune-mips64-nf = "lib64"
> +TUNE_FEATURES_tune-mipsel-nf = "o32"
> +BASE_LIB_tune-mipsel-nf = "lib"
> +TUNE_FEATURES_tune-mips64el-nf-n32 = "n32"
> +BASE_LIB_tune-mips64el-nf-n32 = "lib32"
> +TUNE_FEATURES_tune-mips64el-nf = "n64"
> +BASE_LIB_tune-mips64el-nf = "lib64"
> +
> diff --git a/meta/conf/machine/include/tune-mips32.inc b/meta/conf/machine/include/tune-mips32.inc
> index 28b0047..1f913df 100644
> --- a/meta/conf/machine/include/tune-mips32.inc
> +++ b/meta/conf/machine/include/tune-mips32.inc
> @@ -1,4 +1,10 @@
> +DEFAULTTUNE ?= "mips32"
> +
>  require conf/machine/include/mips/arch-mips.inc
>  
> -TUNE_CCARGS = "-march=mips32"
> -TUNE_PKGARCH = "mips"
> +TUNEVALID[mips32] = "Enable mips32 specific processor optimizations"

If tune-mips32 is used, then all of the n32 and n64 variants are not possible.
Do we have a way to specify that?  Perhaps using the TUNECONFLICT?

> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "mips32", "-march=mips32", "", d)}"
> +
> +AVAILTUNES += "mips32"
> +TUNE_FEATURES_tune-mips32 = "${TUNE_FEATURES_tune-mips} mips32"
> +PACKAGE_EXTRA_ARCHS_tune-mips32 = "mips"
Richard Purdie - July 26, 2011, 4:51 p.m.
On Tue, 2011-07-26 at 09:41 -0500, Mark Hatle wrote:
> Few quick items here:
> 
> On 7/26/11 7:44 AM, Richard Purdie wrote:
> > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> > ---
> >  meta/conf/machine/include/mips/arch-mips.inc |   64 +++++++++++++++++++++++++-
> >  meta/conf/machine/include/tune-mips32.inc    |   10 +++-
> >  2 files changed, 71 insertions(+), 3 deletions(-)
> > 
> > diff --git a/meta/conf/machine/include/mips/arch-mips.inc b/meta/conf/machine/include/mips/arch-mips.inc
> > index f7f4eed..071e6b5 100644
> > --- a/meta/conf/machine/include/mips/arch-mips.inc
> > +++ b/meta/conf/machine/include/mips/arch-mips.inc
> > @@ -1 +1,63 @@
> ...
> 
> > +# Floating point
> > +TUNEVALID[fpu-hard] = "Use hardware FPU"
> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "-mhard-float", "-msoft-float", d)}"
> > +TARGET_FPU = "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "", "soft", d)}"
> > +
> > +# Package naming
> > +MIPSPKGSFX_ENDIAN = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "", "el", d)}"
> > +MIPSPKGSFX_BYTE = "${@bb.utils.contains("TUNE_FEATURES", "n64" , "64", "", d)}"
> 
> n32 is also MIPS64.
> 
> so a:
> 
> MIPSPKGSFX_BYTE .= "${@bb.utils.contains("TUNE_FEATURES", "n32" , "64", "", d)}"
> 
> should fix the issue.
> 
> > +TUNE_ARCH = "mips${MIPSPKGSFX_BYTE}${MIPSPKGSFX_ENDIAN}"
> > +
> > +# Base tunes
> > +AVAILTUNES += "mips mips64-n32 mips64 mipsel mips64el-n32 mips64el mips-nf mips64-nf-n32 mips64-nf mipsel-nf mips64el-nf-n32 mips64el-nf"
> > +TUNE_FEATURES_tune-mips = "o32 bigendian fpu-hard"
> > +BASE_LIB_tune-mips = "lib"
> > +TUNE_FEATURES_tune-mips64-n32 = "n32 bigendian fpu-hard"
> > +BASE_LIB_tune-mips64-n32 = "lib32"
> > +TUNE_FEATURES_tune-mips64 = "n64 bigendian fpu-hard"
> > +BASE_LIB_tune-mips64 = "lib64"
> > +TUNE_FEATURES_tune-mipsel = "o32 fpu-hard"
> > +BASE_LIB_tune-mipsel = "lib"
> > +TUNE_FEATURES_tune-mips64el-n32 = "n32 fpu-hard"
> > +BASE_LIB_tune-mips64el-n32 = "lib32"
> > +TUNE_FEATURES_tune-mips64el = "n64 fpu-hard"
> > +BASE_LIB_tune-mips64el = "lib64"
> > +TUNE_FEATURES_tune-mips-nf = "o32 bigendian"
> > +BASE_LIB_tune-mips-nf = "lib"
> > +TUNE_FEATURES_tune-mips64-nf-n32 = "n32 bigendian"
> > +BASE_LIB_tune-mips64-nf-n32 = "lib32"
> > +TUNE_FEATURES_tune-mips64-nf = "n64 bigendian"
> > +BASE_LIB_tune-mips64-nf = "lib64"
> > +TUNE_FEATURES_tune-mipsel-nf = "o32"
> > +BASE_LIB_tune-mipsel-nf = "lib"
> > +TUNE_FEATURES_tune-mips64el-nf-n32 = "n32"
> > +BASE_LIB_tune-mips64el-nf-n32 = "lib32"
> > +TUNE_FEATURES_tune-mips64el-nf = "n64"
> > +BASE_LIB_tune-mips64el-nf = "lib64"
> > +
> > diff --git a/meta/conf/machine/include/tune-mips32.inc b/meta/conf/machine/include/tune-mips32.inc
> > index 28b0047..1f913df 100644
> > --- a/meta/conf/machine/include/tune-mips32.inc
> > +++ b/meta/conf/machine/include/tune-mips32.inc
> > @@ -1,4 +1,10 @@
> > +DEFAULTTUNE ?= "mips32"
> > +
> >  require conf/machine/include/mips/arch-mips.inc
> >  
> > -TUNE_CCARGS = "-march=mips32"
> > -TUNE_PKGARCH = "mips"
> > +TUNEVALID[mips32] = "Enable mips32 specific processor optimizations"
> 
> If tune-mips32 is used, then all of the n32 and n64 variants are not possible.
> Do we have a way to specify that?  Perhaps using the TUNECONFLICT?

Agreed, TUNE_CONFLICTS is the way to go. I've updated the patch on my
branch with this and the other tweak:

http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/ml4&id=2a31a7d38149b6bc972831964bfdeae7422c128c

Cheers,

Richard
Mark Hatle - July 26, 2011, 5:08 p.m.
On 7/26/11 11:51 AM, Richard Purdie wrote:
> On Tue, 2011-07-26 at 09:41 -0500, Mark Hatle wrote:
>> Few quick items here:
>>
>> On 7/26/11 7:44 AM, Richard Purdie wrote:
>>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>>> ---
>>>  meta/conf/machine/include/mips/arch-mips.inc |   64 +++++++++++++++++++++++++-
>>>  meta/conf/machine/include/tune-mips32.inc    |   10 +++-
>>>  2 files changed, 71 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/meta/conf/machine/include/mips/arch-mips.inc b/meta/conf/machine/include/mips/arch-mips.inc
>>> index f7f4eed..071e6b5 100644
>>> --- a/meta/conf/machine/include/mips/arch-mips.inc
>>> +++ b/meta/conf/machine/include/mips/arch-mips.inc
>>> @@ -1 +1,63 @@
>> ...
>>
>>> +# Floating point
>>> +TUNEVALID[fpu-hard] = "Use hardware FPU"
>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "-mhard-float", "-msoft-float", d)}"
>>> +TARGET_FPU = "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "", "soft", d)}"
>>> +
>>> +# Package naming
>>> +MIPSPKGSFX_ENDIAN = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "", "el", d)}"
>>> +MIPSPKGSFX_BYTE = "${@bb.utils.contains("TUNE_FEATURES", "n64" , "64", "", d)}"
>>
>> n32 is also MIPS64.
>>
>> so a:
>>
>> MIPSPKGSFX_BYTE .= "${@bb.utils.contains("TUNE_FEATURES", "n32" , "64", "", d)}"
>>
>> should fix the issue.
>>
>>> +TUNE_ARCH = "mips${MIPSPKGSFX_BYTE}${MIPSPKGSFX_ENDIAN}"
>>> +
>>> +# Base tunes
>>> +AVAILTUNES += "mips mips64-n32 mips64 mipsel mips64el-n32 mips64el mips-nf mips64-nf-n32 mips64-nf mipsel-nf mips64el-nf-n32 mips64el-nf"
>>> +TUNE_FEATURES_tune-mips = "o32 bigendian fpu-hard"
>>> +BASE_LIB_tune-mips = "lib"
>>> +TUNE_FEATURES_tune-mips64-n32 = "n32 bigendian fpu-hard"
>>> +BASE_LIB_tune-mips64-n32 = "lib32"
>>> +TUNE_FEATURES_tune-mips64 = "n64 bigendian fpu-hard"
>>> +BASE_LIB_tune-mips64 = "lib64"
>>> +TUNE_FEATURES_tune-mipsel = "o32 fpu-hard"
>>> +BASE_LIB_tune-mipsel = "lib"
>>> +TUNE_FEATURES_tune-mips64el-n32 = "n32 fpu-hard"
>>> +BASE_LIB_tune-mips64el-n32 = "lib32"
>>> +TUNE_FEATURES_tune-mips64el = "n64 fpu-hard"
>>> +BASE_LIB_tune-mips64el = "lib64"
>>> +TUNE_FEATURES_tune-mips-nf = "o32 bigendian"
>>> +BASE_LIB_tune-mips-nf = "lib"
>>> +TUNE_FEATURES_tune-mips64-nf-n32 = "n32 bigendian"
>>> +BASE_LIB_tune-mips64-nf-n32 = "lib32"
>>> +TUNE_FEATURES_tune-mips64-nf = "n64 bigendian"
>>> +BASE_LIB_tune-mips64-nf = "lib64"
>>> +TUNE_FEATURES_tune-mipsel-nf = "o32"
>>> +BASE_LIB_tune-mipsel-nf = "lib"
>>> +TUNE_FEATURES_tune-mips64el-nf-n32 = "n32"
>>> +BASE_LIB_tune-mips64el-nf-n32 = "lib32"
>>> +TUNE_FEATURES_tune-mips64el-nf = "n64"
>>> +BASE_LIB_tune-mips64el-nf = "lib64"
>>> +
>>> diff --git a/meta/conf/machine/include/tune-mips32.inc b/meta/conf/machine/include/tune-mips32.inc
>>> index 28b0047..1f913df 100644
>>> --- a/meta/conf/machine/include/tune-mips32.inc
>>> +++ b/meta/conf/machine/include/tune-mips32.inc
>>> @@ -1,4 +1,10 @@
>>> +DEFAULTTUNE ?= "mips32"
>>> +
>>>  require conf/machine/include/mips/arch-mips.inc
>>>  
>>> -TUNE_CCARGS = "-march=mips32"
>>> -TUNE_PKGARCH = "mips"
>>> +TUNEVALID[mips32] = "Enable mips32 specific processor optimizations"
>>
>> If tune-mips32 is used, then all of the n32 and n64 variants are not possible.
>> Do we have a way to specify that?  Perhaps using the TUNECONFLICT?
> 
> Agreed, TUNE_CONFLICTS is the way to go. I've updated the patch on my
> branch with this and the other tweak:
> 
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/ml4&id=2a31a7d38149b6bc972831964bfdeae7422c128c

Looks good..

Acked-by: Mark Hatle <mark.hatle@windriver.com>

> Cheers,
> 
> Richard
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Khem Raj - July 26, 2011, 7:47 p.m.
On Tue, Jul 26, 2011 at 5:44 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
>  meta/conf/machine/include/mips/arch-mips.inc |   64 +++++++++++++++++++++++++-
>  meta/conf/machine/include/tune-mips32.inc    |   10 +++-
>  2 files changed, 71 insertions(+), 3 deletions(-)
>
> diff --git a/meta/conf/machine/include/mips/arch-mips.inc b/meta/conf/machine/include/mips/arch-mips.inc
> index f7f4eed..071e6b5 100644
> --- a/meta/conf/machine/include/mips/arch-mips.inc
> +++ b/meta/conf/machine/include/mips/arch-mips.inc
> @@ -1 +1,63 @@
> -TUNE_ARCH = "mips"
> +# 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)}"
> +
> +# ABI flags
> +TUNEVALID[o32] = "MIPS o32 ABI"
> +TUNECONFLICT[o32] = "n32 n64"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "o32", "-mabi=32", "", d)}"
> +
> +TUNEVALID[n32] = "MIPS64 n32 ABI"
> +TUNECONFLICT[n32] = "o32 n64"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "n32", "-mabi=n32", "", d)}"
> +
> +TUNEVALID[n64] = "MIPS64 n64 ABI"
> +TUNECONFLICT[n64] = "o32 n32"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "n64", "-mabi=64", "", d)}"
> +
> +# Floating point
> +TUNEVALID[fpu-hard] = "Use hardware FPU"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "-mhard-float", "-msoft-float", d)}"
> +TARGET_FPU = "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "", "soft", d)}"
> +
> +# Package naming
> +MIPSPKGSFX_ENDIAN = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "", "el", d)}"
> +MIPSPKGSFX_BYTE = "${@bb.utils.contains("TUNE_FEATURES", "n64" , "64", "", d)}"
> +
> +TUNE_ARCH = "mips${MIPSPKGSFX_BYTE}${MIPSPKGSFX_ENDIAN}"
> +
> +# Base tunes
> +AVAILTUNES += "mips mips64-n32 mips64 mipsel mips64el-n32 mips64el mips-nf mips64-nf-n32 mips64-nf mipsel-nf mips64el-nf-n32 mips64el-nf"

may be nf should be called nofpu to make it a familiar term.

> +TUNE_FEATURES_tune-mips = "o32 bigendian fpu-hard"
> +BASE_LIB_tune-mips = "lib"
> +TUNE_FEATURES_tune-mips64-n32 = "n32 bigendian fpu-hard"
> +BASE_LIB_tune-mips64-n32 = "lib32"
> +TUNE_FEATURES_tune-mips64 = "n64 bigendian fpu-hard"
> +BASE_LIB_tune-mips64 = "lib64"
> +TUNE_FEATURES_tune-mipsel = "o32 fpu-hard"
> +BASE_LIB_tune-mipsel = "lib"
> +TUNE_FEATURES_tune-mips64el-n32 = "n32 fpu-hard"
> +BASE_LIB_tune-mips64el-n32 = "lib32"
> +TUNE_FEATURES_tune-mips64el = "n64 fpu-hard"
> +BASE_LIB_tune-mips64el = "lib64"
> +TUNE_FEATURES_tune-mips-nf = "o32 bigendian"
> +BASE_LIB_tune-mips-nf = "lib"
> +TUNE_FEATURES_tune-mips64-nf-n32 = "n32 bigendian"
> +BASE_LIB_tune-mips64-nf-n32 = "lib32"
> +TUNE_FEATURES_tune-mips64-nf = "n64 bigendian"
> +BASE_LIB_tune-mips64-nf = "lib64"
> +TUNE_FEATURES_tune-mipsel-nf = "o32"
> +BASE_LIB_tune-mipsel-nf = "lib"
> +TUNE_FEATURES_tune-mips64el-nf-n32 = "n32"
> +BASE_LIB_tune-mips64el-nf-n32 = "lib32"
> +TUNE_FEATURES_tune-mips64el-nf = "n64"
> +BASE_LIB_tune-mips64el-nf = "lib64"
> +
> diff --git a/meta/conf/machine/include/tune-mips32.inc b/meta/conf/machine/include/tune-mips32.inc
> index 28b0047..1f913df 100644
> --- a/meta/conf/machine/include/tune-mips32.inc
> +++ b/meta/conf/machine/include/tune-mips32.inc
> @@ -1,4 +1,10 @@
> +DEFAULTTUNE ?= "mips32"
> +
>  require conf/machine/include/mips/arch-mips.inc
>
> -TUNE_CCARGS = "-march=mips32"
> -TUNE_PKGARCH = "mips"
> +TUNEVALID[mips32] = "Enable mips32 specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "mips32", "-march=mips32", "", d)}"
> +
> +AVAILTUNES += "mips32"
> +TUNE_FEATURES_tune-mips32 = "${TUNE_FEATURES_tune-mips} mips32"
> +PACKAGE_EXTRA_ARCHS_tune-mips32 = "mips"
> --
> 1.7.4.1
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Phil Blundell - Aug. 11, 2011, 11:25 a.m.
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.

p.
Richard Purdie - Aug. 11, 2011, 12:08 p.m.
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
Phil Blundell - Aug. 11, 2011, 12:29 p.m.
On Thu, 2011-08-11 at 13:08 +0100, Richard Purdie wrote:
> 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...

Okay.  So, if I let arch-mips.inc set TARGET_ARCH for itself then it
picks "mipsel", which is the second case I mentioned above and leads to
the -mips1 failure.  I guess this means that either uclibc's usage of
overrides needs fixing, or arch-mips ought to be putting "mips" into
${OVERRIDES}.

More generally, it seems as though having TARGET_ARCH in ${OVERRIDES} is
probably going to be fairly useless if that value now includes all the
decorations for ABI features, since it is going to be hard/impossible to
get it to match reliably.

Does the new tune model provide any variable which represents the
underlying CPU architecture ("arm", "mips")?  That seems to be what's
really wanted in almost all the cases where TARGET_ARCH is being used as
an OVERRIDE.

p.
Richard Purdie - Aug. 11, 2011, 2:28 p.m.
On Thu, 2011-08-11 at 13:29 +0100, Phil Blundell wrote:
> On Thu, 2011-08-11 at 13:08 +0100, Richard Purdie wrote:
> > 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...
> 
> Okay.  So, if I let arch-mips.inc set TARGET_ARCH for itself then it
> picks "mipsel", which is the second case I mentioned above and leads to
> the -mips1 failure.  I guess this means that either uclibc's usage of
> overrides needs fixing, or arch-mips ought to be putting "mips" into
> ${OVERRIDES}.
> 
> More generally, it seems as though having TARGET_ARCH in ${OVERRIDES} is
> probably going to be fairly useless if that value now includes all the
> decorations for ABI features, since it is going to be hard/impossible to
> get it to match reliably.

I don't think this is a new problem, its just being brought to the
surface with these changes.

> Does the new tune model provide any variable which represents the
> underlying CPU architecture ("arm", "mips")?  That seems to be what's
> really wanted in almost all the cases where TARGET_ARCH is being used as
> an OVERRIDE.

Not currently but this does sound like a good idea.

The old approach to this was always ugly (was it i586 or i686 or x86? or
i386/i486 for that matter?). The arch/tune files provide a good place to
try and clean this up, cleaning up OVERRIDES for an added bonus.

The problem is we'd traditionally had variables which get overloaded to
many different meanings. We're hopefully getting to grips with that and
this would make another good step in that direction.

Cheers,

Richard
Khem Raj - Aug. 11, 2011, 2:49 p.m.
On Thursday, August 11, 2011 01:29:38 PM Phil Blundell wrote:
> On Thu, 2011-08-11 at 13:08 +0100, Richard Purdie wrote:
> > 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...
> 
> Okay.  So, if I let arch-mips.inc set TARGET_ARCH for itself then it
> picks "mipsel", which is the second case I mentioned above and leads to
> the -mips1 failure.  I guess this means that either uclibc's usage of
> overrides needs fixing, or arch-mips ought to be putting "mips" into
> ${OVERRIDES}.

uclibc's configuration can now be simplified a bit with new tune files
right now it uses target arch heavily.

> 
> More generally, it seems as though having TARGET_ARCH in ${OVERRIDES} is
> probably going to be fairly useless if that value now includes all the
> decorations for ABI features, since it is going to be hard/impossible to
> get it to match reliably.
> 
> Does the new tune model provide any variable which represents the
> underlying CPU architecture ("arm", "mips")?  That seems to be what's
> really wanted in almost all the cases where TARGET_ARCH is being used as
> an OVERRIDE.

yeah I think major cpu architecture would be nice to have in overrides
e.g. mips for mipseb and mipsel. We dont need endianness info since we
can deduce that from tune features in todays setup.

> 
> p.
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Mark Hatle - Aug. 11, 2011, 3:54 p.m.
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@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Phil Blundell - Aug. 12, 2011, 2:35 p.m.
On Thu, 2011-08-11 at 07:49 -0700, Khem Raj wrote:
> yeah I think major cpu architecture would be nice to have in overrides
> e.g. mips for mipseb and mipsel. We dont need endianness info since we
> can deduce that from tune features in todays setup.

I'm not entirely convinced it's wholesome for random recipes to start
poking around inside TUNE_FEATURES.  SITEINFO_ENDIANNESS seems like the
cleanest way for recipes to get that information.

p.
Khem Raj - Aug. 12, 2011, 3:28 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/12/2011 07:35 AM, Phil Blundell wrote:
> On Thu, 2011-08-11 at 07:49 -0700, Khem Raj wrote:
>> yeah I think major cpu architecture would be nice to have in
>> overrides e.g. mips for mipseb and mipsel. We dont need endianness
>> info since we can deduce that from tune features in todays setup.
> 
> I'm not entirely convinced it's wholesome for random recipes to
> start poking around inside TUNE_FEATURES.  SITEINFO_ENDIANNESS seems
> like the cleanest way for recipes to get that information.

yes. for endianness thats better to get it from SITEINFO_ENDIANNESS so
far TARGET_ARCH was being used which should be improved.

> 
> p.
> 
> 
> 
> _______________________________________________ Openembedded-core
> mailing list Openembedded-core@lists.openembedded.org 
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk5FRoMACgkQuwUzVZGdMxRoSACeLo3/aWiLbQn86+ZoxQDw4rXR
7zoAnA0TxTF7fDFQgLsgOWqji/KEz7hJ
=0IKr
-----END PGP SIGNATURE-----

Patch

diff --git a/meta/conf/machine/include/mips/arch-mips.inc b/meta/conf/machine/include/mips/arch-mips.inc
index f7f4eed..071e6b5 100644
--- a/meta/conf/machine/include/mips/arch-mips.inc
+++ b/meta/conf/machine/include/mips/arch-mips.inc
@@ -1 +1,63 @@ 
-TUNE_ARCH = "mips"
+# 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)}"
+
+# ABI flags
+TUNEVALID[o32] = "MIPS o32 ABI"
+TUNECONFLICT[o32] = "n32 n64"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "o32", "-mabi=32", "", d)}"
+
+TUNEVALID[n32] = "MIPS64 n32 ABI"
+TUNECONFLICT[n32] = "o32 n64"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "n32", "-mabi=n32", "", d)}"
+
+TUNEVALID[n64] = "MIPS64 n64 ABI"
+TUNECONFLICT[n64] = "o32 n32"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "n64", "-mabi=64", "", d)}"
+
+# Floating point
+TUNEVALID[fpu-hard] = "Use hardware FPU"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "-mhard-float", "-msoft-float", d)}"
+TARGET_FPU = "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "", "soft", d)}"
+
+# Package naming
+MIPSPKGSFX_ENDIAN = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "", "el", d)}"
+MIPSPKGSFX_BYTE = "${@bb.utils.contains("TUNE_FEATURES", "n64" , "64", "", d)}"
+
+TUNE_ARCH = "mips${MIPSPKGSFX_BYTE}${MIPSPKGSFX_ENDIAN}"
+
+# Base tunes
+AVAILTUNES += "mips mips64-n32 mips64 mipsel mips64el-n32 mips64el mips-nf mips64-nf-n32 mips64-nf mipsel-nf mips64el-nf-n32 mips64el-nf"
+TUNE_FEATURES_tune-mips = "o32 bigendian fpu-hard"
+BASE_LIB_tune-mips = "lib"
+TUNE_FEATURES_tune-mips64-n32 = "n32 bigendian fpu-hard"
+BASE_LIB_tune-mips64-n32 = "lib32"
+TUNE_FEATURES_tune-mips64 = "n64 bigendian fpu-hard"
+BASE_LIB_tune-mips64 = "lib64"
+TUNE_FEATURES_tune-mipsel = "o32 fpu-hard"
+BASE_LIB_tune-mipsel = "lib"
+TUNE_FEATURES_tune-mips64el-n32 = "n32 fpu-hard"
+BASE_LIB_tune-mips64el-n32 = "lib32"
+TUNE_FEATURES_tune-mips64el = "n64 fpu-hard"
+BASE_LIB_tune-mips64el = "lib64"
+TUNE_FEATURES_tune-mips-nf = "o32 bigendian"
+BASE_LIB_tune-mips-nf = "lib"
+TUNE_FEATURES_tune-mips64-nf-n32 = "n32 bigendian"
+BASE_LIB_tune-mips64-nf-n32 = "lib32"
+TUNE_FEATURES_tune-mips64-nf = "n64 bigendian"
+BASE_LIB_tune-mips64-nf = "lib64"
+TUNE_FEATURES_tune-mipsel-nf = "o32"
+BASE_LIB_tune-mipsel-nf = "lib"
+TUNE_FEATURES_tune-mips64el-nf-n32 = "n32"
+BASE_LIB_tune-mips64el-nf-n32 = "lib32"
+TUNE_FEATURES_tune-mips64el-nf = "n64"
+BASE_LIB_tune-mips64el-nf = "lib64"
+
diff --git a/meta/conf/machine/include/tune-mips32.inc b/meta/conf/machine/include/tune-mips32.inc
index 28b0047..1f913df 100644
--- a/meta/conf/machine/include/tune-mips32.inc
+++ b/meta/conf/machine/include/tune-mips32.inc
@@ -1,4 +1,10 @@ 
+DEFAULTTUNE ?= "mips32"
+
 require conf/machine/include/mips/arch-mips.inc
 
-TUNE_CCARGS = "-march=mips32"
-TUNE_PKGARCH = "mips"
+TUNEVALID[mips32] = "Enable mips32 specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "mips32", "-march=mips32", "", d)}"
+
+AVAILTUNES += "mips32"
+TUNE_FEATURES_tune-mips32 = "${TUNE_FEATURES_tune-mips} mips32"
+PACKAGE_EXTRA_ARCHS_tune-mips32 = "mips"