Change default boot order when no SD card is used

[OGKevin]

When you use a SD card, you can change the boot order and have it saved to RPI_EFI.fd. However when you are not using an SD card there is no way to "presist" this change.

Theoretically Actually, you can plug in a SD card, make the change, and then copy the RPI_EFI.fd back to your tfpt server. However, this means that the RPI_EFI.fd will only work for that host and is no longer universal as things like MAC Address are different which makes the PXE boot fail on a diff host if you happened to have put this as first in the order.

So my question then is, as the "build in" default is SD card, is there a way to make the build-in default something else, like PXE/HTTP boot? Or instead of rebooting if there is nothing to boot on the SD card to move to the next item in the order? Which in this case is PXE.

This might be slightly related to #136 I'm not sure. As my goal is to essentially:

1. EEPROM PXE boot RPi4
2. Use PRi4 to PXE iPXE
3. Use iPXE to boot my OS

Step 2 is where I get stuck/need human intervention unless I go the tedious route of saving unique RPI_EFI.fd for each host.

[jlinton]

I believe the default boot order list will eventually start trying PXE/HTTPS on the ethernet port out of the box. That said, I don't know what happens if your netbooting the UEFI firmware; besides, as you note, you can't save anything that relies on UEFI variables (which is the boot order/etc).

So what does uefi do, when you load it via PXE? Is it finding another efi system partition on an attached disk and booting that, rather than eventually falling back to netboot?

[OGKevin]

Is it finding another efi system partition on an attached disk and booting that, rather than eventually falling back to netboot?

Exactly! If I don't manually intervene, it looks for something on the disk, if it doesn't find anything it just reboots 😔 instead of falling back to PXE. Unless I use the unique file per host with the changed boot order.

[OGKevin]

actually, #59 is the same issue eventually. But the fact that the boot order is also not executed and the program exits when failing to boot from USB is also an issue imo.

[buckaroogeek]

Isn't boot order on an RPI4 also controlled by an eeprom setting: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711_bootloader_config.md ? I keep a microSD with raspian installed just for this purpose and use it to do a "once and done" configuration of boot order on the eeprom.

[OGKevin]

Isn't boot order on an RPI4 also controlled by an eeprom setting:

yes, but this has nothing to do with RPi4.

1. EEPROM PXE boot RPi4
2. Use PRi4 to PXE iPXE
3. Use iPXE to boot my OS

Changing the boot order of EEPROM only affects step 1. Everything that happens after that is out of EEPROM. So, EEPROM does network boot and pulls RPi4/eufi. Now the eufi takes over the booting process and EEPROM's job is done.

So now I need to be bale to change the boot order of EUFI without pressing esc. The current way I've solved this is by doing

Actually, you can plug in a SD card, make the change, and then copy the RPI_EFI.fd back to your tfpt server. However, this means that the RPI_EFI.fd will only work for that host and is no longer universal as things like MAC Address are different which makes the PXE boot fail on a diff host if you happened to have put this as first in the order.

Which is the same as what is described in #59. If #59 is solved, this issue is also solved OR with a fresh RPI_EFI.fd, the behavior needs to be changed to try and boot via PXE after USB boot fails instead of exiting. However, I have a feeling that the same issue that is in #59 might be the cause of it exiting.

Essentially this is a 2 bootloader boot process. EEPROM --> EUFI --> iPXE.

[samerhaj]

Note that all of these (essentially duplicate) issues will disappear if we implement #6 (UEFI NV variables in flash), since the UEFI variables will be stored in the flash onboard, and not in the RPI_EFI file anymore. This means the firmware in RPI_EFI (still loaded from the TFTP server) will auto-discover the boot options on the board (including the board specific MAC) and save them to the board flash.

[duyleekun]

@samerhaj imo, #59 may not disappear when #9 is fixed. The point of that issue is to support headless provisioning of rpi. May not be a common case but changing the boot order of a dozen pis could feel a bit tedious.

[dimpase]

Could you point me out to docs on changing the default boot order? I read here that it's possible, but how? It's a binary file I have to rebuild somehow, right?

[jlinton]

@dimpase: You use an SD card to boot, write an updated RPI_EFI.fd (where the variables are stored when using SD/etc) then copy the resulting updated RPI_EFI.fd to your target boot media. Then remove the SD card and boot as you normally do.

It should be as simple as pressing 'esc' when the machine is showing the rpi status/waiting for input (before grub and the windows bootloader/etc) to get into the UEFI config menus (or using the UEFI firmware menu in grub when using fedora/etc).

The main uefi menu has "Select Language", "Device Manager"... and "Boot Maintenance Manager" Select the "Boot Maintenance Manager"->"Boot Options" -> "Change Boot Order" -> press enter

Then you will see a popup with all the boot options, use the arrow and +/- kyes to move them around. Press enter when done, then F10, and esc a bunch until you get back to the main menu. Then select continue, or reset or boot one of the options. Anything that continues operation should save the settings to the SD card (which is the only reliable way at the moment, it might work on USB).

The downstream SPI var storepatches, which might eventually get merged allows one to save those settings while running in ACPI mode with efibootmgr in linux same as normal PCs.

edit: cause I forgot to put this here.

If your booting from something other than SD, you can then take the file written to SD, and put it on whatever your normal boot mechanism is after you have written it with an SD card.

So, put an SD card in the pi, copy the firmware to it, boot it , modify the settings, save them, then copy the RPI_EFI.fd file from the SD to your target media. Then you can remove the SD card.

[dimpase]

🤦🏽‍♂️ - it's not obvious for someone not working with hardware regularly that "building" is actually done by hardware, akin to configuring BIOS... Thanks. I'll try putting modified RPI_EFI.fd right on the USB drive I boot OS from (I read somewhere advice to keep the SD card in - so it's not only me who got confused 😄 )

I'd like to mention that to boot headless I also had to add hdmi_force_hotplug=1 to config.txt, cf. #162 (I gather config.txt does not have to come into play when RPI_EFI.fd is used.)

What's still baffling - where have you got the initial RPI_EFI.fd to work with? Copied it from an RPi somehow?

[jlinton]

You are not "building" anything. UEFI is designed around having an exclusive persistent place to store settings, and the rpi out of the box doesn't support such a concept, so there are various workarounds. The one the firmware ships with just stores them back into the firmware image itself stored on SD or USB, except it seems like its only reliable on SD because people have various USB disks/etc that have issues with flushing/whatever is wrong with them.

If you have a SD card in the machine, and USB as well, then just put the firmware on the SD card, and ignore all the other stuff I wrote about copying the image around. The original instructions for just modifying the settings in the menu, and rebooting should be enough.

In theory, if the only thing plugged in is a USB, and the ESP is written properly, you shouldn't have to reset the default boot order as it will be detected/generated on each boot too.

If you really want to look at the code/etc there are various tutorials sitting around about how to build TFA+EDK2, but it is still on top of the rpi foundation's firmware as well, which isn't open source, and that firmware reads/responds to the config.txt changes you have been making. AKA its a big layer cake.

[dimpase]

I called the process of modifying RPI_EFI.fd "building", that's probably incorrect word use, sorry.

then just put the firmware on the SD card, and ignore all the other stuff I wrote about copying the image around

Are you saying that just copying modified RPI_EFI.fd over won't cut it? Or it's just to simplify the process (at expense of an extra SD card sitting there doing almost nothing).

In theory, if the only thing plugged in is a USB...

in practice, there is also ethernet plugged in, and so the default boot order wastes a lot of time (3-4 minutes?), before reaching the USB drive.

---

Ideally, one would like to use your package to build a sane OpenBSD (in my case, but surely other OSs too) installer for RPi4. At the moment, for a non-network boot, a typical OS installer is put on a separate USB stick or something (something one copies over using good old dd command). OS to be installed is to go to another USB disk.

With keyboard plugged in, it leaves one the choice of putting the extra installer stuff on yet another USB stick, as there is one more USB slot, or use ethernet to fetch them (wireless is a problem, thanks to Broadcom :smile:). I used ethernet.

[jlinton]

I guess it depends on what you mean by "sane". You can both build disk images with this firmware or just put it on SD and pretend it's a normal PC, and boot from USB/network/etc as you suggest and install to USB/NVMe/SD.

The use of the SD card as a dedicated firmware store IMHO is the best plan for a general-purpose OS which will tend to eat the SD cards rolling logs and swapping. But it is not needed because you can build more disk images and put the firmware and the root/etc all on either an SD, USB (or for the CM4 nvme) and copy the whole thing with dd/etc (that's how the windows images work).

The point with the SD to USB copy is under the assumption you want to save the settings the RPI_EFI.fd image on SD and then boot only with a USB plugged in. Although, frankly, if your going to distribute it, its likely that someone will want to change the settings/etc.

But really, I guess the question remains why your machine is trying to PXE/etc boot rather than finding the USB disk and booting from it. PXE is usually the last boot option when the firmware doesn't find another bootable ESP with a fallbackaa64.efi. Which I'm guessing is the problem. The disk images your trying to boot from don't have one because they are normal installs without a fallback and they depend on the UEFI nextboot/etc variables to directly boot the target media. So copy the efi application your trying to use to BOOT/fallbackaa64.efi (or better BOOT/bootaa64.efi) and see if the firmware finds it and boots it before trying PXE/HTTPS.