Re: Compile EDK2 to set boot order to PXE


wernerbuck@...
 

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.
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";
}
```

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

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.