openembedded-core.git/meta/conf/machine/include/arm, branch dora

tune-cortexa*.inc: fix tunings for cortex a5, a7, a8, a9, a15 machines.

2013-06-12T16:54:28+00:00

Using CORTEX_ID variable reference in the tuning overrides did not work.
This reverts those changes, and adds a tuning file for the cortex-a5.

Revert "tune-cortexa5.inc: Add tune file for cortex-a5"
Revert "tune-cortexa.inc: create a common include for cortex-a armv7a tuning"

Signed-off-by: Andy Voltz 
Signed-off-by: Richard Purdie

tune-cortexa.inc: create a common include for cortex-a armv7a tuning

2013-06-07T15:41:03+00:00

The tuning files for the cortex-a* processors are mostly identical for
the A7,A8,A9,A15 processors. Rework these files to use a CORTEX_ID
variable to setup the tuning for each specific processor.

Signed-off-by: Andy Voltz 
Signed-off-by: Saul Wold

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

conf/machine: Clean up MACHINEOVERRIDES handling

2013-03-25T17:39:36+00:00

OVERRIDES reads from left to right, least to most specific. We were
appending to MACHINEOVERRIDES when we should have been prepending so
the ordering of qemuall verses qemuxxx was incorrect, as was the x86
override and several of the arm overrides. This patch is a batch cleanup
of the various issues to correct the order from least to most specific.
The include order does matter and we needed to tweak some of that in this
patch too.

[YOCTO #4090]

Signed-off-by: Richard Purdie

arch-armv6: add tunes without vfp enabled

2012-12-03T14:46:31+00:00

This work was made by Victor Enriquez and then modified by Denis Carikli
who was helped by Mark Hatle comments. And in the end modified by Martin
Jansa to support different ARMPKGARCH and removed explicit -novfp suffix.

The changes are for adding support to armv6-novfp, for building binaries
for armv6 machines without vfp, for example the htc dream.

Signed-off-by: Mark Hatle 
Signed-off-by: Denis 'GNUtoo' Carikli 
Signed-off-by: Víctor Enríquez 
Signed-off-by: Martin Jansa 
Signed-off-by: Saul Wold 
Signed-off-by: Richard Purdie

arch-armv4.inc: add --fix-v4bx to TARGET_LD_KERNEL_ARCH only for armv4 and strongarm1100

2012-12-03T14:46:22+00:00

* without this patch it does apply --fix-v4bx not only to armv4, but
  also all higher (because they also have armv4 in TUNE_FEATURES)
* it causes SIGILL on armv4t
  http://lists.linuxtogo.org/pipermail/openembedded-devel/2012-November/042298.html
* someone please test on armv4 device (I tested only bitbake -e output
  that it's correctly applied with DEFAULTTUNE == armv4
* maybe we can should fix this in binutils instead (both 2.22 and 2.23
  are affected)

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

arch-arm*: unify appending to TUNE_FEATURES

2012-12-03T14:46:11+00:00

* that we always use TUNE_FEATURES_tune-arm* variable and add only one TUNE_FEATURE to it
* for bigendian always use littleendian counterpart and append bigendian TUNE_FEATURE

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

arch-armv[457]*: fix PACKAGE_EXTRA_ARCHS for bigendian TUNEs

2012-12-03T14:46:01+00:00

* bigendian should not include little endian PACKAGE_ARCHS

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

arch-armv5: fix missing thumb TUNE_FEATURE in armv5t-vfp and following tunes

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

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

arm/arch-arm: define ARMPKGARCH_tune- for default tunes

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

* tune-foo is not valid override, for it to work I had to add
  ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"
  but that doesn't work without value defined for every supported
  DEFAULTTUNE value, otherwise it's expanded like this
  TUNE_PKGARCH (${ARMPKGARCH_tune-armv5te}te).

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