Hi Shantur,
I am trying to work out how to enable the SetVariableRT service in U-Boot and came across your patch [1] which initially had the SetVariable RT service enabled in EFI but in the final patch this was removed. I am hoping to implement it on top of the SPI Flash EFI store [2] to be able to set Boot order and boot items from Linux the UEFI way.
Can I pick your brain on why it was dropped in the patch? Is there any limitation in SetVariableRT service ?
I recently had a talk about it in Plumbers [0]. Generally speaking, RT
- hardware owned by the kernel is a very weird combination since you
can't guarantee exclusive access to the flash or the bus and you have to preserve a *lot* of code alive in u-boot.
I'll respond to your v1 patchset and we can discuss details there as well.
Thanks for the background and helping me understand the problem. Makes me wonder how things work in the PC world. U-boot being only ~1MB, can we not leave it all in memory and maybe just disable SPI access to Linux.
That's basically it, on x86 there's specific HW that's owned by firmware, I don't know the exact low level details of how that works.
I think x86 devices generally use eSPI for this HW [1] but I don't know the low level details. The Arm SBSA (Server HW spec) and SBBR (Server Base Boot Requirements) specs that are key to ServerReady may go into some details too if you're curious.
Thanks, I think the firmware is still accessible to PCs as one could update the firmware in Windows so Windows has access to that device.
I believe in most cases what happens is the OS sets up the update ready so the firmware itself can apply it on a reboot. This is how UEFI Capsule update works.
If you run "fwupdmgr security" on a Linux system you can see some security features like "SPI lock" and "SPI write". I have at least one x86 hobbyist system where you can enable/disable the SPI access/lock but even with that the firmware update is done from the UEFI shell.
I had some try myself and found that setting a variable to memory backed storage is doable with SetVariable call but we want to store it in any non-volatile storage things really don't look good.
To be able to write SetVariable to any device, the whole u-boot driver model would need to be kept in memory, might as well just keep the whole u-boot in memory at this point, it's anyway small. I don't have much knowledge on how to or pros and cons of doing this.
I believe when set variable is running there is a small subset of U-Boot in memory but Ilias will definitely know the details there.
BTW I plan to test your other patches on the Pinebook Pro.
[1] https://www.totalphase.com/blog/2021/09/what-is-the-espi-protocol-and-how-do...
Thanks, that would be helpful. I am particularly keen on the usb patch here https://patchwork.ozlabs.org/project/uboot/patch/20231110141311.512334-1-i@s...
I'll take a look.
Peter