Boot order changes won't save

[offsides]

This may be related to the closed #78 but it might be different. I have a bunch of RPi4B 4GB models (all running the latest EEPROM firmware), which I use an SD card to boot the UEFI firmware to load OpenBSD off of USB stick. I initially configured the UEFI firmware on all of the SD cards to remove the 4GB limit using the same USB stick (it wouldn't even boot without one installed), but obviously that's not the one I'm using in all of the systems. Now, with a different USB stick installed, it always tries to PXE/HTTP boot before booting off of the USB stick. No matter how many times I go into the UEFI firmware and change the order, delete the listed boot options, whatever, the next time it boots I have to wait for the PXE and HTTP boot attempts to time out before it will boot from the USB stick (which then works fine). I've noticed that this also happens with a couple other settings where the first time I change them they stick, and then after than any attempts to change them don't - the only solution I've found thus far is to replace the RPI_EFI.fd file on the SD card, which of course resets the UEFI settings back to their original values without any changes. I've now sent a couple of these off to remote offices and would prefer to find a solution that doesn't involve having someone pull the SD cards and replace a file if possible, but I've run out of ideas.

Am I missing something? Or is there a bug that makes firmware changes WORM (Write Once, Read Many)?

[buckaroogeek]

Did you try changing the boot order in the EEPROM (e.g.) to 0xf14? The 4 triggers the USB first, the the 1 for an SD card. Brad

…

On Fri, Mar 5, 2021 at 12:39 PM offsides ***@***.***> wrote: This may be related to the closed #78 <#78> but it might be different. I have a bunch of RPi4B 4GB models (all running the latest EEPROM firmware), which I use an SD card to boot the UEFI firmware to load OpenBSD off of USB stick. I initially configured the UEFI firmware on all of the SD cards to remove the 4GB limit using the same USB stick (it wouldn't even boot without one installed), but obviously that's not the one I'm using in all of the systems. Now, with a different USB stick installed, it always tries to PXE/HTTP boot before booting off of the USB stick. No matter how many times I go into the UEFI firmware and change the order, delete the listed boot options, whatever, the next time it boots I have to wait for the PXE and HTTP boot attempts to time out before it will boot from the USB stick (which then works fine). I've noticed that this also happens with a couple other settings where the first time I change them they stick, and then after than any attempts to change them don't - the only solution I've found thus far is to replace the RPI_EFI.fd file on the SD card, which of course resets the UEFI settings back to their original values without any changes. I've now sent a couple of these off to remote offices and would prefer to find a solution that doesn't involve having someone pull the SD cards and replace a file if possible, but I've run out of ideas. Am I missing something? Or is there a bug that makes firmware changes WORM (Write Once, Read Many)? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#136>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKDYHSIPOXZDGBY4WTTFXTTCE6Q7ANCNFSM4YV3MSWQ> .

[offsides]

I haven't touched the EEPROM, but other than updating in in Raspbian before starting to work with OpenBSD, I don't have access to it. It works fine ultimately booting from the USB (and apparently once OpenBSD is installed using the SD card to load the UEFI firmware, I can install it on the USB stick's EFI boot partition and then remove the SD card and it'll still work), the only issue is that when swapping USB sticks after setting up the UEFI firmware in the first place it changes the boot order so that the new USB stick is after the PXE/HTTP boot (whereas the original one was before them), and it doesn't save any changes I make to the order. If I overwrite the RPI_EFI.fd file on the SD card, that resets everything and it goes straight to the USB stick without the PXE/HTTP boot.

Since I now can boot the UEFI firmware straight off of the USB sticks once I have OpenBSD installed, I'm just going to install the latest firmware there, remove the SD card, and adjust the UEFI configuration the first time I reboot after that. As long as I can boot into OpenBSD, I'll be able to redo that as needed in the even that I get stuck again, and have the SD card as a fallback Just In Case. That said, it's still just a workaround, but one that should be sufficient for my needs.

[samerhaj]

Some of this behavior may be linked to what is reported in #144

There is a patch sent to EDK2 (not merged yet). Please give it a try to confirm if it fixes the issue

[sunnywang-arm]

@samerhaj
I can still reproduce this issue with the fix for #144, so we or someone else will need to take a further look.

I did some experiments:

1. Change boot order -> F10 (save the setting) -> shutdown the system -> power on the system -> Failure
2. Change boot order -> F10 (save the setting) -> go back to the front page (first menu) and press the reset/continue or boot shell from boot manager -> It works!

Therefore, it looks to me like the changed boot order setting hasn't been written into the variable store (BootOrder variable) with some path (if the user doesn't exit the UiApp or boot another boot option after changing the boot order ).

[samerhaj]

This is unfortunately "working as designed". The RPi4 does not have a NV variable storage in flash/ HW. Instead, the variables are written to the RPI_efI.fd file on the media (SD or USB, depending on the boot configuration). In order to ensure the variables are actually written to the media, a file flush is necessary. This flush happens in a callback on certain actions. One of them, is choosing the reset or continue option in the uefi setup.

Pressing ctdl+alt*del or power button may result in partial or missing writes of the variables to the file.

[wizeman]

This flush happens in a callback on certain actions. One of them, is choosing the reset or continue option in the uefi setup.

Perhaps the flush should be called when F10 (Save settings) is pressed or when the firmware asks (and the user accepts) to save the settings?

This would be more intuitive because then the "saving the settings" option would actually save the settings to media (i.e. persistently), which is what the option usually means.

[samerhaj]

This flush happens in a callback on certain actions. One of them, is choosing the reset or continue option in the uefi setup.

Perhaps the flush should be called when F10 (Save settings) is pressed or when the firmware asks (and the user accepts) to save the settings?

This would be more intuitive because then the "saving the settings" option would actually save the settings to media (i.e. persistently), which is what the option usually means.

Yes I think this makes sense.. @sunnywang-arm is this something you can help take a look at?