This makes building for little-endian mips32 slightly more convenient.
(From OE-Core rev: cd5b601bb2149cbc866dc32b46f4058d3284fb00)
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.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.
(From OE-Core rev: c70ebd6f8ff34071febeb132c8bc4df220e328da)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
CC: Jason Kridner <jkridner@beagleboard.org>
CC: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A closing quote was missing for an AVAILTUNES append operation, add it.
(From OE-Core rev: 7d46901840795638ff184a43e65299446fbd0b4e)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
CC: Jason Kridner <jkridner@beagleboard.org>
CC: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 14831b6ba26a6e43a1771a8516d0af145006c504)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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
(From OE-Core rev: 60286934715c5f7f27d539f4a43a7226488ef963)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.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.
(From OE-Core rev: 078699cb8c707830c86b55787fd535d87171388e)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 4b5e8074f8aca59b09421db464ce652e84f898f2)
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.
(From OE-Core rev: 2c9bd779b008be266072f3c6d79430f63ec02241)
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.
(From OE-Core rev: f9a8b719dd3fc7593a509c8f288caf1486add2f8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
All 64-bit PPC processors support hard-float so no need to support
soft-float.
(From OE-Core rev: 54c7d1faf5376c8fb9b19f4e192ce959c8442782)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When figuring out how to set TUNE_CCARGS we should look for 'm64' not
'n64' in TUNE_FEATURES.
(From OE-Core rev: 7a9ea28e69e8121a559f610dd2330edd33f0a907)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 391c0102a81455c76244d13b6878e3a76cca65dc)
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>
Otherwise the test in TUNE_CCARGS will never match.
(From OE-Core rev: 3b7784021259ac745c80043bec16189fa8f4e45e)
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>
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.
(From OE-Core rev: 77a41ab5ca92606ee08f002a8dfc631f642a3179)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using i686 doesn't work well with locale generation and doesn't gain anything
so revert to the i586 default.
(From OE-Core rev: 79b7b1aab5d3d002bfa7a49887d5d834c29eae45)
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.
(From OE-Core rev: 02031d766f983cd7e01e468cb2c926604313cd2a)
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
(From OE-Core rev: 54a54778fad39931ac7d43daaf37ce7c1946a29b)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
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>
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>
The ext3 format is pretty much mandatory for qemu usage, so always create it.
(From OE-Core rev: 94da548810eece652bd32fb68a36f978b7d7cf2a)
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.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
(From OE-Core rev: d3f6e1e6106ab539e73c19037915b2e4a5f2efa9)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Things like 'distcc' and 'bash' are not essential to booting a qemu machine.
(From OE-Core rev: 65f1109faf9548c5d083089561d5b9d99dbacc83)
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Modify some configs for ppc to enable the libqtopengl4 support.
This fixes [YOCTO #848]
(From OE-Core rev: cc6763b81fafddcb112a6126373c594e3ec4b140)
Signed-off-by: Mei Lei <lei.mei@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Since bitbake.conf has got rid of -fomit-frame-pointer this
is no longer required
(From OE-Core rev: ba89ba8e02185c7adb92240f119a57e7b21adfa7)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
Fixes [YOCTO #853]
Without these added optimization flags, the matchbox-panel (and possibly other)
applications would segfault. This patch applies the changes to all machines
derived from atom-pc.conf.
[Tweaked by RP to apply to gtk+ only]
(From OE-Core rev: 5eb24b1cb57d1e0b43dfc993a635cd2b58d58fcf)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- add global config option ROOTLESS_X to control if enable
rootless X for the machine. ROOTLESS_X requires graphics
driver supporting KMS (kernel mode setting), so far, only
atom_pc support this. so enable ROOTLESS_X for atom_pc machine
- add config options for xf86-video-intel to support rootless X
Signed-off-by: Yu Ke <ke.yu@intel.com>
Zaurus support was removed with:
673abd92f9
conf/machine: Drop older machines with no recent updates
which removed both the linux-rp and sharp-flash-header recipes required by the
zaurus includes removed by this patch.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
These are all moving to meta-extras. Ideally in the future machines
such as these will be maintained to topic specific layers as we move
to a more layer oriented model. If this causes a problem for anyone
please discuss it on the mailing list.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [BUGID #610]
dtb files were not being built for the mpc8315e-rdb, since they
weren't being configured into the machine. With this and the
related dtc fixes, we now get a dtb in the deployment directories.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Support has been added for basic Beagleboard xM functionality,
including networking, to the linux-yocto kernel repository.
Tested on the Beagleboard xM.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
CC: Bruce Ashfield <bruce.ashfield@windriver.com>
Fixes [BUGID #685]
Although not used if the in kernel uImage is booted, it is
a good idea to set the UBOOT_ENTRYPOINT just as the other
uImage based boards do.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
In preparation to remove the u-boot-omap3 recipe, update the overo
machine to use the new upstream u-boot recipe.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
CC: Tom Zanussi <tom.zanussi@intel.com>
CC: Bruce Ashfield <bruce.ashfield@windriver.com>
The Beagleboard xM requires x-load and u-boot to be installed
on the MMC as it has no NAND (as of rev B and onward).
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
CC: Tom Zanussi <tom.zanussi@intel.com>
CC: Bruce Ashfield <bruce.ashfield@windriver.com>
The linux-yocto-rt kernel has been boot tested on qemux86-64. Unlock
the preferred provider for virtual/kernel so it can be selected and
used.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Enable beagleboard support for 2.6.37. The only non-kernel related
change for the board is to update the serial console designation.
The Beagleboard use omap serial driver, so we replace ttyS2 with ttyO2.
This is described in following link:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg40838.html
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Liming Wang <liming.wang@windriver.com>
The routerstation pro and mpc8315e-rdb have been validated
on 2.6.37 so we can switch their preference to linux-yocto
and update the machine compatibility to add them to the support
list.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
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>
As the yocto-kernel advances, the libc headers must also
advance. This commit fixes the SRC_URI and SRCPV to work
properly with the latest linux-yocto kernel. It also switches
the qemu* targets to prefer this libc recipe.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
In order to extend and create more kernel recipes based on the
supported yocto kernel common routines need to be placed in
re-usable blocks.
To accomplish this meta/recipes-kernel/linux/linux-yocto_git.bb
is broken into three parts:
- meta/classes/kernel-yocto.bbclass: contains common routines
for checking out and configuring a yocto kernel git repository.
This should be inherited by recipes that need this functionality.
- meta/recipes-kernel/linux/linux-yocto.inc: Contains the machine
mappings, compatibility, build directives and common task
definitions for a yocto kernel based recipe. This inherits
kernel-yocto, and is the typical point of entry for other recipes.
- meta/recipes-kernel/linux/linuux-tools.inc: tasks and function definitions
for kernel recipes that want to build/export perf
It also updates the linux-yocto recipe to default to 2.6.37.
As part of the update to 2.6.37 the branch naming and conventions
have been modified to show inheritance, and be more generic.
For example:
master
meta
yocto/base
yocto/standard/arm_versatile_926ejs
yocto/standard/base
yocto/standard/beagleboard
yocto/standard/common_pc/atom-pc
yocto/standard/common_pc/base
yocto/standard/common_pc_64
yocto/standard/fsl-mpc8315e-rdb
yocto/standard/intel_atom_z530
yocto/standard/intel_core_qm57_pch
yocto/standard/mti_malta32_be
yocto/standard/preempt_rt/base
yocto/standard/preempt_rt/common_pc
yocto/standard/preempt_rt/common_pc_64
yocto/standard/preempt_rt/intel_atom_z530
yocto/standard/preempt_rt/intel_core_qm57_pch
yocto/standard/qemu_ppc32
yocto/standard/routerstationpro
In this structure:
master: tracks the mainline kernel
meta: meta information for the BSPs and kernel features
yocto/base: baseline kernel branch
yocto/standard/base: 'standard' kernel, contains features
and configs for all BSPs
yocto/standard/<machine>: represents a BSP with specific
features or configurations
The tools, tree and libc-headers have all been updated to
deal with this new structure. Also in addition to dealing with
the new structure, they continue to work with the existing
tree and will adapt at runtime to the differences.
The linux-yocto-stable_git.bb recipe continues to build the
2.6.34 based tree,and linux-yocto_git.bb builds 2.6.37. As
boards are enabled for the new kernel they will move from
-stable to the development kernel. As of now, only the
emulated targets have moved to 2.6.37-rcX
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Using TRANSLATED_TARGET_ARCH instead of TARGET_ARCH for
cross-canadian packages. This is due to the TARGET_ARCH of x86_64
would results incorrect packaging in cross-canadian packages.
The pacakge name appendix of x86_64 target in cross-canadian
packages is x86-64.
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
The existing preferred yocto kernel wasn't named appropriately
and needs to be updated.
In keeping the changes small and isolated, this commit simply
renames the recipe and some internal variables. Future commits
will refactor the code into more usable blocks.
Now that linuy-wrs has been renamed linux-yocto, we need
to rename and update an board configurations and append
files.
Now that linux-wrs has been renamed linux-yocto, we need to
update the SRCREVs to have the new name.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Fixes [BUGID #500]
While the tuning for the mpc8315e is 603e, the PACKAGE_EXTRA_ARCHES
was ppce300. This created a mismatch and resulted in rootfs assembly
issues due to missing locales.
We align both at 603 and can revist a better tuning in the future.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
The kernel video mode parameters are not needed with the atom-pc linux-wrs
configuration. Without them, we boot up with a standard 80x25 text display
until the Intel i915 driver is initialized, at which point we switch to a
higher resolution text mode. Afterwards, a sato image will start the splash
screen and successfully boot to X.
Tested on the Toshiba NB305 netbook and the Black Sand development board.
[BUGID #450]
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
CC: Tom Zanussi <tom.zanussi@intel.com>
CC: Bruce Ashfield <bruce.ashfield@windriver.com>
CC: Richard Purdie <rpurdie@linux.intel.com>
Temporary fix for [BUGID #450]
This fixes the video mode number to the expected value for this video
setting, but the setting itself needs to be fixed along with matching
config options - this patch is just a temporary fix for RC2.
Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
BUGID: 421
Create the infrastructure to build the beagleboard against the
linux-wrs kernel.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
BUGID: 423
Introduce the basic mpc8315e BSP. By default this BSP uses
the basic 603 tuning and soft-float. There are issues with
the e300 tuning and eglibc, and the compiler. Subsequent
commits will further tune this BSP.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
BUGID: 422
Add the machine configuration and kernel infrastructure for building
the routerstation pro BSP.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
In preparation for the more generic atom-pc, rename the netbook machine and all
the relevant overrides. Leave the linux-netbook kernel recipe intact and as the
default kernel for the atom-pc machine. A future patch will convert this over
to linux-wrs and likely remove the linux-netbook kernel recipe.
Cc: Tom Zanussi <tom.zanussi@intel.com>
Cc: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
The IGEP module is a low-power, high performance production-ready
system-on-module (SOM) based on TI's OMAP3 family.
The IGEP module solution based upon TI OMAP3 provides a low-power/low-cost
platform for a variety of consumer/industrial/medical devices.
Signed-off-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>
om-gta01, om-gta02, nokia700, nokia800 and mx31litekit no longer build and we
don't have a maintainer for them so move them to meta-extras
Signed-off-by: Joshua Lock <josh@linux.intel.com>
The different kernel recipes encapsulate functionality groups for machines,
therefore it makes sense to have all the QEMU machines using the same kernel
recipe.
Switch the QEMU machines to default to the "linux" recipes for their kernel
and bump the latest recipe from linux-2.6.32 to 2.6.33.
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Change the virtual/xserver preferred provider in qemu.inc to a soft assign and
set preferred provider in qemux86 before the require so that the value is retained.
Signed-off-by: Joshua Lock <josh@linux.intel.com>
The IGEP v2 board is a low-cost, fan-less single board computer that
unleashes laptop-like performance and expandability without the bulk,
expense, or noise of typical desktop machines. Its architecture shares
much in common with other OMAP3 boards.
Signed-off-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
The Zoom2 is an OMAP3-based development platform. Its architecture shares much in common with other OMAP3 boards such as Beagle, Overo, and RX51.
Signed-off-by: Mike Turquette <mturquette@ti.com>
Phil Blundell
Darren Hart
Bruce Ashfield
Kumar Gala
Richard Purdie
Nitin A Kamble
Koen Kooi
Malcolm Crossley
Martin Jansa
Dmitry Eremin-Solenikov
Khem Raj
Saul Wold
Mei Lei
Yu Ke
Lianhao Lu
Tom Zanussi
Richard Purdie
Qing He
Saul Wold
Joshua Lock
Enric Balletbo i Serra
Enric Balletbo i Serra
Graeme Gregory
Mike Turquette