Thanks Richard for the clarification. So what would be possible
solution for this circular dependency issue? I can check if we can

get

the latest gnu-config via cvs. Any other or better solution?

Is there a release tarball we can use? If not, we might end up hosting
a
release tarball for it somewhere given this piece of software's
position
in the build process.

I'd like to axe our cvs dependency for sure.

Hi Richard,
The git web interface also export a tarball url: I was trying to use it: http://git.savannah.gnu.org/gitweb/?p=config.git;a=snapshot;h=1a0cbc1cd216932e4ecd7c773a4fa8aecce5b536;sf=tgz

But current bitbake fetcher would not handle ";" in the url. I was working on fixing that.

Thanks,
Nitin

On 10-12-08 03:20 PM, Bruce Ashfield wrote:

On 10-12-08 09:35 AM, Bruce Ashfield wrote:

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.

There may be a minor problem with this, stay tuned.

I just had a strange failure when I built the 2.6.37
kernel .. it blew up in the SRCREVs for the -stable
kernel. Looking into it.

I've resolved this, but don't fully understand it yet.
I'll send an updated patch series tomorrow, but this
shouldn't prevent review, since it is a one line change
to the anonymous python to fix the SRCREV parse errors.

Bruce

Bruce

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@...>
---
meta-emenlow/conf/machine/emenlow.conf | 3 +-
meta/classes/kernel-yocto.bbclass | 202 +++++++++++++++++
.../conf/distro/include/poky-default-revisions.inc | 2 +-
meta/conf/machine/atom-pc.conf | 3 +-
meta/conf/machine/beagleboard.conf | 3 +-
meta/conf/machine/include/qemu.inc | 1 +
meta/conf/machine/mpc8315e-rdb.conf | 3 +-
meta/conf/machine/routerstationpro.conf | 3 +-
.../linux-libc-headers-yocto_git.bb | 4 +-
meta/recipes-kernel/linux/linux-tools.inc | 19 ++
.../recipes-kernel/linux/linux-yocto-stable_git.bb | 41 ++++
meta/recipes-kernel/linux/linux-yocto.inc | 23 ++
meta/recipes-kernel/linux/linux-yocto_git.bb | 232 +++-----------------
13 files changed, 331 insertions(+), 208 deletions(-)
create mode 100644 meta/classes/kernel-yocto.bbclass
create mode 100644 meta/recipes-kernel/linux/linux-tools.inc
create mode 100644 meta/recipes-kernel/linux/linux-yocto-stable_git.bb
create mode 100644 meta/recipes-kernel/linux/linux-yocto.inc

diff --git a/meta-emenlow/conf/machine/emenlow.conf
b/meta-emenlow/conf/machine/emenlow.conf
index 0f9ed8a..b8dea64 100644
--- a/meta-emenlow/conf/machine/emenlow.conf
+++ b/meta-emenlow/conf/machine/emenlow.conf
@@ -16,7 +16,8 @@ MACHINE_FEATURES = "kernel26 screen keyboard pci
usbhost ext2 ext3 x86 \

KERNEL_IMAGETYPE = "bzImage"

-PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
+PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-stable"
+#PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"
PREFERRED_PROVIDER_libdrm = "libdrm-poulsbo"
PREFERRED_PROVIDER_drm = "libdrm-poulsbo"
PREFERRED_PROVIDER_virtual/libx11 = "libx11-trim"
diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass
new file mode 100644
index 0000000..87d06aa
--- /dev/null
+++ b/meta/classes/kernel-yocto.bbclass
@@ -0,0 +1,202 @@
+S = "${WORKDIR}/linux"
+
+# Determine which branch to fetch and build. Not all branches are in the
+# upstream repo (but will be locally created after the fetchers run) so
+# a fallback branch needs to be chosen.
+#
+# The default machine 'UNDEFINED'. If the machine is not set to a
specific
+# branch in this recipe or in a recipe extension, then we fallback to a
+# branch that is always present 'standard'. This sets the KBRANCH
variable
+# and is used in the SRC_URI. The machine is then set back to
${MACHINE},
+# since futher processing will use that to create local branches
+python __anonymous () {
+ import bb, re
+
+ version = bb.data.getVar("LINUX_VERSION", d, 1)
+ # 2.6.34 signifies the old-style tree, so we need some temporary
+ # conditional processing based on the kernel version.
+ if version == "2.6.34":
+ bb.data.setVar("KBRANCH", "${KMACHINE}-${LINUX_KERNEL_TYPE}", d)
+ bb.data.setVar("KMETA", "wrs_meta", d)
+ mach = bb.data.getVar("KMACHINE", d, 1)
+ if mach == "UNDEFINED":
+ bb.data.setVar("KBRANCH", "standard", d)
+ bb.data.setVar("KMACHINE", "${MACHINE}", d)
+ # track the global configuration on a bootstrapped BSP
+ bb.data.setVar("SRCREV_machine", "${SRCREV_meta}", d)
+ bb.data.setVar("BOOTSTRAP", "t", d)
+
+ else:
+ # The branch for a build is:
+ # yocto/<kernel type>/${KMACHINE} or
+ # yocto/<kernel type>/${KMACHINE}/base
+ bb.data.setVar("KBRANCH",
bb.data.expand("yocto/${LINUX_KERNEL_TYPE}/${KMACHINE}",d), d)
+ bb.data.setVar("KMETA", "meta", d)
+
+ mach = bb.data.getVar("KMACHINE", d, 1)
+ # drop the "/base" if it was on the KMACHINE
+ kmachine = mach.replace('/base','')
+ # and then write KMACHINE back
+ bb.data.setVar('KMACHINE_' + bb.data.expand("${MACHINE}",d),
kmachine, d)
+
+ if mach == "UNDEFINED":
+ bb.data.setVar("KBRANCH", "yocto/standard/base", d)
+ bb.data.setVar('KMACHINE_' + bb.data.expand("${MACHINE}",d),
bb.data.expand("${MACHINE}",d), d)
+ bb.data.setVar("SRCREV_machine", "standard", d)
+ bb.data.setVar("BOOTSTRAP", "t", d)
+}
+
+do_patch() {
+ cd ${S}
+ if [ -f ${WORKDIR}/defconfig ]; then
+ defconfig=${WORKDIR}/defconfig
+ fi
+
+ if [ -n "${BOOTSTRAP}" ]; then
+ kbranch="yocto/${LINUX_KERNEL_TYPE}/${KMACHINE}"
+ else
+ kbranch=${KBRANCH}
+ fi
+
+ # simply ensures that a branch of the right name has been created
+ createme ${ARCH} ${kbranch} ${defconfig}
+ if [ $? -ne 0 ]; then
+ echo "ERROR. Could not create ${kbranch}"
+ exit 1
+ fi
+
+ # updates or generates the target description
+ if [ -n "${KERNEL_FEATURES}" ]; then
+ addon_features="--features ${KERNEL_FEATURES}"
+ fi
+ updateme ${addon_features} ${ARCH} ${WORKDIR}
+ if [ $? -ne 0 ]; then
+ echo "ERROR. Could not update ${kbranch}"
+ exit 1
+ fi
+
+ # executes and modifies the source tree as required
+ patchme ${kbranch}
+ if [ $? -ne 0 ]; then
+ echo "ERROR. Could not modify ${kbranch}"
+ exit 1
+ fi
+}
+
+do_kernel_checkout() {
+ if [ -d ${WORKDIR}/.git/refs/remotes/origin ]; then
+ echo "Fixing up git directory for ${LINUX_KERNEL_TYPE}/${KMACHINE}"
+ rm -rf ${S}
+ mkdir ${S}
+ mv ${WORKDIR}/.git ${S}
+
+ if [ -e ${S}/.git/packed-refs ]; then
+ cd ${S}
+ rm -f .git/refs/remotes/origin/HEAD
+IFS='
+';
+ for r in `git show-ref | grep remotes`; do
+ ref=`echo $r | cut -d' ' -f1`;
+ b=`echo $r | cut -d' ' -f2 | sed 's%refs/remotes/origin/%%'`;
+ dir=`dirname $b`
+ mkdir -p .git/refs/heads/$dir
+ echo $ref> .git/refs/heads/$b
+ done
+ cd ..
+ else
+ cp -r ${S}/.git/refs/remotes/origin/* ${S}/.git/refs/heads
+ rmdir ${S}/.git/refs/remotes/origin
+ fi
+ fi
+ cd ${S}
+
+ # checkout and clobber and unimportant files
+ git checkout -f ${KBRANCH}
+}
+do_kernel_checkout[dirs] = "${S}"
+
+addtask kernel_checkout before do_patch after do_unpack
+
+do_kernel_configme() {
+ echo "[INFO] doing kernel configme"
+
+ cd ${S}
+ configme --reconfig
+ if [ $? -ne 0 ]; then
+ echo "ERROR. Could not configure ${KMACHINE}-${LINUX_KERNEL_TYPE}"
+ exit 1
+ fi
+
+ echo "# Global settings from linux recipe">> ${B}/.config
+ echo "CONFIG_LOCALVERSION="\"${LINUX_VERSION_EXTENSION}\">>
${B}/.config
+}
+
+do_kernel_configcheck() {
+ echo "[INFO] validating kernel configuration"
+ cd ${B}/..
+ kconf_check ${B}/.config ${B} ${S} ${B} ${LINUX_VERSION}
${KMACHINE}-${LINUX_KERNEL_TYPE}
+}
+
+
+# Ensure that the branches (BSP and meta) are on the locatios
specified by
+# their SRCREV values. If they are NOT on the right commits, the
branches
+# are reset to the correct commit.
+do_validate_branches() {
+ cd ${S}
+ branch_head=`git show-ref -s --heads ${KBRANCH}`
+ meta_head=`git show-ref -s --heads ${KMETA}`
+ target_branch_head="${SRCREV_machine}"
+ target_meta_head="${SRCREV_meta}"
+
+ # nothing to do if bootstrapping
+ if [ -n "${BOOTSTRAP}" ]; then
+ return
+ fi
+
+ if [ -n "$target_branch_head" ]&& [ "$branch_head" !=
"$target_branch_head" ]; then
+ if [ -n "${KERNEL_REVISION_CHECKING}" ]; then
+ git show ${target_branch_head}> /dev/null 2>&1
+ if [ $? -eq 0 ]; then
+ echo "Forcing branch ${KMACHINE}-${LINUX_KERNEL_TYPE} to
${target_branch_head}"
+ git branch -m ${KMACHINE}-${LINUX_KERNEL_TYPE}
${KMACHINE}-${LINUX_KERNEL_TYPE}-orig
+ git checkout -b ${KMACHINE}-${LINUX_KERNEL_TYPE} ${target_branch_head}
+ else
+ echo "ERROR ${target_branch_head} is not a valid commit ID."
+ echo "The kernel source tree may be out of sync"
+ exit 1
+ fi
+ fi
+ fi
+
+ if [ "$meta_head" != "$target_meta_head" ]; then
+ if [ -n "${KERNEL_REVISION_CHECKING}" ]; then
+ git show ${target_meta_head}> /dev/null 2>&1
+ if [ $? -eq 0 ]; then
+ echo "Forcing branch meta to ${target_meta_head}"
+ git branch -m meta meta-orig
+ git checkout -b meta ${target_meta_head}
+ else
+ echo "ERROR ${target_meta_head} is not a valid commit ID"
+ echo "The kernel source tree may be out of sync"
+ exit 1
+ fi
+ fi
+ fi
+
+ # restore the branch for builds
+ git checkout -f ${KBRANCH}
+}
+
+# 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
+}
+
+
diff --git a/meta/conf/distro/include/poky-default-revisions.inc
b/meta/conf/distro/include/poky-default-revisions.inc
index 7f3468d..0ec7a3a 100644
--- a/meta/conf/distro/include/poky-default-revisions.inc
+++ b/meta/conf/distro/include/poky-default-revisions.inc
@@ -56,7 +56,7 @@ SRCREV_pn-gypsy ??= "147"
SRCREV_pn-inputproto ??= "7203036522ba9d4b224d282d6afc2d0b947711ee"
SRCREV_pn-inputproto-native ??=
"7203036522ba9d4b224d282d6afc2d0b947711ee"
SRCREV_pn-inputproto-nativesdk ??=
"7203036522ba9d4b224d282d6afc2d0b947711ee"
-SRCREV_pn-kern-tools-native ??=
"9722d8decacd2b750f079b3fde7918810700f80e"
+SRCREV_pn-kern-tools-native ??=
"c85dcdd2dc50d71476a11c2960bf14c2b144b3c7"
SRCREV_pn-libdrm ??= "3f3c5be6f908272199ccf53f108b1124bfe0a00e"
SRCREV_pn-libfakekey ??= "2031"
SRCREV_pn-libgdbus ??= "aeab6e3c0185b271ca343b439470491b99cc587f"
diff --git a/meta/conf/machine/atom-pc.conf
b/meta/conf/machine/atom-pc.conf
index 7ca952a..8cf09b8 100644
--- a/meta/conf/machine/atom-pc.conf
+++ b/meta/conf/machine/atom-pc.conf
@@ -13,7 +13,8 @@ MACHINE_FEATURES = "kernel26 screen keyboard pci
usbhost ext2 ext3 x86 wifi \

KERNEL_IMAGETYPE = "bzImage"

-PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto-stable"
+#PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"
PREFERRED_PROVIDER_virtual/libx11 ?= "libx11-trim"
PREFERRED_PROVIDER_virtual/libgl ?= "mesa-dri"
PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xf86-dri-lite"
diff --git a/meta/conf/machine/beagleboard.conf
b/meta/conf/machine/beagleboard.conf
index 657bd36..1b73250 100644
--- a/meta/conf/machine/beagleboard.conf
+++ b/meta/conf/machine/beagleboard.conf
@@ -22,7 +22,8 @@ EXTRA_IMAGECMD_jffs2 = "-lnp "
# Guesswork
SERIAL_CONSOLE = "115200 ttyS2"

-PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
+PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-stable"
+#PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"

KERNEL_IMAGETYPE = "uImage"

diff --git a/meta/conf/machine/include/qemu.inc
b/meta/conf/machine/include/qemu.inc
index 1b1b888..502e24f 100644
--- a/meta/conf/machine/include/qemu.inc
+++ b/meta/conf/machine/include/qemu.inc
@@ -16,5 +16,6 @@ RDEPENDS_kernel-base = ""

# Use a common kernel recipe for all QEMU machines
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
+#PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"

EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
diff --git a/meta/conf/machine/mpc8315e-rdb.conf
b/meta/conf/machine/mpc8315e-rdb.conf
index 3341186..1b7982a 100644
--- a/meta/conf/machine/mpc8315e-rdb.conf
+++ b/meta/conf/machine/mpc8315e-rdb.conf
@@ -13,4 +13,5 @@ SERIAL_CONSOLE = "115200 ttyS0"

MACHINE_FEATURES = "kernel26 keyboard pci ext2 ext3 serial"

-PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
+PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-stable"
+#PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"
diff --git a/meta/conf/machine/routerstationpro.conf
b/meta/conf/machine/routerstationpro.conf
index 485ee3c..4f1bbbb 100644
--- a/meta/conf/machine/routerstationpro.conf
+++ b/meta/conf/machine/routerstationpro.conf
@@ -12,7 +12,8 @@ MACHINE_FEATURES = "kernel26 screen keyboard pci
usbhost ext2 ext3 \
KERNEL_IMAGETYPE = "vmlinux"
KERNEL_ALT_IMAGETYPE = "vmlinux.bin"

-PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
+PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-stable"
+#PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"

SERIAL_CONSOLE = "115200 ttyS0"

diff --git
a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb
index 6ae6d5f..3e3c1fa 100644
---
a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb
+++
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb
@@ -4,7 +4,7 @@ INHIBIT_DEFAULT_DEPS = "1"
DEPENDS += "unifdef-native"
PROVIDES = "linux-libc-headers"
PV = "2.6.34+git-${SRCPV}"
-PR = "r0"
+PR = "r1"

SRC_URI = "git://git.pokylinux.org/linux-2.6-windriver.git;fullclone=1"

@@ -45,7 +45,7 @@ do_compile () {

do_install() {
set_arch
- oe_runmake headers_install_all INSTALL_HDR_PATH=${D}${exec_prefix}
ARCH=$ARCH
+ oe_runmake headers_install INSTALL_HDR_PATH=${D}${exec_prefix}
ARCH=$ARCH
}

BBCLASSEXTEND = "nativesdk"
diff --git a/meta/recipes-kernel/linux/linux-tools.inc
b/meta/recipes-kernel/linux/linux-tools.inc
new file mode 100644
index 0000000..714207f
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-tools.inc
@@ -0,0 +1,19 @@
+# included by kernel recipes if they want to build/provide
+# perf functionality from their tree.
+
+do_compile_perf() {
+ oe_runmake -C ${S}/tools/perf CC="${KERNEL_CC}" LD="${KERNEL_LD}"
prefix=${prefix}
+}
+
+do_install_perf() {
+ oe_runmake -C ${S}/tools/perf CC="${KERNEL_CC}" LD="${KERNEL_LD}"
prefix=${prefix} DESTDIR=${D} install
+}
+
+
+# perf tasks
+addtask compile_perf after do_compile before do_install
+addtask install_perf after do_install before do_package do_deploy
+
+do_compile_perf[depends] = "virtual/libc:do_populate_sysroot"
+do_compile_perf[depends] =+ "elfutils:do_populate_sysroot"
+RDEPENDS_perf += "python perl elfutils"
diff --git a/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
b/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
new file mode 100644
index 0000000..8ecd86f
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
@@ -0,0 +1,41 @@
+inherit kernel
+require linux-yocto.inc
+
+KMACHINE_qemux86 = "common_pc/base"
+KMACHINE_qemux86-64 = "common_pc_64"
+KMACHINE_qemuppc = "qemu_ppc32"
+KMACHINE_qemumips = "mti_malta32_be"
+KMACHINE_qemuarm = "arm_versatile_926ejs"
+KMACHINE_atom-pc = "atom-pc"
+KMACHINE_routerstationpro = "routerstationpro"
+KMACHINE_mpc8315e-rdb = "fsl-mpc8315e-rdb"
+KMACHINE_beagleboard = "beagleboard"
+
+LINUX_VERSION ?= "2.6.34"
+LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"
+PR = "r0"
+PV = "${LINUX_VERSION}+git${SRCPV}"
+SRCREV_FORMAT = "meta_machine"
+
+# this performs a fixup on the SRCREV for new/undefined BSPs
+python __anonymous () {
+ import bb, re
+
+ rev = bb.data.getVar("SRCREV_machine", d, 1)
+ if rev == "standard":
+ bb.data.setVar("SRCREV_machine", "${SRCREV_meta}", d)
+}
+
+SRC_URI =
"git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;fullclone=1;branch=${KBRANCH};name=machine
\
+
git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;noclone=1;branch=wrs_meta;name=meta"

+
+
+# Functionality flags
+KERNEL_REVISION_CHECKING ?= "t"
+KERNEL_FEATURES=features/netfilter
+
+# extra tasks
+addtask kernel_link_vmlinux after do_compile before do_install
+addtask validate_branches before do_patch after do_kernel_checkout
+
+require linux-tools.inc
diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
b/meta/recipes-kernel/linux/linux-yocto.inc
new file mode 100644
index 0000000..095b337
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -0,0 +1,23 @@
+DESCRIPTION = "Yocto Kernel"
+SECTION = "kernel"
+LICENSE = "GPL"
+
+# A KMACHINE is the mapping of a yocto $MACHINE to what is built
+# by the kernel. This is typically the branch that should be built,
+# and it can be specific to the machine or shared
+KMACHINE = "UNDEFINED"
+
+COMPATIBLE_MACHINE =
"(qemuarm|qemux86|qemuppc|qemumips|qemux86-64|atom-pc|routerstationpro)"
+
+# Set this to 'preempt_rt' in the local.conf if you want a real time
kernel
+LINUX_KERNEL_TYPE ?= standard
+
+do_patch[depends] = "kern-tools-native:do_populate_sysroot"
+
+addtask kernel_configme before do_configure after do_patch
+addtask kernel_configcheck after do_configure before do_compile
+
+# Pick up shared functions
+inherit kernel-yocto
+
+B = "${WORKDIR}/linux-${KMACHINE}-${LINUX_KERNEL_TYPE}-build"
diff --git a/meta/recipes-kernel/linux/linux-yocto_git.bb
b/meta/recipes-kernel/linux/linux-yocto_git.bb
index ef005ae..db2e90b 100644
--- a/meta/recipes-kernel/linux/linux-yocto_git.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_git.bb
@@ -1,21 +1,7 @@
-DESCRIPTION = "Yocto Kernel"
-SECTION = "kernel"
-LICENSE = "GPL"
-
-# Set this to 'preempt_rt' in the local.conf if you want a real time
kernel
-LINUX_KERNEL_TYPE ?= standard
-SRCREV_FORMAT = "meta_machine"
-PV = "2.6.34+git${SRCPV}"
-
-# To use a staged, on-disk bare clone of a Wind River Kernel, use a
-# variant of the below
-# SRC_URI = "git://///path/to/kernel/default_kernel.git;fullclone=1"
-SRC_URI =
"git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;fullclone=1;branch=${KBRANCH};name=machine
\
-
git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;noclone=1;branch=wrs_meta;name=meta"

+inherit kernel
+require linux-yocto.inc

-# map the poky machine to a 'kernel machine'
-KMACHINE = "UNDEFINED"
-KMACHINE_qemux86 = "common_pc"
+KMACHINE_qemux86 = "common_pc/base"
KMACHINE_qemux86-64 = "common_pc_64"
KMACHINE_qemuppc = "qemu_ppc32"
KMACHINE_qemumips = "mti_malta32_be"
@@ -25,199 +11,45 @@ KMACHINE_routerstationpro = "routerstationpro"
KMACHINE_mpc8315e-rdb = "fsl-mpc8315e-rdb"
KMACHINE_beagleboard = "beagleboard"

-# Determine which branch to fetch and build. Not all branches are in the
-# upstream repo (but will be locally created after the fetchers run) so
-# a fallback branch needs to be chosen.
-#
-# The default machine 'UNDEFINED'. If the machine is not set to a
specific
-# branch in this recipe or in a recipe extension, then we fallback to a
-# branch that is always present 'standard'. This sets the KBRANCH
variable
-# and is used in the SRC_URI. The machine is then set back to
${MACHINE},
-# since futher processing will use that to create local branches
+# Holding area for board REVs until the full switch to this
+# recipe is complete
+SRCREV_machine_pn-linux-yocto_qemuarm =
"87e00a2d47ba80b4ad1f9170cb3f6cf81f21d739"
+SRCREV_machine_pn-linux-yocto_qemumips =
"7231e473dd981a28e3cea9f677ed60583e731550"
+SRCREV_machine_pn-linux-yocto_qemuppc =
"3ab3559637130b65d8889fa74286fdb57935726f"
+SRCREV_machine_pn-linux-yocto_qemux86 =
"87aacc373557f8849dde8618fbe1f7f8f2af6038"
+SRCREV_machine_pn-linux-yocto_qemux86-64 =
"87aacc373557f8849dde8618fbe1f7f8f2af6038"
+SRCREV_machine_pn-linux-yocto_emenlow =
"87aacc373557f8849dde8618fbe1f7f8f2af6038"
+SRCREV_machine_pn-linux-yocto_atom-pc =
"87aacc373557f8849dde8618fbe1f7f8f2af6038"
+SRCREV_machine_pn-linux-yocto_routerstationpro =
"773d3a1c8eba563ffcdbf61057ef6e39cee0c88b"
+SRCREV_machine_pn-linux-yocto_mpc8315e-rdb =
"5ff609967ffe87c49d534d7861a7e0b150517726"
+SRCREV_machine_pn-linux-yocto_beagleboard =
"87aacc373557f8849dde8618fbe1f7f8f2af6038"
+SRCREV_meta_pn-linux-yocto = "ee0a10ab687b29c4d22d47e5b28bc8b3ebb7a8d9"
+
+LINUX_VERSION ?= "2.6.37"
+LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"
+PR = "r14"
+PV = "${LINUX_VERSION}+git${SRCPV}"
+SRCREV_FORMAT = "meta_machine"
+
+# this performs a fixup on the SRCREV for new/undefined BSPs
python __anonymous () {
import bb, re

- bb.data.setVar("KBRANCH", "${KMACHINE}-${LINUX_KERNEL_TYPE}", d)
- mach = bb.data.getVar("KMACHINE", d, 1)
- if mach == "UNDEFINED":
- bb.data.setVar("KBRANCH", "standard", d)
- bb.data.setVar("KMACHINE", "${MACHINE}", d)
- # track the global configuration on a bootstrapped BSP
+ rev = bb.data.getVar("SRCREV_machine", d, 1)
+ if rev == "standard":
bb.data.setVar("SRCREV_machine", "${SRCREV_meta}", d)
- bb.data.setVar("BOOTSTRAP", "t", d)
}

-COMPATIBLE_MACHINE =
"(qemuarm|qemux86|qemuppc|qemumips|qemux86-64|atom-pc|routerstationpro|mpc8315e-rdb|beagleboard)"

-
-LINUX_VERSION = "v2.6.34"
-LINUX_VERSION_EXTENSION = "-wr-${LINUX_KERNEL_TYPE}"
-PR = "r13"
+SRC_URI =
"git://git.pokylinux.org/linux-yocto-2.6.37;protocol=git;fullclone=1;branch=${KBRANCH};name=machine
\
+
git://git.pokylinux.org/linux-yocto-2.6.37;protocol=git;noclone=1;branch=meta;name=meta"


-S = "${WORKDIR}/linux"
-B = "${WORKDIR}/linux-${KMACHINE}-${LINUX_KERNEL_TYPE}-build"

-# functionality flags
+# Functionality flags
KERNEL_REVISION_CHECKING ?= "t"
KERNEL_FEATURES=features/netfilter

-do_patch() {
- cd ${S}
- if [ -f ${WORKDIR}/defconfig ]; then
- defconfig=${WORKDIR}/defconfig
- fi
-
- # simply ensures that a branch of the right name has been created
- createme ${ARCH} ${KMACHINE}-${LINUX_KERNEL_TYPE} ${defconfig}
- if [ $? -ne 0 ]; then
- echo "ERROR. Could not create ${KMACHINE}-${LINUX_KERNEL_TYPE}"
- exit 1
- fi
-
- # updates or generates the target description
- if [ -n "${KERNEL_FEATURES}" ]; then
- addon_features="--features ${KERNEL_FEATURES}"
- fi
- updateme ${addon_features} ${ARCH} ${WORKDIR}
- if [ $? -ne 0 ]; then
- echo "ERROR. Could not update ${KMACHINE}-${LINUX_KERNEL_TYPE}"
- exit 1
- fi
-
- # executes and modifies the source tree as required
- patchme ${KMACHINE}-${LINUX_KERNEL_TYPE}
- if [ $? -ne 0 ]; then
- echo "ERROR. Could not modify ${KMACHINE}-${LINUX_KERNEL_TYPE}"
- exit 1
- fi
-}
-
-validate_branches() {
- branch_head=`git show-ref -s --heads ${KBRANCH}`
- meta_head=`git show-ref -s --heads wrs_meta`
- target_branch_head="${SRCREV_machine}"
- target_meta_head="${SRCREV_meta}"
-
- if [ -n "$target_branch_head" ]&& [ "$branch_head" !=
"$target_branch_head" ]; then
- if [ -n "${KERNEL_REVISION_CHECKING}" ]; then
- git show ${target_branch_head}> /dev/null 2>&1
- if [ $? -eq 0 ]; then
- echo "Forcing branch ${KMACHINE}-${LINUX_KERNEL_TYPE} to
${target_branch_head}"
- git branch -m ${KMACHINE}-${LINUX_KERNEL_TYPE}
${KMACHINE}-${LINUX_KERNEL_TYPE}-orig
- git checkout -b ${KMACHINE}-${LINUX_KERNEL_TYPE} ${target_branch_head}
- else
- echo "ERROR ${target_branch_head} is not a valid commit ID."
- echo "The kernel source tree may be out of sync"
- exit 1
- fi
- fi
- fi
-
- if [ "$meta_head" != "$target_meta_head" ]; then
- if [ -n "${KERNEL_REVISION_CHECKING}" ]; then
- git show ${target_meta_head}> /dev/null 2>&1
- if [ $? -eq 0 ]; then
- echo "Forcing branch wrs_meta to ${target_meta_head}"
- git branch -m wrs_meta wrs_meta-orig
- git checkout -b wrs_meta ${target_meta_head}
- else
- echo "ERROR ${target_meta_head} is not a valid commit ID"
- echo "The kernel source tree may be out of sync"
- exit 1
- fi
- fi
- fi
-}
-
-do_kernel_checkout() {
- if [ -d ${WORKDIR}/.git/refs/remotes/origin ]; then
- echo "Fixing up git directory for ${KMACHINE}-${LINUX_KERNEL_TYPE}"
- rm -rf ${S}
- mkdir ${S}
- mv ${WORKDIR}/.git ${S}
-
- if [ -e ${S}/.git/packed-refs ]; then
- cd ${S}
- rm -f .git/refs/remotes/origin/HEAD
-IFS='
-';
-
- for r in `git show-ref | grep remotes`; do
- ref=`echo $r | cut -d' ' -f1`;
- b=`echo $r | cut -d'/' -f4`;
- echo $ref> .git/refs/heads/$b
- done
- cd ..
- else
- mv ${S}/.git/refs/remotes/origin/* ${S}/.git/refs/heads
- rmdir ${S}/.git/refs/remotes/origin
- fi
- fi
- cd ${S}
-
- # checkout and clobber and unimportant files
- git checkout -f ${KBRANCH}
-
- if [ -z "${BOOTSTRAP}" ]; then
- validate_branches
- fi
-
- # this second checkout is intentional, we want to leave ourselves
- # on the branch to be built, but validate_branches could have changed
- # our initial checkout. So we do it a second time to be sure
- git checkout -f ${KBRANCH}
-}
-do_kernel_checkout[dirs] = "${S}"
-
-addtask kernel_checkout before do_patch after do_unpack
-
-do_kernel_configme() {
- echo "Doing kernel configme"
-
- cd ${S}
- configme --reconfig
- if [ $? -ne 0 ]; then
- echo "ERROR. Could not configure ${KMACHINE}-${LINUX_KERNEL_TYPE}"
- exit 1
- fi
-
- echo "# CONFIG_WRNOTE is not set">> ${B}/.config
- echo "# Global settings from linux recipe">> ${B}/.config
- echo "CONFIG_LOCALVERSION="\"${LINUX_VERSION_EXTENSION}\">>
${B}/.config
-}
-
-do_kernel_configcheck() {
- echo "[INFO] validating kernel configuration"
- cd ${B}/..
- kconf_check ${B}/.config ${B} ${S} ${B} ${LINUX_VERSION}
${KMACHINE}-${LINUX_KERNEL_TYPE}
-}
-
-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
-}
-
-do_compile_perf() {
- oe_runmake -C ${S}/tools/perf CC="${KERNEL_CC}" LD="${KERNEL_LD}"
prefix=${prefix}
-}
-
-do_install_perf() {
- oe_runmake -C ${S}/tools/perf CC="${KERNEL_CC}" LD="${KERNEL_LD}"
prefix=${prefix} DESTDIR=${D} install
-}
-
-do_patch[depends] = "kern-tools-native:do_populate_sysroot"
-addtask kernel_configme before do_configure after do_patch
+# extra tasks
addtask kernel_link_vmlinux after do_compile before do_install
-addtask kernel_configcheck after do_configure before do_compile
-
-inherit kernel
-
-# perf tasks
-addtask compile_perf after do_compile before do_install
-addtask install_perf after do_install before do_package do_deploy
+addtask validate_branches before do_patch after do_kernel_checkout

-do_compile_perf[depends] = "virtual/libc:do_populate_sysroot"
-do_compile_perf[depends] =+ "elfutils:do_populate_sysroot"
-RDEPENDS_perf += "python perl elfutils"
+require linux-tools.inc

_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto

On 10-12-08 09:35 AM, Bruce Ashfield wrote:

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:

<snip>

}

-COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemux86-64|atom-pc|routerstationpro|mpc8315e-rdb|beagleboard)"
-
-LINUX_VERSION = "v2.6.34"
-LINUX_VERSION_EXTENSION = "-wr-${LINUX_KERNEL_TYPE}"
-PR = "r13"
+SRC_URI = "git://git.pokylinux.org/linux-yocto-2.6.37;protocol=git;fullclone=1;branch=${KBRANCH};name=machine \

Richard,

This URI is only accessible via ssh, but the contents of the kernel
are definitely there. What do we need to change to make this
beastie public ? This is what is causing part of my SRCREV issues.

Cheers,

Bruce

+ git://git.pokylinux.org/linux-yocto-2.6.37;protocol=git;noclone=1;branch=meta;name=meta"

-S = "${WORKDIR}/linux"
-B = "${WORKDIR}/linux-${KMACHINE}-${LINUX_KERNEL_TYPE}-build"

On 10-12-08 09:35 AM, Bruce Ashfield wrote:

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.

There may be a minor problem with this, stay tuned.

I just had a strange failure when I built the 2.6.37
kernel .. it blew up in the SRCREVs for the -stable
kernel. Looking into it.

Bruce

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@...>
---
meta-emenlow/conf/machine/emenlow.conf | 3 +-
meta/classes/kernel-yocto.bbclass | 202 +++++++++++++++++
.../conf/distro/include/poky-default-revisions.inc | 2 +-
meta/conf/machine/atom-pc.conf | 3 +-
meta/conf/machine/beagleboard.conf | 3 +-
meta/conf/machine/include/qemu.inc | 1 +
meta/conf/machine/mpc8315e-rdb.conf | 3 +-
meta/conf/machine/routerstationpro.conf | 3 +-
.../linux-libc-headers-yocto_git.bb | 4 +-
meta/recipes-kernel/linux/linux-tools.inc | 19 ++
.../recipes-kernel/linux/linux-yocto-stable_git.bb | 41 ++++
meta/recipes-kernel/linux/linux-yocto.inc | 23 ++
meta/recipes-kernel/linux/linux-yocto_git.bb | 232 +++-----------------
13 files changed, 331 insertions(+), 208 deletions(-)
create mode 100644 meta/classes/kernel-yocto.bbclass
create mode 100644 meta/recipes-kernel/linux/linux-tools.inc
create mode 100644 meta/recipes-kernel/linux/linux-yocto-stable_git.bb
create mode 100644 meta/recipes-kernel/linux/linux-yocto.inc

diff --git a/meta-emenlow/conf/machine/emenlow.conf b/meta-emenlow/conf/machine/emenlow.conf
index 0f9ed8a..b8dea64 100644
--- a/meta-emenlow/conf/machine/emenlow.conf
+++ b/meta-emenlow/conf/machine/emenlow.conf
@@ -16,7 +16,8 @@ MACHINE_FEATURES = "kernel26 screen keyboard pci usbhost ext2 ext3 x86 \

KERNEL_IMAGETYPE = "bzImage"

-PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
+PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-stable"
+#PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"
PREFERRED_PROVIDER_libdrm = "libdrm-poulsbo"
PREFERRED_PROVIDER_drm = "libdrm-poulsbo"
PREFERRED_PROVIDER_virtual/libx11 = "libx11-trim"
diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-yocto.bbclass
new file mode 100644
index 0000000..87d06aa
--- /dev/null
+++ b/meta/classes/kernel-yocto.bbclass
@@ -0,0 +1,202 @@
+S = "${WORKDIR}/linux"
+
+# Determine which branch to fetch and build. Not all branches are in the
+# upstream repo (but will be locally created after the fetchers run) so
+# a fallback branch needs to be chosen.
+#
+# The default machine 'UNDEFINED'. If the machine is not set to a specific
+# branch in this recipe or in a recipe extension, then we fallback to a
+# branch that is always present 'standard'. This sets the KBRANCH variable
+# and is used in the SRC_URI. The machine is then set back to ${MACHINE},
+# since futher processing will use that to create local branches
+python __anonymous () {
+ import bb, re
+
+ version = bb.data.getVar("LINUX_VERSION", d, 1)
+ # 2.6.34 signifies the old-style tree, so we need some temporary
+ # conditional processing based on the kernel version.
+ if version == "2.6.34":
+ bb.data.setVar("KBRANCH", "${KMACHINE}-${LINUX_KERNEL_TYPE}", d)
+ bb.data.setVar("KMETA", "wrs_meta", d)
+ mach = bb.data.getVar("KMACHINE", d, 1)
+ if mach == "UNDEFINED":
+ bb.data.setVar("KBRANCH", "standard", d)
+ bb.data.setVar("KMACHINE", "${MACHINE}", d)
+ # track the global configuration on a bootstrapped BSP
+ bb.data.setVar("SRCREV_machine", "${SRCREV_meta}", d)
+ bb.data.setVar("BOOTSTRAP", "t", d)
+
+ else:
+ # The branch for a build is:
+ # yocto/<kernel type>/${KMACHINE} or
+ # yocto/<kernel type>/${KMACHINE}/base
+ bb.data.setVar("KBRANCH", bb.data.expand("yocto/${LINUX_KERNEL_TYPE}/${KMACHINE}",d), d)
+ bb.data.setVar("KMETA", "meta", d)
+
+ mach = bb.data.getVar("KMACHINE", d, 1)
+ # drop the "/base" if it was on the KMACHINE
+ kmachine = mach.replace('/base','')
+ # and then write KMACHINE back
+ bb.data.setVar('KMACHINE_' + bb.data.expand("${MACHINE}",d), kmachine, d)
+
+ if mach == "UNDEFINED":
+ bb.data.setVar("KBRANCH", "yocto/standard/base", d)
+ bb.data.setVar('KMACHINE_' + bb.data.expand("${MACHINE}",d), bb.data.expand("${MACHINE}",d), d)
+ bb.data.setVar("SRCREV_machine", "standard", d)
+ bb.data.setVar("BOOTSTRAP", "t", d)
+}
+
+do_patch() {
+ cd ${S}
+ if [ -f ${WORKDIR}/defconfig ]; then
+ defconfig=${WORKDIR}/defconfig
+ fi
+
+ if [ -n "${BOOTSTRAP}" ]; then
+ kbranch="yocto/${LINUX_KERNEL_TYPE}/${KMACHINE}"
+ else
+ kbranch=${KBRANCH}
+ fi
+
+ # simply ensures that a branch of the right name has been created
+ createme ${ARCH} ${kbranch} ${defconfig}
+ if [ $? -ne 0 ]; then
+ echo "ERROR. Could not create ${kbranch}"
+ exit 1
+ fi
+
+ # updates or generates the target description
+ if [ -n "${KERNEL_FEATURES}" ]; then
+ addon_features="--features ${KERNEL_FEATURES}"
+ fi
+ updateme ${addon_features} ${ARCH} ${WORKDIR}
+ if [ $? -ne 0 ]; then
+ echo "ERROR. Could not update ${kbranch}"
+ exit 1
+ fi
+
+ # executes and modifies the source tree as required
+ patchme ${kbranch}
+ if [ $? -ne 0 ]; then
+ echo "ERROR. Could not modify ${kbranch}"
+ exit 1
+ fi
+}
+
+do_kernel_checkout() {
+ if [ -d ${WORKDIR}/.git/refs/remotes/origin ]; then
+ echo "Fixing up git directory for ${LINUX_KERNEL_TYPE}/${KMACHINE}"
+ rm -rf ${S}
+ mkdir ${S}
+ mv ${WORKDIR}/.git ${S}
+
+ if [ -e ${S}/.git/packed-refs ]; then
+ cd ${S}
+ rm -f .git/refs/remotes/origin/HEAD
+IFS='
+';
+ for r in `git show-ref | grep remotes`; do
+ ref=`echo $r | cut -d' ' -f1`;
+ b=`echo $r | cut -d' ' -f2 | sed 's%refs/remotes/origin/%%'`;
+ dir=`dirname $b`
+ mkdir -p .git/refs/heads/$dir
+ echo $ref> .git/refs/heads/$b
+ done
+ cd ..
+ else
+ cp -r ${S}/.git/refs/remotes/origin/* ${S}/.git/refs/heads
+ rmdir ${S}/.git/refs/remotes/origin
+ fi
+ fi
+ cd ${S}
+
+ # checkout and clobber and unimportant files
+ git checkout -f ${KBRANCH}
+}
+do_kernel_checkout[dirs] = "${S}"
+
+addtask kernel_checkout before do_patch after do_unpack
+
+do_kernel_configme() {
+ echo "[INFO] doing kernel configme"
+
+ cd ${S}
+ configme --reconfig
+ if [ $? -ne 0 ]; then
+ echo "ERROR. Could not configure ${KMACHINE}-${LINUX_KERNEL_TYPE}"
+ exit 1
+ fi
+
+ echo "# Global settings from linux recipe">> ${B}/.config
+ echo "CONFIG_LOCALVERSION="\"${LINUX_VERSION_EXTENSION}\">> ${B}/.config
+}
+
+do_kernel_configcheck() {
+ echo "[INFO] validating kernel configuration"
+ cd ${B}/..
+ kconf_check ${B}/.config ${B} ${S} ${B} ${LINUX_VERSION} ${KMACHINE}-${LINUX_KERNEL_TYPE}
+}
+
+
+# Ensure that the branches (BSP and meta) are on the locatios specified by
+# their SRCREV values. If they are NOT on the right commits, the branches
+# are reset to the correct commit.
+do_validate_branches() {
+ cd ${S}
+ branch_head=`git show-ref -s --heads ${KBRANCH}`
+ meta_head=`git show-ref -s --heads ${KMETA}`
+ target_branch_head="${SRCREV_machine}"
+ target_meta_head="${SRCREV_meta}"
+
+ # nothing to do if bootstrapping
+ if [ -n "${BOOTSTRAP}" ]; then
+ return
+ fi
+
+ if [ -n "$target_branch_head" ]&& [ "$branch_head" != "$target_branch_head" ]; then
+ if [ -n "${KERNEL_REVISION_CHECKING}" ]; then
+ git show ${target_branch_head}> /dev/null 2>&1
+ if [ $? -eq 0 ]; then
+ echo "Forcing branch ${KMACHINE}-${LINUX_KERNEL_TYPE} to ${target_branch_head}"
+ git branch -m ${KMACHINE}-${LINUX_KERNEL_TYPE} ${KMACHINE}-${LINUX_KERNEL_TYPE}-orig
+ git checkout -b ${KMACHINE}-${LINUX_KERNEL_TYPE} ${target_branch_head}
+ else
+ echo "ERROR ${target_branch_head} is not a valid commit ID."
+ echo "The kernel source tree may be out of sync"
+ exit 1
+ fi
+ fi
+ fi
+
+ if [ "$meta_head" != "$target_meta_head" ]; then
+ if [ -n "${KERNEL_REVISION_CHECKING}" ]; then
+ git show ${target_meta_head}> /dev/null 2>&1
+ if [ $? -eq 0 ]; then
+ echo "Forcing branch meta to ${target_meta_head}"
+ git branch -m meta meta-orig
+ git checkout -b meta ${target_meta_head}
+ else
+ echo "ERROR ${target_meta_head} is not a valid commit ID"
+ echo "The kernel source tree may be out of sync"
+ exit 1
+ fi
+ fi
+ fi
+
+ # restore the branch for builds
+ git checkout -f ${KBRANCH}
+}
+
+# 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
+}
+
+
diff --git a/meta/conf/distro/include/poky-default-revisions.inc b/meta/conf/distro/include/poky-default-revisions.inc
index 7f3468d..0ec7a3a 100644
--- a/meta/conf/distro/include/poky-default-revisions.inc
+++ b/meta/conf/distro/include/poky-default-revisions.inc
@@ -56,7 +56,7 @@ SRCREV_pn-gypsy ??= "147"
SRCREV_pn-inputproto ??= "7203036522ba9d4b224d282d6afc2d0b947711ee"
SRCREV_pn-inputproto-native ??= "7203036522ba9d4b224d282d6afc2d0b947711ee"
SRCREV_pn-inputproto-nativesdk ??= "7203036522ba9d4b224d282d6afc2d0b947711ee"
-SRCREV_pn-kern-tools-native ??= "9722d8decacd2b750f079b3fde7918810700f80e"
+SRCREV_pn-kern-tools-native ??= "c85dcdd2dc50d71476a11c2960bf14c2b144b3c7"
SRCREV_pn-libdrm ??= "3f3c5be6f908272199ccf53f108b1124bfe0a00e"
SRCREV_pn-libfakekey ??= "2031"
SRCREV_pn-libgdbus ??= "aeab6e3c0185b271ca343b439470491b99cc587f"
diff --git a/meta/conf/machine/atom-pc.conf b/meta/conf/machine/atom-pc.conf
index 7ca952a..8cf09b8 100644
--- a/meta/conf/machine/atom-pc.conf
+++ b/meta/conf/machine/atom-pc.conf
@@ -13,7 +13,8 @@ MACHINE_FEATURES = "kernel26 screen keyboard pci usbhost ext2 ext3 x86 wifi \

KERNEL_IMAGETYPE = "bzImage"

-PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto-stable"
+#PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"
PREFERRED_PROVIDER_virtual/libx11 ?= "libx11-trim"
PREFERRED_PROVIDER_virtual/libgl ?= "mesa-dri"
PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xf86-dri-lite"
diff --git a/meta/conf/machine/beagleboard.conf b/meta/conf/machine/beagleboard.conf
index 657bd36..1b73250 100644
--- a/meta/conf/machine/beagleboard.conf
+++ b/meta/conf/machine/beagleboard.conf
@@ -22,7 +22,8 @@ EXTRA_IMAGECMD_jffs2 = "-lnp "
# Guesswork
SERIAL_CONSOLE = "115200 ttyS2"

-PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
+PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-stable"
+#PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"

KERNEL_IMAGETYPE = "uImage"

diff --git a/meta/conf/machine/include/qemu.inc b/meta/conf/machine/include/qemu.inc
index 1b1b888..502e24f 100644
--- a/meta/conf/machine/include/qemu.inc
+++ b/meta/conf/machine/include/qemu.inc
@@ -16,5 +16,6 @@ RDEPENDS_kernel-base = ""

# Use a common kernel recipe for all QEMU machines
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
+#PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"

EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
diff --git a/meta/conf/machine/mpc8315e-rdb.conf b/meta/conf/machine/mpc8315e-rdb.conf
index 3341186..1b7982a 100644
--- a/meta/conf/machine/mpc8315e-rdb.conf
+++ b/meta/conf/machine/mpc8315e-rdb.conf
@@ -13,4 +13,5 @@ SERIAL_CONSOLE = "115200 ttyS0"

MACHINE_FEATURES = "kernel26 keyboard pci ext2 ext3 serial"

-PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
+PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-stable"
+#PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"
diff --git a/meta/conf/machine/routerstationpro.conf b/meta/conf/machine/routerstationpro.conf
index 485ee3c..4f1bbbb 100644
--- a/meta/conf/machine/routerstationpro.conf
+++ b/meta/conf/machine/routerstationpro.conf
@@ -12,7 +12,8 @@ MACHINE_FEATURES = "kernel26 screen keyboard pci usbhost ext2 ext3 \
KERNEL_IMAGETYPE = "vmlinux"
KERNEL_ALT_IMAGETYPE = "vmlinux.bin"

-PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
+PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-stable"
+#PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"

SERIAL_CONSOLE = "115200 ttyS0"

diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb
index 6ae6d5f..3e3c1fa 100644
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb
@@ -4,7 +4,7 @@ INHIBIT_DEFAULT_DEPS = "1"
DEPENDS += "unifdef-native"
PROVIDES = "linux-libc-headers"
PV = "2.6.34+git-${SRCPV}"
-PR = "r0"
+PR = "r1"

SRC_URI = "git://git.pokylinux.org/linux-2.6-windriver.git;fullclone=1"

@@ -45,7 +45,7 @@ do_compile () {

do_install() {
set_arch
- oe_runmake headers_install_all INSTALL_HDR_PATH=${D}${exec_prefix} ARCH=$ARCH
+ oe_runmake headers_install INSTALL_HDR_PATH=${D}${exec_prefix} ARCH=$ARCH
}

BBCLASSEXTEND = "nativesdk"
diff --git a/meta/recipes-kernel/linux/linux-tools.inc b/meta/recipes-kernel/linux/linux-tools.inc
new file mode 100644
index 0000000..714207f
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-tools.inc
@@ -0,0 +1,19 @@
+# included by kernel recipes if they want to build/provide
+# perf functionality from their tree.
+
+do_compile_perf() {
+ oe_runmake -C ${S}/tools/perf CC="${KERNEL_CC}" LD="${KERNEL_LD}" prefix=${prefix}
+}
+
+do_install_perf() {
+ oe_runmake -C ${S}/tools/perf CC="${KERNEL_CC}" LD="${KERNEL_LD}" prefix=${prefix} DESTDIR=${D} install
+}
+
+
+# perf tasks
+addtask compile_perf after do_compile before do_install
+addtask install_perf after do_install before do_package do_deploy
+
+do_compile_perf[depends] = "virtual/libc:do_populate_sysroot"
+do_compile_perf[depends] =+ "elfutils:do_populate_sysroot"
+RDEPENDS_perf += "python perl elfutils"
diff --git a/meta/recipes-kernel/linux/linux-yocto-stable_git.bb b/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
new file mode 100644
index 0000000..8ecd86f
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
@@ -0,0 +1,41 @@
+inherit kernel
+require linux-yocto.inc
+
+KMACHINE_qemux86 = "common_pc/base"
+KMACHINE_qemux86-64 = "common_pc_64"
+KMACHINE_qemuppc = "qemu_ppc32"
+KMACHINE_qemumips = "mti_malta32_be"
+KMACHINE_qemuarm = "arm_versatile_926ejs"
+KMACHINE_atom-pc = "atom-pc"
+KMACHINE_routerstationpro = "routerstationpro"
+KMACHINE_mpc8315e-rdb = "fsl-mpc8315e-rdb"
+KMACHINE_beagleboard = "beagleboard"
+
+LINUX_VERSION ?= "2.6.34"
+LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"
+PR = "r0"
+PV = "${LINUX_VERSION}+git${SRCPV}"
+SRCREV_FORMAT = "meta_machine"
+
+# this performs a fixup on the SRCREV for new/undefined BSPs
+python __anonymous () {
+ import bb, re
+
+ rev = bb.data.getVar("SRCREV_machine", d, 1)
+ if rev == "standard":
+ bb.data.setVar("SRCREV_machine", "${SRCREV_meta}", d)
+}
+
+SRC_URI = "git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;fullclone=1;branch=${KBRANCH};name=machine \
+ git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;noclone=1;branch=wrs_meta;name=meta"
+
+
+# Functionality flags
+KERNEL_REVISION_CHECKING ?= "t"
+KERNEL_FEATURES=features/netfilter
+
+# extra tasks
+addtask kernel_link_vmlinux after do_compile before do_install
+addtask validate_branches before do_patch after do_kernel_checkout
+
+require linux-tools.inc
diff --git a/meta/recipes-kernel/linux/linux-yocto.inc b/meta/recipes-kernel/linux/linux-yocto.inc
new file mode 100644
index 0000000..095b337
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -0,0 +1,23 @@
+DESCRIPTION = "Yocto Kernel"
+SECTION = "kernel"
+LICENSE = "GPL"
+
+# A KMACHINE is the mapping of a yocto $MACHINE to what is built
+# by the kernel. This is typically the branch that should be built,
+# and it can be specific to the machine or shared
+KMACHINE = "UNDEFINED"
+
+COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemux86-64|atom-pc|routerstationpro)"
+
+# Set this to 'preempt_rt' in the local.conf if you want a real time kernel
+LINUX_KERNEL_TYPE ?= standard
+
+do_patch[depends] = "kern-tools-native:do_populate_sysroot"
+
+addtask kernel_configme before do_configure after do_patch
+addtask kernel_configcheck after do_configure before do_compile
+
+# Pick up shared functions
+inherit kernel-yocto
+
+B = "${WORKDIR}/linux-${KMACHINE}-${LINUX_KERNEL_TYPE}-build"
diff --git a/meta/recipes-kernel/linux/linux-yocto_git.bb b/meta/recipes-kernel/linux/linux-yocto_git.bb
index ef005ae..db2e90b 100644
--- a/meta/recipes-kernel/linux/linux-yocto_git.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_git.bb
@@ -1,21 +1,7 @@
-DESCRIPTION = "Yocto Kernel"
-SECTION = "kernel"
-LICENSE = "GPL"
-
-# Set this to 'preempt_rt' in the local.conf if you want a real time kernel
-LINUX_KERNEL_TYPE ?= standard
-SRCREV_FORMAT = "meta_machine"
-PV = "2.6.34+git${SRCPV}"
-
-# To use a staged, on-disk bare clone of a Wind River Kernel, use a
-# variant of the below
-# SRC_URI = "git://///path/to/kernel/default_kernel.git;fullclone=1"
-SRC_URI = "git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;fullclone=1;branch=${KBRANCH};name=machine \
- git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;noclone=1;branch=wrs_meta;name=meta"
+inherit kernel
+require linux-yocto.inc

-# map the poky machine to a 'kernel machine'
-KMACHINE = "UNDEFINED"
-KMACHINE_qemux86 = "common_pc"
+KMACHINE_qemux86 = "common_pc/base"
KMACHINE_qemux86-64 = "common_pc_64"
KMACHINE_qemuppc = "qemu_ppc32"
KMACHINE_qemumips = "mti_malta32_be"
@@ -25,199 +11,45 @@ KMACHINE_routerstationpro = "routerstationpro"
KMACHINE_mpc8315e-rdb = "fsl-mpc8315e-rdb"
KMACHINE_beagleboard = "beagleboard"

-# Determine which branch to fetch and build. Not all branches are in the
-# upstream repo (but will be locally created after the fetchers run) so
-# a fallback branch needs to be chosen.
-#
-# The default machine 'UNDEFINED'. If the machine is not set to a specific
-# branch in this recipe or in a recipe extension, then we fallback to a
-# branch that is always present 'standard'. This sets the KBRANCH variable
-# and is used in the SRC_URI. The machine is then set back to ${MACHINE},
-# since futher processing will use that to create local branches
+# Holding area for board REVs until the full switch to this
+# recipe is complete
+SRCREV_machine_pn-linux-yocto_qemuarm = "87e00a2d47ba80b4ad1f9170cb3f6cf81f21d739"
+SRCREV_machine_pn-linux-yocto_qemumips = "7231e473dd981a28e3cea9f677ed60583e731550"
+SRCREV_machine_pn-linux-yocto_qemuppc = "3ab3559637130b65d8889fa74286fdb57935726f"
+SRCREV_machine_pn-linux-yocto_qemux86 = "87aacc373557f8849dde8618fbe1f7f8f2af6038"
+SRCREV_machine_pn-linux-yocto_qemux86-64 = "87aacc373557f8849dde8618fbe1f7f8f2af6038"
+SRCREV_machine_pn-linux-yocto_emenlow = "87aacc373557f8849dde8618fbe1f7f8f2af6038"
+SRCREV_machine_pn-linux-yocto_atom-pc = "87aacc373557f8849dde8618fbe1f7f8f2af6038"
+SRCREV_machine_pn-linux-yocto_routerstationpro = "773d3a1c8eba563ffcdbf61057ef6e39cee0c88b"
+SRCREV_machine_pn-linux-yocto_mpc8315e-rdb = "5ff609967ffe87c49d534d7861a7e0b150517726"
+SRCREV_machine_pn-linux-yocto_beagleboard = "87aacc373557f8849dde8618fbe1f7f8f2af6038"
+SRCREV_meta_pn-linux-yocto = "ee0a10ab687b29c4d22d47e5b28bc8b3ebb7a8d9"
+
+LINUX_VERSION ?= "2.6.37"
+LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"
+PR = "r14"
+PV = "${LINUX_VERSION}+git${SRCPV}"
+SRCREV_FORMAT = "meta_machine"
+
+# this performs a fixup on the SRCREV for new/undefined BSPs
python __anonymous () {
import bb, re

- bb.data.setVar("KBRANCH", "${KMACHINE}-${LINUX_KERNEL_TYPE}", d)
- mach = bb.data.getVar("KMACHINE", d, 1)
- if mach == "UNDEFINED":
- bb.data.setVar("KBRANCH", "standard", d)
- bb.data.setVar("KMACHINE", "${MACHINE}", d)
- # track the global configuration on a bootstrapped BSP
+ rev = bb.data.getVar("SRCREV_machine", d, 1)
+ if rev == "standard":
bb.data.setVar("SRCREV_machine", "${SRCREV_meta}", d)
- bb.data.setVar("BOOTSTRAP", "t", d)
}

-COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemux86-64|atom-pc|routerstationpro|mpc8315e-rdb|beagleboard)"
-
-LINUX_VERSION = "v2.6.34"
-LINUX_VERSION_EXTENSION = "-wr-${LINUX_KERNEL_TYPE}"
-PR = "r13"
+SRC_URI = "git://git.pokylinux.org/linux-yocto-2.6.37;protocol=git;fullclone=1;branch=${KBRANCH};name=machine \
+ git://git.pokylinux.org/linux-yocto-2.6.37;protocol=git;noclone=1;branch=meta;name=meta"

-S = "${WORKDIR}/linux"
-B = "${WORKDIR}/linux-${KMACHINE}-${LINUX_KERNEL_TYPE}-build"

-# functionality flags
+# Functionality flags
KERNEL_REVISION_CHECKING ?= "t"
KERNEL_FEATURES=features/netfilter

-do_patch() {
- cd ${S}
- if [ -f ${WORKDIR}/defconfig ]; then
- defconfig=${WORKDIR}/defconfig
- fi
-
- # simply ensures that a branch of the right name has been created
- createme ${ARCH} ${KMACHINE}-${LINUX_KERNEL_TYPE} ${defconfig}
- if [ $? -ne 0 ]; then
- echo "ERROR. Could not create ${KMACHINE}-${LINUX_KERNEL_TYPE}"
- exit 1
- fi
-
- # updates or generates the target description
- if [ -n "${KERNEL_FEATURES}" ]; then
- addon_features="--features ${KERNEL_FEATURES}"
- fi
- updateme ${addon_features} ${ARCH} ${WORKDIR}
- if [ $? -ne 0 ]; then
- echo "ERROR. Could not update ${KMACHINE}-${LINUX_KERNEL_TYPE}"
- exit 1
- fi
-
- # executes and modifies the source tree as required
- patchme ${KMACHINE}-${LINUX_KERNEL_TYPE}
- if [ $? -ne 0 ]; then
- echo "ERROR. Could not modify ${KMACHINE}-${LINUX_KERNEL_TYPE}"
- exit 1
- fi
-}
-
-validate_branches() {
- branch_head=`git show-ref -s --heads ${KBRANCH}`
- meta_head=`git show-ref -s --heads wrs_meta`
- target_branch_head="${SRCREV_machine}"
- target_meta_head="${SRCREV_meta}"
-
- if [ -n "$target_branch_head" ]&& [ "$branch_head" != "$target_branch_head" ]; then
- if [ -n "${KERNEL_REVISION_CHECKING}" ]; then
- git show ${target_branch_head}> /dev/null 2>&1
- if [ $? -eq 0 ]; then
- echo "Forcing branch ${KMACHINE}-${LINUX_KERNEL_TYPE} to ${target_branch_head}"
- git branch -m ${KMACHINE}-${LINUX_KERNEL_TYPE} ${KMACHINE}-${LINUX_KERNEL_TYPE}-orig
- git checkout -b ${KMACHINE}-${LINUX_KERNEL_TYPE} ${target_branch_head}
- else
- echo "ERROR ${target_branch_head} is not a valid commit ID."
- echo "The kernel source tree may be out of sync"
- exit 1
- fi
- fi
- fi
-
- if [ "$meta_head" != "$target_meta_head" ]; then
- if [ -n "${KERNEL_REVISION_CHECKING}" ]; then
- git show ${target_meta_head}> /dev/null 2>&1
- if [ $? -eq 0 ]; then
- echo "Forcing branch wrs_meta to ${target_meta_head}"
- git branch -m wrs_meta wrs_meta-orig
- git checkout -b wrs_meta ${target_meta_head}
- else
- echo "ERROR ${target_meta_head} is not a valid commit ID"
- echo "The kernel source tree may be out of sync"
- exit 1
- fi
- fi
- fi
-}
-
-do_kernel_checkout() {
- if [ -d ${WORKDIR}/.git/refs/remotes/origin ]; then
- echo "Fixing up git directory for ${KMACHINE}-${LINUX_KERNEL_TYPE}"
- rm -rf ${S}
- mkdir ${S}
- mv ${WORKDIR}/.git ${S}
-
- if [ -e ${S}/.git/packed-refs ]; then
- cd ${S}
- rm -f .git/refs/remotes/origin/HEAD
-IFS='
-';
-
- for r in `git show-ref | grep remotes`; do
- ref=`echo $r | cut -d' ' -f1`;
- b=`echo $r | cut -d'/' -f4`;
- echo $ref> .git/refs/heads/$b
- done
- cd ..
- else
- mv ${S}/.git/refs/remotes/origin/* ${S}/.git/refs/heads
- rmdir ${S}/.git/refs/remotes/origin
- fi
- fi
- cd ${S}
-
- # checkout and clobber and unimportant files
- git checkout -f ${KBRANCH}
-
- if [ -z "${BOOTSTRAP}" ]; then
- validate_branches
- fi
-
- # this second checkout is intentional, we want to leave ourselves
- # on the branch to be built, but validate_branches could have changed
- # our initial checkout. So we do it a second time to be sure
- git checkout -f ${KBRANCH}
-}
-do_kernel_checkout[dirs] = "${S}"
-
-addtask kernel_checkout before do_patch after do_unpack
-
-do_kernel_configme() {
- echo "Doing kernel configme"
-
- cd ${S}
- configme --reconfig
- if [ $? -ne 0 ]; then
- echo "ERROR. Could not configure ${KMACHINE}-${LINUX_KERNEL_TYPE}"
- exit 1
- fi
-
- echo "# CONFIG_WRNOTE is not set">> ${B}/.config
- echo "# Global settings from linux recipe">> ${B}/.config
- echo "CONFIG_LOCALVERSION="\"${LINUX_VERSION_EXTENSION}\">> ${B}/.config
-}
-
-do_kernel_configcheck() {
- echo "[INFO] validating kernel configuration"
- cd ${B}/..
- kconf_check ${B}/.config ${B} ${S} ${B} ${LINUX_VERSION} ${KMACHINE}-${LINUX_KERNEL_TYPE}
-}
-
-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
-}
-
-do_compile_perf() {
- oe_runmake -C ${S}/tools/perf CC="${KERNEL_CC}" LD="${KERNEL_LD}" prefix=${prefix}
-}
-
-do_install_perf() {
- oe_runmake -C ${S}/tools/perf CC="${KERNEL_CC}" LD="${KERNEL_LD}" prefix=${prefix} DESTDIR=${D} install
-}
-
-do_patch[depends] = "kern-tools-native:do_populate_sysroot"
-addtask kernel_configme before do_configure after do_patch
+# extra tasks
addtask kernel_link_vmlinux after do_compile before do_install
-addtask kernel_configcheck after do_configure before do_compile
-
-inherit kernel
-
-# perf tasks
-addtask compile_perf after do_compile before do_install
-addtask install_perf after do_install before do_package do_deploy
+addtask validate_branches before do_patch after do_kernel_checkout

-do_compile_perf[depends] = "virtual/libc:do_populate_sysroot"
-do_compile_perf[depends] =+ "elfutils:do_populate_sysroot"
-RDEPENDS_perf += "python perl elfutils"
+require linux-tools.inc

On 10-12-08 09:35 AM, Bruce Ashfield wrote:

Richard,

FYI: Darren pointed out that these should go to poky@
as well, so any follow ups will go to both lists. Sorry
about the initial miss!

Cheers,

Bruce

Consider these patches for merging. I've been building and working
with these for 2 weeks now, and while they aren't perfect, they
work and we need more eyes on 2.6.37.

What we get is the following:

- factoring of the code into some reusable routines in the form
of a linux-yocto bbclass. The -stable, -devel and libc headers
recipes are all using this common code

- A new branching scheme for the 2.6.37 kernel that generalizes
the branch names and shows their hierarchy. The tools that
process the kernel needed a lot of 'unlearning' about the
old structure (this took a lot of my time working on this).

If this needs to be tweaked more, we can do it later, since
the big changes are done and agreed on, and we can't delay
scaling this out to more boards much longer.

- A -stable recipe that continues to build the 2.6.34 kernel
and a move of the main recipe to track the development
2.6.37-rc5 tree. The qemu* targets have their defaults
changed to 2.6.37-rc, while the hardware targets remain
on 2.6.34 for a bit longer. To ease the switch over, I
put the SRCREVs for 2.6.37 into the recipe itself. We
can move these as .37 becomes the default.

- perf is moved into a linux-tools.inc, we can add more to
this and re-use it more easily from here

- BSP boostrapping is streamlined (docs to follow).

The temporary commenting of the preferred libc-headers provider
was intentional. There is something strange happening when
headers are generated for 2.6.34 that was breaking libc builds.
To avoid holding up this series, we'll go with the default
libc headers for a short while.

I've built and booted all the qemu* targets on 2.6.37
(minimal and sato), I've built most of the hardware
targets. I noticed some strangeness with the mouse on
ARM, and that will need to be looked at further. I've done
some audits on the kernel configuration in 2.6.37, and
while it looks sane, full BSP testing will tell us if
anything major changed (that I missed).

If there are better suggestions on how we can stage and
get mileage on this code, I'm all ears, but this is a kernel
uprev, so I expect some issues (there always is even though
I've done plenty of these). If we don't want anything
destabilizing in the tree, I'm fine with this and we just
need to come up with a plan.

What remains (I'm only one person!):

- BSP porting and full BSP testing
- Investigation into the libc-headers issue
- Continued cleanup
- Feature merging into 2.6.37 (lttng, yaffs, etc)

Pull URL: git://git.pokylinux.org/poky-contrib.git
Branch: zedd/kernel
Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Thanks,
Bruce Ashfield<bruce.ashfield@...>
---


Bruce Ashfield (3):
yocto-kernel: factor common routes, update to 2.6.37 and branch
renaming
linux-libc-headers-yocto: use common linux-yocto routines
qemu: update arm timer handling

meta-emenlow/conf/machine/emenlow.conf | 3 +-
meta/classes/kernel-yocto.bbclass | 202 +++++++++++++++++
.../conf/distro/include/poky-default-revisions.inc | 2 +-
meta/conf/machine/atom-pc.conf | 3 +-
meta/conf/machine/beagleboard.conf | 3 +-
meta/conf/machine/include/qemu.inc | 1 +
meta/conf/machine/mpc8315e-rdb.conf | 3 +-
meta/conf/machine/routerstationpro.conf | 3 +-
.../qemu-0.12.4/arm_timer-fix-oneshot-mode.patch | 32 +++
.../arm_timer-reload-timer-when-enabled.patch | 40 ++++
meta/recipes-devtools/qemu/qemu_0.12.4.bb | 4 +-
.../linux-libc-headers-yocto_git.bb | 25 +--
meta/recipes-kernel/linux/linux-tools.inc | 19 ++
.../recipes-kernel/linux/linux-yocto-stable_git.bb | 41 ++++
meta/recipes-kernel/linux/linux-yocto.inc | 23 ++
meta/recipes-kernel/linux/linux-yocto_git.bb | 232 +++-----------------
16 files changed, 415 insertions(+), 221 deletions(-)
create mode 100644 meta/classes/kernel-yocto.bbclass
create mode 100644 meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-fix-oneshot-mode.patch
create mode 100644 meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-reload-timer-when-enabled.patch
create mode 100644 meta/recipes-kernel/linux/linux-tools.inc
create mode 100644 meta/recipes-kernel/linux/linux-yocto-stable_git.bb
create mode 100644 meta/recipes-kernel/linux/linux-yocto.inc

_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto

On 12/08/2010 12:32 AM, Xu, Jiajun wrote:

I wanted to give people a heads up about the addition of a few more
targets to the nightly build and how they'll effect the nightly (and our overall efficency).

This bug asks for the addition of a few targets:

arm: beagleboard: poky-image-sato, poky-image-minimal, poky-image-sdk
powerpc: mpc8315e-rdb: poky-image-minimal
mips: routerstationpro: poky-image-minimal

Hi Beth,
Could you also build sdk images for mpc8315e-rdb and routerstationpro? We will have testing for them from M2.

I have a config file with the requested changes in it. Once build #141
is done, I'm move it over to the main config.

-b

On Wed, 2010-12-08 at 08:29 -0800, Kamble, Nitin A wrote:

On Tue, 2010-12-07 at 19:15 -0800, Kamble, Nitin A wrote:

I am getting following bitbake error. I also tried passing –D

option

to bitbake, but I did not find anything useful. Also bellow is the
change which is causing this error.

I don’t see anything oblivious here. As I understand just changing

the

recipe from cvs to git src_uri has caused this issue.

Its probably exactly this change the breaks things. git SRC_URIs have a
dependency on git-native. git-native probably depends on
gnu-config-native indirectly. The end result is a circular dependency.
Bitbake tried to work this out but obviously got lost in the circular
logic.

Thanks Richard for the clarification. So what would be possible
solution for this circular dependency issue? I can check if we can get
the latest gnu-config via cvs. Any other or better solution?

Is there a release tarball we can use? If not, we might end up hosting a
release tarball for it somewhere given this piece of software's position
in the build process.

I'd like to axe our cvs dependency for sure.

Cheers,

Richard

On 12/08/2010 04:49 AM, Richard Purdie wrote:

Hi,

We're in a position where we have people wanting to extend Poky but
wondering exactly how to add their own layer and make Poky useful for
their specific use cases.

This is a topic I want to work with the OE community on and have
discussion about but equally, people are interested at the moment and we
need something people can experiment with now so we can see what works
and what doesn't.

With this in mind I'm proposing we create a "poky-extras" repository
which contains multiple user contributed layers.

My proposed ground rules are:

* it has the OE style open contributions model
* consists of a set of layers, each clearly identified at the top level
* each layer has a clearly named maintainer or maintainers
* people respect the layer maintainers
* layers are split into logical "topics" where at all possible

Ultimately, the repo structure and some of the details could change but
I'd like to experiment and see what we can come up with which is
probably the only way we're going to move forward.

Any comments, objections or better ideas? :)

Sounds like a good approach to me. What would the expectation of "lifecycle" be? Will these layers move to the poky git repository after some proven time to join things like meta-linaro and meta-demo (which should be renamed meta-dlna) or should we move these layers to poky-extras too?

--
Darren Hart
Yocto Linux Kernel

On Tue, 2010-12-07 at 19:15 -0800, Kamble, Nitin A wrote:

I am getting following bitbake error. I also tried passing –D

option

to bitbake, but I did not find anything useful. Also bellow is the
change which is causing this error.

I don’t see anything oblivious here. As I understand just changing

the

recipe from cvs to git src_uri has caused this issue.

Its probably exactly this change the breaks things. git SRC_URIs have a
dependency on git-native. git-native probably depends on
gnu-config-native indirectly. The end result is a circular dependency.
Bitbake tried to work this out but obviously got lost in the circular
logic.

Thanks Richard for the clarification. So what would be possible solution for this circular dependency issue? I can check if we can get the latest gnu-config via cvs. Any other or better solution?

Thanks,
Nitin

commit e388771458b4ff3ad81ab70e390b24d069647da4 in the upstream
kernel factored/cleaned the SP804 timer code. This commit exposed
issues in the qemu timer emulation that was dependent on the
old behaviour. As a result, no kernel past 2.6.34 would boot on
qemu-system-arm.

The quick fix is to backport two patches from the latest qemu
repositories that fix the timer handling under emulation. Long
term, these will be dropped when qemu is upreved.

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
.../qemu-0.12.4/arm_timer-fix-oneshot-mode.patch | 32 ++++++++++++++++
.../arm_timer-reload-timer-when-enabled.patch | 40 ++++++++++++++++++++
meta/recipes-devtools/qemu/qemu_0.12.4.bb | 4 +-
3 files changed, 75 insertions(+), 1 deletions(-)
create mode 100644 meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-fix-oneshot-mode.patch
create mode 100644 meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-reload-timer-when-enabled.patch

diff --git a/meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-fix-oneshot-mode.patch b/meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-fix-oneshot-mode.patch
new file mode 100644
index 0000000..530736c
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-fix-oneshot-mode.patch
@@ -0,0 +1,32 @@
+From a9cf98d939c4f6539fad7e7d812ea16d96ba3dc9 Mon Sep 17 00:00:00 2001
+From: Rabin Vincent <rabin@...>
+Date: Sun, 2 May 2010 15:20:52 +0530
+Subject: [PATCH] arm_timer: fix oneshot mode
+
+commit id: a9cf98d939c4f6539fad7e7d812ea16d96ba3dc9 in git://git.sv.gnu.org/qemu.git
+
+In oneshot mode, the delta needs to come from the TimerLoad register,
+not the maximum limit.
+
+Signed-off-by: Rabin Vincent <rabin@...>
+Signed-off-by: Aurelien Jarno <aurelien@...>
+---
+ hw/arm_timer.c | 2 +-
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+
+diff --git a/hw/arm_timer.c b/hw/arm_timer.c
+index 5b6947a..9073ffc 100644
+--- a/hw/arm_timer.c
++++ b/hw/arm_timer.c
+@@ -71,7 +71,7 @@ static void arm_timer_recalibrate(arm_timer_state *s, int reload)
+ {
+ uint32_t limit;
+
+- if ((s->control & TIMER_CTRL_PERIODIC) == 0) {
++ if ((s->control & (TIMER_CTRL_PERIODIC | TIMER_CTRL_ONESHOT)) == 0) {
+ /* Free running. */
+ if (s->control & TIMER_CTRL_32BIT)
+ limit = 0xffffffff;
+--
+1.6.5.2
+
diff --git a/meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-reload-timer-when-enabled.patch b/meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-reload-timer-when-enabled.patch
new file mode 100644
index 0000000..1890e21
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-reload-timer-when-enabled.patch
@@ -0,0 +1,40 @@
+From d6759902cb467c002086853d2eb38fb969c29f7f Mon Sep 17 00:00:00 2001
+From: Rabin Vincent <rabin@...>
+Date: Sun, 2 May 2010 15:20:51 +0530
+Subject: [PATCH] arm_timer: reload timer when enabled
+
+commit id: d6759902cb467c002086853d2eb38fb969c29f7f in git://git.sv.gnu.org/qemu.git
+
+Reload the timer when TimerControl is written, if the timer is to be
+enabled. Otherwise, if an earlier write to TimerLoad was done while
+periodic mode was not set, s->delta may incorrectly still have the value
+of the maximum limit instead of the value written to TimerLoad.
+
+This problem is evident on versatileap on current linux-next, which
+enables TIMER_CTRL_32BIT before writing to TimerLoad and then enabling
+periodic mode and starting the timer. This causes the first periodic
+tick to be scheduled to occur after 0xffffffff periods, leading to a
+perceived hang while the kernel waits for the first timer tick.
+
+Signed-off-by: Rabin Vincent <rabin@...>
+Signed-off-by: Aurelien Jarno <aurelien@...>
+---
+ hw/arm_timer.c | 2 +-
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+
+diff --git a/hw/arm_timer.c b/hw/arm_timer.c
+index 9fef191..5b6947a 100644
+--- a/hw/arm_timer.c
++++ b/hw/arm_timer.c
+@@ -113,7 +113,7 @@ static void arm_timer_write(void *opaque, target_phys_addr_t offset,
+ case 1: freq >>= 4; break;
+ case 2: freq >>= 8; break;
+ }
+- arm_timer_recalibrate(s, 0);
++ arm_timer_recalibrate(s, s->control & TIMER_CTRL_ENABLE);
+ ptimer_set_freq(s->timer, freq);
+ if (s->control & TIMER_CTRL_ENABLE) {
+ /* Restart the timer if still enabled. */
+--
+1.6.5.2
+
diff --git a/meta/recipes-devtools/qemu/qemu_0.12.4.bb b/meta/recipes-devtools/qemu/qemu_0.12.4.bb
index f52a5ca..03a3638 100644
--- a/meta/recipes-devtools/qemu/qemu_0.12.4.bb
+++ b/meta/recipes-devtools/qemu/qemu_0.12.4.bb
@@ -25,7 +25,9 @@ SRC_URI = "\
file://cursor-shadow-fix.patch \
file://vmware-vga-fifo-rewind.patch \
file://fix-configure-checks.patch \
- file://powerpc_rom.bin"
+ file://powerpc_rom.bin \
+ file://arm_timer-fix-oneshot-mode.patch \
+ file://arm_timer-reload-timer-when-enabled.patch"

do_install_append () {
install -d ${D}${datadir}/qemu
--
1.7.0.4

Modify linux-libc-headers-yocto to use the common linux-yocto
routines, so headers exported to userspace will track the
branches in the yocto kernel git repository.

This commit also switches supported boards to prefer the
yocto libc headers.

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
.../linux-libc-headers-yocto_git.bb | 21 ++++++++-----------
1 files changed, 9 insertions(+), 12 deletions(-)

diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb
index 3e3c1fa..0515233 100644
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb
@@ -1,4 +1,7 @@
require linux-libc-headers.inc
+include recipes-kernel/linux/linux-yocto.inc
+
+B = "${S}"

INHIBIT_DEFAULT_DEPS = "1"
DEPENDS += "unifdef-native"
@@ -8,7 +11,9 @@ PR = "r1"

SRC_URI = "git://git.pokylinux.org/linux-2.6-windriver.git;fullclone=1"

-S = "${WORKDIR}/linux"
+SRCREV_FORMAT = "meta_machine"
+SRC_URI = "git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;fullclone=1;branch=${KBRANCH};name=machine \
+ git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;noclone=1;branch=wrs_meta;name=meta"

set_arch() {
case ${TARGET_ARCH} in
@@ -26,19 +31,11 @@ do_configure() {
oe_runmake allnoconfig ARCH=$ARCH
}

-do_kernel_checkout() {
- if [ -d ${WORKDIR}/.git/refs/remotes/origin ]; then
- rm -rf ${S}
- mkdir ${S}
- mv ${WORKDIR}/.git ${S}
- mv ${S}/.git/refs/remotes/origin/* ${S}/.git/refs/heads
- rmdir ${S}/.git/refs/remotes/origin
- fi
- cd ${S}
- git checkout -f standard
+do_kernel_configme() {
}

-addtask kernel_checkout before do_patch after do_unpack
+do_patch () {
+}

do_compile () {
}
--
1.7.0.4

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@...>
---
meta-emenlow/conf/machine/emenlow.conf | 3 +-
meta/classes/kernel-yocto.bbclass | 202 +++++++++++++++++
.../conf/distro/include/poky-default-revisions.inc | 2 +-
meta/conf/machine/atom-pc.conf | 3 +-
meta/conf/machine/beagleboard.conf | 3 +-
meta/conf/machine/include/qemu.inc | 1 +
meta/conf/machine/mpc8315e-rdb.conf | 3 +-
meta/conf/machine/routerstationpro.conf | 3 +-
.../linux-libc-headers-yocto_git.bb | 4 +-
meta/recipes-kernel/linux/linux-tools.inc | 19 ++
.../recipes-kernel/linux/linux-yocto-stable_git.bb | 41 ++++
meta/recipes-kernel/linux/linux-yocto.inc | 23 ++
meta/recipes-kernel/linux/linux-yocto_git.bb | 232 +++-----------------
13 files changed, 331 insertions(+), 208 deletions(-)
create mode 100644 meta/classes/kernel-yocto.bbclass
create mode 100644 meta/recipes-kernel/linux/linux-tools.inc
create mode 100644 meta/recipes-kernel/linux/linux-yocto-stable_git.bb
create mode 100644 meta/recipes-kernel/linux/linux-yocto.inc

diff --git a/meta-emenlow/conf/machine/emenlow.conf b/meta-emenlow/conf/machine/emenlow.conf
index 0f9ed8a..b8dea64 100644
--- a/meta-emenlow/conf/machine/emenlow.conf
+++ b/meta-emenlow/conf/machine/emenlow.conf
@@ -16,7 +16,8 @@ MACHINE_FEATURES = "kernel26 screen keyboard pci usbhost ext2 ext3 x86 \

KERNEL_IMAGETYPE = "bzImage"

-PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
+PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-stable"
+#PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"
PREFERRED_PROVIDER_libdrm = "libdrm-poulsbo"
PREFERRED_PROVIDER_drm = "libdrm-poulsbo"
PREFERRED_PROVIDER_virtual/libx11 = "libx11-trim"
diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-yocto.bbclass
new file mode 100644
index 0000000..87d06aa
--- /dev/null
+++ b/meta/classes/kernel-yocto.bbclass
@@ -0,0 +1,202 @@
+S = "${WORKDIR}/linux"
+
+# Determine which branch to fetch and build. Not all branches are in the
+# upstream repo (but will be locally created after the fetchers run) so
+# a fallback branch needs to be chosen.
+#
+# The default machine 'UNDEFINED'. If the machine is not set to a specific
+# branch in this recipe or in a recipe extension, then we fallback to a
+# branch that is always present 'standard'. This sets the KBRANCH variable
+# and is used in the SRC_URI. The machine is then set back to ${MACHINE},
+# since futher processing will use that to create local branches
+python __anonymous () {
+ import bb, re
+
+ version = bb.data.getVar("LINUX_VERSION", d, 1)
+ # 2.6.34 signifies the old-style tree, so we need some temporary
+ # conditional processing based on the kernel version.
+ if version == "2.6.34":
+ bb.data.setVar("KBRANCH", "${KMACHINE}-${LINUX_KERNEL_TYPE}", d)
+ bb.data.setVar("KMETA", "wrs_meta", d)
+ mach = bb.data.getVar("KMACHINE", d, 1)
+ if mach == "UNDEFINED":
+ bb.data.setVar("KBRANCH", "standard", d)
+ bb.data.setVar("KMACHINE", "${MACHINE}", d)
+ # track the global configuration on a bootstrapped BSP
+ bb.data.setVar("SRCREV_machine", "${SRCREV_meta}", d)
+ bb.data.setVar("BOOTSTRAP", "t", d)
+
+ else:
+ # The branch for a build is:
+ # yocto/<kernel type>/${KMACHINE} or
+ # yocto/<kernel type>/${KMACHINE}/base
+ bb.data.setVar("KBRANCH", bb.data.expand("yocto/${LINUX_KERNEL_TYPE}/${KMACHINE}",d), d)
+ bb.data.setVar("KMETA", "meta", d)
+
+ mach = bb.data.getVar("KMACHINE", d, 1)
+ # drop the "/base" if it was on the KMACHINE
+ kmachine = mach.replace('/base','')
+ # and then write KMACHINE back
+ bb.data.setVar('KMACHINE_' + bb.data.expand("${MACHINE}",d), kmachine, d)
+
+ if mach == "UNDEFINED":
+ bb.data.setVar("KBRANCH", "yocto/standard/base", d)
+ bb.data.setVar('KMACHINE_' + bb.data.expand("${MACHINE}",d), bb.data.expand("${MACHINE}",d), d)
+ bb.data.setVar("SRCREV_machine", "standard", d)
+ bb.data.setVar("BOOTSTRAP", "t", d)
+}
+
+do_patch() {
+ cd ${S}
+ if [ -f ${WORKDIR}/defconfig ]; then
+ defconfig=${WORKDIR}/defconfig
+ fi
+
+ if [ -n "${BOOTSTRAP}" ]; then
+ kbranch="yocto/${LINUX_KERNEL_TYPE}/${KMACHINE}"
+ else
+ kbranch=${KBRANCH}
+ fi
+
+ # simply ensures that a branch of the right name has been created
+ createme ${ARCH} ${kbranch} ${defconfig}
+ if [ $? -ne 0 ]; then
+ echo "ERROR. Could not create ${kbranch}"
+ exit 1
+ fi
+
+ # updates or generates the target description
+ if [ -n "${KERNEL_FEATURES}" ]; then
+ addon_features="--features ${KERNEL_FEATURES}"
+ fi
+ updateme ${addon_features} ${ARCH} ${WORKDIR}
+ if [ $? -ne 0 ]; then
+ echo "ERROR. Could not update ${kbranch}"
+ exit 1
+ fi
+
+ # executes and modifies the source tree as required
+ patchme ${kbranch}
+ if [ $? -ne 0 ]; then
+ echo "ERROR. Could not modify ${kbranch}"
+ exit 1
+ fi
+}
+
+do_kernel_checkout() {
+ if [ -d ${WORKDIR}/.git/refs/remotes/origin ]; then
+ echo "Fixing up git directory for ${LINUX_KERNEL_TYPE}/${KMACHINE}"
+ rm -rf ${S}
+ mkdir ${S}
+ mv ${WORKDIR}/.git ${S}
+
+ if [ -e ${S}/.git/packed-refs ]; then
+ cd ${S}
+ rm -f .git/refs/remotes/origin/HEAD
+IFS='
+';
+ for r in `git show-ref | grep remotes`; do
+ ref=`echo $r | cut -d' ' -f1`;
+ b=`echo $r | cut -d' ' -f2 | sed 's%refs/remotes/origin/%%'`;
+ dir=`dirname $b`
+ mkdir -p .git/refs/heads/$dir
+ echo $ref > .git/refs/heads/$b
+ done
+ cd ..
+ else
+ cp -r ${S}/.git/refs/remotes/origin/* ${S}/.git/refs/heads
+ rmdir ${S}/.git/refs/remotes/origin
+ fi
+ fi
+ cd ${S}
+
+ # checkout and clobber and unimportant files
+ git checkout -f ${KBRANCH}
+}
+do_kernel_checkout[dirs] = "${S}"
+
+addtask kernel_checkout before do_patch after do_unpack
+
+do_kernel_configme() {
+ echo "[INFO] doing kernel configme"
+
+ cd ${S}
+ configme --reconfig
+ if [ $? -ne 0 ]; then
+ echo "ERROR. Could not configure ${KMACHINE}-${LINUX_KERNEL_TYPE}"
+ exit 1
+ fi
+
+ echo "# Global settings from linux recipe" >> ${B}/.config
+ echo "CONFIG_LOCALVERSION="\"${LINUX_VERSION_EXTENSION}\" >> ${B}/.config
+}
+
+do_kernel_configcheck() {
+ echo "[INFO] validating kernel configuration"
+ cd ${B}/..
+ kconf_check ${B}/.config ${B} ${S} ${B} ${LINUX_VERSION} ${KMACHINE}-${LINUX_KERNEL_TYPE}
+}
+
+
+# Ensure that the branches (BSP and meta) are on the locatios specified by
+# their SRCREV values. If they are NOT on the right commits, the branches
+# are reset to the correct commit.
+do_validate_branches() {
+ cd ${S}
+ branch_head=`git show-ref -s --heads ${KBRANCH}`
+ meta_head=`git show-ref -s --heads ${KMETA}`
+ target_branch_head="${SRCREV_machine}"
+ target_meta_head="${SRCREV_meta}"
+
+ # nothing to do if bootstrapping
+ if [ -n "${BOOTSTRAP}" ]; then
+ return
+ fi
+
+ if [ -n "$target_branch_head" ] && [ "$branch_head" != "$target_branch_head" ]; then
+ if [ -n "${KERNEL_REVISION_CHECKING}" ]; then
+ git show ${target_branch_head} > /dev/null 2>&1
+ if [ $? -eq 0 ]; then
+ echo "Forcing branch ${KMACHINE}-${LINUX_KERNEL_TYPE} to ${target_branch_head}"
+ git branch -m ${KMACHINE}-${LINUX_KERNEL_TYPE} ${KMACHINE}-${LINUX_KERNEL_TYPE}-orig
+ git checkout -b ${KMACHINE}-${LINUX_KERNEL_TYPE} ${target_branch_head}
+ else
+ echo "ERROR ${target_branch_head} is not a valid commit ID."
+ echo "The kernel source tree may be out of sync"
+ exit 1
+ fi
+ fi
+ fi
+
+ if [ "$meta_head" != "$target_meta_head" ]; then
+ if [ -n "${KERNEL_REVISION_CHECKING}" ]; then
+ git show ${target_meta_head} > /dev/null 2>&1
+ if [ $? -eq 0 ]; then
+ echo "Forcing branch meta to ${target_meta_head}"
+ git branch -m meta meta-orig
+ git checkout -b meta ${target_meta_head}
+ else
+ echo "ERROR ${target_meta_head} is not a valid commit ID"
+ echo "The kernel source tree may be out of sync"
+ exit 1
+ fi
+ fi
+ fi
+
+ # restore the branch for builds
+ git checkout -f ${KBRANCH}
+}
+
+# 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
+}
+
+
diff --git a/meta/conf/distro/include/poky-default-revisions.inc b/meta/conf/distro/include/poky-default-revisions.inc
index 7f3468d..0ec7a3a 100644
--- a/meta/conf/distro/include/poky-default-revisions.inc
+++ b/meta/conf/distro/include/poky-default-revisions.inc
@@ -56,7 +56,7 @@ SRCREV_pn-gypsy ??= "147"
SRCREV_pn-inputproto ??= "7203036522ba9d4b224d282d6afc2d0b947711ee"
SRCREV_pn-inputproto-native ??= "7203036522ba9d4b224d282d6afc2d0b947711ee"
SRCREV_pn-inputproto-nativesdk ??= "7203036522ba9d4b224d282d6afc2d0b947711ee"
-SRCREV_pn-kern-tools-native ??= "9722d8decacd2b750f079b3fde7918810700f80e"
+SRCREV_pn-kern-tools-native ??= "c85dcdd2dc50d71476a11c2960bf14c2b144b3c7"
SRCREV_pn-libdrm ??= "3f3c5be6f908272199ccf53f108b1124bfe0a00e"
SRCREV_pn-libfakekey ??= "2031"
SRCREV_pn-libgdbus ??= "aeab6e3c0185b271ca343b439470491b99cc587f"
diff --git a/meta/conf/machine/atom-pc.conf b/meta/conf/machine/atom-pc.conf
index 7ca952a..8cf09b8 100644
--- a/meta/conf/machine/atom-pc.conf
+++ b/meta/conf/machine/atom-pc.conf
@@ -13,7 +13,8 @@ MACHINE_FEATURES = "kernel26 screen keyboard pci usbhost ext2 ext3 x86 wifi \

KERNEL_IMAGETYPE = "bzImage"

-PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto-stable"
+#PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"
PREFERRED_PROVIDER_virtual/libx11 ?= "libx11-trim"
PREFERRED_PROVIDER_virtual/libgl ?= "mesa-dri"
PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xf86-dri-lite"
diff --git a/meta/conf/machine/beagleboard.conf b/meta/conf/machine/beagleboard.conf
index 657bd36..1b73250 100644
--- a/meta/conf/machine/beagleboard.conf
+++ b/meta/conf/machine/beagleboard.conf
@@ -22,7 +22,8 @@ EXTRA_IMAGECMD_jffs2 = "-lnp "
# Guesswork
SERIAL_CONSOLE = "115200 ttyS2"

-PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
+PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-stable"
+#PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"

KERNEL_IMAGETYPE = "uImage"

diff --git a/meta/conf/machine/include/qemu.inc b/meta/conf/machine/include/qemu.inc
index 1b1b888..502e24f 100644
--- a/meta/conf/machine/include/qemu.inc
+++ b/meta/conf/machine/include/qemu.inc
@@ -16,5 +16,6 @@ RDEPENDS_kernel-base = ""

# Use a common kernel recipe for all QEMU machines
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
+#PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"

EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
diff --git a/meta/conf/machine/mpc8315e-rdb.conf b/meta/conf/machine/mpc8315e-rdb.conf
index 3341186..1b7982a 100644
--- a/meta/conf/machine/mpc8315e-rdb.conf
+++ b/meta/conf/machine/mpc8315e-rdb.conf
@@ -13,4 +13,5 @@ SERIAL_CONSOLE = "115200 ttyS0"

MACHINE_FEATURES = "kernel26 keyboard pci ext2 ext3 serial"

-PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
+PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-stable"
+#PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"
diff --git a/meta/conf/machine/routerstationpro.conf b/meta/conf/machine/routerstationpro.conf
index 485ee3c..4f1bbbb 100644
--- a/meta/conf/machine/routerstationpro.conf
+++ b/meta/conf/machine/routerstationpro.conf
@@ -12,7 +12,8 @@ MACHINE_FEATURES = "kernel26 screen keyboard pci usbhost ext2 ext3 \
KERNEL_IMAGETYPE = "vmlinux"
KERNEL_ALT_IMAGETYPE = "vmlinux.bin"

-PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
+PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-stable"
+#PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"

SERIAL_CONSOLE = "115200 ttyS0"

diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb
index 6ae6d5f..3e3c1fa 100644
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb
@@ -4,7 +4,7 @@ INHIBIT_DEFAULT_DEPS = "1"
DEPENDS += "unifdef-native"
PROVIDES = "linux-libc-headers"
PV = "2.6.34+git-${SRCPV}"
-PR = "r0"
+PR = "r1"

SRC_URI = "git://git.pokylinux.org/linux-2.6-windriver.git;fullclone=1"

@@ -45,7 +45,7 @@ do_compile () {

do_install() {
set_arch
- oe_runmake headers_install_all INSTALL_HDR_PATH=${D}${exec_prefix} ARCH=$ARCH
+ oe_runmake headers_install INSTALL_HDR_PATH=${D}${exec_prefix} ARCH=$ARCH
}

BBCLASSEXTEND = "nativesdk"
diff --git a/meta/recipes-kernel/linux/linux-tools.inc b/meta/recipes-kernel/linux/linux-tools.inc
new file mode 100644
index 0000000..714207f
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-tools.inc
@@ -0,0 +1,19 @@
+# included by kernel recipes if they want to build/provide
+# perf functionality from their tree.
+
+do_compile_perf() {
+ oe_runmake -C ${S}/tools/perf CC="${KERNEL_CC}" LD="${KERNEL_LD}" prefix=${prefix}
+}
+
+do_install_perf() {
+ oe_runmake -C ${S}/tools/perf CC="${KERNEL_CC}" LD="${KERNEL_LD}" prefix=${prefix} DESTDIR=${D} install
+}
+
+
+# perf tasks
+addtask compile_perf after do_compile before do_install
+addtask install_perf after do_install before do_package do_deploy
+
+do_compile_perf[depends] = "virtual/libc:do_populate_sysroot"
+do_compile_perf[depends] =+ "elfutils:do_populate_sysroot"
+RDEPENDS_perf += "python perl elfutils"
diff --git a/meta/recipes-kernel/linux/linux-yocto-stable_git.bb b/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
new file mode 100644
index 0000000..8ecd86f
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
@@ -0,0 +1,41 @@
+inherit kernel
+require linux-yocto.inc
+
+KMACHINE_qemux86 = "common_pc/base"
+KMACHINE_qemux86-64 = "common_pc_64"
+KMACHINE_qemuppc = "qemu_ppc32"
+KMACHINE_qemumips = "mti_malta32_be"
+KMACHINE_qemuarm = "arm_versatile_926ejs"
+KMACHINE_atom-pc = "atom-pc"
+KMACHINE_routerstationpro = "routerstationpro"
+KMACHINE_mpc8315e-rdb = "fsl-mpc8315e-rdb"
+KMACHINE_beagleboard = "beagleboard"
+
+LINUX_VERSION ?= "2.6.34"
+LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"
+PR = "r0"
+PV = "${LINUX_VERSION}+git${SRCPV}"
+SRCREV_FORMAT = "meta_machine"
+
+# this performs a fixup on the SRCREV for new/undefined BSPs
+python __anonymous () {
+ import bb, re
+
+ rev = bb.data.getVar("SRCREV_machine", d, 1)
+ if rev == "standard":
+ bb.data.setVar("SRCREV_machine", "${SRCREV_meta}", d)
+}
+
+SRC_URI = "git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;fullclone=1;branch=${KBRANCH};name=machine \
+ git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;noclone=1;branch=wrs_meta;name=meta"
+
+
+# Functionality flags
+KERNEL_REVISION_CHECKING ?= "t"
+KERNEL_FEATURES=features/netfilter
+
+# extra tasks
+addtask kernel_link_vmlinux after do_compile before do_install
+addtask validate_branches before do_patch after do_kernel_checkout
+
+require linux-tools.inc
diff --git a/meta/recipes-kernel/linux/linux-yocto.inc b/meta/recipes-kernel/linux/linux-yocto.inc
new file mode 100644
index 0000000..095b337
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -0,0 +1,23 @@
+DESCRIPTION = "Yocto Kernel"
+SECTION = "kernel"
+LICENSE = "GPL"
+
+# A KMACHINE is the mapping of a yocto $MACHINE to what is built
+# by the kernel. This is typically the branch that should be built,
+# and it can be specific to the machine or shared
+KMACHINE = "UNDEFINED"
+
+COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemux86-64|atom-pc|routerstationpro)"
+
+# Set this to 'preempt_rt' in the local.conf if you want a real time kernel
+LINUX_KERNEL_TYPE ?= standard
+
+do_patch[depends] = "kern-tools-native:do_populate_sysroot"
+
+addtask kernel_configme before do_configure after do_patch
+addtask kernel_configcheck after do_configure before do_compile
+
+# Pick up shared functions
+inherit kernel-yocto
+
+B = "${WORKDIR}/linux-${KMACHINE}-${LINUX_KERNEL_TYPE}-build"
diff --git a/meta/recipes-kernel/linux/linux-yocto_git.bb b/meta/recipes-kernel/linux/linux-yocto_git.bb
index ef005ae..db2e90b 100644
--- a/meta/recipes-kernel/linux/linux-yocto_git.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_git.bb
@@ -1,21 +1,7 @@
-DESCRIPTION = "Yocto Kernel"
-SECTION = "kernel"
-LICENSE = "GPL"
-
-# Set this to 'preempt_rt' in the local.conf if you want a real time kernel
-LINUX_KERNEL_TYPE ?= standard
-SRCREV_FORMAT = "meta_machine"
-PV = "2.6.34+git${SRCPV}"
-
-# To use a staged, on-disk bare clone of a Wind River Kernel, use a
-# variant of the below
-# SRC_URI = "git://///path/to/kernel/default_kernel.git;fullclone=1"
-SRC_URI = "git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;fullclone=1;branch=${KBRANCH};name=machine \
- git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;noclone=1;branch=wrs_meta;name=meta"
+inherit kernel
+require linux-yocto.inc

-# map the poky machine to a 'kernel machine'
-KMACHINE = "UNDEFINED"
-KMACHINE_qemux86 = "common_pc"
+KMACHINE_qemux86 = "common_pc/base"
KMACHINE_qemux86-64 = "common_pc_64"
KMACHINE_qemuppc = "qemu_ppc32"
KMACHINE_qemumips = "mti_malta32_be"
@@ -25,199 +11,45 @@ KMACHINE_routerstationpro = "routerstationpro"
KMACHINE_mpc8315e-rdb = "fsl-mpc8315e-rdb"
KMACHINE_beagleboard = "beagleboard"

-# Determine which branch to fetch and build. Not all branches are in the
-# upstream repo (but will be locally created after the fetchers run) so
-# a fallback branch needs to be chosen.
-#
-# The default machine 'UNDEFINED'. If the machine is not set to a specific
-# branch in this recipe or in a recipe extension, then we fallback to a
-# branch that is always present 'standard'. This sets the KBRANCH variable
-# and is used in the SRC_URI. The machine is then set back to ${MACHINE},
-# since futher processing will use that to create local branches
+# Holding area for board REVs until the full switch to this
+# recipe is complete
+SRCREV_machine_pn-linux-yocto_qemuarm = "87e00a2d47ba80b4ad1f9170cb3f6cf81f21d739"
+SRCREV_machine_pn-linux-yocto_qemumips = "7231e473dd981a28e3cea9f677ed60583e731550"
+SRCREV_machine_pn-linux-yocto_qemuppc = "3ab3559637130b65d8889fa74286fdb57935726f"
+SRCREV_machine_pn-linux-yocto_qemux86 = "87aacc373557f8849dde8618fbe1f7f8f2af6038"
+SRCREV_machine_pn-linux-yocto_qemux86-64 = "87aacc373557f8849dde8618fbe1f7f8f2af6038"
+SRCREV_machine_pn-linux-yocto_emenlow = "87aacc373557f8849dde8618fbe1f7f8f2af6038"
+SRCREV_machine_pn-linux-yocto_atom-pc = "87aacc373557f8849dde8618fbe1f7f8f2af6038"
+SRCREV_machine_pn-linux-yocto_routerstationpro = "773d3a1c8eba563ffcdbf61057ef6e39cee0c88b"
+SRCREV_machine_pn-linux-yocto_mpc8315e-rdb = "5ff609967ffe87c49d534d7861a7e0b150517726"
+SRCREV_machine_pn-linux-yocto_beagleboard = "87aacc373557f8849dde8618fbe1f7f8f2af6038"
+SRCREV_meta_pn-linux-yocto = "ee0a10ab687b29c4d22d47e5b28bc8b3ebb7a8d9"
+
+LINUX_VERSION ?= "2.6.37"
+LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"
+PR = "r14"
+PV = "${LINUX_VERSION}+git${SRCPV}"
+SRCREV_FORMAT = "meta_machine"
+
+# this performs a fixup on the SRCREV for new/undefined BSPs
python __anonymous () {
import bb, re

- bb.data.setVar("KBRANCH", "${KMACHINE}-${LINUX_KERNEL_TYPE}", d)
- mach = bb.data.getVar("KMACHINE", d, 1)
- if mach == "UNDEFINED":
- bb.data.setVar("KBRANCH", "standard", d)
- bb.data.setVar("KMACHINE", "${MACHINE}", d)
- # track the global configuration on a bootstrapped BSP
+ rev = bb.data.getVar("SRCREV_machine", d, 1)
+ if rev == "standard":
bb.data.setVar("SRCREV_machine", "${SRCREV_meta}", d)
- bb.data.setVar("BOOTSTRAP", "t", d)
}

-COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemux86-64|atom-pc|routerstationpro|mpc8315e-rdb|beagleboard)"
-
-LINUX_VERSION = "v2.6.34"
-LINUX_VERSION_EXTENSION = "-wr-${LINUX_KERNEL_TYPE}"
-PR = "r13"
+SRC_URI = "git://git.pokylinux.org/linux-yocto-2.6.37;protocol=git;fullclone=1;branch=${KBRANCH};name=machine \
+ git://git.pokylinux.org/linux-yocto-2.6.37;protocol=git;noclone=1;branch=meta;name=meta"

-S = "${WORKDIR}/linux"
-B = "${WORKDIR}/linux-${KMACHINE}-${LINUX_KERNEL_TYPE}-build"

-# functionality flags
+# Functionality flags
KERNEL_REVISION_CHECKING ?= "t"
KERNEL_FEATURES=features/netfilter

-do_patch() {
- cd ${S}
- if [ -f ${WORKDIR}/defconfig ]; then
- defconfig=${WORKDIR}/defconfig
- fi
-
- # simply ensures that a branch of the right name has been created
- createme ${ARCH} ${KMACHINE}-${LINUX_KERNEL_TYPE} ${defconfig}
- if [ $? -ne 0 ]; then
- echo "ERROR. Could not create ${KMACHINE}-${LINUX_KERNEL_TYPE}"
- exit 1
- fi
-
- # updates or generates the target description
- if [ -n "${KERNEL_FEATURES}" ]; then
- addon_features="--features ${KERNEL_FEATURES}"
- fi
- updateme ${addon_features} ${ARCH} ${WORKDIR}
- if [ $? -ne 0 ]; then
- echo "ERROR. Could not update ${KMACHINE}-${LINUX_KERNEL_TYPE}"
- exit 1
- fi
-
- # executes and modifies the source tree as required
- patchme ${KMACHINE}-${LINUX_KERNEL_TYPE}
- if [ $? -ne 0 ]; then
- echo "ERROR. Could not modify ${KMACHINE}-${LINUX_KERNEL_TYPE}"
- exit 1
- fi
-}
-
-validate_branches() {
- branch_head=`git show-ref -s --heads ${KBRANCH}`
- meta_head=`git show-ref -s --heads wrs_meta`
- target_branch_head="${SRCREV_machine}"
- target_meta_head="${SRCREV_meta}"
-
- if [ -n "$target_branch_head" ] && [ "$branch_head" != "$target_branch_head" ]; then
- if [ -n "${KERNEL_REVISION_CHECKING}" ]; then
- git show ${target_branch_head} > /dev/null 2>&1
- if [ $? -eq 0 ]; then
- echo "Forcing branch ${KMACHINE}-${LINUX_KERNEL_TYPE} to ${target_branch_head}"
- git branch -m ${KMACHINE}-${LINUX_KERNEL_TYPE} ${KMACHINE}-${LINUX_KERNEL_TYPE}-orig
- git checkout -b ${KMACHINE}-${LINUX_KERNEL_TYPE} ${target_branch_head}
- else
- echo "ERROR ${target_branch_head} is not a valid commit ID."
- echo "The kernel source tree may be out of sync"
- exit 1
- fi
- fi
- fi
-
- if [ "$meta_head" != "$target_meta_head" ]; then
- if [ -n "${KERNEL_REVISION_CHECKING}" ]; then
- git show ${target_meta_head} > /dev/null 2>&1
- if [ $? -eq 0 ]; then
- echo "Forcing branch wrs_meta to ${target_meta_head}"
- git branch -m wrs_meta wrs_meta-orig
- git checkout -b wrs_meta ${target_meta_head}
- else
- echo "ERROR ${target_meta_head} is not a valid commit ID"
- echo "The kernel source tree may be out of sync"
- exit 1
- fi
- fi
- fi
-}
-
-do_kernel_checkout() {
- if [ -d ${WORKDIR}/.git/refs/remotes/origin ]; then
- echo "Fixing up git directory for ${KMACHINE}-${LINUX_KERNEL_TYPE}"
- rm -rf ${S}
- mkdir ${S}
- mv ${WORKDIR}/.git ${S}
-
- if [ -e ${S}/.git/packed-refs ]; then
- cd ${S}
- rm -f .git/refs/remotes/origin/HEAD
-IFS='
-';
-
- for r in `git show-ref | grep remotes`; do
- ref=`echo $r | cut -d' ' -f1`;
- b=`echo $r | cut -d'/' -f4`;
- echo $ref > .git/refs/heads/$b
- done
- cd ..
- else
- mv ${S}/.git/refs/remotes/origin/* ${S}/.git/refs/heads
- rmdir ${S}/.git/refs/remotes/origin
- fi
- fi
- cd ${S}
-
- # checkout and clobber and unimportant files
- git checkout -f ${KBRANCH}
-
- if [ -z "${BOOTSTRAP}" ]; then
- validate_branches
- fi
-
- # this second checkout is intentional, we want to leave ourselves
- # on the branch to be built, but validate_branches could have changed
- # our initial checkout. So we do it a second time to be sure
- git checkout -f ${KBRANCH}
-}
-do_kernel_checkout[dirs] = "${S}"
-
-addtask kernel_checkout before do_patch after do_unpack
-
-do_kernel_configme() {
- echo "Doing kernel configme"
-
- cd ${S}
- configme --reconfig
- if [ $? -ne 0 ]; then
- echo "ERROR. Could not configure ${KMACHINE}-${LINUX_KERNEL_TYPE}"
- exit 1
- fi
-
- echo "# CONFIG_WRNOTE is not set" >> ${B}/.config
- echo "# Global settings from linux recipe" >> ${B}/.config
- echo "CONFIG_LOCALVERSION="\"${LINUX_VERSION_EXTENSION}\" >> ${B}/.config
-}
-
-do_kernel_configcheck() {
- echo "[INFO] validating kernel configuration"
- cd ${B}/..
- kconf_check ${B}/.config ${B} ${S} ${B} ${LINUX_VERSION} ${KMACHINE}-${LINUX_KERNEL_TYPE}
-}
-
-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
-}
-
-do_compile_perf() {
- oe_runmake -C ${S}/tools/perf CC="${KERNEL_CC}" LD="${KERNEL_LD}" prefix=${prefix}
-}
-
-do_install_perf() {
- oe_runmake -C ${S}/tools/perf CC="${KERNEL_CC}" LD="${KERNEL_LD}" prefix=${prefix} DESTDIR=${D} install
-}
-
-do_patch[depends] = "kern-tools-native:do_populate_sysroot"
-addtask kernel_configme before do_configure after do_patch
+# extra tasks
addtask kernel_link_vmlinux after do_compile before do_install
-addtask kernel_configcheck after do_configure before do_compile
-
-inherit kernel
-
-# perf tasks
-addtask compile_perf after do_compile before do_install
-addtask install_perf after do_install before do_package do_deploy
+addtask validate_branches before do_patch after do_kernel_checkout

-do_compile_perf[depends] = "virtual/libc:do_populate_sysroot"
-do_compile_perf[depends] =+ "elfutils:do_populate_sysroot"
-RDEPENDS_perf += "python perl elfutils"
+require linux-tools.inc
--
1.7.0.4

Richard,

Consider these patches for merging. I've been building and working
with these for 2 weeks now, and while they aren't perfect, they
work and we need more eyes on 2.6.37.

What we get is the following:

- factoring of the code into some reusable routines in the form
of a linux-yocto bbclass. The -stable, -devel and libc headers
recipes are all using this common code

- A new branching scheme for the 2.6.37 kernel that generalizes
the branch names and shows their hierarchy. The tools that
process the kernel needed a lot of 'unlearning' about the
old structure (this took a lot of my time working on this).

If this needs to be tweaked more, we can do it later, since
the big changes are done and agreed on, and we can't delay
scaling this out to more boards much longer.

- A -stable recipe that continues to build the 2.6.34 kernel
and a move of the main recipe to track the development
2.6.37-rc5 tree. The qemu* targets have their defaults
changed to 2.6.37-rc, while the hardware targets remain
on 2.6.34 for a bit longer. To ease the switch over, I
put the SRCREVs for 2.6.37 into the recipe itself. We
can move these as .37 becomes the default.

- perf is moved into a linux-tools.inc, we can add more to
this and re-use it more easily from here

- BSP boostrapping is streamlined (docs to follow).

The temporary commenting of the preferred libc-headers provider
was intentional. There is something strange happening when
headers are generated for 2.6.34 that was breaking libc builds.
To avoid holding up this series, we'll go with the default
libc headers for a short while.

I've built and booted all the qemu* targets on 2.6.37
(minimal and sato), I've built most of the hardware
targets. I noticed some strangeness with the mouse on
ARM, and that will need to be looked at further. I've done
some audits on the kernel configuration in 2.6.37, and
while it looks sane, full BSP testing will tell us if
anything major changed (that I missed).

If there are better suggestions on how we can stage and
get mileage on this code, I'm all ears, but this is a kernel
uprev, so I expect some issues (there always is even though
I've done plenty of these). If we don't want anything
destabilizing in the tree, I'm fine with this and we just
need to come up with a plan.

What remains (I'm only one person!):

- BSP porting and full BSP testing
- Investigation into the libc-headers issue
- Continued cleanup
- Feature merging into 2.6.37 (lttng, yaffs, etc)

Pull URL: git://git.pokylinux.org/poky-contrib.git
Branch: zedd/kernel
Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Thanks,
Bruce Ashfield <bruce.ashfield@...>
---


Bruce Ashfield (3):
yocto-kernel: factor common routes, update to 2.6.37 and branch
renaming
linux-libc-headers-yocto: use common linux-yocto routines
qemu: update arm timer handling

meta-emenlow/conf/machine/emenlow.conf | 3 +-
meta/classes/kernel-yocto.bbclass | 202 +++++++++++++++++
.../conf/distro/include/poky-default-revisions.inc | 2 +-
meta/conf/machine/atom-pc.conf | 3 +-
meta/conf/machine/beagleboard.conf | 3 +-
meta/conf/machine/include/qemu.inc | 1 +
meta/conf/machine/mpc8315e-rdb.conf | 3 +-
meta/conf/machine/routerstationpro.conf | 3 +-
.../qemu-0.12.4/arm_timer-fix-oneshot-mode.patch | 32 +++
.../arm_timer-reload-timer-when-enabled.patch | 40 ++++
meta/recipes-devtools/qemu/qemu_0.12.4.bb | 4 +-
.../linux-libc-headers-yocto_git.bb | 25 +--
meta/recipes-kernel/linux/linux-tools.inc | 19 ++
.../recipes-kernel/linux/linux-yocto-stable_git.bb | 41 ++++
meta/recipes-kernel/linux/linux-yocto.inc | 23 ++
meta/recipes-kernel/linux/linux-yocto_git.bb | 232 +++-----------------
16 files changed, 415 insertions(+), 221 deletions(-)
create mode 100644 meta/classes/kernel-yocto.bbclass
create mode 100644 meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-fix-oneshot-mode.patch
create mode 100644 meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-reload-timer-when-enabled.patch
create mode 100644 meta/recipes-kernel/linux/linux-tools.inc
create mode 100644 meta/recipes-kernel/linux/linux-yocto-stable_git.bb
create mode 100644 meta/recipes-kernel/linux/linux-yocto.inc

On Wed, 2010-12-08 at 07:08 -0700, Chris Larson wrote:

On Wed, Dec 8, 2010 at 5:49 AM, Richard Purdie <rpurdie@...> wrote:

We're in a position where we have people wanting to extend Poky but
wondering exactly how to add their own layer and make Poky useful for
their specific use cases.

This is a topic I want to work with the OE community on and have
discussion about but equally, people are interested at the moment and we
need something people can experiment with now so we can see what works
and what doesn't.

With this in mind I'm proposing we create a "poky-extras" repository
which contains multiple user contributed layers.

My proposed ground rules are:

* it has the OE style open contributions model
* consists of a set of layers, each clearly identified at the top level
* each layer has a clearly named maintainer or maintainers
* people respect the layer maintainers
* layers are split into logical "topics" where at all possible

Ultimately, the repo structure and some of the details could change but
I'd like to experiment and see what we can come up with which is
probably the only way we're going to move forward.

Any comments, objections or better ideas? :)

This seems fine to me as an area to hash out good practices and
experiment, as long as we don't expect to use this structure long
term. It makes sense for the core layers to be in one repo, but it
makes more sense to use one git repository per external layer, imo.
Is that the intent, or am I misunderstanding its purpose?

That is the intent but we don't currently have the tooling to make repos
per external layer work nicely for the end user (not that I think its
too hard to create). This repo give us a way to experiment with
splitting things up whilst still not hurting the end user experience too
much.

So its not the final solution, just what I think might be a good way to
start hashing things out.

Cheers,

Richard

On Wed, Dec 8, 2010 at 5:49 AM, Richard Purdie <rpurdie@...> wrote:

We're in a position where we have people wanting to extend Poky but
wondering exactly how to add their own layer and make Poky useful for
their specific use cases.

This is a topic I want to work with the OE community on and have
discussion about but equally, people are interested at the moment and we
need something people can experiment with now so we can see what works
and what doesn't.

With this in mind I'm proposing we create a "poky-extras" repository
which contains multiple user contributed layers.

My proposed ground rules are:

* it has the OE style open contributions model
* consists of a set of layers, each clearly identified at the top level
* each layer has a clearly named maintainer or maintainers
* people respect the layer maintainers
* layers are split into logical "topics" where at all possible

Ultimately, the repo structure and some of the details could change but
I'd like to experiment and see what we can come up with which is
probably the only way we're going to move forward.

Any comments, objections or better ideas? :)

This seems fine to me as an area to hash out good practices and
experiment, as long as we don't expect to use this structure long
term. It makes sense for the core layers to be in one repo, but it
makes more sense to use one git repository per external layer, imo.
Is that the intent, or am I misunderstanding its purpose?
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Hi,

We're in a position where we have people wanting to extend Poky but
wondering exactly how to add their own layer and make Poky useful for
their specific use cases.

This is a topic I want to work with the OE community on and have
discussion about but equally, people are interested at the moment and we
need something people can experiment with now so we can see what works
and what doesn't.

With this in mind I'm proposing we create a "poky-extras" repository
which contains multiple user contributed layers.

My proposed ground rules are:

* it has the OE style open contributions model
* consists of a set of layers, each clearly identified at the top level
* each layer has a clearly named maintainer or maintainers
* people respect the layer maintainers
* layers are split into logical "topics" where at all possible

Ultimately, the repo structure and some of the details could change but
I'd like to experiment and see what we can come up with which is
probably the only way we're going to move forward.

Any comments, objections or better ideas? :)

Cheers,

Richard

Hi Nitin,

On Tue, 2010-12-07 at 19:15 -0800, Kamble, Nitin A wrote:

I am getting following bitbake error. I also tried passing –D option
to bitbake, but I did not find anything useful. Also bellow is the
change which is causing this error.

I don’t see anything oblivious here. As I understand just changing the
recipe from cvs to git src_uri has caused this issue.

Its probably exactly this change the breaks things. git SRC_URIs have a
dependency on git-native. git-native probably depends on
gnu-config-native indirectly. The end result is a circular dependency.
Bitbake tried to work this out but obviously got lost in the circular
logic.

It did try and warn you with:

"""

ERROR: Unbuildable tasks were found.

These are usually caused by circular dependencies and any circular
dependency chains found will be printed below. Increase the debug
level to see a list of unbuildable tasks.

"""

Cheers,

Richard

Lu, Lianhao wrote:

Richard Purdie wrote on 2010-12-08:

Hi Lianhao,

On Tue, 2010-12-07 at 00:02 -0800, Lu, Lianhao wrote:

I'm wondering whether"-sysroot" is enough for our current design
that the rootfs used by toolchain can be copied by the user to
various locations? I just bumped into a problem when the
cross-canadian g++ complaining: fatal error: iostream: No such file
or direcotory.

I tried to compile the following hello.cpp with with
"mips-poky-linux-g++ --sysroot=<mysysroot> hello.cpp".

#include <iostream>

using namespace std;

void main()

{

cout << "Hello World!" << endl;
}



I straced the mips-poky-linux-g++ and found that it
searched"<mysysroot>/usr/include" for file iostream while that file
is actually located at"<mysysroot>/usr/include/c++". The
cross-canadian g ++ seems to be configured with"-
with-gxx-include-dir=/opt/poky/sysroots/mips-poky-linux/usr/include/
c ++", but it seems"-sysroot" option has no effect on the gxx
include search path.

So I'm confused as these two sentences appear to contradict each
other.

"""
it searched "<mysysroot>/usr/include" for file iostream while that
file is actually located at"<mysysroot>/usr/include/c++" """

means it did use <mysysroot> and the --with-sysroot option did
something but dropped the c++ part at the end of the path?

Exactly. It only searched the /usr/include under the sysroot
specified by "--sysroot" options, but did not search the
/usr/include/c++.

Reading gcc manual, it seems --sysroot will only look at
<sysroot>/usr/include and <sysroot>/usr/lib. I've also played with
-isysroot, which pretty much the same effect as sysroot. I can only get the
compilation going by explicitly using -I <mysysroot>/usr/include/c++ -I
<mysysroot>/usr/include/c++/i586-poky-linux options. And by using strace, I
found the command line options won't override the default header/library
searching sequence of gcc (set by with-gxx-include-dir), which still trying
to search under /opt/poky/i586-poky-linux/usr/include/c++, etc first...

And Jessica

If you have no rights to modify my branch tree ( I am not sure), you can check it in your own branch.

We can merge it later.

Thanks a lot!
criping