On 11/03/2014 07:18 AM, Pant, Alok wrote: >>>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
Another possibility is to handle variable services via an external BMC or management controller and its private storage. Have the BIOS firmware drivers (boot time and runtime) send variable read/write requests to the external controller, which uses private storage of its own to store the data. That way there's no collision between OS-owned and firmware-owned storage. In effect that's what the usual SMM-based variable driver does: SMM is the external controller, accessing private SPI-based storage. That may not be possible on a small embedded system without a BMC, though. Brian > > *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 > ------------------------------------------------------------------------------ _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
