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

Hi Casey,

On Wed, 29 Jul 2026 at 13:45, Balaji Selvanathan
<[email protected]> wrote:
>
> Hi Casey, Ilias,
>
> On 7/28/2026 5:51 PM, Casey Connolly wrote:
> >
> > On 28/07/2026 13:44, Balaji Selvanathan wrote:
> >> Hi Ilias,
> >>
> >> On 7/27/2026 9:57 PM, Balaji Selvanathan wrote:
> >>> Hi Ilias,
> >>>
> >>> On 7/27/2026 6:11 PM, Ilias Apalodimas wrote:
> >>>> On Mon, 27 Jul 2026 at 13:00, Balaji Selvanathan
> >>>> <[email protected]> wrote:
> >>>>> Hi Ilias, Casey,
> >>>>>
> >>>>> On 7/24/2026 12:37 AM, Casey Connolly wrote:
> >>>>>> On 23/07/2026 18:43, Balaji Selvanathan wrote:
> >>>>>>> Hi Casey,
> >>>>>>>
> >>>>>>> On 7/22/2026 8:19 PM, Casey Connolly wrote:
> >>>>>>>> Hi Balaji,
> >>>>>>>>
> >>>>>>>> On 22/07/2026 11:23, Balaji Selvanathan wrote:
> >>>>>>>>> Hi Casey,
> >>>>>>>>>
> >>>>>>>>> On 7/18/2026 4:19 PM, Casey Connolly wrote:
> >>>>>>>>>> On 7/17/26 18:16, Balaji Selvanathan wrote:
> >>>>>>>>>>> Hi Casey, Ilias, Simon,
> >>>>>>>>>>>
> >>>>>>>>>>> On 5/26/2026 7:05 PM, Casey Connolly wrote:
> >>>>>>>>>>>> Hi Balaji,
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 25/05/2026 13:24, Balaji Selvanathan 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-
> >>>>>>>>>>>>>> [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.
> >>>>>>>>>>>>      From a quick look it seems like it would be fairly
> >>>>>>>>>>>> straightforward to
> >>>>>>>>>>>> extend mkeficapsule to support multiple images, the capsule
> >>>>>>>>>>>> header
> >>>>>>>>>>>> has
> >>>>>>>>>>>> an item_offset_list[] array with offsets to each image, today
> >>>>>>>>>>>> we just
> >>>>>>>>>>>> write 1 but it shouldn't be too much of a challenge to put a
> >>>>>>>>>>>> loop in
> >>>>>>>>>>>> here and extend the argument parsing.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Given that we a) already use raw capsules and b) they are
> >>>>>>>>>>>> part of the
> >>>>>>>>>>>> EFI spec, I'm gonna try and save us all some time and just
> >>>>>>>>>>>> put my
> >>>>>>>>>>>> foot
> >>>>>>>>>>>> down here. A single raw EFI capsule file can already support
> >>>>>>>>>>>> updating
> >>>>>>>>>>>> multiple images, U-Boot already has all of the machinery for
> >>>>>>>>>>>> it with
> >>>>>>>>>>>> the
> >>>>>>>>>>>> exception of mkeficapsule but I expect that's something you can
> >>>>>>>>>>>> tackle.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The upside to this is that you will be able to build capsule
> >>>>>>>>>>>> files
> >>>>>>>>>>>> for
> >>>>>>>>>>>> updating xbl/tz/hyp/aop that can be consumed by U-Boot and edk2!
> >>>>>>>>>>> Thanks for the detailed feedback.
> >>>>>>>>>>>
> >>>>>>>>>>> We agree — we'll drop the FIT capsule approach and move
> >>>>>>>>>>> forward with
> >>>>>>>>>>> RAW capsules.
> >>>>>>>>>>>
> >>>>>>>>>>> Here's the plan:
> >>>>>>>>>>>
> >>>>>>>>>>> 1. mkeficapsule tool: Extend Sughosh's multi-payload capsule
> >>>>>>>>>>> series
> >>>>>>>>>>> [1] to support generating multi-image capsules from a config
> >>>>>>>>>>>        file, so we can build a single capsule covering all the
> >>>>>>>>>>> partitions
> >>>>>>>>>>> we need to update.
> >>>>>>>>>>> 2. U-Boot (Qualcomm): Today the Qualcomm capsule update code only
> >>>>>>>>>>> supports a single firmware image (U-Boot itself) via a
> >>>>>>>>>>>        single-entry fw_images[] array. We'll move to a SoC-
> >>>>>>>>>>> specific,
> >>>>>>>>>>> multi- entry fw_images[] array (defined per board, e.g.
> >>>>>>>>>>>        board/qualcomm/<board>/fw_images.c), so a single capsule
> >>>>>>>>>>> update
> >>>>>>>>>>> flow can cover multiple firmware components — each with its own
> >>>>>>>>>>>        ESRT entry and FMP image_index — instead of just U-Boot.
> >>>>>>>>>> No need for this, just build fw_images[] on the fly derived
> >>>>>>>>>> from the
> >>>>>>>>>> partition table on the board, with an entry for each partition
> >>>>>>>>>> that
> >>>>>>>>>> can be updated. You just need to add a map from partition label to
> >>>>>>>>>> fw_name string, starting with the xbl/uefi/boot partitions we
> >>>>>>>>>> already
> >>>>>>>>>> handle.
> >>>>>>>>>>
> >>>>>>>>>> The entire point of having logic here was to avoid per-board
> >>>>>>>>>> stuff, if
> >>>>>>>>>> you're thinking "ah I'll do this per-board" you should immediately
> >>>>>>>>>> wonder "but can we do it dynamically instead?".
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>> Casey
> >>>>>>>>> Hi Casey, Ilias,
> >>>>>>>>>
> >>>>>>>>>       Thanks for the pointer — agreed, building fw_images[]
> >>>>>>>>> dynamically
> >>>>>>>>> from
> >>>>>>>>> the partition table is the right call, avoids per-target code
> >>>>>>>>> entirely.
> >>>>>>>> Can I talk to a human instead of an LLM please?
> >>>>>>>>
> >>>>>>>>>       Plan:
> >>>>>>>>>       - Keep a fixed table mapping "partition label → fw_name + a
> >>>>>>>>> fixed
> >>>>>>>>> image index", this mapping going to be a superset list for all
> >>>>>>>>> the Boot
> >>>>>>>>> FW images supported in different Qualcomm targets.
> >>>>>>>> This reads vaguely like a rephrasing of what I proposed, not
> >>>>>>>> clear if
> >>>>>>>> you really understand it though.
> >>>>>>>>
> >>>>>>>>>          Sample table:
> >>>>>>>>>
> >>>>>>>>> ┌──────────────────┬───────────────┬───────┬────────────────────────┐
> >>>>>>>>>         │ part_base_name         │ fw_name                │ index
> >>>>>>>>> │ guid
> >>>>>>>>> (fixed)                                │
> >>>>>>>>> ├──────────────────|───────────────|───────-|
> >>>>>>>>> ───────────────────────- |
> >>>>>>>>>         │ xbl                                  │ QCOM_XBL │   1
> >>>>>>>>> │  QCOM_XBL_GUID                  │
> >>>>>>>>>         │ ubootspl                       │ QCOM_UBOOTSPL│   2   │
> >>>>>>>>> QCOM_UBOOTSPL_GUID     │
> >>>>>>>>>         │ uboot                            │ QCOM_UBOOT      │   3
> >>>>>>>>> │  QCOM_UBOOT_GUID            │
> >>>>>>>>> └──────────────────┴───────────────┴───────┴────────────────────────┘
> >>>>>>>>>
> >>>>>>>>>         Target-1 supports xbl and Target-2 supports ubootspl.
> >>>>>>>>>
> >>>>>>>>>       - At boot, scan the partition table against this table. Only
> >>>>>>>>> partitions actually present on that target get an fw_images[]/
> >>>>>>>>> ESRT entry
> >>>>>>>>> — nothing hardcoded per target.
> >>>>>>>>>
> >>>>>>>>>       - The image index for each partition type stays fixed and
> >>>>>>>>> published,
> >>>>>>>>> so whoever builds a capsule (mkeficapsule) always knows which
> >>>>>>>>> index to
> >>>>>>>>> target, regardless of what's discovered at runtime.
> >>>>>>>>>
> >>>>>>>>>       One wrinkle I want to flag: today's SetImage() path assumes
> >>>>>>>>> dfu_alt_num = image_index - 1, i.e. it picks the Nth entry in
> >>>>>>>>> dfu_alt_info purely by
> >>>>>>>>>       position. If a partition from the middle of the table is
> >>>>>>>>> missing on a
> >>>>>>>>> given target, everything after it would shift by one position
> >>>>>>>>> and the
> >>>>>>>>> wrong
> >>>>>>>>>       partition would get flashed — silently. Since I'd rather
> >>>>>>>>> not touch
> >>>>>>>>> that logic in common code, my plan is to keep every fixed index's
> >>>>>>>>> position in
> >>>>>>>>>       dfu_alt_info stable by inserting a placeholder (U-Boot's
> >>>>>>>>> existing
> >>>>>>>>> virt
> >>>>>>>>> DFU backend, which just no-ops) wherever a partition is absent,
> >>>>>>>>> so the
> >>>>>>>>> position
> >>>>>>>>>       math stays correct for everything after it. The missing
> >>>>>>>>> partition
> >>>>>>>>> itself simply won't have an fw_images[]/ESRT entry, so a capsule
> >>>>>>>>> can't
> >>>>>>>>> target it
> >>>>>>>>>       anyway — it'd get rejected before reaching DFU.
> >>>>>>>> Skipping past this noise... Ilias probably knows better here but
> >>>>>>>> yes the
> >>>>>>>> way dfu_alt_num is derived from ImageIndex does impose a
> >>>>>>>> limitation here
> >>>>>>>> currently where we need to ensure the indexes always start at 1 and
> >>>>>>>> count up.
> >>>>>>>>
> >>>>>>>> That being said, it's already quite complicated to have to
> >>>>>>>> maintain a
> >>>>>>>> database of the indices for each board, and even more complicated
> >>>>>>>> when
> >>>>>>>> we have boards that may or may not be using U-Boot SPL (for
> >>>>>>>> example).
> >>>>>>>>
> >>>>>>>> Having fixed ImageIndex values for each image would then seem to
> >>>>>>>> make
> >>>>>>>> the most sense as we could just use fwu to set dfu_alt_num (or
> >>>>>>>> another
> >>>>>>>> platform specific mechanism), however the EFI spec is clear that the
> >>>>>>>> ImageIndex of EFI_FIRMWARE_IMAGE_DESCRIPTOR must be <=
> >>>>>>>> DescriptorCount
> >>>>>>>> as returned by fmp->GetImageInfo(), so we would need to also have
> >>>>>>>> dummy
> >>>>>>>> entries in the fw_images[] array so it doesn't really solve our
> >>>>>>>> problem.
> >>>>>>>>
> >>>>>>>> https://uefi.org/specs/
> >>>>>>>> UEFI/2.9_A/23_Firmware_Update_and_Reporting.html
> >>>>>>>>
> >>>>>>>> Currently, other than for setting dfu_alt_num, the only other place
> >>>>>>>> where the image index needs to match is in efi_fmp_find() which was
> >>>>>>>> added by [1] seemingly to prevent an incorrect image index in the
> >>>>>>>> /capsule/ file causing dfu_alt_num to be set wrong resulting in the
> >>>>>>>> wrong partition being flashed. In other words, we should be able
> >>>>>>>> to find
> >>>>>>>> a way to safely remove this check.
> >>>>>>>>
> >>>>>>>> But alas, it seems like we are stuck with fmp->SetImage() being
> >>>>>>>> called
> >>>>>>>> with the image index from the capsule file per the spec, and it
> >>>>>>>> is the
> >>>>>>>> only way to identify the target partition without doing other hacks.
> >>>>>>>>
> >>>>>>>> I'd like to get some feedback from Ilias on this, since adding dummy
> >>>>>>>> entries really doesn't feel like an acceptable approach to me.
> >>>>>>>> The only
> >>>>>>>> alternatives I can think of also don't seem great... Either:
> >>>>>>>>
> >>>>>>>> 1. Sidestep the EFI spec by either caching data in the call to
> >>>>>>>> GetImageInfo() or by assuming that the void *image pointer
> >>>>>>>> immediately
> >>>>>>>> follows the efi_firmware_management_capsule_image_header (this is
> >>>>>>>> true
> >>>>>>>> for us today but would be a fragile assumption to make).
> >>>>>>>> 2. Use the internal image index (looked up via the image name and
> >>>>>>>> type_id) as the index when calling fmp->set_image() - going
> >>>>>>>> against the
> >>>>>>>> spec.
> >>>>>>>>
> >>>>>>>> It's not really clear to me what purpose the ImageIndex property
> >>>>>>>> serves,
> >>>>>>>> since GetImageInfo() is meant to match on the ImageTypeId anyway, I
> >>>>>>>> assume it relates somehow to the fact that there can be multiple
> >>>>>>>> instances of the firmware management protocol, but in U-Boot we only
> >>>>>>>> have one.
> >>>>>>>>
> >>>>>>>> I think the other way forward would be to use the only included
> >>>>>>>> escape
> >>>>>>>> hatch in the UEFI spec with a custom GUID in the capsule header
> >>>>>>>> capsule_guid field which would let us have a custom mechanism
> >>>>>>>> which in
> >>>>>>>> our case could just be a soft-fork of the existing spec with minor
> >>>>>>>> changes so we can just remove/ignore the UpdateImageIndex field
> >>>>>>>> in the
> >>>>>>>> capsule. Maybe this would be the most correct solution?
> >>>>>>>>
> >>>>>>>> Hopefully Ilias has some time to chime in on this, I'm sure we
> >>>>>>>> can find
> >>>>>>>> a way to go about this that doesn't involve exposing dummy data.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> // Casey
> >>>>>>> I feel we are complicating it by trying to go for dynamic fw_images.
> >>>>>>>
> >>>>>>> Rather than introducing a solution that diverges from the UEFI
> >>>>>>> specification, shall we use a board-specific static fw_images[]
> >>>>>> Well, the solution I proposed at the end very much doesn't diverge
> >>>>>> from
> >>>>>> the spec, that was kinda the point.
> >>>>>>
> >>>>>>> definition. This approach is simpler, remains spec-compliant, and
> >>>>>>> other
> >>>>>> Simpler for you to implement or simpler to maintain? I think that's
> >>>>>> quite debatable...
> >>>>>>
> >>>>>>> vendors (like NXP, TI) have also implemented static fw_images (in
> >>>>>>> board/
> >>>>>>> nxp, board/ti).
> >>>>>> The decision not to do this for mach-snapdragon was quite intentional
> >>>>>> and was the motivator behind dynamic generation of image GUIDs:
> >>>>>> https://lore.kernel.org/u-boot/20240830-b4-dynamic-uuid-
> >>>>>> [email protected]/
> >>>>>>
> >>>>>> The image index issue was always bound to come up, and it's absolutely
> >>>>>> something we should be solving and not just sidestepping. We already
> >>>>>> support dynamic fw_images[] anyway and it's already being used by some
> >>>>>> devices, so we need to maintain the existing support regardless.
> >>>>>>
> >>>>>> As I understand it, Qualcomm also intend to support multiple boot
> >>>>>> media
> >>>>>> (UFS, eMMC, SPI flash) with a single U-Boot binary, so to some extent
> >>>>>> this array must be dynamic. And since at boot time we have all the
> >>>>>> info
> >>>>>> we need to generate fw_images, keeping a static list per-board is at
> >>>>>> best lazy and at worst will just make things even more complicated
> >>>>>> when
> >>>>>> we suddenly want to support configurations with/without OP-TEE and
> >>>>>> with/without SPL.
> >>>>>>
> >>>>>> So unless I'm missing something here I think there's a strong case
> >>>>>> here
> >>>>>> to add support for ignoring the capsule provided image index, but
> >>>>>> we'll
> >>>>>> see what Ilias has to say when he's back from vacation.
> >>>>> Okay Casey.
> >>>>>
> >>>>> Hi Ilias,
> >>>>>
> >>>>> Request your input on this.
> >>>> So the problem you are trying to fix here, is that you have boards
> >>>> with multiple configurations, that their image index might change, but
> >>>> you want to update them with a single capsule right?
> >>>>
> >>>> If that's the case, we can have a board specific function that does
> >>>> nothing by default, but on the qualcomm case, re-arranges the capsule
> >>>> image indexes *after* the capsule authentication has passed. I think
> >>>> this still violates the EFI spec, but I am ok with it.
> >>>>
> >>>> Cheers
> >>>> /Ilias
> >>> Hi Ilias,
> >>>
> >>>    Thanks for the input. Just to make sure we're on the same page:
> >>>
> >>>    Our understanding is that we'd add a board-specific hook (default
> >>> no-op, so other vendors are unaffected) that runs after the capsule
> >>> signature is verified but before dfu_alt_num is
> >>>    derived from image_index. On Qualcomm boards, this hook would look
> >>> at the partitions actually present at boot and remap the capsule's
> >>> (fixed, published) image_index to whatever position that image
> >>> actually occupies in dfu_alt_info on that specific target — rather
> >>> than assuming a fixed 1:1 mapping between image_index and position.
> >>>
> >>>    To be clear on scope: we're not ignoring the image_index value
> >>> itself — it's still read from the capsule and used as-is to look up
> >>> which firmware component (xbl/uboot/etc.) is being
> > no, the entire point is that the image index is bunk, why are you
> > feeding these emails through an LLM?
> >
> >>>    targeted. What we're overriding is the spec's assumption that this
> >>> index also encodes position, i.e. that dfu_alt_num = image_index - 1
> >>> and that image_index stays within descriptor_count.
> > the spec's assumption????? this has nothing to do with the spec
> >>>    Since our FMP descriptor list is built dynamically per-board, a
> >>> fixed global index can exceed the descriptor count on boards missing
> >>> some partitions, so we remap it to the correct DFU
> > no
> >>>    position ourselves instead.
> >>>
> >>> Is that a correct read of what you had in mind?
> > please use plain text formatting for emails.
> >>> Regards,
> >>>
> >>> Balaji
> >> If the above assumption is correct, then we will have following problems,
> >>
> >> During authentication, U-Boot performs anti-rollback checks.
> >>
> >> As part of this flow, the Image Index is converted to an Image GUID
> >> using fw_images[].
> >>
> >> Since the capsule Image Index does not match the fw_images[] Image Index
> >> at this stage, the anti-rollback logic may resolve the wrong GUID or
> >> fail to find a matching entry in fw_images[].
> > I'd like to understand from Ilias why we need to authenticate the
> > firmware first before adjusting the image index, I'd hope we could avoid
> > that? Unless changing the index would invalidate the checksum

I was remembering the FMP parts wrong. Looking at the spec again, it
seems that UpdateImageIndex is not part of the signed payload. So you
can switch it before that.

> >
> > The image is authenticated inside of fmp->SetImage() at which point we
> > don't have the image type ID or name so it's too late at that point. We
> > would need to adjust it earlier.

Yea that should be fine

> >
> > perhaps we could go about it another way, what if we add a dfu_alt_num
> > field to efi_fw_image (and add a flag to efi_capsule_update_info to
> > indicate if the new field is valid), then in efi_capsule.c just before
> > we call efi_fmp_find() we can call a new weak function that would adjust
> > the image index of the matching efi_fw_image so it matches whatever is
> > in the capsule. Then we don't have to care what it is since we can use
> > the right dfu_alt_num field anyway.


Doesn't that have to be defined per board config though?

> >
> > Maybe this could just all be done in efi_capsule.c and not even need a
> > platform hook, either gated behind a config option or just behind the
> > new efi_fw_image.dfu_alt_num field being used.
> >
> > I worry that's too much of a workaround that might cause issues down the
> > line but I'm not really familiar enough with this to be sure.

I think the workaround is not too big of a hack. You are essentially
remapping some image indexes based on runtime info of the board
because you want a single capsule to support multiple confugurations.

>
> Casey,
>
> We have checked and this approach seems to be fine. In this approach
> though, it comes back to the issue we saw earlier: the image index (from
> the capsule) could be > descriptor count.
>
> If this is fine, then we can proceed with this approach. Atleast we
> won't be creating dummy dfu strings.
>
> Ilias,
>
> Would like to hear your view on this, so we are all on the same page.
>
> Regards,
>
> Balaji
>
> >
> >> Regards,
> >>
> >> Balaji
> >>
> >>>
> >>>>> Regards,
> >>>>>
> >>>>> Balaji
> >>>>>
> >>>>>>> Regards,
> >>>>>>>
> >>>>>>> Balaji
> >>>>>>>
> >>>>>>>> [1]: 7cf06f09cc51 ("capsule: Put a check for image index before the
> >>>>>>>> update")
> >>>>>>>>
> >>>>>>>>>       Let me know if this approach sounds reasonable.
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> Balaji
> >>>>>>>>>>> Will send an updated series once the mkeficapsule and qcom
> >>>>>>>>>>> capsule
> >>>>>>>>>>> update changes are in shape.
> >>>>>>>>>>>
> >>>>>>>>>>> [1] https://lore.kernel.org/u-boot/20240419065542.1160527-1-
> >>>>>>>>>>> [email protected]/
> >>>>>>>>>>>
> >>>>>>>>>>> Regards,
> >>>>>>>>>>> Balaji
> >>>>>>>>>>>> Kind regards,