+ Simon as he seems to have done a lot of work in the driver model.
On Mon, Nov 27, 2023 at 10:12 AM Shantur Rathore <i...@shantur.com> wrote: > > Hi Ilias, > > On Mon, Nov 27, 2023 at 7:16 AM Ilias Apalodimas > <ilias.apalodi...@linaro.org> wrote: > > > > Hi Shantur > > > > On Sun, 26 Nov 2023 at 12:33, Shantur Rathore <i...@shantur.com> wrote: > > > > > > Hi Peter, > > > > > > On Sat, Nov 25, 2023 at 6:19 AM Peter Robinson <pbrobin...@gmail.com> > > > wrote: > > > > > > > > Hi Shantur, > > > > > > > > On Fri, Nov 24, 2023 at 11:55 PM Shantur Rathore <i...@shantur.com> > > > > wrote: > > > > > > > > > > Hi Ilias, > > > > > > > > > > On Fri, Nov 24, 2023 at 10:50 PM Ilias Apalodimas > > > > > <ilias.apalodi...@linaro.org> wrote: > > > > > > > > > > > > Hi Shantur > > > > > > > > > > > > On Fri, 24 Nov 2023 at 18:51, Shantur Rathore <i...@shantur.com> > > > > > > wrote: > > > > > > > > > > > > > > Hi Heinrich, > > > > > > > > > > > > > > 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 would work, but you cant guarantee Linux wont enable the SPI flash. > > > > > > > > > > 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. > > > > On X86 the SPI flash is handled entirely by the firmware and SMM. You > > can find more details here [0] > > Thanks for more info. > > > > > > > > > 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 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. > > > > The major problem here is who owns the hardware. With the SPI flash > > implementation as well as the RPMB implementation Linux owns that > > flash. > > For the RPMB we've introduced a mechanism so the kernel replaces the > > runtime calls with internal functions [1]. I think we should come up > > with a similar architecture for SPI. In any case we should keep in > > mind that setting authenticated EFI variables should be forbidden on > > the file/SPI backends since they are not really secure. > > > > Thanks, I understand now that we can't use SPI flash for saving secure > variables and stop Linux from accessing it. > My requirement is to be able to save non-Secure boot related variables > ( BootOrder, BootNext and BootOptions ). > For this purpose as we don't need secure channel and to be compatible > with current Linux versions I started > implementing SetVariable in runtime in [1] > I was able to get it working until it's ready to write stuff into SPI Flash. > To be able to use SPI Flash, runtime call needs to access the drivers > and this needs the whole driver-model to be in > efi runtime memory makes me think would it make sense to keep the > whole u-boot in efi runtime memory or just > driver model and all SPI drivers for now and keep adding other drivers > when needed like RPMB. > > I need some pointers to what would be the best approach accessing > hardware from runtime. > > [1] - https://github.com/shantur/u-boot/tree/spi-flash-runtime-setvariable > > Kind regards, > Shantur