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. > > > > > > > > [0] https://lpc.events/event/17/contributions/1653/ > > > > > > 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-does-it-improve-upon-lpc/ > > Thanks, that would be helpful. > I am particularly keen on the usb patch here > https://patchwork.ozlabs.org/project/uboot/patch/20231110141311.512334-...@shantur.com/ I'll take a look. Peter