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).
Does this means say if we are booting from "A" partition then the update gets applied to "A" partition only? IOW, we don't support dual bank updates as of now? > > 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. Thanks for working on EFI firmware capsule updates feature. I think currently we are missing any documentation from this patch-set. IOW, how one can test updating U-Boot via EFI firmware capsules? I suppose we are using here dynamic GUID generation while creating update capsules, right? -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> >
