summaryrefslogtreecommitdiffstats
path: root/meta/classes/kernel-yocto.bbclass
Commit message (Collapse)AuthorAgeFilesLines
* linux-yocto: generalize kernel config search patternBruce Ashfield2011-09-051-1/+1
| | | | | | | | | | | | | | | | 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>
* kernel-yocto: add CCACHE_DIR dependency to do_kernel_configmeSaul Wold2011-08-081-0/+1
| | | | | | | | | | | | | [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>
* linux-yocto: allow configuration of arbitrary branchesBruce Ashfield2011-08-081-12/+4
| | | | | | | | | | | | | | | | | | | 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>
* linux-yocto: pass KMACHINE to updateme, not MACHINEBruce Ashfield2011-08-081-1/+1
| | | | | | | | | | | | 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>
* kernel: copy defconfig to {B} vs {S}Bruce Ashfield2011-07-221-6/+0
| | | | | | | | | | | | | | | | | | | | | | | 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>
* kernel-yocto: Fix case where recipe is always reparsedRichard Purdie2011-07-071-1/+1
| | | | | | | | | | | | | | | | 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>
* 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>