openembedded-core.git/meta/conf/machine/include/tune-cortexm3.inc, branch fido

conf/machine: use .= instead of += in TUNE_CCARGS

2013-04-29T13:43:50+00:00

* number of TUNE_CCARGS conditionals is important if we add
  extra space with each one in "else" branch

  I'm building for 2 MACHINEs one is cortexa9, second is cortexa8

  few months ago we added TUNE_CCARGS[vardepvalue] in bitbake.conf
  http://git.openembedded.org/openembedded-core/commit/?id=03f1e34ea3ce80931e9c3cd2ab22824f28a7233b

  which fixed some cases (like mentioned tune-xscale and tune-arm926ejs)
  where both had unused TUNE_CCARGS when common DEFAULTTUNE was used.

  with cortexa[89] it's different, because cortexa9 has one extra TUNE_CCARGS
  TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexa9", "-mtune=cortex-a9", "", d)}"
  which adds extra *space* even when not used because of '+=' and as result:

  $ bitbake-diffsigs tmp-eglibc/sstate-diff/1366797730/*/armv7*/adapterbase/*do_configure*
  basehash changed from f986789fb8fb3579ed6a3492cc8a8d10 to c851b5f838d945ee13072e9ad6725dca
  Variable TUNE_CCARGS value changed from
  ' -march=armv7-a     -mthumb-interwork -mfloat-abi=softfp -mfpu=neon '
  to
  ' -march=armv7-a     -mthumb-interwork -mfloat-abi=softfp -mfpu=neon  '
  Hash for dependent task gcc-runtime_4.7.bb.do_populate_sysroot changed from bdeabf7a86958b9110b566344b7916de to 2be5618e6bc8c57ec9db5659bf217915
  Hash for dependent task eglibc_2.17.bb.do_populate_sysroot changed from b4f40fc62dde684acd0a574532a55360 to 97fcb426603d4a1c1099c0504d2ebf7d
  Hash for dependent task glib-2.0_2.34.3.bb.do_populate_sysroot changed from fd2f90b83098c34e88d649d70f6ea4f5 to ebd740bb94ea3eb0a914efda6fc82c4a

Signed-off-by: Martin Jansa 
Signed-off-by: Saul Wold

tune-*: add PACKAGE_EXTRA_ARCHS entries starting with specific ARMPKGARCH

2012-12-03T14:45:40+00:00

* e.g. arm926ejs DEFAULT tune is compatible with all PACKAGE_EXTRA_ARCHS_tune-armv5te, but needs to list arm926ejs with all possible suffixes too

Signed-off-by: Martin Jansa 
Signed-off-by: Saul Wold 
Signed-off-by: Richard Purdie

arch-arm: define different ARMPKGARCH when different CCARGS are used

2012-11-26T10:00:26+00:00

* without this tune-xscale and tune-arm926ejs were both creating
  packages in armv5te feed, but each with different -mtune, with
  OEBasicHash enabled it was causing each package to rebuild with new
  -mtune after MACHINE switch, but that doesn't make sense with output
  stored in the same armv5te feed

* this makes different feed for each -mtune, but more generic one to be
  selected with DEFAULTTUNE

* tune-iwmmxt and tune-ep9312 were already using this, just move it
  bellow AVAILTUNES and use ARMPKGARCH_tune-foo syntax

* tune-cortexr4 and tune-cortexm3 are using armv7r/armv7m as ARMPKGARCH
  because there isn't another tune to use the same -march

Signed-off-by: Martin Jansa 
Signed-off-by: Richard Purdie

conf/machine/include: Cleanup ARM tunings to match README

2012-04-04T16:15:33+00:00

Cleanup the ARM tunings to match the new tunings README file.

The ARM tunings define TUNE_PKGARCH in a way that only one main
arm architecture, i.e. armv6, may be defined at the same time.  We
may have to revise these settings in the future, as well as figure
out a way to better differentiate various optimize tunings in the
package arch.  (This was not done, to preserve existing behavior!)

Fix a number of minor issues w/ the armv5 tunings where DSP variants
were referenced but not defined.

Fix incorrect armv7 entries in armv7a.

Fix PACKAGE_EXTRA_ARCHS definitions inside of tune-cortexm3 and tune-cortexr4.

Signed-off-by: Mark Hatle

tune-cortex{m1, m3, r4}: correct spelling of "cortex"

2011-07-29T16:47:56+00:00

Otherwise the test in TUNE_CCARGS will never match.

Signed-off-by: Phil Blundell 
Signed-off-by: Khem Raj

Add ARM tune file overhaul based largely on work from Mark Hatle

2011-07-27T14:43:38+00:00

Signed-off-by: Richard Purdie

conf/machine/include: Start to fill out architecture specific tune include files and tune features

2011-07-25T13:19:54+00:00

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[] 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-.
For defined tune configuation,  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- and
BASE_LIB_tune- to control the multilib location. All options can be overridden
by the distro or local user configuration.

Signed-off-by: Richard Purdie

conf/machine/include: Set TUNE_CCARGS instead of TARGET_CC_ARCH

2011-07-22T14:38:50+00:00

Since we're updating the tune file format, it makes sense to abstract
the compiler tune arguments at this point too. This means that should
these need to be overridden at any point, the original values can
still be obtained in a similar manner to the other TUNE* variables.

Whilst this isn't strictly necessary for any current need, its likely
good practise to standardise this behaviour.

Signed-off-by: Richard Purdie

conf/machine/tune: Overhaul tune include file variables

2011-07-22T14:38:40+00:00

There is currently consideradble confusion over how the tune files operate
and how these interact with the rest of the build system. This update/overhaul
changes things so the tune files are primarily resonsible for setting:

TUNE_ARCH - What was formerly set as TARGET_ARCH and is the value that
represents the architecture we're targetting.

TUNE_PKGARCH - The value that represents the tune confuration that this set
of tune parameters results in.

This allows the significant improvement that the core can now always determine
the target architecture value, even when TARGET_ARCH needs to be reset to
something different and likewise, there is one package architecture variable
the core can reference allowing simplification of the BASE_PACKAGE_ARCH, PACKAGE_ARCH
and FEED_ARCH variables.

Signed-off-by: Richard Purdie

bitbake.conf/tune.conf: Set BASE_PACKAGE_ARCH and build PACKAGE_ARCH from this

2008-07-17T20:40:34+00:00

git-svn-id: https://svn.o-hand.com/repos/poky/trunk@4857 311d38ba-8fff-0310-9ca6-ca027cbcb966