Re: [PATCH 3/3] efi_loader: setting boot device

From: Heinrich Schuchardt <xypron.glpk@gmx.de>
To: Kyle Evans <kevans@freebsd.org>
Cc: Alexander Graf <agraf@csgraf.de>,
	Joe Hershberger <joe.hershberger@ni.com>,
	Simon Glass <sjg@chromium.org>,
	Joao Marcos Costa <joaomarcos.costa@bootlin.com>,
	Richard Genoud <richard.genoud@posteo.net>,
	Niel Fourie <lusus@denx.de>,
	u-boot@lists.denx.de
Subject: Re: [PATCH 3/3] efi_loader: setting boot device
Date: Mon, 04 Apr 2022 07:58:10 +0200	[thread overview]
Message-ID: <9491CEF0-F9F2-4DED-833D-3DE3F2670B53@gmx.de> (raw)
In-Reply-To: <CACNAnaGKLUyYXWJFtaOEatEbYbrhJ6iFRD5jQOtrwByBWDgs+A@mail.gmail.com>

Am 4. April 2022 07:40:16 MESZ schrieb Kyle Evans <kevans@freebsd.org>:
>On Mon, Apr 4, 2022 at 12:09 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>
>> Am 3. April 2022 23:08:33 MESZ schrieb Kyle Evans <kevans@freebsd.org>:
>> > On Tue, Jan 12, 2021 at 1:59 PM Heinrich Schuchardt <xypron.glpk@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.