[RFC 0/2] Do not stop with an error when mkimage fails

Michael Walle michael at walle.cc
Wed Nov 10 09:28:14 CET 2021


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.

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.

-michael


More information about the U-Boot mailing list