audk/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h

200 lines
5.3 KiB
C
Raw Normal View History

/**@file
Copyright (c) 2006, Intel Corporation. All rights reserved.<BR>
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
THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
Module Name:
FwBlockService.h
Abstract:
Firmware volume block driver for Intel Firmware Hub (FWH) device
**/
#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;
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;
} ESAL_FWB_GLOBAL;
extern ESAL_FWB_GLOBAL *mFvbModuleGlobal;
//
// Fvb Protocol instance data
//
#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)
#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
);
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
);
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
);
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
);
//
// 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,
...
);
//
// 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
);
EFI_STATUS
MarkIoMemoryRangeForRuntimeAccess (
IN EFI_PHYSICAL_ADDRESS BaseAddress,
IN UINTN Length
);
#endif