The per-tune qemu options variable is QEMU_EXTRAOPTIONS_${TUNE_PKGARCH},
but this doesn't follow the pattern of all of the other tune-specific
variables in the machine configuration which is VARIABLE:tune-[name].
Rename QEMU_EXTRAOPTIONS_${TUNE_PKGARCH} to
QEMU_EXTRAOPTIONS:tune-${TUNE_PKGARCH} for consistency.
Note that this will mean that BSPs need to update any assignments of
this variable.
(From OE-Core rev: 7f981d074442b901f7e64dbdb9db851ff31c3733)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Every other architecture has the QEMU_EXTRAOPTIONS assignments in the
tune files, so move the PPC ones too.
(From OE-Core rev: ba05251c89d8cc243e861886124573c83197e949)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Description: now we can tune our build only for power7 or power9
processor for PowerPC arch, this patch add posibility to choose power8 tune.
(From OE-Core rev: 10f7eeafd16c8b825b3c9b96b8433311f122df1e)
Signed-off-by: Aleksey Smirnov <aleksey.smirnov@yadro.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
OE-core previously carried patches to glibc that added optimized sqrt
implementations for various PowerPC chips. These were recently removed,
which now results in errors when compiling glibc with certian PowerPC
machine tunes:
checking sysdep dirs... configure: error: The 603e subspecies of powerpc is not supported.
Remove setting GLIBC_EXTRA_OECONF with parameters that are no longer
valid. Also remove a commented out setting of the variable that probably
isn't vaild anyway.
Fixes: 2511e937f445 ("glibc: Drop ppc sqrt optimisations")
(From OE-Core rev: 40f15066c24720aae36713c9856ffb4fae146a45)
Signed-off-by: Robert Joslyn <robert.joslyn@redrectangle.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move all of the tune files found in conf/machine/include into their
respective architecture directories in that same location. All
references to these will need to be updated. So, change the relevant
ones for this tree in this commit as well.
For the ARM tunes, nest them one further into armv8a, armv8m, etc. and
rename some to make them uniform with the rest of the tunes.
(From OE-Core rev: b6f15209bcfff953cce69da97a93f9ddff141ced)
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is the result of automated script conversion:
scripts/contrib/convert-overrides.py <oe-core directory>
converting the metadata to use ":" as the override character instead of "_".
(From OE-Core rev: 42344347be29f0997cc2f7636d9603b1fe1875ae)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This helps in constructing right arch for target tuple name for
Little-endian ppc
(From OE-Core rev: b6ac40f1cbabb20896bf113568f7735a462ed1a6)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This helps in defining LE tunes and at the same time specifies
endianness on compiler cmdline clearly, clang e.g. defaults to
little-endian always, so unless specified with -mbig-endian won't
compile the code right
(From OE-Core rev: e0fd699d398f0e88fb208970dea7b74e6e9431fe)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Historically first PowerPC ABI was big-endian only (elfv1 currently). It
is standard ABI for both 32-bit ppc and 64-bit ppc64 architectures.
With PowerPC little-endian support new ABI was introduced (elfv2) and it
is used primarily with ppc64le target only. While it has support for
big-endian it is not commonly used and elfv1 still preferred.
Musl does support only elfv2 ABI for both LE and BE and does not have
any plans to support elfv1.
Since then to build for powerpc64 with musl new ABI should be used. As
expected it is not compatible with elfv1 but that isn't problem as long
as there is no binary distributed software or assembly code written for
elfv1 ABI.
(From OE-Core rev: 68c9641855199f34aabe1050e863c21830116fe1)
Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* some tunes were using weak assignment for TUNE_FEATURES, unify
all tunes to use normal assignment so it behaves consistently
(From OE-Core rev: 0a52bd3ed23e66200401d0836aad783095e7c7a0)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* 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
(From OE-Core rev: b7430ff83760ac29079d20dc7c62f498a0a9d55d)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Cleanup the PowerPC tunings to match the new tuning README file.
Default PowerPC to using TUNE_PKGARCH = ${TUNE_PKGARCH_tune-<tune>}
Fix AVAILTUNE settings in ppc603e, and ppce500mc to be addative.
Correct potentially overlapping "spe" definitions in ppce500 and ppce500v2.
(From OE-Core rev: f81f71bcff4bb1032b034b068efe6065113ca9e7)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We can use the default value for TUNE_PKGARCH, and now we just
append "-nf" if TARGET_FPU is fpu-soft
(From OE-Core rev: c2d96179c00e6600698d3fbc5cf5c95313ab7535)
Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Set PACKAGE_EXTRA_ARCHS for the generic tunes ("powerpc" and
"powerpc-nf") thus allowing to use them instead of tuning to the
specific CPU.
(From OE-Core rev: 5eafbe2d8684ee1c45477bfd69b579af47adccd9)
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.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.
(From OE-Core rev: 2c9bd779b008be266072f3c6d79430f63ec02241)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
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.
(From OE-Core rev: f9a8b719dd3fc7593a509c8f288caf1486add2f8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
All 64-bit PPC processors support hard-float so no need to support
soft-float.
(From OE-Core rev: 54c7d1faf5376c8fb9b19f4e192ce959c8442782)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When figuring out how to set TUNE_CCARGS we should look for 'm64' not
'n64' in TUNE_FEATURES.
(From OE-Core rev: 7a9ea28e69e8121a559f610dd2330edd33f0a907)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
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.
(From OE-Core rev: 5f9d56bd64997b93ed7e46c117851002a0556654)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
