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.

Bruce



Kind regards
Bent Bisballe Nyeng


--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Reply via email to