summaryrefslogtreecommitdiff
path: root/meta/conf/machine/include
AgeCommit message (Collapse)AuthorFiles
2012-12-03tune-cortexa*, tune-xscale: fix ARMPKGARCHMartin Jansa3
* hf/t/neon/b suffix is added by other ARMPKGSFX* variables, should not be part of ARMPKGARCH, otherwise resulting TUNE_PKGARCH have that suffix twice, e.g. cortexa8hf-neonhf-neon 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-11-26tune-*: define more generic DEFAULTTUNE to share feed between machinesMartin Jansa9
* this is mostly for backwards compatibility and to share binary feed like it was before, but now without missing different -mtune in it * if you want to build some package with -mtune add something like this to your distro config DEFAULTTUNE_qemuarm_pn-openssl = "arm926ejs" DEFAULTTUNE_qemuarmx_pn-openssl = "xscale" be aware that if you do this you should do it also for all packages which depends on openssl because if you dont and you build e.g. dhcp, then dhcp build for arm926ejs (even with DEFAULTTUNE armv5te) will depend on openssl with arm926ejs, so dhcp in armv5te feed will be rebuild after each MACHINE switch. * cortexm3, cortexr4, iwmmx and ep9312 are using own DEFAULTTUNE because they define also different -march * shared feeds are armv4t: arm920t, arm9tdmi armv5te: arm926ejs, xscale armv7a-neon: cortexa8, cortexa9 Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-11-26arch-arm: define different ARMPKGARCH when different CCARGS are usedMartin Jansa13
* without this tune-xscale and tune-arm926ejs were both creating packages in armv5te feed, but each with different -mtune, with OEBasicHash enabled it was causing each package to rebuild with new -mtune after MACHINE switch, but that doesn't make sense with output stored in the same armv5te feed * this makes different feed for each -mtune, but more generic one to be selected with DEFAULTTUNE * tune-iwmmxt and tune-ep9312 were already using this, just move it bellow AVAILTUNES and use ARMPKGARCH_tune-foo syntax * tune-cortexr4 and tune-cortexm3 are using armv7r/armv7m as ARMPKGARCH because there isn't another tune to use the same -march Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-11-26arm/arch-arm*: define ARMPKGARCH_tune-* for default tunesMartin Jansa6
* tune-foo is not valid override, for it to work I had to add ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}" but that doesn't work without value defined for every supported DEFAULTTUNE value, otherwise it's expanded like this TUNE_PKGARCH (${ARMPKGARCH_tune-armv5te}te). Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-11-25tune-cortexr4: fix march valueMartin Jansa1
* probably copy&paste error from tune-cortexm3.conf commit 789dcb8e68a2ab9784ac10ab36815010c61af2fc Author: Richard Purdie <richard.purdie@linuxfoundation.org> Date: Mon Jul 25 19:03:24 2011 +0100 Add ARM tune file overhaul based largely on work from Mark Hatle Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-11-25tune-xscale: replace TUNE_CCARGS for webkit-gtk and cairo only with xscale ↵Martin Jansa1
in TUNE_FEATURES * without this you'll get different sstate checksum for webkit-gtk and cairo even when you build them with DEFAULTTUNE == armv5te * maybe this isn't needed at all anymore or if it is then it should be applied in arm-armv5.inc for all armv5te devices, not only xscale? Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-11-20ia32-base: fix typo in XSERVER_IA32_EXT definitionRoss Burton1
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-11-19xserver-xorg: upgrade to 1.13.0Laurentiu Palcu1
The patch contains several aditional changes: * removed one backported patch (included in the new release); * changed mips64-compiler.patch to apply properly; * licence checksum for COPYING file changed: some copyright years have been changed; * bump PR in xorg-driver-common.inc so that all input/video drivers get rebuilt. That's becaue the ABI changed; The following external modules are now built-in: * DBE * DRI2 * DRI * RECORD The extmod module was completely removed. Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-10-27insane.bbclass and friends: Fix sanity checks and multlib headers for n32Peter Seebach1
The n32 architecture is odd, in that it's a mips64 ABI which happens to be 32-bit. To handle this, we need something in the environment which can be used to distinguish it. The obvious place to stash this is the ABI suffix, so we use "n32" as an ABI suffix. This allows a couple of improved checks: 1. In insane.bbclass, we can use "linux-gnun32" to discern that it's okay for a mips64 binary to be a 32-bit binary in some cases. 2. In multilib_header, we can check for the n32 ABI, and use a distinct value. 3. In siteinfo, add linux-gnun32 as a synonym for linux, similar to what's done for linux-gnux32, and tell the mips*-linux-gnun32 variants to pick up the corresponding mips-linux site configs. Note that the multilib header wrapper already has n32 hooks in it, there was just nothing creating -n32 header variants. Signed-off-by: Peter Seebach <peter.seebach@windriver.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
2012-10-18ia32-base.inc: don't depend on mesa-driRoss Burton1
mesa-dri is an empty package, so depending on it doesn't achieve anything. Signed-off-by: Ross Burton <ross.burton@intel.com>
2012-09-28tune-ppce6500.inc: add e6500 tune filesMatthew McClintock1
Also supports a new altivec TUNE_FEATURE Signed-off-by: Matthew McClintock <msm@freescale.com>
2012-09-28arch-powerpc.inc: add altivec as a valid tune featureMatthew McClintock1
Signed-off-by: Matthew McClintock <msm@freescale.com>
2012-09-24arch-armv7a.inc: Don't disable vectorizationKhem Raj1
We have been adding this option to paper over a bug in old toolchain http://hardwarebug.org/2008/11/28/codesourcery-fails-again/ e.g. is one but these have been weeded out. Therefore let gcc take the default vectorization optimizations Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-09-10machines/x86: Drop redundant glibc configure knobsKhem Raj1
nptl and thereby tls are not optional anymore Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
2012-09-10arch-armv4.inc: On armv4 add --fix-v4bx to linker flags for kernelKhem Raj1
Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
2012-09-07conf/tune: add tune-ppce300c3Bruce Ashfield1
It has been pointed out several times that the yocto mpc8315e-rdb reference was using the wrong tuning (603e), since it is actually a e300c3 board. This commit creates a e300c3 tune file based on the e300c2 variant already in oe-core. This commit also inhibits altivec in flac when this new tuning is enabled and used by the mpc8315e-rdb [YOCTO #1192] Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-08-28ia32-base.inc: new include fileTom Zanussi1
This is the ia32-base.inc moved over from meta-intel. See meta-intel for the complete history of contributions to this file. Here's the initial commit text that explains the purpose of this file: The meta-intel BSPs currently have a number of machine settings common to all - factor these out into a common include file. Also add several new intel-specific XSERVER variables for building XSERVER variables in BSPs. Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
2012-07-18tune-ppc476.inc: Support ppc476Peter Seebach1
A couple of boards use chips which perform noticably better when optimized for the 476. Add a trivial tune file to let them run better. Signed-off-by: Peter Seebach <peter.seebach@windriver.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
2012-07-16conf/machine: replace TUNE_CONFLICTS with TUNECONFLICTSMartin Jansa5
* it wasn't consistent with other machine configs * reported 2 months ago.. http://lists.linuxtogo.org/pipermail/openembedded-core/2012-May/022154.html Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
2012-05-24qemu.inc: Remove mesa-xlib as PREFERRED_PROVIDERSaul Wold1
The xserver-xorg uses and depends on mesa-dri, so we should use the default PREFERRED_PROVIDER of libgl as mesa-dri. This resolves the following: ERROR: Multiple .bb files are due to be built which each provide virtual/libgl (/intel/poky/distro/meta/recipes-graphics/mesa/mesa-dri_7.11.bb /intel/poky/distro/meta/recipes-graphics/mesa/mesa-xlib_7.11.bb). This usually means one provides something the other doesn't and should. Signed-off-by: Saul Wold <sgw@linux.intel.com>
2012-05-24qemumachines: Enable xserver-xorg as default xserverKhem Raj1
For qemux86 and qemux86-64 include qemu.inc after defining XSERVER XSERVER variable is also weakly defined in task-core-x11.bb which means we can not use ??= otherwise when building any qemu image that uses task-core-x11.bb will get the wrong definition So we define the XSERVER common set for qemu in qemu.inc and as we know x86 and x86-64 qemu overrides the default we include qemu.inc after that definition which means that qemux86 and qemux86-64 get their own definitions and other qemus get the definitions from qemu.inc. other non-qemu machine will get their defintion from task which points to kdrive as of now. Signed-off-by: Khem Raj <raj.khem@gmail.com>
2012-05-20tune-mips64.inc: Add new tune file for mips64 big-endianKhem Raj1
Signed-off-by: Khem Raj <raj.khem@gmail.com>
2012-05-06conf/machine: Clean up configuration values.Peter Seebach6
This cleans up and/or corrects a few values from machine includes for consistency with future toolchain sanity checks, and also adds the TUNEVALID and TUNECONFLICTS to documentation.conf. Signed-off-by: Peter Seebach <peter.seebach@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-05-01tune-sh4.inc: Fix spelling of big-endian feature setPeter Seebach3
In tune-sh3, tune-xscale, and tune-sh4, several FEATURES lines referred to nonexistent features like "sh3eb" when they should have referred to "sh3 bigendian" or the like. Caught by the TUNEVALID sanity check. Signed-off-by: Peter Seebach <peter.seebach@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-04-04conf/machine/include: Update SH tunings to match READMEMark Hatle4
Update the experimental SH tunings to match the tunings README. These tunings have not been tested, and are experimental! Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
2012-04-04conf/machine/include: Cleanup ARM tunings to match READMEMark Hatle6
Cleanup the ARM tunings to match the new tunings README file. The ARM tunings define TUNE_PKGARCH in a way that only one main arm architecture, i.e. armv6, may be defined at the same time. We may have to revise these settings in the future, as well as figure out a way to better differentiate various optimize tunings in the package arch. (This was not done, to preserve existing behavior!) Fix a number of minor issues w/ the armv5 tunings where DSP variants were referenced but not defined. Fix incorrect armv7 entries in armv7a. Fix PACKAGE_EXTRA_ARCHS definitions inside of tune-cortexm3 and tune-cortexr4. Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
2012-04-04conf/machine/include: Cleanup PowerPC tunings to match READMEMark Hatle9
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. Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
2012-04-04conf/machine/include: Cleanup MIPS tunings to match READMEMark Hatle3
Cleanup the MIPS tunings to match the new tuning README file. Also add a MIPS specific README file to explain the MIPS specifical architectural issues. Finally correct the variant configurations within the tune-mips32.inc. Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
2012-04-04conf/machine/include: Cleanup IA tunings to match READMEMark Hatle5
We perform a basic cleanup of the IA32 architecture and related tunings in order to match the rules and descriptions within the new tuning README file. A number of small issues were corrected in the "c3" tuning to bring it inline with the README. Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
2012-04-04conf/machine/include/README: Add readme to explain cpu tuningsMark Hatle1
Add a new README that covers the basic items used with various cpu tunings. The goal is to better help people understand the various settings and where things should or should not be defined. Corresponding architecture README files will also be generated to explain the particulars of architectural tunings. Also remove the default TUNE_PKGARCH setting in bitbake.conf. This was done to ensure an error occurs if an invalid tuning is defined. Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
2012-03-31tune-cortexa8/9: fix PACKAGE tunes being all armv7at even for non-Thumb onesDenys Dmytriyenko2
All PACKAGE_EXTRA_ARCHS for cortexa8, cortexa8t and cortexa8-neon have typo in referencing tune-armv7at even for non-Thumb modes. Probably a copy/paste error. That's not the case for recently-added hard-fp tunes. Same for cortexa9. Signed-off-by: Denys Dmytriyenko <denys@ti.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-03-30virtual/libgl: use mesa-xlib for qemuarm/qemumips/qemuppcZhai Edwin1
Still need mesa-xlib for emulation of GLX interface on qemuarm/mips/ppc, where mesa-dri doesn't work for pure qemu emulator. [YOCTO #2066] fixed. Signed-off-by: Zhai Edwin <edwin.zhai@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-03-30arch-armv7a.inc: fix PACKAGE_EXTRA_ARCHS after armv7.inc was removedMartin Jansa1
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-03-29qemu.inc: Use '+=' for IMAGE_FSTYPESTom Rini1
As per http://lists.linuxtogo.org/pipermail/openembedded-core/2012-March/020053.html a machine conf file should use '+=' to set IMAGE_FSTYPES. Signed-off-by: Tom Rini <trini@ti.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-03-28powerpc e500: set -mfloat-gprs=doubleChristopher Larson2
Use of FPRs instead of GPRs is incompatible with e500/SPE, so let's be explicit about the use of GPRs to avoid potential errors. For example, with the Sourcery G++ toolchain, one can hit: conftest.c:1:0: error: E500 and FPRs not supported. Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-03-28tune/armv7: DeleteKhem Raj3
armv7 is least common denominator of armv7-a armv7-m and armv7-r and armv7-m does not support ARM instructions but only thumb2 instruction set which means armv7 when chosen will complain if code is compiled in arm mode which is default in OE if not specified other wise if we chose this tuning errors like below pop up error: target CPU does not support ARM mode This tuning seems theoretical and base tune for armv7 would be one of armv7-a, armv7-m or armv7-r Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-03-22arch-powerpc.inc: use default value of TUNE_PKGARCHMatthew McClintock1
We can use the default value for TUNE_PKGARCH, and now we just append "-nf" if TARGET_FPU is fpu-soft Signed-off-by: Matthew McClintock <msm@freescale.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-03-05meta: Convert getVar/getVarFlag(xxx, 1) -> (xxx, True)Richard Purdie2
Using "1" with getVar is bad coding style and "True" is preferred. This patch is a sed over the meta directory of the form: sed \ -e 's:\(\.getVar([^,()]*, \)1 *):\1True):g' \ -e 's:\(\.getVarFlag([^,()]*, [^,()]*, \)1 *):\1True):g' \ -i `grep -ril getVar *` Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-03-04soc-family.inc: to be included in machine.conf to add SOC_FAMILY to ↵Denys Dmytriyenko1
MACHINEOVERRIDE Add a soc-family.inc file that can be included in a machine.conf to enable the use of SOC_FAMILY in MACHINEOVERRIDE, which could be useful to group multiple machines with the same common base. Some examples can be seen in meta-ti BSP layer. Signed-off-by: Denys Dmytriyenko <denys@ti.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-02-28tune-ppc*.inc: update to use new default value for TUNE_PKGARCHMatthew McClintock5
Signed-off-by: Matthew McClintock <msm@freescale.com>
2012-02-28tune-ppce5500: consolidate ppce5500 and ppc64e5500 into one tune fileMatthew McClintock3
We don't need two files for this. Also this fixes some mutlilib build issues where we were not able to select the multilib arch to be ppce5500 or ppc64e5500. Changes recently made to meta-fsl-ppc layer depend on this change as well Signed-off-by: Matthew McClintock <msm@freescale.com>
2012-02-28arch-powerpc{, 64}.inc: update/add PACKAGE_EXTRA_ARCHS for powerpc/powerpc64Matthew McClintock2
Signed-off-by: Matthew McClintock <msm@freescale.com>
2012-02-26arch-armv7.inc: fix quotingMartin Jansa1
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-02-07tune-mips32.inc: Add mips32-nf and mips32el-nfAndreas Oberritter1
tune-mips32.inc only lists mips32 CPUs with hardware FPU. Extend it to list CPUs without hardware FPU, too. Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
2012-01-09Remove last remnants of kernel26 MACHINE_FEATURESSteve Sakoman1
There is no reason to continue to carry this feature Signed-off-by: Steve Sakoman <steve@sakoman.com>
2011-12-23Change -mno-thumb to -marmKen Werner2
Recent versions of the GCC reject the -mno-thumb option. In order to prevent the compiler from generating code for the Thumb instruction set the -marm switch should be used instead. For details see GNU bug #47930. Signed-off-by: Ken Werner <ken.werner@linaro.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-12-22arch-powerpc: set PACKAGE_EXTRA_ARCHSIlya Yanok4
Set PACKAGE_EXTRA_ARCHS for the generic tunes ("powerpc" and "powerpc-nf") thus allowing to use them instead of tuning to the specific CPU. Signed-off-by: Ilya Yanok <yanok@emcraft.com>
2011-12-13conf/machine/include/arm add extra MACHINEOVERRIDES like x86 doesMartin Jansa5
* motivated by this NAK http://patchwork.openembedded.org/patch/15777/ and today's discussion on #yocto I hope it's worth it to send this RFC Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-12-12x86 tune: fix TUNE_PKGARCH definition for proper PACKAGE_ARCHNitin A Kamble2
rpmbuild can not handle the PACKAGE_ARCH of these kinds: x86_64-x32, core2-64, core2-64-x32 With these kinds of PACKAGE_ARCH the --target parameter of rpmbuild becomes like: core2-64-x32-poky-linux-gnux32 ; And rpmbuild extracts %_target (arch) wrongly as core2 generating these kinds of rpms with incorrect filenames: zip-3.0-r0.core2.rpm So this commit fixes the issue by making PACKAGE_ARCH like this: x86_64_x32, core2_64, core2_64_x32 Now --target parameter of rpmbuild becomes like: core2_64_x32-poky-linux-gnux32 ; And rpmbuild extracts %_target (arch) correctly as core2_64_x32 generating these kinds of rpms with correct filenames: zip-3.0-r0.core2_64_x32.rpm Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
2011-12-06conf/machine: Don't poke around providers which aren't machine specific/safeRichard Purdie1
Machines shouldn't be poking around PREFERRED_PROVIDERS which aren't machine specific or at least machine safe. Kernels are machine specific and the xserver is selectable. libx11 and mesa are now really a distro choice and machine configurations shouldn't be poking around them as it just leads to corruption, conflicts and confusion. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-16 21:42:11 +0000