[PATCH v2 0/4] Qualcomm: expand capsule update support

[PATCH v2 0/4] Qualcomm: expand capsule update support

[Caleb Connolly]

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.

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

[PATCH v2 1/4] mach-snapdragon: track boot source

[Caleb Connolly]

Keep track of whether we were loaded via ABL or if U-Boot is running as
a first-stage bootloader.

For now we set this based on if we have a valid external FDT or not,
since it isn't possible to chainload U-Boot from ABL without there being
an external FDT.

This will be used to inform the capsule update logic which partition
U-Boot is flashed to.

Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
---
 arch/arm/mach-snapdragon/board.c     | 26 ++++++++++++++++++++++++++
 arch/arm/mach-snapdragon/qcom-priv.h | 14 ++++++++++++++
 2 files changed, 40 insertions(+)

diff --git a/arch/arm/mach-snapdragon/board.c b/arch/arm/mach-snapdragon/board.c
index deae4d323789eab75d5fe735159b4cd820c02c45..34e37ab083f20b70660f2ab90a2995a4dfb33f8e 100644
--- a/arch/arm/mach-snapdragon/board.c
+++ b/arch/arm/mach-snapdragon/board.c
@@ -36,8 +36,10 @@
 #include "qcom-priv.h"
 
 DECLARE_GLOBAL_DATA_PTR;
 
+enum qcom_boot_source qcom_boot_source __section(".data") = 0;
+
 static struct mm_region rbx_mem_map[CONFIG_NR_DRAM_BANKS + 2] = { { 0 } };
 
 struct mm_region *mem_map = rbx_mem_map;
 
@@ -237,8 +239,14 @@ int board_fdt_blob_setup(void **fdtp)
 
 	if (ret < 0)
 		panic("No valid memory ranges found!\n");
 
+	/* If we have an external FDT, it can only have come from the Android bootloader. */
+	if (external_valid)
+		qcom_boot_source = QCOM_BOOT_SOURCE_ANDROID;
+	else
+		qcom_boot_source = QCOM_BOOT_SOURCE_XBL;
+
 	debug("ram_base = %#011lx, ram_size = %#011llx\n",
 	      gd->ram_base, gd->ram_size);
 
 	if (internal_valid) {
@@ -472,8 +480,25 @@ static void configure_env(void)
 
 	qcom_set_serialno();
 }
 
+void qcom_show_boot_source(void)
+{
+	const char *name = "UNKNOWN";
+
+	switch (qcom_boot_source) {
+	case QCOM_BOOT_SOURCE_ANDROID:
+		name = "ABL";
+		break;
+	case QCOM_BOOT_SOURCE_XBL:
+		name = "XBL";
+		break;
+	}
+
+	log_info("U-Boot loaded from %s\n", name);
+	env_set("boot_source", name);
+}
+
 void __weak qcom_late_init(void)
 {
 }
 
@@ -515,8 +540,9 @@ int board_late_init(void)
 
 	configure_env();
 	qcom_late_init();
 
+	qcom_show_boot_source();
 	/* Configure the dfu_string for capsule updates */
 	qcom_configure_capsule_updates();
 
 	return 0;
diff --git a/arch/arm/mach-snapdragon/qcom-priv.h b/arch/arm/mach-snapdragon/qcom-priv.h
index 74d39197b89f4e769299b06214c26ee829ecdce0..e5eb4cfbc2b752de799b1407ede69683c81474c1 100644
--- a/arch/arm/mach-snapdragon/qcom-priv.h
+++ b/arch/arm/mach-snapdragon/qcom-priv.h
@@ -2,8 +2,22 @@
 
 #ifndef __QCOM_PRIV_H__
 #define __QCOM_PRIV_H__
 
+/**
+ * enum qcom_boot_source - Track where we got loaded from.
+ * Used for capsule update logic.
+ *
+ * @QCOM_BOOT_SOURCE_ANDROID: chainloaded (typically from ABL)
+ * @QCOM_BOOT_SOURCE_XBL: flashed to the XBL or UEFI partition
+ */
+enum qcom_boot_source {
+	QCOM_BOOT_SOURCE_ANDROID = 1,
+	QCOM_BOOT_SOURCE_XBL,
+};
+
+extern enum qcom_boot_source qcom_boot_source;
+
 #if IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT)
 void qcom_configure_capsule_updates(void);
 #else
 void qcom_configure_capsule_updates(void) {}

-- 
2.49.0

[PATCH v2 2/4] mach-snapdragon: CapsuleUpdate: support all boot methods

[Caleb Connolly]

Expand capsule update support to correctly identify which partition
U-Boot is flashed to (between xbl, uefi, and boot including A/B
variants).

Use qcom_boot_source to determine if we were chainloaded from ABL,
meaning U-Boot is on the boot partition, otherwise we assume uefi if
it's available, finally leaving the xbl partition.

Set a different fw_name based on the target partition to prevent GUID
collisions, since a board may support U-Boot flashed to boot or XBL we
need to differentiate them since the U-Boot binary must be built
differently.

Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
---
 arch/arm/mach-snapdragon/capsule_update.c | 274 ++++++++++++++++++++++++------
 1 file changed, 223 insertions(+), 51 deletions(-)

diff --git a/arch/arm/mach-snapdragon/capsule_update.c b/arch/arm/mach-snapdragon/capsule_update.c
index bf75a9a1b24c714792bae3712b83b96353b1df8f..4dced4961b684be198d8f9b5e30d2264871ea163 100644
--- a/arch/arm/mach-snapdragon/capsule_update.c
+++ b/arch/arm/mach-snapdragon/capsule_update.c
@@ -19,24 +19,21 @@
 
 #include "qcom-priv.h"
 
 /*
- * NOTE: for now this implementation only supports the rb3gen2. Supporting other
- * boards that boot in different ways (e.g. chainloaded from ABL) will require
- * additional complexity to properly create the dfu string and fw_images array.
- */
-
-/*
- * To handle different variants like chainloaded U-Boot here we'll need to
- * build the fw_images array dynamically at runtime. It looks like
- * mach-rockchip is a good example for how to do this.
- * Detecting which image types a board uses is TBD, hence for now we only
- * support the one new board that runs U-Boot as its primary bootloader.
+ * To handle different variants like chainloaded U-Boot here we need to
+ * build the fw_images array dynamically at runtime. These are the possible
+ * implementations:
+ *
+ * - Devices with U-Boot on the uefi_a/b partition
+ * - Devices with U-Boot on the boot (a/b) partition
+ * - Devices with U-Boot on the xbl (a/b) partition
+ *
+ * Which partition actually has U-Boot on it is determined based on the
+ * qcom_boot_source variable and additional logic in find_target_partition().
  */
 struct efi_fw_image fw_images[] = {
 	{
-		/* U-Boot flashed to the uefi_X partition (e.g. rb3gen2) */
-		.fw_name = u"UBOOT_UEFI_PARTITION",
 		.image_index = 1,
 	},
 };
 
@@ -46,8 +43,14 @@ struct efi_capsule_update_info update_info = {
 	.num_images = ARRAY_SIZE(fw_images),
 	.images = fw_images,
 };
 
+enum target_part_type {
+	TARGET_PART_UEFI = 1,
+	TARGET_PART_XBL,
+	TARGET_PART_BOOT,
+};
+
 /* LSB first */
 struct part_slot_status {
 	u16: 2;
 	u16 active : 1;
@@ -56,37 +59,204 @@ struct part_slot_status {
 	u16 unbootable : 1;
 	u16 tries_remaining : 4;
 };
 
-static int find_boot_partition(const char *partname, struct blk_desc *blk_dev, char *name)
+enum ab_slot {
+	SLOT_NONE,
+	SLOT_A,
+	SLOT_B,
+};
+
+static enum ab_slot get_part_slot(const char *partname)
+{
+	int len = strlen(partname);
+
+	if (partname[len - 2] != '_')
+		return SLOT_NONE;
+	if (partname[len - 1] == 'a')
+		return SLOT_A;
+	if (partname[len - 1] == 'b')
+		return SLOT_B;
+
+	return SLOT_NONE;
+}
+
+/*
+ * Determine which partition U-Boot is flashed to based on the boot source (ABL/XBL),
+ * the slot status, and prioritizing the uefi partition over xbl if found.
+ */
+static int find_target_partition(int *devnum, enum uclass_id *uclass,
+				 enum target_part_type *target_part_type)
 {
 	int ret;
-	int partnum;
+	int partnum, uefi_partnum = -1, xbl_partnum = -1;
 	struct disk_partition info;
 	struct part_slot_status *slot_status;
+	struct udevice *dev = NULL;
+	struct blk_desc *desc = NULL, *xbl_desc = NULL;
+	uchar ptn_name[32] = { 0 };
+	bool have_ufs = false;
 
-	for (partnum = 1;; partnum++) {
-		ret = part_get_info(blk_dev, partnum, &info);
-		if (ret)
-			return ret;
+	/*
+	 * Check to see if we have UFS storage, if so U-Boot MUST be on it and we can skip
+	 * all non-UFS block devices
+	 */
+	uclass_foreach_dev_probe(UCLASS_UFS, dev) {
+		have_ufs = true;
+		break;
+	}
 
-		slot_status = (struct part_slot_status *)&info.type_flags;
-		log_io("%16s: Active: %1d, Successful: %1d, Unbootable: %1d, Tries left: %1d\n",
-		       info.name, slot_status->active,
-		       slot_status->successful, slot_status->unbootable,
-		       slot_status->tries_remaining);
+	uclass_foreach_dev_probe(UCLASS_BLK, dev) {
+		if (device_get_uclass_id(dev) != UCLASS_BLK)
+			continue;
+
+		/* If we have a UFS then don't look at any other block devices */
+		if (have_ufs) {
+			if (device_get_uclass_id(dev->parent->parent) != UCLASS_UFS)
+				continue;
 		/*
-		 * FIXME: eventually we'll want to find the active/inactive variant of the partition
-		 * but on the rb3gen2 these values might all be 0
+		 * If we don't have UFS, then U-Boot must be on the eMMC which is always the first
+		 * MMC device.
 		 */
-		if (!strncmp(info.name, partname, strlen(partname))) {
-			log_debug("Found active %s partition: '%s'!\n", partname, info.name);
-			strlcpy(name, info.name, sizeof(info.name));
-			return partnum;
+		} else if (dev->parent->seq_ > 0) {
+			continue;
+		}
+
+		desc = dev_get_uclass_plat(dev);
+		if (!desc || desc->part_type == PART_TYPE_UNKNOWN)
+			continue;
+		for (partnum = 1;; partnum++) {
+			ret = part_get_info(desc, partnum, &info);
+			if (ret)
+				break;
+
+			slot_status = (struct part_slot_status *)&info.type_flags;
+
+			/*
+			 * Qualcomm Linux devices have a "uefi" partition, it's A/B but the
+			 * flags might not be set so we assume the A partition unless the B
+			 * partition is active.
+			 */
+			if (!strncmp(info.name, "uefi", strlen("uefi"))) {
+				/*
+				 * If U-Boot was chainloaded somehow we can't be flashed to
+				 * the uefi partition
+				 */
+				if (qcom_boot_source != QCOM_BOOT_SOURCE_XBL)
+					continue;
+
+				*target_part_type = TARGET_PART_UEFI;
+				/*
+				 * Found an active UEFI partition, this is where U-Boot is
+				 * flashed.
+				 */
+				if (slot_status->active)
+					goto found;
+
+				/* Prefer A slot if it's not marked active */
+				if (get_part_slot(info.name) == SLOT_A) {
+					/*
+					 * If we found the A slot after the B slot (both
+					 * inactive) then we assume U-Boot is on the A slot.
+					 */
+					if (uefi_partnum >= 0)
+						goto found;
+
+					/* Didn't find the B slot yet */
+					uefi_partnum = partnum;
+					strlcpy(ptn_name, info.name, 32);
+				} else {
+					/*
+					 * Found inactive B slot after inactive A slot, return
+					 * the A slot
+					 */
+					if (uefi_partnum >= 0) {
+						partnum = uefi_partnum;
+						goto found;
+					}
+
+					/*
+					 * Didn't find the A slot yet. Record that we found the
+					 * B slot
+					 */
+					uefi_partnum = partnum;
+					strlcpy(ptn_name, info.name, 32);
+				}
+				/* xbl and aboot are effectively the same */
+			} else if ((!strncmp(info.name, "xbl", strlen("xbl")) &&
+				    strlen(info.name) == 5) ||
+				    !strncmp(info.name, "aboot", strlen("aboot"))) {
+				/*
+				 * If U-Boot was booted via ABL, we can't be flashed to the
+				 * XBL partition
+				 */
+				if (qcom_boot_source != QCOM_BOOT_SOURCE_XBL)
+					continue;
+
+				/*
+				 * ignore xbl partition if we have uefi partitions, U-Boot will
+				 * always be on the UEFI partition in this case.
+				 */
+				if (*target_part_type == TARGET_PART_UEFI)
+					continue;
+
+				/* Either non-A/B or find the active XBL partition */
+				if (slot_status->active || !get_part_slot(info.name)) {
+					/*
+					 * No quick return since we might find a uefi partition
+					 * later
+					 */
+					xbl_partnum = partnum;
+					*target_part_type = TARGET_PART_XBL;
+					xbl_desc = desc;
+					strlcpy(ptn_name, info.name, 32);
+				}
+
+				/*
+				 * No fast return since we might also have a uefi partition which
+				 * will take priority.
+				 */
+			} else if (!strncmp(info.name, "boot", strlen("boot"))) {
+				/* We can only be flashed to boot if we were chainloaded */
+				if (qcom_boot_source != QCOM_BOOT_SOURCE_ANDROID)
+					continue;
+
+				/*
+				 * Either non-A/B or find the active partition. We can return
+				 * immediately here since we've narrowed it down to a single option
+				 */
+				if (slot_status->active || !get_part_slot(info.name)) {
+					*target_part_type = TARGET_PART_BOOT;
+					goto found;
+				}
+			}
 		}
 	}
 
+	/*
+	 * Now we've exhausted all options, if we didn't find a uefi partition
+	 * then we are indeed flashed to the xbl partition.
+	 */
+	if (*target_part_type == TARGET_PART_XBL) {
+		partnum = xbl_partnum;
+		desc = xbl_desc;
+		goto found;
+	}
+
+	/* Found no candidate partitions */
 	return -1;
+
+found:
+	if (desc) {
+		*devnum = desc->devnum;
+		*uclass = desc->uclass_id;
+	}
+
+	/* info won't match for XBL hence the copy. */
+	log_info("Capsule update target: %s (disk %d:%d)\n",
+		 *target_part_type == TARGET_PART_BOOT ? info.name : ptn_name,
+		 *devnum, partnum);
+	return partnum;
 }
 
 /**
  * qcom_configure_capsule_updates() - Configure the DFU string for capsule updates
@@ -100,14 +270,12 @@ static int find_boot_partition(const char *partname, struct blk_desc *blk_dev, c
  * in the GPT partition vendor attribute bits.
  */
 void qcom_configure_capsule_updates(void)
 {
-	struct blk_desc *desc;
 	int ret = 0, partnum = -1, devnum;
 	static char dfu_string[32] = { 0 };
-	char name[32]; /* GPT partition name */
-	char *partname = "uefi_a";
-	struct udevice *dev = NULL;
+	enum target_part_type target_part_type = 0;
+	enum uclass_id dev_uclass;
 
 	if (IS_ENABLED(CONFIG_SCSI)) {
 		/* Scan for SCSI devices */
 		ret = scsi_scan(false);
@@ -116,38 +284,42 @@ void qcom_configure_capsule_updates(void)
 			return;
 		}
 	}
 
-	uclass_foreach_dev_probe(UCLASS_BLK, dev) {
-		if (device_get_uclass_id(dev) != UCLASS_BLK)
-			continue;
-
-		desc = dev_get_uclass_plat(dev);
-		if (!desc || desc->part_type == PART_TYPE_UNKNOWN)
-			continue;
-		devnum = desc->devnum;
-		partnum = find_boot_partition(partname, desc,
-					      name);
-		if (partnum >= 0)
-			break;
-	}
-
+	partnum = find_target_partition(&devnum, &dev_uclass, &target_part_type);
 	if (partnum < 0) {
 		log_err("Failed to find boot partition\n");
 		return;
 	}
 
-	switch (desc->uclass_id) {
+	/*
+	 * Set the fw_name based on the partition type. This causes the GUID to be different
+	 * so we will never accidentally flash a U-Boot image intended for XBL to the boot
+	 * partition.
+	 */
+	switch (target_part_type) {
+	case TARGET_PART_UEFI:
+		fw_images[0].fw_name = u"UBOOT_UEFI_PARTITION";
+		break;
+	case TARGET_PART_XBL:
+		fw_images[0].fw_name = u"UBOOT_XBL_PARTITION";
+		break;
+	case TARGET_PART_BOOT:
+		fw_images[0].fw_name = u"UBOOT_BOOT_PARTITION";
+		break;
+	}
+
+	switch (dev_uclass) {
 	case UCLASS_SCSI:
 		snprintf(dfu_string, 32, "scsi %d=u-boot.bin part %d", devnum, partnum);
 		break;
 	case UCLASS_MMC:
 		snprintf(dfu_string, 32, "mmc 0=u-boot.bin part %d %d", devnum, partnum);
 		break;
 	default:
-		debug("Unsupported storage uclass: %d\n", desc->uclass_id);
+		debug("Unsupported storage uclass: %d\n", dev_uclass);
 		return;
 	}
-	log_debug("boot partition is %s, DFU string: '%s'\n", name, dfu_string);
+	log_debug("DFU string: '%s'\n", dfu_string);
 
 	update_info.dfu_string = dfu_string;
 }

-- 
2.49.0

[PATCH v2 3/4] dfu: scsi: don't call scsi_scan()

[Caleb Connolly]

Calling scsi_scan() results in all the block devices (and EFI block
devices) being destroyed and re-created. This breaks the EFI filesystem
drivers during capsule update.

Remove the call, since boards really should be calling scsi_scan()
themselves during board_init().

Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
---
 drivers/dfu/dfu_scsi.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/drivers/dfu/dfu_scsi.c b/drivers/dfu/dfu_scsi.c
index 9f95194784c1de00458843276872b1d23d023444..a234548ae46dc2a6ae1ca5770accb58f43782239 100644
--- a/drivers/dfu/dfu_scsi.c
+++ b/drivers/dfu/dfu_scsi.c
@@ -341,13 +341,8 @@ int dfu_fill_entity_scsi(struct dfu_entity *dfu, char *devstr, char **argv, int
 		if (*s)
 			return -EINVAL;
 	}
 
-	if (scsi_scan(false)) {
-		pr_err("Couldn't init scsi device.\n");
-		return -ENODEV;
-	}
-
 	ret = find_scsi_device(dfu->data.scsi.lun, &scsi);
 	if (ret < 0) {
 		pr_err("Couldn't find scsi device no. %d.\n", dfu->data.scsi.lun);
 		return -ENODEV;

-- 
2.49.0

[PATCH v2 4/4] qcom_defconfig: enable capsule update support

[Caleb Connolly]

We can now correctly identify which partition U-Boot is flashed to
between uefi, xbl, and boot (including A/B support) so enable capsule
update support for all boards.

Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
---
 configs/qcm6490_defconfig | 6 ------
 configs/qcom_defconfig    | 3 +++
 2 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/configs/qcm6490_defconfig b/configs/qcm6490_defconfig
index ba26924da161b1c4b5378955185f314b05cb1006..5ddc5ab3ef8cfe8f9cc09eb573c1a8130b394b43 100644
--- a/configs/qcm6490_defconfig
+++ b/configs/qcm6490_defconfig
@@ -18,10 +18,4 @@ CONFIG_DEBUG_UART_CLOCK=14745600
 CONFIG_TEXT_BASE=0x9fc00000
 CONFIG_REMAKE_ELF=y
 
 CONFIG_DEFAULT_DEVICE_TREE="qcom/qcs6490-rb3gen2"
-
-# Enable capsule updates
-CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
-CONFIG_EFI_CAPSULE_ON_DISK=y
-CONFIG_EFI_IGNORE_OSINDICATIONS=y
-CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig
index 537806450dc4a61d3c617cdd2b0cfb8eab1c343c..36e2f45d22aeec6d8c4d904d22bfc466ca1f5b0d 100644
--- a/configs/qcom_defconfig
+++ b/configs/qcom_defconfig
@@ -5,8 +5,11 @@ CONFIG_SYS_INIT_SP_BSS_OFFSET=1572864
 CONFIG_ARCH_SNAPDRAGON=y
 CONFIG_NR_DRAM_BANKS=24
 CONFIG_DEFAULT_DEVICE_TREE="qcom/sdm845-db845c"
 CONFIG_SYS_LOAD_ADDR=0xA0000000
+CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
+CONFIG_EFI_CAPSULE_ON_DISK=y
+CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
 CONFIG_BUTTON_CMD=y
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_BOOTSTD_FULL=y

-- 
2.49.0

Re: [PATCH v2 0/4] Qualcomm: expand capsule update support

[Sumit Garg]

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

Re: [PATCH v2 0/4] Qualcomm: expand capsule update support

[Casey Connolly]

Hi Sumit,

On 5/2/25 12:50, 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).
> 
> 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?

Yes exactly, to have A/B working we would need the following:

* Implement all the fiddly GPT stuff (the vendor bits but also swapping 
the partition type GUIDs between A/B partitions)
* Change MMC/UFS boot block/LUN
* Support flashing all other bootloader partitions via capsule update

And really some tooling to produce said capsule update files containing 
all the bootloader related images.

> 
>>
>> 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?

Yes, we're using dynamic GUIDs. I have written a small tool and brief 
docs here for creating an LVFS cabinet which can be used with FWUPD

https://github.com/kcxt/mkcab

I'll write something in doc/board/qualcomm to explain things too 
(excluding the LVFS bits).

Kind regards,
Casey (she/they)>
> -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@linaro.org>
>>

-- 
Casey (she/they)

Re: [PATCH v2 0/4] Qualcomm: expand capsule update support

[Sumit Garg]

On Fri, May 02, 2025 at 02:16:53PM +0200, Casey Connolly wrote:
> Hi Sumit,
> 
> On 5/2/25 12:50, 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).
> > 
> > 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?
> 
> Yes exactly, to have A/B working we would need the following:
> 
> * Implement all the fiddly GPT stuff (the vendor bits but also swapping the
> partition type GUIDs between A/B partitions)
> * Change MMC/UFS boot block/LUN
> * Support flashing all other bootloader partitions via capsule update
> 
> And really some tooling to produce said capsule update files containing all
> the bootloader related images.

Thanks for the info, those can sure be next steps.

> 
> > 
> > > 
> > > 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?
> 
> Yes, we're using dynamic GUIDs. I have written a small tool and brief docs
> here for creating an LVFS cabinet which can be used with FWUPD
> 
> https://github.com/kcxt/mkcab

Thanks for working on that tooling. However, it would be better for
U-Boot documentation to instead use standard tooling like:

$ fwupdtool build-cabinet ARCHIVE FIRMWARE METAINFO

where we can provide an example meta info xml file in the docs for Qcom
platforms.

> 
> I'll write something in doc/board/qualcomm to explain things too (excluding
> the LVFS bits).

Thanks.

-Sumit

> 
> Kind regards,
> Casey (she/they)>
> > -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@linaro.org>
> > > 
> 
> -- 
> Casey (she/they)
> 

Re: [PATCH v2 0/4] Qualcomm: expand capsule update support

[Casey Connolly]

On 5/2/25 14:37, Sumit Garg wrote:
> On Fri, May 02, 2025 at 02:16:53PM +0200, Casey Connolly wrote:
>> Hi Sumit,
>>
>> On 5/2/25 12:50, 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).
>>>
>>> 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?
>>
>> Yes exactly, to have A/B working we would need the following:
>>
>> * Implement all the fiddly GPT stuff (the vendor bits but also swapping the
>> partition type GUIDs between A/B partitions)
>> * Change MMC/UFS boot block/LUN
>> * Support flashing all other bootloader partitions via capsule update
>>
>> And really some tooling to produce said capsule update files containing all
>> the bootloader related images.
> 
> Thanks for the info, those can sure be next steps.
> 
>>
>>>
>>>>
>>>> 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?
>>
>> Yes, we're using dynamic GUIDs. I have written a small tool and brief docs
>> here for creating an LVFS cabinet which can be used with FWUPD
>>
>> https://github.com/kcxt/mkcab
> 
> Thanks for working on that tooling. However, it would be better for
> U-Boot documentation to instead use standard tooling like:
> 
> $ fwupdtool build-cabinet ARCHIVE FIRMWARE METAINFO
> 
> where we can provide an example meta info xml file in the docs for Qcom
> platforms.

oh lol, you mean this exact thing already exists! grrr>
>>
>> I'll write something in doc/board/qualcomm to explain things too (excluding
>> the LVFS bits).
> 
> Thanks.
> 
> -Sumit
> 
>>
>> Kind regards,
>> Casey (she/they)>
>>> -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@linaro.org>
>>>>
>>
>> -- 
>> Casey (she/they)
>>

-- 
Casey (she/they)

Re: [PATCH v2 0/4] Qualcomm: expand capsule update support

[Sumit Garg]

On Fri, May 02, 2025 at 04:32:44PM +0200, Casey Connolly wrote:
> 
> 
> On 5/2/25 14:37, Sumit Garg wrote:
> > On Fri, May 02, 2025 at 02:16:53PM +0200, Casey Connolly wrote:
> > > Hi Sumit,
> > > 
> > > On 5/2/25 12:50, 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).
> > > > 
> > > > 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?
> > > 
> > > Yes exactly, to have A/B working we would need the following:
> > > 
> > > * Implement all the fiddly GPT stuff (the vendor bits but also swapping the
> > > partition type GUIDs between A/B partitions)
> > > * Change MMC/UFS boot block/LUN
> > > * Support flashing all other bootloader partitions via capsule update
> > > 
> > > And really some tooling to produce said capsule update files containing all
> > > the bootloader related images.
> > 
> > Thanks for the info, those can sure be next steps.
> > 
> > > 
> > > > 
> > > > > 
> > > > > 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?
> > > 
> > > Yes, we're using dynamic GUIDs. I have written a small tool and brief docs
> > > here for creating an LVFS cabinet which can be used with FWUPD
> > > 
> > > https://github.com/kcxt/mkcab
> > 
> > Thanks for working on that tooling. However, it would be better for
> > U-Boot documentation to instead use standard tooling like:
> > 
> > $ fwupdtool build-cabinet ARCHIVE FIRMWARE METAINFO
> > 
> > where we can provide an example meta info xml file in the docs for Qcom
> > platforms.
> 
> oh lol, you mean this exact thing already exists! grrr>

Yeah but TBH the documentation is pretty limited for that tool.

-Sumit

Re: [PATCH v2 0/4] Qualcomm: expand capsule update support

[Sumit Garg]

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

Re: [PATCH v2 0/4] Qualcomm: expand capsule update support

[Casey Connolly]

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

-- 
Casey (she/they)

Re: [PATCH v2 0/4] Qualcomm: expand capsule update support

[Sumit Garg]

+ 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,

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?

-Sumit

> 
> 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@linaro.org>
> > > 
> 
> -- 
> Casey (she/they)
> 

Re: [PATCH v2 0/4] Qualcomm: expand capsule update support

[Ilias Apalodimas]

Hi Sumit

On Tue, 6 May 2025 at 15:37, Sumit Garg <sumit.garg@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@linaro.org>
> > > >
> >
> > --
> > Casey (she/they)
> >

Re: [PATCH v2 0/4] Qualcomm: expand capsule update support

[Sumit Garg]

Hi Ilias,

Thanks for your response.

On Tue, May 06, 2025 at 04:26:03PM +0300, Ilias Apalodimas wrote:
> Hi Sumit
> 
> On Tue, 6 May 2025 at 15:37, Sumit Garg <sumit.garg@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.

Agree, however this patch-set doesn't enable EFI runtime variable
services and hence CONFIG_EFI_IGNORE_OSINDICATIONS=y is set. Hence the
BootNext or BootOrder variables can't get configured by the OS
(fwupdtool). That's probably why Casey used `eficonfig` to set up new
boot entry pointing at ESP or the approach you mentioned below is
additionally needed for capsule update to work with this patch-set.

Casey,

It is something we should put under documenation for capsule update
support until we enable runtime EFI variables support.

> 
> > 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?

Yeah the EFI variable storage based on ESP file is enabled by this
patch-set.

> 
> Do you have EFI_CAPSULE_ON_DISK_EARLY enabled?

I am just directly testing this patch-set on RB1 and using fwupdtool on
the OS side to install capsules. So, EFI_CAPSULE_ON_DISK_EARLY isn't
enabled.

> My guess is that the disk isn't scanned yet and the capsule update
> doesn't start.

I can see the disk being scanned however as I mentioned above the ESP
boot entry is missing since the runtime variables support isn't present.

> 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

Thanks for this suggestion, now I am able to get the capsule update to
work by manually adding a boot next entry as per following diff:

diff --git a/board/qualcomm/default.env b/board/qualcomm/default.env
index dbf6f4e7260..87703b5a643 100644
--- a/board/qualcomm/default.env
+++ b/board/qualcomm/default.env
@@ -3,7 +3,9 @@ stdout=serial,vidconsole
 stderr=serial,vidconsole
 preboot=scsi scan; usb start
 fastboot=fastboot -l $fastboot_addr_r usb 0
-do_boot=bootefi bootmgr
+cap_update=efidebug boot add -b 1001 cap mmc 0:47 EFI/UpdateCapsule && efidebug boot next 1001 && efidebug capsule disk-update
+cap_cleanup=efidebug boot rm 1001 && efidebug boot next 0000
+do_boot=run cap_update; run cap_cleanup; bootefi bootmgr
 bootmenu_0=Boot first available device=run do_boot
 bootmenu_1=Enable fastboot mode=run fastboot
 bootmenu_2=Reset device=reset

Since this diff requires specifying ESP partition specific to RB1, we
can't merge something like this upstream. So I am just hoping if the
generic EFI framework is able to auto discover the ESP partition for
capsule updates similar to how ESP is dicovered during boot in case the
EFI runtime variables and OsIndications aren't supported.

-Sumit

> 
> >
> > -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
> 
> 

Re: [PATCH v2 0/4] Qualcomm: expand capsule update support

[Casey Connolly]

On Fri, 11 Apr 2025 17:03:33 +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).
> 
> [...]

Applied, thanks!

[1/4] mach-snapdragon: track boot source
      https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/41feef758d18
[2/4] mach-snapdragon: CapsuleUpdate: support all boot methods
      https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/e0208fc4195c
[3/4] dfu: scsi: don't call scsi_scan()
      https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/a4c413862b8f
[4/4] qcom_defconfig: enable capsule update support
      https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/c4b9eb6abb9c

Best regards,
-- 
Casey Connolly <casey.connolly@linaro.org>