generic-poky/meta/classes/kernel-yocto.bbclass

414 lines
13 KiB
Plaintext
Raw Normal View History

yocto-kernel: factor common routes, update to 2.6.37 and branch renaming 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>
2010-11-18 21:09:02 +00:00
S = "${WORKDIR}/linux"
# remove tasks that modify the source tree in case externalsrc is inherited
SRCTREECOVEREDTASKS += "do_kernel_link_vmlinux do_kernel_configme do_validate_branches do_kernel_configcheck do_kernel_checkout do_patch"
# returns local (absolute) path names for all valid patches in the
# src_uri
def find_patches(d):
patches = src_patches(d)
patch_list=[]
for p in patches:
_, _, local, _, _, _ = bb.fetch.decodeurl(p)
patch_list.append(local)
return patch_list
# returns all the elements from the src uri that are .scc files
def find_sccs(d):
sources=src_patches(d, True)
sources_list=[]
for s in sources:
base, ext = os.path.splitext(os.path.basename(s))
if ext and ext in [".scc", ".cfg"]:
sources_list.append(s)
elif base and base in 'defconfig':
sources_list.append(s)
return sources_list
kernel-yocto: allow multiple / shared kernel feature directories 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>
2013-01-23 20:21:52 +00:00
# check the SRC_URI for "kmeta" type'd git repositories. Return the name of
# the repository as it will be found in WORKDIR
def find_kernel_feature_dirs(d):
feature_dirs=[]
fetch = bb.fetch2.Fetch([], d)
for url in fetch.urls:
urldata = fetch.ud[url]
parm = urldata.parm
if "type" in parm:
type = parm["type"]
if "destsuffix" in parm:
destdir = parm["destsuffix"]
if type == "kmeta":
feature_dirs.append(destdir)
return feature_dirs
# find the master/machine source branch. In the same way that the fetcher proceses
# git repositories in the SRC_URI we take the first repo found, first branch.
def get_machine_branch(d, default):
fetch = bb.fetch2.Fetch([], d)
for url in fetch.urls:
urldata = fetch.ud[url]
parm = urldata.parm
if "branch" in parm:
branches = urldata.parm.get("branch").split(',')
return branches[0]
return default
yocto-kernel: factor common routes, update to 2.6.37 and branch renaming 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>
2010-11-18 21:09:02 +00:00
do_patch() {
cd ${S}
export KMETA=${KMETA}
yocto-kernel: factor common routes, update to 2.6.37 and branch renaming 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>
2010-11-18 21:09:02 +00:00
# if kernel tools are available in-tree, they are preferred
# and are placed on the path before any external tools. Unless
# the external tools flag is set, in that case we do nothing.
if [ -f "${S}/scripts/util/configme" ]; then
if [ -z "${EXTERNAL_KERNEL_TOOLS}" ]; then
PATH=${S}/scripts/util:${PATH}
fi
fi
machine_branch="${@ get_machine_branch(d, "${KBRANCH}" )}"
# if we have a defined/set meta branch we should not be generating
# any meta data. The passed branch has what we need.
if [ -n "${KMETA}" ]; then
createme_flags="--disable-meta-gen --meta ${KMETA}"
fi
createme ${createme_flags} ${ARCH} ${machine_branch}
yocto-kernel: factor common routes, update to 2.6.37 and branch renaming 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>
2010-11-18 21:09:02 +00:00
if [ $? -ne 0 ]; then
echo "ERROR. Could not create ${machine_branch}"
yocto-kernel: factor common routes, update to 2.6.37 and branch renaming 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>
2010-11-18 21:09:02 +00:00
exit 1
fi
sccs="${@" ".join(find_sccs(d))}"
patches="${@" ".join(find_patches(d))}"
kernel-yocto: allow multiple / shared kernel feature directories 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>
2013-01-23 20:21:52 +00:00
feat_dirs="${@" ".join(find_kernel_feature_dirs(d))}"
set +e
# add any explicitly referenced features onto the end of the feature
# list that is passed to the kernel build scripts.
yocto-kernel: factor common routes, update to 2.6.37 and branch renaming 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>
2010-11-18 21:09:02 +00:00
if [ -n "${KERNEL_FEATURES}" ]; then
for feat in ${KERNEL_FEATURES}; do
addon_features="$addon_features --feature $feat"
done
yocto-kernel: factor common routes, update to 2.6.37 and branch renaming 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>
2010-11-18 21:09:02 +00:00
fi
kernel-yocto: allow multiple / shared kernel feature directories 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>
2013-01-23 20:21:52 +00:00
# check for feature directories/repos/branches that were part of the
# SRC_URI. If they were supplied, we convert them into include directives
# for the update part of the process
if [ -n "${feat_dirs}" ]; then
for f in ${feat_dirs}; do
if [ -d "${WORKDIR}/$f/meta" ]; then
includes="$includes -I${WORKDIR}/$f/meta"
elif [ -d "${WORKDIR}/$f" ]; then
includes="$includes -I${WORKDIR}/$f"
fi
done
fi
if [ "${machine_branch}" != "${KBRANCH_DEFAULT}" ]; then
updateme_flags="--branch ${machine_branch}"
fi
# updates or generates the target description
updateme ${updateme_flags} -DKDESC=${KMACHINE}:${LINUX_KERNEL_TYPE} \
kernel-yocto: allow multiple / shared kernel feature directories 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>
2013-01-23 20:21:52 +00:00
${includes} ${addon_features} ${ARCH} ${KMACHINE} ${sccs} ${patches}
yocto-kernel: factor common routes, update to 2.6.37 and branch renaming 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>
2010-11-18 21:09:02 +00:00
if [ $? -ne 0 ]; then
echo "ERROR. Could not update ${machine_branch}"
yocto-kernel: factor common routes, update to 2.6.37 and branch renaming 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>
2010-11-18 21:09:02 +00:00
exit 1
fi
# executes and modifies the source tree as required
patchme ${KMACHINE}
yocto-kernel: factor common routes, update to 2.6.37 and branch renaming 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>
2010-11-18 21:09:02 +00:00
if [ $? -ne 0 ]; then
echo "ERROR. Could not apply patches for ${KMACHINE}."
echo " Patch failures can be resolved in the devshell (bitbake -c devshell ${PN})"
exit 1
fi
# Perform a final check. If something other than the default kernel
# branch was requested, and that's not where we ended up, then we
# should thrown an error, since we aren't building what was expected
final_branch="$(git symbolic-ref HEAD 2>/dev/null)"
final_branch=${final_branch##refs/heads/}
if [ "${machine_branch}" != "${KBRANCH_DEFAULT}" ] &&
[ "${final_branch}" != "${machine_branch}" ]; then
echo "ERROR: branch ${machine_branch} was requested, but was not properly"
echo " configured to be built. The current branch is ${final_branch}"
yocto-kernel: factor common routes, update to 2.6.37 and branch renaming 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>
2010-11-18 21:09:02 +00:00
exit 1
fi
}
do_kernel_checkout() {
linux-yocto: improve checkout error handling and reporting 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>
2012-02-24 01:58:47 +00:00
set +e
# A linux yocto SRC_URI should use the bareclone option. That
# ensures that all the branches are available in the WORKDIR version
# of the repository.
source_dir=`echo ${S} | sed 's%/$%%'`
source_workdir="${WORKDIR}/git"
if [ -d "${WORKDIR}/git/" ] && [ -d "${WORKDIR}/git/.git" ]; then
# case2: the repository is a non-bare clone
# if S is WORKDIR/git, then we shouldn't be moving or deleting the tree.
if [ "${source_dir}" != "${source_workdir}" ]; then
rm -rf ${S}
mv ${WORKDIR}/git ${S}
fi
linux-yocto: improve checkout error handling and reporting 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>
2012-02-24 01:58:47 +00:00
cd ${S}
elif [ -d "${WORKDIR}/git/" ] && [ ! -d "${WORKDIR}/git/.git" ]; then
# case2: the repository is a bare clone
# if S is WORKDIR/git, then we shouldn't be moving or deleting the tree.
if [ "${source_dir}" != "${source_workdir}" ]; then
rm -rf ${S}
mkdir -p ${S}/.git
mv ${WORKDIR}/git/* ${S}/.git
rm -rf ${WORKDIR}/git/
fi
cd ${S}
linux-yocto: improve checkout error handling and reporting 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>
2012-02-24 01:58:47 +00:00
git config core.bare false
else
# case 3: we have no git repository at all.
# To support low bandwidth options for building the kernel, we'll just
# convert the tree to a git repo and let the rest of the process work unchanged
# if ${S} hasn't been set to the proper subdirectory a default of "linux" is
# used, but we can't initialize that empty directory. So check it and throw a
# clear error
cd ${S}
if [ ! -f "Makefile" ]; then
echo "[ERROR]: S is not set to the linux source directory. Check "
echo " the recipe and set S to the proper extracted subdirectory"
exit 1
fi
git init
git add .
git commit -q -m "baseline commit: creating repo for ${PN}-${PV}"
yocto-kernel: factor common routes, update to 2.6.37 and branch renaming 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>
2010-11-18 21:09:02 +00:00
fi
linux-yocto: improve checkout error handling and reporting 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>
2012-02-24 01:58:47 +00:00
# end debare
yocto-kernel: factor common routes, update to 2.6.37 and branch renaming 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>
2010-11-18 21:09:02 +00:00
# If KMETA is defined, the branch must exist, but a machine branch
# can be missing since it may be created later by the tools.
if [ -n "${KMETA}" ]; then
git branch -a | grep -q ${KMETA}
if [ $? -ne 0 ]; then
echo "ERROR. The branch '${KMETA}' is required and was not"
echo "found. Ensure that the SRC_URI points to a valid linux-yocto"
echo "kernel repository"
exit 1
fi
fi
machine_branch="${@ get_machine_branch(d, "${KBRANCH}" )}"
if [ "${KBRANCH}" != "${machine_branch}" ]; then
echo "WARNING: The SRC_URI machine branch and KBRANCH are not the same."
echo " KBRANCH will be adjusted to match, but this typically is a"
echo " misconfiguration and should be checked."
fi
linux-yocto: improve checkout error handling and reporting 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>
2012-02-24 01:58:47 +00:00
# convert any remote branches to local tracking ones
for i in `git branch -a | grep remotes | grep -v HEAD`; do
b=`echo $i | cut -d' ' -f2 | sed 's%remotes/origin/%%'`;
git show-ref --quiet --verify -- "refs/heads/$b"
if [ $? -ne 0 ]; then
git branch $b $i > /dev/null
fi
done
# Create a working tree copy of the kernel by checking out a branch
git show-ref --quiet --verify -- "refs/heads/${machine_branch}"
if [ $? -eq 0 ]; then
# checkout and clobber any unimportant files
git checkout -f ${machine_branch}
else
echo "Not checking out ${machine_branch}, it will be created later"
git checkout -f master
fi
yocto-kernel: factor common routes, update to 2.6.37 and branch renaming 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>
2010-11-18 21:09:02 +00:00
}
do_kernel_checkout[dirs] = "${S}"
addtask kernel_checkout before do_patch after do_unpack
do_kernel_configme[dirs] = "${S} ${B}"
yocto-kernel: factor common routes, update to 2.6.37 and branch renaming 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>
2010-11-18 21:09:02 +00:00
do_kernel_configme() {
echo "[INFO] doing kernel configme"
export KMETA=${KMETA}
yocto-kernel: factor common routes, update to 2.6.37 and branch renaming 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>
2010-11-18 21:09:02 +00:00
if [ -n ${KCONFIG_MODE} ]; then
configmeflags=${KCONFIG_MODE}
else
# If a defconfig was passed, use =n as the baseline, which is achieved
# via --allnoconfig
if [ -f ${WORKDIR}/defconfig ]; then
configmeflags="--allnoconfig"
fi
fi
cd ${S}
PATH=${PATH}:${S}/scripts/util
configme ${configmeflags} --reconfig --output ${B} ${LINUX_KERNEL_TYPE} ${KMACHINE}
yocto-kernel: factor common routes, update to 2.6.37 and branch renaming 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>
2010-11-18 21:09:02 +00:00
if [ $? -ne 0 ]; then
echo "ERROR. Could not configure ${KMACHINE}-${LINUX_KERNEL_TYPE}"
exit 1
fi
yocto-kernel: factor common routes, update to 2.6.37 and branch renaming 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>
2010-11-18 21:09:02 +00:00
echo "# Global settings from linux recipe" >> ${B}/.config
echo "CONFIG_LOCALVERSION="\"${LINUX_VERSION_EXTENSION}\" >> ${B}/.config
}
python do_kernel_configcheck() {
import re, string, sys
yocto-kernel: factor common routes, update to 2.6.37 and branch renaming 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>
2010-11-18 21:09:02 +00:00
bb.plain("NOTE: validating kernel config, see log.do_kernel_configcheck for details")
kernel-yocto: fix kernel configuration audit for custom yocto kernels 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>
2012-09-13 12:59:08 +00:00
# if KMETA isn't set globally by a recipe using this routine, we need to
# set the default to 'meta'. Otherwise, kconf_check is not passed a valid
# meta-series for processing
kmeta = d.getVar( "KMETA", True ) or "meta"
kern-tools: usability, bug fixes and no guilt 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>
2013-08-23 18:08:16 +00:00
if not os.path.exists(kmeta):
kmeta = "." + kmeta
kernel-yocto: fix kernel configuration audit for custom yocto kernels 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>
2012-09-13 12:59:08 +00:00
pathprefix = "export PATH=%s:%s; " % (d.getVar('PATH', True), "${S}/scripts/util/")
kernel-yocto: fix kernel configuration audit for custom yocto kernels 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>
2012-09-13 12:59:08 +00:00
cmd = d.expand("cd ${S}; kconf_check -config- %s/meta-series ${S} ${B}" % kmeta)
ret, result = oe.utils.getstatusoutput("%s%s" % (pathprefix, cmd))
config_check_visibility = d.getVar( "KCONF_AUDIT_LEVEL", True ) or 1
if config_check_visibility == 1:
bb.debug( 1, "%s" % result )
else:
bb.note( "%s" % result )
}
yocto-kernel: factor common routes, update to 2.6.37 and branch renaming 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>
2010-11-18 21:09:02 +00:00
# Ensure that the branches (BSP and meta) are on the locations specified by
yocto-kernel: factor common routes, update to 2.6.37 and branch renaming 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>
2010-11-18 21:09:02 +00:00
# their SRCREV values. If they are NOT on the right commits, the branches
# are corrected to the proper commit.
yocto-kernel: factor common routes, update to 2.6.37 and branch renaming 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>
2010-11-18 21:09:02 +00:00
do_validate_branches() {
cd ${S}
export KMETA=${KMETA}
yocto-kernel: factor common routes, update to 2.6.37 and branch renaming 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>
2010-11-18 21:09:02 +00:00
machine_branch="${@ get_machine_branch(d, "${KBRANCH}" )}"
set +e
# if SRCREV is AUTOREV it shows up as AUTOINC there's nothing to
# check and we can exit early
if [ "${SRCREV_machine}" = "AUTOINC" ] || "${SRCREV_machine}" = "INVALID" ] ||
[ "${SRCREV_machine}" = "" ]; then
return
fi
# If something other than the default branch was requested, it must
# exist in the tree, and it's a hard error if it wasn't
git show-ref --quiet --verify -- "refs/heads/${machine_branch}"
if [ $? -eq 1 ]; then
if [ -n "${KBRANCH_DEFAULT}" ] &&
[ "${machine_branch}" != "${KBRANCH_DEFAULT}" ]; then
echo "ERROR: branch ${machine_branch} was set for kernel compilation, "
echo " but it does not exist in the kernel repository."
echo " Check the value of KBRANCH and ensure that it describes"
echo " a valid banch in the source kernel repository"
exit 1
fi
fi
if [ -z "${SRCREV_machine}" ]; then
target_branch_head="${SRCREV}"
else
target_branch_head="${SRCREV_machine}"
fi
# $SRCREV could have also been AUTOINC, so check again
if [ "${target_branch_head}" = "AUTOINC" ]; then
return
fi
ref=`git show ${target_branch_head} 2>&1 | head -n1 || true`
if [ "$ref" = "fatal: bad object ${target_meta_head}" ]; then
echo "ERROR ${target_branch_head} is not a valid commit ID."
echo "The kernel source tree may be out of sync"
exit 1
yocto-kernel: factor common routes, update to 2.6.37 and branch renaming 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>
2010-11-18 21:09:02 +00:00
fi
containing_branches=`git branch --contains $target_branch_head | sed 's/^..//'`
if [ -z "$containing_branches" ]; then
echo "ERROR: SRCREV was set to \"$target_branch_head\", but no branches"
echo " contain this commit"
exit 1
fi
# force the SRCREV in each branch that contains the specified
# SRCREV (if it isn't the current HEAD of that branch)
git checkout -q master
for b in $containing_branches; do
branch_head=`git show-ref -s --heads ${b}`
if [ "$branch_head" != "$target_branch_head" ]; then
echo "[INFO] Setting branch $b to ${target_branch_head}"
if [ "$b" = "master" ]; then
git reset --hard $target_branch_head > /dev/null
else
git branch -D $b > /dev/null
git branch $b $target_branch_head > /dev/null
fi
fi
done
## KMETA branch validation
meta_head=`git show-ref -s --heads ${KMETA}`
target_meta_head="${SRCREV_meta}"
git show-ref --quiet --verify -- "refs/heads/${KMETA}"
if [ $? -eq 1 ]; then
return
fi
if [ "${target_meta_head}" = "AUTOINC" ]; then
return
fi
yocto-kernel: factor common routes, update to 2.6.37 and branch renaming 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>
2010-11-18 21:09:02 +00:00
if [ "$meta_head" != "$target_meta_head" ]; then
ref=`git show ${target_meta_head} 2>&1 | head -n1 || true`
if [ "$ref" = "fatal: bad object ${target_meta_head}" ]; then
echo "ERROR ${target_meta_head} is not a valid commit ID"
echo "The kernel source tree may be out of sync"
exit 1
else
echo "[INFO] Setting branch ${KMETA} to ${target_meta_head}"
git branch -m ${KMETA} ${KMETA}-orig
git checkout -q -b ${KMETA} ${target_meta_head}
if [ $? -ne 0 ];then
echo "ERROR: could not checkout ${KMETA} branch from known hash ${target_meta_head}"
yocto-kernel: factor common routes, update to 2.6.37 and branch renaming 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>
2010-11-18 21:09:02 +00:00
exit 1
fi
yocto-kernel: factor common routes, update to 2.6.37 and branch renaming 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>
2010-11-18 21:09:02 +00:00
fi
fi
git show-ref --quiet --verify -- "refs/heads/${machine_branch}"
if [ $? -eq 0 ]; then
# restore the branch for builds
git checkout -q -f ${machine_branch}
else
git checkout -q master
fi
yocto-kernel: factor common routes, update to 2.6.37 and branch renaming 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>
2010-11-18 21:09:02 +00:00
}
# Many scripts want to look in arch/$arch/boot for the bootable
# image. This poses a problem for vmlinux based booting. This
# task arranges to have vmlinux appear in the normalized directory
# location.
do_kernel_link_vmlinux() {
if [ ! -d "${B}/arch/${ARCH}/boot" ]; then
mkdir ${B}/arch/${ARCH}/boot
fi
cd ${B}/arch/${ARCH}/boot
ln -sf ../../../vmlinux
}
OE_TERMINAL_EXPORTS += "GUILT_BASE KBUILD_OUTPUT"
GUILT_BASE = "meta"
KBUILD_OUTPUT = "${B}"