Is the RPi4 UEFI v1.33 known to be broken for saving EDK2 settings in some contexts using a microsd card in the RPi4B's slot?

[markmi]

Is the RPi4 UEFI v1.33 known to be broken for saving EDK2 settings in some contexts? The context involved happens to be an old 8 GiByte B0T stepping Rev 1.4. EDK2 was on a microsd card in the RPi4B's slot and the save attempts were while the firmware was active. (The OS loader and OS were on a USB3 SSD.) I've tried setting Serial vs. Graphical and 3GB limit being Disabled vs. Enabled. I'm able to use the serial console to control booting and use the system (despite the setting not sticking) but I do not even have video connected. FreeBSD always reports: real memory = 3135406080 (2990 MB) avail memory = 3026731008 (2886 MB) and looking in EDK2 at the next boot start after attempting setting the values shows the values did not change (so, for example: still 3GB limited). (Ultimately, FreeBSD may still not handle the 3GB hardware limitation yet and so the 3 GB EDK2 limitation may end up being all that is safe.)

I got access to an old RPi4B 4GiByte model and moved the microsd card and USB SSD to it and tried: same type of result.

[markmi]

FYI: I tried the RPi* firmware related files in RPi4_UEFI_Firmware_v1.33.zip :

# strings start4.elf | grep "VC_BUILD_ID_"
VC_BUILD_ID_USER: dom
VC_BUILD_ID_TIME: 14:21:38
VC_BUILD_ID_VARIANT: start
VC_BUILD_ID_TIME: Mar  1 2022
VC_BUILD_ID_BRANCH: bcm2711_2
VC_BUILD_ID_HOSTNAME: buildbot
VC_BUILD_ID_PLATFORM: raspberrypi_linux
VC_BUILD_ID_VERSION: 969fb9b1521fc7ac2b88b15a3a9e942da7678c4d (clean)

And also the RPi* firmware files associated with the recent release:

# strings start4.elf | grep "VC_BUILD_ID_"
VC_BUILD_ID_USER: dom
VC_BUILD_ID_TIME: 13:19:26
VC_BUILD_ID_VARIANT: start
VC_BUILD_ID_TIME: Mar 24 2022
VC_BUILD_ID_BRANCH: bcm2711_2
VC_BUILD_ID_HOSTNAME: buildbot
VC_BUILD_ID_PLATFORM: raspberrypi_linux
VC_BUILD_ID_VERSION: e5a963efa66a1974127860b42e913d2374139ff5 (clean)

I did not notice any differences in behavior.

[markmi]

For reference (from booting and using raspiOS 64):

# rpi-eeprom-update
BOOTLOADER: up to date
   CURRENT: Tue Jan 25 14:30:41 UTC 2022 (1643121041)
    LATEST: Tue Jan 25 14:30:41 UTC 2022 (1643121041)
   RELEASE: default (/lib/firmware/raspberrypi/bootloader/default)
            Use raspi-config to change the release.

  VL805_FW: Using bootloader EEPROM
     VL805: up to date
   CURRENT: 000138a1
    LATEST: 000138a1

and:

# rpi-eeprom-config
[all]
BOOT_UART=1
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
ENABLE_SELF_UPDATE=1
DISABLE_HDMI=0
BOOT_ORDER=0xf41

[TheMindVirus]

yes. https://github.com/pftf/RPi4/issues/136

[markmi]

yes. #136

In my context, with EDK2 on a microsd card in the RPi4B's slot, I'm unable to have save activity stick with that EDK2 active. The USB SSD is not set up to boot via EDK2, but via FreeBSD's normal structure involving U-Boot. (But after updating the RPi* firmware as a test, that crashes. Thus the switch to a microsd card boot. I happened to try EDK2 [v1.33] on the microsd card, not having used EDK2 is a long time.)

Overall the contexts do not seem to be a match.

[jlinton]

There was a bug I fixed which causes the flash volume header to be overwritten if the FaultTolerantWriteDxe needs to garbage collect the variable store space. Although the usual result is that the system simply fails to boot once its been corrupted, but I guess its possible this is a result too.

You might try my build at https://github.com/jlinton/edk2-platforms/blob/cppc6-various-fixes-vc4aml-mailboxspinlock-xhcipci-clocktweaks-spiv4/RPI_EFI.fd and see if it fixes your issues (or integrate the SPI patches in one you build yourself).

I've been considering having that version flush the last version of the eeprom before all the rpi foundations network recovery trash as well. That will solve the problem with the latest eeproms taking up to much space as well.

[markmi]

The bug is possibly just in my brain: In allowing setting up for the same media to be able to boot both RPi4B's and an RPi3B I used the name RPI4_EFI.fd ( allowing for a RPI3_EFI.fd ), letting the config.txt be responsible to bind to the the right one. It might be nothing more than a file-not-found error that has no explicit notice. (I tend to set up for booting multiple machines of various related types. I'm not a fan of such name duplication for things that can not substitute for each other.) I'll try the pre-supplied naming and see if v1.33 works. . . . Yep: that was it.

[TheMindVirus]

Renaming or Replacing RPI_EFI.fd is only a temporary solution to flush the cache. The errors start reappearing only after several reboots where NV Variables are still pending write on disk and haven't actually been written yet.

If there is a file-not-found error then no settings would save at all and it would revert completely back to defaults. Is that what you're seeing, or does it remember the settings initially but doesn't save them after a few reboots?

[markmi]

Renaming or Replacing RPI_EFI.fd is only a temporary solution to flush the cache. The errors start reappearing only after several reboots where NV Variables are still pending write on disk and haven't actually been written yet.

If there is a file-not-found error then no settings would save at all and it would revert completely back to defaults. Is that what you're seeing, or does it remember the settings initially but doesn't save them after a few reboots?

I did the renaming for other reasons than "flush the cache". There was no RPI_EFI.fd present at all (by name).

And, yes, the only values I ever could see were the default values: no value was ever saved until I finally used RPI_EFI.fd as the file name, once I realized my false implicit assumption. With the RPI_EFI.fd name in use, it worked just fine to save while EDK2's UI was active.