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.
>
> 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)
