linux-yocto: consolidated pull request

Richard/Saul,

Here's another small queue of patches, some minor updates to kernel configs and fixes for YOCTO #3422 and YOCTO #3473.

patch 1/4 [linux-yocto/3.0: fix virtio configuration typo] fixes a build error atom-pc build in master by fixing the kernel fragment.

atom-pc should probably be using the 3.4 kernel, but that's a question for Darren/Tom/Nitin (so I've added them to the cc), since there may be a reason (with respect to graphics) as to why it is on 3.0.

While fixing that build error, I also modified the kern tools to clearly report the error and avoid needing to go to the logs for diagnosis, that's patch 4/4 [kern-tools: report missing config fragments by name].

The other change is a comment fixup for YOCTO #3422, just to make it clear if meta branches do or do not need to exist.

And finally, Tom noticed that a bad merge dropped some uprobes configuration and sent a fixup patch.

Cheers,

Bruce

The following changes since commit 1b4dcf10b0fe9b4e95ca84f32de0c7dcfee2b729:

ldconfig/cdrtools/icecc-create-env/linuxdoc-tools/python: Set FILESPATH to find -native files (2012-11-21 16:56:04 +0000)

are available in the git repository at:

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

Bruce Ashfield (4):
linux-yocto/3.0: fix virtio configuration typo linux-yocto/3.4: uprobes: reinstate config options for 'uprobe'
feature
kernel-yocto: clarify KMETA branch comments
kern-tools: report missing config fragments by name

 meta/classes/kernel-yocto.bbclass                       |    5 +++--
 meta/recipes-kernel/kern-tools/kern-tools-native_git.bb |    2 +-
 meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb         |    2 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_3.4.bb       |    2 +-
 meta/recipes-kernel/linux/linux-yocto_3.0.bb            |    2 +-
 meta/recipes-kernel/linux/linux-yocto_3.4.bb            |    2 +-
 6 files changed, 8 insertions(+), 7 deletions(-)

1.7.10.4

The recent tools updates in master exposed a typo that has existed in the 3.0 kernel meta data and that breaks the build for boards still using the 3.0 kernel.

Bumping the meta SRCREV to pickup the following fix:

[
commit fa9b8c24e84bb9d75d08d197c84c50ce4f99c424
Author: Bruce Ashfield <[email protected]>
Date: Wed Nov 21 09:24:46 2012 -0500

meta: fix typo in virtio.scc

virtio.scc was referring to an invalid/incorrect virto.cfg. Fixing this typo fixes the build for boards still using the 3.0 kernel.
]

---
 meta/recipes-kernel/linux/linux-yocto_3.0.bb |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index e917beb..b7fbf23 100644
@@ -17,7 +17,7 @@ SRCREV_machine_qemuppc ?= "d8779a6245d13c3b56eabac36a14c8896f448566"
 SRCREV_machine_qemux86 ?= "33d5d1ea371dad280e5bcfadd12c3a360c6bc5b8"
 SRCREV_machine_qemux86-64 ?= "fe23c7dd94eb94dd5887028683093615ac921086"
 SRCREV_machine ?= "cef17a18d72eae749dc78de3c83772f52815d842"
-SRCREV_meta ?= "bf5ee4945ee6d748e6abe16356f2357f76b5e2f0"
+SRCREV_meta ?= "fa9b8c24e84bb9d75d08d197c84c50ce4f99c424"
 
 PR = "${INC_PR}.1"
 PV = "${LINUX_VERSION}+git${SRCPV}"

1.7.10.4

bumping the meta SRCREV to import the following fix:

[
uprobes: reinstate config options for 'uprobe' feature

commit 17ec51adfff (meta: cleanup invalid/obselete 3.4 CONFIG options) removed the uprobes config options, this restores them.
]

---
 meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb   |    2 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_3.4.bb |    2 +-
 meta/recipes-kernel/linux/linux-yocto_3.4.bb      |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

index 1176404..76ee542 100644
@@ -10,7 +10,7 @@ KMETA = "meta"
 
 SRCREV_machine ?= "2572b13999da8129c37eb2bf7e9a8fa68dc2a4bf"
 SRCREV_machine_qemuppc ?= "2004632314104d4f31bb1577e955da53796f517c"
-SRCREV_meta ?= "553a8512fd924420db5cc2320ece4a6fd9b1e486"
+SRCREV_meta ?= "472aaf880c9176a40de98c97e14355fe77478598"
 
 PR = "${INC_PR}.0"
 PV = "${LINUX_VERSION}+git${SRCPV}"

index 6cfec92..50890a3 100644
@@ -13,7 +13,7 @@ LINUX_VERSION ?= "3.4.18"
 KMETA = "meta"
 
 SRCREV_machine ?= "f1c2320544eaffd6ecc7fcb8b18f8a0ed4ba2e14"
-SRCREV_meta ?= "553a8512fd924420db5cc2320ece4a6fd9b1e486"
+SRCREV_meta ?= "472aaf880c9176a40de98c97e14355fe77478598"
 
 PR = "${INC_PR}.0"
 PV = "${LINUX_VERSION}+git${SRCPV}"

index 7a58e1c..587bdd6 100644
@@ -9,7 +9,7 @@ SRCREV_machine_qemuppc ?= "ae8e2cd14e47bceb9c2bdcb927b3a0ea61f6c311"
 SRCREV_machine_qemux86 ?= "f1c2320544eaffd6ecc7fcb8b18f8a0ed4ba2e14"
 SRCREV_machine_qemux86-64 ?= "f1c2320544eaffd6ecc7fcb8b18f8a0ed4ba2e14"
 SRCREV_machine ?= "f1c2320544eaffd6ecc7fcb8b18f8a0ed4ba2e14"
-SRCREV_meta ?= "553a8512fd924420db5cc2320ece4a6fd9b1e486"
+SRCREV_meta ?= "472aaf880c9176a40de98c97e14355fe77478598"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
 

1.7.10.4

Having a meta branch is not strictly required by the tools (and recipes like linux-yocto-custom do not have meta branches), but the comments in the kernel-yocto.bbclass could lead someone to think that it was required.

This commit clearifies the comment to the following:

# We can fix up the kernel repository even if it wasn't a bare clone. # If KMETA is defined, the branch must exist, but a machine branch

  # can be missing since it may be created later by the tools.

[YOCTO #3422]

---
 meta/classes/kernel-yocto.bbclass |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

index f78d63b..0d4ed21 100644
@@ -130,8 +130,9 @@ do_kernel_checkout() {
 		echo "WARNING. ${WORKDIR}/git is not a bare clone."
 		echo "Ensure that the SRC_URI includes the 'bareclone=1' option."
 		
-		# we can fix up the kernel repository, but at the least the meta
-		# branch must be present. The machine branch may be created later.
+		# We can fix up the kernel repository even if it wasn't a bare clone.
+		# If KMETA is defined, the branch must exist, but a machine branch
+		# can be missing since it may be created later by the tools.
 		mv ${WORKDIR}/git/.git ${S}
 		rm -rf ${WORKDIR}/git/
 		cd ${S}

1.7.10.4

If a configuration fragment was missing, the previous error output was not clear about the error:

  | [INFO] doing kernel configme
  | [INFO] Configuring target/machine combo: "standard/atom-pc"
  | [INFO] collecting configs in ./meta/meta-series
  | ERROR: could not sanitize configuration fragments
  |    errors are logged in ... linux/meta/cfg/standard/atom-pc/config.log

but we know the name of the missing fragment and can improve the error message to be this:

  | [ERROR] kernel configuration fragment fragment 'virto.cfg' cannot be found
  | ERROR. A meta series could not be created for branch yocto/standard/common-pc/atom-pc
  | ERROR. Could not locate meta series for atom-pc
  | ERROR. Could not apply patches for atom-pc.
  |        Patch failures can be resolved in the devshell (bitbake -c devshell linux-yocto)

[YOCTO #3473]

---
 meta/recipes-kernel/kern-tools/kern-tools-native_git.bb |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index f2cd39f..635dfe6 100644
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=d8d1d729a70c
 
 DEPENDS = "git-native guilt-native"
 
-SRCREV = "6f68c9473b43c3e39755a72aef8733cbd0bf1a59"
+SRCREV = "62c8807825ea923a18b1519375b0df67ad9daf2b"
 PR = "r12"
 PV = "0.1+git${SRCPV}"
 

1.7.10.4

Ping Darren/Tom/Nitin.

atom-pc is certainly lagging behind by still being on 3.0, and I can't see any reason why we'd want to stick with 3.0 for graphics. In fact as the most common graphics driver used on atom-pc is a i965 we want a modern kernel as that is where the development is.

(this may explain why my GPU crashes when I stress it under Yocto)

Ross

I don't know of any technical reason for it to still be at 3.0.

Until recently all of the 'core machines' were at 3.0 and probably the assumption was that whoever upgraded those in the past would also be upgrading atom-pc - has that changed?.

So who does own the core machines and if that doesn't cover atom-pc, then who owns that?

Tom

As I understood it, WR owns the non-IA core machines, you (as in the Intel team) own the IA ones, namely atom-pc.

Cheers,

Richard

Agreed, it should be updated. Tom, Nitin, and I will discuss and select an owner.

Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel

OK, yeah, I anyway had just assumed it was WR for the core machines:

commit f08b8c96402cd2b1e939f1babbc002d630fbf274
Author: Bruce Ashfield <[email protected]>
Date: Fri Aug 19 00:37:08 2011 -0400

meta-yocto: atom-pc/mpc8315e-rdb change preferred version to 3.0

Updating two more yocto hardware reference platforms to use the 3.0 kernel by default.

But I see that Darren had done the previous upgrade:

commit 622fb696a6fc9eab991a5f412eb28e2ff949a32b
Author: Darren Hart <[email protected]>
Date: Fri May 6 12:12:50 2011 -0700

atom-pc: use linux-yocto (2.6.37) kernel

Tested boot, network, sato desktop, amixer, and audio playback on a
Toshiba

    NB305 netbook.

And it does make sense for Intel to own the atom-pc, it's just never been clearly stated unless I missed the discussion.

Tom