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
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.
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.
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.
>
> 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,
--
// Casey (she/her)
