On 5/7/20 4:10 AM, Akashi Takahiro wrote: > 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
Please, try to align. We should avoid alternative implementations were not needed. We could also have a chat on Zoom together. Best regards Heinrich > > >> -sughosh