kHi Xavier, On Tue, 26 Jul 2022 at 13:08, Xavier Drudis Ferran <xdru...@tinet.cat> wrote: > > El Tue, Jul 26, 2022 at 11:08:21AM +0200, Quentin Schulz deia: > > > > You could also have a fit,align = <8>; property instead of hardcoding it. > > I'm not sure the fit entry in binman heeds this property, may have > overlooked something. I'd have to try it.
[..] > > > > > This is unfortunately not possible since binman parallelizes the build of > > images in the binman DT node. This means there is no guarantee the > > u-boot.itb file is generated before this section is worked on by binman. Or > > maybe I misunderstood the docs. > > > > But good progress, I guess this phandle thing "just" needs to be fixed to > > have something nice (both for this patch series and mine). > > > > I'm sending another patch below "fixing" the phandle issue, but it's a > dirty hack without too much thought given. It could still fail if threads > try to read data from the image of another thread before it's ready or > something. > Only lightly tested with binman -T 0, not parallel. > It seems to run mkimage -B 8 -E -t -F ./itb.fit.fit SIX times each time > I run binman. Not sure why. > > But it boots. > > I wonder if we shouldn't just run binman several times from make instead of > once at the end, > have make run it once for each file we want to create, so that we can reuse > u-boot.itb for both > the MMC and the SPI image. We could have one .dts for each image, so when make > want u-boot.itb it runs binman -a of-list="rk3399-rock-pi-4b.dts > rockchip-itb-u-boot.dts" We must not move to multiple invocations of binman. It is supposed to handle everything at once. But for the case you have here, we could perhaps add a feature to specify an ordering for images and to explicitly allow one image to include another? [..] Regards, Simon