openembedded-core.git/meta/conf/machine/include/mips/arch-mips.inc, branch morty Mirror of openembedded-core arch-mips.inc: remove duplicates from PACKAGE_ARCHS 2016-10-15T08:58:48+00:00 Robert Yang liezhi.yang@windriver.com 2016-10-14T10:08:36+00:00 e57d70e6803c63823ae3a7c7971fc06db3748b68 Fixed: MACHINE = "qemumips64" DEFAULTTUNE = "mips64-o32" $ bitbake linux-yocto ERROR: OE-core's config sanity checker detected a potential misconfiguration. Either fix the cause of this error or at your own risk disable the checker (see sanity.conf). Following is the list of potential problems / advisories: Error, the PACKAGE_ARCHS variable contains duplicates. The following archs are listed more than once: mips64-o32 Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> 
Fixed:
MACHINE = "qemumips64"
DEFAULTTUNE = "mips64-o32"

$ bitbake linux-yocto
ERROR:  OE-core's config sanity checker detected a potential misconfiguration.
    Either fix the cause of this error or at your own risk disable the checker (see sanity.conf).
    Following is the list of potential problems / advisories:

    Error, the PACKAGE_ARCHS variable contains duplicates. The following archs are listed more than once: mips64-o32

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
arch-mips: Add mipsisa{32, 64}r6{el, } tunes 2016-10-07T15:43:49+00:00 Zubair Lutfullah Kakakhel Zubair.Kakakhel@imgtec.com 2016-10-04T11:31:21+00:00 6b2e0c60c3222a13b33284f258d5c340222d759f Add support for MIPS Release 6 ISA and the various tune configurations. This patch adds the tunes for 32r6 and 64r6 n64 and not the n32 variants at the moment. Release 6 onwards, the tuples are now - mipsisa32r6-linux-gnu - mipsisa32r6el-linux-gnu - mipsisa64r6-linux-gnuabi64 - mipsisa64r6el-linux-gnuabi64 - mipsisa64r6-linux-gnuabin32 - mipsisa64r6el-linux-gnuabin32 For more details, check https://wiki.debian.org/Multiarch/Tuples Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
Add support for MIPS Release 6 ISA and the various tune
configurations.

This patch adds the tunes for 32r6 and 64r6 n64 and not the n32
variants at the moment.

Release 6 onwards, the tuples are now
 - mipsisa32r6-linux-gnu
 - mipsisa32r6el-linux-gnu
 - mipsisa64r6-linux-gnuabi64
 - mipsisa64r6el-linux-gnuabi64
 - mipsisa64r6-linux-gnuabin32
 - mipsisa64r6el-linux-gnuabin32

For more details, check https://wiki.debian.org/Multiarch/Tuples

Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
arch-mips: Add mips64-o32 tunes 2016-09-23T17:06:10+00:00 Zubair Lutfullah Kakakhel Zubair.Kakakhel@imgtec.com 2016-09-23T14:28:08+00:00 ae5073c4abd8935c01d14d3e6395124f815bd10b Add mips64 + o32 rootfs abi tune configurations Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
Add mips64 + o32 rootfs abi tune configurations

Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
arch-mips.inc: Disable QEMU usermode usage when building with n32 ABI 2016-09-03T22:45:46+00:00 Alexander Kanavin alexander.kanavin@linux.intel.com 2016-09-01T17:50:54+00:00 66aa39a959bd41f7063fe64a9225eb9fd6c3293b QEMU usermode doesn't support n32 binaries, erroring with "Invalid ELF image for this architecture". Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
QEMU usermode doesn't support n32 binaries, erroring with "Invalid
ELF image for this architecture".

Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
meta/conf/machine: use ' inside quoted values 2015-12-01T21:30:55+00:00 Martin Jansa martin.jansa@gmail.com 2015-11-18T18:37:17+00:00 924ccf202a6d89de32fc34a140bf9e35e8e43b4e Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> 
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
arch-mips.inc: don't override TRANSLATED_TARGET_ARCH 2015-07-31T14:15:12+00:00 Dmitry Eremin-Solenikov dbaryshkov@gmail.com 2015-07-01T14:02:19+00:00 3ee5c9ad302bc05c75badbe29dd983a043a114c2 Currently MIPS64 N32 is broken. There is internal disagreement between TARGET_ARCH (which doesn't contain ABIEXTENSION) and TRANSLATED_TARGET_ARCH (which contains ABIEXTENSION). ABI is already encoded into the TARGET_OS. ARM tunes in the same situation override neither the TARGET_ARCH nor the TRANSLATED_TARGET_ARCH. So let's drop this override. Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
Currently MIPS64 N32 is broken. There is internal disagreement
between TARGET_ARCH (which doesn't contain ABIEXTENSION) and
TRANSLATED_TARGET_ARCH (which contains ABIEXTENSION). ABI is already
encoded into the TARGET_OS. ARM tunes in the same situation override
neither the TARGET_ARCH nor the TRANSLATED_TARGET_ARCH. So let's drop
this override.

Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@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>
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>
conf/machine: use .= instead of += in TUNE_CCARGS 2013-04-29T13:43:50+00:00 Martin Jansa martin.jansa@gmail.com 2013-04-24T13:42:12+00:00 b7430ff83760ac29079d20dc7c62f498a0a9d55d * 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 <Martin.Jansa@gmail.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> 
* 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 <Martin.Jansa@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
insane.bbclass and friends: Fix sanity checks and multlib headers for n32 2012-10-27T08:31:36+00:00 Peter Seebach peter.seebach@windriver.com 2012-10-23T22:56:00+00:00 c8e8e8ba22eaa335ac72f0e5b317f804035133e2 The n32 architecture is odd, in that it's a mips64 ABI which happens to be 32-bit. To handle this, we need something in the environment which can be used to distinguish it. The obvious place to stash this is the ABI suffix, so we use "n32" as an ABI suffix. This allows a couple of improved checks: 1. In insane.bbclass, we can use "linux-gnun32" to discern that it's okay for a mips64 binary to be a 32-bit binary in some cases. 2. In multilib_header, we can check for the n32 ABI, and use a distinct value. 3. In siteinfo, add linux-gnun32 as a synonym for linux, similar to what's done for linux-gnux32, and tell the mips*-linux-gnun32 variants to pick up the corresponding mips-linux site configs. Note that the multilib header wrapper already has n32 hooks in it, there was just nothing creating -n32 header variants. Signed-off-by: Peter Seebach <peter.seebach@windriver.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> 
The n32 architecture is odd, in that it's a mips64 ABI which happens
to be 32-bit. To handle this, we need something in the environment
which can be used to distinguish it. The obvious place to stash this
is the ABI suffix, so we use "n32" as an ABI suffix. This allows
a couple of improved checks:

1. In insane.bbclass, we can use "linux-gnun32" to discern that it's
okay for a mips64 binary to be a 32-bit binary in some cases.
2. In multilib_header, we can check for the n32 ABI, and use a distinct
value.
3. In siteinfo, add linux-gnun32 as a synonym for linux, similar to
what's done for linux-gnux32, and tell the mips*-linux-gnun32 variants
to pick up the corresponding mips-linux site configs.

Note that the multilib header wrapper already has n32 hooks in it, there
was just nothing creating -n32 header variants.

Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>