Skip to content

[qcom-next] mkeficapsule: Support multi-payload capsules - #111

Open
balajiselvanathan wants to merge 8 commits into
qualcomm-linux:qcom-nextfrom
balajiselvanathan:mkeficapsule
Open

[qcom-next] mkeficapsule: Support multi-payload capsules#111
balajiselvanathan wants to merge 8 commits into
qualcomm-linux:qcom-nextfrom
balajiselvanathan:mkeficapsule

Conversation

@balajiselvanathan

Copy link
Copy Markdown

This series adds support for bundling multiple firmware images into a
single UEFI capsule, driven through mkeficapsule's config file.

Upstream Link: https://lore.kernel.org/u-boot/20260727-mkeficapsule-v1-0-5b162866b092@oss.qualcomm.com/

Sughosh Ganu and others added 8 commits August 13, 2026 14:49
…ig file

Add support for specifying the parameters needed for capsule
generation through a config file, instead of passing them through
command-line. Parameters for more than a single capsule file can be
specified, resulting in generation of multiple capsules through a
single invocation of the command.

The config file can be passed to the mkeficapsule tool in such manner

 $ ./tools/mkeficapsule -f <path/to/the/config/file>

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Add create_multi_payload_fwbin() to bundle up to 16 firmware images
into a single capsule file. Only normal blob payloads are supported
for now; signing and the config file parser integration will follow
in later patches.

Signed-off-by: Balaji Selvanathan <balaji.selvanathan@oss.qualcomm.com>
Extend the config file parser to automatically group multiple payloads
with the same capsule filename into a single multi-payload capsule.

The parser now operates in two phases:
1. Parse all payload entries and group by capsule filename
2. Generate capsules based on grouping:
   - Single payload: use existing generation path
   - Multiple normal payloads: create multi-payload capsule
   - Mixed/non-normal types: generate separate capsules with warning

This allows users to specify multiple firmware images for the same
capsule file in the config, and the tool will automatically create
an optimized multi-payload capsule when possible.

Example config usage:
  [capsule1]
  image-guid: <guid1>
  hardware-instance: 0
  image-index: 1
  payload: payload1.bin
  capsule: update.capsule

  [capsule1]
  image-guid: <guid2>
  hardware-instance: 0
  image-index: 2
  payload: payload2.bin
  capsule: update.capsule

This will generate a single update.capsule containing both payloads.

Signed-off-by: Balaji Selvanathan <balaji.selvanathan@oss.qualcomm.com>
Add signing support to create_multi_payload_fwbin(), which previously
rejected any payload with a private key and certificate. Per the UEFI
FMP capsule spec, signing is a per-image property, so each payload in
a multi-payload capsule can be signed independently.

Each signed payload gets its own authentication header and PKCS#7
signature written after its image header, reusing the existing
create_auth_data()/free_sig_data() helpers from the single-payload
path. Unsigned payloads in the same capsule are unaffected.

Signed-off-by: Balaji Selvanathan <balaji.selvanathan@oss.qualcomm.com>
The UEFI capsule can now be generated by specifying the capsule
parameters through a config file. Highlight these changes in the
documentation.

Also document that payloads sharing the same capsule filename are
automatically grouped into a single multi-payload capsule, and that
payloads in such a group can be individually signed, with an example
config demonstrating both behaviours.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Signed-off-by: Balaji Selvanathan <balaji.selvanathan@oss.qualcomm.com>
Add a config file that drives capsule generation through the
mkeficapsule config-file parser, and enable it on the sandbox variant.
These capsules are used to test the capsule update feature on
sandbox.

Fix Test05, which had two identical blocks (same image-guid and
image-index) that would now silently merge into an unintended
2-payload capsule under the parser's new grouping-by-filename
behavior; give the second block its own index and GUID so Test05
instead demonstrates multi-payload grouping on purpose.

Add Test116 to cover a multi-payload capsule with a signed first
payload and an unsigned second payload, and Test06/Test15 to cover
the same raw-image update path (rather than the existing FIT-image
examples), with Test06 unsigned and Test15 signing each payload
independently.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Signed-off-by: Balaji Selvanathan <balaji.selvanathan@oss.qualcomm.com>
Add logic to generate capsules through a config file while testing
the EFI capsule update functionality, and enable this on the sandbox
variant.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Signed-off-by: Balaji Selvanathan <balaji.selvanathan@oss.qualcomm.com>
Add pytest coverage that exercises a real multi-payload capsule
update end-to-end: a single capsule file containing two raw-image
payloads is applied and both target regions (U-Boot binary and
U-Boot environment) are verified to have been updated from one
capsule apply. test_efi_capsule_fw6 covers the unsigned case and
test_efi_capsule_auth6 covers the signed case, where each payload in
the capsule is signed independently.

Signed-off-by: Balaji Selvanathan <balaji.selvanathan@oss.qualcomm.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant