Re: Storing Non volatile variables on SD/NAND

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

Thanks Jeremy 

> Hi,
> 
> On 10/27/2017 10:09 PM, Udit Kumar wrote:
> >> (along those lines)
> >>
> >> 6 - Build an emulated disk controller as well as NV region in el3 (or
> >> el2) and export them to UEFI & the OS as real devices. Then
> >> trap/forward requests to the actual storage device, which is
> >> "hidden". This AFAIK was the basic idea behind the PS/2 emulation in
> >> x86/SMM. Again, probably not a high performance option.
> >
> > You mean, have a driver in el3 or el2 and UEFI or OS is doing smc call to get
> things done.
> > On this line,  some sort of permission manager could reside in el3 or el2.
> > Either UEFI or OS driver needs to make a call, if they are allowed to
> > access this specific controller or other driver is accessing it.
> > With this  performance issue could be ironed out .
> 
> That isn't really what I meant, what I was thinking about was creating an
> emulated (AHCI for example) controller where accesses to the "register" space
> would trap to synchronous data/external aborts. That way the firmware and OS
> could use existing drivers without knowledge that the device was in any way
> special. If you create a driver and do SMC/whatever calls, then your basically
> doing #5..

This may work if both OS and UEFI are residing is same EL level.  
Do you mean, to get access to controller use this trap or entire AHCI space in
unmapped area, which will leads to synchronous aborts.

> 
> >
> > Regards
> > Udit
> >
> >> -----Original Message-----
> >> From: Jeremy Linton [mailto:jeremy.linton@arm.com]
> >> Sent: Friday, October 27, 2017 11:16 PM
> >> To: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Udit Kumar
> >> <udit.kumar@nxp.com>
> >> Cc: edk2-devel@lists.01.org; Andrew Fish <afish@apple.com>;
> >> Olivier.Martin@arm.com; Vladimir Olovyannikov
> >> <vladimir.olovyannikov@broadcom.com>
> >> Subject: Re: [edk2] Storing Non volatile variables on SD/NAND
> >>
> >> On 09/20/2017 12:39 PM, Ard Biesheuvel wrote:
> >>> 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.
> >>
> >> (along those lines)
> >>
> >> 6 - Build an emulated disk controller as well as NV region in el3 (or
> >> el2) and export them to UEFI & the OS as real devices. Then
> >> trap/forward requests to the actual storage device, which is
> >> "hidden". This AFAIK was the basic idea behind the PS/2 emulation in
> >> x86/SMM. Again, probably not a high performance option.
> >>
> >>
> >>>
> >>> 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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli
> >> sts.01
> >> .org%2Fmailman%2Flistinfo%2Fedk2-
> >>
> devel&data=02%7C01%7Cudit.kumar%40nxp.com%7Cfe11f07ea67a4efa7d1b08
> >>
> d51d629deb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63644723
> >>
> 1755528994&sdata=FYnH3ItGhXmqxNr%2BnaJBFMcKKduf%2FcS06JEA6dT6ZQA
> >> %3D&reserved=0
> >>>
> >