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

From: Tom Rini <trini@konsulko.com>
To: Wolfgang Denk <wd@denx.de>
Cc: Heiko Thiery <heiko.thiery@gmail.com>,
	u-boot@lists.denx.de, Stefano Babic <sbabic@denx.de>,
	Fabio Estevam <festevam@gmail.com>,
	Michael Walle <michael@walle.cc>, Simon Glass <sjg@chromium.org>
Subject: Re: [RFC 0/2] Do not stop with an error when mkimage fails
Date: Thu, 11 Nov 2021 10:04:13 -0500	[thread overview]
Message-ID: <20211111150413.GN24579@bill-the-cat> (raw)
In-Reply-To: <1289506.1636633642@gemini.denx.de>

[-- Attachment #1: Type: text/plain, Size: 2086 bytes --]

On Thu, Nov 11, 2021 at 01:27:22PM +0100, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20211109194224.GB24579@bill-the-cat> you wrote:
> > 
> > > The only reason I want to introduce this is because I want to have my
> > > imx8mq board built by CI. This board needs an external HDMI firmware
> > > which is used by mkimage. But because this firmware is not available
> > > in the CI build, it comes to the abort. With other boards it is also
> > > so that in the CI external blobs are not available and these make
> > > nevertheless without error a binman run. In this case only a warning
> > > is output.
> ...
> > 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.
> 
> This is a terrible degradtion from standard programming style, then.

Yes, there's a lot of things to grumble about with firmware for modern
SoCs.

> > 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.
> 
> Well, why not fix the root cause?
> 
> Heiko writes that "an external HDMI firmware" is needed - so the fix
> is to provide one, or at least a dummy file which is good enough for
> the build to succeed.  It should be trivial to create a dummy file
> in the CI context, no?

Yes, generally we provide some dummy file so that we can link and
complain to stdout that things won't function.  This series is (and it
seems like within the confines of "this sucks to have to do as a
concept") updating that mechanism to cover yet another case where we
need some external blob that we either can't redistribute or it would
just be wrong to fork and include some other project within our sources.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]