Re: Storing Non volatile variables on SD/NAND

[Jeremy Linton <jeremy.linton@arm.com>]

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




> 
> 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%2Flists.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
>>>
>