On Wed, Jan 05, 2022 at 11:07:03PM +0100, Marcel Ziswiler wrote: > On Wed, 2022-01-05 at 17:04 -0500, Tom Rini wrote: > > On Wed, Jan 05, 2022 at 10:51:23PM +0100, Marcel Ziswiler wrote: > > > Hi Tim et al. > > > > > > On Wed, 2022-01-05 at 11:08 -0800, Tim Harvey wrote: > > > > 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? > > > > > > I have to admit that I did not closely follow that discussion lately. But > > > it seems to me that this should > > > be > > > solvable, not? > > > > > > Anyway, at least in my local buildman use case just touching resp. binary > > > blob file names helped me getting > > > thought this: > > > > > > ⬢[zim@toolbox u-boot.git]$ touch lpddr4_pmu_train_1d_imem.bin > > > ⬢[zim@toolbox u-boot.git]$ touch lpddr4_pmu_train_1d_dmem.bin > > > ⬢[zim@toolbox u-boot.git]$ touch lpddr4_pmu_train_2d_imem.bin > > > ⬢[zim@toolbox u-boot.git]$ touch lpddr4_pmu_train_2d_dmem.bin > > > ⬢[zim@toolbox u-boot.git]$ touch bl31.bin > > > > > > Couldn't that somehow also be done for CI? > > > > There's a whole thread on making binman be able to fake things out in > > this case, so that it doesn't require too much special casing within CI > > itself. > > > > > > > > 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? > > > > > > > > Sounds like we need to revert d9a6f0eed6 ("tree: imx: remove old fit > > > > generator script") > > > > > > I kind of agree. However, much smarter would be to finish that binman > > > conversion which I also still have > > > one in > > > flight [1] plus the follow on patch series [2] (plus an unrelated i.MX 8M > > > Plus board addition [3]) all > > > still > > > sitting there idle since October with acks resp. reviewed-bys in place! > > > > Yes, I am hopeful many outstanding things in this area will get picked > > up after v2022.01 is released. Might it make sense to revert what Tim > > suggested for now tho? > > Sure, fair enough. > > And what about them pending patch series?
Fabio noted elsewhere that Stefano is on vacation still right now, but yes, I very much want to see these outstanding items picked up, and I'm unsure what additional help Stefano would find useful. -- Tom
signature.asc
Description: PGP signature