[PATCH 1/7] qcom: capsule: add FIT capsule support with multi-partition

[Simon Glass]

Hi Ilias,

On Mon, 25 May 2026 at 15:07, Ilias Apalodimas
<ilias.apalodimas at linaro.org> wrote:
>
> Hi Simon,
>
> On Mon, 25 May 2026 at 21:10, Simon Glass <sjg at chromium.org> wrote:
> >
> > Hi all,
> >
> > On Mon, 25 May 2026 at 05:24, Balaji Selvanathan
> > <balaji.selvanathan at oss.qualcomm.com> 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/20240419065542.1160527-1-sughosh.ganu@linaro.org/
> > >
> > > 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.

>
> >
> > Given that, the FIT handler has concrete advantages:
> >
> > 1. Signing: A FIT is signed once with U-Boot's existing FIT signature
> > machinery - the same code already verifying boot images on these
> > platforms. Multi-payload RAW needs per-payload FMP authentication
> > (auth header, signature, monotonic count per image), which is a second
> > key-management and tooling path to maintain.
> >
> > 2. Composition: Adding a partition to an update is a node in a .its
> > and a rebuild. The multi-payload RAW equivalent needs the item-offset
> > table and per-payload auth headers regenerated; EDK2 GenerateCapsule
> > handles it, and the mkeficapsule side still needs Sughosh's 2024
> > series merged before it's even an option in-tree.
>
> That's how capsules are designed and I am fine with it. I want our
> U-Boot part to remain as close to the spec as possible.

Are you saying that the spec prohibits FIT in some way, or perhaps
that it prohibts its images being containers? I'm really not seeing
it.

>
> >
> > 3. Surface area: EFI loader is already large, and each "use the EFI
> > path for this too" decision is locally reasonable but cumulatively
> > expensive for boards that don't otherwise need much of UEFI.
>
> If you don't need EFI, then you can't use capsules either. You have to
> initialize the entire subsystem to access the capsules, so you are
> better off using dfu directly.

But then you can use the same FIT for update. We should not need to
create an entirely different format. To my mind, EFI update is just
the mechanism.

>
> > The FIT
> > capsule keeps the heavy lifting in code U-Boot already has for non-EFI
> > reasons, which is the direction I'd like to see us biased toward when
> > both options are available.
> >
> > We keep arriving at 'the EFI equivalent already exists, use
> > that'...each individual decision may be defensible, but the cumulative
> > effect is that EFI is quietly becoming the default
> > boot/firmware-update story for U-Boot. It leads us to GRUB or another
> > EFI app just to boot the OS,
>
> It does not. You can boot the kernel directly for a couple of years
> now. GRUB/systemd etc are optional. UEFI is the preferred way to boot
> in arm64 and I suspec RISC-V is going down that path as well. There
> are certain features you can't get without UEFI e.g randomizing the
> kernel physical placement during KASLR.

You will agree that GRUB is what is actually being used, though,
right? After all we have the DT-fixup protocol partly in order to deal
with this. I have a Mediatek board which runs GRUB....

>
> Thanks
> /Ilias
>
> > which is itself being pushed to being an
> > EFI app. This is the backdrop to why I'd like the FIT option kept open
> > here.
> >
> > So I'd suggest:
> >
> > 1. Split the partition discovery / A/B selection / DFU-string building
> > out as its own cleanup, usable by either handler.
> > 2. Then layer the payload dispatch on top - I'd prefer FIT for the
> > reasons above, but the split lets us land (1) without resolving (2)
> > first.
> >
> > Separately, I'll see if I can send some patches for Boot Loader
> > Specification, as another option beside the extlinux.conf file.
[..]

I still think (1) would be a useful next step.

Anyway, I believe that if we can use FIT for all updates (EFI or not)
things will be a lot simpler for people.. It also provides an path
beyond EFI in the future. At the moment it seems as if we are
reinventing wheels here.

I'll try to catch you on irc to figure this out.

Regards,
Simon