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

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/[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
>
>   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.
>
>   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
>
>   position ourselves instead.
>
> Is that a correct read of what you had in mind?
>
> 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[].

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,