On Thu, May 23, 2024 at 04:09:38PM -0500, Jon Humphreys wrote: > Tom Rini <[email protected]> writes: > > > On Wed, May 22, 2024 at 11:12:35PM -0500, Jon Humphreys wrote: > >> Tom Rini <[email protected]> writes: > >> > >> > On Tue, May 21, 2024 at 09:20:26PM -0500, Jon Humphreys wrote: > >> >> Tom Rini <[email protected]> writes: > >> >> > >> >> > On Fri, Apr 19, 2024 at 04:28:16PM -0500, Jonathan Humphreys wrote: > >> >> > > >> >> >> Fill in the BeaglePlay's capsule GUID properties of the base binman > >> >> >> capsule > >> >> >> nodes. > >> >> >> > >> >> >> Signed-off-by: Jonathan Humphreys <[email protected]> > >> >> >> --- > >> >> >> arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 27 > >> >> >> ++++++++++++++++++++ > >> >> >> arch/arm/dts/k3-am625-r5-beagleplay.dts | 15 +++++++++++ > >> >> >> 2 files changed, 42 insertions(+) > >> >> > > >> >> > This series introduces failure to build in CI, and it's a little > >> >> > tricky > >> >> > to replicate locally, depending on your environment. You first need to > >> >> > NOT have BINMAN_INDIRS set and instead be using fake binaries. Second, > >> >> > it seems python version dependent perhaps? I don't see this on my > >> >> > host, > >> >> > but by: > >> >> > - Using the CI container > >> >> > - Setting up a virtualenv inside of it > >> >> > - pip install -r tools/buildman/requirements.txt > >> >> > I get: > >> >> > $ ./tools/buildman/buildman --keep-outputs --reproducible-builds > >> >> > -dvel --force-build -PEWM --output /tmp/am62x_beagleplay_r5 --board > >> >> > am62x_beagleplay_r5 > >> >> > Building current source for 1 boards (1 thread, 12 jobs per thread) > >> >> > arm: + am62x_beagleplay_r5 > >> >> > +(am62x_beagleplay_r5) Image 'tiboot3-am62x-gp-evm.bin' is missing > >> >> > optional external blobs but is still functional: ti-fs-gp.bin > >> >> > +(am62x_beagleplay_r5) > >> >> > +(am62x_beagleplay_r5) /binman/tiboot3-am62x-gp-evm.bin/ti-fs-gp.bin > >> >> > (ti-sysfw/ti-fs-firmware-am62x-gp.bin): > >> >> > +(am62x_beagleplay_r5) Missing blob > >> >> > +(am62x_beagleplay_r5) binman: object of type 'NoneType' has no len() > >> >> > +(am62x_beagleplay_r5) make[1]: *** [Makefile:1126: .binman_stamp] > >> >> > Error 1 > >> >> > +(am62x_beagleplay_r5) make: *** [Makefile:177: sub-make] Error 2 > >> >> > 0 0 1 /1 am62x_beagleplay_r5 > >> >> > >> >> Tom, this is failing in the CI container because the container is > >> >> missing > >> >> the mkeficapsule tool. > >> >> > >> >> To solve this, we just need to add it to the CI container. > >> >> > >> >> My understanding of binman's handling of missing bintools is that it > >> >> should > >> >> gracefully continue with fake data, so that buildman can successfully > >> >> test > >> >> out builds for boards even when you don't have all the required > >> >> bintools. > >> >> If I have that correct, I can also create a patch to properly handle > >> >> this > >> >> when using mkeficapsule. But I want to verify this is the desired > >> >> behavior, > >> >> since mkeficapsule isn't a unique or vendor specific tool, so shouldn't > >> >> we > >> >> require it as part of the U-Boot build environment and err out if it is > >> >> missing? > >> > > >> > Perhaps it's a binman issue since we build mkeficapsule or at least > >> > should be? Neha? > >> > > >> > >> Never mind - I figured it out. > >> > >> The mkeficapsule tools is built by u-boot if TOOLS_MKEFICAPSULE config is > >> set. I didn't explicitly set it because it is implied by > >> EFI_CAPSULE_ON_DISK config. But this is only set for the A core u-boot, as > >> that is what would apply the capsules. SPL running on the R cores does not > >> need this. But that then means that the R core u-boot builds don't have > >> TOOLS_MKEFICAPSULE set and if that is all that is being built (as in the > >> case of buildman), the mkeficapsule tool isn't built and so is missing. > >> > >> So I need to explicitly set TOOLS_MKEFICAPSULE in the R core defconfigs. > >> I'll repost the patches. > > > > Interesting. My next thought here is that whatever symbol is allowing > > for "make a capsule" should be select'ing TOOLS_MKEFICAPSULE and so the > > current logic is a bit flawed. I'm just not sure off-hand where it > > should be instead, do you have some ideas now? Thanks. > > There is no config that indicates that capsules will be generated for the > resulting binary. The only thing I can think of is to scan the board's DTB > for the presence of a capsule binman node, and then set the > TOOLS_MKEFICAPSULE config. But this seems very complicated to do at > build time.
Yeah, that's the wrong direction I think. We should perhaps just make TOOLS_MKEFICAPSULE default y if EFI_LOADER instead. -- Tom
signature.asc
Description: PGP signature
