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

[Casey Connolly]

On 5/6/25 09:13, 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).
>>
>> 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.
> 
> I gave this patch-set a try on RB1, but somehow the firmware capsule
> update didn't worked for me. I was able to install the firmware capsule
> update using the "fwupdtool" from the OS but U-Boot can't consume it
> from disk upon a reboot as follows:
> 
> Update capsule is present in EFI system partition as:
> 
> => ls mmc 0:47 EFI/UpdateCapsule/
>              ./
>              ../
>    1794156   fwupd-77f90b51-588c-5ef0-aab9-046aeb2ac8c5.cap
> 
> 1 file(s), 2 dir(s)
> 
> However, it can't be picked via a manual/automatic capsule update
> process in U-Boot:
> 
> => efidebug capsule disk-update
> =>
> 
> Is there a known issue? After enabling debug logs, I see the capsule
> update invocation bails out from here [1].

Yes, this is a known issue. I was able to work around it by running 
`eficonfig` and creating an entry pointing to the same partition, then 
the EFI framework knows what you "boot device" is, since there is no 
default.

I spoke with Ilias about this and we think it's appropriate to bypass 
this check if the option is enabled to ignore OS indications, but didn't 
get aroudn to implementing it yet.

Kind regards,

> 
> [1] https://source.denx.de/u-boot/u-boot/-/blob/master/lib/efi_loader/efi_capsule.c?ref_type=heads#L1037
> 
> -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)