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
