All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tim Harvey <tharvey@gateworks.com>
To: Tom Rini <trini@konsulko.com>
Cc: Simon Glass <sjg@chromium.org>, u-boot <u-boot@lists.denx.de>
Subject: Re: binman warning/failure when blobs are missing
Date: Thu, 11 Aug 2022 09:59:05 -0700	[thread overview]
Message-ID: <CAJ+vNU0WJBn1Wr9fPO9fv5dNx=rRR-qCbfSePZVeJt45+y5hCg@mail.gmail.com> (raw)
In-Reply-To: <20220811164850.GY1146598@bill-the-cat>

On Thu, Aug 11, 2022 at 9:48 AM Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Aug 11, 2022 at 09:27:44AM -0700, Tim Harvey wrote:
>
> > Greetings,
> >
> > After a couple of hours troubleshooting a bad boot image today I
> > realized the issue was that I had some 0 byte files for the lpddr4
> > training blobs that are part of the imx8mp binman created image.
> >
> > Digging in I found that if a blob referenced in the binman node is
> > missing a warning will be output but the missing files will be
> > 'created' as 0 byte files such that the next time you build you will
> > get no warning (but will have a non-working image). Additionally the
> > error does not cause a non-zero exit code.
> >
> > I'm not that fluent in python these days, and don't have the time for
> > a while to try and fix this but I figured I would at least send this
> > email in case someone else does.
> >
> > Example:
> > # rm *lpddr4*.bin # make sure lpddr4*.bin files referenced in binman
> > nodes are missing
> > # make distclean imx8mp_venice_defconfig flash.bin && echo "build ok"
> > ...
> >   BINMAN  flash.bin
> > Image 'main-section' is missing external blobs and is non-functional: ddr-1d-ime
> > m-fw ddr-1d-dmem-fw ddr-2d-imem-fw ddr-2d-dmem-fw
> > Image 'main-section' has faked external blobs and is non-functional: lpddr4_pmu_
> > train_1d_imem_202006.bin lpddr4_pmu_train_1d_dmem_202006.bin lpddr4_pmu_train_2d
> > _imem_202006.bin lpddr4_pmu_train_2d_dmem_202006.bin
> >
> > Some images are invalid
> > ^^^ excellent warning
> > build ok
> > ^^^ not so great that there is a successful exit code
> > # make flash.bin && echo "build ok"
> > ...
> >   BINMAN  flash.bin
> > build ok
> > ^^^ absolutely horrible that 0 byte files were created and thus
> > everything looks good this time around!
> > # stat -c "%s %n" lpddr4*.bin
> > 0 lpddr4_pmu_train_1d_dmem_202006.bin
> > 0 lpddr4_pmu_train_1d_imem_202006.bin
> > 0 lpddr4_pmu_train_2d_dmem_202006.bin
> > 0 lpddr4_pmu_train_2d_imem_202006.bin
>
> So, this isn't the first time someone has had this problem. On the one
> hand, we need CI to pass, and not require fetching of arbitrary further
> images to assemble the binary. On the other hand, we don't want users
> spending a bunch of time because something didn't work and the normal
> way of conveying THIS WON'T WORK is a non-zero exit status. Can we
> easily make some flag for buildman or binman that we do set in CI but
> won't be set by users?
>

Tom,

Ok - that makes sense as far as the exit status goes. It would be MUCH
easier to catch an error like this if binman didn't create 0 byte
files for missing files so that you at least get the (ascii colored)
message indicating the image is wrong.

I do love the idea of a flag for CI also!

Best Regards,

Tim

  reply	other threads:[~2022-08-11 16:59 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-11 16:27 binman warning/failure when blobs are missing Tim Harvey
2022-08-11 16:48 ` Tom Rini
2022-08-11 16:59   ` Tim Harvey [this message]
2022-08-11 17:43     ` Tom Rini
2022-08-12  0:08       ` Simon Glass
2022-08-12  0:13         ` Tim Harvey
2022-08-12  1:03         ` Tom Rini
2022-08-12 15:11           ` Simon Glass
2022-08-12 16:11             ` Tom Rini
2022-08-13  2:21               ` Simon Glass
2022-08-13 12:36                 ` Tom Rini
2022-08-15 17:37                   ` Simon Glass
2022-08-31 14:17                     ` Tom Rini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJ+vNU0WJBn1Wr9fPO9fv5dNx=rRR-qCbfSePZVeJt45+y5hCg@mail.gmail.com' \
    --to=tharvey@gateworks.com \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.