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 <w...@denx.de>:
> >
> > Dear Heiko,
> >
> > In message
> > <caeymn7zgn1ej3kgzg2kicyqk5dqhksdxnauavzgs+3l_fb1...@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. -- Tom
signature.asc
Description: PGP signature
