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