summaryrefslogtreecommitdiffstats
path: root/meta/classes/kernel-yocto.bbclass
Commit message (Collapse)AuthorAgeFilesLines
* 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>