2013-11-12 19:34:52 +01:00
|
|
|
/**@file
|
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Copyright (c) 2006, Intel Corporation. All rights reserved.<BR>
|
2015-10-26 15:58:01 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
This program and the accompanying materials are licensed and made available
|
|
|
|
under the terms and conditions of the BSD License which accompanies this
|
|
|
|
distribution. The full text of the license may be found at
|
|
|
|
http://opensource.org/licenses/bsd-license.php
|
2013-11-12 19:34:52 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
|
|
|
|
WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
|
2013-11-12 19:34:52 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Module Name:
|
2015-10-26 15:58:01 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
FwBlockService.h
|
2013-11-12 19:34:52 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Abstract:
|
|
|
|
|
|
|
|
Firmware volume block driver for Intel Firmware Hub (FWH) device
|
2013-11-12 19:34:52 +01:00
|
|
|
|
|
|
|
**/
|
|
|
|
|
|
|
|
#ifndef _FW_BLOCK_SERVICE_H
|
|
|
|
#define _FW_BLOCK_SERVICE_H
|
|
|
|
|
|
|
|
typedef struct {
|
OvmfPkg: QemuFlashFvbServicesRuntimeDxe: no dual addressing needed
Currently the EFI_FW_VOL_INSTANCE and ESAL_FWB_GLOBAL structures declare
the following entries as arrays, with two entries each:
- EFI_FW_VOL_INSTANCE.FvBase[2]
- ESAL_FWB_GLOBAL.FvInstance[2]
In every case, the entry at subscript zero is meant as "physical address",
while the entry at subscript one is meant as "virtual address" -- a
pointer to the same object. The virtual address entry is originally
initialized to the physical address, and then it is converted to the
virtual mapping in FvbVirtualddressChangeEvent().
Functions that (a) read the listed fields and (b) run both before and
after the virtual address change event -- since this is a runtime DXE
driver -- derive the correct array subscript by calling the
EfiGoneVirtual() function from UefiRuntimeLib.
The problem with the above infrastructure is that it's entirely
superfluous.
EfiGoneVirtual() "knows" whether EFI has gone virtual only because the
UefiRuntimeLib constructor registers the exact same kind of virtual
address change callback, and the callback flips a static variabe to TRUE,
and EfiGoneVirtual() queries that static variable.
In effect this means for QemuFlashFvbServicesRuntimeDxe: "when there is a
virtual address change, convert the entries with subscript one from
physical to virtual, and from then on use the entries with subscript one".
This would only make sense if QemuFlashFvbServicesRuntimeDxe ever needed
the original (physical) addresses (ie. the entries with subscript zero)
after the virtual address change, but that is not the case.
Replace the arrays with single elements. The subscript zero elements
simply disappear, and the single elements take the role of the prior
subscript one elements.
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@18670 6f19259b-4bc3-4df7-8a09-765794883524
2015-10-26 15:58:33 +01:00
|
|
|
UINTN FvBase;
|
2013-11-12 19:34:52 +01:00
|
|
|
UINTN NumOfBlocks;
|
|
|
|
EFI_FIRMWARE_VOLUME_HEADER VolumeHeader;
|
|
|
|
} EFI_FW_VOL_INSTANCE;
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
UINT32 NumFv;
|
OvmfPkg: QemuFlashFvbServicesRuntimeDxe: no dual addressing needed
Currently the EFI_FW_VOL_INSTANCE and ESAL_FWB_GLOBAL structures declare
the following entries as arrays, with two entries each:
- EFI_FW_VOL_INSTANCE.FvBase[2]
- ESAL_FWB_GLOBAL.FvInstance[2]
In every case, the entry at subscript zero is meant as "physical address",
while the entry at subscript one is meant as "virtual address" -- a
pointer to the same object. The virtual address entry is originally
initialized to the physical address, and then it is converted to the
virtual mapping in FvbVirtualddressChangeEvent().
Functions that (a) read the listed fields and (b) run both before and
after the virtual address change event -- since this is a runtime DXE
driver -- derive the correct array subscript by calling the
EfiGoneVirtual() function from UefiRuntimeLib.
The problem with the above infrastructure is that it's entirely
superfluous.
EfiGoneVirtual() "knows" whether EFI has gone virtual only because the
UefiRuntimeLib constructor registers the exact same kind of virtual
address change callback, and the callback flips a static variabe to TRUE,
and EfiGoneVirtual() queries that static variable.
In effect this means for QemuFlashFvbServicesRuntimeDxe: "when there is a
virtual address change, convert the entries with subscript one from
physical to virtual, and from then on use the entries with subscript one".
This would only make sense if QemuFlashFvbServicesRuntimeDxe ever needed
the original (physical) addresses (ie. the entries with subscript zero)
after the virtual address change, but that is not the case.
Replace the arrays with single elements. The subscript zero elements
simply disappear, and the single elements take the role of the prior
subscript one elements.
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@18670 6f19259b-4bc3-4df7-8a09-765794883524
2015-10-26 15:58:33 +01:00
|
|
|
EFI_FW_VOL_INSTANCE *FvInstance;
|
2013-11-12 19:34:52 +01:00
|
|
|
} ESAL_FWB_GLOBAL;
|
|
|
|
|
2015-10-26 15:58:39 +01:00
|
|
|
extern ESAL_FWB_GLOBAL *mFvbModuleGlobal;
|
|
|
|
|
2013-11-12 19:34:52 +01:00
|
|
|
//
|
|
|
|
// Fvb Protocol instance data
|
|
|
|
//
|
2015-10-26 15:58:08 +01:00
|
|
|
#define FVB_DEVICE_FROM_THIS(a) CR (a, EFI_FW_VOL_BLOCK_DEVICE, \
|
|
|
|
FwVolBlockInstance, FVB_DEVICE_SIGNATURE)
|
|
|
|
|
|
|
|
#define FVB_EXTEND_DEVICE_FROM_THIS(a) CR (a, EFI_FW_VOL_BLOCK_DEVICE, \
|
|
|
|
FvbExtension, FVB_DEVICE_SIGNATURE)
|
|
|
|
|
2013-11-12 19:34:52 +01:00
|
|
|
#define FVB_DEVICE_SIGNATURE SIGNATURE_32 ('F', 'V', 'B', 'N')
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
MEDIA_FW_VOL_DEVICE_PATH FvDevPath;
|
|
|
|
EFI_DEVICE_PATH_PROTOCOL EndDevPath;
|
|
|
|
} FV_PIWG_DEVICE_PATH;
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
MEMMAP_DEVICE_PATH MemMapDevPath;
|
|
|
|
EFI_DEVICE_PATH_PROTOCOL EndDevPath;
|
|
|
|
} FV_MEMMAP_DEVICE_PATH;
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
UINTN Signature;
|
|
|
|
EFI_DEVICE_PATH_PROTOCOL *DevicePath;
|
|
|
|
UINTN Instance;
|
|
|
|
EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL FwVolBlockInstance;
|
|
|
|
} EFI_FW_VOL_BLOCK_DEVICE;
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
GetFvbInfo (
|
|
|
|
IN UINT64 FvLength,
|
|
|
|
OUT EFI_FIRMWARE_VOLUME_HEADER **FvbInfo
|
|
|
|
);
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
FvbSetVolumeAttributes (
|
|
|
|
IN UINTN Instance,
|
|
|
|
IN OUT EFI_FVB_ATTRIBUTES_2 *Attributes,
|
OvmfPkg: QemuFlashFvbServicesRuntimeDxe: no dual addressing needed
Currently the EFI_FW_VOL_INSTANCE and ESAL_FWB_GLOBAL structures declare
the following entries as arrays, with two entries each:
- EFI_FW_VOL_INSTANCE.FvBase[2]
- ESAL_FWB_GLOBAL.FvInstance[2]
In every case, the entry at subscript zero is meant as "physical address",
while the entry at subscript one is meant as "virtual address" -- a
pointer to the same object. The virtual address entry is originally
initialized to the physical address, and then it is converted to the
virtual mapping in FvbVirtualddressChangeEvent().
Functions that (a) read the listed fields and (b) run both before and
after the virtual address change event -- since this is a runtime DXE
driver -- derive the correct array subscript by calling the
EfiGoneVirtual() function from UefiRuntimeLib.
The problem with the above infrastructure is that it's entirely
superfluous.
EfiGoneVirtual() "knows" whether EFI has gone virtual only because the
UefiRuntimeLib constructor registers the exact same kind of virtual
address change callback, and the callback flips a static variabe to TRUE,
and EfiGoneVirtual() queries that static variable.
In effect this means for QemuFlashFvbServicesRuntimeDxe: "when there is a
virtual address change, convert the entries with subscript one from
physical to virtual, and from then on use the entries with subscript one".
This would only make sense if QemuFlashFvbServicesRuntimeDxe ever needed
the original (physical) addresses (ie. the entries with subscript zero)
after the virtual address change, but that is not the case.
Replace the arrays with single elements. The subscript zero elements
simply disappear, and the single elements take the role of the prior
subscript one elements.
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@18670 6f19259b-4bc3-4df7-8a09-765794883524
2015-10-26 15:58:33 +01:00
|
|
|
IN ESAL_FWB_GLOBAL *Global
|
2013-11-12 19:34:52 +01:00
|
|
|
);
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
FvbGetVolumeAttributes (
|
|
|
|
IN UINTN Instance,
|
|
|
|
OUT EFI_FVB_ATTRIBUTES_2 *Attributes,
|
OvmfPkg: QemuFlashFvbServicesRuntimeDxe: no dual addressing needed
Currently the EFI_FW_VOL_INSTANCE and ESAL_FWB_GLOBAL structures declare
the following entries as arrays, with two entries each:
- EFI_FW_VOL_INSTANCE.FvBase[2]
- ESAL_FWB_GLOBAL.FvInstance[2]
In every case, the entry at subscript zero is meant as "physical address",
while the entry at subscript one is meant as "virtual address" -- a
pointer to the same object. The virtual address entry is originally
initialized to the physical address, and then it is converted to the
virtual mapping in FvbVirtualddressChangeEvent().
Functions that (a) read the listed fields and (b) run both before and
after the virtual address change event -- since this is a runtime DXE
driver -- derive the correct array subscript by calling the
EfiGoneVirtual() function from UefiRuntimeLib.
The problem with the above infrastructure is that it's entirely
superfluous.
EfiGoneVirtual() "knows" whether EFI has gone virtual only because the
UefiRuntimeLib constructor registers the exact same kind of virtual
address change callback, and the callback flips a static variabe to TRUE,
and EfiGoneVirtual() queries that static variable.
In effect this means for QemuFlashFvbServicesRuntimeDxe: "when there is a
virtual address change, convert the entries with subscript one from
physical to virtual, and from then on use the entries with subscript one".
This would only make sense if QemuFlashFvbServicesRuntimeDxe ever needed
the original (physical) addresses (ie. the entries with subscript zero)
after the virtual address change, but that is not the case.
Replace the arrays with single elements. The subscript zero elements
simply disappear, and the single elements take the role of the prior
subscript one elements.
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@18670 6f19259b-4bc3-4df7-8a09-765794883524
2015-10-26 15:58:33 +01:00
|
|
|
IN ESAL_FWB_GLOBAL *Global
|
2013-11-12 19:34:52 +01:00
|
|
|
);
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
FvbGetPhysicalAddress (
|
|
|
|
IN UINTN Instance,
|
|
|
|
OUT EFI_PHYSICAL_ADDRESS *Address,
|
OvmfPkg: QemuFlashFvbServicesRuntimeDxe: no dual addressing needed
Currently the EFI_FW_VOL_INSTANCE and ESAL_FWB_GLOBAL structures declare
the following entries as arrays, with two entries each:
- EFI_FW_VOL_INSTANCE.FvBase[2]
- ESAL_FWB_GLOBAL.FvInstance[2]
In every case, the entry at subscript zero is meant as "physical address",
while the entry at subscript one is meant as "virtual address" -- a
pointer to the same object. The virtual address entry is originally
initialized to the physical address, and then it is converted to the
virtual mapping in FvbVirtualddressChangeEvent().
Functions that (a) read the listed fields and (b) run both before and
after the virtual address change event -- since this is a runtime DXE
driver -- derive the correct array subscript by calling the
EfiGoneVirtual() function from UefiRuntimeLib.
The problem with the above infrastructure is that it's entirely
superfluous.
EfiGoneVirtual() "knows" whether EFI has gone virtual only because the
UefiRuntimeLib constructor registers the exact same kind of virtual
address change callback, and the callback flips a static variabe to TRUE,
and EfiGoneVirtual() queries that static variable.
In effect this means for QemuFlashFvbServicesRuntimeDxe: "when there is a
virtual address change, convert the entries with subscript one from
physical to virtual, and from then on use the entries with subscript one".
This would only make sense if QemuFlashFvbServicesRuntimeDxe ever needed
the original (physical) addresses (ie. the entries with subscript zero)
after the virtual address change, but that is not the case.
Replace the arrays with single elements. The subscript zero elements
simply disappear, and the single elements take the role of the prior
subscript one elements.
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@18670 6f19259b-4bc3-4df7-8a09-765794883524
2015-10-26 15:58:33 +01:00
|
|
|
IN ESAL_FWB_GLOBAL *Global
|
2013-11-12 19:34:52 +01:00
|
|
|
);
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
FvbInitialize (
|
|
|
|
IN EFI_HANDLE ImageHandle,
|
|
|
|
IN EFI_SYSTEM_TABLE *SystemTable
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
|
|
VOID
|
|
|
|
EFIAPI
|
|
|
|
FvbClassAddressChangeEvent (
|
|
|
|
IN EFI_EVENT Event,
|
|
|
|
IN VOID *Context
|
|
|
|
);
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
FvbGetLbaAddress (
|
|
|
|
IN UINTN Instance,
|
|
|
|
IN EFI_LBA Lba,
|
|
|
|
OUT UINTN *LbaAddress,
|
|
|
|
OUT UINTN *LbaLength,
|
|
|
|
OUT UINTN *NumOfBlocks,
|
OvmfPkg: QemuFlashFvbServicesRuntimeDxe: no dual addressing needed
Currently the EFI_FW_VOL_INSTANCE and ESAL_FWB_GLOBAL structures declare
the following entries as arrays, with two entries each:
- EFI_FW_VOL_INSTANCE.FvBase[2]
- ESAL_FWB_GLOBAL.FvInstance[2]
In every case, the entry at subscript zero is meant as "physical address",
while the entry at subscript one is meant as "virtual address" -- a
pointer to the same object. The virtual address entry is originally
initialized to the physical address, and then it is converted to the
virtual mapping in FvbVirtualddressChangeEvent().
Functions that (a) read the listed fields and (b) run both before and
after the virtual address change event -- since this is a runtime DXE
driver -- derive the correct array subscript by calling the
EfiGoneVirtual() function from UefiRuntimeLib.
The problem with the above infrastructure is that it's entirely
superfluous.
EfiGoneVirtual() "knows" whether EFI has gone virtual only because the
UefiRuntimeLib constructor registers the exact same kind of virtual
address change callback, and the callback flips a static variabe to TRUE,
and EfiGoneVirtual() queries that static variable.
In effect this means for QemuFlashFvbServicesRuntimeDxe: "when there is a
virtual address change, convert the entries with subscript one from
physical to virtual, and from then on use the entries with subscript one".
This would only make sense if QemuFlashFvbServicesRuntimeDxe ever needed
the original (physical) addresses (ie. the entries with subscript zero)
after the virtual address change, but that is not the case.
Replace the arrays with single elements. The subscript zero elements
simply disappear, and the single elements take the role of the prior
subscript one elements.
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@18670 6f19259b-4bc3-4df7-8a09-765794883524
2015-10-26 15:58:33 +01:00
|
|
|
IN ESAL_FWB_GLOBAL *Global
|
2013-11-12 19:34:52 +01:00
|
|
|
);
|
|
|
|
|
|
|
|
//
|
|
|
|
// Protocol APIs
|
|
|
|
//
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
FvbProtocolGetAttributes (
|
|
|
|
IN CONST EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL *This,
|
|
|
|
OUT EFI_FVB_ATTRIBUTES_2 *Attributes
|
|
|
|
);
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
FvbProtocolSetAttributes (
|
|
|
|
IN CONST EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL *This,
|
|
|
|
IN OUT EFI_FVB_ATTRIBUTES_2 *Attributes
|
|
|
|
);
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
FvbProtocolGetPhysicalAddress (
|
|
|
|
IN CONST EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL *This,
|
|
|
|
OUT EFI_PHYSICAL_ADDRESS *Address
|
|
|
|
);
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
FvbProtocolGetBlockSize (
|
|
|
|
IN CONST EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL *This,
|
|
|
|
IN CONST EFI_LBA Lba,
|
|
|
|
OUT UINTN *BlockSize,
|
|
|
|
OUT UINTN *NumOfBlocks
|
|
|
|
);
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
FvbProtocolRead (
|
|
|
|
IN CONST EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL *This,
|
|
|
|
IN CONST EFI_LBA Lba,
|
|
|
|
IN CONST UINTN Offset,
|
|
|
|
IN OUT UINTN *NumBytes,
|
|
|
|
IN UINT8 *Buffer
|
|
|
|
);
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
FvbProtocolWrite (
|
|
|
|
IN CONST EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL *This,
|
|
|
|
IN EFI_LBA Lba,
|
|
|
|
IN UINTN Offset,
|
|
|
|
IN OUT UINTN *NumBytes,
|
|
|
|
IN UINT8 *Buffer
|
|
|
|
);
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
FvbProtocolEraseBlocks (
|
|
|
|
IN CONST EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL *This,
|
|
|
|
...
|
|
|
|
);
|
|
|
|
|
2015-10-26 15:58:39 +01:00
|
|
|
//
|
|
|
|
// The following functions have different implementations dependent on the
|
|
|
|
// module type chosen for building this driver.
|
|
|
|
//
|
|
|
|
VOID
|
|
|
|
InstallProtocolInterfaces (
|
|
|
|
IN EFI_FW_VOL_BLOCK_DEVICE *FvbDevice
|
|
|
|
);
|
|
|
|
|
|
|
|
VOID
|
|
|
|
InstallVirtualAddressChangeHandler (
|
|
|
|
VOID
|
|
|
|
);
|
2018-07-06 17:00:41 +02:00
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
MarkIoMemoryRangeForRuntimeAccess (
|
|
|
|
IN EFI_PHYSICAL_ADDRESS BaseAddress,
|
|
|
|
IN UINTN Length
|
|
|
|
);
|
|
|
|
|
2013-11-12 19:34:52 +01:00
|
|
|
#endif
|