Re: Compile EDK2 to set boot order to PXE


Pete Batard
 

On 2021.02.06 16:01, Werner Buck wrote:
It is exactly as Micheal Brown put it. Thank you for all your thoughts into this!

> 1. UEFI firmware defaults to attempting a network boot if no SD card is
present.  This would allow the UEFI firmware to load iPXE via TFTP.
Actually this is what is surprising to me. When RPI4 UEFI is running it tries to boot `efi/boot/bootaa64.efi` as a first option but as the uefi is running from network boot is unable to find it. I would expect the firmware to then choose network boot but the pi actually does a reboot loop.
I believe the way Raspberry Pi defaults to network boot is actually by updating the boot options and issuing a reboot, per: https://github.com/tianocore/edk2-platforms/commit/8dd78ea11a38d2d7e8031c4783e9f2ca5569956b

In other words, we currently rely on hitting PlatformBootManagerUnableToBoot() once, so that we update the boot options, and then reboot the system into an environment that now has network boot as default.

You can validate this by simply extracting a newly built UEFI firmware (such as the one from the official archives) on USB/SD and powering up. You'll see that it takes one reboot, before it starts to look for network files.

But of course, that only works if you can save variables... which you can't do in this scenario. If you are downloading the same "pristine" UEFI firmware over and over, you will indeed hit a boot loop.

CCing Samer, who might have looked at alternatives to enable network boot by default, and could have some ideas of how we may achieve this, in a scenario where we can't save boot variables...

Regards,

/Pete

Mind that this is all without an SD card present currently. Should I raise a bug for this at the RPI4 platform side?
I am actually doing triple network boot here. And have actually had 0 reliability problems with network booting at least on the RPI4 with DHCP ISC server with the below config and having dnsmasq serve an tftp server.
Just for transparency this is what im running in an isc dhcp server:
```
# network boot coming in
if substring (option vendor-class-identifier,0,9) = "PXEClient" {
        option tftp-server-name "10.10.10.1";
        # raspberry pi defaults to loading bootcode.bin from tftp and i have the rpi4 uefi firmware just extracted on the tftproot.
        # when booted using uefi and starting network boot again architecture is 00:0b (uefi arm64) and we download iPXE
        if option arch = 00:0b {
           log(info, "This is UEFI ARM boot (raspberry pi), booting ipxe..");
           #specially compiled ipxe with 8gb
           filename "ipxe-pi.efi";
        }
}
# Detecting ipxe https flag so we point filename to the boot.ipxe filename.
if exists ipxe.https {
  log (info, "ipxe enabled");
  # matchbox server
  filename "http://10.10.10.1:8085/boot.ipxe <http://10.10.10.1:8085/boot.ipxe>";
}
```
Packing iPXE in some way and tricking UEFI with the PCD file GUID is what im going to try this weekend!
Thanks all I will keep you posted.
Werner Buck
Op do 4 feb. 2021 om 13:54 schreef Laszlo Ersek <lersek@redhat.com <mailto:lersek@redhat.com>>:
On 02/04/21 13:35, Michael Brown wrote:
> On 04/02/2021 08:56, Laszlo Ersek wrote:
>> I've attempted to wrap my brain around the initial report in this
>> thread, and honestly I'm lost. My standard answer would be "BDS
behavior
>> is platform policy, so look into whatever PlatformBootManagerLib
>> instance is used by the RPi firmware" (and I understand that Ard's
>> response is somehow consistent with this). But honestly I can't
figure
>> out whether the problem is related to the part of the RPi
firmware that
>> runs *before* TianoCore. What exactly is PXE-booted before what
else?...
>> I think we'd need a much more detailed issue report here.
>
> My best guess (based on having tried to do something similar
before) is:
>
> - Pi has no local storage.
>
> - Pi uses its builtin network boot (running on the VC4 GPU, not
the CPU)
> to download bootcode.bin, config.txt, and an appropriate
start*.elf via
> TFTP.
>
> - The downloaded config.txt includes "armstub=RPI_EFI.fd".  The
VC4 GPU
> (now executing start*.elf, as far as I am aware) downloads RPI_EFI.fd
> and boots the ARM CPU into this.
>
> - At this point, we have the CPU running the RPi UEFI firmware.
>
> There is no non-volatile storage available
O_o
Thank you for the explanation. Not that I can help Werner in any way,
but now I understand the issue at least.
Thanks,
Laszlo

> and so no way to use EFI
> variables to control the boot order.  The boot device will be
whatever
> is the *compile-time* default for RPI_EFI.fd.
>
> The intention is that the UEFI firmware should then attempt a network
> boot.  This could be done in at least three ways:
>
> 1. UEFI firmware defaults to attempting a network boot if no SD
card is
> present.  This would allow the UEFI firmware to load iPXE via TFTP.
>
> 2. iPXE as a driver (specifically bin-arm64-efi/rpi.efidrv) is
embedded
> within the RPI_EFI.fd image, and UEFI firmware defaults to
attempting a
> network boot if no SD card is present.
>
> 3. iPXE as an application (specifically bin-arm64-efi/rpi.efi) is
> embedded within the RPI_EFI.fd image, and UEFI firmware somehow
defaults
> to running this application (e.g. via the PCD file GUID trick
suggested
> by Ard).
>
> All three of these options would result in the RPi running UEFI
iPXE as
> requested.
>
> Werner: please correct me if I have misunderstood what you are
trying to
> do.
>
> Thanks,
>
> Michael
>

Join discuss@edk2.groups.io to automatically receive all group messages.