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

Hi Ilias,

On 7/31/2026 3:06 PM, Ilias Apalodimas wrote:
> 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.

Thanks for the suggestion. Will go ahead with this approach and will 
soon post the series.

Regards,

Balaji

>
>> 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,