openembedded-core.git/meta/conf/machine, branch fido Mirror of openembedded-core feature-arm-thumb.inc: Fix ARMPKGSFX_THUMB value 2015-12-16T20:55:25+00:00 Martin Jansa martin.jansa@gmail.com 2015-06-30T14:15:00+00:00 17b3112a3d6fc4c777429f8b5965206889c55cc3 * my previous thumb related commit: commit 3e760031f91fb87c3e2f62b77a117eb41164f259 Author: Martin Jansa <martin.jansa@gmail.com> Date: Wed Feb 18 15:40:35 2015 +0100 feature-arm-thumb.inc: respect ARM_INSTRUCTION_SET when adding thumb suffix unfortunately removed conditional on "thumb" in TUNE_FEATURES, when setting ARMPKGSFX_THUMB * in case we have MACHINE without "thumb" in TUNE_FEATURES and distro setting ARM_INSTRUCTION_SET to "thumb" we end with: ARM_INSTRUCTION_SET="thumb" ARM_THUMB_OPT="thumb" ARM_M_OPT="thumb" # TUNE_CCARGS correctly not adding -mthumb TUNE_CCARGS=" -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mfpu=neon" # but ARMPKGSFX_THUMB and TUNE_PKGARCH including "t2": ARMPKGSFX_THUMB="t2" TUNE_PKGARCH="armv7at2-vfp-neon" # causing following error: Error, the PACKAGE_ARCHS variable does not contain TUNE_PKGARCH (armv7at2-vfp-neon). (From OE-Core master rev: 951200673af27538beaef647a33308b4f15d1fb0) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Joshua Lock <joshua.lock@collabora.co.uk> 
* my previous thumb related commit:
  commit 3e760031f91fb87c3e2f62b77a117eb41164f259
  Author: Martin Jansa <martin.jansa@gmail.com>
  Date:   Wed Feb 18 15:40:35 2015 +0100

    feature-arm-thumb.inc: respect ARM_INSTRUCTION_SET when adding thumb
    suffix

  unfortunately removed conditional on "thumb" in TUNE_FEATURES, when
  setting ARMPKGSFX_THUMB

* in case we have MACHINE without "thumb" in TUNE_FEATURES and distro
  setting ARM_INSTRUCTION_SET to "thumb" we end with:
  ARM_INSTRUCTION_SET="thumb"
  ARM_THUMB_OPT="thumb"
  ARM_M_OPT="thumb"

  # TUNE_CCARGS correctly not adding -mthumb
  TUNE_CCARGS=" -march=armv7-a  -mthumb-interwork -mfloat-abi=softfp -mfpu=neon"

  # but ARMPKGSFX_THUMB and TUNE_PKGARCH including "t2":
  ARMPKGSFX_THUMB="t2"
  TUNE_PKGARCH="armv7at2-vfp-neon"

  # causing following error:
  Error, the PACKAGE_ARCHS variable does not contain TUNE_PKGARCH (armv7at2-vfp-neon).

(From OE-Core master rev: 951200673af27538beaef647a33308b4f15d1fb0)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Joshua Lock <joshua.lock@collabora.co.uk>
soc-family.inc: Add a default SOC_FAMILY value 2015-06-28T08:42:00+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2015-06-01T21:14:10+00:00 7c763846bca4347d6b9e8cc388ad075f00123235 Otherwise, if MACHINEOVERRIDES is expanded before SOC_FAMILY is set (which may happen as MACHINEOVERRIDES is included in OVERRIDES) we can see: ExpansionError: Failure expanding variable MACHINEOVERRIDES, expression was ${@['', '${SOC_FAMILY}:']['${SOC_FAMILY}' != '']}p1022ds which triggered exception SyntaxError: EOL while scanning string literal (MACHINEOVERRIDES, line 1) To avoid this, give SOC_FAMILY a default empty value so it doesn't get read as None. (From OE-Core rev: dee005b6e1bc353230f9f27a469b2054a644e542) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
Otherwise, if MACHINEOVERRIDES is expanded before SOC_FAMILY is set
(which may happen as MACHINEOVERRIDES is included in OVERRIDES) we can
see:

ExpansionError: Failure expanding variable MACHINEOVERRIDES, expression was
${@['', '${SOC_FAMILY}:']['${SOC_FAMILY}' != '']}p1022ds
which triggered exception SyntaxError: EOL while scanning string literal (MACHINEOVERRIDES, line 1)

To avoid this, give SOC_FAMILY a default empty value so it doesn't
get read as None.

(From OE-Core rev: dee005b6e1bc353230f9f27a469b2054a644e542)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
machine/qemu: Switch from ext3 to ext4 2015-02-21T22:04:26+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2015-02-20T17:39:21+00:00 430b9ae71b1aa76f8421127d17e0e0723d4818d3 There is no good reason not to use ext4 at this point, it has advantages and few drawbacks. Therefore switch the qemu machines over (and the default runqemu script options). Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
There is no good reason not to use ext4 at this point, it has advantages
and few drawbacks. Therefore switch the qemu machines over (and the default
runqemu script options).

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
arch-armv7a.inc, tune-arm920t.inc: Fix PACKAGE_EXTRA_ARCHS 2015-02-21T22:04:25+00:00 Martin Jansa martin.jansa@gmail.com 2015-02-19T15:00:48+00:00 fd7f3cd9affbfb9ce483a5a1d6054da2365fcb0e * each DEFAULTTUNE with thumb enabled should list it's arm variants in PACKAGE_EXTRA_ARCHS, otherwise packages which force arm ISA won't be found in do_rootfs * armv7athf-neon-vfpv4 was missing its own PACKAGE_ARCH and also the arm variant Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
* each DEFAULTTUNE with thumb enabled should list it's arm variants in
  PACKAGE_EXTRA_ARCHS, otherwise packages which force arm ISA won't be
  found in do_rootfs
* armv7athf-neon-vfpv4 was missing its own PACKAGE_ARCH and also the arm
  variant

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
feature-arm-thumb.inc: respect ARM_INSTRUCTION_SET when adding thumb suffix 2015-02-21T22:04:25+00:00 Martin Jansa martin.jansa@gmail.com 2015-02-18T14:40:35+00:00 3e760031f91fb87c3e2f62b77a117eb41164f259 * this means that recipes with ARM_INSTRUCTION_SET explicitly changed to arm will be built in feed without thumb suffix, the same does apply for workdir, e.g. after "bitbake glib-2.0" you can see: tmp-glibc/work/armv5e-oe-linux-gnueabi: glib-2.0 glibc glibc-initial tmp-glibc/work/armv5te-oe-linux-gnueabi: acl db gdk-pixbuf kmod .... and tmp-glibc/deploy/ipk: all armv5e armv5te qemuarm * feed config should be ok, because all default DEFAULTTUNEs always include "arm" variants of all supported PACKAGE_ARCHs * for more details see http://lists.openembedded.org/pipermail/openembedded-core/2014-April/091960.html the toolchain path issues were resolved in 1.8 * add ARM_INSTRUCTION_SET = "arm" to glibc-collateral.inc and comment in glibc.inc to fix glibc-locale and glibc-scripts build Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
* this means that recipes with ARM_INSTRUCTION_SET explicitly changed
  to arm will be built in feed without thumb suffix, the same does apply
  for workdir, e.g. after "bitbake glib-2.0" you can see:

  tmp-glibc/work/armv5e-oe-linux-gnueabi:
  glib-2.0  glibc  glibc-initial

  tmp-glibc/work/armv5te-oe-linux-gnueabi:
  acl              db              gdk-pixbuf     kmod  ....

  and

  tmp-glibc/deploy/ipk:
  all  armv5e  armv5te  qemuarm

* feed config should be ok, because all default DEFAULTTUNEs always
  include "arm" variants of all supported PACKAGE_ARCHs

* for more details see
  http://lists.openembedded.org/pipermail/openembedded-core/2014-April/091960.html
  the toolchain path issues were resolved in 1.8

* add ARM_INSTRUCTION_SET = "arm" to glibc-collateral.inc and comment in
  glibc.inc to fix glibc-locale and glibc-scripts build

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
arch-mips.inc: Change definition of TRANSLATED_TARGET_ARCH 2015-01-29T10:37:51+00:00 Mark Hatle mark.hatle@windriver.com 2015-01-22T04:45:28+00:00 4b3a2b703b20583bd107f00a297d972e9bfb514a [YOCTO #7230] In certain system configurations TRANSLATED_TARGET_ARCH will not expand in the right order for gcc-cross-candian-mips64n32 to be generated properly. This will cause SDKs to fail to generate properly. Changing the global definition of TRANSLATED_TARGET_ARCH always expands the ABIEXTENSION, which causes the OVERRIDES to pick it up as well. This effectively defines a new class of overrides for the 'n32'. The side effect is that we need to duplicate some mips64 overrides, and redefine others that were previously 'n32' or 'mips64' exclusive to have the correct semantics. Signed-off-by: Mark Hatle <mark.hatle@windriver.com> 
[YOCTO #7230]

In certain system configurations TRANSLATED_TARGET_ARCH will not
expand in the right order for gcc-cross-candian-mips64n32 to be
generated properly.

This will cause SDKs to fail to generate properly.

Changing the global definition of TRANSLATED_TARGET_ARCH always
expands the ABIEXTENSION, which causes the OVERRIDES to pick it up
as well.  This effectively defines a new class of overrides for the 'n32'.

The side effect is that we need to duplicate some mips64 overrides, and
redefine others that were previously 'n32' or 'mips64' exclusive to have
the correct semantics.

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
feature-arm-thumb.inc: Remove extra space on thumb override 2015-01-29T10:37:51+00:00 Mark Hatle mark.hatle@windriver.com 2015-01-14T19:30:42+00:00 330119da319a08c13ca3350270a95d66d18ffb94 The extra space makes the overrides look like "foo:bar: thumb:foobar". This may prevent thumb from working properly, and the space was never intended in the original fix. Signed-off-by: Mark Hatle <mark.hatle@windriver.com> 
The extra space makes the overrides look like "foo:bar: thumb:foobar".

This may prevent thumb from working properly, and the space was never
intended in the original fix.

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
arch-mips.inc: Add the MIPS ABIEXTENSION to toolchain name 2015-01-21T14:28:43+00:00 Mark Hatle mark.hatle@windriver.com 2015-01-15T15:05:33+00:00 0bcc01121e928d0be7a0550e500425852c63cf98 [YOCTO #7143] When the system is configured for a multilib SDK, such as: require conf/multilib.conf MULTILIBS = "multilib:lib32 multilib:lib64" DEFAULTTUNE = "mips32r2" DEFAULTTUNE_virtclass-multilib-lib32 = "mips64-n32" DEFAULTTUNE_virtclass-multilib-lib64 = "mips64" Only one of the mips64-n32 or mips64 toolchains is built. Causing the other to be unavailable. This is due to both recipes ending up with the same PN. The toolchain uses the TRANSLATED_TARGET_ARCH in it's name, however the target for mips64 and mips64 n32 were the same, causing the conflict. Avoid this conflict by adding the ABIEXTENSION to the name. Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
[YOCTO #7143]

When the system is configured for a multilib SDK, such as:

require conf/multilib.conf
MULTILIBS = "multilib:lib32 multilib:lib64"
DEFAULTTUNE = "mips32r2"
DEFAULTTUNE_virtclass-multilib-lib32 = "mips64-n32"
DEFAULTTUNE_virtclass-multilib-lib64 = "mips64"

Only one of the mips64-n32 or mips64 toolchains is built.  Causing the
other to be unavailable.  This is due to both recipes ending up with the
same PN.

The toolchain uses the TRANSLATED_TARGET_ARCH in it's name, however the
target for mips64 and mips64 n32 were the same, causing the conflict.
Avoid this conflict by adding the ABIEXTENSION to the name.

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
aarch-arm64: Update tune files 2014-12-22T10:53:56+00:00 Mark Hatle mark.hatle@windriver.com 2014-12-18T08:51:14+00:00 03d2f5646485b565cc14a0009b7d5224ab298f4c arch-arm64 is the base tune file for aarch64. Update this to allow the system to work with both aarch32 and aarch64 (multilib). arch-armv8 is for compatibility, it simply uses the base config for now. feature-arm-thumb was updated, since aarch64 mode does NOT have thumb support. We should only be processing warnings and additional arguments if thumb support is enabled on the processor core. Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
arch-arm64 is the base tune file for aarch64.  Update this to allow the
system to work with both aarch32 and aarch64 (multilib).

arch-armv8 is for compatibility, it simply uses the base config for now.

feature-arm-thumb was updated, since aarch64 mode does NOT have thumb support.
We should only be processing warnings and additional arguments if thumb
support is enabled on the processor core.

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add machine qemuarm64 2014-12-21T17:36:01+00:00 Kai Kang kai.kang@windriver.com 2014-12-18T08:50:58+00:00 d7314c3bc804b7bcc921b0a6c5b63d71ca2e73db Add machine qemuarm64. The configure files are derived from linaro. Update: * rename genericarmv8 to qemuarm64 for coordination in oe-core * include qemu.inc then remove common part of config * disable using autoserial * move arch-armv8.inc from machine/include/arm64 to machine/include/arm [YOCTO #6487] Signed-off-by: Kai Kang <kai.kang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
Add machine qemuarm64. The configure files are derived from linaro.

Update:
* rename genericarmv8 to qemuarm64 for coordination in oe-core
* include qemu.inc then remove common part of config
* disable using autoserial
* move arch-armv8.inc from machine/include/arm64 to machine/include/arm

[YOCTO #6487]

Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>