[...]
> > > > > > 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
