[PATCH 3/3] efi_loader: setting boot device

[Kyle Evans]

On Mon, Apr 4, 2022 at 12:59 AM Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
> 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.
>

Indeed, thanks! It's a bit less convenient than being able to script
this from the beginning, but it's a lot better than having to
distribute a patched u-boot to folks working on this with me.

> >
> >> >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.
>

Will do- I considered dropping the size or adding a subcommand that
does this instead and reading the size from the header, but I think
it's grown on me as a cheap/easy way to extend the base bootefi
without adding the footgun of a previously invalid command suddenly
doing the wrong thing. If you just plopped it into memory, knowing the
size should be an easy task