Age | Commit message (Collapse) | Author | Files |
|
Signed-off-by: Matthew McClintock <msm@freescale.com>
|
|
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
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>
|
|
With this new emulation, existing qemuppc functionality is maintained
and other functionality such as framebuffer + sato and NFS boot are
added.
Signed-off-by: Liming Wang <liming.wang@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
There is no reason to continue to carry this feature
Signed-off-by: Steve Sakoman <steve@sakoman.com>
|
|
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>
|
|
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>
|
|
* 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>
|
|
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>
|
|
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>
|
|
This is the result of running the following over the metadata:
sed \
-e 's:bb.data.\(setVar([^,()]*,[^,()]*\), *\([^ )]*\) *):\2.\1):g' \
-e 's:bb.data.\(setVarFlag([^,()]*,[^,()]*,[^,()]*\), *\([^) ]*\) *):\2.\1):g' \
-e 's:bb.data.\(getVar([^,()]*\), *\([^(), ]*\) *,\([^)]*\)):\2.\1,\3):g' \
-e 's:bb.data.\(getVarFlag([^,()]*,[^,()]*\), *\([^(), ]*\) *,\([^)]*\)):\2.\1,\3):g' \
-e 's:bb.data.\(getVarFlag([^,()]*,[^,()]*\), *\([^() ]*\) *):\2.\1):g' \
-e 's:bb.data.\(getVar([^,()]*\), *\([^) ]*\) *):\2.\1):g' \
-i `grep -ril bb.data *`
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This ensures that on a multilib system the two executable formats
don't conflict.
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
|
|
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
* xserver-xorg is closer to upstream naming and
that's how it's named in OE-classic and meta-oe? It would make meta-oe
transition easier and better to do it now then convert meta-oe to
xserver-xf86 and then rename it back later.
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
|
|
Use TUNE_FEATURES to determine the setting to TUNE_PKGARCH, which fixes
the wrong setting of PACKAGE_ARCH in multilib case.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Henning Heinold <heinold@inf.fu-berlin.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This makes building for little-endian mips32 slightly more convenient.
Signed-off-by: Phil Blundell <philb@gnu.org>
|
|
Enable machines or distros to select the hard floating point abi for cortexa8
machines. I left out the arm7a thumb+neon combinations as they were not
present in the original non-hf set.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
CC: Jason Kridner <jkridner@beagleboard.org>
CC: Koen Kooi <koen@dominion.thruhere.net>
|
|
A closing quote was missing for an AVAILTUNES append operation, add it.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
CC: Jason Kridner <jkridner@beagleboard.org>
CC: Koen Kooi <koen@dominion.thruhere.net>
|
|
The explicit setting of version preference to 2.6.37 is
no longer required. All of the qemu targets have been built
and boot tested on 3.0.1 for core-image-minimal and core-image-sato
and are safe for wider build/boot testing.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
The PPC e5500 is a 64-bit core so we add both a 32 and 64-bit set of
tune files to allow for:
* pure 32-bit build
* pure 64-bit build
* 32-bit base, 64-bit multilib
* 64-bit base, 32-bit multilib
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
|
|
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.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
arch-ia32 version
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
|
|
The previous commit to this file meant thumb was always being turned on
even when TUNE_FEATURES did not contain "thumb". This is clearly wrong
and this patch corrects this so thumb options are no longer specified
in that case.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Added a DEFAULTTUNE setting and included arch-powerpc.inc. This way we
pick up the changes to TUNE_PKGARCH and things should be kept more in
sync going forward.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
|
|
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
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.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Without this 'armv7a' is used as TUNE_ARCH but does *not* end up in PACKAGE_EXTRA_ARCHS:
arch all 1
arch any 6
arch noarch 11
arch arm 16
arch armv4 21
arch armv4t 26
arch armv5 31
arch armv5t 36
arch armv5-vfp 41
arch armv5t-vfp 46
arch armv5e 51
arch armv5te 56
arch armv5e-vfp 61
arch armv5te-vfp 66
arch armv6-vfp 71
arch armv6t-vfp 76
arch armv7-vfp 81
arch armv7t2-vfp 86
arch armv7a-vfp 91
arch armv7at2-vfp 96
arch armv7a-vfp-neon 101
arch armv7at2-vfp-neon 106
arch beagleboard 111
Which leads to a failing do_rootfs
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Malcolm Crossley <malcolm.crossley@ge.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
|
|
All 64-bit PPC processors support hard-float so no need to support
soft-float.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
|
|
When figuring out how to set TUNE_CCARGS we should look for 'm64' not
'n64' in TUNE_FEATURES.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
|
|
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
|
|
Currently tune-xscale.inc has options wrt. setting of xscale/xscale-be tunes.
Fix that.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
|
|
PACKAGE_EXTRA_ARCHS_tune-armv5eb needs to be defined in terms of
the non-e with the same endianness, i.e. PACKAGE_EXTRA_ARCHS_tune-armv5b
not PACKAGE_EXTRA_ARCHS_tune-armv5, otherwise PACKAGE_EXTRA_ARCHS will
end up containing a semi-random mixture of endiannesses and disaster
will ensue. Likewise for the vfp and armv6 variants.
This is all a bit confusing because TUNE_FEATURES is done the opposite
way around, i.e. TUNE_FEATURES_tune-armv5eb is derived by taking the
armv5e version and adding bigendian. But fixing that is probably
a subject for a separate patch.
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
|
|
Otherwise the test in TUNE_CCARGS will never match.
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
|
|
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Acked-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The introduction of the linux-yocto-3.0 kernel is taking
precedence over the known working 2.6.37 version. Forcing
2.6.37 until 3.0 is validated on the qemu machines.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Using i686 doesn't work well with locale generation and doesn't gain anything
so revert to the i586 default.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The current approach causes duplicate values to appear in the TUNE_ARCH
field and this patch addresses that.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
There is this discrepency in spelling. Lets fix it in
core. There are lot of layers using SITEINFO_ENDIANNESS
This was shielded since meta-oe had its own copy of
siteinfo class. But that class has now been deleted in
favor of oe-core
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
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.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
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.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
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.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
|
|
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
|
|
This basic cleanup removes the _ext2/3 overrides from places they
no longer belong since they did not allow further overrides. In doing
this the core-image-minimal* recipes can now set a reasonably small
rootfs so that it's a realistic size for minimal.
The new default for minimal is 8M and will be adujsted upward by the
IMAGE_OVERHEAD_FACTOR (default of 1.3).
This also fixes the ROOTFS_SIZE usage in the IMAGE_CMD_<fstype> code
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|