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.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"),
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 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