[PATCH] Revert "mksunxi_fit_atf.sh: Allow for this to complete when bl31.bin is missing"

[Tom Rini]

On Tue, Mar 17, 2020 at 02:54:40PM +0100, Petr Štetiar wrote:
> Tom Rini <trini at konsulko.com> [2020-03-17 09:20:38]:
> 
> Hi,
> 
> > On Tue, Mar 17, 2020 at 02:12:55PM +0100, Petr Štetiar wrote:
> > 
> > > This reverts commit 4c78028737c3185f49f5691183aeac3478b5f699.
> > > 
> > > bl31.bin file is mandatory for functional, usable and bootable binaries,
> > > thus it should be hard error if bl31.bin is missing. It doesn't matter
> > > if I'm building on autobuilder or locally, the resulting binaries should
> > > be usable in both cases.
> > > 
> > > Cc: Simon Glass <sjg at chromium.org>
> > > Cc: Tom Rini <trini at konsulko.com>
> > > Cc: Andre Przywara <andre.przywara at arm.com>
> > > Cc: Maxime Ripard <maxime.ripard at free-electrons.com>
> > > Signed-off-by: Petr Štetiar <ynezz at true.cz>
> > > ---
> > > 
> > > I've just spent some time hunting eMMC boot issue on a64-olinuxino. It's
> > > really easy to miss that warning message on fast build hosts as the message is
> > > scrolled out very quickly out of the screen and thus using the broken images,
> > > which would get stuck at `Trying to boot from MMC2`.
> > > 
> > > I think, that if it's desired to have broken images on the output, then it
> > > should be handled on the autobuilder itself before build of sunxi target.
> > > 
> > > Another option is probably adding AUTOBUILDER_ALLOW_BROKEN_IMAGES config
> > > option, which would make it clear for everybody.
> > > 
> > >  board/sunxi/mksunxi_fit_atf.sh | 6 ------
> > >  1 file changed, 6 deletions(-)
> > 
> > It's the case that the vast majority of aarch64 platforms only function
> > when we have other binary files available for the final link and so have
> > a similar we had hoped loud enough WARNING message.  And yes, this is so
> > that all of the different CI systems can complete build testing.
> 
> so there's some requirement, that the CI systems should always build with
> simple `make` call? You know, `make BL31=/dev/null` works just fine if having a
> green build, but unusable binaries is desired.

Yes, it's required that CI continue to pass, otherwise we run into the
case where you can't build the platform at all.  And no, it's not just a
simple 'make' call, please take a look at one or more of the CI scripts.

> > So, can you please RFC some patches such that we can still run CI but we
> > drop all of the "non-functional" WARNING messages we have?  Thanks!
> 
> If it's desired to bloat the codebase with config options and ifdefs just to
> adapt for unflexible CI systems, fine with me, I'll do so.

Everything is as (un)flexible as we make it.  The current approach, for
all the platforms that require various third-party binaries, is to shout
at the user they're making a binary that won't work.  Before this, we
had either silently making binaries that didn't work or defaulting to
not trying to build a final image format (and then problems introduced
in that last phase not being detected).

So if you can think of a cleaner approach that doesn't further
complicate CI nor end-users, please RFC some patches.  Thanks!

-- 
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/20200317/09bc8baf/attachment.sig>