[PATCH v2 4/7] dts: beagleplay: binman: Include firmware capsules binman nodes

[Jon Humphreys]

Tom Rini <trini at konsulko.com> writes:

> On Wed, May 22, 2024 at 11:12:35PM -0500, Jon Humphreys wrote:
>> Tom Rini <trini at konsulko.com> writes:
>> 
>> > On Tue, May 21, 2024 at 09:20:26PM -0500, Jon Humphreys wrote:
>> >> Tom Rini <trini at konsulko.com> 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 <j-humphreys at ti.com>
>> >> >> ---
>> >> >>  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.

Jon

> -- 
> Tom