Hi Bruce,
On Thu, Dec 8, 2016 at 3:36 PM, Bruce Ashfield <bruce.ashfi...@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.
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@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
