public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Sumit Garg <sumit.garg@kernel.org>
To: Casey Connolly <casey.connolly@linaro.org>
Cc: Lukasz Majewski <lukma@denx.de>, Tom Rini <trini@konsulko.com>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Mattijs Korpershoek <mkorpershoek@kernel.org>,
	u-boot@lists.denx.de, u-boot-qcom@groups.io,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>
Subject: Re: [PATCH v2 0/4] Qualcomm: expand capsule update support
Date: Fri, 2 May 2025 16:20:15 +0530	[thread overview]
Message-ID: <aBSjZ7ospvGxJrbD@sumit-X1> (raw)
In-Reply-To: <20250411-b4-qcom-capsule-update-improvements-v2-0-27f6b2fcc4a9@linaro.org>

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

  parent reply	other threads:[~2025-05-02 10:50 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-11 15:03 [PATCH v2 0/4] Qualcomm: expand capsule update support Caleb Connolly
2025-04-11 15:03 ` [PATCH v2 1/4] mach-snapdragon: track boot source Caleb Connolly
2025-04-11 15:03 ` [PATCH v2 2/4] mach-snapdragon: CapsuleUpdate: support all boot methods Caleb Connolly
2025-04-11 15:03 ` [PATCH v2 3/4] dfu: scsi: don't call scsi_scan() Caleb Connolly
2025-04-11 15:03 ` [PATCH v2 4/4] qcom_defconfig: enable capsule update support Caleb Connolly
2025-05-02 10:50 ` Sumit Garg [this message]
2025-05-02 12:16   ` [PATCH v2 0/4] Qualcomm: expand " Casey Connolly
2025-05-02 12:37     ` Sumit Garg
2025-05-02 14:32       ` Casey Connolly
2025-05-05  5:14         ` Sumit Garg
2025-05-06  7:13 ` Sumit Garg
2025-05-06 11:33   ` Casey Connolly
2025-05-06 12:36     ` Sumit Garg
2025-05-06 13:26       ` Ilias Apalodimas
2025-05-07  8:48         ` Sumit Garg
2025-06-23 23:49 ` Casey Connolly

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aBSjZ7ospvGxJrbD@sumit-X1 \
    --to=sumit.garg@kernel.org \
    --cc=casey.connolly@linaro.org \
    --cc=ilias.apalodimas@linaro.org \
    --cc=lukma@denx.de \
    --cc=mkorpershoek@kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=trini@konsulko.com \
    --cc=u-boot-qcom@groups.io \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox