[yocto] Kernel config incremental modification not working.

Bruce Ashfield bruce.ashfield at windriver.com
Fri Dec 9 08:47:54 PST 2016


On 2016-12-09 11:17 AM, Andrea Galbusera wrote:
> Hi Bruce,
>
> On Thu, Dec 8, 2016 at 3:36 PM, Bruce Ashfield
> <bruce.ashfield at windriver.com <mailto:bruce.ashfield at 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 at yoctoproject.org <mailto:yocto at yoctoproject.org>
>     https://lists.yoctoproject.org/listinfo/yocto
>     <https://lists.yoctoproject.org/listinfo/yocto>
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-kernel-yocto-explicitly-trap-subcommand-errors.patch
Type: text/x-patch
Size: 1854 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20161209/f7a59e6b/attachment.bin>


More information about the yocto mailing list