[yocto] Kernel config incremental modification not working.

[Bruce Ashfield]

On 2016-12-09 02:25 AM, Bent Bisballe Nyeng wrote:
> On 12/08/2016 05:06 PM, Bruce Ashfield 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
>>
>>   - 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.
> Hi Bruce
>
> Thanks for the reply.
>
> A quick test shows that the linux-fslc-imx recipe doesn't respond well
> to the 'inherit kernel-yocto' solution failing in the do_kernel_checkout
> task with a "Bad substitution" error message.
> So I think I will go with the defconfig solution until the release of 2.3.
> Any estimate of when 2.3 will be shipping? And do you know if this will
> by any chance include the upcoming 4.9 LTS kernel?

April 2017, and it will have the 4.9 kernel + 4.10 (unless 4.11 really
hurries along).

>
> If you would like some more info on the failing task I'll be happy to
> supply it.

If you put the configuration you are using (bblayers, MACHINE) in an
email and send it directly to me, I'll find time to poke at it, I'm
interested to understand why it failed.

bruce

>
> Thanks for your help :-)
>
> Kind regards
> Bent Bisballe Nyeng
>