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

[Heinrich Schuchardt]

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 <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.
>
> 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