[PATCH 8/8] qemu: arm64: Add documentation for capsule update

[Sughosh Ganu]

On Fri, 1 May 2020 at 00:57, Tom Rini <trini at 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.glpk at 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.ganu at 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.

-sughosh