On 2016-12-09 11:17 AM, Andrea Galbusera wrote:
Hi Bruce,

On Thu, Dec 8, 2016 at 3:36 PM, Bruce Ashfield
<bruce.ashfi...@windriver.com <mailto:bruce.ashfi...@windriver.com>> wrote:

    On 2016-12-08 09:06 AM, Bent Bisballe Nyeng wrote:

        Hi list

        I am working on a project based on the iMX6UL-EVK using the
        meta-fsl-arm
        layer for the kernel.
        In a local layer I have a bbappend recipe containing a patch for an
        extra kernel feature (a framebuffer device) in that kernel as
        well as a
        .cfg enabling said feature.
        The bbappend recipe is located in
        recipes-kernel/linux/linux-fslc-imx_%.bbappend and looks like this:
        FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

        SRC_URI += " \
                file://0001-mxc-4.1.patch \
                file://ST7789S.cfg \
        "

        KERNEL_DEVICETREE = "imx6ul-14x14-evk.dtb"

        The .cfg is located in
        recipes-kernel/linux/linux-fslc-imx/ST7789S.cfg
        and looks like:
        CONFIG_FB_MXS_ST7789S_QVGA=y

        The 0001-mxc-4.1.patch patch is correctly applied but the .cfg
        is either
        ignored or overwritten by some later buyild step since the resulting
        .config after kernel compilation contains:
        # CONFIG_FB_MXS_ST7789S_QVGA is not set

        I have tried finding the script in the build/.../temp folder
        that takes
        care of the .cfg file patching but have not been able to find
        anything
        useful.

        Any hints as to where I should start looking for a solution?


    Fragment processing using the kernel tools + auditing is only currently
    available to kernel recipes that use the kernel-yocto bbclass. That
    opt-in requirement was to ensure that existing recipes and workflows
    weren't broken by the new features.

    Last time I checked, the meta-fsl* kernel recipes don't use the
    kernel-yocto bbclass, so the fragment would be ignored.

    I'm taking the processing of fragments and making it universally
    available in the upcoming 2.3 release, so what I just described
    won't be an issue for much longer.

    In the mean time, you have a few options:

     - in your bbappend, add "inherit kernel-yocto" and the processing
       of fragments will be enabled (I can't say that I've tested
       it against that recipe .. but the entire point of the new tasks
       is that they are transparent/don't break existing worflows)

     - carry a defconfig in your layer, and add it to the SRC_URI. That
       defconfig would be the existing kernel recipe's defconfig + your
       options


I was just testing one of my layers against your recent patchset on
kernel-yocto when I noticed this thread. My build is broken by commit
476ffd57cf5b6fba40d4e3f5dd913824ab8a8d3d on oe-core
(e38775a1d82e6dc60fc96cf243ecb94be964d9b2 on the poky repo side).

WARNING: linux-altera-ltsi-4.1.22-ltsi+gitAUTOINC+76bdba2700-r0
do_kernel_metadata: GIZERO: before 'cmp'
ERROR: linux-altera-ltsi-4.1.22-ltsi+gitAUTOINC+76bdba2700-r0
do_kernel_metadata: Function failed: do_kernel_metadata (log file is
located at
/scratch/gizero/mitysom-5csx-master-build/tmp/work/cyclone5-poky-linux-gnueabi/linux-altera-ltsi/4.1.22-ltsi+gitAUTOINC+76bdba2700-r0/temp/log.do_kernel_metadata.28274)
ERROR: Logfile of failure stored in:
/scratch/gizero/mitysom-5csx-master-build/tmp/work/cyclone5-poky-linux-gnueabi/linux-altera-ltsi/4.1.22-ltsi+gitAUTOINC+76bdba2700-r0/temp/log.do_kernel_metadata.28274
Log data follows:
| DEBUG: Executing shell function do_kernel_metadata
| WARNING: GIZERO: before 'cmp'
|
/scratch/gizero/mitysom-5csx-master-build/tmp/work/cyclone5-poky-linux-gnueabi/linux-altera-ltsi/4.1.22-ltsi+gitAUTOINC+76bdba2700-r0/defconfig
/scratch/gizero/mitysom-5csx-master-build/tmp/work-shared/cyclone5/kernel-source/arch/arm/configs/socfpga_defconfig
differ: byte 1525, line 72
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_kernel_metadata (log file is located at
/scratch/gizero/mitysom-5csx-master-build/tmp/work/cyclone5-poky-linux-gnueabi/linux-altera-ltsi/4.1.22-ltsi+gitAUTOINC+76bdba2700-r0/temp/log.do_kernel_metadata.28274)
ERROR: Task
(/home/gizero/work/decos/repo-master/poky/../meta-altera/recipes-kernel/linux/linux-altera-ltsi_4.1.22.bb:do_kernel_metadata)
failed with exit code '1'

The commit in the patch remove the 'set +e' bits, but the following
legit code path expects the cmp command to have a non-zero return value.

        if [ -n "${KBUILD_DEFCONFIG}" ]; then
                if [ -f "${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}"
]; then
                        if [ -f "${WORKDIR}/defconfig" ]; then
                                # If the two defconfig's are different,
warn that we didn't overwrite the
                                # one already placed in WORKDIR by the
fetcher.
                                cmp "${WORKDIR}/defconfig"
"${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}"
                                if [ $? -ne 0 ]; then
                                        bbwarn "defconfig detected in
WORKDIR. ${KBUILD_DEFCONFIG} skipped"
                                fi

My layer provides a defconfig on top of a bsp layer which
defines KBUILD_DEFCONFIG. So, in my opinion, if this scenario is still
supported as you confirm in this thread, we should expect cmp to always
return nonzero when this is the case.

Sorry for posting here, but I wasn't subscribed to the oe-core mailing
list, so I don't have the original email to oe-core mailing list with
the patch to reply to...

attached is the patch that should fix the issue. I'll send it to oe-core
later today once I've done more testing.

Bruce




     - write a custom task that runs before configuration to add your
       options (cat, merge, etc, etc).

    I wouldn't really suggest the custom task route, but it is a valid
    option, so I put it in my list.

    The quickest is probably the defconfig option, and then the new
    inherit. If you had issues with the inherit, I could lend a hand to
    debug what is wrong .. since I'll run into it eventually with my
    feature work for the 2.3 release.

    Bruce




        Kind regards
        Bent Bisballe Nyeng


    --
    _______________________________________________
    yocto mailing list
    yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
    https://lists.yoctoproject.org/listinfo/yocto
    <https://lists.yoctoproject.org/listinfo/yocto>



>From db987543ed78a7c2747428ca97aae84d9f2473fb Mon Sep 17 00:00:00 2001
From: Bruce Ashfield <bruce.ashfi...@windriver.com>
Date: Fri, 9 Dec 2016 11:38:34 -0500
Subject: [PATCH] kernel-yocto: explicitly trap subcommand errors

To trap errors and halt processing, do_kernel_metadata was recently
switched to exit on any non zero return code. While the concept is
sound, there are subcommands that have legitimate non-zero return
codes.

Instead of removing set +e, we'll explicitly check the return code
of the commands that can error, and throw a bbfatal to alert the
user.

Signed-off-by: Bruce Ashfield <bruce.ashfi...@windriver.com>
---
 meta/classes/kernel-yocto.bbclass | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-yocto.bbclass
index cd34a4cf9aef..8d8d9fc9db6f 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -75,6 +75,7 @@ def get_machine_branch(d, default):
     return default
 
 do_kernel_metadata() {
+	set +e
 	cd ${S}
 	export KMETA=${KMETA}
 
@@ -156,12 +157,18 @@ do_kernel_metadata() {
 	elements="`echo -n ${bsp_definition} ${sccs} ${patches} ${KERNEL_FEATURES}`"
 	if [ -n "${elements}" ]; then
 		scc --force -o ${S}/${meta_dir}:cfg,meta ${includes} ${bsp_definition} ${sccs} ${patches} ${KERNEL_FEATURES}
+		if [ $? -ne 0 ]; then
+			bbfatal_log "Could not generate configuration queue for ${KMACHINE}."
+		fi
 	fi
 
 	# run2: only generate patches for elements that have been passed on the SRC_URI
 	elements="`echo -n ${sccs} ${patches} ${KERNEL_FEATURES}`"
 	if [ -n "${elements}" ]; then
 		scc --force -o ${S}/${meta_dir}:patch --cmds patch ${includes} ${sccs} ${patches} ${KERNEL_FEATURES}
+		if [ $? -ne 0 ]; then
+			bbfatal_log "Could not generate configuration queue for ${KMACHINE}."
+		fi
 	fi
 }
 
-- 
2.5.0

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

Reply via email to