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

[Sumit Garg <sumit.garg@kernel.org>]

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].

[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@linaro.org>
>