mirror of
https://git.yoctoproject.org/poky
synced 2026-06-17 06:19:56 +00:00
Alexander Kanavin
f2bb462850
Qemu 7.2 finally allows us to move beyond building for original Core 2/Core i7 era hardware, and this patch adds support for the newer generations. But first, a bit of background: Recently toolchains gained support for specifying x86-64 'levels' of instruction set support; v3 corresponds to 2013-era Haswell CPUs (and later), with AVX, AVX2 and a few other instructions that were introduced in that generation. I believe this is preferrable to picking a specific CPU model as the baseline. Here's Phoronix's feature article that explains the feature and the available levels: "Both LLVM Clang 12 and GCC 11 are ready to go in offering the new x86-64-v2, x86-64-v3, and x86-64-v4 targets. These x86_64 micro-architecture feature levels have been about coming up with a few "classes" of Intel/AMD CPU processor support rather than continuing to rely on just the x86_64 baseline or targeting a specific CPU family for optimizations. These new levels make it easier to raise the base requirements around Linux x86-64 whether it be for a Linux distribution or a particular software application where the developer/ISV may be wanting to compile with greater instruction set extensions enabled in catering to more recent Intel/AMD CPUs." https://www.phoronix.com/news/GCC-11-x86-64-Feature-Levels Here's gcc docs for it: https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html And here's the formal specification (click on the pdf link): https://gitlab.com/x86-psABIs/x86-64-ABI The actual tune file was created by copying corei7 tunes and doing search/replace on them. Qemu options were dropped as unnecessary. 32 bit tune was dropped as well, as there is no 32 bit only CPU that also supports these new instructions; all of the v3 capable chips are 64 bit. (From OE-Core rev: ac041f90e71dba83b7144c91f929de88aaeae519) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012/03/30 - Mark Hatle <mark.hatle@windriver.com>
- Initial Revision
Introduction
============
The individual CPU, and ABI tunings are contained in this directory. A
number of local and global variables are used to control the way the
tunings are setup and how they work together to specify an optimized
configuration.
The following is brief summary of the generic components that are used
in these tunings.
AVAILTUNES - This is a list of all of the tuning definitions currently
available in the system. Not all tunes in this list may be compatible
with the machine configuration, or each other in a multilib
configuration. Each tuning file can add to this list using "+=", but
should never replace the list using "=".
DEFAULTTUNE - This specifies the tune to use for a particular build.
Each tune should specify a reasonable default, which can be overriden by
a machine or multilib configuration. The specified tune must be listed
in the AVAILTUNES.
TUNEVALID[feature] - The <feature> is defined with a human readable
explanation for what it does. All architectural, cpu, abi, etc tuning
features must be defined using TUNEVALID.
TUNECONFLICTS[feature] - A list of features which conflict with <feature>.
New sanity checks will try to reject combinations in which a single
tuning ends up with features which conflict with each other.
TUNE_FEATURES - This is automatically defined as TUNE_FEATURES:tune-<tune>.
See TUNE_FEATURES:tune-<tune> for more information.
TUNE_FEATURES:tune-<tune> - Specify the features used to describe a
specific tune. This is a list of features that a tune support, each
feature must be in the TUNEVALID list. Note: the tune and a given
feature name may be the same, but they have different purposes. Only
features may be used to change behavior, while tunes are used to
describe an overall set of features.
ABIEXTENSION - An ABI extension may be specified by a specific feature
or other tuning setting, such as TARGET_FPU. Any ABI extensions either
need to be defined in the architectures base arch file, i.e.
ABIEXTENSION = "eabi" in the arm case, or appended to in specific tune
files with a ".=". Spaces are not allowed in this variable.
TUNE_CCARGS - Setup the cflags based on the TUNE_FEATURES settings.
These should be additive when defined using "+=". All items in this
list should be dynamic! i.e.
${@bb.utils.contains("TUNE_FEATURES", "feature", "cflag", "!cflag", d)}
TUNE_ARCH - The GNU canonical arch for a specific architecture. i.e.
arm, armeb, mips, mips64, etc. This value is used by bitbake to setup
configure. TUNE_ARCH definitions are specific to a given architecture.
They may be a single static definition, or may be dynamically adjusted.
See each architecture's README for details for that CPU family.
TUNE_PKGARCH - The package architecture used by the packaging systems to
define the architecture, abi and tuning of a particular package.
Similarly to TUNE_ARCH, the definition of TUNE_PKGARCH is specific to
each architecture. See each architectures README for details for that
CPU family.
PACKAGE_EXTRA_ARCHS - Lists all runtime compatible package
architectures. By default this is equal to
PACKAGE_EXTRA_ARCHS:tune-<tune>. If an architecture deviates from the
default it will be listed in the architecture README.
PACKAGE_EXTRA_ARCHS:tune-<tune> - List all of the package architectures
that are compatible with this specific tune. The package arch of this
tune must be in the list.
TARGET_FPU - The FPU setting for a given tune, hard (generate floating
point instructions), soft (generate internal gcc calls), "other"
architecture specific floating point. This is synchronized with the
compiler and other toolchain items. This should be dynamically
configured in the same way that TUNE_CCARGS is.
BASE_LIB:tune-<tune> - The "/lib" location for a specific ABI. This is
used in a multilib configuration to place the libraries in the correct,
non-conflicting locations.
Best Practice
=============
The tune infrastructure is designed to be hierarchical. When writing a
new tune file for a "fast-forward" CPU architecture (one that supports
everything from a previous generation), it is recommended to require the
previous generation tune file and specify PACKAGE_EXTRA_ARCHS using the
previous generation's override and appending the new tune. Note that
only one previous tune file should be included to avoid mutiple includes
of the base arch which could lead to a broken configuration due to
multiple prepend and append assignments.
For example, for x86, there is a common x86/arch-x86.inc which is
included in the base i586 tune file. The core2 tune builds
on that, and corei7 builds on core2.