summaryrefslogtreecommitdiff
path: root/OvmfPkg/Include/Library
AgeCommit message (Collapse)Author
2017-09-05Remove core packages since we can get them from edk2 repositoryGuo Mang
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Guo Mang <mang.guo@intel.com>
2015-03-03OvmfPkg: XenHypercallLib: introduce XenHypercallIsAvailable()Laszlo Ersek
Similarly to QemuFwCfgLib, we prefer mellow library construction code and an explicit "are you available" query function in the XenHypercallLib class. In this step we introduce that query function, but move no client code to it yet. Suggested-by: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17000 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-28ArmVirtualizationPkg: add XenIoMmioLibArd Biesheuvel
This adds a XenIoMmioLib declaration and implementation that can be invoked to install the XENIO_PROTOCOL and a corresponding grant table address on a EFI handle. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16979 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-28Ovmf/Xen: move XenBusDxe hypercall code to separate libraryArd Biesheuvel
This moves all of the Xen hypercall code that was private to XenBusDxe to a new library class XenHypercallLib. This will allow us to reimplement it for ARM, and to export the Xen hypercall functionality to other parts of the code, such as a Xen console SerialPortLib driver. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16970 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-14OvmfPkg: QemuBootOrderLib: expose QEMU's "-boot menu=on[,splash-time=N]"Laszlo Ersek
The QEMU command line option -boot menu=on is meant to have the guest firmware wait for a firmware-specific interval for the user to enter the boot menu. During the wait, the user can opt to enter the boot menu, or interrupt the wait and proceed to booting at once. If the wait interval elapses, the firmware should boot as it normally would. The QEMU command line option -boot menu=on,splash-time=N means the same, except the firmware should wait for cca. N milliseconds instead of a firmware-specific interval. We can approximate this behavior quite well for edk2's virtual platforms because the Intel BDS front page already supports a progress bar, with semantics similar to the above. Let's distill the fw_cfg bits underlying "-boot menu=on,splash-time=N" for the BDS policies, in the form of a timeout value they can pass to Intel's PlatformBdsEnterFrontPage(). If the boot menu is not requested, we return "gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformBootTimeOut", which is what the virtual platforms use right now. If the boot menu is requested without specifying the timeout, we return the same PCD, unless it would cause us to skip the boot menu at once. In the latter case, we return 3 seconds (as an approximation of the 2500 ms SeaBIOS default.) RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1170507 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Olivier Martin <Olivier.martin@arm.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16610 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-02OvmfPkg: extract QemuBootOrderLibLaszlo Ersek
and rebase OvmfPkg's PlatformBdsLib on the standalone library. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16570 6f19259b-4bc3-4df7-8a09-765794883524
2014-06-19OvmgPkg: QemuFwCfgLib: export QEMU_FW_CFG_FNAME_SIZELaszlo Ersek
Names of firmware configuration files always take 56 bytes (including at least one terminating NUL byte). Expose this constant to all consumers of QemuFwCfgLib because further interfaces may depend on it. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15571 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04OvmfPkg QemuFwCfgLib: determine if S3 support is explicitly enabledLaszlo Ersek
Such a packaged query function will come in handy in the following patches. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> [jordan.l.justen@intel.com: check for enabled rather than disabled] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15292 6f19259b-4bc3-4df7-8a09-765794883524
2014-01-03OvmfPkg: QemuFwCfgLib: introduce InternalQemuFwCfgIsAvailable()Laszlo Ersek
This internal function allows separation of library-internal and for-clients external availability of fw_cfg. The interface contract of QemuFwCfgIsAvailable() is changed so that now it may modify fw_cfg state. All current users are compliant with the new contract. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15044 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11OvmfPkg/Virtio: Removed VirtioReadDevice() / VirtIoWriteDevice() functionsOlivier Martin
These functions did not provide much more than the new protocol functions VIRTIO_DEVICE_PROTOCOL.ReadDevice() / VIRTIO_DEVICE_PROTOCOL.WriteDevice(). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14968 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11OvmfPkg: Make the VirtIo devices use the new VIRTIO_DEVICE_PROTOCOLOlivier Martin
This change replaces the accesses to the PCI bus from the Block, Scsi and Net drivers by the use of the new VIRTIO_DEVICE_PROTOCOL protocol that abstracts the transport layer. It means these drivers can be used on PCI and MMIO transport layer. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> v5: - VirtioFlush(): update comment block in VirtioLib.[hc]; error code is propagated from VirtIo->SetQueueNotify(). - VirtioBlkInit(): jump to Failed label if SetPageSize() fails - VirtioBlkInit(): fixup comment, and add error handling, near SetQueueNum() call - VirtioBlkDriverBindingStart(): remove redundant (always false) check for a subsystem device ID different from VIRTIO_SUBSYSTEM_BLOCK_DEVICE; VirtioBlkDriverBindingSupported() handles it already - VirtioNetGetFeatures(): update stale comment block - VirtioNetGetFeatures(): retrieve MAC address byte for byte (open-coded loop) - VirtioNetDriverBindingStart(): remove redundant (always false) check for a subsystem device ID different from VIRTIO_SUBSYSTEM_NETWORK_CARD; VirtioNetDriverBindingSupported() handles it already - VirtioNetInitRing(): call SetQueueNum() and SetQueueAlign() for proper MMIO operation - VirtioNetInitialize(): fix destination error label for when SetPageSize() fails - VirtioScsi.c: fix comment block of VIRTIO_CFG_WRITE()/VIRTIO_CFG_READ() - VirtioScsiInit(): fix destination error label for when SetPageSize() fails - VirtioScsiInit(): call SetQueueNum() and SetQueueAlign() for proper MMIO operation Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14966 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11OvmfPkg/VirtioMmioDeviceLib: Implement VIRTIO_DEVICE_PROTOCOL for VirtIo ↵Olivier Martin
Devices over MMIO Why is the virtio-mmio implementation of the protocol a library, instead of a driver binary? The UEFI driver model would encourage to create a virtio-mmio driver instead of a library. But the reasons why I created a library are: - A virtio-mmio driver would imply an additional protocol that would probably have a single attribute field: typedef struct { PHYSICAL_ADDRESS BaseAddress; } VIRTIO_MMIO_DEVICE_PROTOCOL; - There is no (easy) way to scan the available VirtIo devices on a platform. So, the UEFI firmware for this platform would need a driver to produce instances for every virtio devices it wants to expose in UEFI. A single call to a helper library (ie: VirtioMmioDeviceLib) make the porting easier. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> v5: - typo fix in VirtioMmioInstallDevice() comment block - plug MmioDevice leak in VirtioMmioUninstallDevice() - return EFI_INVALID_PARAMETER in VirtioMmioGetQueueAddress() if QueueAddress is NULL - VirtioMmioSetQueueSize(): fix return value (it's a status code) - VirtioMmioSetPageSize(): check against EFI_PAGE_SIZE with "if" plus EFI_UNSUPPORTED, rather than ASSERT() - VirtioMmioDeviceWrite(), VirtioMmioDeviceRead(): remove redundant (FieldSize > 8) checks - VirtioMmioDeviceLib.inf: drop UefiDriverEntryPoint library dependency Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14965 6f19259b-4bc3-4df7-8a09-765794883524
2013-05-15OvmfPkg: adapt VirtioFlush()'s leading comment to the coding stylejljusten
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14362 6f19259b-4bc3-4df7-8a09-765794883524
2013-05-15OvmfPkg: adapt VirtioAppendDesc()'s leading comment to the coding stylejljusten
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14361 6f19259b-4bc3-4df7-8a09-765794883524
2013-05-15OvmfPkg: adapt VirtioPrepare()'s leading comment to the coding stylejljusten
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14360 6f19259b-4bc3-4df7-8a09-765794883524
2013-05-14OvmfPkg: VirtioLib: populate the Available Ring correctlyjljusten
The descriptor table (also known as "queue") consists of descriptors. (The corresponding type in the code is VRING_DESC.) An individual descriptor describes a contiguous buffer, to be transferred uni-directionally between host and guest. Several descriptors in the descriptor table can be linked into a descriptor chain, specifying a bi-directional scatter-gather transfer between host and guest. Such a descriptor chain is also known as "virtio request". (The descriptor table can host sereval descriptor chains (in-flight virtio requests) in parallel, but the OVMF driver supports at most one chain, at any point in time.) The first descriptor in any descriptor chain is called "head descriptor". In order to submit a number of parallel requests (= a set of independent descriptor chains) from the guest to the host, the guest must put *only* the head descriptor of each separate chain onto the Available Ring. VirtioLib currently places the head of its one descriptor chain onto the Available Ring repeatedly, once for each single (head *or* dependent) descriptor in said descriptor chain. If the descriptor chain comprises N descriptors, this error amounts to submitting the same entire chain N times in parallel. Available Ring Descriptor table Ptr to head ----> Desc#0 (head of chain) Ptr to head --/ Desc#1 (next in same chain) ... / ... Ptr to head / Desc#(N-1) (last in same chain) Anatomy of a single virtio-blk READ request (a descriptor chain with three descriptors): virtio-blk request header, prepared by guest: VirtioAppendDesc PhysAddr=3FBC6050 Size=16 Flags=1 Head=1232 Next=1232 payload to be filled in by host: VirtioAppendDesc PhysAddr=3B934C00 Size=32768 Flags=3 Head=1232 Next=1233 host status, to be filled in by host: VirtioAppendDesc PhysAddr=3FBC604F Size=1 Flags=2 Head=1232 Next=1234 Processing on the host side -- the descriptor chain is processed three times in parallel (its head is available to virtqueue_pop() thrice); the same chain is submitted/collected separately to/from AIO three times: virtio_queue_notify vdev VDEV vq VQ#0 virtqueue_pop vq VQ#0 elem EL#0 in_num 2 out_num 1 bdrv_aio_readv bs BDRV sector_num 585792 nb_sectors 64 opaque REQ#0 virtqueue_pop vq VQ#0 elem EL#1 in_num 2 out_num 1 bdrv_aio_readv bs BDRV sector_num 585792 nb_sectors 64 opaque REQ#1 virtqueue_pop vq VQ#0 elem EL#2 in_num 2 out_num 1 bdrv_aio_readv bs BDRV sector_num 585792 nb_sectors 64 opaque REQ#2 virtio_blk_rw_complete req REQ#0 ret 0 virtio_blk_req_complete req REQ#0 status 0 virtio_blk_rw_complete req REQ#1 ret 0 virtio_blk_req_complete req REQ#1 status 0 virtio_blk_rw_complete req REQ#2 ret 0 virtio_blk_req_complete req REQ#2 status 0 On my Thinkpad T510 laptop with RHEL-6 as host, this probably leads to simultaneous DMA transfers targeting the same RAM area. Even though the source of each transfer is identical, the data is corrupted in the destination buffer -- the CRC32 calculated over the buffer varies, even though the origin of the transfers is the same, never rewritten LBA. SynchronousRequest Lba=585792 BufSiz=32768 ReqIsWrite=0 Crc32=BF68A44D The problem is invisible on my HP Z400 workstation. Fix the request submission by: - building the only one descriptor chain supported by VirtioLib always at the beginning of the descriptor table, - ensuring the head descriptor of this chain is put on the Available Ring only once, - requesting the virtio spec's language to be cleaned up <http://lists.linuxfoundation.org/pipermail/virtualization/2013-April/024032.html>. Available Ring Descriptor table Ptr to head ----> Desc#0 (head of chain) Desc#1 (next in same chain) ... Desc#(N-1) (last in same chain) VirtioAppendDesc PhysAddr=3FBC6040 Size=16 Flags=1 Head=0 Next=0 VirtioAppendDesc PhysAddr=3B934C00 Size=32768 Flags=3 Head=0 Next=1 VirtioAppendDesc PhysAddr=3FBC603F Size=1 Flags=2 Head=0 Next=2 virtio_queue_notify vdev VDEV vq VQ#0 virtqueue_pop vq VQ#0 elem EL#0 in_num 2 out_num 1 bdrv_aio_readv bs BDRV sector_num 585792 nb_sectors 64 opaque REQ#0 virtio_blk_rw_complete req REQ#0 ret 0 virtio_blk_req_complete req REQ#0 status 0 SynchronousRequest Lba=585792 BufSiz=32768 ReqIsWrite=0 Crc32=1EEB2B07 (The Crc32 was double-checked with edk2's and Linux's guest IDE driver.) Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14356 6f19259b-4bc3-4df7-8a09-765794883524
2013-01-28QemuFwCfgLib: Add QemuFwCfgWriteBytes() functionjljusten
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14109 6f19259b-4bc3-4df7-8a09-765794883524
2013-01-16OvmfPkg: LoadLinuxLib: Zero kernel parameters instead of passing garbagejljusten
We're supposed to zero everything in the kernel bootparams that we don't explicitly initialise, other than the setup_header from 0x1f1 onwards for a precisely defined length, which is copied from the bzImage. We're *not* supposed to just pass the garbage that we happened to find in the bzImage file surrounding the setup_header. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14052 6f19259b-4bc3-4df7-8a09-765794883524
2012-11-02OvmfPkg: Add LoadLinuxLib library interfacejljusten
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13921 6f19259b-4bc3-4df7-8a09-765794883524
2012-10-12OvmfPkg: MSVC build fixes for VirtioLib and VirtioBlkDxejljusten
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Mike Lee <leemiketw@gmail.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13845 6f19259b-4bc3-4df7-8a09-765794883524
2012-10-12OvmfPkg: librarize reusable bits from VirtioBlkDxe's SynchronousRequest()jljusten
new VirtioLib functions: - VirtioPrepare(): prepare for appending descriptors - VirtioFlush(): submit descriptor chain and await host answer Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13844 6f19259b-4bc3-4df7-8a09-765794883524
2012-10-12OvmfPkg: rename AppendDesc to VirtioAppendDescjljusten
AppendDesc() should have a prefix implying its containing library, VirtioLib. Update its sole client VirtioBlkDxe. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13843 6f19259b-4bc3-4df7-8a09-765794883524
2012-10-12OvmfPkg: extract VirtioLib from VirtioBlkDxejljusten
Introduce a new library called VirtioLib, for now only collecting the following reusable functions with as little changes as possible: - VirtioWrite() - VirtioRead() - VirtioRingInit() - VirtioRingUninit() - AppendDesc() Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13842 6f19259b-4bc3-4df7-8a09-765794883524
2012-07-23OvmfPkg: introduce QemuFwCfgFindFile ()jljusten
Tested with the "bootorder" fw_cfg file. Example contents (leading space added and line terminators transcribed for readability): /pci@i0cf8/ide@1,1/drive@0/disk@0<LF> /pci@i0cf8/ide@1,1/drive@1/disk@0<LF> /pci@i0cf8/ethernet@3/ethernet-phy@0<NUL> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13549 6f19259b-4bc3-4df7-8a09-765794883524
2012-05-30OvmfPkg: Add QemuFwCfgLib library class and implementationjljusten
QEMU's Firmware Configuration interface gives the firmware access to various types of information. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13383 6f19259b-4bc3-4df7-8a09-765794883524
2011-01-30OvmfPkg: Add SerializeVariablesLib library classjljusten
This library provides an interface for converting the system variables into a binary and also restoring the system variables from that binary. git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11284 6f19259b-4bc3-4df7-8a09-765794883524
2011-01-09OvmfPkg EMU FVB: Add 2 functions to PlatformFvbLibjljusten
Add PlatformFvbDataRead and PlatformFvbBlocksErased functions. git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11241 6f19259b-4bc3-4df7-8a09-765794883524
2011-01-09OvmfPkg EMU FVB: Convert to FVB2 protocoljljusten
Convert from using EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL to EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL. git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11240 6f19259b-4bc3-4df7-8a09-765794883524
2011-01-09OvmfPkg PlatformFvbLib: Change PlatformFvbDataWrittenjljusten
The new parameters closely match the EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL Write function parameters. git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11239 6f19259b-4bc3-4df7-8a09-765794883524
2010-04-28Update the copyright notice formathhtian
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10439 6f19259b-4bc3-4df7-8a09-765794883524
2009-09-26OVMF: Add support for saving the NV variables to disk following each ↵jljusten
SetVariable call. Note: * This only works before ExitBootServices * For OVMF, variables are only preserved on the disk if there is a hard disk connected which has a writeable FAT file system. The Ovmf/Library/EmuVariableFvbLib library will look for the gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent PCD to be set to a non-zero value. If set, it is treated as an event handle, and each write to the EmuVariableFvb will cause the event to be signaled. In this change, the OVMF platform BDS library sets up this event, and sets the PCD so that after each write to the EMU Variable FVB, the non-volatile variables will be saved out to the file system. The end result is that NV variables that are written prior to the ExitBootServices call should be preserved by storing them on the disk. git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9318 6f19259b-4bc3-4df7-8a09-765794883524
2009-09-26Add PlatformFvbLib to allow platform customization of an FVB driver.jljusten
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9313 6f19259b-4bc3-4df7-8a09-765794883524
2009-09-16Implement NvVarsFileLib to save and restore non-volatile variables using a file.jljusten
This library provides an interface where variables can be saved and restored using a file in a file system accessible to the firmware. It is expected that a platform BDS library will use this library. The platform BDS implementation can decide which devices to connect and then to attempt to use for saving and restoring NV variables. git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9272 6f19259b-4bc3-4df7-8a09-765794883524
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-20 15:05:34 +0000