kernel-yocto: consolidated pull request

Integrating the korg 4.1.29 -stable release

Signed-off-by Bruce Ashfield <[email protected]>

---
 meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb   |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb |  6 +++---
 meta/recipes-kernel/linux/linux-yocto_4.1.bb      | 20 ++++++++++---
-------
 3 files changed, 16 insertions(+), 16 deletions(-)

Quoted 9 lines · Bruce Ashfield

Integrating the korg 4.1.29 -stable release

Signed-off-by Bruce Ashfield <[email protected]>

---
 meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb   |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb |  6 +++---
 meta/recipes-kernel/linux/linux-yocto_4.1.bb      | 20 ++++++++++---
-------
 3 files changed, 16 insertions(+), 16 deletions(-)

FWIW since the update before this one, we've seen a lot of instability in ppc:

https://autobuilder.yoctoproject.org/main/builders/nightly-ppc-lsb/builds/881/steps/Running%20Sanity%20Tests/logs/stdio

basically the network seems very flaky. Doesn't happen every time but we are seeing a rising number of these kinds of 'random' failures. Are there any ppc changes or fixes which look like they're responsible, I'm pretty sure its something 4.1 kernel related...

The update also triggered a new 'error' for amd_nb in the error log parsing which I just whitelisted, probably from some change in the configuration options enabled.

Cheers,

Richard

Quoted 27 lines · Richard Purdie

Quoted 10 lines · Bruce Ashfield

Integrating the korg 4.1.29 -stable release

Signed-off-by Bruce Ashfield <[email protected]>

---
 meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb   |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb |  6 +++---
 meta/recipes-kernel/linux/linux-yocto_4.1.bb      | 20
++++++++++---
-------
 3 files changed, 16 insertions(+), 16 deletions(-)

FWIW since the update before this one, we've seen a lot of instability
in ppc:

https://autobuilder.yoctoproject.org/main/builders/nightly-ppc-lsb/
builds/881/steps/Running%20Sanity%20Tests/logs/stdio

basically the network seems very flaky. Doesn't happen every time but
we are seeing a rising number of these kinds of 'random' failures. Are
there any ppc changes or fixes which look like they're responsible, I'm
pretty sure its something 4.1 kernel related...

Quoted 3 lines

The update also triggered a new 'error' for amd_nb in the error log parsing which I just whitelisted, probably from some change in the configuration options enabled.

I have a 4.1.30 update queued locally, and I'll double check to see what may have changed in the configuration that could explain any new warnings or instability.

Quoted 28 lines · Bruce Ashfield

Quoted 27 lines · Richard Purdie

Quoted 10 lines · Bruce Ashfield

Integrating the korg 4.1.29 -stable release

Signed-off-by Bruce Ashfield <[email protected]>

---
 meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb   |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb |  6 +++---
 meta/recipes-kernel/linux/linux-yocto_4.1.bb      | 20
++++++++++---
-------
 3 files changed, 16 insertions(+), 16 deletions(-)

FWIW since the update before this one, we've seen a lot of instability
in ppc:

https://autobuilder.yoctoproject.org/main/builders/nightly-ppc-lsb/
builds/881/steps/Running%20Sanity%20Tests/logs/stdio

basically the network seems very flaky. Doesn't happen every time but
we are seeing a rising number of these kinds of 'random' failures. Are
there any ppc changes or fixes which look like they're responsible, I'm
pretty sure its something 4.1 kernel related...

Quoted 7 lines

Quoted 3 lines

The update also triggered a new 'error' for amd_nb in the error log parsing which I just whitelisted, probably from some change in the configuration options enabled.

I have a 4.1.30 update queued locally, and I'll double check to see what may have changed in the configuration that could explain any new warnings or instability.

Just to be clear, the amb_nd change was on qemux86* on 4.1

https://autobuilder.yoctoproject.org/main/builders/nightly-x86-64-lsb/builds/911/steps/Running%20Sanity%20Tests/logs/stdio

fixed with:

http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=26b0657b2f78751e60df6e695d5bc0dd703a5bc2

The ppc issue is a separate one.

Cheers,

Richard

Quoted 48 lines · Richard Purdie

Quoted 40 lines · Bruce Ashfield

Quoted 33 lines · Richard Purdie

Review

Quoted 12 lines · Bruce Ashfield

Integrating the korg 4.1.29 -stable release

Signed-off-by Bruce Ashfield <[email protected]>

---
 meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb   |  6 +++--

(quoted diff) +1 -3

-
 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb |  6 +++--
-
 meta/recipes-kernel/linux/linux-yocto_4.1.bb      | 20
++++++++++---
-------
 3 files changed, 16 insertions(+), 16 deletions(-)

FWIW since the update before this one, we've seen a lot of instability
in ppc:

https://autobuilder.yoctoproject.org/main/builders/nightly-ppc-
lsb/ builds/881/steps/Running%20Sanity%20Tests/logs/stdio

basically the network seems very flaky. Doesn't happen every time
but
we are seeing a rising number of these kinds of 'random' failures.
Are
there any ppc changes or fixes which look like they're responsible,
I'm
pretty sure its something 4.1 kernel related...

Quoted 5 lines

The update also triggered a new 'error' for amd_nb in the error log
parsing which I just whitelisted, probably from some change in the
configuration options enabled.

Quoted 4 lines

I have a 4.1.30 update queued locally, and I'll double check to see
what may have changed in the configuration that could explain any new warnings or instability.

Just to be clear, the amb_nd change was on qemux86* on 4.1

Quoted 7 lines

https://autobuilder.yoctoproject.org/main/builders/nightly-x86-64-l
sb/builds/911/steps/Running%20Sanity%20Tests/logs/stdio

fixed with:

http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=26b0657b2f7875
1e60df6e695d5bc0dd703a5bc2

I had a look at this, and I don't have a root cause for why this is just popping up now. I'm trying to track down an older build, so I can
compare the .configs.

The kernel code, and Kconfig files themselves haven't changed in some time, and the symbol in question AMD_NB is default 'y' if the dependencies are met. We include cfg/amd.scc in all of the qemux86* builds, so it gets enabled (as it should have before).

I could force that option off, but the whitelist is an appropriate fix,
since this is an interaction between qemu and the kernel, whereas the files that include amd.scc are targeted at a range of platforms.

Quoted 1 line

Quoted 1 line

The ppc issue is a separate one.

I've been blasting away on my 4.1.30 qemuppc build, and I'm not seeing
anything yet, but I will keep trying.

Quoted 73 lines · Bruce Ashfield

Quoted 48 lines · Richard Purdie

Quoted 40 lines · Bruce Ashfield

Quoted 33 lines · Richard Purdie

Review

Quoted 12 lines · Bruce Ashfield

Integrating the korg 4.1.29 -stable release

Signed-off-by Bruce Ashfield <[email protected]>

---
 meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb   |  6 +++--

(quoted diff) +1 -3

-
 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb |  6 +++--
-
 meta/recipes-kernel/linux/linux-yocto_4.1.bb      | 20
++++++++++---
-------
 3 files changed, 16 insertions(+), 16 deletions(-)

FWIW since the update before this one, we've seen a lot of instability
in ppc:

https://autobuilder.yoctoproject.org/main/builders/nightly-ppc-
lsb/ builds/881/steps/Running%20Sanity%20Tests/logs/stdio

basically the network seems very flaky. Doesn't happen every time
but
we are seeing a rising number of these kinds of 'random' failures.
Are
there any ppc changes or fixes which look like they're responsible,
I'm
pretty sure its something 4.1 kernel related...

Quoted 5 lines

The update also triggered a new 'error' for amd_nb in the error log
parsing which I just whitelisted, probably from some change in the
configuration options enabled.

Quoted 4 lines

I have a 4.1.30 update queued locally, and I'll double check to see
what may have changed in the configuration that could explain any new warnings or instability.

Just to be clear, the amb_nd change was on qemux86* on 4.1

Quoted 7 lines

https://autobuilder.yoctoproject.org/main/builders/nightly-x86-64-l
sb/builds/911/steps/Running%20Sanity%20Tests/logs/stdio

fixed with:

http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=26b0657b2f7875
1e60df6e695d5bc0dd703a5bc2

I had a look at this, and I don't have a root cause for why this is just popping up now. I'm trying to track down an older build, so I can
compare the .configs.

The kernel code, and Kconfig files themselves haven't changed in some time, and the symbol in question AMD_NB is default 'y' if the dependencies are met. We include cfg/amd.scc in all of the qemux86* builds, so it gets enabled (as it should have before).

I could force that option off, but the whitelist is an appropriate fix,
since this is an interaction between qemu and the kernel, whereas the files that include amd.scc are targeted at a range of platforms.

Quoted 1 line

Quoted 5 lines

Quoted 1 line

The ppc issue is a separate one.

I've been blasting away on my 4.1.30 qemuppc build, and I'm not seeing
anything yet, but I will keep trying.

Its still going on even with the recent updates:

https://autobuilder.yoctoproject.org/main/builders/nightly-ppc-lsb/
builds/889/steps/Running%20Sanity%20Tests/logs/stdio

Seems the network works intermittently, dropping connections...

Cheers,

Richard
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

We've been running with a set of kern-tools that were designed to work with build systems that knew nothing about git, trees, commits, etc.

As such, there's been a set of shims/wrappers in place to work with within bitbake/oe-core. These were the *me scripts: createme, updateme, patchme and configme.

With this commit, we strip that legacy code and use the tools directly. This means less complexity, fewer corner cases .. and no surprises when the tools are arunning. As another benefit, the tools consume much less time during a typical build and have no noticeable impact on the overall build time.

Existing .scc files, features, and processing are not impacted as these tools are compatible with existing feature descriptions and kerne configuration fragments.

The audit of kernel configuration fragments is now detached from the linux-yocto build structure and process. This means that they can eventually be tweaked to offer kernel audit to any type of kernel build and configuration process.

Additionally, the kernel symbol audit phase can now resolve symbol dependencies and offer guidance when a symbol is missing:

   WARNING: linux-yocto-4.4.15+gitAUTOINC+b030d96c7b_f5e2c49d58-r0
do_kernel_configcheck: [kernel config]: specified values did not make it into the kernel's final configuration:

   ---------- CONFIG_BT_6LOWPAN -----------------
   Config: CONFIG_BT_6LOWPAN
   From: /home/bruce/poky/build/tmp/work-shared/qemux86-64/kernel- source/.kernel-meta/configs/standard/features/bluetooth/bluetooth.cfg Requested value:  CONFIG_BT_6LOWPAN=y
   Actual value:

   Config 'BT_6LOWPAN' has the following conditionals:
     BT_LE && 6LOWPAN (value: "n")
   Dependency values are:
     BT_LE [y] 6LOWPAN [n]

Signed-off-by Bruce Ashfield <[email protected]>

---
 meta/classes/kernel-yocto.bbclass                  | 143 ++++++++------
-------
 .../kern-tools/kern-tools-native_git.bb            |   4 +-

 2 files changed, 55 insertions(+), 92 deletions(-)

meta/classes/kernel- renamed from meta/classes/kernel-yocto.bbclass +0 -0

yocto.bbclass
index a9d4205..8650e55 100644

meta/classes/kernel-yocto.bbclass +0 -0

@@ -119,77 +119,42 @@ do_kernel_metadata() {

  patches="${@" ".join(find_patches(d))}" feat_dirs="${@" ".join(find_kernel_feature_dirs(d))}"

meta/classes/kernel-yocto.bbclass +0 -1

-	# add any explicitly referenced features onto the end of the

feature

meta/classes/kernel-yocto.bbclass +0 -7

-	# list that is passed to the kernel build scripts.
-	if [ -n "${KERNEL_FEATURES}" ]; then
-		for feat in ${KERNEL_FEATURES}; do
-			addon_features="$addon_features --feature $feat"
-		done
-	fi
-

 	# check for feature directories/repos/branches that were part of
the
 	# SRC_URI. If they were supplied, we convert them into include
directives
 	# for the update part of the process

meta/classes/kernel-yocto.bbclass +1 -2

-	if [ -n "${feat_dirs}" ]; then
-	    for f in ${feat_dirs}; do
+	for f in ${feat_dirs}; do

  if [ -d "${WORKDIR}/$f/meta" ]; then

meta/classes/kernel-yocto.bbclass +1 -1

-		    includes="$includes -I${WORKDIR}/$f/meta"
+			includes="$includes -I${WORKDIR}/$f/meta"

  elif [ -d "${WORKDIR}/$f" ]; then

meta/classes/kernel-yocto.bbclass +1 -1

-		    includes="$includes -I${WORKDIR}/$f"
+			includes="$includes -I${WORKDIR}/$f"

  fi

meta/classes/kernel-yocto.bbclass +5 -2

-	    done
-	fi
+	done
+	for s in ${sccs}; do
+		sdir=$(dirname $s)
+		includes="$includes -I${sdir}"
+	done

meta/classes/kernel-yocto.bbclass +0 -4

-	# updates or generates the target description
-	updateme ${updateme_flags}
-DKDESC=${KMACHINE}:${LINUX_KERNEL_TYPE} \
-                         ${includes} ${addon_features} ${ARCH}

${KMACHINE} ${sccs} ${patches}

meta/classes/kernel-yocto.bbclass +5 -4

-	if [ $? -ne 0 ]; then
-		bbfatal_log "Could not update ${machine_branch}"
-	fi
+	# expand kernel features into their full path equivalents
+	bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE}
-DKTYPE=${LINUX_KERNEL_TYPE})
+	meta_dir=$(kgit --meta)
+
+	# run1: pull all the configuration fragments, no matter where

they come from

meta/classes/kernel-yocto.bbclass +1 -0

+	scc --force -o ${S}/${meta_dir}:cfg,meta ${includes}

${bsp_definition} ${sccs} ${patches} ${KERNEL_FEATURES}

meta/classes/kernel-yocto.bbclass +2 -0

+
+	# run2: only generate patches for elements that have been passed

on the SRC_URI

meta/classes/kernel-yocto.bbclass +1 -0

+	scc --force -o ${S}/${meta_dir}:patch --cmds patch ${includes}

${sccs} ${patches} ${KERNEL_FEATURES}
 }

 do_patch() {
  cd ${S}

meta/classes/kernel-yocto.bbclass +0 -5

-	# executes and modifies the source tree as required
-	patchme ${KMACHINE}
-	if [ $? -ne 0 ]; then
-		bberror "Could not apply patches for ${KMACHINE}."
-		bbfatal_log "Patch failures can be resolved in the linux

source directory ${S})"

meta/classes/kernel-yocto.bbclass +0 -3

-	fi
-
-	# check to see if the specified SRCREV is reachable from the

final branch.

meta/classes/kernel-yocto.bbclass +0 -4

-	# if it wasn't something wrong has happened, and we should error.
-	machine_srcrev="${SRCREV_machine}"
-	if [ -z "${machine_srcrev}" ]; then
-		# fallback to SRCREV if a non machine_meta tree is being

built

meta/classes/kernel-yocto.bbclass +0 -4

-		machine_srcrev="${SRCREV}"
-		# if SRCREV cannot be reached something is wrong.
-		if [ -z "${machine_srcrev}" ]; then
-			bbfatal "Neither SRCREV_machine or SRCREV was

specified!"

meta/classes/kernel-yocto.bbclass +0 -8

-		fi
-	fi
-
-        if [ -n "${KMETA_AUDIT}" ]; then
-            current_branch=`git rev-parse --abbrev-ref HEAD`
-            machine_branch="${@ get_machine_branch(d, "${KBRANCH}" )}"
-            if [ "${current_branch}" != "${machine_branch}" ]; then
-                bbwarn "After meta data application, the kernel tree

branch is ${current_branch}."
-                bbwarn "The SRC_URI specified branch ${machine_branch}." -                bbwarn ""
-                bbwarn "The branch will be forced to ${machine_branch}, but this means the board meta data"
-                bbwarn "(.scc files) do not match the SRC_URI specification."
-                bbwarn ""
-                bbwarn "The meta data and branch ${machine_branch} should be inspected to ensure the proper"
-                bbwarn "kernel is being built."
-                git checkout -f ${machine_branch}
-            fi
-        fi

meta/classes/kernel-yocto.bbclass +0 -3

-
-	if [ "${machine_srcrev}" != "AUTOINC" ]; then
-		if ! [ "$(git rev-parse --verify ${machine_srcrev}~0)" =

"$(git merge-base ${machine_srcrev} HEAD)" ]; then

meta/classes/kernel-yocto.bbclass +0 -1

-			bberror "SRCREV ${machine_srcrev} was specified,

but is not reachable"

meta/classes/kernel-yocto.bbclass +0 -1

-			bbfatal "Check the BSP description for incorrect

branch selection, or other errors."

meta/classes/kernel-yocto.bbclass +6 -0

+	meta_dir=$(kgit --meta)
+	(cd ${meta_dir}; ln -sf patch.queue series)
+	if [ -f "${meta_dir}/series" ]; then
+		kgit-s2q --gen -v --patches .kernel-meta/
+		if [ $? -ne 0 ]; then
+			bberror "Could not apply patches for

${KMACHINE}."

meta/classes/kernel-yocto.bbclass +1 -0

+			bbfatal_log "Patch failures can be resolved in

the linux source directory ${S})"
  fi
  fi
 }

meta/classes/kernel-yocto.bbclass +0 -0

@@ -258,26 +223,37 @@ do_kernel_metadata[depends] = "kern-tools-

native:do_populate_sysroot"

 do_kernel_configme[dirs] += "${S} ${B}"
 do_kernel_configme() {

meta/classes/kernel-yocto.bbclass +1 -2

-	bbnote "kernel configme"
-	export KMETA=${KMETA}
+	set +e

meta/classes/kernel-yocto.bbclass +0 -4

-	if [ -n "${KCONFIG_MODE}" ]; then
-		configmeflags=${KCONFIG_MODE}
-	else
-		# If a defconfig was passed, use =n as the baseline,

which is achieved

meta/classes/kernel-yocto.bbclass +10 -1

-		# via --allnoconfig
+	# translate the kconfig_mode into something that merge_config.sh
+	# understands
+	case ${KCONFIG_MODE} in
+		allnoconfig)
+			config_flags="-n"
+			;;
+		alldefconfig)
+			config_flags=""
+			;;
+	    *)

  if [ -f ${WORKDIR}/defconfig ]; then

meta/classes/kernel-yocto.bbclass +1 -1

-			configmeflags="--allnoconfig"
+			config_flags="-n"

  fi

meta/classes/kernel-yocto.bbclass +2 -1

-	fi
+	    ;;
+	esac

  cd ${S}

meta/classes/kernel-yocto.bbclass +0 -2

-	PATH=${PATH}:${S}/scripts/util
-	configme ${configmeflags} --reconfig --output ${B}

${LINUX_KERNEL_TYPE} ${KMACHINE}

meta/classes/kernel-yocto.bbclass +5 -0

+
+	meta_dir=$(kgit --meta)
+	configs="$(scc --configs -o ${meta_dir})"
+	if [ -z "${configs}" ]; then
+		bbfatal_log "Could not find configuration queue

(${meta_dir}/config.queue)"

meta/classes/kernel-yocto.bbclass +3 -0

+	fi
+
+	ARCH=${ARCH} merge_config.sh -O ${B} ${config_flags} ${configs} >

${meta_dir}/cfg/merge_config_build.log 2>&1
  if [ $? -ne 0 ]; then
  bbfatal_log "Could not configure ${KMACHINE}- ${LINUX_KERNEL_TYPE}"
  fi

meta/classes/kernel-yocto.bbclass +1 -1

-	
+

  echo "# Global settings from linux recipe" >> ${B}/.config echo "CONFIG_LOCALVERSION="\"${LINUX_VERSION_EXTENSION}\" >> ${B}/.config
 }

meta/classes/kernel-yocto.bbclass +0 -0

@@ -295,36 +271,23 @@ python do_kernel_configcheck() {

         kmeta = "." + kmeta

     pathprefix = "export PATH=%s:%s; " % (d.getVar('PATH', True), "${S}/scripts/util/")
-    cmd = d.expand("cd ${S}; kconf_check -config %s/meta-series ${S} ${B}" % kmeta)

meta/classes/kernel-yocto.bbclass +5 -0

+
+    cmd = d.expand("scc --configs -o ${S}/.kernel-meta")
+    ret, configs = oe.utils.getstatusoutput("%s%s" % (pathprefix, cmd))
+
+    cmd = d.expand("cd ${S}; kconf_check --report -o ${S}/%s/cfg/

${B}/.config ${S} %s" % (kmeta,configs))
     ret, result = oe.utils.getstatusoutput("%s%s" % (pathprefix, cmd))
     config_check_visibility = int(d.getVar( "KCONF_AUDIT_LEVEL", True ) or 0)
     bsp_check_visibility = int(d.getVar( "KCONF_BSP_AUDIT_LEVEL", True ) or 0)

     # if config check visibility is non-zero, report dropped
configuration values
-    mismatch_file = "${S}/" + kmeta + "/" + "mismatch.cfg"
+    mismatch_file = d.expand("${S}/%s/cfg/mismatch.txt" % kmeta)
     if os.path.exists(mismatch_file):
         if config_check_visibility:
             with open (mismatch_file, "r") as myfile:
                 results = myfile.read()
                 bb.warn( "[kernel config]: specified values did not make
it into the kernel's final configuration:\n\n%s" % results)
-
-    # if config check visibility is level 2 or higher, report non-
hardware options
-    nonhw_file = "${S}/" + kmeta + "/" + "nonhw_report.cfg"
-    if os.path.exists(nonhw_file):
-        if config_check_visibility > 1:
-            with open (nonhw_file, "r") as myfile:
-                results = myfile.read()
-                bb.warn( "[kernel config]: BSP specified non-hw
configuration:\n\n%s" % results)
-
-    bsp_desc = "${S}/" + kmeta + "/" + "top_tgt"
-    if os.path.exists(bsp_desc) and bsp_check_visibility > 1:
-        with open (bsp_desc, "r") as myfile:
-            bsp_tgt = myfile.read()
-            m = re.match("^(.*)scratch.obj(.*)$", bsp_tgt)
-            if not m is None:
-                bb.warn( "[kernel]: An auto generated BSP description was
used, this normally indicates a misconfiguration.\n" +
-                         "Check that your machine (%s) has an associated
kernel description." % "${MACHINE}" )
 }
 
 # Ensure that the branches (BSP and meta) are on the locations specified
by

meta/recipes-kernel/kern-tools/kern-tools-native_git.bb +0 -0

index c3ded98..6877a0c 100644
@@ -1,10 +1,10 @@

 SUMMARY = "Tools for managing Yocto Project style branched kernels" LICENSE = "GPLv2"
-LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=d8d1d729a70cd5f52972f8884 b80743d"
+LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1bda400e2828845 ba0d06c"

 DEPENDS = "git-native"

meta/recipes-kernel/kern-tools/kern-tools-native_git.bb +1 -1

-SRCREV = "a6a6f6e1e738d2ecd26b675e9bec867105703416"
+SRCREV = "4b5de9011b31ff92ba2b6e052ab818b09affd905"

 PR = "r12"
 PV = "0.2+git${SRCPV}"

--
2.5.0

My kmeta stuff is located directly inside two meta-* layers (i.e. not in an extra git repo), where the 2nd layer's kernel recipes .bbappends to the 1st one with additional kmeta things.

This used to work fine, but since this commit it doesn't anymore as only the kmeta stuff from the 2nd layer is being copied into workdir.

Have I been doing something that wasn't guaranteed / supposed to work in the first place? Or should that still work? Is it worth fixing or should I rethink my approach?

Cheers,
Andre'

Quoted 315 lines · Bruce Ashfield

We've been running with a set of kern-tools that were designed to work with build systems that knew nothing about git, trees, commits, etc.

As such, there's been a set of shims/wrappers in place to work with within bitbake/oe-core. These were the *me scripts: createme, updateme, patchme and configme.

With this commit, we strip that legacy code and use the tools directly. This means less complexity, fewer corner cases .. and no surprises when the tools are arunning. As another benefit, the tools consume much less time during a typical build and have no noticeable impact on the overall build time.

Existing .scc files, features, and processing are not impacted as these tools are compatible with existing feature descriptions and kerne configuration fragments.

The audit of kernel configuration fragments is now detached from the linux-yocto build structure and process. This means that they can eventually be tweaked to offer kernel audit to any type of kernel build and configuration process.

Additionally, the kernel symbol audit phase can now resolve symbol dependencies and offer guidance when a symbol is missing:

   WARNING: linux-yocto-4.4.15+gitAUTOINC+b030d96c7b_f5e2c49d58-r0

do_kernel_configcheck: [kernel config]: specified values did not make it into the kernel's final configuration:

   ---------- CONFIG_BT_6LOWPAN -----------------
   Config: CONFIG_BT_6LOWPAN
   From: /home/bruce/poky/build/tmp/work-shared/qemux86-64/kernel-

source/.kernel-meta/configs/standard/features/bluetooth/bluetooth.cfg
Requested value: CONFIG_BT_6LOWPAN=y
Actual value:

Config 'BT_6LOWPAN' has the following conditionals:

     BT_LE && 6LOWPAN (value: "n")
   Dependency values are:
     BT_LE [y] 6LOWPAN [n]

Signed-off-by Bruce Ashfield <[email protected]>

---
 meta/classes/kernel-yocto.bbclass                  | 143 ++++++++------
-------
 .../kern-tools/kern-tools-native_git.bb            |   4 +-
 2 files changed, 55 insertions(+), 92 deletions(-)

meta/classes/kernel- renamed from meta/classes/kernel-yocto.bbclass +0 -0

yocto.bbclass
index a9d4205..8650e55 100644

meta/classes/kernel-yocto.bbclass +0 -1

@@ -119,77 +119,42 @@ do_kernel_metadata() {
 	patches="${@" ".join(find_patches(d))}"
 	feat_dirs="${@" ".join(find_kernel_feature_dirs(d))}"
 
-	# add any explicitly referenced features onto the end of the

feature

meta/classes/kernel-yocto.bbclass +0 -7

-	# list that is passed to the kernel build scripts.
-	if [ -n "${KERNEL_FEATURES}" ]; then
-		for feat in ${KERNEL_FEATURES}; do
-			addon_features="$addon_features --feature $feat"
-		done
-	fi
-
 	# check for feature directories/repos/branches that were part of

the
# SRC_URI. If they were supplied, we convert them into include
directives

meta/classes/kernel-yocto.bbclass +8 -10

 	# for the update part of the process
-	if [ -n "${feat_dirs}" ]; then
-	    for f in ${feat_dirs}; do
+	for f in ${feat_dirs}; do
 		if [ -d "${WORKDIR}/$f/meta" ]; then
-		    includes="$includes -I${WORKDIR}/$f/meta"
+			includes="$includes -I${WORKDIR}/$f/meta"
 		elif [ -d "${WORKDIR}/$f" ]; then
-		    includes="$includes -I${WORKDIR}/$f"
+			includes="$includes -I${WORKDIR}/$f"
 		fi
-	    done
-	fi
+	done
+	for s in ${sccs}; do
+		sdir=$(dirname $s)
+		includes="$includes -I${sdir}"
+	done
 
-	# updates or generates the target description
-	updateme ${updateme_flags}
-DKDESC=${KMACHINE}:${LINUX_KERNEL_TYPE} \
-                         ${includes} ${addon_features} ${ARCH}

${KMACHINE} ${sccs} ${patches}

meta/classes/kernel-yocto.bbclass +5 -4

-	if [ $? -ne 0 ]; then
-		bbfatal_log "Could not update ${machine_branch}"
-	fi
+	# expand kernel features into their full path equivalents
+	bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE}
-DKTYPE=${LINUX_KERNEL_TYPE})
+	meta_dir=$(kgit --meta)
+
+	# run1: pull all the configuration fragments, no matter where

they come from

meta/classes/kernel-yocto.bbclass +1 -0

+	scc --force -o ${S}/${meta_dir}:cfg,meta ${includes}

${bsp_definition} ${sccs} ${patches} ${KERNEL_FEATURES}

meta/classes/kernel-yocto.bbclass +2 -0

+
+	# run2: only generate patches for elements that have been passed

on the SRC_URI

meta/classes/kernel-yocto.bbclass +1 -0

+	scc --force -o ${S}/${meta_dir}:patch --cmds patch ${includes}

${sccs} ${patches} ${KERNEL_FEATURES}
}

do_patch() {

meta/classes/kernel-yocto.bbclass +0 -5

 	cd ${S}
 
-	# executes and modifies the source tree as required
-	patchme ${KMACHINE}
-	if [ $? -ne 0 ]; then
-		bberror "Could not apply patches for ${KMACHINE}."
-		bbfatal_log "Patch failures can be resolved in the linux

source directory ${S})"

meta/classes/kernel-yocto.bbclass +0 -3

-	fi
-
-	# check to see if the specified SRCREV is reachable from the

final branch.

meta/classes/kernel-yocto.bbclass +0 -4

-	# if it wasn't something wrong has happened, and we should error.
-	machine_srcrev="${SRCREV_machine}"
-	if [ -z "${machine_srcrev}" ]; then
-		# fallback to SRCREV if a non machine_meta tree is being

built

meta/classes/kernel-yocto.bbclass +0 -4

-		machine_srcrev="${SRCREV}"
-		# if SRCREV cannot be reached something is wrong.
-		if [ -z "${machine_srcrev}" ]; then
-			bbfatal "Neither SRCREV_machine or SRCREV was

specified!"

meta/classes/kernel-yocto.bbclass +0 -8

-		fi
-	fi
-
-        if [ -n "${KMETA_AUDIT}" ]; then
-            current_branch=`git rev-parse --abbrev-ref HEAD`
-            machine_branch="${@ get_machine_branch(d, "${KBRANCH}" )}"
-            if [ "${current_branch}" != "${machine_branch}" ]; then
-                bbwarn "After meta data application, the kernel tree

branch is ${current_branch}."

meta/classes/kernel-yocto.bbclass +0 -3

-                bbwarn "The SRC_URI specified branch ${machine_branch}."
-                bbwarn ""
-                bbwarn "The branch will be forced to ${machine_branch},

but this means the board meta data"
- bbwarn "(.scc files) do not match the SRC_URI
specification."

meta/classes/kernel-yocto.bbclass +0 -2

-                bbwarn ""
-                bbwarn "The meta data and branch ${machine_branch} should

be inspected to ensure the proper"

meta/classes/kernel-yocto.bbclass +0 -7

-                bbwarn "kernel is being built."
-                git checkout -f ${machine_branch}
-            fi
-        fi
-
-	if [ "${machine_srcrev}" != "AUTOINC" ]; then
-		if ! [ "$(git rev-parse --verify ${machine_srcrev}~0)" =

"$(git merge-base ${machine_srcrev} HEAD)" ]; then

meta/classes/kernel-yocto.bbclass +0 -1

-			bberror "SRCREV ${machine_srcrev} was specified,

but is not reachable"

meta/classes/kernel-yocto.bbclass +0 -1

-			bbfatal "Check the BSP description for incorrect

branch selection, or other errors."

meta/classes/kernel-yocto.bbclass +6 -0

+	meta_dir=$(kgit --meta)
+	(cd ${meta_dir}; ln -sf patch.queue series)
+	if [ -f "${meta_dir}/series" ]; then
+		kgit-s2q --gen -v --patches .kernel-meta/
+		if [ $? -ne 0 ]; then
+			bberror "Could not apply patches for

${KMACHINE}."

meta/classes/kernel-yocto.bbclass +1 -0

+			bbfatal_log "Patch failures can be resolved in

the linux source directory ${S})"

meta/classes/kernel-yocto.bbclass +0 -0

 		fi
 	fi
 }

@@ -258,26 +223,37 @@ do_kernel_metadata[depends] = "kern-tools-

native:do_populate_sysroot"

do_kernel_configme[dirs] += "${S} ${B}"
do_kernel_configme() {

meta/classes/kernel-yocto.bbclass +1 -6

-	bbnote "kernel configme"
-	export KMETA=${KMETA}
+	set +e
 
-	if [ -n "${KCONFIG_MODE}" ]; then
-		configmeflags=${KCONFIG_MODE}
-	else
-		# If a defconfig was passed, use =n as the baseline,

which is achieved

meta/classes/kernel-yocto.bbclass +13 -5

-		# via --allnoconfig
+	# translate the kconfig_mode into something that merge_config.sh
+	# understands
+	case ${KCONFIG_MODE} in
+		allnoconfig)
+			config_flags="-n"
+			;;
+		alldefconfig)
+			config_flags=""
+			;;
+	    *)
 		if [ -f ${WORKDIR}/defconfig ]; then
-			configmeflags="--allnoconfig"
+			config_flags="-n"
 		fi
-	fi
+	    ;;
+	esac
 
 	cd ${S}
-	PATH=${PATH}:${S}/scripts/util
-	configme ${configmeflags} --reconfig --output ${B}

${LINUX_KERNEL_TYPE} ${KMACHINE}

meta/classes/kernel-yocto.bbclass +5 -0

+
+	meta_dir=$(kgit --meta)
+	configs="$(scc --configs -o ${meta_dir})"
+	if [ -z "${configs}" ]; then
+		bbfatal_log "Could not find configuration queue

(${meta_dir}/config.queue)"

meta/classes/kernel-yocto.bbclass +3 -0

+	fi
+
+	ARCH=${ARCH} merge_config.sh -O ${B} ${config_flags} ${configs} >

${meta_dir}/cfg/merge_config_build.log 2>&1

meta/classes/kernel-yocto.bbclass +0 -0

 	if [ $? -ne 0 ]; then
 		bbfatal_log "Could not configure ${KMACHINE}-

${LINUX_KERNEL_TYPE}"

meta/classes/kernel-yocto.bbclass +1 -1

 	fi
-	
+
 	echo "# Global settings from linux recipe" >> ${B}/.config
 	echo "CONFIG_LOCALVERSION="\"${LINUX_VERSION_EXTENSION}\" >>

${B}/.config
}

meta/classes/kernel-yocto.bbclass +5 -1

@@ -295,36 +271,23 @@ python do_kernel_configcheck() {
         kmeta = "." + kmeta
 
     pathprefix = "export PATH=%s:%s; " % (d.getVar('PATH', True),
 "${S}/scripts/util/")
-    cmd = d.expand("cd ${S}; kconf_check -config %s/meta-series ${S}
 ${B}" % kmeta)
+
+    cmd = d.expand("scc --configs -o ${S}/.kernel-meta")
+    ret, configs = oe.utils.getstatusoutput("%s%s" % (pathprefix, cmd))
+
+    cmd = d.expand("cd ${S}; kconf_check --report -o ${S}/%s/cfg/
 ${B}/.config ${S} %s" % (kmeta,configs))
     ret, result = oe.utils.getstatusoutput("%s%s" % (pathprefix, cmd))
 
     config_check_visibility = int(d.getVar( "KCONF_AUDIT_LEVEL", True )
 or 0)
     bsp_check_visibility = int(d.getVar( "KCONF_BSP_AUDIT_LEVEL", True )
 or 0)
 
     # if config check visibility is non-zero, report dropped

configuration values

meta/classes/kernel-yocto.bbclass +1 -1

-    mismatch_file = "${S}/" + kmeta + "/" + "mismatch.cfg"
+    mismatch_file = d.expand("${S}/%s/cfg/mismatch.txt" % kmeta)
     if os.path.exists(mismatch_file):
         if config_check_visibility:
             with open (mismatch_file, "r") as myfile:
                 results = myfile.read()
                 bb.warn( "[kernel config]: specified values did not make

it into the kernel's final configuration:\n\n%s" % results)

meta/classes/kernel-yocto.bbclass +0 -2

-
-    # if config check visibility is level 2 or higher, report non-

hardware options

meta/classes/kernel-yocto.bbclass +0 -6

-    nonhw_file = "${S}/" + kmeta + "/" + "nonhw_report.cfg"
-    if os.path.exists(nonhw_file):
-        if config_check_visibility > 1:
-            with open (nonhw_file, "r") as myfile:
-                results = myfile.read()
-                bb.warn( "[kernel config]: BSP specified non-hw

configuration:\n\n%s" % results)

meta/classes/kernel-yocto.bbclass +0 -8

-
-    bsp_desc = "${S}/" + kmeta + "/" + "top_tgt"
-    if os.path.exists(bsp_desc) and bsp_check_visibility > 1:
-        with open (bsp_desc, "r") as myfile:
-            bsp_tgt = myfile.read()
-            m = re.match("^(.*)scratch.obj(.*)$", bsp_tgt)
-            if not m is None:
-                bb.warn( "[kernel]: An auto generated BSP description was

used, this normally indicates a misconfiguration.\n" +
- "Check that your machine (%s) has an associated
kernel description." % "${MACHINE}" )
}

# Ensure that the branches (BSP and meta) are on the locations specified
by

meta/recipes-kernel/kern-tools/kern-tools-native_git.bb +0 -1

index c3ded98..6877a0c 100644
@@ -1,10 +1,10 @@
 SUMMARY = "Tools for managing Yocto Project style branched kernels"
 LICENSE = "GPLv2"
-LIC_FILES_CHKSUM =

"file://git/tools/kgit;beginline=5;endline=9;md5=d8d1d729a70cd5f52972f8884 b80743d"
+LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1bda400e2828845 ba0d06c"

DEPENDS = "git-native"

meta/recipes-kernel/kern-tools/kern-tools-native_git.bb +1 -2

-SRCREV = "a6a6f6e1e738d2ecd26b675e9bec867105703416"
+SRCREV = "4b5de9011b31ff92ba2b6e052ab818b09affd905"
 PR = "r12"
 PV = "0.2+git${SRCPV}"
 
--

2.5.0

Quoted 7 lines · André Draszik

My kmeta stuff is located directly inside two meta-* layers (i.e. not in an
extra git repo), where the 2nd layer's kernel recipes .bbappends to the 1st
one with additional kmeta things.

Quoted 8 lines

This used to work fine, but since this commit it doesn't anymore as only the
kmeta stuff from the 2nd layer is being copied into workdir.

Have I been doing something that wasn't guaranteed / supposed to work in the
first place? Or should that still work? Is it worth fixing or should I rethink my approach?

That was complexity that I had tried to remove, but thinking on it a bit, I think I can restore that without adding much complexity.

I'm just finishing work on the 4.8 kernel today, and can look at this tomorrow.

Do you have any public layers that I can reference to pull together a test case ?

Quoted 17 lines · Bruce Ashfield

Quoted 15 lines · André Draszik

My kmeta stuff is located directly inside two meta-* layers (i.e. not in an
extra git repo), where the 2nd layer's kernel recipes .bbappends to the 1st
one with additional kmeta things.

This used to work fine, but since this commit it doesn't anymore as only the
kmeta stuff from the 2nd layer is being copied into workdir.

Have I been doing something that wasn't guaranteed / supposed to work in the
first place? Or should that still work? Is it worth fixing or should I rethink my approach?

Quoted 5 lines

That was complexity that I had tried to remove, but thinking on it a bit, I think I can restore that without adding much complexity.

I'm just finishing work on the 4.8 kernel today, and can look at this tomorrow.

Thank you Bruce!

Quoted 3 lines

Do you have any public layers that I can reference to pull together a test case ?

Unfortunately not :-(

But I'm happy to test and report back!

Cheers,
Andre'

Can you clarify for me if you are are using SRC_URI items tagged with 'kmeta', i.e. a directory of fragments, or are you just adding .cfg/.scc items directly to the SRC_URI ?

Quoted 3 lines · Bruce Ashfield

Can you clarify for me if you are are using SRC_URI items tagged with 'kmeta', i.e. a directory of fragments, or are you just adding .cfg/.scc items directly to the SRC_URI ?

I do both:

in the 1st layer, my kernel recipe boils down to:

SRC_URI = "\
    git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git;protocol=git;nocheckout=1;branch=${KBRANCH} \
    file://0001-a-patch.patch \
    file://kernel-meta;type=kmeta;destsuffix=${KMETA} \

"

KERNEL_FEATURES_append = " patches/some-patches.scc" KERNEL_FEATURES_append = " patches/more-patches.scc" KERNEL_FEATURES_append = " patches/even-more-patches.scc"

some of the above in turn include additional .scc items recursively.

In the 2nd layer, my .bbappend boils down to:

FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}-4.4:"

KERNEL_FEATURES_append_tgm = " patches/tgm.scc"

2nd-layer.scc is located in ${THISDIR}/kernel-meta/patches/ in the 2nd layer. I don't specifically add another SRC_URI item tagged with 'kmeta' (or any other explicit SRC_URI item for that matter).

Andre'

Quoted 32 lines · André Draszik

Quoted 5 lines · Bruce Ashfield

Can you clarify for me if you are are using SRC_URI items tagged with 'kmeta', i.e. a directory of fragments, or are you just adding .cfg/.scc
items directly to the SRC_URI ?

I do both:

in the 1st layer, my kernel recipe boils down to:

SRC_URI = "\
    git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-
stable.git;protocol=git;nocheckout=1;branch=${KBRANCH} \
    file://0001-a-patch.patch \
    file://kernel-meta;type=kmeta;destsuffix=${KMETA} \
"

KERNEL_FEATURES_append = " patches/some-patches.scc" KERNEL_FEATURES_append = " patches/more-patches.scc" KERNEL_FEATURES_append = " patches/even-more-patches.scc"

some of the above in turn include additional .scc items recursively.

In the 2nd layer, my .bbappend boils down to:

FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}-4.4:"

KERNEL_FEATURES_append_tgm = " patches/tgm.scc"

Quoted 4 lines

2nd-layer.scc is located in ${THISDIR}/kernel-meta/patches/ in the 2nd layer. I don't specifically add another SRC_URI item tagged with 'kmeta' (or
any other explicit SRC_URI item for that matter).

One more clarification. From our problem description, are you saying that in your runs, only the meta data from layer2 is getting copied and not that from layer1 ?

I ran my sanity test, and saw meta data from both my layers copied .. so I'm worried that I misunderstood the issue you are seeing.

But looking at the code, I can definitely do some minor tweaks in this area .. I'm just trying to get the reproducer nailed down.

Quoted 33 lines · Bruce Ashfield

Quoted 32 lines · André Draszik

Quoted 5 lines · Bruce Ashfield

Can you clarify for me if you are are using SRC_URI items tagged with 'kmeta', i.e. a directory of fragments, or are you just adding .cfg/.scc
items directly to the SRC_URI ?

I do both:

in the 1st layer, my kernel recipe boils down to:

SRC_URI = "\
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-

stable.git;protocol=git;nocheckout=1;branch=${KBRANCH} \
    file://0001-a-patch.patch \
    file://kernel-meta;type=kmeta;destsuffix=${KMETA} \

"

KERNEL_FEATURES_append = " patches/some-patches.scc" KERNEL_FEATURES_append = " patches/more-patches.scc" KERNEL_FEATURES_append = " patches/even-more-patches.scc"

some of the above in turn include additional .scc items recursively.

In the 2nd layer, my .bbappend boils down to:

FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}-4.4:"

KERNEL_FEATURES_append_tgm = " patches/tgm.scc"

Quoted 8 lines

Quoted 4 lines

2nd-layer.scc is located in ${THISDIR}/kernel-meta/patches/ in the 2nd layer. I don't specifically add another SRC_URI item tagged with 'kmeta' (or
any other explicit SRC_URI item for that matter).

One more clarification. From our problem description, are you saying that in your runs, only the meta data from layer2 is getting copied and not that from layer1 ?

That is what I had inferred from the error message:

| DEBUG: Executing shell function do_kernel_metadata
| ERROR. input file "patches/some-patches.scc" does not exist
| ERROR: could not process input files: <2nd_layer>/recipes-kernel/linux/linux-ramips-4.4/tgm/defconfig <1st_layer>/recipes-kernel/linux/linux-ramips-4.4/0001-a-patch.patch patches/some-patches.scc patches/more-patches.scc patches/even-more-patches.scc patches/tgm.scc
|        See /tmp/tmp.mPP1jtatxm for details
| ERROR. input file "patches/some-patches.scc" does not exist
| ERROR: could not process input files: <2nd_layer>/recipes-kernel/linux/linux-ramips-4.4/tgm/defconfig <1st_layer>/recipes-kernel/linux/linux-ramips-4.4/0001-a-patch.patch patches/some-patches.scc patches/more-patches.scc patches/even-more-patches.scc patches/tgm.scc
|        See /tmp/tmp.v9LU9ccpbl for details
| WARNING: exit code 1 from a shell command.

Quoted 2 lines

I ran my sanity test, and saw meta data from both my layers copied .. so I'm worried that I misunderstood the issue you are seeing.

I can see that they are actually copied indeed, but it doesn't find them... The file /tmp/tmp.v9LU9ccpbl mentioned above is empty.

Quoted 3 lines

But looking at the code, I can definitely do some minor tweaks in this area .. I'm just trying to get the reproducer nailed down.

I can try to create one for you if you prefer tomorrow, rather than wasting your time with this, if you don't get any further?

Andre'

Quoted 33 lines · Bruce Ashfield

Quoted 32 lines · André Draszik

Quoted 5 lines · Bruce Ashfield

Can you clarify for me if you are are using SRC_URI items tagged with 'kmeta', i.e. a directory of fragments, or are you just adding .cfg/.scc
items directly to the SRC_URI ?

I do both:

in the 1st layer, my kernel recipe boils down to:

SRC_URI = "\
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-

stable.git;protocol=git;nocheckout=1;branch=${KBRANCH} \
    file://0001-a-patch.patch \
    file://kernel-meta;type=kmeta;destsuffix=${KMETA} \

"

KERNEL_FEATURES_append = " patches/some-patches.scc" KERNEL_FEATURES_append = " patches/more-patches.scc" KERNEL_FEATURES_append = " patches/even-more-patches.scc"

some of the above in turn include additional .scc items recursively.

In the 2nd layer, my .bbappend boils down to:

FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}-4.4:"

KERNEL_FEATURES_append_tgm = " patches/tgm.scc"

Quoted 8 lines

Quoted 4 lines

2nd-layer.scc is located in ${THISDIR}/kernel-meta/patches/ in the 2nd layer. I don't specifically add another SRC_URI item tagged with 'kmeta' (or
any other explicit SRC_URI item for that matter).

One more clarification. From our problem description, are you saying that in your runs, only the meta data from layer2 is getting copied and not that from layer1 ?

That is what I had inferred from the error message:

| DEBUG: Executing shell function do_kernel_metadata
| ERROR. input file "patches/some-patches.scc" does not exist
| ERROR: could not process input files: <2nd_layer>/recipes-kernel/linux/linux-ramips-4.4/tgm/defconfig <1st_layer>/recipes-kernel/linux/linux-ramips-4.4/0001-a-patch.patch patches/some-patches.scc patches/more-patches.scc patches/even-more-patches.scc patches/tgm.scc
|        See /tmp/tmp.mPP1jtatxm for details
| ERROR. input file "patches/some-patches.scc" does not exist
| ERROR: could not process input files: <2nd_layer>/recipes-kernel/linux/linux-ramips-4.4/tgm/defconfig <1st_layer>/recipes-kernel/linux/linux-ramips-4.4/0001-a-patch.patch patches/some-patches.scc patches/more-patches.scc patches/even-more-patches.scc patches/tgm.scc
|        See /tmp/tmp.v9LU9ccpbl for details
| WARNING: exit code 1 from a shell command.

Quoted 2 lines

I ran my sanity test, and saw meta data from both my layers copied .. so I'm worried that I misunderstood the issue you are seeing.

I can see that they are actually copied indeed, but it doesn't find them... The file /tmp/tmp.v9LU9ccpbl mentioned above is empty.

Quoted 2 lines

But looking at the code, I can definitely do some minor tweaks in this area .. I'm just trying to get the reproducer nailed down.

I can try to create one for you if you prefer tomorrow, rather than wasting your time with this, if you don't get any further?

Andre'

Quoted 74 lines · André Draszik

Quoted 39 lines · Bruce Ashfield

Quoted 30 lines · André Draszik

Quoted 5 lines · Bruce Ashfield

Can you clarify for me if you are are using SRC_URI items tagged with 'kmeta', i.e. a directory of fragments, or are you just adding .cfg/.scc
items directly to the SRC_URI ?

I do both:

in the 1st layer, my kernel recipe boils down to:

SRC_URI = "\
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-

stable.git;protocol=git;nocheckout=1;branch=${KBRANCH} \
    file://0001-a-patch.patch \
    file://kernel-meta;type=kmeta;destsuffix=${KMETA} \

"

KERNEL_FEATURES_append = " patches/some-patches.scc" KERNEL_FEATURES_append = " patches/more-patches.scc" KERNEL_FEATURES_append = " patches/even-more-patches.scc"

some of the above in turn include additional .scc items recursively.

In the 2nd layer, my .bbappend boils down to:

FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}-4.4:"

Quoted 7 lines

KERNEL_FEATURES_append_tgm = " patches/tgm.scc"

2nd-layer.scc is located in ${THISDIR}/kernel-meta/patches/ in the 2nd layer. I don't specifically add another SRC_URI item tagged with 'kmeta'
(or
any other explicit SRC_URI item for that matter).

Quoted 3 lines

One more clarification. From our problem description, are you saying that in your runs, only the meta data from layer2 is getting copied and not that from layer1 ?

That is what I had inferred from the error message:

| DEBUG: Executing shell function do_kernel_metadata
| ERROR. input file "patches/some-patches.scc" does not exist
| ERROR: could not process input files:

<2nd_layer>/recipes-kernel/linux/linux-ramips-4.4/tgm/defconfig <1st_layer>/recipes-kernel/linux/linux-ramips-4.4/0001-a-patch.patch patches/some-patches.scc patches/more-patches.scc patches/even-more-patches.scc patches/tgm.scc

|        See /tmp/tmp.mPP1jtatxm for details
| ERROR. input file "patches/some-patches.scc" does not exist
| ERROR: could not process input files:

<2nd_layer>/recipes-kernel/linux/linux-ramips-4.4/tgm/defconfig <1st_layer>/recipes-kernel/linux/linux-ramips-4.4/0001-a-patch.patch patches/some-patches.scc patches/more-patches.scc patches/even-more-patches.scc patches/tgm.scc
| See /tmp/tmp.v9LU9ccpbl for details
| WARNING: exit code 1 from a shell command.

Quoted 2 lines

I ran my sanity test, and saw meta data from both my layers copied .. so I'm worried that I misunderstood the issue you are seeing.

I can see that they are actually copied indeed, but it doesn't find them...
The file /tmp/tmp.v9LU9ccpbl mentioned above is empty.

Quoted 2 lines

But looking at the code, I can definitely do some minor tweaks in this area .. I'm just trying to get the reproducer nailed down.

Quoted 3 lines

I can try to create one for you if you prefer tomorrow, rather than wasting
your time with this, if you don't get any further?

I was able to trigger a similar trap to the above. And yes, it was sort of working by luck before.

I need to stare at this for a few hours and figure out the right way to restore similar behaviour. But now .. sleep.

Cheers,

Bruce

Quoted 4 lines

Andre'

Are the important part of this series, and a significant contribution to the
fall release. I've been testing these for some time, and we've run the kernel lab and yocto-bsp scripts against the tools. We haven't found a regression yet, but I'm sure there are some lurking. These definitely need cycles on the autobuilders.

On 15 August 2016 at 19:26, Bruce Ashfield <[email protected] <mailto:[email protected]>> wrote:

Are the important part of this series, and a significant contribution to the
fall release. I've been testing these for some time, and we've run the kernel lab and yocto-bsp scripts against the tools. We haven't found a regression yet, but I'm sure there are some lurking. These definitely need
cycles on the autobuilders.

qemux86 throws these warnings at me:

WARNING: linux-yocto-4.4.15+gitAUTOINC+b030d96c7b_ddab242999-r0
do_kernel_configcheck: [kernel config]: specified values did not make it into the kernel's final configuration:

---------- CONFIG_BT_6LOWPAN -----------------
Config: CONFIG_BT_6LOWPAN
From:
/data/poky-master/tmp-glibc/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/features/bluetooth/bluetooth.cfg Requested value: CONFIG_BT_6LOWPAN=y
Actual value:

Config 'BT_6LOWPAN' has the following conditionals:
BT_LE && 6LOWPAN (value: "n")
Dependency values are:
BT_LE [y] 6LOWPAN [n]

---------- CONFIG_BT_CMTP -----------------
Config: CONFIG_BT_CMTP
From:
/data/poky-master/tmp-glibc/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/features/bluetooth/bluetooth.cfg Requested value: CONFIG_BT_CMTP=m
Actual value:

Config 'BT_CMTP' has the following conditionals:
BT_BREDR && ISDN_CAPI (value: "n")
Dependency values are:
BT_BREDR [y] ISDN_CAPI [n]

Ross

Yep, that was covered in my 0/N:

On 16 August 2016 at 17:01, Bruce Ashfield <[email protected] <mailto:[email protected]>> wrote:

Yep, that was covered in my 0/N:

<cough>

I'll get my coat.

Ross

... and hopefully hit me with it for hiding that note way down in a TL;DR 0/N message.