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.biesheu...@linaro.org] > Sent: Wednesday, September 20, 2017 11:09 PM > To: Udit Kumar <udit.ku...@nxp.com> > Cc: Pankaj Bansal <pankaj.ban...@nxp.com>; Andrew Fish <af...@apple.com>; > olivier.mar...@arm.com; Vladimir Olovyannikov > <vladimir.olovyanni...@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.ku...@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. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
