Hi Michael, On Wed, 10 Nov 2021 at 01:28, Michael Walle <mich...@walle.cc> wrote: > > Am 2021-11-10 02:37, schrieb Tom Rini: > > On Wed, Nov 10, 2021 at 01:26:12AM +0100, Rasmus Villemoes wrote: > >> On 10/11/2021 01.18, Rasmus Villemoes wrote: > >> > On 09/11/2021 20.42, Tom Rini wrote: > >> >> On Tue, Nov 09, 2021 at 08:21:07PM +0100, Heiko Thiery wrote: > >> >>> Hi Wolfgang, > >> >>> > >> > > >> >>> I know this is not a perfect solution but I don't know how to get my > >> >>> board merged without doing this kind of workaround for the U-Boot CI. > >> >> > >> >> Unfortunately in these days of needing multiple inputs to create a > >> >> functional image and also needing to have CI be able to be at all > >> >> useful, what we do in many many many cases is yell loudly to the user > >> >> that the resulting file here will NOT work and why. So yes, some "yell > >> >> it won't work but not return non-zero exit status" is the norm. > >> >> > >> >> I would be very much open however to some way to handle this > >> >> differently. Some environment variable our tools check for and then > >> >> yell-but-succeed? Some other idea? I'm just thinking out loud here. > >> > > >> > Yes, I believe the build system must be taught some env var (or other > >> > means) for opting in to this behavior. > >> > >> Oh, and it should of course only paper over missing binary blobs, not > >> arbitrary errors from mkimage or other tools. The easiest way to do > >> that > >> is probably to create some dummy blob(s) [only when > >> CREATE_BROKEN_IMAGES > >> is set of course] before calling the tool that will consume the blobs. > > > > Some patches along those lines would be most welcome :) > > If I understand Simon correctly, then it is possible to fill in missing > blobs later with binman (or an fit image in general?). Which is quite > useful in a build system, because you don't have a chain of dependent > packages, but you can assemble all the binaries in a final step.
Yes binman is designed to handle that final step, but it is also useful to do a 'preiminary' build in-tree when there are missing images. It is possible to use the 'replace' command to update images after the image is built. It should continue to follow the various rules in the image definition. But it is better to just build the whole image from scratch once everything is there. > > But this also means, that "missing binary blobs" are not an error but > may even be expected. Unfortunately, this all falls apart if the binary > is inside an image produced by mkimage (like the hdmi phy firmware in > for the imx8). Though the finaly image is generated by binman, you > cannot replace/insert the hdmi phy firmware later on [except you'd > unpack the imx image, replace the firmware, pack it again and then > replace it again in the outer image]. IMHO quite a drawback if we're > saying binman isn't replacing mkimage. We need all the binaries to be available at once to package the image. Looking at the above, we could perhaps do one of two things: - add a flag to mkimage to tell it to use an empty file for anything missing (would need to know if it did so with an exit code) - update binman to create empty files for mkimage for anything that is missing, before calling mkimage (this would be a little harder as we would need to understand the FIT format in the image defintiion) That way, binman can know whether the image is valid or not. Regards, Simon
