> On Apr 23, 2015, at 7:50 PM, Andrew Fish <[email protected]> wrote:
>
>
>> On Apr 23, 2015, at 7:44 PM, Yao, Jiewen <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Hi Andrew or Haojiang
>> Would you please share more your insight below:
>> “It should be possible to discover based on address or PCD device path (or
>> protocol) and do the reads via FVB.”
>>
>> Is “discover” here means something done in variable driver Entrypoint?
>> Then variable driver need be enhanced get base address via DevicePathPcd or
>> Protocol (another dependency ?)
>> So we still assume variable storage is linear block device. Right?
>>
>
So yes if we only use FVB protocol LBA based addressing we solve the problem.
Then we have to add a way to find the correct FVB protocol to use.
Sorry I did not answer you question the 1st time.
Thanks,
Andrew Fish
> The issue if how do you find the FVB protocol to use with the store.
> Currently it is done via matching a memory mapped address. If you find the
> correct FVB you can do all the reads and writes from that device and that
> removes the assumption that the device is memory mapped. I think currently
> the write are done via FVB, but the initial read (to cache the store), and
> matching of FVB is done via an address.
>
> Thus if an FVB only supports a block device that can NOT be memory mapped, it
> will not be discovered by the variable driver, and there is no way to cache
> the variable store as that 1st read is memory based.
>
> Thanks,
>
> Andrew Fish
>
>> Thank you
>> Yao Jiewen
>>
>> From: Andrew Fish [mailto:[email protected] <mailto:[email protected]>]
>> Sent: Friday, April 24, 2015 10:01 AM
>> To: [email protected]
>> <mailto:[email protected]>
>> Subject: Re: [edk2] Variable Storage Driver
>>
>>
>> On Apr 23, 2015, at 6:53 PM, Haojian Zhuang <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> 在 2015/4/24 9:35, Yao, Jiewen 写道:
>>
>> 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?
>>
>> I think that we could just implement a block variable driver. And we
>> don't need to change more in existing variablue driver + fault write driver.
>>
>> Here's a reference as my implementation.
>> https://github.com/96boards/edk2/tree/hikey/HisiPkg/HiKeyPkg/Drivers/BlockVariableDxe
>>
>> <https://github.com/96boards/edk2/tree/hikey/HisiPkg/HiKeyPkg/Drivers/BlockVariableDxe>
>>
>> I only make it support FVB protocol, and it works. In order to keep
>> align with existing PCD values in variable driver. I keep declaring
>> PcdFlashNvStorageVariableBase & PcdNvStorageVariableBlockSize in memory
>> that are not useful. And I create new
>> PcdNvStorageVariableBlockDevicePath, PcdFlashNvStorageVariableBlockCount
>> & PcdNvStorageVariableBlockLba. And I still need to fix one thing that
>> should reserve this memory space.
>>
>>
>> I was just writing an email with a note that this was the right way to fix
>> the variable driver…. Thanks!
>>
>> The PCD could be a device path, or a feature flag to look for an FVB
>> protocol with a well know protocol on the handle (MdeModulePkg protocol with
>> NUL data).
>>
>> It should be possible to discover based on address or PCD device path (or
>> protocol) and do the reads via FVB.
>>
>> Thanks,
>>
>> Andrew Fish
>>
>>
>> Regards
>> Haojian
>>
>> ------------------------------------------------------------------------------
>> 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_______________________________________________
>>
>> <http://ad.doubleclick.net/ddm/clk/290420510;117567292;y_______________________________________________>
>> 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>
> ------------------------------------------------------------------------------
> 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
