[U-Boot] [PATCH 0/2] Add support for booting EFI FIT images
Heinrich Schuchardt
xypron.debian at gmx.de
Thu Nov 28 07:20:03 UTC 2019
On 11/27/19 8:45 PM, Cristian Ciocaltea wrote:
> On Tue, Nov 26, 2019 at 07:31:39PM +0100, Heinrich Schuchardt wrote:
>> On 11/24/19 9:11 PM, Cristian Ciocaltea wrote:
>>> Currently the only way to run an EFI binary like GRUB2 is via the
>>> 'bootefi' command, which cannot be used in a verified boot scenario.
>>>
>>> The obvious solution to this limitation is to add support for
>>> booting FIT images containing those EFI binaries.
>>>
>>> The implementation relies on a new image type - IH_OS_EFI - which
>>> can be created by using 'os = "efi"' inside an ITS file:
>>>
>>> / {
>>> #address-cells = <1>;
>>>
>>> images {
>>> efi-grub {
>>> description = "GRUB EFI";
>>> data = /incbin/("EFI/BOOT/bootarm.efi");
>>> type = "kernel_noload";
>>> arch = "arm";
>>> os = "efi";
>>> compression = "none";
>>> load = <0x0>;
>>> entry = <0x0>;
>>> hash-1 {
>>> algo = "sha256";
>>> };
>>> };
>>> };
>>>
>>> configurations {
>>> default = "config-grub";
>>> config-grub {
>>> kernel = "efi-grub";
>>> signature-1 {
>>> algo = "sha256,rsa2048";
>>> sign-images = "kernel";
>>> };
>>> };
>>> };
>>> };
>>>
>>> The bootm command has been extended to handle the IH_OS_EFI images.
>>> To enable this feature, a new configuration option has been added:
>>> BOOTM_EFI
>>>
>>> I tested the solution using the 'qemu_arm' board:
>>>
>>> => load scsi 0:1 ${kernel_addr_r} efi-image.fit
>>> => bootm ${kernel_addr_r}#config-grub
>>
>> Thanks a lot for the patch series which makes good sense to me.
>>
>> I think we should pass addresses and not strings to cmd/bootefi.c. This
>> will need a bit of refactoring as already addressed in a comment to
>> patch 2/2.
>>
>> Additionally the documentation in doc/uefi/u-boot_on_efi.rst and
>> doc/uImage.FIT/howto.txt should be updated.
>>
>> I cc the contributors given by
>> scripts/get_maintainer.pl -f common/bootm_os.c
>>
>> Best regards
>>
>> Heinrich
>>
>
> Thanks for the feedback, Heinrich!
>
> Instead of creating new function(s), I think we could simply extend
> int do_bootefi_image(const char *image_opt)
> with a new parameter to hold the fdt address and move here the call
> to 'efi_install_fdt()', which is now performed by 'do_bootefi()'.
efi_install_fdt() has to be called for the 'bootefi bootmgr' command too
so the refactoring is a bit more complicated. I have started on that.
The first step is to change efi_install_fdt() to expect the argument as
address instead of a string.
https://github.com/xypron/u-boot-patches/blob/efi-next/0001-efi_loader-pass-address-to-efi_install_fdt.patch
fdt_addr==NULL indicates no device tree supplied by user.
Best regards
Heinrich
>
> However, I'm not sure about changing the data types, i.e. from
> 'char *' to ulong, for the following reasons:
> 1. image_opt may have a different meaning in addition to efi address
> 2. fdt address may not be provided, so we need somehow to detect an
> invalid value
>
> Kind regards,
> Cristian
>
>>>
>>>
>>> Cristian Ciocaltea (2):
>>> image: Add IH_OS_EFI for EFI chain-load boot
>>> bootm: Add a bootm command for type IH_OS_EFI
>>>
>>> cmd/Kconfig | 9 ++++++++-
>>> cmd/bootefi.c | 2 +-
>>> common/bootm_os.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
>>> common/image-fit.c | 3 ++-
>>> common/image.c | 1 +
>>> include/bootm.h | 2 ++
>>> include/image.h | 1 +
>>> 7 files changed, 59 insertions(+), 3 deletions(-)
>>>
>>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
More information about the U-Boot
mailing list