* We have various variables which are either not quoted at all or are half
quoted. This patch fixes the bad exmaples so everything is consistent.
(From OE-Core rev: 960ee8076e860353a05eb2eb7f825a455c54698d)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
During the initial development of the linux-yocto recipes there were
several additional tasks that needed to be run in any inheriting
recipe. At that time, they didn't seem to fire if they were in the
include file versus the recipes themselves. As it turns out, these
tasks do work fine if placed in the linux-yocto.inc file, and the
rest of the recipes can be simplified as a result.
(From OE-Core rev: a1ab7c5e03df97e630dfee470ff7959d3143bf41)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
During the preparation of some linux-yocto extension documentation it
was clear that some variables are being defined in each recipe, when
they don't have to be. Moving the defaults into linux-yocto.in and
allowing them to be overidden in recipes simpifies the reuse of the
base infrastructure.
(From OE-Core rev: 0ca26544efe8d650f36db9dc1c3b3a15110d7e31)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As reported by Koen Kooi, the LICENSE for linux-yocto can be tightened
up to specifiy the particular version of the GPL.
cc: Koen Kooi <koen@dominion.thruhere.net>
(From OE-Core rev: 0b163efe5536555867f71561914414648b08ed24)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The existing infrastructure uses an external build tree which references the
kernel source in the work dir. If run with rm work, building external modules
will fail.
This patch places a configured source tree in sysroots. Striking a balance
between minimal size and minimal maintenance is difficult. A fully configured
tree is about 500MB after a clean. This version leans on the side of caution and
removes only the obviously unecessary parts of the source tree to conserve
space, resulting in about 170MB. The arch directories would be some additional
pruning we could do. Given examples from the devel package from distributions, I
suspect this size could be reduced to 75MB or so, but at the cost of a much more
complex recipe which is likely to require a great deal more maintenance to keep
current with kernel releases.
Care is also taken to clean the hostprogs in scripts, and the modules are
responsible for building them as needed. Although it is unclear to me if this is
really necessary, especially considering that modules put these bits back as
soon as they compile. If we are not generating an sstate package, I suspect we
can ignore these.
Please try this with your modules and let me know how it does. I tried to take
non linux-yocto kernel recipes into account, but I have only tested with
linux-yocto and the hello-mod recipe so far.
(From OE-Core rev: a9d41062e24a6b99661b3a5256f369b557433607)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Acked-by: Koen Kooi <koen@dominion.thruhere.net>
Acked-by: Gary Thomas <gary@mlbassoc.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [BUGID #610]
The powerpc linux-yocto kernels were not creating dtb images
in the deploy directories. This was due to two problems:
- the dtb generation rules were not being configured
- the boards were not specifying a device tree in their config
This change addresses the first point by factoring out the
dtb generation routines into a new include that can be used by
multiple recipes.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
In order to build BSPs that were not already integrated into
the upstream linux yocto kernel AND keep the git fetcher happy,
some fairly complex anonymous python sections were required.
These sections cause problems with variable expansion and SRCREV
processing.
With the updated git fetcher code, we can streamline the BSP
boostrapping process and drop 99% of the anonymous python code.
This commit has the following changes to support BSP boot strapping
and simplication for existing BSPs.
- KMETA is set per-recipe rather than in python code
- undefined machines are no longer used, but instead common
branch names are set per-recipe
- fallback machine SRCREVs are present in the default revisions
file
- A new variable YOCTO_KERNEL_EXTERNAL_BRANCH should be set in
the local.conf for new BSPs instead of being programatically
determined in the anonymous python.
- No more explicity KMACHINE variable expansion and manipulation,
since the tools and build phases no longer require it due
to the per-recipe fallbacks.
Integrated/merged BSPs are unaffected by the changes and have been
regression tested.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
foo
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Fixes [BUGID #692]
Previously the information dumped by the kernel configuration audit
scripts was only placed in log files. This isn't as useful as it
could be, since they are rarely checked. This change takes the
output from kconf_check and explicitly displays it to the user.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
During the last phase of the recipe factoring, the board compatibility
lists ended up in the wrong place, which meant we had an incomplete
list of boards, and the same set of boards for both kernels (stable
and devel).
To fix this, I've yanked the compatibility to the recipes themselves and
updated the emenlow to have a -stable bbappend.
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>
Martin Jansa
Bruce Ashfield
Darren Hart
Saul Wold