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

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

+ Heinrich

On Tue, May 06, 2025 at 01:33:33PM +0200, Casey Connolly wrote:
> 
> 
> 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,

Can you share exactly what entry works for you via "eficonfig"?

> then the
> EFI framework knows what you "boot device" is, since there is no default.

I can see the "boot device" listed as part of BootOrder as follows:

=> efidebug boot order
 1: Boot0000: mmc 0

=> efidebug boot dump
Boot0000:
attributes: A-- (0x00000001)
  label: mmc 0
  file_path: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,0000000000000000)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,6d00000000000000)/eMMC(0)/eMMC(0)
  data:
    00000000: 4e ac 08 81 11 9f 59 4d 85 0e e2 1a 52 2c 59 b2  N.....YM....R,Y.

So I am unsure why the EFI framework is unable to see that although I
can see code under API: find_boot_device() in "lib/efi_loader/efi_capsule.c"
looking for active device under BootOrder.

Ilias, Heinrich,

Do you have any clue here what may be going wrong here?

-Sumit

> 
> 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@linaro.org>
> > > 
> 
> -- 
> Casey (she/they)
>