Well, the FTW driver is itself waiting on an event for FVB protocol before
it installs FTW protocol. So I need to do something in my DXE driver where
I have implemented FVB protocol. Something to kick the chain of events to
resolve these dependencies.


On Fri, Oct 31, 2014 at 5:47 PM, Narinder Dhillon <[email protected]>
wrote:

> Hi Jordan, Andrew,
>
> I can see that Variable/EmuRuntimeDxe installs
> the gEfiVariableWriteArchProtocolGuid while Variable/RuntimeDxe registers
> for FTW protocol event and only when the event notification function gets
> called then gEfiVariableWriteArchProtocolGuid is published.
>
>   EfiCreateProtocolNotifyEvent (
>     &gEfiFaultTolerantWriteProtocolGuid,
>     TPL_CALLBACK,
>     FtwNotificationEvent,
>     (VOID *)SystemTable,
>     &mFtwRegistration
>     );
>
> From the logs, FTW is getting loaded. Wonder if there is some DEPEX that I
> need.
>
> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 7F449840
> add-symbol-file
> /home/narinder/workdir2/sdk/bootloader/edk2/Build/Thunder_cn88xx/DEBUG_ARMLINUXGCC/AARCH64/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe/DEBUG/FaultTolerantWriteDxe.dll
> 0x7F6E6260
> Loading driver at 0x0007F6E6000 EntryPoint=0x0007F6E62B0
> FaultTolerantWriteDxe.efi
> InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 7F424C18
>
>
> On Fri, Oct 31, 2014 at 5:34 PM, Jordan Justen <[email protected]> wrote:
>
>> On Fri, Oct 31, 2014 at 5:00 PM, Narinder Dhillon <[email protected]>
>> wrote:
>> > Hi Jordan,
>> >
>> > What is the difference between RuntimeDxe, EmuRuntimeDxe ?
>> > From looking at the code, seems like RuntimeDxe is more complete
>> > implementation. But when I switch to that, I get errors from DxeMain.
>> > Not sure why.
>> > Thanx.
>>
>> Variable/EmuRuntimeDxe only tries to store variables in RAM. So, it
>> can be simplified somewhat. It does have much less external
>> dependencies, so from that viewpoint it is easier to use.
>>
>> Variable/RuntimeDxe brings a dependency on a FirmwareVolumeBlock
>> protocols.
>>
>> In OVMF I wanted to use Variable/RuntimeDxe, so I created the
>> OvmfPkg/EmuVariableFvbRuntimeDxe driver. It provides an FVB instance
>> that Variable/RuntimeDxe can then use.
>>
>> While EmuVariableFvbRuntimeDxe installs an FVB, it stores the contents
>> of the FVB in RAM. It then calls out to the hooks in
>> OvmfPkg/Include/Library/PlatformFvbLib.h so the platform can take some
>> action when the contents of the FVB in RAM are updated.
>>
>> Anyway, the reason for all the error messages below is that one of the
>> dependencies of Variable/RuntimeDxe must not have been found.
>> Therefore variable services were never started. And, when that
>> happens, many more things then fail to start.
>>
>> -Jordan
>>
>> > Variable Write Arch Protocol not present!!
>> >
>> > Capsule Arch Protocol not present!!
>> >
>> > Monotonic Counter Arch Protocol not present!!
>> > Driver 42857F0A-13F2-4B21-8A23-53D3F714B840 was discovered but not
>> loaded!!
>> > Driver AD608272-D07F-4964-801E-7BD3B7888652 was discovered but not
>> loaded!!
>> > Driver 51CCF399-4FDF-4E55-A45B-E123F84D456A was discovered but not
>> loaded!!
>> > Driver 408EDCEC-CF6D-477C-A5A8-B4844E3DE281 was discovered but not
>> loaded!!
>> > Driver 9E863906-A40F-4875-977F-5B93FF237FC6 was discovered but not
>> loaded!!
>> > Driver 93B80004-9FB3-11D4-9A3A-0090273FC14D was discovered but not
>> loaded!!
>> > Driver 8F4CD826-A5A0-4E93-9522-CFB0AB72926C was discovered but not
>> loaded!!
>> > Driver 5E523CB4-D397-4986-87BD-A6DD8B22F455 was discovered but not
>> loaded!!
>> > Driver 19DF145A-B1D4-453F-8507-38816676D7F6 was discovered but not
>> loaded!!
>> > Driver A2F436EA-A127-4EF8-957C-8048606FF670 was discovered but not
>> loaded!!
>> > Driver 529D3F93-E8E9-4E73-B1E1-BDF6A9D50113 was discovered but not
>> loaded!!
>> > Driver 94734718-0BBC-47FB-96A5-EE7A5AE6A2AD was discovered but not
>> loaded!!
>> > Driver 26841BDE-920A-4E7A-9FBE-637F477143A6 was discovered but not
>> loaded!!
>> > Driver 9FB1A1F3-3B71-4324-B39A-745CBB015FFF was discovered but not
>> loaded!!
>> > Driver 025BBFC7-E6A9-4B8B-82AD-6815A1AEAF4A was discovered but not
>> loaded!!
>> > Driver E4F61863-FE2C-4B56-A8F4-08519BC439DF was discovered but not
>> loaded!!
>> > Driver DC3641B8-2FA8-4ED3-BC1F-F9962A03454B was discovered but not
>> loaded!!
>> > Driver 6D6963AB-906D-4A65-A7CA-BD40E5D6AF4D was discovered but not
>> loaded!!
>> > Driver 6D6963AB-906D-4A65-A7CA-BD40E5D6AF2B was discovered but not
>> loaded!!
>> > Driver 3B1DEAB5-C75D-442E-9238-8E2FFB62B0BB was discovered but not
>> loaded!!
>> > Driver 4579B72D-7EC4-4DD4-8486-083C86B182A7 was discovered but not
>> loaded!!
>> > Driver AC7E2A1E-B975-4C79-8ADA-C9EEFC55A407 was discovered but not
>> loaded!!
>> > Driver B7F50E91-A759-412C-ADE4-DCD03E7F7C28 was discovered but not
>> loaded!!
>> > Driver 240612B7-A063-11D4-9A3A-0090273FC14D was discovered but not
>> loaded!!
>> > Driver 9FB4B4A7-42C0-4BCD-8540-9BCC6711F83E was discovered but not
>> loaded!!
>> > Driver C5B9C74A-6D72-4719-99AB-C59F199091EB was discovered but not
>> loaded!!
>> > Driver 6B38F7B4-AD98-40E9-9093-ACA2B5A253C4 was discovered but not
>> loaded!!
>> > Driver 1FA1F39E-FEFF-4AAE-BD7B-38A070A3B609 was discovered but not
>> loaded!!
>> > Driver 961578FE-B6B7-44C3-AF35-6BC705CD2B1F was discovered but not
>> loaded!!
>> > Driver CD3BAFB6-50FB-4FE8-8E4E-AB74D2C1A600 was discovered but not
>> loaded!!
>> >
>> > ASSERT_EFI_ERROR (Status = Not Found)
>> > ASSERT
>> >
>> /home/narinder/workdir2/sdk/bootloader/edk2/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c(489):
>> > !EFI_ERROR (Status)
>> >
>> >
>> > On Fri, Oct 31, 2014 at 2:54 PM, Jordan Justen <[email protected]>
>> wrote:
>> >>
>> >> On 2014-10-31 00:16:07, Gao, Liming wrote:
>> >> >    Yes. EDKII variable assumes the variable storage at a physically
>> map
>> >> >    location. This is a limitation.
>> >> >
>> >> >    To work with current EDKII variable drivers, for Variable Read,
>> PEI
>> >> > phase
>> >> >    also require to support it. So, you need to read variable storage
>> to
>> >> >    memory in PEI Phase, and share it to DXE phase. For Variable
>> Write,
>> >> > only
>> >> >    DXE phase requires it. So, you can implement FVB protocol to
>> handle
>> >> > the
>> >> >    write operation in the cached memory and storage.
>> >>
>> >> Well, we worked around this pretty nicely in OVMF when we wanted to
>> >> serialize variables to/from the FAT parition.
>> >>
>> >> OvmfPkg/EmuVariableFvbRuntimeDxe creates the FVB in RAM.
>> >>
>> >> It uses to 'hooks' for reading/writing the FVB via this library:
>> >> OvmfPkg/Include/Library/PlatformFvbLib.h
>> >>
>> >> When a write happens to the variable store, OVMF uses the FVB write
>> >> hook to signal that the variables need to be serialized to the FAT FS.
>> >>
>> >> I'm disappointed that I was not able to make this system replace
>> >> MdeModulePkg/Universal/Variable/EmuRuntimeDxe and DuetPkg/FSVariable
>> >> because then we could always just use the single variable driver:
>> >> MdeModulePkg/Universal/Variable/RuntimeDxe
>> >>
>> >> Now that QEMU/KVM has real flash support, I suppose that some parts of
>> >> this code now has an expiration date in OVMF... (The desire to
>> >> actually serialize the variables to/from disk is greatly diminished.)
>> >>
>> >> -Jordan
>> >>
>> >> >    From: Narinder Dhillon [mailto:[email protected]]
>> >> >    Sent: Friday, October 31, 2014 12:12 PM
>> >> >    To: [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]
>> >> 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
>>
>
>
------------------------------------------------------------------------------
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Reply via email to