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