[RFC 0/2] Do not stop with an error when mkimage fails
Simon Glass
sjg at chromium.org
Wed Nov 10 01:58:25 CET 2021
Hi,
On Tue, 9 Nov 2021 at 12:42, Tom Rini <trini at konsulko.com> wrote:
>
> On Tue, Nov 09, 2021 at 08:21:07PM +0100, Heiko Thiery wrote:
> > Hi Wolfgang,
> >
> > Am So., 7. Nov. 2021 um 15:48 Uhr schrieb Wolfgang Denk <wd at denx.de>:
> > >
> > > Dear Heiko,
> > >
> > > In message <CAEyMn7Zgn1ej3kGzg2kiCyqK5DQhkSdXNAUavZGs+3L_fb1Lvg at mail.gmail.com> you wrote:
> > > >
> > > > > > While converting to binman for an imx8mq board, it has been found that
> > > > > > building in the u-boot CI fails. This is because an imx8mq requires an
> > > > > > external binary (signed_hdmi_imx8m.bin). If this file cannot be found
> > > > > > mkimage fails. To work around the problem the exception is caught, an
> > > > > > error message is printed and binman continues.
> > > > >
> > > > > But how can you continue, when mkimage fails and cannot generate the
> > > > > needed image?
> > >
> > > Let me rephrase:
> > >
> > > How can can you continue, when mkimage fails and cannot
> > > _succesfully_ generate the needed image?
> > >
> > > > > In your patch 2/2 we have this:
> > > > >
> > > > > + tools.Run('mkimage', '-d', input_fname, *self._args, output_fname)
> > > > > + except Exception as e:
> > > > > + tout.Error("mkimage failed: %s" % e)
> > > > > +
> > > > > self.SetContents(tools.ReadFile(output_fname))
> > > > >
> > > > > mkimage is supposed to create an output file which name is in
> > > > > output_fname; if mkimage fails and you continue, the next step is
> > > > > tools.ReadFile(output_fname) trying to read that file. How is this
> > > > > possible?
> > > >
> > > > # ls -al mkimage*
> > > > -rw-r--r-- 1 hthiery hthiery 0 Nov 4 20:28 mkimage-out.spl.mkimage
> > > > -rw-r--r-- 1 hthiery hthiery 180392 Nov 4 20:28 mkimage.spl.mkimage
> > > >
> > > > The file (mkimage-out.spl.mkimage) with size 0 seems to be created. I
> > > > assume mkimage will create that.
> > >
> > > So in this situation we know that mkimage failed, and it generated
> > > an empty output file.
> > >
> > > I guess the output file is _not_ empty when no errors occur?
> > >
> > > which reasonable results can you expect when you ignore an error and
> > > just continue with garbage data as if nothing happened?
> > >
> > > Sorry, but this makes no sense to me. If there is an error, it
> > > should be reported and - if possible - handled. If this is not
> > > possible, then the correct thing is to abort. Ignoring errors and
> > > trying to continue is always the worst thing to do.
> >
> > 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.
> >
> > 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.
I think the approach in this series works, but it might be nicer to:
- output a special error return code from mkimage when a file is missing
- make sure that binman detects this situation and reports its warning
about some blobs being missing
Regards,
Simon
More information about the U-Boot
mailing list