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 18:07:11 +0530	[thread overview]
Message-ID: <aBS8d8sffQitinZW@sumit-X1> (raw)
In-Reply-To: <3a56b0bb-9446-42f2-9b85-ae65de295499@linaro.org>

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

  reply	other threads:[~2025-05-02 12:37 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 ` [PATCH v2 0/4] Qualcomm: expand " Sumit Garg
2025-05-02 12:16   ` Casey Connolly
2025-05-02 12:37     ` Sumit Garg [this message]
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=aBS8d8sffQitinZW@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