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