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

Tom Rini trini at konsulko.com
Wed Nov 10 02:37:20 CET 2021


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 :)

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20211109/a962b65a/attachment.sig>


More information about the U-Boot mailing list