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.
---
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 | 25 +++
arch/arm/mach-snapdragon/capsule_update.c | 256 +++++++++++++++++++++++-------
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, 245 insertions(+), 64 deletions(-)
---
base-commit: 68ac813c70d991ec518d0fd815efdb10a05958c0
Caleb Connolly <caleb.conno...@linaro.org>
