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