Re: Storing Non volatile variables on SD/NAND

[Udit Kumar <udit.kumar@nxp.com>]

> On 18 September 2017 at 22:28, Udit Kumar <udit.kumar@nxp.com> wrote:
> > Thanks Vladimir,
> > With your design, you did delayed write to eMMC due to sharing with
> > OS.  But it works for you:) Say if eMMC controllers offers you a
> > status bit, if eMMC storage is being used for not. Then this could be possible to
> update at run time, both OS/UEFI needs to check and wait if controller is being
> used.
> 
> That is the problem right there. The nice thing about a firmware spec is that you
> don't have to care about how it was implemented if you adhere to the API rules.

Yup, we are fine as long as long UEFI firmware is stored on dedicated media. 

> Imposing additional restrictions (such as requiring the OS to be careful about not
> using the eMMC when it may be in use by the firmware) defeats the purpose of
> using UEFI, since you won't be able to use a generic OS anyway.
> 

Hmm,  so far, I haven't come across where UEFI specs says, we need a separate
Storage for firmware. (May be I missed some part of specs)
Irrespective of storage media, we have this problem if OS and UEFI shares same  
storage. 

> > For sure,  some synchronization issues need to be ironed out (or maybe I am
> just dreaming here).
> >
> > On part 2) where you forked VariableRuntime driver , could we think of
> > updating VariableRuntime driver, to support non-XIP or memory mapped
> devices.
> >
> 
> I think being able to support non-memorymapped FV volumes for the variable
> store would be a big improvement. This does require changes to both the
> FaultTolerantWrite drivers and the VariableRuntime drivers, which both appear
> in PEI, DXE and SMM flavors, and require thorough review due to the security
> impact bugs have in this layer, so this is a rather large chunk of work to take on.

Thanks,  your list is longer than what I was thinking :-)
I think, for embedded world with UEFI, later or sooner, this will be required.

Thanks
Udit