[PATCH v2 0/4] Qualcomm: expand capsule update support
Ilias Apalodimas
ilias.apalodimas at linaro.org
Tue May 6 15:26:03 CEST 2025
Hi Sumit
On Tue, 6 May 2025 at 15:37, Sumit Garg <sumit.garg at kernel.org> wrote:
>
> + 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,
>
It's not an issue. It what the EFI spec describes for capsule updates
on disk [0].
That one says
"The directory \EFI\UpdateCapsule is checked for capsules only within
the EFI system partition on the device specified in the active boot
option determine by reference to BootNext variable or BootOrder
variable processing"
So tl;dr your active boot options needs to point to the same ESP as
you active boot option.
eficonfig scans and stores default boot options when it runs, so I
guess that's what made it work for you.
> 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?
I assume the partition you store the capsule is an ESP -- IOW can you
write and preserve EFI variables?
Do you have EFI_CAPSULE_ON_DISK_EARLY enabled?
My guess is that the disk isn't scanned yet and the capsule update
doesn't start.
There are some problems currently with scanned devices that Heinrich
was looking at [1]
You can try
- efidebug capsule update <capsule address> after you load the capsule
manually. That will at least perform the update and you can move on
with reviewing the patch as the current issue is orthogonal
or
- efidebug boot add -b 1001 cap mmc 1:1 EFI/UpdateCapsule && efidebug
boot next 1001
- setenv -e -nv -bs -rt -v OsIndications =0x0000000000000004 (if you
dont have OS INDICATIONS)
- efidebug capsule disk-update
>
> -Sumit
[0] https://uefi.org/specs/UEFI/2.11/08_Services_Runtime_Services.html#delivery-of-capsules-via-file-on-mass-storage-device
[1] https://lore.kernel.org/u-boot/20250421162555.1200687-1-heinrich.schuchardt@canonical.com/
Thanks
/Ilias
>
> >
> > 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)
> >
More information about the U-Boot
mailing list