[PATCH v2 0/4] Qualcomm: expand capsule update support

[Casey Connolly]

Hi Sumit,

On 5/2/25 12:50, Sumit Garg wrote:
> Hi Casey
> 
> On Fri, Apr 11, 2025 at 05:03:33PM +0200, Caleb Connolly wrote:
>> The initial capsule update support only worked on the RB3 Gen 2 and made
>> a lot of assumptions specific to that board.
>>
>> Implement the logic necessary to update U-Boot no matter where it was
>> flashed to, independent of any particular board.
>>
>> First, we keep track of how U-Boot was loaded, specifically if we had a
>> valid external FDT (even if we didn't use it) this indicates that we
>> were booted via the Android bootloader, in this case the target for
>> capsule updates is the boot partition. Otherwise, we target the uefi
>> partition (if it exists) or the xbl partition. We handle A/B support for
>> all 3 (currently we always flash to the currently active partition with
>> a minor exception for the uefi partition).
> 
> Does this means say if we are booting from "A" partition then the update
> gets applied to "A" partition only? IOW, we don't support dual bank
> updates as of now?

Yes exactly, to have A/B working we would need the following:

* Implement all the fiddly GPT stuff (the vendor bits but also swapping 
the partition type GUIDs between A/B partitions)
* Change MMC/UFS boot block/LUN
* Support flashing all other bootloader partitions via capsule update

And really some tooling to produce said capsule update files containing 
all the bootloader related images.

> 
>>
>> We introduce two new fw_name strings to differentiate the GUIDs based on
>> the target partition, this means one board can support multiple boot
>> methods with capsule update support for all of them (typically this
>> would be chainloading OR flashing U-Boot to XBL).
>>
>> Lastly, the call to scsi_scan() in dfu_scsi.c is removed. Since
>> scsi_scan() unbinds all scsi devices it breaks device handles maintained
>> in the EFI layer for the duration of the capsule update process and
>> causes the EFI filesystem access to delete the capsule file after the
>> update to fail.
>>
>> Boards should instead be responsible for calling scsi_scan() before
>> initiating DFU.
> 
> Thanks for working on EFI firmware capsule updates feature. I think
> currently we are missing any documentation from this patch-set. IOW, how
> one can test updating U-Boot via EFI firmware capsules? I suppose we are
> using here dynamic GUID generation while creating update capsules,
> right?

Yes, we're using dynamic GUIDs. I have written a small tool and brief 
docs here for creating an LVFS cabinet which can be used with FWUPD

https://github.com/kcxt/mkcab

I'll write something in doc/board/qualcomm to explain things too 
(excluding the LVFS bits).

Kind regards,
Casey (she/they)>
> -Sumit
> 
>>
>> ---
>> Changes in v2:
>> - Restrict the partition hunt to either UFS storage or the first MMC
>>    device so that we never accidentally write to some external storage
>>    (like an sdcard) during a capsule update.
>> - Fix typo
>> - Link to v1: https://lore.kernel.org/r/20250326-b4-qcom-capsule-update-improvements-v1-0-afe2e3696675@linaro.org
>>
>> ---
>> Caleb Connolly (4):
>>        mach-snapdragon: track boot source
>>        mach-snapdragon: CapsuleUpdate: support all boot methods
>>        dfu: scsi: don't call scsi_scan()
>>        qcom_defconfig: enable capsule update support
>>
>>   arch/arm/mach-snapdragon/board.c          |  26 +++
>>   arch/arm/mach-snapdragon/capsule_update.c | 274 ++++++++++++++++++++++++------
>>   arch/arm/mach-snapdragon/qcom-priv.h      |  14 ++
>>   configs/qcm6490_defconfig                 |   6 -
>>   configs/qcom_defconfig                    |   3 +
>>   drivers/dfu/dfu_scsi.c                    |   5 -
>>   6 files changed, 266 insertions(+), 62 deletions(-)
>> ---
>> base-commit: 885d68280c29b8011731b6a7cdac32b8d9a4e6fd
>> change-id: 20250326-b4-qcom-capsule-update-improvements-16ff7bc2d1d2
>>
>> Caleb Connolly <caleb.connolly at linaro.org>
>>

-- 
Casey (she/they)