summaryrefslogtreecommitdiffstats
path: root/meta/conf/machine/include/tune-ppc603e.inc
Commit message (Collapse)AuthorAgeFilesLines
* meta/conf/machine: use ' inside quoted valuesMartin Jansa2015-12-011-2/+2
| | | | | | | | (From OE-Core rev: 924ccf202a6d89de32fc34a140bf9e35e8e43b4e) 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>
* conf/machine: use .= instead of += in TUNE_CCARGSMartin Jansa2013-04-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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>
* conf/machine/include: Cleanup PowerPC tunings to match READMEMark Hatle2012-04-041-2/+2
| | | | | | | | | | | | | | | 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>
* tune-ppc*.inc: update to use new default value for TUNE_PKGARCHMatthew McClintock2012-02-281-1/+1
| | | | | | | (From OE-Core rev: 12f0a0d3e1afe90633c8b95d36670ab0f156e912) Signed-off-by: Matthew McClintock <msm@freescale.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* arch-powerpc: set PACKAGE_EXTRA_ARCHSIlya Yanok2011-12-221-1/+1
| | | | | | | | | | | 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>
* tune-ppc: Update to pass glibc configure option to get cpu specific supportKumar Gala2011-08-121-1/+4
| | | | | | | | | | | | | | | We need --with-cpu based to glibc to get proper support on 603e & e500mc to pickup proper math libs to deal with sqrt. These core do not implement the fsqrt[s] instructions that the normal PPC math libs utilize. This causes use to not set AVAILTUNES specifically to the sub-arch only as we arent generically compatiable. (From OE-Core rev: 078699cb8c707830c86b55787fd535d87171388e) Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* tune/ppc: Fix various TUNE_PKGARCH issuesRichard Purdie2011-08-021-1/+1
| | | | | | | | | | 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>
* Add basic PowerPC core tune configRichard Purdie2011-07-271-3/+9
| | | | | | (From OE-Core rev: 3212029f0967dd353fec8cc147d2b95031d1018a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* conf/machine/include: Start to fill out architecture specific tune include ↵Richard Purdie2011-07-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | files and tune features 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>
* conf/machine/include: Set TUNE_CCARGS instead of TARGET_CC_ARCHRichard Purdie2011-07-251-1/+1
| | | | | | | | | | | | | | Since we're updating the tune file format, it makes sense to abstract the compiler tune arguments at this point too. This means that should these need to be overridden at any point, the original values can still be obtained in a similar manner to the other TUNE* variables. Whilst this isn't strictly necessary for any current need, its likely good practise to standardise this behaviour. (From OE-Core rev: 3a3c69a1bc3cf0b6f6a3b13d86c12ed21798d48e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* conf/machine/tune: Overhaul tune include file variablesRichard Purdie2011-07-251-2/+3
| | | | | | | | | | | | | | | | | | | | | | There is currently consideradble confusion over how the tune files operate and how these interact with the rest of the build system. This update/overhaul changes things so the tune files are primarily resonsible for setting: TUNE_ARCH - What was formerly set as TARGET_ARCH and is the value that represents the architecture we're targetting. TUNE_PKGARCH - The value that represents the tune confuration that this set of tune parameters results in. This allows the significant improvement that the core can now always determine the target architecture value, even when TARGET_ARCH needs to be reset to something different and likewise, there is one package architecture variable the core can reference allowing simplification of the BASE_PACKAGE_ARCH, PACKAGE_ARCH and FEED_ARCH variables. (From OE-Core rev: a10de4cf8b424ee95c8e283e75d486be5b3b8eac) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf/tune files: Adjust PACKAGE_EXTEA_ARCHSRichard Purdie2011-03-231-1/+1
| | | | | | | | | | | | | | | | | | | | | There is a problem with the current PACKAGE_EXTRA_ARCHS implementation since its impossible to control which extra architectures sort higher than TARGET_ARCH and which sort lower. In the x86 case for example, TARGET_ARCH might be "i586", i486 should be lower than this and i686 should be higher. There are also complications where its easy to inject duplicate entries into the variable. I tried various versions of this patch and concluded that it was simplest just to force the tune files to include TARGET_ARCH in the list in the right place if they're planning to customise it themselves. Other approaches with appends and prepends just complicated the code for no good reason. The TARGET_ARCH definitions should also move to the tune files but I'll leave this for a separate patch. (From OE-Core rev: d492ebf8b1801da99c679f465be98ce54fd3061a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* machines: move PACKAGE_EXTRA_ARCHS to tune filesKoen Kooi2011-01-101-1/+3
| | | | | | | | This gets us closer to making including tune-<arch>.inc "just work". Moving the TARGET_ARCH definitions is something for a follup patch. Signed-off-by: Koen Kooi <koen@dominion.thruhere.net> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf/tune.conf: Set BASE_PACKAGE_ARCH and build PACKAGE_ARCH from thisRichard Purdie2008-07-171-1/+1
| | | | git-svn-id: https://svn.o-hand.com/repos/poky/trunk@4857 311d38ba-8fff-0310-9ca6-ca027cbcb966
* conf/machine: Sync various changes with OERichard Purdie2007-09-021-1/+1
| | | | git-svn-id: https://svn.o-hand.com/repos/poky/trunk@2656 311d38ba-8fff-0310-9ca6-ca027cbcb966
* conf/machine/include: Rename to .conf to .inc filesRichard Purdie2007-08-081-0/+2
git-svn-id: https://svn.o-hand.com/repos/poky/trunk@2388 311d38ba-8fff-0310-9ca6-ca027cbcb966