New: unable to build u-boot.imx reliably

https://bugs.busybox.net/show_bug.cgi?id=10161

Bug ID: 10161
Summary: unable to build u-boot.imx reliably
Product: buildroot
Version: unspecified
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P5
Component: Other
Assignee: unassigned at buildroot.uclibc.org
Reporter: yurovsky at gmail.com
CC: buildroot at uclibc.org
Target Milestone: ---

Created attachment 7156
--> https://bugs.busybox.net/attachment.cgi?id=7156&action=edit
hacky workaround

I'm unable to build the u-boot.imx image (for Freescale i.MX SoCs) reliably (that is, it generally works but if I "slow down" my system by making the CPUs busy, or use a slower machine, I can break the build very often).

The issue seems to be in u-boot's build system but I'm not certain so I wanted to check if there's anything that we might be doing in buildroot that should be done differently before taking this up with them.

To build the i.MX image the config should have:

BR2_TARGET_UBOOT_FORMAT_IMX=y

(and be one of the i.MX targets anyway since we need a board target in u-boot). What happens is u-boot will process a template config file and eventually mkimage is run to generate the .imx image using the .cfg files in the board directory. The build will fail because the processed .cfg isn't found and it seems that the .cfg was in fact built, it just raced with the image step.

I have a workaround that, while hacky, shows that we can prevent the problem by making those steps less parallel (attached).

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=10161

--- Comment #1 from Arnout Vandecappelle <[email protected]> --- Without any other evidence, we can only assume it's an issue with the U-Boot build system. And something that is very hard to fix at the Buildroot level:
since we don't know which U-Boot version is being used, we can't easily patch it.

I have done a quick review of the Makefile for imx in the U-Boot source, and it looks good to me. But you haven't really given sufficient information to pinpoint the problem. You should try to reproduce with V=1 so we get usable output. And also try to reproduce outside of Buildroot - should be easy, you basically just have to run 'make CROSS_COMPILE=... ARCH=arm ..._defconfig; make CROSS_COMPILE=... ARCH=arm V=1 u-boot.imx'.

Or perhaps it only happens when you try to build u-boot.imx and u-boot-dtb.imx in parallel?

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=10161

--- Comment #2 from Andrey Yurovsky <[email protected]> --- Sorry, I meant to say I tried 2017.05 and 2017.07. I'll reproduce this and post output, however the output is a bit unclear (even at V=1) because this is a parallel make problem so we're dealing with some kind of race condition.

I believe that I can only reproduce it by building the way buildroot does (one make invocation with multiple targets), the attached workaround patch shows that we avoid the problem by invoking make twice.

I'll try to reproduce this with u-boot on its own. The Makefile portions dealing with building a .imx image have changed significantly between 2017.05 and 2017.07.

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=10161

--- Comment #3 from Thomas Petazzoni <[email protected]> --- I also believe that Buildroot is not at fault here, it's U-Boot build system that doesn't have the proper dependencies. Could you report this issue to upstream U-Boot instead ? I'm pretty sure you can reproduce it outside of Buildroot by running the same build commands.

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=10161

Thomas Petazzoni <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

         Resolution|---                         |WONTFIX
             Status|NEW                         |RESOLVED

--- Comment #4 from Thomas Petazzoni <[email protected]> --- This problem clearly seems to be a U-Boot issue, so it should be reported to the upstream U-Boot project instead.

You are receiving this mail because:
You are on the CC list for the bug.