Re: mkimage_fit_atf.sh: not found

[Simon Glass <sjg@chromium.org>]

Hi Heiko,

On Thu, 6 Jan 2022 at 13:44, Heiko Thiery <heiko.thiery@gmail.com> wrote:
>
> Hi Tim and all,
>
> Am Do., 6. Jan. 2022 um 18:10 Uhr schrieb Tim Harvey <tharvey@gateworks.com>:
> >
> > On Thu, Jan 6, 2022 at 2:07 AM ZHIZHIKIN Andrey
> > <andrey.zhizhikin@leica-geosystems.com> wrote:
> > >
> > > Hello Tim,
> > >
> > > > -----Original Message-----
> > > > From: U-Boot <u-boot-bounces@lists.denx.de> On Behalf Of Tim Harvey
> > > > Sent: Wednesday, January 5, 2022 8:08 PM
> > > > To: ZHIZHIKIN Andrey <andrey.zhizhikin@leica-geosystems.com>
> > > > Cc: u-boot <u-boot@lists.denx.de>; Stefano Babic <sbabic@denx.de>; Fabio Estevam
> > > > <festevam@gmail.com>; Schrempf Frieder <frieder.schrempf@kontron.de>; Adam Ford
> > > > <aford173@gmail.com>; Marcel Ziswiler <marcel@ziswiler.com>; Jagan Teki
> > > > <jagan@amarulasolutions.com>
> > > > Subject: Re: mkimage_fit_atf.sh: not found
> > > >
> > > > On Wed, Jan 5, 2022 at 3:34 AM ZHIZHIKIN Andrey
> > > > <andrey.zhizhikin@leica-geosystems.com> wrote:
> > > > >
> > > > > Hello Tim,
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: U-Boot <u-boot-bounces@lists.denx.de> On Behalf Of Tim Harvey
> > > > > > Sent: Tuesday, January 4, 2022 11:48 PM
> > > > > > To: u-boot <u-boot@lists.denx.de>; Stefano Babic <sbabic@denx.de>; Fabio
> > > > Estevam
> > > > > > <festevam@gmail.com>
> > > > > > Cc: Schrempf Frieder <frieder.schrempf@kontron.de>; Adam Ford
> > > > > > <aford173@gmail.com>; Marcel Ziswiler <marcel@ziswiler.com>; Jagan Teki
> > > > > > <jagan@amarulasolutions.com>
> > > > > > Subject: mkimage_fit_atf.sh: not found
> > > > > >
> > > > > > Stefano and Fabio,
> > > > > >
> > > > > > I'm seeing the imx8mm_venice_defconfig target failing to build on
> > > > > > master due to mkimage_fit_atf.sh not found:
> > > > > > ./"arch/arm/mach-imx/mkimage_fit_atf.sh" \
> > > > > > arch/arm/dts/imx8mm-venice-gw71xx-0x.dtb
> > > > > > arch/arm/dts/imx8mm-venice-gw72xx-0x.dtb
> > > > > > arch/arm/dts/imx8mm-venice-gw73xx-0x.dtb
> > > > > > arch/arm/dts/imx8mm-venice-gw7901.dtb
> > > > > > arch/arm/dts/imx8mm-venice-gw7902.dtb > u-boot.its
> > > > > > /bin/sh: 1: ./arch/arm/mach-imx/mkimage_fit_atf.sh: not found
> > > > > >
> > > > >
> > > > > This has been dropped in d9a6f0eed6 ("tree: imx: remove old fit generator
> > > > script")
> > > >
> > > > So why was that merged when it breaks several boards that are not
> > > > switched to binman because of the CI issue?
> > >
> > > Because the FIT generator script has been broken after commit 3f04db891a
> > > ("image: Check for unit addresses in FITs"), which has covered CVE-2021-27138.
> > > You can see the reasoning of merging d9a6f0eed6 ("tree: imx: remove old fit
> > > generator script") in the commit message.
> > >
> > > In addition, d9a6f0eed6 ("tree: imx: remove old fit generator script") has
> > > been introduced as a part of discussion stemmed from [1], where it has been
> > > pointed out that certain boards are still using old FIT generator which is
> > > not working, and I've listed those board config files for maintainers to react.
> > >
> >
> > Andrey,
> >
> > I agree removing the old fit generator is the right path but I am very
> > surprised it was merged when it broke boards that had not moved to
> > binman yet. There has been a warning to migrate to binman but there
> > was never a deadline.
> >
> > > Binman CI missing binaries verification came later I believe, that is the
> > > reason we are seeing those conversions pending. But this is unrelated to the
> > > FIT generator script removal, which was broken anyways.
> > >
> >
> > I have not followed the discussion about what was wrong with the FIT
> > generator or what was specifically 'broken' but boards at least built
> > and booted with it and now they do not build. I do know there was a
> > time where I needed a patch that dealt with '@' symbols and I'm not
> > sure if that ever got merged before the FIT generator was simply
> > removed. Again, I hadn't thought much of it because I had binman
> > conversion patches in flight not realizing they would get stuck
> > because of CI.
> >
> > I don't really know anything about U-Boot CI but I'm also surprised it
> > doesn't point out the fact that several boards won't currently build.
> >
> > > >
> > > > >
> > > > > > As far as I can tell the other boards that are still using
> > > > > > SPL_FIT_GENERATOR also fail due to this (ie imx8mm_beacon_defconfig,
> > > > > > imx8mq_evk_defconfig, imx8mm-icore-mx8mm-edimm2.2_defconfig, etc).
> > > > >
> > > > > imx8mq_evk is already converted and I've sent a patch for it, see [1].
> > > > >
> > > > > >
> > > > > > What is the state of the binman conversion? I submitted a series to
> > > > > > convert my boards to binman and it has just been sitting without any
> > > > > > response for months now [1].
> > > > >
> > > > > I believe that the reason for your series sitting in the queue is the same as
> > > > > for imx8mq_evk: missing binary blobs (ATF and DDR) are failing CI builds.
> > > > >
> > > >
> > > > Right, so imx8mq_evk (and others) are completely broken for the
> > > > pending release correct?
> > >
> > > That is correct, and there are patches to address this.
> > >
> > > There is also a patch series from Heiko to address the "missing binary" CI issue, see [2].
> > >
> >
> > Again personally I did not pay attention to d9a6f0eed6 ("tree: imx:
> > remove old fit generator script") because I already had submitted a
> > series to move my board to binman (other boards still had not done
> > this however and would be broken without a change). I see that Stefano
> > applied d9a6f0eed6 ("tree: imx: remove old fit generator script") on
> > Oct 7 and he must not have realized it broke boards that had not moved
> > to binman. Several of us have submitted patches to move to binman and
> > thus also likely did not notice but those patches never got merged
> > because of this CI issue.
> >
> > I see Heiko has a v4 of his patch here
> > https://patchwork.ozlabs.org/project/uboot/list/?series=279595. Can
> > that get merged?
>
> I think applying this patch will not solve the issue finally. This
> change will add the ability to fake the needed files (lpddr fw, hdmi
> fw ...) by binman with adding the introduced u-boot make option. But
> this option has to be set by buildman somehow for the CI. Or we need
> to change the default behavior of binman as Simon already proposed.

Yes and I will add a patch for that in the series I expect to send
soon (which deals with missing binary tools). We do the same for
missing binaries, so I think it makes sense.

Regards,
Simon