[yocto] Kernel config incremental modification not working.

[Bruce Ashfield]

On 2016-12-11 02:33 PM, Paul Eggleton wrote:
> On Fri, 09 Dec 2016 11:19:56 Bruce Ashfield 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-gnu
>>> eabi/linux-altera-ltsi/4.1.22-ltsi+gitAUTOINC+76bdba2700-r0/temp/log.do_ke
>>> rnel_metadata.28274) ERROR: Logfile of failure stored in:
>>> /scratch/gizero/mitysom-5csx-master-build/tmp/work/cyclone5-poky-linux-gnu
>>> eabi/linux-altera-ltsi/4.1.22-ltsi+gitAUTOINC+76bdba2700-r0/temp/log.do_ke
>>> rnel_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-gnu
>>> eabi/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-gnu
>>> eabi/linux-altera-ltsi/4.1.22-ltsi+gitAUTOINC+76bdba2700-r0/temp/log.do_ke
>>> rnel_metadata.28274) ERROR: Task
>>> (/home/gizero/work/decos/repo-master/poky/../meta-altera/recipes-kernel/li
>>> nux/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.
>
> Can we please have some automated tests covering all of this? Perhaps it would
> be worth talking to Francisco Pedraza who is looking at adding tests under bug
> 6359:

We are already meeting to talk about this :D

Bruce

>
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=6359
>
> Cheers,
> Paul
>