It's better to check a branches existence via show-ref versus the end
user branch commands. So we make the switch.
Also as part of this change, we move the conversion of remote branches
to local branches above the meta branch checking. This is required to
ensure that the branch is local for the show-ref check.
(From OE-Core rev: 04bd4cee625574cfa67679b6b2a150a21106c5bf)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The checking of machine and meta branch SRCREVs was inconsistent and
didn't allow a mixed AUTOREV machine/meta branch combination. By
simplifying the checks and changing the logic, we can now allow this
combination.
(From OE-Core rev: e272cfbba87a98393d6c22bd96c7f1cb6902170a)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
KBRANCH_DEFAULT was introduced as a way to trigger the enforced build
of a particular branch of the tree. With the fetcher now enforcing
SRCREVs existing on a branch, we can simply validate that the SRCREV
is reachable from the final branch and no longer care about enforcing
a given branch.
(From OE-Core rev: fbacbb0ca79cdae33803fdd3158671488b9bbcbe)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that the fetcher will enforce branch existence, we no longer need to
confirm that a branch exists, and that it was the branch requested to
be built.
We know the branch exists and we'll confirm that the specified SRCREV
is going to be built after we've patched the tree.
(From OE-Core rev: 93a7c7bd8e860e621af7174ef10d571b0d8622b2)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We no longer need to check if the KBRANCH matches the branch specified
in the SRC_URI. This is taken care of by the fetcher at the beginning
and SRCREV ancestor validation after patching.
(From OE-Core rev: a9b6550d3e2f5bf21fd05a17bca3e57c5b74e057)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The bitbake fetcher now enforces that a commit is contained by a branch,
so this code can be dropped from do_validate_branches.
(From OE-Core rev: 9e473d348d9e0db34e03446065c6c48d36964e1e)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rather than attempting to condition the entire tree to machine SRCREV (since
we don't know what branch will be built), we can instead wait until patching
has completed and then confirm that we are indeed building a decendant of the
specified SRCREV. The result is a much simpler check, and no mangling of the
tree.
(From OE-Core rev: 97075af9e9a691276cd417f1181ca73223f52d1c)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Parsing the output of git show is error prone, since it changes based on
the type of issue with bad comit IDs. Since the output is no longer used
in the case of a valid ref, we can switch to git-cat-file and simply
check the return code.
(From OE-Core rev: 228c05013fe691321ec00467d8d0c0bb64dd175c)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
do_validate_branches checks to ensure that a valid machine SRCREV was
set. A test against an empty SRCREV is done in two separate locations,
we only need one, since the first check immediately returns and the
second check never hits.
At the same time, we can stop referring to the same commit hash by
3 different names. Instead we assign to a local variable at the
top of the routine, and refer to it at all times.
(From OE-Core rev: 05508339882c7cc1fe3f1f67f72314fdcab979b7)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We allow inheriting recipes to control the kconfig mode used by merge_config.sh
via the KCONFIG_MODE variable. An error crept into the variable reference, and
since it is not quoted, the true condition always runs.
The result is that operations without an explicit kconfig mode cannot trigger
allnoconfig for defconfig builds, which can result in some options being
dropped from the final .config.
Quoting the reference allows it to evaluate properly.
(From OE-Core rev: aad19e4381a8a09c354e5899885997c5b4cd115b)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The dependency to CCACHE_DIR was moved to ccache.bbclass in
commit 2acf8da4f13c175ea818b9514677b7059de1e3e2:
[ ccache: Separate out into its own class ]
then the '=' should be replaced by '+=', otherwise, it will overwrite
the original ${CCACHE_DIR} in dirs.
Signen-off-by: Ming Liu <ming.liu@windriver.com>
(From OE-Core rev: e8b90254747651670031e6b2b8a702732124ecac)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The bbclass did the following:
do_diffconfig[depends] += "virtual/kernel:do_kernel_configme"
This clearly introduces a cross-kernel task dependency if the recipe
inheriting this class isn't the preferred provider of virtual/kernel, which is
obviously wrong, but further, will break the build if a kernel-yocto based
kernel is parsed and not skipped, but virtual/kernel refers to
a non-kernel-yocto recipe, which would not have the do_kernel_configme task.
Work around this by adding the in-recipe task dep programmatically with
bb.build.addtask when do_diffconfig exists.
(From OE-Core rev: 0e6881146d87f0d214d80bc92e54c113906db63a)
Signed-off-by: Christopher Larson <kergoth@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
'git branch' may use ANSI escape codes in its output (to provide colour)
which doesn't play well with commands expecting pure plain text, e.g.
fatal: '^[[31mmaster^[[m' is not a valid branch name.
Use the --no-color option to ensure all branch names are plain text.
Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
(From OE-Core rev: 87acfdb28380c26344a79a9dc0b4b403173bdc44)
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The validate_branches routine is responsible for ensuring that the specified
SRCREV exists, and that the tree has been prepared for eventual patching
starting directly from that SRCREV.
On exit, the routine checks out the specified machine branch and the
preparation is complete .. except if a KMETA branch isn't used, we exit
early since the branch can't be validated.
To make the exit condition consistent for all cases, we can move the
KMETA validation inside a conditional and allow the same exit path for
both cases.
(From OE-Core rev: 6eb63237c3bf48377f75e48e637d76108c8666df)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of using 'diff' command between two kernel config files,
the task diffconfig does the job creating the file
$WORKDIR/fragment.cfg that user should review and use.
[YOCTO #3862]
(From OE-Core rev: db2a44c8f08f2371a52ff6662d6bc64bc42ad551)
Signed-off-by: João Henrique Ferreira de Freitas <joaohf@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
While non-git kernel repos are not the preferred format for a kernel upstream,
they are supported. Depending on the creator of the archive the expanded
source directory name varies. If the recipe for the kernel doesn't properly
set S to the right value, a cryptic git error message is produced. We can
detect the situation and offer some advice on how to fix the issue.
A second check is also added in this commit for archive based kernel repos
which won't have a SRCREV to validate. If we have no SRCREV or SRCREV is
INVALID, we can exit the branch validation step immediately. This saves yet
another cryptic git error message and simplifies a custom tgz based recipe.
(From OE-Core rev: 0ebf67e8b4f7aaf259d7abac4af645070d846ec8)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These have been deprecated for a long time, convert the remaining
references to the correct modules and prepare for removal of the
compatibility support from bitbake.
(From OE-Core rev: 6a39835af2b2b3c7797fe05479341d71a3f3aaf6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Updating the kern-tools SRCREV to pick up the following fixes:
60a894e kgit-s2q: add proper commit ID handling for mixed am/apply usage
3b08257 kgit-s2q: delete pruning of path support.
c5868b4 kgit-s2q: Restore implicit exit status to "git apply" section
1bd00b9 kgit-scc: mask warnings from cleanup phase 5
bb75299 kgit-s2q: fix commit warp when running "git am --abort"
ef9571b kgit-scc: cleanup git rebase-apply dir
fdb7d21 kgit-scc: ensure treegen stops if a meta series fails
008987b config: add kconfig cleaning options
69ff569 kgit-s2q: strip blank lines and comments
e7b4540 kgit-init: disable garbage collection on a new tree
417eaed kgit-s2q: delete old LTSI patch dir finding code
21f2200 kgit-scc: better error checking on resume
ad5084c kern-tools: use .meta as meta data container
1deb5d8 kgit-meta: don't push patches without a series file
eb431a1 kgit-s2q: aid patch reject resolution via helper scripts
f859c40 kgit-s2q: only use patch annotations when explicitly asked
333ae18 kgit: speed patch application by batching patches
bf6991d kgit: teach tools about non-default meta dirs
bcfc712 kgit-s2q: usability improvements
cb28803 kgit-s2q: fix patch prefix stripping.
37f40e1 kgit-s2q: warn/exit with error if patch not in series
f4704d2 kgit-s2q: consistent rm usage
e11819c kgit-s2q: standardize on use of git mailinfo
36a5eda kgit: remove guilt dependency
c461a4f spp/scc: export mark commands to meta-series
5311162 updateme: ensure that generated features are only used once
4f7a263 kgit-checkpoint: clear .gitignore for meta branch
21ee6f2 updateme: enforce a matching machine
b08749d kgit-scc: remove -meta files after consruction
These are bug fixes, usability changes as well as the removal of the
guilt dependency. During the uprev of the guilt package, the amount of
circumvention of the typical guilt workflow and checks meant that using
it as a series -> branch manager was no longer appropriate. As a result
a new tools kgit-s2q (series 2 queue) was created based on git-quiltimport,
git am, and the LTSI tree generation scripts.
The result is better series to branch validation, faster application and
a simpler management model. This tool is backwards compatible with any
tree previously constructed with guilt. We are now "guilt free"
(From OE-Core rev: 983bff587b60fdd0244ad00f238df5ed50cc1e1a)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I mistakenly thought subprocess had getcmdstatus in python 2. It doesn't so lets
add a wrapper and have this work in both worlds.
(From OE-Core rev: 2253e9f12734c6e6aa489942b5e4628eca1fa29d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The commands module is removed in python3. Use the subprocess module instead
and the pipes module to replace the mkargs usage.
(From OE-Core rev: e2e1dcd74bc45381baccf507c0309dd792229afe)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
commit 61001aa [kernel-yocto: respect SRC_URI modified branch selection]
changed branch processing such that a branch specified in the SRC_URI
would set the branch forced as the build branch.
This change broke compatibility with the yocto-bsp, linux-yocto-custom
based recipes. These recipes specify the branch to be built via KBRANCH,
but allow the fetcher to use master for keeping the repository up to
date. This means that no explicit branch is set in the SRC_URI and the
routines return the default branch of 'master', which is not what is
set in KBRANCH.
To support this case, we simply pass a default branch into the routine
returning the branch to build, and ensure that the default is KBRANCH
so if no branch is passed in the SRC_URI, KBRANCH is always built.
[YOCTO #4145]
(From OE-Core rev: 0c389f41d7ea0697a5468c73cce295a2fa64e9e0)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The linux-yocto recipes themselves always set S="${WORKDIR}/linux" and
arrange for the fetcher default of ${WORKDIR}/git to be renamed before
building.
Part of this rename involves an assumption that the directory used by
the fetcher can be removed as part of the renaming process, or in fact
that renaming is required.
If a derived recipe uses S="${WORKDIR}/git", the checkout phase fails
since the kernel source is removed as part of the processing.
To fix this the code now detects this situation and does not clean the
source directory before renaming the fetcher default (and in fact does
not rename it at all).
(From OE-Core rev: e4ab5efea1a41297f63c96de97270136535b5f0b)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Although the setting of KBRANCH is the suggested/primary way to interact with
the yocto kern-tools and the fetcher, some users may be more comfortable
modifying the SRC_URI branch parameter directly.
If they do, the tools will not force their branch and build output will be
different then they expect, in non obvious ways.
It's easy enough to detect this scenario, but checking the SRC_URI in the
same way that the git fetcher checks for the branch (and SRCREV). If we take
the value from the SRC_URI and use it directly in the patch/validate/update
routines, we'll stay consistent with KBRANCH if it is used, and also
automatically adapt to a manually changed branch parameter on the SRC_URI.
For all other users, there are no visible or behavioural changes as a result
of this change
(From OE-Core rev: cfce8643ed166b51d7178be173677ea6f527d453)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To support configurations where active development is not being done within
the oe/bitbake build environment and restricted bandwidth situations, this
commit allows the SRC_URI to point to a kernel tgz instead of a full git
repository.
Outside of the upstream tgz instead of a kernel git repository, the
restrictions, config and patch process is the same as any linux-yocto-custom
recipe.
An example linux-yocto-custom based recipe would have a configuration like
this to build the 3.7 kernel, using an externally supplied config, from the
3.7 tgz:
SRC_URI = "http://kernel.org/pub/linux/kernel/v3.0/linux-3.7.tar.bz2"
PV = "3.7"
S = "${WORKDIR}/linux-3.7"
SRC_URI[md5sum] = "5323f3faadd051e83af605a63be5ea2e"
SRC_URI[sha256sum] = "dc08d87a579fe2918362e6666e503a95a76296419195cb499aa9dd4dbe171a9e"
[YOCTO #2686]
(From OE-Core rev: 08b3a282ce75a9972694f0c4379179505b9ec91f)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To promote the reuse and sharing of configuration fragments this change
allows any kernel-yocto based recipe to have multiple alternate git repositories
which provide kernel feature directory trees listed on the SRC_URI.
These feature directories are in addition to any in-tree kernel meta data branches
that may be available (described via the KMETA variable in linux-yocto recipes).
Features found within these directories can be used from recipes via the
KERNEL_FEATURES variable. Features found within a feature directory are free
to include any other features that are available in any directories. In both
cases the path to a feature description (a .scc file) is relative to the
root of a given feature directory (which is how existing .scc files work)
The search order for features is determined by the order that repositories
appear on the SRC_URI.
Normal SRC_URI rules apply to any repository that is added as a kernel
feature container. A SRCREV must be supplied and it must be unpacked to
a unique directory, which is controlled via the "destsuffic" url parameter.
In addition to these standard requirements, any kernel feature repository
reference should identify itself via the "type=kmeta" url parameter. If
type=kmeta is not supplied, the repository will not be processed for
kernel features.
As an example, the following in a linux-yocto bbappend makes two additional
feature directories available to KERNEL_FEATURES and fragments.
SRC_URI += "git://git.yoctoproject.org/yocto-kernel-cache;protocol=git;branch=master;type=kmeta;name=feat1;destsuffix=kernel-cache/"
SRC_URI += "git://${KSRC_linux_yocto_3_4};protocol=file;branch=meta;name=feat2;type=kmeta;destsuffix=kernel-features-experimental/"
SRCREV_feat1 = "${AUTOREV}"
SRCREV_feat2 = "${AUTOREV}"
(From OE-Core rev: 02ad603a104b70ab74548c8018e738bfbb3c59db)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
SRC_URIs that contained git repositories or other constructs that resulted
in an extension of "." or a substring of "scc" or "cfg" were matching the
tests for patches and configs. This was due to a python tuple being used
instead of an array. Switching to an array makes the match exact and the
behaviour we want.
(From OE-Core rev: 22aa5d040604b37ba984bae9e800e56ba6e4956d)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The details of the kernel configuration audit are typically a
debug action, so should be moved to bb.debug(). But in order
to maintain visibility of the results, a reference to the log
file is provided in the standard message.
(From OE-Core rev: 9ab80ad88d34622a81670cdc45cc3275fc3ebabe)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since linux-yocto based recipes have a split build and source directory,
we should export KBUILD=${B} to the devshell. This allows the kernel to
be incrementally build within the shell and not dirty the source
directory (which breaks subsequent full builds).
(From OE-Core rev: 88f88a22dfa730161168b0f228e3954178b74c6a)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the past working from a non-bare clone would cause problems,
due to branches not existing in the WORKDIR clone. This hasn't
been true for some time, since the routines which convert remotes
into local branches have been functioning without problems.
So we no longer need the warning and it can be removed.
(From OE-Core rev: 42d42c24a37af0ea8896087c7cc8215eb19f633d)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We should always leave the tree on a BSP branch or master when
do_validate_branches completes to avoid modifying version tracked
files are part of the build process. Modifying these files will lead
to errors when changing branches, since the contents would be lost.
This is evident in the case that a the meta branch is reset to a
known SRCREV and the tree was left on the meta branch. This branch
tracks the meta/meta-series, and other artifacts of the original
tree construction. When the build process runs, it updates these same
files, which creates a conflict when switching branches.
This has been fixed in the tree construction scripts to not track
these files, but a secondary fix is also required of not leaving
the build on these branches, to allow arbitrary trees to be built.
[YOCTO #3413]
(From OE-Core rev: 57397592ff8ec16922604d398c18d53a589be41f)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Having a meta branch is not strictly required by the tools (and
recipes like linux-yocto-custom do not have meta branches), but the
comments in the kernel-yocto.bbclass could lead someone to think that
it was required.
This commit clearifies the comment to the following:
# We can fix up the kernel repository even if it wasn't a bare clone.
# If KMETA is defined, the branch must exist, but a machine branch
# can be missing since it may be created later by the tools.
[YOCTO #3422]
(From OE-Core rev: 421a2e2523a8f2c461479a1c0d44908cc1eaca6b)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It was reported that the kernel configuration checks for custom yocto
kernels had the following output:
NOTE: validating kernel configuration
grep: /meta-series: No such file or directory
grep: /meta-series: No such file or directory
WARNING: Can't find any BSP hardware or required configuration fragments.
WARNING: Looked at //cfg///hdw_frags.txt and //cfg///required_frags.txt in directory: //cfg//
NOTE: Tasks Summary: Attempted 375 tasks of which 367 didn't need to be rerun and all succeeded.
which is not inspire confidence in the output of the process.
Completely inhibiting the check is one option to remove the messages,
but that removes the ability see output, which can help move users to
a better or more fully configured linux-yocto based kernel.
To fix this, we have to ensure that the path to the meta-series is
always valid, and that the tools can deal with not all files existing
in the audit directory.
Since custom yocto kernels do not set KMETA (they don't have a meta branch),
we ensure that a default of 'meta' is passed to the audit ('meta' is always
valid), and that kconf_check itself can deal with an incomplete set of
input audit files.
The net result is output like this (using a defconfig with invalid options
for the kernel being built):
NOTE: validating kernel configuration
This BSP sets 19 invalid/obsolete kernel options.
These config options are not offered anywhere within this kernel.
The full list can be found in your kernel src dir at:
meta/cfg/standard/qemux86/invalid.cfg
There were 1 instances of config fragment errors.
The full list can be found in your kernel src dir at:
meta/cfg/standard/qemux86/fragment_errors.txt
The full list can be found in your kernel src dir at:
meta/cfg/standard/qemux86/missing_required.cfg
(From OE-Core rev: 4d1b7dae063ee4c35c426306d0e22f11ce112c72)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
do_validate_branches ensures that the desired SRCREV is at
the tip of every branch that contains the revision. To do this,
it looks for containing branches and processes them.
This processing was mistakenly placed before the check for an
invalid SRCREV, hence a git error message is seen in the log
if a bad SRCREV is used, rather than a clear message.
reordering the checks, and fixing a check for master, ensures
that clear messages are generated in all cases.
(From OE-Core rev: 7e4518bf88af53b09536a3bafcd4c392a094023f)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When patches fail to apply, the status of all pending patches should
be exported to the logs and to the user. Currently, a missing export
of GUILT_BASE makes it look more like an internal error, than a 'normal'
patch failure:
| [ERROR] unable to complete push
| pending patches are:
| Patches directory doesn't exist, try guilt-init
With this variable exported, we have this:
| [INFO] validating against known patches (qemux86-standard-meta)
| error: patch failed: Makefile:2
| error: Makefile: patch does not apply
| To force apply this patch, use 'guilt push -f'
| [ERROR] unable to complete push
| pending patches are:
| links/files/0002-makefile-patch.patch
(From OE-Core rev: b2b2512cbc4196fa0f814be3677517dab30e5b52)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The commit a9f11849 [linux-yocto: explicitly export KMETA to scripts]
allows the meta branch name to be changed by exporting it to all
phases of the build.
But if a custom kernel without a meta branch is built, we end up
passing an empty string to the creation scripts, which breaks the
build since input is expected.
Inhibiting the export of KMETA to the creation scripts when empty
fixes the problem.
(From OE-Core rev: 61162fbe01993659301fe2e821bf9c3e801206d8)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To support custom repositories that set a SRCREV and that only have
a single master branch, do_validate_branches needs a special case
for 'master'. We can't delete and recreate the branch, since you
cannot delete the current branch, instead we must reset the branch
to the proper SRCREV.
(From OE-Core rev: de5bb5879fa3282c46dc1ede36af34eaab8f647f)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The kern-tools scripts can support a meta branch and directory of a name that
isn't "meta", but they need the name passed through the environment variable
KMETA. ensuring that KMETA is exported in the shell environment sets the stage
to support flexible meta branch name.
(From OE-Core rev: 9b90c8ace04c88ac6105f0bf686f9abc70fe8074)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The kernel branch is no longer required by the yocto-kern-tools
to locate BSP feature descriptions (it is the MACHINE:KTYPE
descriptor), so we no longer require that the BSP branch be
explicitly set.
If a kernel branch is explicitly set, it is now used to trigger
a checks to ensure that the branch really is being built.
Otherwise the branch that the machine description creates will
be built (just as it always was).
This further simplies the use and configuration of a linux-yocto
based kernel recipe.
(From OE-Core rev: 3cac3ce65abae9dc253641a2004440a2b38fd44d)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In do_kernel_checkout(), replace the creation of ${S}/.git with just
the creation of ${S} since the .git subdirectory is created only a few
lines later using a "mv". Here's the original code:
rm -rf ${S}
mkdir -p ${S}/.git
echo "WARNING. ${WORKDIR}/git is not a bare clone."
echo "Ensure that the SRC_URI includes the 'bareclone=1' option."
# we can fix up the kernel repository, but at the least the meta
# branch must be present. The machine branch may be created later.
mv ${WORKDIR}/git/.git ${S} <-- See? There it is.
There's no functional change here, it's just less confusing.
(From OE-Core rev: f0d318177096a7a1c7406642663ae4ce28010d12)
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: 072476bb6468d984ae3246f478fd5b3a21f7c8d6)
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The bb and os modules are always imported so having these extra import calls
are a waste of space/execution time. They also set a bad example for people
copy and pasting code so clean them up.
(From OE-Core rev: 7d674820958be3a7051ea619effe1a6061d9cbe2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Updating the kern-tools SRCREV to pickup the following functionality:
- buildall: provides the ability to build all kernel branches
without a build system, only a cross compiler and configme
are required.
- robustness/cleanups: obselete/unused code removal and general robustness
fixes from Paul Gortmaker and Bruce Ashfield
The following kern-tools commits are part of this series:
b8dfd3d buildall: add whitelist/blacklist support
0ef039c configme: catch errors found during fragment sanitization
5b6498c buildall: remove all instances of it using/reading scc files
2e57550 buildall: support semi seamless restarts
4b5dd4d kconf_check: simplify cmdline args, dont store data per branch
58fbb6e configme: relieve it of all knowledge of scc files
a03e291 configme: strip out alternative meta series logic.
96d2bcf kgit-init: check for valid branchpoint
5598db6 buildall: allow a max cap on the number of builds done
b46abec buildall: add support for randomizing build order
68a04e9 buildall: dont copy failed build logs into main build dir
5575d85 buildall: script to independently build all board kernels
86d6200 configme: delete unused variable
8d4e29d configme: delete unused KPROFILE setting
7e15436 configme: ensure we have a valid machine type set
152b9cb scc: remove depreciated/unused commands
bb4e96a scc: allow includes within conditional statements
7da7951 configme: derive path to tools from $0
152dc45 configme: test for BUILD_DIR != ""
129f7b0 kgit-scc: add warnings about bad input args.
e977662 kgit-scc: add text for no arg and invalid arg case.
[YOCTO #843]
(From OE-Core rev: be3cff86d55db6255e036d68e943e527802b4f4c)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, ccache is used if it is present. When building from scratch it gives
no performance improvement and creates a ton of empty directories even when its
not in use.
This change moves ccache support to a bbclass file which the user can choose to
enable. This should make builds more determinstic and make it easier/clearer
to the end user when its being used and when it is not.
(From OE-Core rev: 2acf8da4f13c175ea818b9514677b7059de1e3e2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
One of the patch backends to linux-yocto is guilt, which normally
tracks patches under .git. But .git isn't something that can be
checked into a SCM and repeated. So it has been moved under meta/patches
and committed to the meta branch.
If devshell is used, GUILT_BASE isn't set, so patch manipulations will
fail. We export GUILT_BASE and point it at the meta directory when
devshell is invoked for linux-yocto.
(From OE-Core rev: 10546e42a0db6a9585488536e29759239ef6e73b)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In order to support repositories of various types (with or without
meta data, branched, pristine, custom, etc) information about the
type of processing that is required was passed to the processing
phases via variables.
The combination of variables involved in coordinating the processing
creates a learning curve and overly complicates recipe extensions.
With minor tweaks to the kern-tools, adding flexibility and keying
off the existence of the meta branch it is possible to remove all
of the variables that were added to support different repository
types.
(From OE-Core rev: 06e5f45c8f38925cd5902a3a3f436f5e9451dd16)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In fixing an existing patch migration bug, the list of valid extensions
got out of sync from the core patch class. As a result, valid patches
were not being applied to the tree.
Updating the tools to migrate .diff files fixes the issue.
Also in this fix is the removal of .patch in the find_sccs() routine, since
it will never be returned by patch.bbclass when all non-patches are
requested, it is simply confusing.
(From OE-Core rev: 0ade3f26f40b67d7296725b1e956c46be9a86089)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
During testing/extension of the linux-yocto-tiny kernel it was found that
defconfigs were not always properly applied. This was due to two issues:
- not being able to fully control the order of objects applied to the
git tree on the SRC_URI
- defconfigs triggering --allnoconfig before being applied
To fix this, the recipe space code that previously detected and generated
automatic features moves back to the kernel tools (where it was before) and
is updated to also process .cfg and defconfigs. Moving this back to the
tools allow other recipes to automatically benefit from the additional
support.
The second issue is addressed by allowing configme to take --alldefconfig
when a recipe wishes to pass a defconfig and override the default
behaviour.
Fixes [YOCTO: 2250]
(From OE-Core rev: 08c368b9980716e459d846dd7183940a5bf8bea4)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are a few extra task that modify the source tree that should
be removed when externalsrc is inherited by a recipe that uses a
linux-yocto tree.
Adding those tasks to SRCTREECOVEREDTASKS means that they are skipped
and externalsrc works as intended.
(From OE-Core rev: e3117fb15498c899282f25a195f3dd3dc889168c)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
During the work to enhance the ability to specify out of tree kernel
features, an assumption was made about PN being part of a patch
path. This assumption is incorrect, since patches can be anywhere in
the valid FILESPATH.
To make locating the patches in WORKDIR simple, we can just query
patch.bbclass and return both the absolute directory of the patch
and the subdirectory as it was specified on the src_uri.
(From OE-Core rev: ecade4c986e5045879ea204e31457c9b53a15e33)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The steps in do_kernel_checkout modify the source tree in WORKDIR.
If it is called multiple times, or interrupted, the tree is left
in an inconsistent state.
This change adds protections around branch names, and around the
manipulations of directories to ensure that it is safe to call
at any point.
(From OE-Core rev: f937977f241e786c5a7438449ed4c9da4c55829b)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Not all users of the checkout phase of linux-yocto have all
branches present. This is normal, and should be supported. By
checking for an empty KBRANCH we can avoid validating a branch
that isn't supposed to exist.
[YOCTO #2032]
(From OE-Core rev: fb2b3c7c10df1b44679a20e7dffd37f07fd01aba)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The typical workflow for linux-yocto simply uses a remote
upstream repository (Whether it is mirrored or not), and in this
case there are no issues with consistency in the format of the
resository that is unpacked into the WORKDIR.
When working with a local linux-yocto repository for kernel
development the remote vs local branches is not always consistent
between repositories.
The suggested/documented workflow has always been to use a
bare clone of linux-yocto, and use a second working tree repository
for development. Changes flow from the working tree to the bare
clone and then into the working directory for build. A common
mistake that happens with this workflow is that the non-bare,
working repository is used instead of the bare clone version.
If a non-bare repository is reference by the SRC_URI, then the
branches that are fetched into WORKDIR are not consitent. If the
MACHINE and META branches are not present, cryptic build errors
will result.
To solve this problem, the checkout code has been changed in
several ways:
- works with a newly proposed 'bareclone' option to bitbake
- detects if a bareclone is present in WORKDIR or not and
adjustst the checkout accordingly.
- if a non-bare clone is detected, machine and meta branches
are checked. If they are not present, or can't be created
a clear error message is produced
- instead of manipulating the refs directly in the git tree,
local tracking branches are (quietly) created for remote
branches. Enabling a better workflow in the WORKDIR kernel
repository.
This has been tested with linux-yocto remote upstreams, local
bare and non-bare respositories. All builds succeed or fail
with clear error messages.
(From OE-Core rev: e3b6537cc7931636ab11ae6ed2c8fbaad9da91bc)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In a similar manner to calling the patch.bbclass to locate patches that
were listed on the SRC_URI, it is also useful to query about 'other' items
that are on the SRC_URI. In the case of linux-yocto, it allows us to
know about kernel features that were specific on the URI and then apply
them to the current tree.
(From OE-Core rev: 3e2ce87566124db8c78472f9a4f00ab26410f213)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the switch to using src_patches and using patches in their
source directory, the scanning of WORKDIR migrated items like
config fragments was dropped. Adding WORKDIR back as a patch
directory restores the old functionality.
(From OE-Core rev: fd46d2ec75a53a02464ab2f0bc69eb1971432c9a)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To support larger out of tree kernel features and enhanced patching schemes,
this changeset modifies the linux-yocto patching routines to call the
recently factored out 'src_patches' routine. Using the returned list of local
URIs for all valid patches, the logic can then determine whether or not
patches can be used in place, or need to be migrated and have re-usable
kernel features created. The results are then fed to the existing
infrastructure to be applied and commited to the tree.
(From OE-Core rev: dca97bbdbfc88c91287e74eb6a3974277f1028b7)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The changes made to prefer in-tree kernel tools forced the location
of kconf_check prematurely. For maximum flexibility, locating it
on the PATH is ideal, since the transition to in-tree tools will be
completely transparent.
(From OE-Core rev: 68684b4903261cc5d3f48355f7cc6671484bb546)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When creating a minimal config or creating a hard baseline for
incremental changes, it is often desired to disable all kernel
options and then begin building and enabling only what is required.
To support this workflow, a new variable KCONFIG_MODE is introduced
to contain a hint to the kernel configuration about how the kernel
config should be produced. This variable is passed directly to lkc
when it is invoked during configuration, so the contents of the
variable must be a valid option for the kernel config build.
Additionally, when a defconfig is detected, allnoconfig is enabled
as the default operation, unless otherwise specified by KCONFIG_MODE.
(From OE-Core rev: 644f2e525b910b9ff8d9aaa33f11eba3fefa7c85)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
kernel configuration validation takes place between two files. An
unprocessed configuration file (which is all the options found in
the various configuration fragments) and the final .config produced
by the lkc.
The unprocessed configuration file's name historically is based on
the name of the branch that was used to build the BSP. But with the
ability to map machine names to arbitrary branches, this is no longer
always true.
Searching for the pattern *-config-* in the meta subdirectory will
only match the config file, and frees the config validation phase
from being concerned with what branch was used to build the BSP.
(From OE-Core rev: 92e0d61f5bf15ca4eb262dfa3c533f9209a87915)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After constructing a kernel configuration file it then needs
to be located in the tree so it can be audited against the
final .config. The previous string that was used for the search
pattern contains the kernel version. If the recipe space kernel
version and internal tree version are out of sync, this will
cause the constructed config to not be found. By removing the
version from the search string, we can still find out config and
gracefully adapt to minor version skew.
(From OE-Core rev: f072ddc43828ebe8df4dd7433726775dd547580b)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #1350]
Since do_kernel_configme is added before the standard do_configure task
we needed to add CCACHE_DIR so when the kernel builds it's host configure
tools the CCACHE_DIR exists.
(From OE-Core rev: 564d5fd5a289be0ca47d53608e43f9b78d5c6ee0)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When building an external tree or bootstrapping a BSP the
external branch may not have been checked out. The tools now ensure
that the tree is ready for configuration, so we no longer need to
force the checkout of the external branch.
This change is coupled with some kern tools tweaks as follows:
40d9bab updateme: allow the location of board descriptions based on defines
59859ca createme: use branch name when creating meta data
91b4275 configme: determine meta branch based on directories, not branch naming
f5a915c kgit-meta: make branch creation and renaming more robust
(From OE-Core rev: 02c82bf5255b09bb27a0a4509861a3d2bd84b09f)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To support the mapping of any oe/yocto MACHINE to a kernel
branch that may not share that naming structure we have
KMACHINE and KBRANCH. To allow the mapping to work, we
actually have to pass KMACHINE into updateme and not MACHINE.
(From OE-Core rev: 658f2cc721b121c0a9a9e7aa8b41463952314c0b)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For kernel's that use a split source/object build the copy
of defconfig to {S} in the base kernel class is problematic.
The previous solution for this was to override the do_configure
of the base kernel class in a subclass. While this is still
a viable/valid option, it does mean that changes to the base
do_configure will be missed.
The solution to this is to copy a defconfig to {B} which is
typically the same as {S}, so most kernel recipes won't see or
care about this change.
With this change in place, linux-yocto.bbclass can drop its
override of do_configure.
Tested with linux-yocto and oe linux recipes.
(From OE-Core rev: 4f03d922ce32f602a5a407cf422d82a0d036e4a0)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you include a bitbake variable as a comment in a shell function
then it gets expanded by the bitbake signature handling code.
This could be classed as a bug or a feature depending on your viewpoint
(e.g. a multiline variable included in a comment could actually contain
executable code).
Since we don't always want kernel-yocto to reparse this changes the
syntax of the comment so it doesn't trigger the problem.
(From OE-Core rev: 512be74ee0d7ad7e76c1be62d1e0f499aa51d174)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When a BSP or layer specifies an AUTOREV for SRCREV, the logic
that matches expected vs real branch heads doesn't apply. We
always want the latest.
To solve the issues with invalid git revs causing validation
failures, we detect the AUTOINC value and do a early return,
skipping validation.
(From OE-Core rev: b4f1845f7cf42059984112e3f41a323b4c9d6dfd)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are valid reasons to build repositories without meta
data present and there are times when this is an error. This
change adds sanity tests to the build process to detect missing
meta data and throw an informative error message.
Sanity checking is only triggered from recipes (linux-yocto)
that always require meta data to be present. Other recipes
are not impacted and can auto-generate meta data as required.
Without this change the build process suceeds, but incorrect
meta data will be used (with no user knowledge), which is not
the desired behaviour.
(From OE-Core rev: adf9f92e2f8f6cc3deba72a194ded85e160ad9e3)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The BSP bootstrap and -dev use cases can be applied against
unbranched or repos without meta data. To allow the proper
and safe processing of those repositories, slight modifications
to the tools are required to pass the branch on the command
line (rather than detecting it always) and to only checkout
branches that exist.
(From OE-Core rev: ae754be8b43677604a853ec6f62b2490a91d8836)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To support quick uprev and testing, it is desireable to build
repositories that do not have embedded meta data. In this scenario
the meta data can be automatically created or provided externally.
This commit supports the first situation by detecting the lack
of meta data and then automatically creating a base set of meta
files.
(From OE-Core rev: 32c56cd6a5756f21d19d8a32239b783a7854aed3)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [BUGID #488#734]
Enable audio for qemux86/qemux86-64 via the following kernel
configuration options.
CONFIG_SOUND_OSS_CORE=y
CONFIG_SOUND_OSS_CORE_PRECLAIM=y
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=y
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_PCM_OSS_PLUGINS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RAWMIDI_SEQ=m
CONFIG_SND_AC97_CODEC=m
CONFIG_SND_ENS1370=m
CONFIG_SND_INTEL8X0=m
CONFIG_AC97_BUS=m
The mechanism to trigger these options is in the form of an
optional kernel feature that is only appended for qemux86
and qemux86-64, but is contained within the kernel tree.
This allows several things:
- the options to be available/shared for all boards
- the options to be in tree
- to not add the options to every board, which unecessarily
bloats the default configuration.
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>
The python code in this class file needs to run before SRCPV is expanded
and calls into the fetcher are made. To so this we create a python function
and prepend a call to it before SRCPV's get_srcrev() call.
Ugly, ugly, ugly but the ordering is guaranteed.
If this doesn't happen, the fetcher can end up in two different states and
there may be caching implications of this.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we don't do this and try to bring up a new machine we can trigger network
access to resolve the branch name to a revision which is undesireable.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
By default the linux-yocto recipes operate on the current branch
and use it as a trigger to locate the description of a board. This
model works well when using the git repo outside of a build system
since the commands can be simply invoked and will do something
useful. However, it does mean that you can't have two BSPs that
differ only by configuration, building out of a single branch
in the repository.
This means that you must have many branches for very similar
BSPs. This model is still preferred, but having the choice of
branching strategies is better.
With this change we can have multiple BSPs using a single branch
with the preferred description being hinted from the build
system by passing the $machine value to updateme/configme.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
The previous implementation of invalid commit ID checks would
error early when a bad object was detected. Rather than changing
to set +e for the entire routine, we'll capture the output and
do an explicit check for a bad object and throw a useful error
message when it is detected.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
By setting BOOTSTRAP to the branch that should be used for a
currently undefined BSP a build can be completed and an
environment for streamlining the BSP created.
With the appropriate machine.conf, and a defconfig any MACHINE
can be built against and inherit the configuration of the
standard yocto kernel.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
configme used to be able to calculate the output/build directory
when branches were always <machine>-<kernel type>. Branch names
can now be widely different and to avoid embedding complexity
in the scripts it is easier to just pass ${B} from the build system
down to the scripts.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
BSPs are built from a particular branch of the kernel repository
which is specfied via the mapping of MACHINE to KMACHINE. Unless
a global branch is being forced (like libc headers), KMACHINE
is an override on a per machine basis.
Because KMACHINE is typically override we must first try the
most specific variant KMACHINE_<machine> and if that is undefined
look for a fallack default. This allows any combination of
variables to work (and at the time the anonymous python
executes) safely and get us a properly defined branch for the
fetcher and build.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
The existing 2.6.34 kernel tree uses _ where poky typically
uses -. This is a historical artifact, since working with
gnu Make and shells means avoiding - is wise. The opposite
is true in Yocto.
To avoid using the _ reserved character wherever possible
we can simply remove it from the branch names in the
new 2.6.37 kernel, but to keep the content stable in the
0.9 2.6.34 kernel, we map _ to - for the purposes of
packaging.
To further faciliate this switch, the branch names no
longer need to be shortened in the KMACHINE mappings, but
can be fully specified and the tools/processing adapt as
required. This gives us the flexibility to map multiple
boards to a single branch for building.
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>
Bruce Ashfield
Ming Liu
Christopher Larson
Matt Fleming
João Henrique Ferreira de Freitas
Peter Kjellerstedt
Richard Purdie
Robert P. J. Day
Saul Wold