Patchwork [3/3] Add basic PowerPC core tune config

login
register
mail settings
Submitter Richard Purdie
Date July 26, 2011, 12:44 p.m.
Message ID <992efbf4ec3d7c55346953dbe82f9745590e64bf.1311683981.git.richard.purdie@linuxfoundation.org>
Download mbox | patch
Permalink /patch/8555/
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/powerpc/arch-powerpc.inc |   45 +++++++++++++++++++-
 meta/conf/machine/include/tune-ppc603e.inc         |   12 ++++-
 meta/conf/machine/include/tune-ppce300c2.inc       |   12 ++++-
 meta/conf/machine/include/tune-ppce500.inc         |   13 ++++--
 meta/conf/machine/include/tune-ppce500mc.inc       |   12 ++++-
 meta/conf/machine/include/tune-ppce500v2.inc       |   12 ++++-
 6 files changed, 88 insertions(+), 18 deletions(-)
Kumar Gala - July 26, 2011, 1:47 p.m.
On Jul 26, 2011, at 7:44 AM, Richard Purdie wrote:

> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
> meta/conf/machine/include/powerpc/arch-powerpc.inc |   45 +++++++++++++++++++-
> meta/conf/machine/include/tune-ppc603e.inc         |   12 ++++-
> meta/conf/machine/include/tune-ppce300c2.inc       |   12 ++++-
> meta/conf/machine/include/tune-ppce500.inc         |   13 ++++--
> meta/conf/machine/include/tune-ppce500mc.inc       |   12 ++++-
> meta/conf/machine/include/tune-ppce500v2.inc       |   12 ++++-
> 6 files changed, 88 insertions(+), 18 deletions(-)

One thing I'm wondering about as we do this is the ability to pass --with-cpu to gcc & [e]glibc configure to pickup proper optimized cfgs & libs for a given target.

- k
Richard Purdie - July 26, 2011, 1:59 p.m.
On Tue, 2011-07-26 at 08:47 -0500, Kumar Gala wrote:
> On Jul 26, 2011, at 7:44 AM, Richard Purdie wrote:
> 
> > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> > ---
> > meta/conf/machine/include/powerpc/arch-powerpc.inc |   45 +++++++++++++++++++-
> > meta/conf/machine/include/tune-ppc603e.inc         |   12 ++++-
> > meta/conf/machine/include/tune-ppce300c2.inc       |   12 ++++-
> > meta/conf/machine/include/tune-ppce500.inc         |   13 ++++--
> > meta/conf/machine/include/tune-ppce500mc.inc       |   12 ++++-
> > meta/conf/machine/include/tune-ppce500v2.inc       |   12 ++++-
> > 6 files changed, 88 insertions(+), 18 deletions(-)
> 
> One thing I'm wondering about as we do this is the ability to pass
> --with-cpu to gcc & [e]glibc configure to pickup proper optimized cfgs
> & libs for a given target.

As far as I can tell, gcc 4.x has no --with-cpu option. We pass the
correct march and mtune options to the compiler at runtime through
CFLAGS and friends.

You're already found the way to pass configuration to *libc using values
in TARGET_FPU to pickup the right configuration.

Is there a use case we're missing?

Cheers,

Richard
Mark Hatle - July 26, 2011, 2:57 p.m.
Comments below...

On 7/26/11 7:44 AM, Richard Purdie wrote:
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
>  meta/conf/machine/include/powerpc/arch-powerpc.inc |   45 +++++++++++++++++++-
>  meta/conf/machine/include/tune-ppc603e.inc         |   12 ++++-
>  meta/conf/machine/include/tune-ppce300c2.inc       |   12 ++++-
>  meta/conf/machine/include/tune-ppce500.inc         |   13 ++++--
>  meta/conf/machine/include/tune-ppce500mc.inc       |   12 ++++-
>  meta/conf/machine/include/tune-ppce500v2.inc       |   12 ++++-
>  6 files changed, 88 insertions(+), 18 deletions(-)
> 
> diff --git a/meta/conf/machine/include/powerpc/arch-powerpc.inc b/meta/conf/machine/include/powerpc/arch-powerpc.inc
> index 17ace32..3f7befb 100644
> --- a/meta/conf/machine/include/powerpc/arch-powerpc.inc
> +++ b/meta/conf/machine/include/powerpc/arch-powerpc.inc
> @@ -1,3 +1,44 @@
> -TUNE_ARCH = "powerpc"
> +# Power Architecture definition
> +# Four defined ABIs, all combinations of:
> +# *) Hard/Soft Floating Point
> +# *) 32-bit/64-bit
> +
> +DEFAULTTUNE ?= "powerpc"
> +
> +TUNEVALID[m32] = "Power ELF32 standard ABI"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32", "", d)}"
> +
> +TUNEVALID[m32-arch] = "Enable powerpc package architecture"
> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m32-arch" ], "powerpc", "", d)}"
> +
> +TUNEVALID[m64] = "Power ELF64 standard ABI"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "n64", "-m64", "", d)}"
> +
> +TUNEVALID[m64-arch] = "Enable powerpc64 package architecture"
> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m64-arch" ], "powerpc64", "", d)}"

Why m32-arch and m64-arch?  If m32 or m64 is selected then it should mean
powerpc or powerpc64.

> +TUNEVALID[fpu-hard] = "Use hardware FPU."
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "-mhard-float", "", d)}"
> +
> +TUNEVALID[fpu-soft] = "Use software FPU."
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft", "-msoft-float", "", d)}"
> +TARGET_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft", "soft", "", d)}"

Why specify both fpu-hard and fpu-soft?  The "unusual" ABI is fpu-soft.  It
would simplify it to only have to specify one, and you get the other automatically.

> +TUNEVALID[spe] = "Enable SPE ABI extensions"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "spe", "-mabi=spe -mspe", "", d)}"
> +
> +ABIEXTENSION = "${@['','spe'][d.getVar('TARGET_FPU', True) in ['ppc-efd', 'ppc-efs']]}"

SPE instructions are specific to certain processors and not generic across all
of PPC.  I would move this to each of the tunes where it may be used.

Also I see the ABIEXTENSION, but where is it being set?

In the core PowerPC specification there are two ABIs defined.  The standard
classic PPC FPU hard-float (this is the long-running default), and a no-float
version that avoids passing via FPU registers.

There is a variant of the soft-float specific to certain processors.. each
processor has it's own variant depending on what registers it has.  e500(v1 -
single precision) and e500v2 (double precision) each have their own variants.  I
believe there is also an e300 variant that has a completely different SPE as well.

I assume from the above ppc-efd is double and efs is single...  Perhaps an e500
tune file that specific the ABI extension and has knowledge of both e500(v1) and
e500v2?

> +# Basic tune definitions
> +AVAILTUNES += "powerpc powerpc-nf" 
> +TUNE_FEATURES_tune-powerpc ?= "m32 m32-arch fpu-hard"
> +BASE_LIB_tune-powerpc = "lib"
> +TUNE_FEATURES_tune-powerpc-nf ?= "m32 m32-arch fpu-soft"
> +BASE_LIB_tune-powerpc-nf = "lib"
> +
> +AVAILTUNES += "powerpc64 powerpc64-nf"
> +TUNE_FEATURES_tune-powerpc64 ?= "m64 m64-arch fpu-hard"
> +BASE_LIB_tune-powerpc64 = "lib64"
> +TUNE_FEATURES_tune-powerpc64-nf ?= "m64 m64-arch fpu-soft"
> +BASE_LIB_tune-powerpc64-nf = "lib64"
>  
> -ABIEXTENSION = "${@['','spe'][bb.data.getVar('TARGET_FPU',d,1) in ['ppc-efd', 'ppc-efs']]}"
> diff --git a/meta/conf/machine/include/tune-ppc603e.inc b/meta/conf/machine/include/tune-ppc603e.inc
> index 61c0669..6991ae0 100644
> --- a/meta/conf/machine/include/tune-ppc603e.inc
> +++ b/meta/conf/machine/include/tune-ppc603e.inc
> @@ -1,5 +1,11 @@
> +DEFAULTTUNE ?= "ppc603e"
> +
>  require conf/machine/include/powerpc/arch-powerpc.inc
>  
> -TUNE_CCARGS = "-mcpu=603e  -mhard-float"
> -TUNE_PKGARCH = "ppc603e"
> -PACKAGE_EXTRA_ARCHS = "powerpc ppc603e"
> +TUNEVALID[ppc603e] = "Enable ppc603e specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "-mcpu=603e", "", d)}"
> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "ppc603e", "", d)}"
> +
> +AVAILTUNES += "ppc603e"
> +TUNE_FEATURES_tune-ppc603e = "m32 fpu-hard ppc603e"
> +PACKAGE_EXTRA_ARCHS_tune-ppc603e = "powerpc ppc603e"

Going back to my original comment, the m32-arch is missing... or m32 should mean
"powerpc" (my suggestion).

> diff --git a/meta/conf/machine/include/tune-ppce300c2.inc b/meta/conf/machine/include/tune-ppce300c2.inc
> index a38e97c..652422f 100644
> --- a/meta/conf/machine/include/tune-ppce300c2.inc
> +++ b/meta/conf/machine/include/tune-ppce300c2.inc
> @@ -1,5 +1,11 @@
> +DEFAULTTUNE ?= "ppce300"
> +
>  require conf/machine/include/powerpc/arch-powerpc.inc
>  
> -TUNE_CCARGS = "-mcpu=e300c2 -msoft-float"
> -TUNE_PKGARCH = "ppce300"
> -PACKAGE_EXTRA_ARCHS = "powerpc ppce300"
> +TUNEVALID[ppce300] = "Enable ppce300 specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce300", "-mcpu=e300c2", "", d)}"
> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce300", "ppce300", "", d)}"
> +
> +AVAILTUNES += "ppce300"
> +TUNE_FEATURES_tune-ppce300 = "m32 fpu-soft ppce300"
> +PACKAGE_EXTRA_ARCHS_tune-ppce300 = "powerpc ppce300"

There is also a ppce300 as well as the e300c2, so I'd change the option to be
fully qualified.  (One has floating point one doesn't..)

> diff --git a/meta/conf/machine/include/tune-ppce500.inc b/meta/conf/machine/include/tune-ppce500.inc
> index 22208f0..fe62445 100644
> --- a/meta/conf/machine/include/tune-ppce500.inc
> +++ b/meta/conf/machine/include/tune-ppce500.inc
> @@ -1,6 +1,11 @@
> +DEFAULTTUNE ?= "ppce500"
> +
>  require conf/machine/include/powerpc/arch-powerpc.inc
>  
> -TUNE_CCARGS = "-mcpu=8540"
> -BASE_PACKAGE_ARCH = "ppce500"
> -TUNE_PKGARCH = "ppce500"
> -PACKAGE_EXTRA_ARCHS = "powerpc ppce500"
> +TUNEVALID[ppce500] = "Enable ppce500 specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500", "-mcpu=8540", "", d)}"
> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce500", "ppce500", "", d)}"
> +
> +AVAILTUNES += "ppce500"
> +TUNE_FEATURES_tune-ppce500 = "m32 ppce500"
> +PACKAGE_EXTRA_ARCHS_tune-ppce500 = "powerpc ppce500"

This is the single precision e500 -- it should be specifying it's floating point
type.

> diff --git a/meta/conf/machine/include/tune-ppce500mc.inc b/meta/conf/machine/include/tune-ppce500mc.inc
> index 182d019..0d3640f 100644
> --- a/meta/conf/machine/include/tune-ppce500mc.inc
> +++ b/meta/conf/machine/include/tune-ppce500mc.inc
> @@ -1,5 +1,11 @@
> +DEFAULTTUNE ?= "ppce500mc"
> +
>  require conf/machine/include/powerpc/arch-powerpc.inc
>  
> -TUNE_CCARGS = "-mcpu=e500mc"
> -TUNE_PKGARCH = "ppce500mc"
> -PACKAGE_EXTRA_ARCHS = "powerpc ppce500mc"
> +TUNEVALID[ppce500mc] = "Enable ppce500mc specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "-mcpu=e500mc", "", d)}"
> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "ppce500mc", "", d)}"
> +
> +AVAILTUNES += "ppce500mc"
> +TUNE_FEATURES_tune-ppce500mc = "m32 ppce500mc"
> +PACKAGE_EXTRA_ARCHS_tune-ppce500mc = "powerpc ppce500mc"

e500mc using the classic "hard-float" floating point unit.

> diff --git a/meta/conf/machine/include/tune-ppce500v2.inc b/meta/conf/machine/include/tune-ppce500v2.inc
> index daf2d58..e6b48a2 100644
> --- a/meta/conf/machine/include/tune-ppce500v2.inc
> +++ b/meta/conf/machine/include/tune-ppce500v2.inc
> @@ -1,5 +1,11 @@
> +DEFAULTTUNE ?= "ppce500v2"
> +
>  require conf/machine/include/powerpc/arch-powerpc.inc
>  
> -TUNE_CCARGS = "-mcpu=8548 -mabi=spe -mspe"
> -TUNE_PKGARCH = "ppce500v2"
> -PACKAGE_EXTRA_ARCHS = "powerpc ppce500v2"
> +TUNEVALID[ppce500mc] = "Enable ppce500mc specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500v2", "-mcpu=8548", "", d)}"
> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce500v2", "ppce500v2", "", d)}"
> +
> +AVAILTUNES += "ppce500v2"
> +TUNE_FEATURES_tune-ppce500v2 = "m32 spe ppce500v2"
> +PACKAGE_EXTRA_ARCHS_tune-ppce500v2 = "powerpc ppce500v2"

This one is double precision.
Mark Hatle - July 26, 2011, 2:59 p.m.
On 7/26/11 8:59 AM, Richard Purdie wrote:
> On Tue, 2011-07-26 at 08:47 -0500, Kumar Gala wrote:
>> On Jul 26, 2011, at 7:44 AM, Richard Purdie wrote:
>>
>>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>>> ---
>>> meta/conf/machine/include/powerpc/arch-powerpc.inc |   45 +++++++++++++++++++-
>>> meta/conf/machine/include/tune-ppc603e.inc         |   12 ++++-
>>> meta/conf/machine/include/tune-ppce300c2.inc       |   12 ++++-
>>> meta/conf/machine/include/tune-ppce500.inc         |   13 ++++--
>>> meta/conf/machine/include/tune-ppce500mc.inc       |   12 ++++-
>>> meta/conf/machine/include/tune-ppce500v2.inc       |   12 ++++-
>>> 6 files changed, 88 insertions(+), 18 deletions(-)
>>
>> One thing I'm wondering about as we do this is the ability to pass
>> --with-cpu to gcc & [e]glibc configure to pickup proper optimized cfgs
>> & libs for a given target.
> 
> As far as I can tell, gcc 4.x has no --with-cpu option. We pass the
> correct march and mtune options to the compiler at runtime through
> CFLAGS and friends.
> 
> You're already found the way to pass configuration to *libc using values
> in TARGET_FPU to pickup the right configuration.
> 
> Is there a use case we're missing?

glibc is capable of some processor specific optimizations.  So you can say I
want e500 or ppc603e or... as it's base configuration.  This is useful on MIPS
as well.

My suggestion would be to use the TUNE_FEATURES in eglibc to figure out what
option(s) we want to pass to glibc.  (We could also use the tune name, but I'd
be afraid that the names could change arbitrarily over time..  the tune_features
I would expect to have a longer life span.)

--Mark

> Cheers,
> 
> Richard
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Kumar Gala - July 26, 2011, 3:22 p.m.
On Jul 26, 2011, at 8:59 AM, Richard Purdie wrote:

> On Tue, 2011-07-26 at 08:47 -0500, Kumar Gala wrote:
>> On Jul 26, 2011, at 7:44 AM, Richard Purdie wrote:
>> 
>>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>>> ---
>>> meta/conf/machine/include/powerpc/arch-powerpc.inc |   45 +++++++++++++++++++-
>>> meta/conf/machine/include/tune-ppc603e.inc         |   12 ++++-
>>> meta/conf/machine/include/tune-ppce300c2.inc       |   12 ++++-
>>> meta/conf/machine/include/tune-ppce500.inc         |   13 ++++--
>>> meta/conf/machine/include/tune-ppce500mc.inc       |   12 ++++-
>>> meta/conf/machine/include/tune-ppce500v2.inc       |   12 ++++-
>>> 6 files changed, 88 insertions(+), 18 deletions(-)
>> 
>> One thing I'm wondering about as we do this is the ability to pass
>> --with-cpu to gcc & [e]glibc configure to pickup proper optimized cfgs
>> & libs for a given target.
> 
> As far as I can tell, gcc 4.x has no --with-cpu option. We pass the
> correct march and mtune options to the compiler at runtime through
> CFLAGS and friends.

Hmm, gcc still supports this:

http://gcc.gnu.org/install/configure.html

--with-cpu=cpu
--with-cpu-32=cpu
--with-cpu-64=cpu
Specify which cpu variant the compiler should generate code for by default. cpu will be used as the default value of the -mcpu= switch. This option is only supported on some targets, including ARM, i386, M68k, PowerPC, and SPARC. The --with-cpu-32 and --with-cpu-64 options specify separate default CPUs for 32-bit and 64-bit modes; these options are only supported for i386, x86-64 and PowerPC. 

http://gcc.gnu.org/install/specific.html

powerpc-*-*
You can specify a default version for the -mcpu=cpu_type switch by using the configure option --with-cpu-cpu_type.

> You're already found the way to pass configuration to *libc using values
> in TARGET_FPU to pickup the right configuration.
> 
> Is there a use case we're missing?

Yes, for [e]glibc we have optimized libc functions for a given / specific PPC processor.  So we need someway to tell configure this.

- k
Richard Purdie - July 26, 2011, 4:18 p.m.
On Tue, 2011-07-26 at 10:22 -0500, Kumar Gala wrote:
> On Jul 26, 2011, at 8:59 AM, Richard Purdie wrote:
> 
> > On Tue, 2011-07-26 at 08:47 -0500, Kumar Gala wrote:
> >> On Jul 26, 2011, at 7:44 AM, Richard Purdie wrote:
> >> 
> >>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> >>> ---
> >>> meta/conf/machine/include/powerpc/arch-powerpc.inc |   45 +++++++++++++++++++-
> >>> meta/conf/machine/include/tune-ppc603e.inc         |   12 ++++-
> >>> meta/conf/machine/include/tune-ppce300c2.inc       |   12 ++++-
> >>> meta/conf/machine/include/tune-ppce500.inc         |   13 ++++--
> >>> meta/conf/machine/include/tune-ppce500mc.inc       |   12 ++++-
> >>> meta/conf/machine/include/tune-ppce500v2.inc       |   12 ++++-
> >>> 6 files changed, 88 insertions(+), 18 deletions(-)
> >> 
> >> One thing I'm wondering about as we do this is the ability to pass
> >> --with-cpu to gcc & [e]glibc configure to pickup proper optimized cfgs
> >> & libs for a given target.
> > 
> > As far as I can tell, gcc 4.x has no --with-cpu option. We pass the
> > correct march and mtune options to the compiler at runtime through
> > CFLAGS and friends.
> 
> Hmm, gcc still supports this:
> 
> http://gcc.gnu.org/install/configure.html
> 
> --with-cpu=cpu
> --with-cpu-32=cpu
> --with-cpu-64=cpu
> Specify which cpu variant the compiler should generate code for by default. cpu will be used as the default value of the -mcpu= switch. This option is only supported on some targets, including ARM, i386, M68k, PowerPC, and SPARC. The --with-cpu-32 and --with-cpu-64 options specify separate default CPUs for 32-bit and 64-bit modes; these options are only supported for i386, x86-64 and PowerPC. 
> 
> http://gcc.gnu.org/install/specific.html
> 
> powerpc-*-*
> You can specify a default version for the -mcpu=cpu_type switch by using the configure option --with-cpu-cpu_type.

I couldn't find that looking at the configure script :/.

Anyhow, according to that page, its to "Specify which cpu variant the
compiler should generate code for by default. cpu will be used as the
default value of the -mcpu= switch". Since we always specify -mcpu when
needed, I don't believe this is an issue for us as far as the build
system goes.

If you're talking about the gcc we build for the target, we should
really encode all the cpu/tune options in there, not just part of the
config so again, I don't think its appropriate to the way we use gcc.

> > You're already found the way to pass configuration to *libc using values
> > in TARGET_FPU to pickup the right configuration.
> > 
> > Is there a use case we're missing?
> 
> Yes, for [e]glibc we have optimized libc functions for a given /
> specific PPC processor.  So we need someway to tell configure this.

I'd do this by looking for flags in TUNE_FEATURES as Mark has also
mentioned.

Cheers,

Richard
Richard Purdie - July 26, 2011, 4:36 p.m.
On Tue, 2011-07-26 at 09:57 -0500, Mark Hatle wrote:
> On 7/26/11 7:44 AM, Richard Purdie wrote:
> > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> > ---
> >  meta/conf/machine/include/powerpc/arch-powerpc.inc |   45 +++++++++++++++++++-
> >  meta/conf/machine/include/tune-ppc603e.inc         |   12 ++++-
> >  meta/conf/machine/include/tune-ppce300c2.inc       |   12 ++++-
> >  meta/conf/machine/include/tune-ppce500.inc         |   13 ++++--
> >  meta/conf/machine/include/tune-ppce500mc.inc       |   12 ++++-
> >  meta/conf/machine/include/tune-ppce500v2.inc       |   12 ++++-
> >  6 files changed, 88 insertions(+), 18 deletions(-)
> > 
> > diff --git a/meta/conf/machine/include/powerpc/arch-powerpc.inc b/meta/conf/machine/include/powerpc/arch-powerpc.inc
> > index 17ace32..3f7befb 100644
> > --- a/meta/conf/machine/include/powerpc/arch-powerpc.inc
> > +++ b/meta/conf/machine/include/powerpc/arch-powerpc.inc
> > @@ -1,3 +1,44 @@
> > -TUNE_ARCH = "powerpc"
> > +# Power Architecture definition
> > +# Four defined ABIs, all combinations of:
> > +# *) Hard/Soft Floating Point
> > +# *) 32-bit/64-bit
> > +
> > +DEFAULTTUNE ?= "powerpc"
> > +
> > +TUNEVALID[m32] = "Power ELF32 standard ABI"
> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32", "", d)}"
> > +
> > +TUNEVALID[m32-arch] = "Enable powerpc package architecture"
> > +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m32-arch" ], "powerpc", "", d)}"
> > +
> > +TUNEVALID[m64] = "Power ELF64 standard ABI"
> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "n64", "-m64", "", d)}"
> > +
> > +TUNEVALID[m64-arch] = "Enable powerpc64 package architecture"
> > +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m64-arch" ], "powerpc64", "", d)}"
> 
> Why m32-arch and m64-arch?  If m32 or m64 is selected then it should mean
> powerpc or powerpc64.

I've gotten confused here and mixed up TUNE_ARCH and TUNE_PKGARCH but
there was a reason.

The missing piece is 

TUNE_PKGARCH ?= "${TUNE_ARCH}"

and the trouble comes when a tune file wants to change this only when
its tune config is in action.

I'm thinking ahead to trying a mixed ppc 32 and 64 bit build where
TUNE_PKGARCH needs to take on the values for both configs.

> > +TUNEVALID[fpu-hard] = "Use hardware FPU."
> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "-mhard-float", "", d)}"
> > +
> > +TUNEVALID[fpu-soft] = "Use software FPU."
> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft", "-msoft-float", "", d)}"
> > +TARGET_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft", "soft", "", d)}"
> 
> Why specify both fpu-hard and fpu-soft?  The "unusual" ABI is fpu-soft.  It
> would simplify it to only have to specify one, and you get the other automatically.

The trouble is the spe pieces which seemed to imply TARGET_FPU should
take on a value of other than "soft". Setting it to "soft" if fpu-hard
isn't in TUNE_FEATURES therefore wasn't enough...

> > +TUNEVALID[spe] = "Enable SPE ABI extensions"
> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "spe", "-mabi=spe -mspe", "", d)}"
> > +
> > +ABIEXTENSION = "${@['','spe'][d.getVar('TARGET_FPU', True) in ['ppc-efd', 'ppc-efs']]}"
> 
> SPE instructions are specific to certain processors and not generic across all
> of PPC.  I would move this to each of the tunes where it may be used.

I guess this should be a feature file like thumb on arm?

> Also I see the ABIEXTENSION, but where is it being set?

I'm just migrating the existing code in that regard, I'm also puzzled as
to where that is getting set currently.

> > +# Basic tune definitions
> > +AVAILTUNES += "powerpc powerpc-nf" 
> > +TUNE_FEATURES_tune-powerpc ?= "m32 m32-arch fpu-hard"
> > +BASE_LIB_tune-powerpc = "lib"
> > +TUNE_FEATURES_tune-powerpc-nf ?= "m32 m32-arch fpu-soft"
> > +BASE_LIB_tune-powerpc-nf = "lib"
> > +
> > +AVAILTUNES += "powerpc64 powerpc64-nf"
> > +TUNE_FEATURES_tune-powerpc64 ?= "m64 m64-arch fpu-hard"
> > +BASE_LIB_tune-powerpc64 = "lib64"
> > +TUNE_FEATURES_tune-powerpc64-nf ?= "m64 m64-arch fpu-soft"
> > +BASE_LIB_tune-powerpc64-nf = "lib64"
> >  
> > -ABIEXTENSION = "${@['','spe'][bb.data.getVar('TARGET_FPU',d,1) in ['ppc-efd', 'ppc-efs']]}"
> > diff --git a/meta/conf/machine/include/tune-ppc603e.inc b/meta/conf/machine/include/tune-ppc603e.inc
> > index 61c0669..6991ae0 100644
> > --- a/meta/conf/machine/include/tune-ppc603e.inc
> > +++ b/meta/conf/machine/include/tune-ppc603e.inc
> > @@ -1,5 +1,11 @@
> > +DEFAULTTUNE ?= "ppc603e"
> > +
> >  require conf/machine/include/powerpc/arch-powerpc.inc
> >  
> > -TUNE_CCARGS = "-mcpu=603e  -mhard-float"
> > -TUNE_PKGARCH = "ppc603e"
> > -PACKAGE_EXTRA_ARCHS = "powerpc ppc603e"
> > +TUNEVALID[ppc603e] = "Enable ppc603e specific processor optimizations"
> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "-mcpu=603e", "", d)}"
> > +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "ppc603e", "", d)}"
> > +
> > +AVAILTUNES += "ppc603e"
> > +TUNE_FEATURES_tune-ppc603e = "m32 fpu-hard ppc603e"
> > +PACKAGE_EXTRA_ARCHS_tune-ppc603e = "powerpc ppc603e"
> 
> Going back to my original comment, the m32-arch is missing... or m32 should mean
> "powerpc" (my suggestion).

No, TUNE_ARCH should be TUNE_PKGARCH above, then this makes more
sense...

> > diff --git a/meta/conf/machine/include/tune-ppce300c2.inc b/meta/conf/machine/include/tune-ppce300c2.inc
> > index a38e97c..652422f 100644
> > --- a/meta/conf/machine/include/tune-ppce300c2.inc
> > +++ b/meta/conf/machine/include/tune-ppce300c2.inc
> > @@ -1,5 +1,11 @@
> > +DEFAULTTUNE ?= "ppce300"
> > +
> >  require conf/machine/include/powerpc/arch-powerpc.inc
> >  
> > -TUNE_CCARGS = "-mcpu=e300c2 -msoft-float"
> > -TUNE_PKGARCH = "ppce300"
> > -PACKAGE_EXTRA_ARCHS = "powerpc ppce300"
> > +TUNEVALID[ppce300] = "Enable ppce300 specific processor optimizations"
> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce300", "-mcpu=e300c2", "", d)}"
> > +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce300", "ppce300", "", d)}"
> > +
> > +AVAILTUNES += "ppce300"
> > +TUNE_FEATURES_tune-ppce300 = "m32 fpu-soft ppce300"
> > +PACKAGE_EXTRA_ARCHS_tune-ppce300 = "powerpc ppce300"
> 
> There is also a ppce300 as well as the e300c2, so I'd change the option to be
> fully qualified.  (One has floating point one doesn't..)

Fair enough.

> > diff --git a/meta/conf/machine/include/tune-ppce500.inc b/meta/conf/machine/include/tune-ppce500.inc
> > index 22208f0..fe62445 100644
> > --- a/meta/conf/machine/include/tune-ppce500.inc
> > +++ b/meta/conf/machine/include/tune-ppce500.inc
> > @@ -1,6 +1,11 @@
> > +DEFAULTTUNE ?= "ppce500"
> > +
> >  require conf/machine/include/powerpc/arch-powerpc.inc
> >  
> > -TUNE_CCARGS = "-mcpu=8540"
> > -BASE_PACKAGE_ARCH = "ppce500"
> > -TUNE_PKGARCH = "ppce500"
> > -PACKAGE_EXTRA_ARCHS = "powerpc ppce500"
> > +TUNEVALID[ppce500] = "Enable ppce500 specific processor optimizations"
> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500", "-mcpu=8540", "", d)}"
> > +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce500", "ppce500", "", d)}"
> > +
> > +AVAILTUNES += "ppce500"
> > +TUNE_FEATURES_tune-ppce500 = "m32 ppce500"
> > +PACKAGE_EXTRA_ARCHS_tune-ppce500 = "powerpc ppce500"
> 
> This is the single precision e500 -- it should be specifying it's floating point
> type.

which is? :)

> > diff --git a/meta/conf/machine/include/tune-ppce500mc.inc b/meta/conf/machine/include/tune-ppce500mc.inc
> > index 182d019..0d3640f 100644
> > --- a/meta/conf/machine/include/tune-ppce500mc.inc
> > +++ b/meta/conf/machine/include/tune-ppce500mc.inc
> > @@ -1,5 +1,11 @@
> > +DEFAULTTUNE ?= "ppce500mc"
> > +
> >  require conf/machine/include/powerpc/arch-powerpc.inc
> >  
> > -TUNE_CCARGS = "-mcpu=e500mc"
> > -TUNE_PKGARCH = "ppce500mc"
> > -PACKAGE_EXTRA_ARCHS = "powerpc ppce500mc"
> > +TUNEVALID[ppce500mc] = "Enable ppce500mc specific processor optimizations"
> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "-mcpu=e500mc", "", d)}"
> > +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "ppce500mc", "", d)}"
> > +
> > +AVAILTUNES += "ppce500mc"
> > +TUNE_FEATURES_tune-ppce500mc = "m32 ppce500mc"
> > +PACKAGE_EXTRA_ARCHS_tune-ppce500mc = "powerpc ppce500mc"
> 
> e500mc using the classic "hard-float" floating point unit.

ok, so its hard-fpu...

> > diff --git a/meta/conf/machine/include/tune-ppce500v2.inc b/meta/conf/machine/include/tune-ppce500v2.inc
> > index daf2d58..e6b48a2 100644
> > --- a/meta/conf/machine/include/tune-ppce500v2.inc
> > +++ b/meta/conf/machine/include/tune-ppce500v2.inc
> > @@ -1,5 +1,11 @@
> > +DEFAULTTUNE ?= "ppce500v2"
> > +
> >  require conf/machine/include/powerpc/arch-powerpc.inc
> >  
> > -TUNE_CCARGS = "-mcpu=8548 -mabi=spe -mspe"
> > -TUNE_PKGARCH = "ppce500v2"
> > -PACKAGE_EXTRA_ARCHS = "powerpc ppce500v2"
> > +TUNEVALID[ppce500mc] = "Enable ppce500mc specific processor optimizations"
> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500v2", "-mcpu=8548", "", d)}"
> > +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce500v2", "ppce500v2", "", d)}"
> > +
> > +AVAILTUNES += "ppce500v2"
> > +TUNE_FEATURES_tune-ppce500v2 = "m32 spe ppce500v2"
> > +PACKAGE_EXTRA_ARCHS_tune-ppce500v2 = "powerpc ppce500v2"
> 
> This one is double precision.

so hard-fpu?

Cheers,

Richard
Mark Hatle - July 26, 2011, 4:53 p.m.
On 7/26/11 11:36 AM, Richard Purdie wrote:
> On Tue, 2011-07-26 at 09:57 -0500, Mark Hatle wrote:
>> On 7/26/11 7:44 AM, Richard Purdie wrote:
>>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>>> ---
>>>  meta/conf/machine/include/powerpc/arch-powerpc.inc |   45 +++++++++++++++++++-
>>>  meta/conf/machine/include/tune-ppc603e.inc         |   12 ++++-
>>>  meta/conf/machine/include/tune-ppce300c2.inc       |   12 ++++-
>>>  meta/conf/machine/include/tune-ppce500.inc         |   13 ++++--
>>>  meta/conf/machine/include/tune-ppce500mc.inc       |   12 ++++-
>>>  meta/conf/machine/include/tune-ppce500v2.inc       |   12 ++++-
>>>  6 files changed, 88 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/meta/conf/machine/include/powerpc/arch-powerpc.inc b/meta/conf/machine/include/powerpc/arch-powerpc.inc
>>> index 17ace32..3f7befb 100644
>>> --- a/meta/conf/machine/include/powerpc/arch-powerpc.inc
>>> +++ b/meta/conf/machine/include/powerpc/arch-powerpc.inc
>>> @@ -1,3 +1,44 @@
>>> -TUNE_ARCH = "powerpc"
>>> +# Power Architecture definition
>>> +# Four defined ABIs, all combinations of:
>>> +# *) Hard/Soft Floating Point
>>> +# *) 32-bit/64-bit
>>> +
>>> +DEFAULTTUNE ?= "powerpc"
>>> +
>>> +TUNEVALID[m32] = "Power ELF32 standard ABI"
>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32", "", d)}"
>>> +
>>> +TUNEVALID[m32-arch] = "Enable powerpc package architecture"
>>> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m32-arch" ], "powerpc", "", d)}"
>>> +
>>> +TUNEVALID[m64] = "Power ELF64 standard ABI"
>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "n64", "-m64", "", d)}"
>>> +
>>> +TUNEVALID[m64-arch] = "Enable powerpc64 package architecture"
>>> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m64-arch" ], "powerpc64", "", d)}"
>>
>> Why m32-arch and m64-arch?  If m32 or m64 is selected then it should mean
>> powerpc or powerpc64.
> 
> I've gotten confused here and mixed up TUNE_ARCH and TUNE_PKGARCH but
> there was a reason.
> 
> The missing piece is 
> 
> TUNE_PKGARCH ?= "${TUNE_ARCH}"
> 
> and the trouble comes when a tune file wants to change this only when
> its tune config is in action.
> 
> I'm thinking ahead to trying a mixed ppc 32 and 64 bit build where
> TUNE_PKGARCH needs to take on the values for both configs.

As far as I can tell, in all cases m32 = powerpc and m64 = powerpc64..  There is
no way to mix a build of ppc32 and ppc64 w/o using the multilib code.

The m32/m64 is the ABI, so only one can be present in the TUNE_FEATURES.. and
passed via gcc through the TUNE_CCARGS.

>>> +TUNEVALID[fpu-hard] = "Use hardware FPU."
>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "-mhard-float", "", d)}"
>>> +
>>> +TUNEVALID[fpu-soft] = "Use software FPU."
>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft", "-msoft-float", "", d)}"
>>> +TARGET_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft", "soft", "", d)}"
>>
>> Why specify both fpu-hard and fpu-soft?  The "unusual" ABI is fpu-soft.  It
>> would simplify it to only have to specify one, and you get the other automatically.
> 
> The trouble is the spe pieces which seemed to imply TARGET_FPU should
> take on a value of other than "soft". Setting it to "soft" if fpu-hard
> isn't in TUNE_FEATURES therefore wasn't enough...

Can you do something like:

TARGET_FPU = "${@...if "fpu" is not in TUNE_FEATURES..., "hard"}"
TARGET_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft", "soft", "", d)}"

Then later in the tune's that have unique spe units..

TARGET_FPU .= "${@bb.utils.contains("TUNE_FEATURES", [ "e500", "fpu-spe" ],
"ppc-efs", "", d)}"

TARGET_FPU .= "${@bb.utils.contains("TUNE_FEATURES", [ "e500", "fpu-spe" ],
"ppc-efd", "", d)}"

>>> +TUNEVALID[spe] = "Enable SPE ABI extensions"
>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "spe", "-mabi=spe -mspe", "", d)}"
>>> +
>>> +ABIEXTENSION = "${@['','spe'][d.getVar('TARGET_FPU', True) in ['ppc-efd', 'ppc-efs']]}"
>>
>> SPE instructions are specific to certain processors and not generic across all
>> of PPC.  I would move this to each of the tunes where it may be used.
> 
> I guess this should be a feature file like thumb on arm?

Unfortunately it's SoC specific on PowerPC.  There is no uniform definition of
an SPE unit.. (SPE stands for Special Purpose Execution..  by spec, the SPE can
use any instruction set, and do any set of operations.. the individual cores
define what the SPE instructions do.  The e500 and e500v2 have their own unique
SPEs that do math-like functionality.  Other cores use the SPE instructions for
encryption services, multimedia, etc...)

Thats why the SPE settings need to be in the individual tune files, they are
unique to each core.

>> Also I see the ABIEXTENSION, but where is it being set?
> 
> I'm just migrating the existing code in that regard, I'm also puzzled as
> to where that is getting set currently.

I think this is something we need to fix.  The ABIEXTENSION contents look
reasonable, but again, I believe it's really core specific.

>>> +# Basic tune definitions
>>> +AVAILTUNES += "powerpc powerpc-nf" 
>>> +TUNE_FEATURES_tune-powerpc ?= "m32 m32-arch fpu-hard"
>>> +BASE_LIB_tune-powerpc = "lib"
>>> +TUNE_FEATURES_tune-powerpc-nf ?= "m32 m32-arch fpu-soft"
>>> +BASE_LIB_tune-powerpc-nf = "lib"
>>> +
>>> +AVAILTUNES += "powerpc64 powerpc64-nf"
>>> +TUNE_FEATURES_tune-powerpc64 ?= "m64 m64-arch fpu-hard"
>>> +BASE_LIB_tune-powerpc64 = "lib64"
>>> +TUNE_FEATURES_tune-powerpc64-nf ?= "m64 m64-arch fpu-soft"
>>> +BASE_LIB_tune-powerpc64-nf = "lib64"
>>>  
>>> -ABIEXTENSION = "${@['','spe'][bb.data.getVar('TARGET_FPU',d,1) in ['ppc-efd', 'ppc-efs']]}"
>>> diff --git a/meta/conf/machine/include/tune-ppc603e.inc b/meta/conf/machine/include/tune-ppc603e.inc
>>> index 61c0669..6991ae0 100644
>>> --- a/meta/conf/machine/include/tune-ppc603e.inc
>>> +++ b/meta/conf/machine/include/tune-ppc603e.inc
>>> @@ -1,5 +1,11 @@
>>> +DEFAULTTUNE ?= "ppc603e"
>>> +
>>>  require conf/machine/include/powerpc/arch-powerpc.inc
>>>  
>>> -TUNE_CCARGS = "-mcpu=603e  -mhard-float"
>>> -TUNE_PKGARCH = "ppc603e"
>>> -PACKAGE_EXTRA_ARCHS = "powerpc ppc603e"
>>> +TUNEVALID[ppc603e] = "Enable ppc603e specific processor optimizations"
>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "-mcpu=603e", "", d)}"
>>> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "ppc603e", "", d)}"
>>> +
>>> +AVAILTUNES += "ppc603e"
>>> +TUNE_FEATURES_tune-ppc603e = "m32 fpu-hard ppc603e"
>>> +PACKAGE_EXTRA_ARCHS_tune-ppc603e = "powerpc ppc603e"
>>
>> Going back to my original comment, the m32-arch is missing... or m32 should mean
>> "powerpc" (my suggestion).
> 
> No, TUNE_ARCH should be TUNE_PKGARCH above, then this makes more
> sense...

Yes, I understand.. TUNE_ARCH is the canonical arch, TUNE_PKGARCH is what to
call the packages generated.

So in the above features, if TUNE_ARCH is used as implemented m32-arch is
missing -- but on Power there are only two current options and the m32/m64
should be able to switch them.

>>> diff --git a/meta/conf/machine/include/tune-ppce300c2.inc b/meta/conf/machine/include/tune-ppce300c2.inc
>>> index a38e97c..652422f 100644
>>> --- a/meta/conf/machine/include/tune-ppce300c2.inc
>>> +++ b/meta/conf/machine/include/tune-ppce300c2.inc
>>> @@ -1,5 +1,11 @@
>>> +DEFAULTTUNE ?= "ppce300"
>>> +
>>>  require conf/machine/include/powerpc/arch-powerpc.inc
>>>  
>>> -TUNE_CCARGS = "-mcpu=e300c2 -msoft-float"
>>> -TUNE_PKGARCH = "ppce300"
>>> -PACKAGE_EXTRA_ARCHS = "powerpc ppce300"
>>> +TUNEVALID[ppce300] = "Enable ppce300 specific processor optimizations"
>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce300", "-mcpu=e300c2", "", d)}"
>>> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce300", "ppce300", "", d)}"
>>> +
>>> +AVAILTUNES += "ppce300"
>>> +TUNE_FEATURES_tune-ppce300 = "m32 fpu-soft ppce300"
>>> +PACKAGE_EXTRA_ARCHS_tune-ppce300 = "powerpc ppce300"
>>
>> There is also a ppce300 as well as the e300c2, so I'd change the option to be
>> fully qualified.  (One has floating point one doesn't..)
> 
> Fair enough.
> 
>>> diff --git a/meta/conf/machine/include/tune-ppce500.inc b/meta/conf/machine/include/tune-ppce500.inc
>>> index 22208f0..fe62445 100644
>>> --- a/meta/conf/machine/include/tune-ppce500.inc
>>> +++ b/meta/conf/machine/include/tune-ppce500.inc
>>> @@ -1,6 +1,11 @@
>>> +DEFAULTTUNE ?= "ppce500"
>>> +
>>>  require conf/machine/include/powerpc/arch-powerpc.inc
>>>  
>>> -TUNE_CCARGS = "-mcpu=8540"
>>> -BASE_PACKAGE_ARCH = "ppce500"
>>> -TUNE_PKGARCH = "ppce500"
>>> -PACKAGE_EXTRA_ARCHS = "powerpc ppce500"
>>> +TUNEVALID[ppce500] = "Enable ppce500 specific processor optimizations"
>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500", "-mcpu=8540", "", d)}"
>>> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce500", "ppce500", "", d)}"
>>> +
>>> +AVAILTUNES += "ppce500"
>>> +TUNE_FEATURES_tune-ppce500 = "m32 ppce500"
>>> +PACKAGE_EXTRA_ARCHS_tune-ppce500 = "powerpc ppce500"
>>
>> This is the single precision e500 -- it should be specifying it's floating point
>> type.
> 
> which is? :)

Based on the above, ppc-efs..  (I believe these names are completely arbitrary...)

Ohh didn't notice before, but once you enable the spe floating point, the
registers are used and it's no longer soft-float anymore.. (hard-float = classic
PPC floating point unit).  So the PACKAGE_EXTRA_ARCHS_tune-ppce500 should be
simply "ppce500"

>>> diff --git a/meta/conf/machine/include/tune-ppce500mc.inc b/meta/conf/machine/include/tune-ppce500mc.inc
>>> index 182d019..0d3640f 100644
>>> --- a/meta/conf/machine/include/tune-ppce500mc.inc
>>> +++ b/meta/conf/machine/include/tune-ppce500mc.inc
>>> @@ -1,5 +1,11 @@
>>> +DEFAULTTUNE ?= "ppce500mc"
>>> +
>>>  require conf/machine/include/powerpc/arch-powerpc.inc
>>>  
>>> -TUNE_CCARGS = "-mcpu=e500mc"
>>> -TUNE_PKGARCH = "ppce500mc"
>>> -PACKAGE_EXTRA_ARCHS = "powerpc ppce500mc"
>>> +TUNEVALID[ppce500mc] = "Enable ppce500mc specific processor optimizations"
>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "-mcpu=e500mc", "", d)}"
>>> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "ppce500mc", "", d)}"
>>> +
>>> +AVAILTUNES += "ppce500mc"
>>> +TUNE_FEATURES_tune-ppce500mc = "m32 ppce500mc"
>>> +PACKAGE_EXTRA_ARCHS_tune-ppce500mc = "powerpc ppce500mc"
>>
>> e500mc using the classic "hard-float" floating point unit.
> 
> ok, so its hard-fpu...

That is my understanding.  Hopefully someone can verify this...

>>> diff --git a/meta/conf/machine/include/tune-ppce500v2.inc b/meta/conf/machine/include/tune-ppce500v2.inc
>>> index daf2d58..e6b48a2 100644
>>> --- a/meta/conf/machine/include/tune-ppce500v2.inc
>>> +++ b/meta/conf/machine/include/tune-ppce500v2.inc
>>> @@ -1,5 +1,11 @@
>>> +DEFAULTTUNE ?= "ppce500v2"
>>> +
>>>  require conf/machine/include/powerpc/arch-powerpc.inc
>>>  
>>> -TUNE_CCARGS = "-mcpu=8548 -mabi=spe -mspe"
>>> -TUNE_PKGARCH = "ppce500v2"
>>> -PACKAGE_EXTRA_ARCHS = "powerpc ppce500v2"
>>> +TUNEVALID[ppce500mc] = "Enable ppce500mc specific processor optimizations"
>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500v2", "-mcpu=8548", "", d)}"
>>> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce500v2", "ppce500v2", "", d)}"
>>> +
>>> +AVAILTUNES += "ppce500v2"
>>> +TUNE_FEATURES_tune-ppce500v2 = "m32 spe ppce500v2"
>>> +PACKAGE_EXTRA_ARCHS_tune-ppce500v2 = "powerpc ppce500v2"
>>
>> This one is double precision.
> 
> so hard-fpu?

Nope.. this is the ppc-efd.  Note, again not compatible w/ "powerpc".. and NOT
compatible with "ppce500".  (Since they're different SPE units, the call passing
is different..)

Fun with extensible architectures.. :P

--Mark

> Cheers,
> 
> Richard
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Richard Purdie - July 26, 2011, 5:05 p.m.
On Tue, 2011-07-26 at 11:53 -0500, Mark Hatle wrote:
> On 7/26/11 11:36 AM, Richard Purdie wrote:
> > On Tue, 2011-07-26 at 09:57 -0500, Mark Hatle wrote:
> >> On 7/26/11 7:44 AM, Richard Purdie wrote:
> >>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> >>> ---
> >>>  meta/conf/machine/include/powerpc/arch-powerpc.inc |   45 +++++++++++++++++++-
> >>>  meta/conf/machine/include/tune-ppc603e.inc         |   12 ++++-
> >>>  meta/conf/machine/include/tune-ppce300c2.inc       |   12 ++++-
> >>>  meta/conf/machine/include/tune-ppce500.inc         |   13 ++++--
> >>>  meta/conf/machine/include/tune-ppce500mc.inc       |   12 ++++-
> >>>  meta/conf/machine/include/tune-ppce500v2.inc       |   12 ++++-
> >>>  6 files changed, 88 insertions(+), 18 deletions(-)
> >>>
> >>> diff --git a/meta/conf/machine/include/powerpc/arch-powerpc.inc b/meta/conf/machine/include/powerpc/arch-powerpc.inc
> >>> index 17ace32..3f7befb 100644
> >>> --- a/meta/conf/machine/include/powerpc/arch-powerpc.inc
> >>> +++ b/meta/conf/machine/include/powerpc/arch-powerpc.inc
> >>> @@ -1,3 +1,44 @@
> >>> -TUNE_ARCH = "powerpc"
> >>> +# Power Architecture definition
> >>> +# Four defined ABIs, all combinations of:
> >>> +# *) Hard/Soft Floating Point
> >>> +# *) 32-bit/64-bit
> >>> +
> >>> +DEFAULTTUNE ?= "powerpc"
> >>> +
> >>> +TUNEVALID[m32] = "Power ELF32 standard ABI"
> >>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32", "", d)}"
> >>> +
> >>> +TUNEVALID[m32-arch] = "Enable powerpc package architecture"
> >>> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m32-arch" ], "powerpc", "", d)}"
> >>> +
> >>> +TUNEVALID[m64] = "Power ELF64 standard ABI"
> >>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "n64", "-m64", "", d)}"
> >>> +
> >>> +TUNEVALID[m64-arch] = "Enable powerpc64 package architecture"
> >>> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m64-arch" ], "powerpc64", "", d)}"
> >>
> >> Why m32-arch and m64-arch?  If m32 or m64 is selected then it should mean
> >> powerpc or powerpc64.
> > 
> > I've gotten confused here and mixed up TUNE_ARCH and TUNE_PKGARCH but
> > there was a reason.
> > 
> > The missing piece is 
> > 
> > TUNE_PKGARCH ?= "${TUNE_ARCH}"
> > 
> > and the trouble comes when a tune file wants to change this only when
> > its tune config is in action.
> > 
> > I'm thinking ahead to trying a mixed ppc 32 and 64 bit build where
> > TUNE_PKGARCH needs to take on the values for both configs.
> 
> As far as I can tell, in all cases m32 = powerpc and m64 = powerpc64..  There is
> no way to mix a build of ppc32 and ppc64 w/o using the multilib code.
> 
> The m32/m64 is the ABI, so only one can be present in the TUNE_FEATURES.. and
> passed via gcc through the TUNE_CCARGS.

Ok, say I use tune-ppcXXX and it sets TUNE_PKGARCH:

TUNE_PKGARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "ppc603e", "", d)}"

and I want a multilib config using this as the m32 ABI and also have
powerpc64 as my other multilib. I can't select that as it will get
TUNE_PKGARCH wrong in the 64 bit case since:

TUNE_PKGARCH ?= "${TUNE_ARCH}"

is overwritten. I guess we could do:

TUNE_PKGARCH = "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "ppc603e", "${TUNE_ARCH}", d)}"

?

Cheers,

Richard
Mark Hatle - July 26, 2011, 5:15 p.m.
On 7/26/11 12:05 PM, Richard Purdie wrote:
> On Tue, 2011-07-26 at 11:53 -0500, Mark Hatle wrote:
>> On 7/26/11 11:36 AM, Richard Purdie wrote:
>>> On Tue, 2011-07-26 at 09:57 -0500, Mark Hatle wrote:
>>>> On 7/26/11 7:44 AM, Richard Purdie wrote:
>>>>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>>>>> ---
>>>>>  meta/conf/machine/include/powerpc/arch-powerpc.inc |   45 +++++++++++++++++++-
>>>>>  meta/conf/machine/include/tune-ppc603e.inc         |   12 ++++-
>>>>>  meta/conf/machine/include/tune-ppce300c2.inc       |   12 ++++-
>>>>>  meta/conf/machine/include/tune-ppce500.inc         |   13 ++++--
>>>>>  meta/conf/machine/include/tune-ppce500mc.inc       |   12 ++++-
>>>>>  meta/conf/machine/include/tune-ppce500v2.inc       |   12 ++++-
>>>>>  6 files changed, 88 insertions(+), 18 deletions(-)
>>>>>
>>>>> diff --git a/meta/conf/machine/include/powerpc/arch-powerpc.inc b/meta/conf/machine/include/powerpc/arch-powerpc.inc
>>>>> index 17ace32..3f7befb 100644
>>>>> --- a/meta/conf/machine/include/powerpc/arch-powerpc.inc
>>>>> +++ b/meta/conf/machine/include/powerpc/arch-powerpc.inc
>>>>> @@ -1,3 +1,44 @@
>>>>> -TUNE_ARCH = "powerpc"
>>>>> +# Power Architecture definition
>>>>> +# Four defined ABIs, all combinations of:
>>>>> +# *) Hard/Soft Floating Point
>>>>> +# *) 32-bit/64-bit
>>>>> +
>>>>> +DEFAULTTUNE ?= "powerpc"
>>>>> +
>>>>> +TUNEVALID[m32] = "Power ELF32 standard ABI"
>>>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32", "", d)}"
>>>>> +
>>>>> +TUNEVALID[m32-arch] = "Enable powerpc package architecture"
>>>>> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m32-arch" ], "powerpc", "", d)}"
>>>>> +
>>>>> +TUNEVALID[m64] = "Power ELF64 standard ABI"
>>>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "n64", "-m64", "", d)}"
>>>>> +
>>>>> +TUNEVALID[m64-arch] = "Enable powerpc64 package architecture"
>>>>> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m64-arch" ], "powerpc64", "", d)}"
>>>>
>>>> Why m32-arch and m64-arch?  If m32 or m64 is selected then it should mean
>>>> powerpc or powerpc64.
>>>
>>> I've gotten confused here and mixed up TUNE_ARCH and TUNE_PKGARCH but
>>> there was a reason.
>>>
>>> The missing piece is 
>>>
>>> TUNE_PKGARCH ?= "${TUNE_ARCH}"
>>>
>>> and the trouble comes when a tune file wants to change this only when
>>> its tune config is in action.
>>>
>>> I'm thinking ahead to trying a mixed ppc 32 and 64 bit build where
>>> TUNE_PKGARCH needs to take on the values for both configs.
>>
>> As far as I can tell, in all cases m32 = powerpc and m64 = powerpc64..  There is
>> no way to mix a build of ppc32 and ppc64 w/o using the multilib code.
>>
>> The m32/m64 is the ABI, so only one can be present in the TUNE_FEATURES.. and
>> passed via gcc through the TUNE_CCARGS.
> 
> Ok, say I use tune-ppcXXX and it sets TUNE_PKGARCH:
> 
> TUNE_PKGARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "ppc603e", "", d)}"
> 
> and I want a multilib config using this as the m32 ABI and also have
> powerpc64 as my other multilib. I can't select that as it will get
> TUNE_PKGARCH wrong in the 64 bit case since:
> 
> TUNE_PKGARCH ?= "${TUNE_ARCH}"
> 
> is overwritten. I guess we could do:
> 
> TUNE_PKGARCH = "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "ppc603e", "${TUNE_ARCH}", d)}"

ppc603e is the new option.. (lets say for argument it can run in 64-bit mode, in
reality it can't and is an invalid config....)

TUNEVALID[ppc603e] = "PowerPC 603e Optimization"

# Note the TUNE_NAME is used differently from the TUNE_FEATURES
TUNE_NAME ?= "ppc603e"

TUNE_FEATURES_ppc603e = "m32 ppc603e"
TUNE_FEATURES_ppc603e-64 = "m64 ppc603e"

The if you include the tune-ppc603e.inc the default is the 32-bit version (what
I'd consider the reasonable default...)  If you wanted the 64-bit version
instead you'd simply change set the TUNE_NAME to "ppc603e-64" and the properly
tuned set of features is set for you.

TUNE_PKGARCH_ppc603e = "ppc603e"
TUNE_PKGARCH_ppc603e-64 = "ppc603e-64"

etc...

in the default (ppc603e) case, the TUNE_ARCH should always be "powerpc", and in
the ppc603e-64 case (if manually enabled), it would be "powerpc64"...

This is what was done in the ARM cases and I believe the core2 case in ia32.

--Mark

> ?
> 
> Cheers,
> 
> Richard
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Richard Purdie - July 26, 2011, 7:21 p.m.
On Tue, 2011-07-26 at 12:15 -0500, Mark Hatle wrote:
> On 7/26/11 12:05 PM, Richard Purdie wrote:
> > On Tue, 2011-07-26 at 11:53 -0500, Mark Hatle wrote:
> >> On 7/26/11 11:36 AM, Richard Purdie wrote:
> >>> On Tue, 2011-07-26 at 09:57 -0500, Mark Hatle wrote:
> >>>> On 7/26/11 7:44 AM, Richard Purdie wrote:
> >>>>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> >>>>> ---
> >>>>>  meta/conf/machine/include/powerpc/arch-powerpc.inc |   45 +++++++++++++++++++-
> >>>>>  meta/conf/machine/include/tune-ppc603e.inc         |   12 ++++-
> >>>>>  meta/conf/machine/include/tune-ppce300c2.inc       |   12 ++++-
> >>>>>  meta/conf/machine/include/tune-ppce500.inc         |   13 ++++--
> >>>>>  meta/conf/machine/include/tune-ppce500mc.inc       |   12 ++++-
> >>>>>  meta/conf/machine/include/tune-ppce500v2.inc       |   12 ++++-
> >>>>>  6 files changed, 88 insertions(+), 18 deletions(-)
> >>>>>
> >>>>> diff --git a/meta/conf/machine/include/powerpc/arch-powerpc.inc b/meta/conf/machine/include/powerpc/arch-powerpc.inc
> >>>>> index 17ace32..3f7befb 100644
> >>>>> --- a/meta/conf/machine/include/powerpc/arch-powerpc.inc
> >>>>> +++ b/meta/conf/machine/include/powerpc/arch-powerpc.inc
> >>>>> @@ -1,3 +1,44 @@
> >>>>> -TUNE_ARCH = "powerpc"
> >>>>> +# Power Architecture definition
> >>>>> +# Four defined ABIs, all combinations of:
> >>>>> +# *) Hard/Soft Floating Point
> >>>>> +# *) 32-bit/64-bit
> >>>>> +
> >>>>> +DEFAULTTUNE ?= "powerpc"
> >>>>> +
> >>>>> +TUNEVALID[m32] = "Power ELF32 standard ABI"
> >>>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32", "", d)}"
> >>>>> +
> >>>>> +TUNEVALID[m32-arch] = "Enable powerpc package architecture"
> >>>>> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m32-arch" ], "powerpc", "", d)}"
> >>>>> +
> >>>>> +TUNEVALID[m64] = "Power ELF64 standard ABI"
> >>>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "n64", "-m64", "", d)}"
> >>>>> +
> >>>>> +TUNEVALID[m64-arch] = "Enable powerpc64 package architecture"
> >>>>> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m64-arch" ], "powerpc64", "", d)}"
> >>>>
> >>>> Why m32-arch and m64-arch?  If m32 or m64 is selected then it should mean
> >>>> powerpc or powerpc64.
> >>>
> >>> I've gotten confused here and mixed up TUNE_ARCH and TUNE_PKGARCH but
> >>> there was a reason.
> >>>
> >>> The missing piece is 
> >>>
> >>> TUNE_PKGARCH ?= "${TUNE_ARCH}"
> >>>
> >>> and the trouble comes when a tune file wants to change this only when
> >>> its tune config is in action.
> >>>
> >>> I'm thinking ahead to trying a mixed ppc 32 and 64 bit build where
> >>> TUNE_PKGARCH needs to take on the values for both configs.
> >>
> >> As far as I can tell, in all cases m32 = powerpc and m64 = powerpc64..  There is
> >> no way to mix a build of ppc32 and ppc64 w/o using the multilib code.
> >>
> >> The m32/m64 is the ABI, so only one can be present in the TUNE_FEATURES.. and
> >> passed via gcc through the TUNE_CCARGS.
> > 
> > Ok, say I use tune-ppcXXX and it sets TUNE_PKGARCH:
> > 
> > TUNE_PKGARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "ppc603e", "", d)}"
> > 
> > and I want a multilib config using this as the m32 ABI and also have
> > powerpc64 as my other multilib. I can't select that as it will get
> > TUNE_PKGARCH wrong in the 64 bit case since:
> > 
> > TUNE_PKGARCH ?= "${TUNE_ARCH}"
> > 
> > is overwritten. I guess we could do:
> > 
> > TUNE_PKGARCH = "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "ppc603e", "${TUNE_ARCH}", d)}"
> 
> ppc603e is the new option.. (lets say for argument it can run in 64-bit mode, in
> reality it can't and is an invalid config....)
> 
> TUNEVALID[ppc603e] = "PowerPC 603e Optimization"
> 
> # Note the TUNE_NAME is used differently from the TUNE_FEATURES
> TUNE_NAME ?= "ppc603e"
> 
> TUNE_FEATURES_ppc603e = "m32 ppc603e"
> TUNE_FEATURES_ppc603e-64 = "m64 ppc603e"
> 
> The if you include the tune-ppc603e.inc the default is the 32-bit version (what
> I'd consider the reasonable default...)  If you wanted the 64-bit version
> instead you'd simply change set the TUNE_NAME to "ppc603e-64" and the properly
> tuned set of features is set for you.
> 
> TUNE_PKGARCH_ppc603e = "ppc603e"
> TUNE_PKGARCH_ppc603e-64 = "ppc603e-64"

The thing is we don't' support the above syntax for TUNE_PKGARCH...

> etc...
> 
> in the default (ppc603e) case, the TUNE_ARCH should always be "powerpc", and in
> the ppc603e-64 case (if manually enabled), it would be "powerpc64"...
> 
> This is what was done in the ARM cases and I believe the core2 case in ia32.

which turns out to be broken :/.

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

is what I'm considering to "fix" this. I guess the config could do:

TUNE_PKGARCH ?= "${@bb.utils.contains("TUNE_FEATURES", "ppc603e-64", "ppc603e-64", "ppc603e", d)}"

as per the x86 case but since this really limits the reuse of any of the
core variables as you might as well do:

AVAILTUNES = "ppc603e ppc603e-64" 

after doing that since TUNE_PKGARCH will be wrong in any other case.

Cheers,

Richard
Khem Raj - July 26, 2011, 8:03 p.m.
On Tue, Jul 26, 2011 at 8:22 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Jul 26, 2011, at 8:59 AM, Richard Purdie wrote:
>
>> On Tue, 2011-07-26 at 08:47 -0500, Kumar Gala wrote:
>>> On Jul 26, 2011, at 7:44 AM, Richard Purdie wrote:
>>>
>>>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>>>> ---
>>>> meta/conf/machine/include/powerpc/arch-powerpc.inc |   45 +++++++++++++++++++-
>>>> meta/conf/machine/include/tune-ppc603e.inc         |   12 ++++-
>>>> meta/conf/machine/include/tune-ppce300c2.inc       |   12 ++++-
>>>> meta/conf/machine/include/tune-ppce500.inc         |   13 ++++--
>>>> meta/conf/machine/include/tune-ppce500mc.inc       |   12 ++++-
>>>> meta/conf/machine/include/tune-ppce500v2.inc       |   12 ++++-
>>>> 6 files changed, 88 insertions(+), 18 deletions(-)
>>>
>>> One thing I'm wondering about as we do this is the ability to pass
>>> --with-cpu to gcc & [e]glibc configure to pickup proper optimized cfgs
>>> & libs for a given target.
>>
>> As far as I can tell, gcc 4.x has no --with-cpu option. We pass the
>> correct march and mtune options to the compiler at runtime through
>> CFLAGS and friends.
>
> Hmm, gcc still supports this:
>
> http://gcc.gnu.org/install/configure.html
>
> --with-cpu=cpu
> --with-cpu-32=cpu
> --with-cpu-64=cpu
> Specify which cpu variant the compiler should generate code for by default. cpu will be used as the default value of the -mcpu= switch. This option is only supported on some targets, including ARM, i386, M68k, PowerPC, and SPARC. The --with-cpu-32 and --with-cpu-64 options specify separate default CPUs for 32-bit and 64-bit modes; these options are only supported for i386, x86-64 and PowerPC.
>
> http://gcc.gnu.org/install/specific.html
>
> powerpc-*-*
> You can specify a default version for the -mcpu=cpu_type switch by using the configure option --with-cpu-cpu_type.

thats only when you dont use -march -mtune -mcpu options but we use
them always so using this configure option is not needed so much
for us. Although I am not sure if the TARGET_CC_ARCH really makes into
gcc runtime especially libgcc in that case --with-cpu will do
things differently.

>
>> You're already found the way to pass configuration to *libc using values
>> in TARGET_FPU to pickup the right configuration.
>>
>> Is there a use case we're missing?
>
> Yes, for [e]glibc we have optimized libc functions for a given / specific PPC processor.  So we need someway to tell configure this.
>

you need to use --with-cpu=CPU option at configure time. glibc
configury does not grok the -mtune options otherwise.

> - k
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Khem Raj - July 26, 2011, 8:13 p.m.
On Tue, Jul 26, 2011 at 9:36 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Tue, 2011-07-26 at 09:57 -0500, Mark Hatle wrote:
>> On 7/26/11 7:44 AM, Richard Purdie wrote:
>> > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>> > ---
>> >  meta/conf/machine/include/powerpc/arch-powerpc.inc |   45 +++++++++++++++++++-
>> >  meta/conf/machine/include/tune-ppc603e.inc         |   12 ++++-
>> >  meta/conf/machine/include/tune-ppce300c2.inc       |   12 ++++-
>> >  meta/conf/machine/include/tune-ppce500.inc         |   13 ++++--
>> >  meta/conf/machine/include/tune-ppce500mc.inc       |   12 ++++-
>> >  meta/conf/machine/include/tune-ppce500v2.inc       |   12 ++++-
>> >  6 files changed, 88 insertions(+), 18 deletions(-)
>> >
>> > diff --git a/meta/conf/machine/include/powerpc/arch-powerpc.inc b/meta/conf/machine/include/powerpc/arch-powerpc.inc
>> > index 17ace32..3f7befb 100644
>> > --- a/meta/conf/machine/include/powerpc/arch-powerpc.inc
>> > +++ b/meta/conf/machine/include/powerpc/arch-powerpc.inc
>> > @@ -1,3 +1,44 @@
>> > -TUNE_ARCH = "powerpc"
>> > +# Power Architecture definition
>> > +# Four defined ABIs, all combinations of:
>> > +# *) Hard/Soft Floating Point
>> > +# *) 32-bit/64-bit
>> > +
>> > +DEFAULTTUNE ?= "powerpc"
>> > +
>> > +TUNEVALID[m32] = "Power ELF32 standard ABI"
>> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32", "", d)}"
>> > +
>> > +TUNEVALID[m32-arch] = "Enable powerpc package architecture"
>> > +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m32-arch" ], "powerpc", "", d)}"
>> > +
>> > +TUNEVALID[m64] = "Power ELF64 standard ABI"
>> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "n64", "-m64", "", d)}"
>> > +
>> > +TUNEVALID[m64-arch] = "Enable powerpc64 package architecture"
>> > +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m64-arch" ], "powerpc64", "", d)}"
>>
>> Why m32-arch and m64-arch?  If m32 or m64 is selected then it should mean
>> powerpc or powerpc64.
>
> I've gotten confused here and mixed up TUNE_ARCH and TUNE_PKGARCH but
> there was a reason.
>
> The missing piece is
>
> TUNE_PKGARCH ?= "${TUNE_ARCH}"
>
> and the trouble comes when a tune file wants to change this only when
> its tune config is in action.
>
> I'm thinking ahead to trying a mixed ppc 32 and 64 bit build where
> TUNE_PKGARCH needs to take on the values for both configs.
>
>> > +TUNEVALID[fpu-hard] = "Use hardware FPU."
>> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "-mhard-float", "", d)}"
>> > +
>> > +TUNEVALID[fpu-soft] = "Use software FPU."
>> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft", "-msoft-float", "", d)}"
>> > +TARGET_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft", "soft", "", d)}"
>>
>> Why specify both fpu-hard and fpu-soft?  The "unusual" ABI is fpu-soft.  It
>> would simplify it to only have to specify one, and you get the other automatically.
>
> The trouble is the spe pieces which seemed to imply TARGET_FPU should
> take on a value of other than "soft". Setting it to "soft" if fpu-hard
> isn't in TUNE_FEATURES therefore wasn't enough...
>
>> > +TUNEVALID[spe] = "Enable SPE ABI extensions"
>> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "spe", "-mabi=spe -mspe", "", d)}"
>> > +
>> > +ABIEXTENSION = "${@['','spe'][d.getVar('TARGET_FPU', True) in ['ppc-efd', 'ppc-efs']]}"
>>
>> SPE instructions are specific to certain processors and not generic across all
>> of PPC.  I would move this to each of the tunes where it may be used.
>
> I guess this should be a feature file like thumb on arm?
>
>> Also I see the ABIEXTENSION, but where is it being set?
>
> I'm just migrating the existing code in that regard, I'm also puzzled as
> to where that is getting set currently.
>
>> > +# Basic tune definitions
>> > +AVAILTUNES += "powerpc powerpc-nf"
>> > +TUNE_FEATURES_tune-powerpc ?= "m32 m32-arch fpu-hard"
>> > +BASE_LIB_tune-powerpc = "lib"
>> > +TUNE_FEATURES_tune-powerpc-nf ?= "m32 m32-arch fpu-soft"
>> > +BASE_LIB_tune-powerpc-nf = "lib"
>> > +
>> > +AVAILTUNES += "powerpc64 powerpc64-nf"
>> > +TUNE_FEATURES_tune-powerpc64 ?= "m64 m64-arch fpu-hard"
>> > +BASE_LIB_tune-powerpc64 = "lib64"
>> > +TUNE_FEATURES_tune-powerpc64-nf ?= "m64 m64-arch fpu-soft"
>> > +BASE_LIB_tune-powerpc64-nf = "lib64"
>> >
>> > -ABIEXTENSION = "${@['','spe'][bb.data.getVar('TARGET_FPU',d,1) in ['ppc-efd', 'ppc-efs']]}"
>> > diff --git a/meta/conf/machine/include/tune-ppc603e.inc b/meta/conf/machine/include/tune-ppc603e.inc
>> > index 61c0669..6991ae0 100644
>> > --- a/meta/conf/machine/include/tune-ppc603e.inc
>> > +++ b/meta/conf/machine/include/tune-ppc603e.inc
>> > @@ -1,5 +1,11 @@
>> > +DEFAULTTUNE ?= "ppc603e"
>> > +
>> >  require conf/machine/include/powerpc/arch-powerpc.inc
>> >
>> > -TUNE_CCARGS = "-mcpu=603e  -mhard-float"
>> > -TUNE_PKGARCH = "ppc603e"
>> > -PACKAGE_EXTRA_ARCHS = "powerpc ppc603e"
>> > +TUNEVALID[ppc603e] = "Enable ppc603e specific processor optimizations"
>> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "-mcpu=603e", "", d)}"
>> > +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "ppc603e", "", d)}"
>> > +
>> > +AVAILTUNES += "ppc603e"
>> > +TUNE_FEATURES_tune-ppc603e = "m32 fpu-hard ppc603e"
>> > +PACKAGE_EXTRA_ARCHS_tune-ppc603e = "powerpc ppc603e"
>>
>> Going back to my original comment, the m32-arch is missing... or m32 should mean
>> "powerpc" (my suggestion).
>
> No, TUNE_ARCH should be TUNE_PKGARCH above, then this makes more
> sense...
>
>> > diff --git a/meta/conf/machine/include/tune-ppce300c2.inc b/meta/conf/machine/include/tune-ppce300c2.inc
>> > index a38e97c..652422f 100644
>> > --- a/meta/conf/machine/include/tune-ppce300c2.inc
>> > +++ b/meta/conf/machine/include/tune-ppce300c2.inc
>> > @@ -1,5 +1,11 @@
>> > +DEFAULTTUNE ?= "ppce300"
>> > +
>> >  require conf/machine/include/powerpc/arch-powerpc.inc
>> >
>> > -TUNE_CCARGS = "-mcpu=e300c2 -msoft-float"
>> > -TUNE_PKGARCH = "ppce300"
>> > -PACKAGE_EXTRA_ARCHS = "powerpc ppce300"
>> > +TUNEVALID[ppce300] = "Enable ppce300 specific processor optimizations"
>> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce300", "-mcpu=e300c2", "", d)}"
>> > +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce300", "ppce300", "", d)}"
>> > +
>> > +AVAILTUNES += "ppce300"
>> > +TUNE_FEATURES_tune-ppce300 = "m32 fpu-soft ppce300"
>> > +PACKAGE_EXTRA_ARCHS_tune-ppce300 = "powerpc ppce300"
>>
>> There is also a ppce300 as well as the e300c2, so I'd change the option to be
>> fully qualified.  (One has floating point one doesn't..)
>
> Fair enough.
>
>> > diff --git a/meta/conf/machine/include/tune-ppce500.inc b/meta/conf/machine/include/tune-ppce500.inc
>> > index 22208f0..fe62445 100644
>> > --- a/meta/conf/machine/include/tune-ppce500.inc
>> > +++ b/meta/conf/machine/include/tune-ppce500.inc
>> > @@ -1,6 +1,11 @@
>> > +DEFAULTTUNE ?= "ppce500"
>> > +
>> >  require conf/machine/include/powerpc/arch-powerpc.inc
>> >
>> > -TUNE_CCARGS = "-mcpu=8540"
>> > -BASE_PACKAGE_ARCH = "ppce500"
>> > -TUNE_PKGARCH = "ppce500"
>> > -PACKAGE_EXTRA_ARCHS = "powerpc ppce500"
>> > +TUNEVALID[ppce500] = "Enable ppce500 specific processor optimizations"
>> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500", "-mcpu=8540", "", d)}"
>> > +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce500", "ppce500", "", d)}"
>> > +
>> > +AVAILTUNES += "ppce500"
>> > +TUNE_FEATURES_tune-ppce500 = "m32 ppce500"
>> > +PACKAGE_EXTRA_ARCHS_tune-ppce500 = "powerpc ppce500"
>>
>> This is the single precision e500 -- it should be specifying it's floating point
>> type.
>
> which is? :)

ppc-efs in oe terms

>
>> > diff --git a/meta/conf/machine/include/tune-ppce500mc.inc b/meta/conf/machine/include/tune-ppce500mc.inc
>> > index 182d019..0d3640f 100644
>> > --- a/meta/conf/machine/include/tune-ppce500mc.inc
>> > +++ b/meta/conf/machine/include/tune-ppce500mc.inc
>> > @@ -1,5 +1,11 @@
>> > +DEFAULTTUNE ?= "ppce500mc"
>> > +
>> >  require conf/machine/include/powerpc/arch-powerpc.inc
>> >
>> > -TUNE_CCARGS = "-mcpu=e500mc"
>> > -TUNE_PKGARCH = "ppce500mc"
>> > -PACKAGE_EXTRA_ARCHS = "powerpc ppce500mc"
>> > +TUNEVALID[ppce500mc] = "Enable ppce500mc specific processor optimizations"
>> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "-mcpu=e500mc", "", d)}"
>> > +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "ppce500mc", "", d)}"
>> > +
>> > +AVAILTUNES += "ppce500mc"
>> > +TUNE_FEATURES_tune-ppce500mc = "m32 ppce500mc"
>> > +PACKAGE_EXTRA_ARCHS_tune-ppce500mc = "powerpc ppce500mc"
>>
>> e500mc using the classic "hard-float" floating point unit.
>
> ok, so its hard-fpu...
>
>> > diff --git a/meta/conf/machine/include/tune-ppce500v2.inc b/meta/conf/machine/include/tune-ppce500v2.inc
>> > index daf2d58..e6b48a2 100644
>> > --- a/meta/conf/machine/include/tune-ppce500v2.inc
>> > +++ b/meta/conf/machine/include/tune-ppce500v2.inc
>> > @@ -1,5 +1,11 @@
>> > +DEFAULTTUNE ?= "ppce500v2"
>> > +
>> >  require conf/machine/include/powerpc/arch-powerpc.inc
>> >
>> > -TUNE_CCARGS = "-mcpu=8548 -mabi=spe -mspe"
>> > -TUNE_PKGARCH = "ppce500v2"
>> > -PACKAGE_EXTRA_ARCHS = "powerpc ppce500v2"
>> > +TUNEVALID[ppce500mc] = "Enable ppce500mc specific processor optimizations"
>> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500v2", "-mcpu=8548", "", d)}"
>> > +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce500v2", "ppce500v2", "", d)}"
>> > +
>> > +AVAILTUNES += "ppce500v2"
>> > +TUNE_FEATURES_tune-ppce500v2 = "m32 spe ppce500v2"
>> > +PACKAGE_EXTRA_ARCHS_tune-ppce500v2 = "powerpc ppce500v2"
>>
>> This one is double precision.
>
> so hard-fpu?

no its spe with double precision which is ppc-efd

>
> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Richard Purdie - July 26, 2011, 8:28 p.m.
I've taken various comments on board and a revised version of the PPC
version is:

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

Cheers,

Richard
Kumar Gala - July 26, 2011, 9:56 p.m.
On Jul 26, 2011, at 11:18 AM, Richard Purdie wrote:

>>> 
>>> You're already found the way to pass configuration to *libc using values
>>> in TARGET_FPU to pickup the right configuration.
>>> 
>>> Is there a use case we're missing?
>> 
>> Yes, for [e]glibc we have optimized libc functions for a given /
>> specific PPC processor.  So we need someway to tell configure this.
> 
> I'd do this by looking for flags in TUNE_FEATURES as Mark has also
> mentioned.

Are we thinking something like the following in e[glibc] recipes:

EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "-with-cpu=e500mc", "", d)}"

- k
Kumar Gala - July 26, 2011, 10:02 p.m.
On Jul 26, 2011, at 11:18 AM, Richard Purdie wrote:

>>> You're already found the way to pass configuration to *libc using values
>>> in TARGET_FPU to pickup the right configuration.
>>> 
>>> Is there a use case we're missing?
>> 
>> Yes, for [e]glibc we have optimized libc functions for a given /
>> specific PPC processor.  So we need someway to tell configure this.
> 
> I'd do this by looking for flags in TUNE_FEATURES as Mark has also
> mentioned.
> 
> Cheers,
> 
> Richard

Are we thinking something like the following in e[glibc] recipes:

EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "-with-cpu=e500mc", "", d)}"

- k
Kumar Gala - July 26, 2011, 10:03 p.m.
On Jul 26, 2011, at 11:18 AM, Richard Purdie wrote:

> On Tue, 2011-07-26 at 10:22 -0500, Kumar Gala wrote:
>> On Jul 26, 2011, at 8:59 AM, Richard Purdie wrote:
>> 
>>> On Tue, 2011-07-26 at 08:47 -0500, Kumar Gala wrote:
>>>> On Jul 26, 2011, at 7:44 AM, Richard Purdie wrote:
>>>> 
>>>>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>>>>> ---
>>>>> meta/conf/machine/include/powerpc/arch-powerpc.inc |   45 +++++++++++++++++++-
>>>>> meta/conf/machine/include/tune-ppc603e.inc         |   12 ++++-
>>>>> meta/conf/machine/include/tune-ppce300c2.inc       |   12 ++++-
>>>>> meta/conf/machine/include/tune-ppce500.inc         |   13 ++++--
>>>>> meta/conf/machine/include/tune-ppce500mc.inc       |   12 ++++-
>>>>> meta/conf/machine/include/tune-ppce500v2.inc       |   12 ++++-
>>>>> 6 files changed, 88 insertions(+), 18 deletions(-)
>>>> 
>>>> One thing I'm wondering about as we do this is the ability to pass
>>>> --with-cpu to gcc & [e]glibc configure to pickup proper optimized cfgs
>>>> & libs for a given target.
>>> 
>>> As far as I can tell, gcc 4.x has no --with-cpu option. We pass the
>>> correct march and mtune options to the compiler at runtime through
>>> CFLAGS and friends.
>> 
>> Hmm, gcc still supports this:
>> 
>> http://gcc.gnu.org/install/configure.html
>> 
>> --with-cpu=cpu
>> --with-cpu-32=cpu
>> --with-cpu-64=cpu
>> Specify which cpu variant the compiler should generate code for by default. cpu will be used as the default value of the -mcpu= switch. This option is only supported on some targets, including ARM, i386, M68k, PowerPC, and SPARC. The --with-cpu-32 and --with-cpu-64 options specify separate default CPUs for 32-bit and 64-bit modes; these options are only supported for i386, x86-64 and PowerPC. 
>> 
>> http://gcc.gnu.org/install/specific.html
>> 
>> powerpc-*-*
>> You can specify a default version for the -mcpu=cpu_type switch by using the configure option --with-cpu-cpu_type.
> 
> I couldn't find that looking at the configure script :/.
> 
> Anyhow, according to that page, its to "Specify which cpu variant the
> compiler should generate code for by default. cpu will be used as the
> default value of the -mcpu= switch". Since we always specify -mcpu when
> needed, I don't believe this is an issue for us as far as the build
> system goes.
> 
> If you're talking about the gcc we build for the target, we should
> really encode all the cpu/tune options in there, not just part of the
> config so again, I don't think its appropriate to the way we use gcc.

What about tool chains produced as part of a ADT, wouldn't it be useful for such as case?

Seems like having ability to pass '--with-cpu' ends up being useful to set default for things like 32 vs 64-bit on multiple.

- k
Khem Raj - July 26, 2011, 10:29 p.m.
On Tue, Jul 26, 2011 at 3:02 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Jul 26, 2011, at 11:18 AM, Richard Purdie wrote:
>
>>>> You're already found the way to pass configuration to *libc using values
>>>> in TARGET_FPU to pickup the right configuration.
>>>>
>>>> Is there a use case we're missing?
>>>
>>> Yes, for [e]glibc we have optimized libc functions for a given /
>>> specific PPC processor.  So we need someway to tell configure this.
>>
>> I'd do this by looking for flags in TUNE_FEATURES as Mark has also
>> mentioned.
>>
>> Cheers,
>>
>> Richard
>
> Are we thinking something like the following in e[glibc] recipes:
>
> EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "-with-cpu=e500mc", "", d)}"
>

I guess we can make a python function since most architectures can
benefit from --with-cpu

> - k
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Richard Purdie - July 26, 2011, 10:52 p.m.
On Tue, 2011-07-26 at 17:02 -0500, Kumar Gala wrote:
> On Jul 26, 2011, at 11:18 AM, Richard Purdie wrote:
> 
> >>> You're already found the way to pass configuration to *libc using values
> >>> in TARGET_FPU to pickup the right configuration.
> >>> 
> >>> Is there a use case we're missing?
> >> 
> >> Yes, for [e]glibc we have optimized libc functions for a given /
> >> specific PPC processor.  So we need someway to tell configure this.
> > 
> > I'd do this by looking for flags in TUNE_FEATURES as Mark has also
> > mentioned.
> > 
> > Cheers,
> > 
> > Richard
> 
> Are we thinking something like the following in e[glibc] recipes:
> 
> EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "-with-cpu=e500mc", "", d)}"

Could we glean this information from the TUNE_CCARGS variable and do
this automatically?

Cheers,

Richard
Kumar Gala - July 27, 2011, 3:23 a.m.
On Jul 26, 2011, at 5:52 PM, Richard Purdie wrote:

> On Tue, 2011-07-26 at 17:02 -0500, Kumar Gala wrote:
>> On Jul 26, 2011, at 11:18 AM, Richard Purdie wrote:
>> 
>>>>> You're already found the way to pass configuration to *libc using values
>>>>> in TARGET_FPU to pickup the right configuration.
>>>>> 
>>>>> Is there a use case we're missing?
>>>> 
>>>> Yes, for [e]glibc we have optimized libc functions for a given /
>>>> specific PPC processor.  So we need someway to tell configure this.
>>> 
>>> I'd do this by looking for flags in TUNE_FEATURES as Mark has also
>>> mentioned.
>>> 
>>> Cheers,
>>> 
>>> Richard
>> 
>> Are we thinking something like the following in e[glibc] recipes:
>> 
>> EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "-with-cpu=e500mc", "", d)}"
> 
> Could we glean this information from the TUNE_CCARGS variable and do
> this automatically?

For PPC we'd have:

405
440
464
476
603e
e500
e500mc
e5500
970
a2
cell
power4
power5
power5+
power6
power6x
power7

There isn't always a clean mapping.  For example ppce500 & ppce500v2 would want --with-cpu=e500.  I believe ppc603e, ppce300c2 would want --with-cpu=603e.

If we want to just do it as a python function w/a mapping table we could easily handle it that way.

- k
Richard Purdie - July 27, 2011, 8:31 a.m.
On Tue, 2011-07-26 at 17:03 -0500, Kumar Gala wrote:
> On Jul 26, 2011, at 11:18 AM, Richard Purdie wrote:
> 
> > On Tue, 2011-07-26 at 10:22 -0500, Kumar Gala wrote:
> >> On Jul 26, 2011, at 8:59 AM, Richard Purdie wrote:
> >> 
> >>> On Tue, 2011-07-26 at 08:47 -0500, Kumar Gala wrote:
> >>>> On Jul 26, 2011, at 7:44 AM, Richard Purdie wrote:
> >>>> 
> >>>>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> >>>>> ---
> >>>>> meta/conf/machine/include/powerpc/arch-powerpc.inc |   45 +++++++++++++++++++-
> >>>>> meta/conf/machine/include/tune-ppc603e.inc         |   12 ++++-
> >>>>> meta/conf/machine/include/tune-ppce300c2.inc       |   12 ++++-
> >>>>> meta/conf/machine/include/tune-ppce500.inc         |   13 ++++--
> >>>>> meta/conf/machine/include/tune-ppce500mc.inc       |   12 ++++-
> >>>>> meta/conf/machine/include/tune-ppce500v2.inc       |   12 ++++-
> >>>>> 6 files changed, 88 insertions(+), 18 deletions(-)
> >>>> 
> >>>> One thing I'm wondering about as we do this is the ability to pass
> >>>> --with-cpu to gcc & [e]glibc configure to pickup proper optimized cfgs
> >>>> & libs for a given target.
> >>> 
> >>> As far as I can tell, gcc 4.x has no --with-cpu option. We pass the
> >>> correct march and mtune options to the compiler at runtime through
> >>> CFLAGS and friends.
> >> 
> >> Hmm, gcc still supports this:
> >> 
> >> http://gcc.gnu.org/install/configure.html
> >> 
> >> --with-cpu=cpu
> >> --with-cpu-32=cpu
> >> --with-cpu-64=cpu
> >> Specify which cpu variant the compiler should generate code for by default. cpu will be used as the default value of the -mcpu= switch. This option is only supported on some targets, including ARM, i386, M68k, PowerPC, and SPARC. The --with-cpu-32 and --with-cpu-64 options specify separate default CPUs for 32-bit and 64-bit modes; these options are only supported for i386, x86-64 and PowerPC. 
> >> 
> >> http://gcc.gnu.org/install/specific.html
> >> 
> >> powerpc-*-*
> >> You can specify a default version for the -mcpu=cpu_type switch by using the configure option --with-cpu-cpu_type.
> > 
> > I couldn't find that looking at the configure script :/.
> > 
> > Anyhow, according to that page, its to "Specify which cpu variant the
> > compiler should generate code for by default. cpu will be used as the
> > default value of the -mcpu= switch". Since we always specify -mcpu when
> > needed, I don't believe this is an issue for us as far as the build
> > system goes.
> > 
> > If you're talking about the gcc we build for the target, we should
> > really encode all the cpu/tune options in there, not just part of the
> > config so again, I don't think its appropriate to the way we use gcc.
> 
> What about tool chains produced as part of a ADT, wouldn't it be useful for such as case?
> 
> Seems like having ability to pass '--with-cpu' ends up being useful to set default for things like 32 vs 64-bit on multiple.

ADT passes an environment script with all the appropriate flags
contained within including tunings which --with-cpu doesn't help with so
I'm not sure its so useful there.

Cheers,

Richard
Richard Purdie - July 27, 2011, 8:36 a.m.
On Tue, 2011-07-26 at 22:23 -0500, Kumar Gala wrote:
> On Jul 26, 2011, at 5:52 PM, Richard Purdie wrote:
> 
> > On Tue, 2011-07-26 at 17:02 -0500, Kumar Gala wrote:
> >> On Jul 26, 2011, at 11:18 AM, Richard Purdie wrote:
> >> 
> >>>>> You're already found the way to pass configuration to *libc using values
> >>>>> in TARGET_FPU to pickup the right configuration.
> >>>>> 
> >>>>> Is there a use case we're missing?
> >>>> 
> >>>> Yes, for [e]glibc we have optimized libc functions for a given /
> >>>> specific PPC processor.  So we need someway to tell configure this.
> >>> 
> >>> I'd do this by looking for flags in TUNE_FEATURES as Mark has also
> >>> mentioned.
> >>> 
> >>> Cheers,
> >>> 
> >>> Richard
> >> 
> >> Are we thinking something like the following in e[glibc] recipes:
> >> 
> >> EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "-with-cpu=e500mc", "", d)}"
> > 
> > Could we glean this information from the TUNE_CCARGS variable and do
> > this automatically?
> 
> For PPC we'd have:
> 
> 405
> 440
> 464
> 476
> 603e
> e500
> e500mc
> e5500
> 970
> a2
> cell
> power4
> power5
> power5+
> power6
> power6x
> power7
> 
> There isn't always a clean mapping.  For example ppce500 & ppce500v2 would want --with-cpu=e500.  I believe ppc603e, ppce300c2 would want --with-cpu=603e.
> 
> If we want to just do it as a python function w/a mapping table we could easily handle it that way.

We could also put:

GLIBC_EXTRA_OECONF = "--with-cpu=e500"

in the machine config files. When multilib gets involved we'd have to
become a little cleverer with this but there are options there...

Cheers,

Richard
Koen Kooi - July 27, 2011, 8:44 a.m.
Op 27 jul. 2011, om 10:36 heeft Richard Purdie het volgende geschreven:

> [..]

> We could also put:
> 
> GLIBC_EXTRA_OECONF = "--with-cpu=e500"
> 
> in the machine config files.

Note that that will make glibc 'machine' specific and by association all userspace. So if you're going that route, you need to touch TUNE_PKGARCH as well.

regards,

Koen
Richard Purdie - July 27, 2011, 9:30 a.m.
On Wed, 2011-07-27 at 10:44 +0200, Koen Kooi wrote:
> Op 27 jul. 2011, om 10:36 heeft Richard Purdie het volgende geschreven:
> 
> > [..]
> 
> > We could also put:
> > 
> > GLIBC_EXTRA_OECONF = "--with-cpu=e500"
> > 
> > in the machine config files.
> 
> Note that that will make glibc 'machine' specific and by association
> all userspace. So if you're going that route, you need to touch
> TUNE_PKGARCH as well.

Right, I am making the assumption here that the optimisation chosen
would be appropriate to the TUNE_PKGARCH which is set. Certainly on PPC
there are some machines where this is already the case so it isn't a big
deal from what I've see of the tune files.

Cheers,

Richard
Phil Blundell - July 27, 2011, 9:35 a.m.
On Wed, 2011-07-27 at 10:44 +0200, Koen Kooi wrote:
> Op 27 jul. 2011, om 10:36 heeft Richard Purdie het volgende geschreven:
> 
> > [..]
> 
> > We could also put:
> > 
> > GLIBC_EXTRA_OECONF = "--with-cpu=e500"
> > 
> > in the machine config files.
> 
> Note that that will make glibc 'machine' specific and by association all userspace. So if you're going that route, you need to touch TUNE_PKGARCH as well.

That's true for glibc but it isn't entirely accurate to extend that to
"all userspace" since (AFAIK) none of the --with-cpu optimisations that
glibc does are ABI-changing.  So, it's just eglibc itself that needs to
get a different package architecture, everything else can stay with the
generic value.

p.
Kumar Gala - July 28, 2011, 5:25 a.m.
For some reason when I get to do_rootfs for core-image-sato when using rpms I run into an issue in that:

${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}

Isn't expanding or taking the assignment in meta/conf/machine/include/tune-ppcFOO.inc but just using what it found in meta/conf/bitbake.conf

the tune-ppcFOO.inc looks like:

DEFAULTTUNE ?= "ppce5500"

require conf/machine/include/powerpc/arch-powerpc64.inc

TUNEVALID[ppce5500] = "Enable ppce5500 specific processor optimizations"
TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce5500", "-mcpu=e5500", "", d)}"
TUNE_PKGARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce5500", "ppce5500", "", d)}"

AVAILTUNES += "ppce5500"
TUNE_FEATURES_tune-ppce5500 = "m64 hard-fpu ppce5500"
PACKAGE_EXTRA_ARCHS_tune-ppce5500 = "powerpc64 ppce5500"

any ideas?

- k
Saul Wold - July 28, 2011, 6:09 a.m.
On 07/27/2011 10:25 PM, Kumar Gala wrote:
> For some reason when I get to do_rootfs for core-image-sato when using rpms I run into an issue in that:
>
> ${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
>
> Isn't expanding or taking the assignment in meta/conf/machine/include/tune-ppcFOO.inc but just using what it found in meta/conf/bitbake.conf
>
> the tune-ppcFOO.inc looks like:
>
> DEFAULTTUNE ?= "ppce5500"
>
> require conf/machine/include/powerpc/arch-powerpc64.inc
>
> TUNEVALID[ppce5500] = "Enable ppce5500 specific processor optimizations"
> TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce5500", "-mcpu=e5500", "", d)}"
> TUNE_PKGARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce5500", "ppce5500", "", d)}"
>
> AVAILTUNES += "ppce5500"
> TUNE_FEATURES_tune-ppce5500 = "m64 hard-fpu ppce5500"
> PACKAGE_EXTRA_ARCHS_tune-ppce5500 = "powerpc64 ppce5500"
>
> any ideas?
>
I believe that I am seeing this also with an atom-pc build, where the 
PACKAGE_EXTRA_ARCHS seems OK, but ends up just being i586 instead of a 
list of ARCHS that includes core2 (which atom-pc should be).

I am looking into this issue.

Sau!

> - k
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Dexuan Cui - July 28, 2011, 7:48 a.m.
Saul Wold wrote on 2011-07-28:
> On 07/27/2011 10:25 PM, Kumar Gala wrote:
>> For some reason when I get to do_rootfs for core-image-sato when using
>> rpms I run into an issue in that:
>> 
>> ${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
>> 
>> Isn't expanding or taking the assignment in
>> meta/conf/machine/include/tune-ppcFOO.inc but just using what it
>> found in meta/conf/bitbake.conf
>> 
> I believe that I am seeing this also with an atom-pc build, where the
> PACKAGE_EXTRA_ARCHS seems OK, but ends up just being i586 instead of a
> list of ARCHS that includes core2 (which atom-pc should be).
Hi, I'm suffering from the exactly same issue... :-(
I don't know why PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} isn't expending yet.

Thanks,
-- Dexuan
Paul Eggleton - July 28, 2011, 8:47 a.m.
On Thursday 28 July 2011 08:48:43 Cui, Dexuan wrote:
> Saul Wold wrote on 2011-07-28:
> > On 07/27/2011 10:25 PM, Kumar Gala wrote:
> >> For some reason when I get to do_rootfs for core-image-sato when using
> >> rpms I run into an issue in that:
> >> 
> >> ${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
> >> 
> >> Isn't expanding or taking the assignment in
> >> meta/conf/machine/include/tune-ppcFOO.inc but just using what it
> >> found in meta/conf/bitbake.conf
> > 
> > I believe that I am seeing this also with an atom-pc build, where the
> > PACKAGE_EXTRA_ARCHS seems OK, but ends up just being i586 instead of a
> > list of ARCHS that includes core2 (which atom-pc should be).
> 
> Hi, I'm suffering from the exactly same issue... :-(
> I don't know why PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} isn't expending
> yet.

It seems to me that ??= gets confused because the variable name needs 
expanding. If you change the ${DEFAULTTUNE} reference to core2 in 
PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} ??= "${TARGET_ARCH}" it all works. I 
don't know if that indicates a BitBake bug or whether we should try to work 
around it.

Cheers,
Paul
Koen Kooi - July 28, 2011, 8:57 a.m.
Op 28 jul. 2011, om 10:47 heeft Paul Eggleton het volgende geschreven:

> On Thursday 28 July 2011 08:48:43 Cui, Dexuan wrote:
>> Saul Wold wrote on 2011-07-28:
>>> On 07/27/2011 10:25 PM, Kumar Gala wrote:
>>>> For some reason when I get to do_rootfs for core-image-sato when using
>>>> rpms I run into an issue in that:
>>>> 
>>>> ${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
>>>> 
>>>> Isn't expanding or taking the assignment in
>>>> meta/conf/machine/include/tune-ppcFOO.inc but just using what it
>>>> found in meta/conf/bitbake.conf
>>> 
>>> I believe that I am seeing this also with an atom-pc build, where the
>>> PACKAGE_EXTRA_ARCHS seems OK, but ends up just being i586 instead of a
>>> list of ARCHS that includes core2 (which atom-pc should be).
>> 
>> Hi, I'm suffering from the exactly same issue... :-(
>> I don't know why PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} isn't expending
>> yet.
> 
> It seems to me that ??= gets confused because the variable name needs 
> expanding. If you change the ${DEFAULTTUNE} reference to core2 in 
> PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} ??= "${TARGET_ARCH}" it all works. I 
> don't know if that indicates a BitBake bug or whether we should try to work 
> around it.

I think it has to do with when the anonymous python runs. Try comparing 'bitbake -e' and and 'bitbake -e some-image':

koen@dominion:/OE/tentacle/sources/openembedded-core/meta$ bitbake -e | grep PACKAGE_EXTRA_ARCHS\=
# PACKAGE_EXTRA_ARCHS=${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
PACKAGE_EXTRA_ARCHS="arm armv4 armv4t armv5 armv5t armv5-vfp armv5t-vfp armv5e armv5te armv5e-vfp armv5te-vfp armv6-vfp armv6t-vfp armv7-vfp armv7t2-vfp armv7a-vfp armv7at2-vfp armv7a-vfp-neon armv7at2-vfp-neon"

koen@dominion:/OE/tentacle/sources/openembedded-core/meta$ bitbake -e efl-nodm-image | grep PACKAGE_EXTRA_ARCHS\=
# PACKAGE_EXTRA_ARCHS=${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
PACKAGE_EXTRA_ARCHS="arm"

regards,

Koen
Phil Blundell - July 28, 2011, 9:20 a.m.
On Thu, 2011-07-28 at 10:57 +0200, Koen Kooi wrote:
> Op 28 jul. 2011, om 10:47 heeft Paul Eggleton het volgende geschreven:
> 
> > On Thursday 28 July 2011 08:48:43 Cui, Dexuan wrote:
> >> Saul Wold wrote on 2011-07-28:
> >>> On 07/27/2011 10:25 PM, Kumar Gala wrote:
> >>>> For some reason when I get to do_rootfs for core-image-sato when using
> >>>> rpms I run into an issue in that:
> >>>> 
> >>>> ${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
> >>>> 
> >>>> Isn't expanding or taking the assignment in
> >>>> meta/conf/machine/include/tune-ppcFOO.inc but just using what it
> >>>> found in meta/conf/bitbake.conf
> >>> 
> >>> I believe that I am seeing this also with an atom-pc build, where the
> >>> PACKAGE_EXTRA_ARCHS seems OK, but ends up just being i586 instead of a
> >>> list of ARCHS that includes core2 (which atom-pc should be).
> >> 
> >> Hi, I'm suffering from the exactly same issue... :-(
> >> I don't know why PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} isn't expending
> >> yet.
> > 
> > It seems to me that ??= gets confused because the variable name needs 
> > expanding. If you change the ${DEFAULTTUNE} reference to core2 in 
> > PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} ??= "${TARGET_ARCH}" it all works. I 
> > don't know if that indicates a BitBake bug or whether we should try to work 
> > around it.
> 
> I think it has to do with when the anonymous python runs. Try comparing 'bitbake -e' and and 'bitbake -e some-image':
> 
> koen@dominion:/OE/tentacle/sources/openembedded-core/meta$ bitbake -e | grep PACKAGE_EXTRA_ARCHS\=
> # PACKAGE_EXTRA_ARCHS=${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
> PACKAGE_EXTRA_ARCHS="arm armv4 armv4t armv5 armv5t armv5-vfp armv5t-vfp armv5e armv5te armv5e-vfp armv5te-vfp armv6-vfp armv6t-vfp armv7-vfp armv7t2-vfp armv7a-vfp armv7at2-vfp armv7a-vfp-neon armv7at2-vfp-neon"
> 
> koen@dominion:/OE/tentacle/sources/openembedded-core/meta$ bitbake -e efl-nodm-image | grep PACKAGE_EXTRA_ARCHS\=
> # PACKAGE_EXTRA_ARCHS=${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
> PACKAGE_EXTRA_ARCHS="arm"

No, I think Paul is right about the cause (though I don't agree with him
that it is a bug exactly).  The timing of anonymous python oughtn't to
be different in those two cases so I don't think that will be making a
difference.

That assignment to PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} in
bitbake.conf is just fundamentally bogus.  As far as the bitbake parser
is concerned, PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} and
PACKAGE_EXTRA_ARCHS_tune-arm926ejs are different variables (assuming
DEFAULTTUNE=arm926ejs for the sake of an example) and it will create
both of them.  Then, later, when the lvalues get expanded the latter
will be overwritten by the former which seems like it is exactly the
opposite to the effect that's wanted here.

This is long-standing bitbake behaviour and I'm not sure it would be
practical to change.  I think the metadata just needs to be written to
work with the semantics that we have.

p.
Koen Kooi - July 28, 2011, 10 a.m.
Op 28 jul. 2011, om 11:20 heeft Phil Blundell het volgende geschreven:

> On Thu, 2011-07-28 at 10:57 +0200, Koen Kooi wrote:
>> Op 28 jul. 2011, om 10:47 heeft Paul Eggleton het volgende geschreven:
>> 
>>> On Thursday 28 July 2011 08:48:43 Cui, Dexuan wrote:
>>>> Saul Wold wrote on 2011-07-28:
>>>>> On 07/27/2011 10:25 PM, Kumar Gala wrote:
>>>>>> For some reason when I get to do_rootfs for core-image-sato when using
>>>>>> rpms I run into an issue in that:
>>>>>> 
>>>>>> ${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
>>>>>> 
>>>>>> Isn't expanding or taking the assignment in
>>>>>> meta/conf/machine/include/tune-ppcFOO.inc but just using what it
>>>>>> found in meta/conf/bitbake.conf
>>>>> 
>>>>> I believe that I am seeing this also with an atom-pc build, where the
>>>>> PACKAGE_EXTRA_ARCHS seems OK, but ends up just being i586 instead of a
>>>>> list of ARCHS that includes core2 (which atom-pc should be).
>>>> 
>>>> Hi, I'm suffering from the exactly same issue... :-(
>>>> I don't know why PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} isn't expending
>>>> yet.
>>> 
>>> It seems to me that ??= gets confused because the variable name needs 
>>> expanding. If you change the ${DEFAULTTUNE} reference to core2 in 
>>> PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} ??= "${TARGET_ARCH}" it all works. I 
>>> don't know if that indicates a BitBake bug or whether we should try to work 
>>> around it.
>> 
>> I think it has to do with when the anonymous python runs. Try comparing 'bitbake -e' and and 'bitbake -e some-image':
>> 
>> koen@dominion:/OE/tentacle/sources/openembedded-core/meta$ bitbake -e | grep PACKAGE_EXTRA_ARCHS\=
>> # PACKAGE_EXTRA_ARCHS=${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
>> PACKAGE_EXTRA_ARCHS="arm armv4 armv4t armv5 armv5t armv5-vfp armv5t-vfp armv5e armv5te armv5e-vfp armv5te-vfp armv6-vfp armv6t-vfp armv7-vfp armv7t2-vfp armv7a-vfp armv7at2-vfp armv7a-vfp-neon armv7at2-vfp-neon"
>> 
>> koen@dominion:/OE/tentacle/sources/openembedded-core/meta$ bitbake -e efl-nodm-image | grep PACKAGE_EXTRA_ARCHS\=
>> # PACKAGE_EXTRA_ARCHS=${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
>> PACKAGE_EXTRA_ARCHS="arm"
> 
> No, I think Paul is right about the cause (though I don't agree with him
> that it is a bug exactly).  The timing of anonymous python oughtn't to
> be different in those two cases so I don't think that will be making a
> difference.
> 
> That assignment to PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} in
> bitbake.conf is just fundamentally bogus.  As far as the bitbake parser
> is concerned, PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} and
> PACKAGE_EXTRA_ARCHS_tune-arm926ejs are different variables (assuming
> DEFAULTTUNE=arm926ejs for the sake of an example) and it will create
> both of them.  Then, later, when the lvalues get expanded the latter
> will be overwritten by the former which seems like it is exactly the
> opposite to the effect that's wanted here.
> 
> This is long-standing bitbake behaviour and I'm not sure it would be
> practical to change.  I think the metadata just needs to be written to
> work with the semantics that we have.

Removing the PACKAGE_EXTRA_ARCHS line from bitbake.conf makes it work for me again, is that an acceptable solution?

regards,

Koen
Phil Blundell - July 28, 2011, 10:03 a.m.
On Thu, 2011-07-28 at 12:00 +0200, Koen Kooi wrote:
> Removing the PACKAGE_EXTRA_ARCHS line from bitbake.conf makes it work for me again, is that an acceptable solution?

Sounds about right to me.  If ${TARGET_ARCH} really does need to go into
PACKAGE_EXTRA_ARCHS by default (which sounds implausible to me) then
we'll have to find some other way to achieve that.

p.

Patch

diff --git a/meta/conf/machine/include/powerpc/arch-powerpc.inc b/meta/conf/machine/include/powerpc/arch-powerpc.inc
index 17ace32..3f7befb 100644
--- a/meta/conf/machine/include/powerpc/arch-powerpc.inc
+++ b/meta/conf/machine/include/powerpc/arch-powerpc.inc
@@ -1,3 +1,44 @@ 
-TUNE_ARCH = "powerpc"
+# Power Architecture definition
+# Four defined ABIs, all combinations of:
+# *) Hard/Soft Floating Point
+# *) 32-bit/64-bit
+
+DEFAULTTUNE ?= "powerpc"
+
+TUNEVALID[m32] = "Power ELF32 standard ABI"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32", "", d)}"
+
+TUNEVALID[m32-arch] = "Enable powerpc package architecture"
+TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m32-arch" ], "powerpc", "", d)}"
+
+TUNEVALID[m64] = "Power ELF64 standard ABI"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "n64", "-m64", "", d)}"
+
+TUNEVALID[m64-arch] = "Enable powerpc64 package architecture"
+TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m64-arch" ], "powerpc64", "", d)}"
+
+TUNEVALID[fpu-hard] = "Use hardware FPU."
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "-mhard-float", "", d)}"
+
+TUNEVALID[fpu-soft] = "Use software FPU."
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft", "-msoft-float", "", d)}"
+TARGET_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft", "soft", "", d)}"
+
+TUNEVALID[spe] = "Enable SPE ABI extensions"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "spe", "-mabi=spe -mspe", "", d)}"
+
+ABIEXTENSION = "${@['','spe'][d.getVar('TARGET_FPU', True) in ['ppc-efd', 'ppc-efs']]}"
+
+# Basic tune definitions
+AVAILTUNES += "powerpc powerpc-nf" 
+TUNE_FEATURES_tune-powerpc ?= "m32 m32-arch fpu-hard"
+BASE_LIB_tune-powerpc = "lib"
+TUNE_FEATURES_tune-powerpc-nf ?= "m32 m32-arch fpu-soft"
+BASE_LIB_tune-powerpc-nf = "lib"
+
+AVAILTUNES += "powerpc64 powerpc64-nf"
+TUNE_FEATURES_tune-powerpc64 ?= "m64 m64-arch fpu-hard"
+BASE_LIB_tune-powerpc64 = "lib64"
+TUNE_FEATURES_tune-powerpc64-nf ?= "m64 m64-arch fpu-soft"
+BASE_LIB_tune-powerpc64-nf = "lib64"
 
-ABIEXTENSION = "${@['','spe'][bb.data.getVar('TARGET_FPU',d,1) in ['ppc-efd', 'ppc-efs']]}"
diff --git a/meta/conf/machine/include/tune-ppc603e.inc b/meta/conf/machine/include/tune-ppc603e.inc
index 61c0669..6991ae0 100644
--- a/meta/conf/machine/include/tune-ppc603e.inc
+++ b/meta/conf/machine/include/tune-ppc603e.inc
@@ -1,5 +1,11 @@ 
+DEFAULTTUNE ?= "ppc603e"
+
 require conf/machine/include/powerpc/arch-powerpc.inc
 
-TUNE_CCARGS = "-mcpu=603e  -mhard-float"
-TUNE_PKGARCH = "ppc603e"
-PACKAGE_EXTRA_ARCHS = "powerpc ppc603e"
+TUNEVALID[ppc603e] = "Enable ppc603e specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "-mcpu=603e", "", d)}"
+TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "ppc603e", "", d)}"
+
+AVAILTUNES += "ppc603e"
+TUNE_FEATURES_tune-ppc603e = "m32 fpu-hard ppc603e"
+PACKAGE_EXTRA_ARCHS_tune-ppc603e = "powerpc ppc603e"
diff --git a/meta/conf/machine/include/tune-ppce300c2.inc b/meta/conf/machine/include/tune-ppce300c2.inc
index a38e97c..652422f 100644
--- a/meta/conf/machine/include/tune-ppce300c2.inc
+++ b/meta/conf/machine/include/tune-ppce300c2.inc
@@ -1,5 +1,11 @@ 
+DEFAULTTUNE ?= "ppce300"
+
 require conf/machine/include/powerpc/arch-powerpc.inc
 
-TUNE_CCARGS = "-mcpu=e300c2 -msoft-float"
-TUNE_PKGARCH = "ppce300"
-PACKAGE_EXTRA_ARCHS = "powerpc ppce300"
+TUNEVALID[ppce300] = "Enable ppce300 specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce300", "-mcpu=e300c2", "", d)}"
+TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce300", "ppce300", "", d)}"
+
+AVAILTUNES += "ppce300"
+TUNE_FEATURES_tune-ppce300 = "m32 fpu-soft ppce300"
+PACKAGE_EXTRA_ARCHS_tune-ppce300 = "powerpc ppce300"
diff --git a/meta/conf/machine/include/tune-ppce500.inc b/meta/conf/machine/include/tune-ppce500.inc
index 22208f0..fe62445 100644
--- a/meta/conf/machine/include/tune-ppce500.inc
+++ b/meta/conf/machine/include/tune-ppce500.inc
@@ -1,6 +1,11 @@ 
+DEFAULTTUNE ?= "ppce500"
+
 require conf/machine/include/powerpc/arch-powerpc.inc
 
-TUNE_CCARGS = "-mcpu=8540"
-BASE_PACKAGE_ARCH = "ppce500"
-TUNE_PKGARCH = "ppce500"
-PACKAGE_EXTRA_ARCHS = "powerpc ppce500"
+TUNEVALID[ppce500] = "Enable ppce500 specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500", "-mcpu=8540", "", d)}"
+TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce500", "ppce500", "", d)}"
+
+AVAILTUNES += "ppce500"
+TUNE_FEATURES_tune-ppce500 = "m32 ppce500"
+PACKAGE_EXTRA_ARCHS_tune-ppce500 = "powerpc ppce500"
diff --git a/meta/conf/machine/include/tune-ppce500mc.inc b/meta/conf/machine/include/tune-ppce500mc.inc
index 182d019..0d3640f 100644
--- a/meta/conf/machine/include/tune-ppce500mc.inc
+++ b/meta/conf/machine/include/tune-ppce500mc.inc
@@ -1,5 +1,11 @@ 
+DEFAULTTUNE ?= "ppce500mc"
+
 require conf/machine/include/powerpc/arch-powerpc.inc
 
-TUNE_CCARGS = "-mcpu=e500mc"
-TUNE_PKGARCH = "ppce500mc"
-PACKAGE_EXTRA_ARCHS = "powerpc ppce500mc"
+TUNEVALID[ppce500mc] = "Enable ppce500mc specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "-mcpu=e500mc", "", d)}"
+TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "ppce500mc", "", d)}"
+
+AVAILTUNES += "ppce500mc"
+TUNE_FEATURES_tune-ppce500mc = "m32 ppce500mc"
+PACKAGE_EXTRA_ARCHS_tune-ppce500mc = "powerpc ppce500mc"
diff --git a/meta/conf/machine/include/tune-ppce500v2.inc b/meta/conf/machine/include/tune-ppce500v2.inc
index daf2d58..e6b48a2 100644
--- a/meta/conf/machine/include/tune-ppce500v2.inc
+++ b/meta/conf/machine/include/tune-ppce500v2.inc
@@ -1,5 +1,11 @@ 
+DEFAULTTUNE ?= "ppce500v2"
+
 require conf/machine/include/powerpc/arch-powerpc.inc
 
-TUNE_CCARGS = "-mcpu=8548 -mabi=spe -mspe"
-TUNE_PKGARCH = "ppce500v2"
-PACKAGE_EXTRA_ARCHS = "powerpc ppce500v2"
+TUNEVALID[ppce500mc] = "Enable ppce500mc specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500v2", "-mcpu=8548", "", d)}"
+TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce500v2", "ppce500v2", "", d)}"
+
+AVAILTUNES += "ppce500v2"
+TUNE_FEATURES_tune-ppce500v2 = "m32 spe ppce500v2"
+PACKAGE_EXTRA_ARCHS_tune-ppce500v2 = "powerpc ppce500v2"