> On Oct 31, 2014, at 2:25 PM, Olivier Martin <[email protected]> wrote:
> 
> At the last Linaro Connect (http://www.linaro.org/connect 
> <http://www.linaro.org/connect>), Grant, Ard and I started a discussion on 
> this topic. I explained them the design of a UEFI protocol for the handshake 
> between the UEFI Runtime Variable service and the OS driver I had in mind.
> But the problem becomes interesting one you add the UEFI Secure Boot in the 
> equation...
>  

I was going to mention it would be possible to standardize a layout so that it 
is just an EFI driver pre-OS driver, and an OS driver afterwords. But the UEFI 
Secure Boot makes it “challenging”.

Thanks,

Andrew Fish

>  
> From: Zimmer, Vincent [mailto:[email protected] 
> <mailto:[email protected]>] 
> Sent: 31 October 2014 21:07
> To: [email protected] <mailto:[email protected]>
> Subject: Re: [edk2] Non-Volatile Variable Storage
>  
> Good points on both sides.
> I see UEFI Forum w/ USWG and ASWG (UEFI and ACPI spec, resp) as a place to 
> explore this a little further, although Fish may be right about ultimate 
> scope boundaries.
> As such, I’ll take the action item to convey these concerns to those bodies 
> this upcoming week.
> Vincent
>  
> From: Pant, Alok [mailto:[email protected] <mailto:[email protected]>] 
> Sent: Friday, October 31, 2014 1:56 PM
> To: [email protected] <mailto:[email protected]>
> Subject: Re: [edk2] Non-Volatile Variable Storage
>  
> Hi Andrew. Thanks. Yes, I understand and agree with your point. All I point 
> is there is no universally-agreed/“standard” approach to resolve OS-BIOS 
> interaction wrt to shared variable storage & universally agreed interface 
> between BIOS-OS for such scenario could aid OS agnostic firmware solution. 
> You are suggesting that be implementation details beyond the scope of UEFI 
> spec & I agree. The reason I raised here is due to only known forum where all 
> relevant parties engages & I liked to probe if this is common issue for 
> broader vendor-bios-os to seek consensus on common solution, or each come up 
> with their own unique implementation
>  
> Thanks again
> -Alok
>  
> From: Andrew Fish [mailto:[email protected] <mailto:[email protected]>] 
> Sent: Friday, October 31, 2014 12:24 PM
> To: [email protected] <mailto:[email protected]>
> Subject: Re: [edk2] Non-Volatile Variable Storage
>  
>  
>> On Oct 31, 2014, at 7:58 AM, Pant, Alok <[email protected] 
>> <mailto:[email protected]>> wrote:
>>  
>> >> You will need some handshake between the OS kernel and the UEFI firmware.
>> As I understand there is no real “industry standard” spec for runtime nature 
>> of UEFI OS/BIOS access to shared eMMC controller (owned by OS level driver) 
>> and vendor comes with their proprietary OS level solution. Right? Is this 
>> something that need to be addressed (or can be addressed  handshake between 
>> os/bios?) as runtime UEFI variable must be supported on those UEFI OS
>>  
>> This may be more of UEFI spec question but since all the experts chime in 
>> this forum, I also hoped to probe further?
>>  
>  
> The UEFI spec describes how to write EFI Runtime Services that are callable 
> via an OS provided virtual address space. The UEFI does not speak to what 
> hardware is used to implement the backing store. 
>  
> The reality of how the OS and Firmware work is the variable store needs to be 
> a resource owned by the firmware, on a lot of PC like platforms this is the 
> NOR flash that EFI booted out of. 
>  
> To utilize a shared resource would require cooperation between the driver 
> (and maybe the OS) and firmware. The UEFI spec avoids discussing OS 
> specifics, and trying to recommend hardware implementations (as hardware 
> changes at a rapid rate). 
>  
> Thanks,
>  
> Andrew Fish 
>  
> 
> From: Olivier Martin [mailto:[email protected] 
> <mailto:[email protected]>] 
> Sent: Friday, October 31, 2014 9:04 AM
> To: [email protected] <mailto:[email protected]>
> Subject: Re: [edk2] Non-Volatile Variable Storage
>  
> Something you have to be aware about Non-Volatile UEFI variables is they 
> might need to be accessible when the OS is running (through UEFI runtime 
> services).
> If your OS uses the same eMMC controller to access the filesystem then you 
> might have some serious issues. You will need some handshake between the OS 
> kernel and the UEFI firmware.
>  
>  
> From: Narinder Dhillon [mailto:[email protected] 
> <mailto:[email protected]>] 
> Sent: 31 October 2014 04:12
> To: [email protected] <mailto:[email protected]>
> Subject: [edk2] Non-Volatile Variable Storage
>  
> Hi All,
>  
> I am attempting to implement a non-volatile variable storage in an eMMC 
> device. After about a week of looking around, I have come to the realization 
> that there is no such feature in edk2.
> Is this correct ?
>  
> Looking at 'variable' drivers, it seems that the variable storage for both 
> volatile and non are assumed to be at a physically mapped location. I can try 
> to load this physical address by reading the block flash device and copying 
> its contents to this location before the 'variable' driver starts. I will 
> have to implement some shell command to save the changed contents back to 
> flash device.
>  
> Does this sound reasonable or is there an easier way ?
>  
> Where can I implement this driver to load the non-volatile variable store 
> before 'variable' driver starts ?
>  
> Thanx.
> ------------------------------------------------------------------------------
> _______________________________________________
> edk2-devel mailing list
> [email protected] <mailto:[email protected]>
> https://lists.sourceforge.net/lists/listinfo/edk2-devel 
> <https://lists.sourceforge.net/lists/listinfo/edk2-devel>
>  
> ------------------------------------------------------------------------------
> _______________________________________________
> edk2-devel mailing list
> [email protected] <mailto:[email protected]>
> https://lists.sourceforge.net/lists/listinfo/edk2-devel 
> <https://lists.sourceforge.net/lists/listinfo/edk2-devel>
------------------------------------------------------------------------------
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Reply via email to