pftf
Writeable UEFI variables using runtime services (during OS lifetime)
Because the PI has no dedicated chip that could be used for NVRAM, the current variables support relies on modifying RPI_EFI.FD in place. This of course only works before UEFI transitions to the OS, because the the SD controller is exposed via ACPI and subsequently owned by the OS.
Several approaches here to evaluate at some point
Approach 1
The easiest would be to add a boot option that would keep the SD controller as entirely owned by firmware (i.e. removed from ACPI and DT). Then, the runtime support for variable services could be modified to work in runtime, but it would be messy (today the support involves the SD controller, MmcDxe, block driver, fs layer and FAT driver).
Approach 2
Support an optional hat/dongle with another device (SD card?) over SPI pins. Since we can't expect this to always exist, the variable services would have to be rewritten to support both the fall back (current approach) or the SPI-attached storage. Also, the backing SPI controller would still need to be hidden from OS at boot.
Oh and of course none of these methods can support secure var storage.
if you wanted to write to the SPI flash while the OS is running, you might have some conflicts with analog audio you need to smooth over
https://github.com/raspberrypi/rpi-eeprom/blob/22ce0605e47447dcdc27c23ca27e1f5ec43e5f5c/rpi-eeprom-update#L189-L208
this code will use the mailbox to ask start4.elf to disable the power regulator for analog audio (to mute gpio 40/41
then switches those pins from being PWM to MOSI/MISO, and fires up flashrom
in theory, tianocore could do the same thing, and if the alt mode is changed, you can likely keep the PWM enabled, it just wont be driving anything...
https://gist.github.com/cleverca22/2a7e68d4a3d7802fcb3fe72c0aaa152a#gistcomment-3080420
and this details the filesystem within the SPI flash, which would allow you to add custom files, though they will get lost when the firmware updates (enless you hide your vars inside the pre-existing bootconf.txt)
Thanks, this is very useful. Truth be told, these variables are written at install time by the OS and pretty much never again. I’m not too worried about audio for the duration of NVRAM access (although it will have to coral all cpus to avoid concurrent mbox access to be really safe)
the rpi4 is sharing gpio40/41 between both MOSI/MISO and the left/right PWM channel
so if you leave the audio power rail on, then MOSI/MISO get ran thru a current boosting amp, then a low-pass filter, and out the headphone jack, ready to blow some ear-drums!
it likely wont affect the SPI protocol any, since the amp isolates things
I understand that. The code would need to mux things. I’m just saying I’m not worried about audio being broken for a few milliseconds if required
Approach two could be an interesting addition. Particularly if it could be used to alter SMBIOS entries for the main board section as well. To help describe capabilities that could be checked from the OS.
I should add that this would be from the perspective of a CM4 board.
patches were submitted for this:
https://edk2.groups.io/g/devel/message/84253
