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
