<div dir="ltr">Hi Bruce,<div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 8, 2016 at 3:36 PM, Bruce Ashfield <span dir="ltr"><<a href="mailto:bruce.ashfield@windriver.com" target="_blank">bruce.ashfield@windriver.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">On 2016-12-08 09:06 AM, Bent Bisballe Nyeng wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hi list<br>
<br>
I am working on a project based on the iMX6UL-EVK using the meta-fsl-arm<br>
layer for the kernel.<br>
In a local layer I have a bbappend recipe containing a patch for an<br>
extra kernel feature (a framebuffer device) in that kernel as well as a<br>
.cfg enabling said feature.<br>
The bbappend recipe is located in<br>
recipes-kernel/linux/linux-fsl<wbr>c-imx_%.bbappend and looks like this:<br>
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"<br>
<br>
SRC_URI += " \<br>
  Â  Â  Â  file://0001-mxc-4.1.patch \<br>
  Â  Â  Â  file://ST7789S.cfg \<br>
"<br>
<br>
KERNEL_DEVICETREE = "imx6ul-14x14-evk.dtb"<br>
<br>
The .cfg is located in recipes-kernel/linux/linux-fsl<wbr>c-imx/ST7789S.cfg<br>
and looks like:<br>
CONFIG_FB_MXS_ST7789S_QVGA=y<br>
<br>
The 0001-mxc-4.1.patch patch is correctly applied but the .cfg is either<br>
ignored or overwritten by some later buyild step since the resulting<br>
.config after kernel compilation contains:<br>
# CONFIG_FB_MXS_ST7789S_QVGA is not set<br>
<br>
I have tried finding the script in the build/.../temp folder that takes<br>
care of the .cfg file patching but have not been able to find anything<br>
useful.<br>
<br>
Any hints as to where I should start looking for a solution?<br>
</blockquote>
<br></div></div>
Fragment processing using the kernel tools + auditing is only currently<br>
available to kernel recipes that use the kernel-yocto bbclass. That<br>
opt-in requirement was to ensure that existing recipes and workflows<br>
weren't broken by the new features.<br>
<br>
Last time I checked, the meta-fsl* kernel recipes don't use the<br>
kernel-yocto bbclass, so the fragment would be ignored.<br>
<br>
I'm taking the processing of fragments and making it universally<br>
available in the upcoming 2.3 release, so what I just described<br>
won't be an issue for much longer.<br>
<br>
In the mean time, you have a few options:<br>
<br>
 - in your bbappend, add "inherit kernel-yocto" and the processing<br>
  Â of fragments will be enabled (I can't say that I've tested<br>
  Â it against that recipe .. but the entire point of the new tasks<br>
  Â is that they are transparent/don't break existing worflows)<br>
<br>
 - carry a defconfig in your layer, and add it to the SRC_URI. That<br>
  Â defconfig would be the existing kernel recipe's defconfig + your<br>
  Â options<br></blockquote><div><br></div><div>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).</div><div><br></div><div><div>WARNING: linux-altera-ltsi-4.1.22-ltsi+gitAUTOINC+76bdba2700-r0 do_kernel_metadata: GIZERO: before 'cmp'</div><div>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)</div><div>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</div><div>Log data follows:</div><div>| DEBUG: Executing shell function do_kernel_metadata</div><div>| WARNING: GIZERO: before 'cmp'</div><div>| /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</div><div>| WARNING: exit code 1 from a shell command.</div><div>| 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)</div><div>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'</div></div><div><br></div><div>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.</div><div><br></div><div><div>  Â  Â  Â  if [ -n "${KBUILD_DEFCONFIG}" ]; then</div><div>  Â  Â  Â  Â  Â  Â  Â  if [ -f "${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}" ]; then</div><div>  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  if [ -f "${WORKDIR}/defconfig" ]; then</div><div>  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  # If the two defconfig's are different, warn that we didn't overwrite the</div><div>  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  # one already placed in WORKDIR by the fetcher.</div><div>  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  cmp "${WORKDIR}/defconfig" "${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}"<br></div><div>  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  if [ $? -ne 0 ]; then</div><div>  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  bbwarn "defconfig detected in WORKDIR. ${KBUILD_DEFCONFIG} skipped"</div><div>  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  fi</div></div><div><br></div><div>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.</div><div><br></div><div>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...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
 - write a custom task that runs before configuration to add your<br>
  Â options (cat, merge, etc, etc).<br>
<br>
I wouldn't really suggest the custom task route, but it is a valid<br>
option, so I put it in my list.<br>
<br>
The quickest is probably the defconfig option, and then the new<br>
inherit. If you had issues with the inherit, I could lend a hand to<br>
debug what is wrong .. since I'll run into it eventually with my<br>
feature work for the 2.3 release.<span class="gmail-HOEnZb"><font color="#888888"><br>
<br>
Bruce</font></span><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Kind regards<br>
Bent Bisballe Nyeng<br>
<br>
</blockquote>
<br>
-- <br>
______________________________<wbr>_________________<br>
yocto mailing list<br>
<a href="mailto:yocto@yoctoproject.org" target="_blank">yocto@yoctoproject.org</a><br>
<a href="https://lists.yoctoproject.org/listinfo/yocto" rel="noreferrer" target="_blank">https://lists.yoctoproject.org<wbr>/listinfo/yocto</a><br>
</div></div></blockquote></div><br></div></div>