[PATCH 3/3] efi_loader: setting boot device

[Heinrich Schuchardt]

Am 4. April 2022 07:40:16 MESZ schrieb Kyle Evans <kevans at freebsd.org>:
>On Mon, Apr 4, 2022 at 12:09 AM Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>>
>> Am 3. April 2022 23:08:33 MESZ schrieb Kyle Evans <kevans at freebsd.org>:
>> > On Tue, Jan 12, 2021 at 1:59 PM Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>> >>
>> >> Up to now the bootefi command used the last file loaded to determine the
>> >> boot partition. This has led to errors when the fdt had been loaded from
>> >> another partition after the EFI binary.
>> >>
>> >> Before setting the boot device from a loaded file check if it is a PE-COFF
>> >> image or a FIT image.
>> >>
>> >> For a PE-COFF image remember address and size, boot device and path.
>> >>
>> >> For a FIT image remember boot device and path.
>> >>
>> >> If the PE-COFF image is overwritten by loading another file, forget it.
>> >>
>> >> Do not allow to start an image via bootefi which is not the last loaded
>> >> PE-COFF image.
>> >>
>> >
>> >Hi,
>> >
>> >I'm only a little late on this, but may I ask what the rationale of
>> >this last part is? I'm afraid there are some real-world use cases
>> >where a compromise would be great, allowing bootefi to accept a random
>> >region of memory to boot -- in my case, I have the payload (FreeBSD's
>> >loader.efi) already in memory when U-Boot starts and it's unclear that
>>
>> Could you, please, describe your use case in some more detail.
>>
>> Why can't you load loader.efi from the ESP?
>>
>
>I'm explicitly trying to override the loader.efi from ESP, because
>it's broken and I can't (easily) keep switching it out. This is on
>Apple's M1, so I can happily inject the new loader.efi from m1n1 (much
>like the JTAG use-case mentioned in this file) for testing new
>iterations.

You could use the loady command to load the EFI binary via the UART. This should work with an unpatched U-Boot v2022.04-rc5.

>
>> >I can come up with some other way to boot it that doesn't involve a
>> >lot of backflips.
>> >My specific suggestion, which I can formally post to the list if you
>> >don't immediately object, is this:
>> >https://people.freebsd.org/~kevans/uboot.patch
>> >
>> >It basically adds another form:
>> >
>> >`bootefi addr [fdt [size]]`
>>
>> What should size be used for?
>> Both EFI binaries and device-trees provide their size in a header field.
>>

Please, send your patch for review to the mailing list and me.

Best regards

Heinrich

>
>Right now it's used because efi_run_image() wants the buffer size to
>construct the memory-based device path. I'm not familiar enough with
>U-Boot to know if there's a sensible API for grabbing the size from
>this PE image in memory.