Re: Compile EDK2 to set boot order to PXE


Werner Buck <wernerbuck@...>
 

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

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.