From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Thu, 30 Apr 2020 15:27:30 -0400 Subject: [PATCH 8/8] qemu: arm64: Add documentation for capsule update In-Reply-To: References: <20200430173630.15608-1-sughosh.ganu@linaro.org> <20200430173630.15608-9-sughosh.ganu@linaro.org> <270c907e-be81-f4a1-84b8-3931466ee87a@gmx.de> Message-ID: <20200430192730.GA4468@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Fri, May 01, 2020 at 12:38:45AM +0530, Sughosh Ganu wrote: > On Fri, 1 May 2020 at 00:07, Heinrich Schuchardt 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 > > > > 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? -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: