[yocto] Kernel config incremental modification not working.
Bruce Ashfield
bruce.ashfield at windriver.com
Fri Dec 9 08:19:56 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.
Aha. Indeed that is true. Clearly there aren't many people going
through that path.
I'll spin up a new patch that restores the set +e and instead traps
the return codes for the commands that are allowed to fail.
Bruce
>
> 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...
>
>
>
> - 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>
>
>
More information about the yocto
mailing list