[PATCH 1/7] qcom: capsule: add FIT capsule support with multi-partition

[Casey Connolly]

On 6/14/26 14:13, Simon Glass wrote:
> Hi Ilias,
> 
> On Mon, 25 May 2026 at 15:07, Ilias Apalodimas
> <ilias.apalodimas at linaro.org> wrote:
>>
>> Hi Simon,
>>
>> On Mon, 25 May 2026 at 21:10, Simon Glass <sjg at chromium.org> wrote:
>>>
>>> Hi all,
>>>
>>> On Mon, 25 May 2026 at 05:24, Balaji Selvanathan
>>> <balaji.selvanathan at oss.qualcomm.com> 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-sughosh.ganu@linaro.org/
>>>>
>>>> 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.
>>>
>>> Before this respins as multi-payload RAW, I'd like to push back on the
>>> suggestion that FIT is the wrong answer here.
>>>
>>> CONFIG_EFI_CAPSULE_FIRMWARE_FIT is already a first-class handler in
>>> efi_firmware.c next to the RAW one.
>>
>> We accepted it back then because we lacked capsule authentication. I
>> really want to remove it now, since I see no point having a capsule
>> within a FIT.
> 
> I may have misunderstood something here. My understanding with this
> series is that there is a FIT containing multiple images which all
> need updating atomically. So there is one ESRT, isn't there? How does
> it result in a capsule being inside a FIT?
> 
>>
>>> So the choice isn't whether to add
>>> a new mechanism, just which of the two existing handlers Qualcomm
>>> wires up. Both produce an FMP and an ESRT entry; the OS-visible UEFI
>>> behaviour is identical. The difference is entirely in what sits inside
>>> the capsule payload.
>>
>> Not really. FIT capsule will expose a single FMP entry and no
>> information of the firmware components in the esrt, unless I remember
>> the code wrong.
> 
> Well, FIT is designed to hold components so it is provided there, in a
> manner native to U-Boot.

Regardless of the merits of FIT, the EFI capsule spec explicitly 
supports having multiple images in a single capsule and updating all of 
them at once. U-Boot also already has the wiring for this. FIT is 
totally unnecessary here particularly since we don't live in the world 
where we use FIT for everything, so we don't gain any common tooling or 
abstraction by using it for this one case. As Ilias clearly pointed out 
we /lose/ visibility as EFI tooling just sees a FIT image as a binary blob.

If you wish to keep discussing in this thread please drop me from CC.