[edk2] Variable Storage Driver

Discussion:

Narinder Dhillon

2015-04-23 18:35:20 UTC

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, 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.

Is it okay to upstream a package for our platform with these folders inside
it ?

Thanx,

Narinder Dhillon

Andrew Fish

2015-04-23 19:50:50 UTC

Permalink

Post by Narinder Dhillon
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?

Post by Narinder Dhillon
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.

Post by Narinder Dhillon
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

Post by Narinder Dhillon
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_SF_______________________________________________
edk2-devel mailing list
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Yao, Jiewen

2015-04-24 00:37:18 UTC

Permalink

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.

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:***@apple.com]
Sent: Friday, April 24, 2015 3:51 AM
To: edk2-***@lists.sourceforge.net
Subject: Re: [edk2] Variable Storage Driver

Post by Narinder Dhillon
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?

Post by Narinder Dhillon
Is it okay to upstream a package for our platform with these folders inside it ?

Post by Narinder Dhillon
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_SF
_______________________________________________
edk2-devel mailing list
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Andrew Fish

2015-04-24 01:11:04 UTC

Permalink

Post by Yao, Jiewen
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

Post by Yao, Jiewen
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-----
Sent: Friday, April 24, 2015 3:51 AM
Subject: Re: [edk2] Variable Storage Driver

Post by Narinder Dhillon
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?

Post by Narinder Dhillon
Is it okay to upstream a package for our platform with these folders inside it ?

Post by Narinder Dhillon
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_SF
_______________________________________________
edk2-devel mailing list
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
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
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Yao, Jiewen

2015-04-24 01:35:43 UTC

Permalink

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:***@apple.com]
Sent: Friday, April 24, 2015 9:11 AM
To: edk2-***@lists.sourceforge.net
Subject: Re: [edk2] Variable Storage Driver

Post by Yao, Jiewen
1) Software logic layer - like Authentication service, or variable check
2) Hardware access layer - like SPI NOR flash, or eMMC, UFS in the future.

Post by Narinder Dhillon
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?

Post by Narinder Dhillon
Is it okay to upstream a package for our platform with these folders inside it ?

Post by Narinder Dhillon
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
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
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
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
edk2-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Haojian Zhuang

2015-04-24 01:53:10 UTC

Permalink

Post by Yao, Jiewen
HI Andrew
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?

Andrew Fish

2015-04-24 02:00:49 UTC

Permalink

Post by Haojian Zhuang

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

Post by Haojian Zhuang
Regards
Haojian

Haojian Zhuang

2015-04-24 02:23:37 UTC

Permalink

Post by Andrew Fish

On Apr 23, 2015, at 6:53 PM, Haojian Zhuang

Post by Yao, Jiewen
HI Andrew
You are right that we have FVB for flash device abstraction. The
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 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.

How to reserve memory? Since I need to fix it.

Best Regards
Haojian

Yao, Jiewen

2015-04-24 02:44:16 UTC

Permalink

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?

Thank you
Yao Jiewen

From: Andrew Fish [mailto:***@apple.com]
Sent: Friday, April 24, 2015 10:01 AM
To: edk2-***@lists.sourceforge.net
Subject: Re: [edk2] Variable Storage Driver

On Apr 23, 2015, at 6:53 PM, Haojian Zhuang <***@linaro.org<mailto:***@linaro.org>> 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

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

Andrew Fish

2015-04-24 02:50:40 UTC

Permalink

Post by Yao, Jiewen
Hi Andrew or Haojiang
â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?

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

Post by Yao, Jiewen
Thank you
Yao Jiewen
Sent: Friday, April 24, 2015 10:01 AM
Subject: Re: [edk2] Variable Storage Driver
HI Andrew
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
https://lists.sourceforge.net/lists/listinfo/edk2-devel <https://lists.sourceforge.net/lists/listinfo/edk2-devel>

Andrew Fish

2015-04-24 02:53:47 UTC

Permalink

Post by Andrew Fish

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

Post by 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

------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Yao, Jiewen

2015-04-24 04:21:27 UTC

Permalink

That makes a lot of sense. Thanks, Andrew.

Thank you
Yao Jiewen

From: Andrew Fish [mailto:***@apple.com]
Sent: Friday, April 24, 2015 10:54 AM
To: edk2-***@lists.sourceforge.net
Subject: Re: [edk2] Variable Storage Driver

On Apr 23, 2015, at 7:50 PM, Andrew Fish <***@apple.com<mailto:***@apple.com>> wrote:

On Apr 23, 2015, at 7:44 PM, Yao, Jiewen <***@intel.com<mailto:***@intel.com>> 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:***@apple.com]
Sent: Friday, April 24, 2015 10:01 AM
To: edk2-***@lists.sourceforge.net<mailto:edk2-***@lists.sourceforge.net>
Subject: Re: [edk2] Variable Storage Driver

On Apr 23, 2015, at 6:53 PM, Haojian Zhuang <***@linaro.org<mailto:***@linaro.org>> 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

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_______________________________________________
edk2-devel mailing list
edk2-***@lists.sourceforge.net<mailto:edk2-***@lists.sourceforge.net>
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
edk2-***@lists.sourceforge.net<mailto:edk2-***@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Yao, Jiewen

2015-04-24 02:03:55 UTC

Permalink

Hi Haojian
Thanks for the sharing.

May I know if you have validated variable set in UEFI runtime?
I found it is marked as DXE driver instead of RUNTIME driver. But maybe I am wrong.

Thank you
Yao Jiewen

-----Original Message-----
From: Haojian Zhuang [mailto:***@linaro.org]
Sent: Friday, April 24, 2015 9:53 AM
To: edk2-***@lists.sourceforge.net
Subject: Re: [edk2] Variable Storage 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

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.

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
_______________________________________________
edk2-devel mailing list
edk2-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Haojian Zhuang

2015-04-24 02:25:03 UTC

Permalink

Post by Yao, Jiewen
Hi Haojian
Thanks for the sharing.
May I know if you have validated variable set in UEFI runtime?
I found it is marked as DXE driver instead of RUNTIME driver. But maybe I am wrong.

Yes, you'r right. I only verified it as DXE driver. I'll try to access
it for RUNTIME case. Thanks for reminder.

Best Regards
Haojian

Haojian Zhuang

2015-04-24 02:31:28 UTC

Permalink

Post by Haojian Zhuang

Yes, you'r right. I only verified it as DXE driver. I'll try to access
it for RUNTIME case. Thanks for reminder.

When I try to use RUNTIME service, I should reserve UEFI memory in linux
kernel. How could I know how much memory should I reserve? What's the
start address?

Best Regards
Haojian

Andrew Fish

2015-04-24 02:41:12 UTC

Permalink

Post by Haojian Zhuang

Yes, you'r right. I only verified it as DXE driver. I'll try to access
it for RUNTIME case. Thanks for reminder.

When I try to use RUNTIME service, I should reserve UEFI memory in linux
kernel. How could I know how much memory should I reserve? What's the
start address?

You donât need to reserve memory. You allocate memory of a type that lives into UEFI runtime. If you allocate EfiRuntimeServicesData at EFI time that memory is never given to the OS.

Also to be a runtime driver you must support being called by the OS with a virtual mapping provided by the OS. In the Variable driver the VariableClassAddressChangeEvent() function converts the variable drivers pointers to the virtual mapping given by the OS (or the OS loader).

https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
/**
Notification function of EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE.

This is a notification function registered on EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE event.
It convers pointer to new virtual address.

@param Event Event whose notification function is being invoked.
@param Context Pointer to the notification function's context.

**/
VOID
EFIAPI
VariableClassAddressChangeEvent (
IN EFI_EVENT Event,
IN VOID *Context
)
{
EFI_STATUS Status;
UINTN Index;

EfiConvertPointer (0x0, (VOID **) &mVariableModuleGlobal->FvbInstance->GetBlockSize);
EfiConvertPointer (0x0, (VOID **) &mVariableModuleGlobal->FvbInstance->GetPhysicalAddress);
EfiConvertPointer (0x0, (VOID **) &mVariableModuleGlobal->FvbInstance->GetAttributes);
EfiConvertPointer (0x0, (VOID **) &mVariableModuleGlobal->FvbInstance->SetAttributes);
EfiConvertPointer (0x0, (VOID **) &mVariableModuleGlobal->FvbInstance->Read);
EfiConvertPointer (0x0, (VOID **) &mVariableModuleGlobal->FvbInstance->Write);
EfiConvertPointer (0x0, (VOID **) &mVariableModuleGlobal->FvbInstance->EraseBlocks);
EfiConvertPointer (0x0, (VOID **) &mVariableModuleGlobal->FvbInstance);
EfiConvertPointer (0x0, (VOID **) &mVariableModuleGlobal->PlatformLangCodes);
EfiConvertPointer (0x0, (VOID **) &mVariableModuleGlobal->LangCodes);
EfiConvertPointer (0x0, (VOID **) &mVariableModuleGlobal->PlatformLang);
EfiConvertPointer (0x0, (VOID **) &mVariableModuleGlobal->VariableGlobal.NonVolatileVariableBase);
EfiConvertPointer (0x0, (VOID **) &mVariableModuleGlobal->VariableGlobal.VolatileVariableBase);
EfiConvertPointer (0x0, (VOID **) &mVariableModuleGlobal->VariableGlobal.HobVariableBase);
EfiConvertPointer (0x0, (VOID **) &mVariableModuleGlobal);
EfiConvertPointer (0x0, (VOID **) &mNvVariableCache);
EfiConvertPointer (0x0, (VOID **) &mHandlerTable);
for (Index = 0; Index < mNumberOfHandler; Index++) {
EfiConvertPointer (0x0, (VOID **) &mHandlerTable[Index]);
}

Status = EfiConvertList (0x0, &mLockedVariableList);
ASSERT_EFI_ERROR (Status);

Status = EfiConvertList (0x0, &mVarCheckVariableList);
ASSERT_EFI_ERROR (Status);
}

Thanks,

Andrew Fish

https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Include/Uefi/UefiMultiPhase.h
///
/// Enumeration of memory types introduced in UEFI.
///
typedef enum {
///
/// Not used.
///
EfiReservedMemoryType,
///
/// The code portions of a loaded application.
/// (Note that UEFI OS loaders are UEFI applications.)
///
EfiLoaderCode,
///
/// The data portions of a loaded application and the default data allocation
/// type used by an application to allocate pool memory.
///
EfiLoaderData,
///
/// The code portions of a loaded Boot Services Driver.
///
EfiBootServicesCode,
///
/// The data portions of a loaded Boot Serves Driver, and the default data
/// allocation type used by a Boot Services Driver to allocate pool memory.
///
EfiBootServicesData,
///
/// The code portions of a loaded Runtime Services Driver.
///
EfiRuntimeServicesCode,
///
/// The data portions of a loaded Runtime Services Driver and the default
/// data allocation type used by a Runtime Services Driver to allocate pool memory.
///
EfiRuntimeServicesData,
///
/// Free (unallocated) memory.
///
EfiConventionalMemory,
///
/// Memory in which errors have been detected.
///
EfiUnusableMemory,
///
/// Memory that holds the ACPI tables.
///
EfiACPIReclaimMemory,
///
/// Address space reserved for use by the firmware.
///
EfiACPIMemoryNVS,
///
/// Used by system firmware to request that a memory-mapped IO region
/// be mapped by the OS to a virtual address so it can be accessed by EFI runtime services.
///
EfiMemoryMappedIO,
///
/// System memory-mapped IO region that is used to translate memory
/// cycles to IO cycles by the processor.
///
EfiMemoryMappedIOPortSpace,
///
/// Address space reserved by the firmware for code that is part of the processor.
///
EfiPalCode,
EfiMaxMemoryType
} EFI_MEMORY_TYPE;

Post by Haojian Zhuang
Best 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
_______________________________________________
edk2-devel mailing list
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Yao, Jiewen

2015-04-24 02:50:34 UTC

Permalink

Hi Haojian
I am not sure if I understand your question. But I just try to answer:
If you use memory type named " EfiRuntimeServicesData", this memory region will be reserved by UEFI OS automatically.
If you use driver type " DXE_RUNTIME_DRIVER", the driver will be allocated into " EfiRuntimeServicesCode". Then the memory region will be reserved by UEFI OS automatically.

There are something you might need be aware: The virtual memory in OS does not same as physical memory, so your driver might need to run gRT->ConvertPointer().
You may refer to one of runtime driver in EDKII as reference.

Thank you
Yao Jiewen

-----Original Message-----
From: Haojian Zhuang [mailto:***@linaro.org]
Sent: Friday, April 24, 2015 10:31 AM
To: edk2-***@lists.sourceforge.net
Subject: Re: [edk2] Variable Storage Driver

Post by Haojian Zhuang

Yes, you'r right. I only verified it as DXE driver. I'll try to access
it for RUNTIME case. Thanks for reminder.

When I try to use RUNTIME service, I should reserve UEFI memory in linux kernel. How could I know how much memory should I reserve? What's the start address?

Best 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
_______________________________________________
edk2-devel mailing list
edk2-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Haojian Zhuang

2015-07-23 09:20:21 UTC

Permalink

Yes, you'r right. I only verified it as DXE driver. I'll try to access it
for RUNTIME case. Thanks for reminder.

Hi Jiewen & Andrew,

I'm sorry that I just have time to enable the block variable driver as
runtime driver.
Now I find there's the issue on it. We need to enable both the block variable
driver & mmc driver as runtime.

The working flow is in below.
1. MMC controller is intiailized by UEFI.
2. MMC controller is initialized by linux.
3. Update variable in linux. It means MMC driver is invoked by UEFI.

I think the working flow is wrong. We shouldn't do this. It seems that
we have only
two choices. One is to make sure the hardware controller could be only accessed
by UEFI. The second one is to only implement MMC operation in UEFI. When linux
wants to access MMC, it has to submit the request to UEFI.

Do you think it's possible to only implement MMC operation in UEFI?

Regards
Haojian

------------------------------------------------------------------------------

Continue reading on narkive:

Search results for '[edk2] Variable Storage Driver' (Questions and Answers)

replies

Is a Porsche 911 a safe car for a first time driver?

started 2012-03-28 19:09:36 UTC

porsche

replies

My external Hard Drive Homemade not working?

started 2009-12-12 23:58:51 UTC

hardware

replies

Which sewing machine should I buy?