[PATCH 3/8] qemu: arm64: Add support for efi firmware management protocol routines
xypron.glpk at gmx.de
Thu May 7 22:47:47 CEST 2020
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 at gmx.de
>>> <mailto:xypron.glpk at 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 at linaro.org
>>> <mailto:sughosh.ganu at 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.
>> 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).
For reference have a look at
>> * a media device path, a start address, and a truncation flag
>> for each of the binaries
> my FIT-based patch 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.)
>  https://lists.denx.de/pipermail/u-boot/2020-April/408767.html
>> The protocol implementation then will write the binaries to the device
>> * 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
More information about the U-Boot