On Fri, Dec 9, 2016 at 5:47 PM, Bruce Ashfield <bruce.ashfi...@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.ashfi...@windriver.com <mailto: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+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@yoctoproject.org <mailto:yocto@yoctoproject.org> >> https://lists.yoctoproject.org/listinfo/yocto >> <https://lists.yoctoproject.org/listinfo/yocto> >> >> >> >
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto