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

[Sumit Garg <sumit.garg@kernel.org>]

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