summaryrefslogtreecommitdiffstats
path: root/meta/classes/kernel-yocto.bbclass
Commit message (Collapse)AuthorAgeFilesLines
* linux-yocto: detect and avoid branch revision checking for AUTOREVBruce Ashfield2011-05-171-0/+7
| | | | | | | | | | | | | | | 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>
* linux-yocto: error if meta data not presentBruce Ashfield2011-05-101-1/+4
| | | | | | | | | | | | | | | | | | | | 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>
* linux-yocto: safely process unbranched repositoriesBruce Ashfield2011-05-051-2/+5
| | | | | | | | | | | | | | 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>
* linux-yocto: apply meta data to external reposBruce Ashfield2011-05-051-6/+21
| | | | | | | | | | | | | | 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>
* linux-yocto: enable audio for selected qemu targetsBruce Ashfield2011-02-231-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* linux-yocto: streamline BSP bootstrappingBruce Ashfield2011-02-091-61/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* kernel-yocto: Ensure python code has awlays run before SRCPV is expandedRichard Purdie2011-02-081-2/+9
| | | | | | | | | | | | | 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>
* kernel-yocto/poky-default-revisions: Ensure SRCREV_machine is set for the ↵Richard Purdie2011-02-081-1/+0
| | | | | | | | | kernels 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>
* kernel-yocto: 'standard' isn't a valid git branch name for a SRCREV, fixRichard Purdie2011-02-071-1/+1
| | | | Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* linux-yocto/linux-libc-headers-yocto: Adjust to git fetcher improvementsRichard Purdie2011-02-021-2/+2
| | | | Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* linux-yocto: export kernel configuration audit to the consoleBruce Ashfield2011-02-011-6/+11
| | | | | | | | | | | 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>
* linux-yocto: allow multiple BSPs per branchBruce Ashfield2011-01-241-2/+2
| | | | | | | | | | | | | | | | | | | | 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>
* linux-yocto: update validate_branches to detected invalid commit IDsBruce Ashfield2011-01-191-13/+13
| | | | | | | | | | 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>
* linux-yocto: streamline new BSP creationBruce Ashfield2011-01-191-3/+8
| | | | | | | | | | | | 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>
* kernel-yocto: pass the build directory to configmeBruce Ashfield2011-01-101-1/+1
| | | | | | | | | | 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>
* yocto-kernel: fix kmachine to deal with overridesBruce Ashfield2010-12-281-2/+5
| | | | | | | | | | | | | | | | 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>
* linux-yocto: remove or adjust to _ in branch namesBruce Ashfield2010-12-211-7/+5
| | | | | | | | | | | | | | | | | | | | | 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>
* yocto-kernel: factor common routes, update to 2.6.37 and branch renamingBruce Ashfield2010-12-101-0/+202
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>