AnsweredAssumed Answered

Patching u-boot "can't find file to patch", how to fetch source?

Question asked by Steven Snyder on Apr 18, 2018
Latest reply on Apr 19, 2018 by Steven Snyder

I'm trying to patch mx6dqscm.c in u-boot IMX with a bbappend file in my custom layer. I get the following error:

ERROR: u-boot-imx-2016.03-r0 do_patch: Command Error: 'quilt --quiltrc /home/ubuntu/imx6/
build-x11/tmp/sysroots/x86_64-linux/etc/quiltrc push' exited with 1  Output:
Applying patch 0001-my-uboot-patch.patch
can't find file to patch at input line 5

 

I checked buildir/tmp/work/imx6dqscm_1gb_custom-poky-linux-gnueabi/u-boot-imx/2016.03-r0/git and there is no source here. It seems the source code for u-boot-imx was never fetched. It seems like bitbake is trying to apply the patches before the source is fetched. Why?

 

I ran `bitbake -c -f fetchall uboot-imx`, but still no source files in tmp/work...  is this a sign something else is wrong?

 

Here is the relevant part of my tree:

meta-my-layer/recipes-bsp/u-boot/u-boot-imx_2016.03.bbappend
meta-my-layer/recipes-bsp/u-boot/u-boot-imx/imx6dqscm-1gb-custom/0001-my-uboot-patch.patch

 

Content of my bappend file, u-boot-imx_2016.03.bbappend:

 

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI_imx6dqscm-1gb-custom += "file://0001-my-uboot-patch.patch"

SRCBRANCH = "scm-imx_v2016.03_4.1.15_2.0.0_ga"
SRCREV = "${AUTOREV}"

COMPATIBLE_MACHINE = "(mx6)"

 

My patch starts with:

diff --git a/board/freescale/mx6dqscm/mx6dqscm.c b/board/freescale/mx6dqscm/mx6dqscm.c
index de08e95..4a20001 100644
--- a/board/freescale/mx6dqscm/mx6dqscm.c
+++ b/board/freescale/mx6dqscm/mx6dqscm.c

 

It looks just like my kernel patches, which work correctly.

 

UPDATE #1 2018/04/19:  If I run `bitbake -c unpack -f u-boot-imx` the source tree gets populated. This implies that the combination of fetch and unpack would get the sources and put them into the working directory, and that bitbake is trying to apply my patch before the `unpack` step. What's going on here?

 

UPDATE #2 2018/04/19: Added my machine-specific SRC_URI above.  It seems this is related to the behavior. I'm not using this in my working kernel bbappend.  I looked at the fetch and unpack logs, and they only work on one file (my first patch) then stop. Seems like a strong hint that my SRC_URI is malformed.

Outcomes