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, then
the EFI framework knows what you "boot device" is, since there is no
default.
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-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>
--
Casey (she/they)
