HI Andrew You are right that we have FVB for flash device abstraction. The current variable have some assumption: 1) It assumes EFI_FVB2_MEMORY_MAPPED already set for FVB implementation. It even does not check this bit and start use memory map way to read flash. 2) It assumes EFI_FVB2_STICKY_WRITE already set for FVB implementation. So Erase block is always invoked. As you said, current variable driver is optimized for SPI NOR. But it might be burden to other flash device.
One more question is: this variable driver assume variable is stored in flash storage "block" - which can be abstracted by FVB. What happen, if variable in stored in another format? Map variable file to "block"? I see how it is implemented in OVMF, really complicated. Or should the other variable driver duplicate all complicated Authentication server in their own variable driver? In addition, we have 2 copy variable drivers open sourced: MdeModulePkg V.S. SecurityPkg. Many code are duplicated, while the only difference is authentication support. Probably we could put all authentication code into one place (a library maybe), so that other variable driver implementation could use it directly. So all UEFI spec update, like secure boot, can be centralized in this authentication lib, without impact variable storage implementation. A small step enhancement (I hope), but at least we can resolve duplicated code in EDKII. Thank you Yao Jiewen -----Original Message----- From: Andrew Fish [mailto:[email protected]] Sent: Friday, April 24, 2015 9:11 AM To: [email protected] Subject: Re: [edk2] Variable Storage Driver > On Apr 23, 2015, at 5:37 PM, Yao, Jiewen <[email protected]> wrote: > > Maybe it is interesting topic to separate variable driver into 2 layers: > 1) Software logic layer - like Authentication service, or variable > check > 2) Hardware access layer - like SPI NOR flash, or eMMC, UFS in the future. > The PI spec defines the Firmware Volume Block (FVB) protocol and the Fault Tolerant Write protocol. While it is optimized for NOR (memory mapped, with block erase), it also should support a block only interface. The upper layer is only optimizing the writes so that an underlying FVB that implements NOR can minimize the number of block erases that need to happen. If you look at the variable driver it is doing Fvb->Write() to update FLASH, and it passes an LBA (Logical Block Address), so any type of underlying store should be supported. The Fault Tolerant Write is used to store the block that has to be erased. Basically for each block that you needed to erase you did not want to require a spare block in the FLASH map. Historically the issue has been the complexity in the stack of converting hardware devices into FVB. From the PI spec point of view that is an implementation detail and it seems we have done a bad job of that. The FVB abstracts a region of the FD, not the entire FD, and this seems to introduce a massive amount of complexity into the implementations. I would also point out that if you are executing from the FLASH then it is by definition memory mapped. The initial FVB implementations are read only and are used to construct all the Firmware Volumes (another PI concept), and a driver that understands the FLASH device is added later in the boot. Thanks, Andrew Fish > UEFI spec update will only impact #1. > And when we have new storage technology, we only need change #2. > > Thank you > Yao Jiewen > > -----Original Message----- > From: Andrew Fish [mailto:[email protected]] > Sent: Friday, April 24, 2015 3:51 AM > To: [email protected] > Subject: Re: [edk2] Variable Storage Driver > > >> On Apr 23, 2015, at 11:35 AM, Narinder Dhillon <[email protected]> wrote: >> >> Hi All, >> >> It seems that the variable storage driver was written with parallel >> nor flash in mind. In order to make it work with a SPI-NOR flash >> device, > > It is designed to work with NOR flash. What properties of a parallel NOR vs. > SPI NOR do you think are in this code? > >> we have had to copy the >> "MdeModulePkg/Universal/FaultTolerantWriteDxe+Variable" folders to our own >> package and modify the code. >> >> Is my understanding correct ? That the variable store feature does not have >> block flash device support. >> > > It supports NOR Flash. So the code has the NOR like assumption that you can > program one bit transition direction on a per bit basis, but the opposite bit > transition requires a block erase. The Fault Tolerant Write is about having a > back up copy of the block that go erased. Which bit transition (0 to 1 or 1 > to 0) is supported is abstracted in the code. > >> Is it okay to upstream a package for our platform with these folders inside >> it ? >> > > You can do what ever you want in your own packages. IMHO if you want to > change the way one of the standard drivers work, and you have not intent of > getting the open source driver changed you should just copy the driver into > your own package and modify it. > > Thanks, > > Andrew Fish > >> Thanx, >> >> Narinder Dhillon >> >> --------------------------------------------------------------------- >> - >> -------- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT >> Develop your own process in accordance with the BPMN 2 standard Learn >> Process modeling best practices with Bonita BPM through live >> exercises >> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- >> event?utm_ >> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_S >> F _______________________________________________ >> edk2-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/edk2-devel > > > ---------------------------------------------------------------------- > -------- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard Learn > Process modeling best practices with Bonita BPM through live exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- > event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/edk2-devel > > ---------------------------------------------------------------------- > -------- One dashboard for servers and applications across > Physical-Virtual-Cloud Widest out-of-the-box monitoring support with > 50+ applications Performance metrics, stats and reports that give you > Actionable Insights Deep dive visibility with transaction tracing > using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
