902564c044
* 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 master rev: b7430ff83760ac29079d20dc7c62f498a0a9d55d) (From OE-Core rev: 6a9873477faea55a8e8d59a431b8f3c928a2c871) 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>
2012/03/30 - Mark Hatle mark.hatle@windriver.com
- Initial Revision
The ARM architecture definitions are split among a number of files. The primary definitions for the variables are handled by the core arch-arm.inc file.
TUNE_ARCH is set to either "arm" or "armeb" depending on the value of the existence of the "bigendian" feature in a given tune.
A small set of ARM specific variables have been defined to allow TUNE_PKGARCH to be automatically defined. Optimized tunings must NOT change the definiton of TUNE_PKGARCH. TUNE_PKGACH_tune- will be ignored. The format of the package arch is enforced by the TUNE_PKGARCH default. The format must be of the form: [t][e][hf][b][-vfp][-neon]
TUNE_PKGARCH is defined as: ${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}
ARMPKGARCH - This is the core package arch component specified by each tuning. This is the primary identifier of a tuning. Usual values are: arm, armv4, armv5, armv6, armv7a, etc.
ARMPKGSFX_THUMB - This is the thumb specific suffix. Curently it is defined in feature-arm-thumb.inc.
ARMPKGSFX_DSP - This is the DSP specific suffix. Currently this is set to 'e' when on armv5 and the dsp feature is enabled.
ARMPKGSFX_EABI - This is the eabi specific suffix. There are currently
two defined ABIs specificed, standard EABI and Hard Float (VFP) EABI.
When the callconvention-hard is enabled, "hf" is specified, otherwise it
is blank.
ARMPKGSFX_ENDIAN - This is the endian specific suffix. It is defined in the core arch-arm.inc file.
ARMPKGSFX_FPU - This is the FPU specific suffix. The suffix indicates specific FPU optimizations. 'vfp' and 'neon' are both defined.