>> which you can stop the h/w DMA, save OS context, do your task and then >> restore OS context Hi Feng, Thanks. Yes this is one possibly but the implementation is always messy. There is always some corner case where OS on other thread may be accessing the controller and BIOS(SMM) stepping on OS level storage driver execution may not always guarantee a clear save/restore transition and there may always be unanticipated corner cases. Other approach can be proprietary OS level driver coordinating with proprietary BIOS solution but then again one need to change OS driver per underlying kernel need.
When Runtime variable support is initially defined it was anticipated the storage behind the variable is BIOS owned (SPI) which seems to break here. The entire variable support (secure variable; protection) etc was based on this assumption. UEFI spec also discourage against delayed variable write (else BIOS-SMM etc could have cached the variable till later point); and it may be useful to have some consensus between BIOS/OS to play nicely. I could be as simple as whitepaper to define some guidance that works for all flavor of OS as I anticipate this problem is universal for such storage and we all are coming up on our own solution Thanks -Alok From: Tian, Feng [mailto:[email protected]] Sent: Sunday, November 02, 2014 7:09 PM To: [email protected] Subject: Re: [edk2] Non-Volatile Variable Storage Hi, Alok IMHO, One possible way to solve OS and F/W interaction for controlling same h/w controller is to implement a SMM driver, in which you can stop the h/w DMA, save OS context, do your task and then restore OS context. This way could handle OS and F/W access to the different places. but if they are trying to access a same block, the result of read/write is unpredictable. So you may need separate your variable region away from other contents. For example, put your variable at boot partition or RPMB and make a “reasonable” assumption that OS should not touch them directly. If no, then the content may be corrupted. Thanks Feng From: Zimmer, Vincent [mailto:[email protected]] Sent: Saturday, November 01, 2014 05: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]] 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]] 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]] 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]] 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
------------------------------------------------------------------------------
_______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
