[yocto] Kernel config incremental modification not working.
Andrea Galbusera
gizero at gmail.com
Fri Dec 9 09:43:12 PST 2016
On Fri, Dec 9, 2016 at 5:47 PM, Bruce Ashfield <bruce.ashfield at windriver.com
> wrote:
> 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+gitAUT
>> OINC+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+gitAUT
>> OINC+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+gitAUT
>> OINC+76bdba2700-r0/defconfig
>> /scratch/gizero/mitysom-5csx-master-build/tmp/work-shared/cy
>> clone5/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+gitAUT
>> OINC+76bdba2700-r0/temp/log.do_kernel_metadata.28274)
>> ERROR: Task
>> (/home/gizero/work/decos/repo-master/poky/../meta-altera/rec
>> ipes-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.
Thanks Bruce, FWIW I did a spin with this patch and it did un-brick the
build... \o/
In the meanwhile, I'm beginning to port my defconfig into the more scalable
config fragment approach ;-)
>
>
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20161209/5301acc8/attachment.html>
More information about the yocto
mailing list