From mboxrd@z Thu Jan 1 00:00:00 1970 From: Akashi Takahiro Date: Fri, 8 May 2020 08:36:17 +0900 Subject: [PATCH 3/8] qemu: arm64: Add support for efi firmware management protocol routines In-Reply-To: <8e54c2ee-13c3-2679-7041-b2b40550f622@gmx.de> References: <20200430173630.15608-1-sughosh.ganu@linaro.org> <20200430173630.15608-4-sughosh.ganu@linaro.org> <2d2e8312-be4a-50b6-8165-755d4c8dac56@gmx.de> <20200507023324.GI20621@laputa> <8e54c2ee-13c3-2679-7041-b2b40550f622@gmx.de> Message-ID: <20200507233617.GB30323@laputa> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >>> > 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 >>> > > >>> > >>> 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 >