diff options
Diffstat (limited to 'import-layers/yocto-poky/meta/conf/machine/include/README')
| -rw-r--r-- | import-layers/yocto-poky/meta/conf/machine/include/README | 100 |
1 files changed, 0 insertions, 100 deletions
diff --git a/import-layers/yocto-poky/meta/conf/machine/include/README b/import-layers/yocto-poky/meta/conf/machine/include/README deleted file mode 100644 index d66130acb..000000000 --- a/import-layers/yocto-poky/meta/conf/machine/include/README +++ /dev/null @@ -1,100 +0,0 @@ -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. |
