Hi Heiko, On Thu, 6 Jan 2022 at 13:44, Heiko Thiery <heiko.thi...@gmail.com> wrote: > > Hi Tim and all, > > Am Do., 6. Jan. 2022 um 18:10 Uhr schrieb Tim Harvey <thar...@gateworks.com>: > > > > On Thu, Jan 6, 2022 at 2:07 AM ZHIZHIKIN Andrey > > <andrey.zhizhi...@leica-geosystems.com> wrote: > > > > > > Hello Tim, > > > > > > > -----Original Message----- > > > > From: U-Boot <u-boot-boun...@lists.denx.de> On Behalf Of Tim Harvey > > > > Sent: Wednesday, January 5, 2022 8:08 PM > > > > To: ZHIZHIKIN Andrey <andrey.zhizhi...@leica-geosystems.com> > > > > Cc: u-boot <u-boot@lists.denx.de>; Stefano Babic <sba...@denx.de>; > > > > Fabio Estevam > > > > <feste...@gmail.com>; Schrempf Frieder <frieder.schre...@kontron.de>; > > > > Adam Ford > > > > <aford...@gmail.com>; Marcel Ziswiler <mar...@ziswiler.com>; Jagan Teki > > > > <ja...@amarulasolutions.com> > > > > Subject: Re: mkimage_fit_atf.sh: not found > > > > > > > > On Wed, Jan 5, 2022 at 3:34 AM ZHIZHIKIN Andrey > > > > <andrey.zhizhi...@leica-geosystems.com> wrote: > > > > > > > > > > Hello Tim, > > > > > > > > > > > -----Original Message----- > > > > > > From: U-Boot <u-boot-boun...@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 <sba...@denx.de>; > > > > > > Fabio > > > > Estevam > > > > > > <feste...@gmail.com> > > > > > > Cc: Schrempf Frieder <frieder.schre...@kontron.de>; Adam Ford > > > > > > <aford...@gmail.com>; Marcel Ziswiler <mar...@ziswiler.com>; Jagan > > > > > > Teki > > > > > > <ja...@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