On Fri, May 01, 2020 at 11:33:42AM +0200, Heinrich Schuchardt wrote: > On 4/30/20 9:13 PM, Sughosh Ganu wrote: > > > > On Fri, 1 May 2020 at 00:09, Heinrich Schuchardt <xypron.g...@gmx.de > > <mailto:xypron.g...@gmx.de>> wrote: > > > > On 4/30/20 7:36 PM, Sughosh Ganu wrote: > > > Add support for the get_image_info and set_image routines, which are > > > part of the efi firmware management protocol. > > > > > > The current implementation uses the set_image routine for updating the > > > u-boot binary image for the qemu arm64 platform. This is supported > > > using the capsule-on-disk feature of the uefi specification, wherein > > > the firmware image to be updated is placed on the efi system partition > > > as a efi capsule under EFI/UpdateCapsule/ directory. Support has been > > > added for updating the u-boot image on platforms booting with arm > > > trusted firmware(tf-a), where the u-boot image gets booted as the BL33 > > > payload(bl33.bin). > > > > > > The feature can be enabled by the following config options > > > > > > CONFIG_EFI_CAPSULE_ON_DISK=y > > > CONFIG_EFI_FIRMWARE_MANAGEMENT_PROTOCOL=y > > > > > > Signed-off-by: Sughosh Ganu <sughosh.g...@linaro.org > > <mailto:sughosh.g...@linaro.org>> > > > > U-Boot's UEFI subsystem should work in the same way for x86, ARM, and > > RISC-V. Please, come up with an architecture independent solution. > > > > > > Please check the explanation that I gave in the other mail. If you check > > the patch series, the actual capsule authentication logic has been kept > > architecture agnostic, in efi_capsule.c. The fmp protocol is very much > > intended for allowing platforms to define their firmware update > > routines. Edk2 also has platform specific implementation of the fmp > > protocol under the edk2-platforms directory. > > > > -sughosh > > > > > > My idea is that for most platforms it will be enough to have a common > FMP implementation that consumes a capsule > > * with one or more binaries
Does this assumption apply to most platforms? If so ("one"), > * a media device path, a start address, and a truncation flag > for each of the binaries my FIT-based patch[1] meets this assumption and there already are backend drivers for many media (but not for semihosting :) as dfu. (I see little reason to re-invent another set of backend drivers.) [1] https://lists.denx.de/pipermail/u-boot/2020-April/408767.html > The protocol implementation then will write the binaries to the device > paths: > > * to an SD-Card or eMMC exposing the Block IO protocol > for most devices > * to a file in case of the Raspberry Pi or the Sandbox or QEMU > (and truncate it if the truncation flag is set) > > If for some devices like a SPI flash we do not have a media device path > yet, then the only platform specific bit would be the block device > driver exposing the media device path. > > Same with a semi-hosted file: just add a driver exposing it as a media > path with an EFI_BLOCK_IO_PROTOCOL. > > For security reasons it may be advisable to make the device read-only > when reaching ExitBootServices() or even better before the first > execution of StartImage(). For this purpose we could use the Reset() > service of the EFI_BLOCK_IO_PROTOCOL or provide a U-Boot specific > service in the EFI_BLOCK_IO_PROTOCOL. > > Best regards > > Heinrich