On 6/14/26 14:13, Simon Glass wrote:
Hi Ilias,
On Mon, 25 May 2026 at 15:07, Ilias Apalodimas
<[email protected]> wrote:
Hi Simon,
On Mon, 25 May 2026 at 21:10, Simon Glass <[email protected]> wrote:
Hi all,
On Mon, 25 May 2026 at 05:24, Balaji Selvanathan
<[email protected]> wrote:
Hi Ilias,
On 5/23/2026 6:23 PM, Ilias Apalodimas wrote:
[...]
To support multi-image RAW capsules, we would need to:
1. Enhance mkeficapsule to create multi-image capsules?
There's an equivalent tool in EDKII that can produce a capsule with
multiple payloads. There were also patches posted for mkeficapsule,
but need some minor tweaks to merge them
Can you please point me those patches? I did a search myself, but
couldnt find those patches.
https://lore.kernel.org/u-boot/[email protected]/
This patch you mentioned here can create capsule with only one payload;
means for multiple binaries we need to create multiple capsules. I have
also asked the person who made this series to respin, but havent heard
back from him.
Before this respins as multi-payload RAW, I'd like to push back on the
suggestion that FIT is the wrong answer here.
CONFIG_EFI_CAPSULE_FIRMWARE_FIT is already a first-class handler in
efi_firmware.c next to the RAW one.
We accepted it back then because we lacked capsule authentication. I
really want to remove it now, since I see no point having a capsule
within a FIT.
I may have misunderstood something here. My understanding with this
series is that there is a FIT containing multiple images which all
need updating atomically. So there is one ESRT, isn't there? How does
it result in a capsule being inside a FIT?
So the choice isn't whether to add
a new mechanism, just which of the two existing handlers Qualcomm
wires up. Both produce an FMP and an ESRT entry; the OS-visible UEFI
behaviour is identical. The difference is entirely in what sits inside
the capsule payload.
Not really. FIT capsule will expose a single FMP entry and no
information of the firmware components in the esrt, unless I remember
the code wrong.
Well, FIT is designed to hold components so it is provided there, in a
manner native to U-Boot.
Regardless of the merits of FIT, the EFI capsule spec explicitly
supports having multiple images in a single capsule and updating all of
them at once. U-Boot also already has the wiring for this. FIT is
totally unnecessary here particularly since we don't live in the world
where we use FIT for everything, so we don't gain any common tooling or
abstraction by using it for this one case. As Ilias clearly pointed out
we /lose/ visibility as EFI tooling just sees a FIT image as a binary blob.
If you wish to keep discussing in this thread please drop me from CC.
