[PATCH 3/8] qemu: arm64: Add support for efi firmware management protocol routines

[Akashi Takahiro <takahiro.akashi@linaro.org>]

On Thu, May 07, 2020 at 10:47:47PM +0200, Heinrich Schuchardt wrote:
> On 5/7/20 4:33 AM, Akashi Takahiro wrote:
> > 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.glpk@gmx.de
> >>> <mailto:xypron.glpk@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.ganu@linaro.org
> >>>     <mailto:sughosh.ganu@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"),
> 
> Raspberry uses a file in the first partition which must be FAT to store
> U-Boot. The file name of U-Boot is indicated in file config.txt to the
> primary boot loader.
> 
> On all other devices I own U-Boot is installed by command 'dd' writing
> to the SD-Card somewhere after the DOS partition table. (When using a
> GUID partition table often you have to shorten it or relocated it to
> after U-Boot.) Some of the devices could alternativley use eMMC for
> U-Boot (e.g. Odroid C2).

"Firmware" doesn't always mean U-Boot binary.
What I had in my mind is that it can be
  - storage for U-Boot environment variables 
  - firmware for other peripherals, or even
  - kernel(/initfs/dtb)
(Remember that FIT format potentially allows for holding them.)
So I believe that it's totally up to systems.

-Takahiro Akashi

> For reference have a look at
> doc/README.rockchip
> https://a-delacruz.github.io/ubuntu/rpi3-setup-64bit-uboot.html
> 
> Best regards
> 
> Heinrich
> 
> >
> >> * 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
>