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

[Shantur Rathore]

Hi Ilias,

On Thu, Dec 21, 2023 at 6:30 AM Ilias Apalodimas
<ilias.apalodimas at linaro.org> wrote:
>
> Hi Shantur
>
> On Thu, 21 Dec 2023 at 00:57, Shantur Rathore <i at shantur.com> wrote:
> >
> > Hi Illias,
> >
> > On Wed, Dec 20, 2023 at 3:43 PM Peter Robinson <pbrobinson at gmail.com> wrote:
> > >
> > > On Wed, Dec 20, 2023 at 6:37 AM Ilias Apalodimas
> > > <ilias.apalodimas at linaro.org> wrote:
> > > >
> > > > Hi Michael
> > > >
> > > > On Tue, 19 Dec 2023 at 14:47, Michael Walle <mwalle at kernel.org> wrote:
> > > > >
> > > > > Hi Mark,
> > > > >
> > > > > >> > Any runtime device drivers for variable storage should not be in the
> > > > > >> > U-Boot runtime but live in the secure world (e.g. OP-TEE) FF-A is the
> > > > > >> > new ARM protocol for talking to the secure world and hence fits into
> > > > > >> > the picture.
> > > > > >>
> > > > > >> What if I just want a simple embedded boot stack where I don't
> > > > > >> want any secure world and just want to be able to boot a COTS linux
> > > > > >> distribution via EFI?
> > > > > >
> > > > > > That already works for many Linux distros.  As long as the distro
> > > > > > installs the appropriate BOOTxxx.EFI file you don't actually need to
> > > > > > set any EFI variables for the OS to boot.  It can't get any simpler
> > > > > > than that.  Of the main Linux distros it seems that only Debian
> > > > > > doesn't do this.  Someone should probably lobby Debian to do this as
> > > > > > well as it would mean that Debian would just work on an EBBR compliant
> > > > > > system.
> > > > >
> > > > > 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

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