Hi,

I am network booting the raspberry pi firmware. Unfortunately as its loaded from TFTP it does not retain settings nor do I believe I can give it settings.
I am already compiling my own version of RPi4 uefi with edk-platforms/../Rpi4/.dsc edited for some better defaults like setting higher memory.
However, I can't find an option to force a particular boot option as a default. Right now it tries to boot an .efi locally but that efi is not able to be found because we are booting from TFTP.
Instead I would like it to boot to PXE again where I can boot iPXE and control the boot process further. The end goal here is that I can boot UEFI -> iPXE without an SD card.

Could you help me find out what option/variable I can set in the platform dsc? I think the option should be in MdePkg.dec but I can't find any "DefaultBootOption" or override variable.

Kind regards,

Werner Buck

adding Pete and Ard

On Tue, 2 Feb 2021 at 17:41, Laszlo Ersek <lersek@...> wrote:

adding Pete and Ard

On 01/29/21 23:45, wernerbuck@... wrote:

Hi,

I am network booting the raspberry pi firmware. Unfortunately as its loaded from TFTP it does not retain settings nor do I believe I can give it settings.
I am already compiling my own version of RPi4 uefi with edk-platforms/../Rpi4/.dsc edited for some better defaults like setting higher memory.
However, I can't find an option to force a particular boot option as a default. Right now it tries to boot an .efi locally but that efi is not able to be found because we are booting from TFTP.
Instead I would like it to boot to PXE again where I can boot iPXE and control the boot process further. The end goal here is that I can boot UEFI -> iPXE without an SD card.

Could you help me find out what option/variable I can set in the platform dsc? I think the option should be in MdePkg.dec but I can't find any "DefaultBootOption" or override variable.

I think you might be able to trick the BDS into loading iPXE as the
shell if you set the correct file GUID for it in the right PCD.

On 02/02/2021 17:06, Ard Biesheuvel wrote:

On Tue, 2 Feb 2021 at 17:41, Laszlo Ersek <lersek@...> wrote:

On 01/29/21 23:45, wernerbuck@... wrote:

I am network booting the raspberry pi firmware. Unfortunately as its loaded from TFTP it does not retain settings nor do I believe I can give it settings.
I am already compiling my own version of RPi4 uefi with edk-platforms/../Rpi4/.dsc edited for some better defaults like setting higher memory.
However, I can't find an option to force a particular boot option as a default. Right now it tries to boot an .efi locally but that efi is not able to be found because we are booting from TFTP.
Instead I would like it to boot to PXE again where I can boot iPXE and control the boot process further. The end goal here is that I can boot UEFI -> iPXE without an SD card.

Could you help me find out what option/variable I can set in the platform dsc? I think the option should be in MdePkg.dec but I can't find any "DefaultBootOption" or override variable.

I think you might be able to trick the BDS into loading iPXE as the
shell if you set the correct file GUID for it in the right PCD.

I'm interested to know the outcome of this experiment.

Also: the motivation behind creating https://github.com/ipxe/pipxe was because the Pi's VC4 PXE boot code turned out to be incredibly unreliable (with a ~10% boot failure rate) - this is why I personally gave up on getting the Pi to network boot without an SD card as a bootstrap.

Michael

On 02/04/21 01:22, Michael Brown wrote:

On 02/02/2021 17:06, Ard Biesheuvel wrote:

On Tue, 2 Feb 2021 at 17:41, Laszlo Ersek <lersek@...> wrote:

On 01/29/21 23:45, wernerbuck@... wrote:

I am network booting the raspberry pi firmware. Unfortunately as its
loaded from TFTP it does not retain settings nor do I believe I can
give it settings.
I am already compiling my own version of RPi4 uefi with
edk-platforms/../Rpi4/.dsc edited for some better defaults like
setting higher memory.
However, I can't find an option to force a particular boot option as
a default. Right now it tries to boot an .efi locally but that efi
is not able to be found because we are booting from TFTP.
Instead I would like it to boot to PXE again where I can boot iPXE
and control the boot process further. The end goal here is that I
can boot UEFI -> iPXE without an SD card.

Could you help me find out what option/variable I can set in the
platform dsc? I think the option should be in MdePkg.dec but I can't
find any "DefaultBootOption" or override variable.

I think you might be able to trick the BDS into loading iPXE as the
shell if you set the correct file GUID for it in the right PCD.

I'm interested to know the outcome of this experiment.

Also: the motivation behind creating https://github.com/ipxe/pipxe was
because the Pi's VC4 PXE boot code turned out to be incredibly
unreliable (with a ~10% boot failure rate) - this is why I personally
gave up on getting the Pi to network boot without an SD card as a
bootstrap.

Thanks for commenting.

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.

Laszlo

On Thu, 4 Feb 2021 at 09:56, Laszlo Ersek <lersek@...> wrote:

On 02/04/21 01:22, Michael Brown wrote:

On 02/02/2021 17:06, Ard Biesheuvel wrote:

On Tue, 2 Feb 2021 at 17:41, Laszlo Ersek <lersek@...> wrote:

On 01/29/21 23:45, wernerbuck@... wrote:

I am network booting the raspberry pi firmware. Unfortunately as its
loaded from TFTP it does not retain settings nor do I believe I can
give it settings.
I am already compiling my own version of RPi4 uefi with
edk-platforms/../Rpi4/.dsc edited for some better defaults like
setting higher memory.
However, I can't find an option to force a particular boot option as
a default. Right now it tries to boot an .efi locally but that efi
is not able to be found because we are booting from TFTP.
Instead I would like it to boot to PXE again where I can boot iPXE
and control the boot process further. The end goal here is that I
can boot UEFI -> iPXE without an SD card.

Could you help me find out what option/variable I can set in the
platform dsc? I think the option should be in MdePkg.dec but I can't
find any "DefaultBootOption" or override variable.

I think you might be able to trick the BDS into loading iPXE as the
shell if you set the correct file GUID for it in the right PCD.

I'm interested to know the outcome of this experiment.

Also: the motivation behind creating https://github.com/ipxe/pipxe was
because the Pi's VC4 PXE boot code turned out to be incredibly
unreliable (with a ~10% boot failure rate) - this is why I personally
gave up on getting the Pi to network boot without an SD card as a
bootstrap.

Thanks for commenting.

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 understanding is that the UEFI image itself is PXE booted.

But indeed, more clarity is always good

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

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

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

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

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@... <mailto:lersek@...>>:
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
>

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

That was indeed the problem. I changed the RPI4 platform code to always
connect to devices and regenerate boot-options on every boot, and not only
when boot options have failed:
https://github.com/tianocore/edk2-platforms/commit/f88bff4d000c69b1135969dbeafccaeb782dcdf3

@Samer, could this option be the default? Or can this be a compile flag? I
imagine the reasons for the current workflow were to speed up booting and
not process four networkboot options until finally hitting the SD card.

In any case, the goal is complete, there is full headless automated
provisiong of RPI with UEFI firmware.
Thank you all for your assistance.

Kind regards,

Werner Buck

Op za 6 feb. 2021 om 23:59 schreef Pete Batard <pete@...>:

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@...
<mailto:lersek@...>>:

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
>