Re: Storing Non volatile variables on SD/NAND

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

Thanks Ard. 

> The UEFI spec allows you to expose entry points into a DXE_RUNTIME_DRIVER
> module via a UEFI configuration table, and the OS can use a driver that uses the
> abstracted device rather than the real device. Performance is going to be

Could you point me to some sample driver using this scheme, 
Mainly around OS implementation 

Regards 
Udit

> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> Sent: Wednesday, September 20, 2017 11:09 PM
> To: Udit Kumar <udit.kumar@nxp.com>
> Cc: Pankaj Bansal <pankaj.bansal@nxp.com>; Andrew Fish <afish@apple.com>;
> Olivier.Martin@arm.com; Vladimir Olovyannikov
> <vladimir.olovyannikov@broadcom.com>; edk2-devel@lists.01.org
> Subject: Re: [edk2] Storing Non volatile variables on SD/NAND
> 
> On 20 September 2017 at 10:34, Udit Kumar <udit.kumar@nxp.com> wrote:
> >
> > When we want to have UEFI and OS accessing same media , Possibilities
> > I see
> >
> > 1- Patch OS For status check of media (diversion from generic OS), Good case
> will be modify low level driver.
> > But we may end up some surprises on synchronization.
> >
> > 2- no runtime service for OS . I guess this will not be possible
> >
> > 3- Way the  Vladimir implemented for eMMC, This has risk of losing data in
> case of AC power off.
> >
> > 4- update hardware with dual view (Ard suggestion)
> >
> 
> 5 - abstract direct block device access into a firmware service that is exposed via
> a DXE_RUNTIME_DRIVER.
> 
> The UEFI spec allows you to expose entry points into a DXE_RUNTIME_DRIVER
> module via a UEFI configuration table, and the OS can use a driver that uses the
> abstracted device rather than the real device. Performance is going to be
> terrible, probably, and lots of things that are specific to SD/MMC will no longer
> work, but it is a possibility nonetheless.