Adding EFI runtime support to the Arm's FF-A bus

[Ilias Apalodimas]

[...]

> > > > > > I know. Last time I checked CentOS (or was it Ubuntu?) tried to
> > > > > > set EFI variables and the installer just failed. Might be fixed now,
> > > > > > though.
> > > > >
> > > > > It's not. The error message is less scary in distros nowadays, but
> > > > > setting the variable for Boot0000 is still not working. That being
> > > > > said I have a plan to fix it for variables stored in a file, that's
> > > > > why we standardized the efi variable format in EBBR.
> > >
> > > Does this mean supporting SetVariableRT for files ?
> > > If yes, would it work without the driver model in runtime?
> >
> > Yes.
> >
> > The reasoning here is pretty simple. You can't keep alive drivers etc
> > for devices that the *kernel* eventually owns. The proposal is to
> > ignore the EFI spec and teach the kernel to write those directly. We
> > already do that when the variables are stored in an RPMB, we need to
> > figure out a decent scalable architecture for the rest.
> >
> Thanks for explaining this.
> It would be a good idea to provide EFI var storage info like location,
> offset, maxsize to linux
> and linux can modify vars as required.
>
> Eg.
>
> location=espfile://u-boot-efi.vars offset=0 maxsize=-1
> or
> location=spi://0 offset=0x3D0000 maxsize=0xFFFF
>

Yes, you need the flash, offset and size, but I as trying to figure out if
we hand over those as an EFI config table. I haven't managed to do any
coding though yet.

/Ilias
> Then the linux kernel is able to modify vars correctly.
> I think SPI might be simpler to implement vs file as there can be.
> many different
> ESP partitions on multiple drives or no ESP partition at all.
>
> Kind regards,
> Shantur
>
> > /Ilias
> > >
> > > Kind regards,
> > > Shantur