summaryrefslogtreecommitdiffstats
path: root/meta/classes/kernel-yocto.bbclass
Commit message (Collapse)AuthorAgeFilesLines
* linux-yocto: support externalsrc buildsBruce Ashfield2012-03-281-0/+2
| | | | | | | | | | | | | | 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>
* linux-yocto: respect FILESPATH directoriesBruce Ashfield2012-03-131-4/+26
| | | | | | | | | | | | | | | | 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>
* meta: Replace bb.data.expand(xxx, d) -> d.expand(xxx)Richard Purdie2012-03-051-1/+1
| | | | | | | | sed \ -e 's:bb.data.\(expand([^,()]*\), *\([^) ]*\) *):\2.\1):g' \ -i `grep -ril bb.data.expand *` Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* linux-yocto: make kernel_checkout reentrantBruce Ashfield2012-03-021-13/+20
| | | | | | | | | | | | | | | 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>
* linux-yocto: allow non-branched repositories to check outBruce Ashfield2012-02-281-1/+1
| | | | | | | | | | | | | | 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>
* linux-yocto: improve checkout error handling and reportingBruce Ashfield2012-02-241-23/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* linux-yocto: locate and use out of tree features specified on the SRC_URIBruce Ashfield2012-02-081-0/+21
| | | | | | | | | | | | | 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>
* linux-yocto: restore WORKDIR as a patch source directoryBruce Ashfield2012-01-191-0/+2
| | | | | | | | | | | | 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>
* linux-yocto: use src_patches for out of tree kernel feature supportBruce Ashfield2012-01-061-2/+65
| | | | | | | | | | | | | | | 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>
* linux-yocto: use PATH to locate kconf_checkBruce Ashfield2012-01-031-2/+2
| | | | | | | | | | | | 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>
* kernel-yocto: fix extra CR in do_kernel_checkoutSaul Wold2011-12-021-2/+1
| | | | | | | (From OE-Core rev: 405ac5f5e8604dec087c7d87056c8c7f85739a41) Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* linux-yocto: prefer in-tree tools to external onesBruce Ashfield2011-12-021-1/+11
| | | | | | | (From OE-Core rev: ae7b3c518020715dde8b9eabdf30c71430e31712) Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel-yocto: support allnoconfig base configurationBruce Ashfield2011-12-021-2/+13
| | | | | | | | | | | | | | | | | | | | 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>
* Convert to use direct access to the data store (instead of bb.data.*Var*())Richard Purdie2011-11-101-1/+1
| | | | | | | | | | | | | | | | | This is the result of running the following over the metadata: sed \ -e 's:bb.data.\(setVar([^,()]*,[^,()]*\), *\([^ )]*\) *):\2.\1):g' \ -e 's:bb.data.\(setVarFlag([^,()]*,[^,()]*,[^,()]*\), *\([^) ]*\) *):\2.\1):g' \ -e 's:bb.data.\(getVar([^,()]*\), *\([^(), ]*\) *,\([^)]*\)):\2.\1,\3):g' \ -e 's:bb.data.\(getVarFlag([^,()]*,[^,()]*\), *\([^(), ]*\) *,\([^)]*\)):\2.\1,\3):g' \ -e 's:bb.data.\(getVarFlag([^,()]*,[^,()]*\), *\([^() ]*\) *):\2.\1):g' \ -e 's:bb.data.\(getVar([^,()]*\), *\([^) ]*\) *):\2.\1):g' \ -i `grep -ril bb.data *` (From OE-Core rev: b22831fd63164c4db9c0b72934d7d734a6585251) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* linux-yocto: simplify kernel configuration check expressionBruce Ashfield2011-09-221-1/+1
| | | | | | | | | | | | | | | | | | | | | 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>
* 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>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-11-18 02:34:42 +0000