openembedded-core.git/meta/conf/machine/include/powerpc, branch 2011-1 Mirror of openembedded-core tune/arch-powerpc64: include arch-powerpc.inc to keep things in sync 2011-08-05T16:13:00+00:00 Kumar Gala galak@kernel.crashing.org 2011-08-04T07:23:47+00:00 2c9bd779b008be266072f3c6d79430f63ec02241 Added a DEFAULTTUNE setting and included arch-powerpc.inc. This way we pick up the changes to TUNE_PKGARCH and things should be kept more in sync going forward. Signed-off-by: Kumar Gala <galak@kernel.crashing.org> 
Added a DEFAULTTUNE setting and included arch-powerpc.inc.  This way we
pick up the changes to TUNE_PKGARCH and things should be kept more in
sync going forward.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
tune/ppc: Fix various TUNE_PKGARCH issues 2011-08-02T13:40:42+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2011-08-02T11:40:06+00:00 f9a8b719dd3fc7593a509c8f288caf1486add2f8 We need to ensure only one value ends up in TUNE_PKGARCH rather than several. This change ensures consistency accross all the PPC tune files and that they correctly inherit the core value but also allow it to be overwritten. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
We need to ensure only one value ends up in TUNE_PKGARCH rather than several.
This change ensures consistency accross all the PPC tune files and that they
correctly inherit the core value but also allow it to be overwritten.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
tune/arch-powerpc64: Remove support for soft-float from ppc64 2011-08-01T12:58:15+00:00 Kumar Gala galak@kernel.crashing.org 2011-07-28T20:59:05+00:00 54c7d1faf5376c8fb9b19f4e192ce959c8442782 All 64-bit PPC processors support hard-float so no need to support soft-float. Signed-off-by: Kumar Gala <galak@kernel.crashing.org> 
All 64-bit PPC processors support hard-float so no need to support
soft-float.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
tune/arch-powerpc64: Fix typo with 64-bit TUNE_CCARGS handling 2011-08-01T12:58:14+00:00 Kumar Gala galak@kernel.crashing.org 2011-07-28T20:59:04+00:00 7a9ea28e69e8121a559f610dd2330edd33f0a907 When figuring out how to set TUNE_CCARGS we should look for 'm64' not 'n64' in TUNE_FEATURES. Signed-off-by: Kumar Gala <galak@kernel.crashing.org> 
When figuring out how to set TUNE_CCARGS we should look for 'm64' not
'n64' in TUNE_FEATURES.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Add basic PowerPC core tune config 2011-07-27T14:43:57+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2011-07-26T11:36:53+00:00 3212029f0967dd353fec8cc147d2b95031d1018a Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move architecture specific TARGET_OS mangling into tune files 2011-07-25T13:19:54+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2011-07-22T16:54:32+00:00 f10a3457cdfbb4a94978da998d178d4254632fa7 Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
conf/machine/include: Start to fill out architecture specific tune include files and tune features 2011-07-25T13:19:54+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2011-07-22T16:32:21+00:00 5f9d56bd64997b93ed7e46c117851002a0556654 These changes revolve around the idea of tune features. These are represented by 'flag' strings that are included in the TUNE_FEATURES variable. Any string included in TUNE_FEATURES should also add a TUNEVALID[<name>] entry so we can know which flags are available in TUNE_FEATURES and have documentation about what the flags do. We will add sanity code to error if flags are listed in TUNE_FEATURES but are not documented in TUNEVALID. A given tune configuration will want to define one or more predetermined sets of _FEATURE flag lists. These are defined in the form TUNE_FEATURES_tune-<name>. For defined tune configuation, <name> should be added to the AVAILTUNE list so that we can determine what tune configurations are available. Flags cannot be used in this case as with TUNEVALID since its useful to be able to build up tune lists from other TUNE_FEATURES_tune-yyy options. A given tune configuration may also define PACKAGE_EXTRA_ARCHS_tune-<name> and BASE_LIB_tune-<name> to control the multilib location. All options can be overridden by the distro or local user configuration. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
These changes revolve around the idea of tune features. These are represented by
'flag' strings that are included in the TUNE_FEATURES variable.

Any string included in TUNE_FEATURES should also add a TUNEVALID[<name>] entry so
we can know which flags are available in TUNE_FEATURES and have documentation about
what the flags do. We will add sanity code to error if flags are listed in
TUNE_FEATURES but are not documented in TUNEVALID.

A given tune configuration will want to define one or more predetermined sets of
_FEATURE flag lists. These are defined in the form TUNE_FEATURES_tune-<name>.
For defined tune configuation, <name> should be added to the AVAILTUNE list so that
we can determine what tune configurations are available. Flags cannot be used in this
case as with TUNEVALID since its useful to be able to build up tune lists from other
TUNE_FEATURES_tune-yyy options.

A given tune configuration may also define PACKAGE_EXTRA_ARCHS_tune-<name> and
BASE_LIB_tune-<name> to control the multilib location. All options can be overridden
by the distro or local user configuration.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>