On Fri, May 01, 2020 at 11:17:27AM +0530, Sughosh Ganu wrote: > On Fri, 1 May 2020 at 00:57, Tom Rini <tr...@konsulko.com> wrote: > > > On Fri, May 01, 2020 at 12:38:45AM +0530, Sughosh Ganu wrote: > > > On Fri, 1 May 2020 at 00:07, Heinrich Schuchardt <xypron.g...@gmx.de> > > wrote: > > > > > > > On 4/30/20 7:36 PM, Sughosh Ganu wrote: > > > > > Add documentation highlighting the steps for using the uefi capsule > > > > > update feature for updating the u-boot firmware image. > > > > > > > > > > Signed-off-by: Sughosh Ganu <sughosh.g...@linaro.org> > > > > > > > > UEFI capsule updates should be architecture independent. I would expect > > > > that the submitted code should work for x86, ARM, and RISC-V. Why does > > > > this documentation live under the ARM emulation tree? > > > > > > > > > > While the implementation of the core capsule update functionality is > > indeed > > > architecture agnostic, this series is for implementing the routines of > > the > > > firmware management protocol, which is very much platform specific -- the > > > routines to perform the actual firmware update would be very much tied to > > > the platform for which the firmware is being updated. So Takahiro's patch > > > series, which adds the core capsule update changes is architecture > > > independent, while this series is adding the routines for the firmware > > > management protocol, which would be very much platform specific. > > > > Since we're talking QEMU here, how much of this can be easily dropped in > > to QEMU x86_64 and QEMU RISC-V? If not almost all of it, why? Can it > > be reworked as such? > > > > I don't think it would be too difficult to extend it on other > architectures, provided there is some mechanism to access and overwrite the > u-boot binary file from the qemu target. It is currently being done using > the semihosting interface for the arm architecture. I am not aware if there > is an interface like semihosting for accessing the u-boot binary on the > other architectures that you mentioned. Will check on this.
Obviously, another choice would be my FIT-based FMP[1] as it uses update_tftp(), more specifically dfu_tftp_write(), internally. [1] https://lists.denx.de/pipermail/u-boot/2020-April/408767.html Thanks, -Takahiro Akashi > -sughosh