2013-11-12 19:34:52 +01:00
|
|
|
/**@file
|
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.<BR>
|
2013-11-12 19:34:52 +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:
|
2013-11-12 19:34:52 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
FWBlockService.c
|
2013-11-12 19:34:52 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Abstract:
|
|
|
|
|
|
|
|
Revision History
|
2013-11-12 19:34:52 +01:00
|
|
|
|
|
|
|
**/
|
|
|
|
|
|
|
|
//
|
|
|
|
// The protocols, PPI and GUID defintions for this module
|
|
|
|
//
|
|
|
|
#include <Protocol/DevicePath.h>
|
2015-10-26 15:58:46 +01:00
|
|
|
#include <Protocol/FirmwareVolumeBlock.h>
|
2013-11-12 19:34:52 +01:00
|
|
|
|
|
|
|
//
|
|
|
|
// The Library classes this module consumes
|
|
|
|
//
|
|
|
|
#include <Library/BaseLib.h>
|
|
|
|
#include <Library/BaseMemoryLib.h>
|
2015-10-26 15:58:46 +01:00
|
|
|
#include <Library/DebugLib.h>
|
|
|
|
#include <Library/DevicePathLib.h>
|
|
|
|
#include <Library/DxeServicesTableLib.h>
|
2013-11-12 19:34:52 +01:00
|
|
|
#include <Library/MemoryAllocationLib.h>
|
|
|
|
#include <Library/UefiBootServicesTableLib.h>
|
|
|
|
|
|
|
|
#include "FwBlockService.h"
|
|
|
|
#include "QemuFlash.h"
|
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
#define EFI_FVB2_STATUS \
|
|
|
|
(EFI_FVB2_READ_STATUS | EFI_FVB2_WRITE_STATUS | EFI_FVB2_LOCK_STATUS)
|
2013-11-12 19:34:52 +01:00
|
|
|
|
|
|
|
ESAL_FWB_GLOBAL *mFvbModuleGlobal;
|
|
|
|
|
|
|
|
FV_MEMMAP_DEVICE_PATH mFvMemmapDevicePathTemplate = {
|
|
|
|
{
|
|
|
|
{
|
|
|
|
HARDWARE_DEVICE_PATH,
|
|
|
|
HW_MEMMAP_DP,
|
|
|
|
{
|
|
|
|
(UINT8)(sizeof (MEMMAP_DEVICE_PATH)),
|
|
|
|
(UINT8)(sizeof (MEMMAP_DEVICE_PATH) >> 8)
|
|
|
|
}
|
|
|
|
},
|
|
|
|
EfiMemoryMappedIO,
|
|
|
|
(EFI_PHYSICAL_ADDRESS) 0,
|
|
|
|
(EFI_PHYSICAL_ADDRESS) 0,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
END_DEVICE_PATH_TYPE,
|
|
|
|
END_ENTIRE_DEVICE_PATH_SUBTYPE,
|
|
|
|
{
|
|
|
|
END_DEVICE_PATH_LENGTH,
|
|
|
|
0
|
|
|
|
}
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
FV_PIWG_DEVICE_PATH mFvPIWGDevicePathTemplate = {
|
|
|
|
{
|
|
|
|
{
|
|
|
|
MEDIA_DEVICE_PATH,
|
|
|
|
MEDIA_PIWG_FW_VOL_DP,
|
|
|
|
{
|
|
|
|
(UINT8)(sizeof (MEDIA_FW_VOL_DEVICE_PATH)),
|
|
|
|
(UINT8)(sizeof (MEDIA_FW_VOL_DEVICE_PATH) >> 8)
|
|
|
|
}
|
|
|
|
},
|
|
|
|
{ 0 }
|
|
|
|
},
|
|
|
|
{
|
|
|
|
END_DEVICE_PATH_TYPE,
|
|
|
|
END_ENTIRE_DEVICE_PATH_SUBTYPE,
|
|
|
|
{
|
|
|
|
END_DEVICE_PATH_LENGTH,
|
|
|
|
0
|
|
|
|
}
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
EFI_FW_VOL_BLOCK_DEVICE mFvbDeviceTemplate = {
|
|
|
|
FVB_DEVICE_SIGNATURE,
|
|
|
|
NULL,
|
|
|
|
0,
|
|
|
|
{
|
|
|
|
FvbProtocolGetAttributes,
|
|
|
|
FvbProtocolSetAttributes,
|
|
|
|
FvbProtocolGetPhysicalAddress,
|
|
|
|
FvbProtocolGetBlockSize,
|
|
|
|
FvbProtocolRead,
|
|
|
|
FvbProtocolWrite,
|
|
|
|
FvbProtocolEraseBlocks,
|
|
|
|
NULL
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
GetFvbInstance (
|
|
|
|
IN UINTN Instance,
|
|
|
|
IN ESAL_FWB_GLOBAL *Global,
|
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
|
|
|
OUT EFI_FW_VOL_INSTANCE **FwhInstance
|
2013-11-12 19:34:52 +01:00
|
|
|
)
|
|
|
|
/*++
|
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Routine Description:
|
|
|
|
Retrieves the physical address of a memory mapped FV
|
2013-11-12 19:34:52 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Arguments:
|
|
|
|
Instance - The FV instance whose base address is going to be
|
|
|
|
returned
|
|
|
|
Global - Pointer to ESAL_FWB_GLOBAL that contains all
|
|
|
|
instance data
|
|
|
|
FwhInstance - The EFI_FW_VOL_INSTANCE fimrware instance structure
|
2013-11-12 19:34:52 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Returns:
|
|
|
|
EFI_SUCCESS - Successfully returns
|
|
|
|
EFI_INVALID_PARAMETER - Instance not found
|
2013-11-12 19:34:52 +01:00
|
|
|
|
|
|
|
--*/
|
|
|
|
{
|
|
|
|
EFI_FW_VOL_INSTANCE *FwhRecord;
|
|
|
|
|
2014-06-27 21:15:35 +02:00
|
|
|
*FwhInstance = NULL;
|
2013-11-12 19:34:52 +01:00
|
|
|
if (Instance >= Global->NumFv) {
|
|
|
|
return EFI_INVALID_PARAMETER;
|
|
|
|
}
|
|
|
|
//
|
|
|
|
// Find the right instance of the FVB private data
|
|
|
|
//
|
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
|
|
|
FwhRecord = Global->FvInstance;
|
2013-11-12 19:34:52 +01:00
|
|
|
while (Instance > 0) {
|
|
|
|
FwhRecord = (EFI_FW_VOL_INSTANCE *)
|
|
|
|
(
|
|
|
|
(UINTN) ((UINT8 *) FwhRecord) + FwhRecord->VolumeHeader.HeaderLength +
|
|
|
|
(sizeof (EFI_FW_VOL_INSTANCE) - sizeof (EFI_FIRMWARE_VOLUME_HEADER))
|
|
|
|
);
|
|
|
|
Instance--;
|
|
|
|
}
|
|
|
|
|
|
|
|
*FwhInstance = FwhRecord;
|
|
|
|
|
|
|
|
return EFI_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
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
|
|
|
)
|
|
|
|
/*++
|
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Routine Description:
|
|
|
|
Retrieves the physical address of a memory mapped FV
|
2013-11-12 19:34:52 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Arguments:
|
|
|
|
Instance - The FV instance whose base address is going to be
|
|
|
|
returned
|
|
|
|
Address - Pointer to a caller allocated EFI_PHYSICAL_ADDRESS
|
|
|
|
that on successful return, contains the base
|
|
|
|
address of the firmware volume.
|
|
|
|
Global - Pointer to ESAL_FWB_GLOBAL that contains all
|
|
|
|
instance data
|
2013-11-12 19:34:52 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Returns:
|
|
|
|
EFI_SUCCESS - Successfully returns
|
|
|
|
EFI_INVALID_PARAMETER - Instance not found
|
2013-11-12 19:34:52 +01:00
|
|
|
|
|
|
|
--*/
|
|
|
|
{
|
|
|
|
EFI_FW_VOL_INSTANCE *FwhInstance;
|
|
|
|
EFI_STATUS Status;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Find the right instance of the FVB private data
|
|
|
|
//
|
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
|
|
|
Status = GetFvbInstance (Instance, Global, &FwhInstance);
|
2013-11-12 19:34:52 +01:00
|
|
|
ASSERT_EFI_ERROR (Status);
|
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
|
|
|
*Address = FwhInstance->FvBase;
|
2013-11-12 19:34:52 +01:00
|
|
|
|
|
|
|
return EFI_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
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
|
|
|
)
|
|
|
|
/*++
|
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Routine Description:
|
|
|
|
Retrieves attributes, insures positive polarity of attribute bits, returns
|
|
|
|
resulting attributes in output parameter
|
2013-11-12 19:34:52 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Arguments:
|
|
|
|
Instance - The FV instance whose attributes is going to be
|
|
|
|
returned
|
|
|
|
Attributes - Output buffer which contains attributes
|
|
|
|
Global - Pointer to ESAL_FWB_GLOBAL that contains all
|
|
|
|
instance data
|
2013-11-12 19:34:52 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Returns:
|
|
|
|
EFI_SUCCESS - Successfully returns
|
|
|
|
EFI_INVALID_PARAMETER - Instance not found
|
2013-11-12 19:34:52 +01:00
|
|
|
|
|
|
|
--*/
|
|
|
|
{
|
|
|
|
EFI_FW_VOL_INSTANCE *FwhInstance;
|
|
|
|
EFI_STATUS Status;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Find the right instance of the FVB private data
|
|
|
|
//
|
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
|
|
|
Status = GetFvbInstance (Instance, Global, &FwhInstance);
|
2013-11-12 19:34:52 +01:00
|
|
|
ASSERT_EFI_ERROR (Status);
|
|
|
|
*Attributes = FwhInstance->VolumeHeader.Attributes;
|
|
|
|
|
|
|
|
return EFI_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
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
|
|
|
)
|
|
|
|
/*++
|
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Routine Description:
|
|
|
|
Retrieves the starting address of an LBA in an FV
|
|
|
|
|
|
|
|
Arguments:
|
|
|
|
Instance - The FV instance which the Lba belongs to
|
|
|
|
Lba - The logical block address
|
|
|
|
LbaAddress - On output, contains the physical starting address
|
|
|
|
of the Lba
|
|
|
|
LbaLength - On output, contains the length of the block
|
|
|
|
NumOfBlocks - A pointer to a caller allocated UINTN in which the
|
|
|
|
number of consecutive blocks starting with Lba is
|
|
|
|
returned. All blocks in this range have a size of
|
|
|
|
BlockSize
|
|
|
|
Global - Pointer to ESAL_FWB_GLOBAL that contains all
|
|
|
|
instance data
|
|
|
|
|
|
|
|
Returns:
|
|
|
|
EFI_SUCCESS - Successfully returns
|
|
|
|
EFI_INVALID_PARAMETER - Instance not found
|
2013-11-12 19:34:52 +01:00
|
|
|
|
|
|
|
--*/
|
|
|
|
{
|
|
|
|
UINT32 NumBlocks;
|
|
|
|
UINT32 BlockLength;
|
|
|
|
UINTN Offset;
|
|
|
|
EFI_LBA StartLba;
|
|
|
|
EFI_LBA NextLba;
|
|
|
|
EFI_FW_VOL_INSTANCE *FwhInstance;
|
|
|
|
EFI_FV_BLOCK_MAP_ENTRY *BlockMap;
|
|
|
|
EFI_STATUS Status;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Find the right instance of the FVB private data
|
|
|
|
//
|
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
|
|
|
Status = GetFvbInstance (Instance, Global, &FwhInstance);
|
2013-11-12 19:34:52 +01:00
|
|
|
ASSERT_EFI_ERROR (Status);
|
|
|
|
|
|
|
|
StartLba = 0;
|
|
|
|
Offset = 0;
|
|
|
|
BlockMap = &(FwhInstance->VolumeHeader.BlockMap[0]);
|
|
|
|
|
|
|
|
//
|
|
|
|
// Parse the blockmap of the FV to find which map entry the Lba belongs to
|
|
|
|
//
|
|
|
|
while (TRUE) {
|
|
|
|
NumBlocks = BlockMap->NumBlocks;
|
|
|
|
BlockLength = BlockMap->Length;
|
|
|
|
|
|
|
|
if (NumBlocks == 0 || BlockLength == 0) {
|
|
|
|
return EFI_INVALID_PARAMETER;
|
|
|
|
}
|
|
|
|
|
|
|
|
NextLba = StartLba + NumBlocks;
|
|
|
|
|
|
|
|
//
|
|
|
|
// The map entry found
|
|
|
|
//
|
|
|
|
if (Lba >= StartLba && Lba < NextLba) {
|
|
|
|
Offset = Offset + (UINTN) MultU64x32 ((Lba - StartLba), BlockLength);
|
|
|
|
if (LbaAddress != NULL) {
|
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
|
|
|
*LbaAddress = FwhInstance->FvBase + Offset;
|
2013-11-12 19:34:52 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
if (LbaLength != NULL) {
|
|
|
|
*LbaLength = BlockLength;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (NumOfBlocks != NULL) {
|
|
|
|
*NumOfBlocks = (UINTN) (NextLba - Lba);
|
|
|
|
}
|
|
|
|
|
|
|
|
return EFI_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
StartLba = NextLba;
|
|
|
|
Offset = Offset + NumBlocks * BlockLength;
|
|
|
|
BlockMap++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
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
|
|
|
)
|
|
|
|
/*++
|
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Routine Description:
|
|
|
|
Modifies the current settings of the firmware volume according to the
|
|
|
|
input parameter, and returns the new setting of the volume
|
|
|
|
|
|
|
|
Arguments:
|
|
|
|
Instance - The FV instance whose attributes is going to be
|
|
|
|
modified
|
|
|
|
Attributes - On input, it is a pointer to EFI_FVB_ATTRIBUTES_2
|
|
|
|
containing the desired firmware volume settings.
|
|
|
|
On successful return, it contains the new settings
|
|
|
|
of the firmware volume
|
|
|
|
Global - Pointer to ESAL_FWB_GLOBAL that contains all
|
|
|
|
instance data
|
|
|
|
|
|
|
|
Returns:
|
|
|
|
EFI_SUCCESS - Successfully returns
|
|
|
|
EFI_ACCESS_DENIED - The volume setting is locked and cannot be modified
|
|
|
|
EFI_INVALID_PARAMETER - Instance not found, or The attributes requested are
|
|
|
|
in conflict with the capabilities as declared in
|
|
|
|
the firmware volume header
|
2013-11-12 19:34:52 +01:00
|
|
|
|
|
|
|
--*/
|
|
|
|
{
|
|
|
|
EFI_FW_VOL_INSTANCE *FwhInstance;
|
|
|
|
EFI_FVB_ATTRIBUTES_2 OldAttributes;
|
|
|
|
EFI_FVB_ATTRIBUTES_2 *AttribPtr;
|
|
|
|
UINT32 Capabilities;
|
|
|
|
UINT32 OldStatus;
|
|
|
|
UINT32 NewStatus;
|
|
|
|
EFI_STATUS Status;
|
|
|
|
EFI_FVB_ATTRIBUTES_2 UnchangedAttributes;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Find the right instance of the FVB private data
|
|
|
|
//
|
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
|
|
|
Status = GetFvbInstance (Instance, Global, &FwhInstance);
|
2013-11-12 19:34:52 +01:00
|
|
|
ASSERT_EFI_ERROR (Status);
|
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
AttribPtr =
|
|
|
|
(EFI_FVB_ATTRIBUTES_2 *) &(FwhInstance->VolumeHeader.Attributes);
|
2013-11-12 19:34:52 +01:00
|
|
|
OldAttributes = *AttribPtr;
|
|
|
|
Capabilities = OldAttributes & (EFI_FVB2_READ_DISABLED_CAP | \
|
|
|
|
EFI_FVB2_READ_ENABLED_CAP | \
|
|
|
|
EFI_FVB2_WRITE_DISABLED_CAP | \
|
|
|
|
EFI_FVB2_WRITE_ENABLED_CAP | \
|
|
|
|
EFI_FVB2_LOCK_CAP \
|
|
|
|
);
|
|
|
|
OldStatus = OldAttributes & EFI_FVB2_STATUS;
|
|
|
|
NewStatus = *Attributes & EFI_FVB2_STATUS;
|
|
|
|
|
|
|
|
UnchangedAttributes = EFI_FVB2_READ_DISABLED_CAP | \
|
|
|
|
EFI_FVB2_READ_ENABLED_CAP | \
|
|
|
|
EFI_FVB2_WRITE_DISABLED_CAP | \
|
|
|
|
EFI_FVB2_WRITE_ENABLED_CAP | \
|
|
|
|
EFI_FVB2_LOCK_CAP | \
|
|
|
|
EFI_FVB2_STICKY_WRITE | \
|
|
|
|
EFI_FVB2_MEMORY_MAPPED | \
|
|
|
|
EFI_FVB2_ERASE_POLARITY | \
|
|
|
|
EFI_FVB2_READ_LOCK_CAP | \
|
|
|
|
EFI_FVB2_WRITE_LOCK_CAP | \
|
|
|
|
EFI_FVB2_ALIGNMENT;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Some attributes of FV is read only can *not* be set
|
|
|
|
//
|
2015-10-26 15:58:08 +01:00
|
|
|
if ((OldAttributes & UnchangedAttributes) ^
|
|
|
|
(*Attributes & UnchangedAttributes)) {
|
2013-11-12 19:34:52 +01:00
|
|
|
return EFI_INVALID_PARAMETER;
|
|
|
|
}
|
|
|
|
//
|
|
|
|
// If firmware volume is locked, no status bit can be updated
|
|
|
|
//
|
|
|
|
if (OldAttributes & EFI_FVB2_LOCK_STATUS) {
|
|
|
|
if (OldStatus ^ NewStatus) {
|
|
|
|
return EFI_ACCESS_DENIED;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
//
|
|
|
|
// Test read disable
|
|
|
|
//
|
|
|
|
if ((Capabilities & EFI_FVB2_READ_DISABLED_CAP) == 0) {
|
|
|
|
if ((NewStatus & EFI_FVB2_READ_STATUS) == 0) {
|
|
|
|
return EFI_INVALID_PARAMETER;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
//
|
|
|
|
// Test read enable
|
|
|
|
//
|
|
|
|
if ((Capabilities & EFI_FVB2_READ_ENABLED_CAP) == 0) {
|
|
|
|
if (NewStatus & EFI_FVB2_READ_STATUS) {
|
|
|
|
return EFI_INVALID_PARAMETER;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
//
|
|
|
|
// Test write disable
|
|
|
|
//
|
|
|
|
if ((Capabilities & EFI_FVB2_WRITE_DISABLED_CAP) == 0) {
|
|
|
|
if ((NewStatus & EFI_FVB2_WRITE_STATUS) == 0) {
|
|
|
|
return EFI_INVALID_PARAMETER;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
//
|
|
|
|
// Test write enable
|
|
|
|
//
|
|
|
|
if ((Capabilities & EFI_FVB2_WRITE_ENABLED_CAP) == 0) {
|
|
|
|
if (NewStatus & EFI_FVB2_WRITE_STATUS) {
|
|
|
|
return EFI_INVALID_PARAMETER;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
//
|
|
|
|
// Test lock
|
|
|
|
//
|
|
|
|
if ((Capabilities & EFI_FVB2_LOCK_CAP) == 0) {
|
|
|
|
if (NewStatus & EFI_FVB2_LOCK_STATUS) {
|
|
|
|
return EFI_INVALID_PARAMETER;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
*AttribPtr = (*AttribPtr) & (0xFFFFFFFF & (~EFI_FVB2_STATUS));
|
|
|
|
*AttribPtr = (*AttribPtr) | NewStatus;
|
|
|
|
*Attributes = *AttribPtr;
|
|
|
|
|
|
|
|
return EFI_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// FVB protocol APIs
|
|
|
|
//
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
FvbProtocolGetPhysicalAddress (
|
|
|
|
IN CONST EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL *This,
|
|
|
|
OUT EFI_PHYSICAL_ADDRESS *Address
|
|
|
|
)
|
|
|
|
/*++
|
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Routine Description:
|
2013-11-12 19:34:52 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Retrieves the physical address of the device.
|
2013-11-12 19:34:52 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Arguments:
|
2013-11-12 19:34:52 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
This - Calling context
|
|
|
|
Address - Output buffer containing the address.
|
2013-11-12 19:34:52 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Returns:
|
|
|
|
EFI_SUCCESS - Successfully returns
|
2013-11-12 19:34:52 +01:00
|
|
|
|
|
|
|
--*/
|
|
|
|
{
|
|
|
|
EFI_FW_VOL_BLOCK_DEVICE *FvbDevice;
|
|
|
|
|
|
|
|
FvbDevice = FVB_DEVICE_FROM_THIS (This);
|
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
return FvbGetPhysicalAddress (FvbDevice->Instance, 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
|
|
|
mFvbModuleGlobal);
|
2013-11-12 19:34:52 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
FvbProtocolGetBlockSize (
|
|
|
|
IN CONST EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL *This,
|
|
|
|
IN CONST EFI_LBA Lba,
|
|
|
|
OUT UINTN *BlockSize,
|
|
|
|
OUT UINTN *NumOfBlocks
|
|
|
|
)
|
|
|
|
/*++
|
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Routine Description:
|
|
|
|
Retrieve the size of a logical block
|
2013-11-12 19:34:52 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Arguments:
|
|
|
|
This - Calling context
|
|
|
|
Lba - Indicates which block to return the size for.
|
|
|
|
BlockSize - A pointer to a caller allocated UINTN in which
|
|
|
|
the size of the block is returned
|
|
|
|
NumOfBlocks - a pointer to a caller allocated UINTN in which the
|
|
|
|
number of consecutive blocks starting with Lba is
|
|
|
|
returned. All blocks in this range have a size of
|
|
|
|
BlockSize
|
2013-11-12 19:34:52 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Returns:
|
|
|
|
EFI_SUCCESS - The firmware volume was read successfully and
|
|
|
|
contents are in Buffer
|
2013-11-12 19:34:52 +01:00
|
|
|
|
|
|
|
--*/
|
|
|
|
{
|
|
|
|
EFI_FW_VOL_BLOCK_DEVICE *FvbDevice;
|
|
|
|
|
|
|
|
FvbDevice = FVB_DEVICE_FROM_THIS (This);
|
|
|
|
|
|
|
|
return FvbGetLbaAddress (
|
|
|
|
FvbDevice->Instance,
|
|
|
|
Lba,
|
|
|
|
NULL,
|
|
|
|
BlockSize,
|
|
|
|
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
|
|
|
mFvbModuleGlobal
|
2013-11-12 19:34:52 +01:00
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
FvbProtocolGetAttributes (
|
|
|
|
IN CONST EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL *This,
|
|
|
|
OUT EFI_FVB_ATTRIBUTES_2 *Attributes
|
|
|
|
)
|
|
|
|
/*++
|
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Routine Description:
|
|
|
|
Retrieves Volume attributes. No polarity translations are done.
|
2013-11-12 19:34:52 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Arguments:
|
|
|
|
This - Calling context
|
|
|
|
Attributes - output buffer which contains attributes
|
2013-11-12 19:34:52 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Returns:
|
|
|
|
EFI_SUCCESS - Successfully returns
|
2013-11-12 19:34:52 +01:00
|
|
|
|
|
|
|
--*/
|
|
|
|
{
|
|
|
|
EFI_FW_VOL_BLOCK_DEVICE *FvbDevice;
|
|
|
|
|
|
|
|
FvbDevice = FVB_DEVICE_FROM_THIS (This);
|
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
return FvbGetVolumeAttributes (FvbDevice->Instance, 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
|
|
|
mFvbModuleGlobal);
|
2013-11-12 19:34:52 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
FvbProtocolSetAttributes (
|
|
|
|
IN CONST EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL *This,
|
|
|
|
IN OUT EFI_FVB_ATTRIBUTES_2 *Attributes
|
|
|
|
)
|
|
|
|
/*++
|
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Routine Description:
|
|
|
|
Sets Volume attributes. No polarity translations are done.
|
2013-11-12 19:34:52 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Arguments:
|
|
|
|
This - Calling context
|
|
|
|
Attributes - output buffer which contains attributes
|
2013-11-12 19:34:52 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Returns:
|
|
|
|
EFI_SUCCESS - Successfully returns
|
2013-11-12 19:34:52 +01:00
|
|
|
|
|
|
|
--*/
|
|
|
|
{
|
|
|
|
EFI_FW_VOL_BLOCK_DEVICE *FvbDevice;
|
|
|
|
|
|
|
|
FvbDevice = FVB_DEVICE_FROM_THIS (This);
|
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
return FvbSetVolumeAttributes (FvbDevice->Instance, 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
|
|
|
mFvbModuleGlobal);
|
2013-11-12 19:34:52 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
FvbProtocolEraseBlocks (
|
|
|
|
IN CONST EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL *This,
|
|
|
|
...
|
|
|
|
)
|
|
|
|
/*++
|
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Routine Description:
|
2013-11-12 19:34:52 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
The EraseBlock() function erases one or more blocks as denoted by the
|
|
|
|
variable argument list. The entire parameter list of blocks must be
|
|
|
|
verified prior to erasing any blocks. If a block is requested that does
|
|
|
|
not exist within the associated firmware volume (it has a larger index than
|
|
|
|
the last block of the firmware volume), the EraseBlock() function must
|
|
|
|
return EFI_INVALID_PARAMETER without modifying the contents of the firmware
|
|
|
|
volume.
|
2013-11-12 19:34:52 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Arguments:
|
|
|
|
This - Calling context
|
|
|
|
... - Starting LBA followed by Number of Lba to erase.
|
|
|
|
a -1 to terminate the list.
|
2013-11-12 19:34:52 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Returns:
|
|
|
|
EFI_SUCCESS - The erase request was successfully completed
|
|
|
|
EFI_ACCESS_DENIED - The firmware volume is in the WriteDisabled state
|
|
|
|
EFI_DEVICE_ERROR - The block device is not functioning correctly and
|
|
|
|
could not be written. Firmware device may have been
|
|
|
|
partially erased
|
2013-11-12 19:34:52 +01:00
|
|
|
|
|
|
|
--*/
|
|
|
|
{
|
|
|
|
EFI_FW_VOL_BLOCK_DEVICE *FvbDevice;
|
|
|
|
EFI_FW_VOL_INSTANCE *FwhInstance;
|
|
|
|
UINTN NumOfBlocks;
|
|
|
|
VA_LIST args;
|
|
|
|
EFI_LBA StartingLba;
|
|
|
|
UINTN NumOfLba;
|
|
|
|
EFI_STATUS Status;
|
|
|
|
|
|
|
|
FvbDevice = FVB_DEVICE_FROM_THIS (This);
|
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Status = GetFvbInstance (FvbDevice->Instance, mFvbModuleGlobal,
|
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
|
|
|
&FwhInstance);
|
2013-11-12 19:34:52 +01:00
|
|
|
ASSERT_EFI_ERROR (Status);
|
|
|
|
|
|
|
|
NumOfBlocks = FwhInstance->NumOfBlocks;
|
|
|
|
|
|
|
|
VA_START (args, This);
|
|
|
|
|
|
|
|
do {
|
|
|
|
StartingLba = VA_ARG (args, EFI_LBA);
|
|
|
|
if (StartingLba == EFI_LBA_LIST_TERMINATOR) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
NumOfLba = VA_ARG (args, UINT32);
|
|
|
|
|
|
|
|
//
|
|
|
|
// Check input parameters
|
|
|
|
//
|
|
|
|
if ((NumOfLba == 0) || ((StartingLba + NumOfLba) > NumOfBlocks)) {
|
|
|
|
VA_END (args);
|
|
|
|
return EFI_INVALID_PARAMETER;
|
|
|
|
}
|
|
|
|
} while (1);
|
|
|
|
|
|
|
|
VA_END (args);
|
|
|
|
|
|
|
|
VA_START (args, This);
|
|
|
|
do {
|
|
|
|
StartingLba = VA_ARG (args, EFI_LBA);
|
|
|
|
if (StartingLba == EFI_LBA_LIST_TERMINATOR) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
NumOfLba = VA_ARG (args, UINT32);
|
|
|
|
|
|
|
|
while (NumOfLba > 0) {
|
|
|
|
Status = QemuFlashEraseBlock (StartingLba);
|
|
|
|
if (EFI_ERROR (Status)) {
|
|
|
|
VA_END (args);
|
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
|
|
|
StartingLba++;
|
|
|
|
NumOfLba--;
|
|
|
|
}
|
|
|
|
|
|
|
|
} while (1);
|
|
|
|
|
|
|
|
VA_END (args);
|
|
|
|
|
|
|
|
return EFI_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
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
|
|
|
|
)
|
|
|
|
/*++
|
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Routine Description:
|
|
|
|
|
|
|
|
Writes data beginning at Lba:Offset from FV. The write terminates either
|
|
|
|
when *NumBytes of data have been written, or when a block boundary is
|
|
|
|
reached. *NumBytes is updated to reflect the actual number of bytes
|
|
|
|
written. The write opertion does not include erase. This routine will
|
|
|
|
attempt to write only the specified bytes. If the writes do not stick,
|
|
|
|
it will return an error.
|
|
|
|
|
|
|
|
Arguments:
|
|
|
|
This - Calling context
|
|
|
|
Lba - Block in which to begin write
|
|
|
|
Offset - Offset in the block at which to begin write
|
|
|
|
NumBytes - On input, indicates the requested write size. On
|
|
|
|
output, indicates the actual number of bytes
|
|
|
|
written
|
|
|
|
Buffer - Buffer containing source data for the write.
|
|
|
|
|
|
|
|
Returns:
|
|
|
|
EFI_SUCCESS - The firmware volume was written successfully
|
|
|
|
EFI_BAD_BUFFER_SIZE - Write attempted across a LBA boundary. On output,
|
|
|
|
NumBytes contains the total number of bytes
|
|
|
|
actually written
|
|
|
|
EFI_ACCESS_DENIED - The firmware volume is in the WriteDisabled state
|
|
|
|
EFI_DEVICE_ERROR - The block device is not functioning correctly and
|
|
|
|
could not be written
|
|
|
|
EFI_INVALID_PARAMETER - NumBytes or Buffer are NULL
|
2013-11-12 19:34:52 +01:00
|
|
|
|
|
|
|
--*/
|
|
|
|
{
|
2015-10-26 15:58:08 +01:00
|
|
|
return QemuFlashWrite ((EFI_LBA)Lba, (UINTN)Offset, NumBytes,
|
|
|
|
(UINT8 *)Buffer);
|
2013-11-12 19:34:52 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
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
|
|
|
|
)
|
|
|
|
/*++
|
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Routine Description:
|
|
|
|
|
|
|
|
Reads data beginning at Lba:Offset from FV. The Read terminates either
|
|
|
|
when *NumBytes of data have been read, or when a block boundary is
|
|
|
|
reached. *NumBytes is updated to reflect the actual number of bytes
|
|
|
|
written. The write opertion does not include erase. This routine will
|
|
|
|
attempt to write only the specified bytes. If the writes do not stick,
|
|
|
|
it will return an error.
|
|
|
|
|
|
|
|
Arguments:
|
|
|
|
This - Calling context
|
|
|
|
Lba - Block in which to begin Read
|
|
|
|
Offset - Offset in the block at which to begin Read
|
|
|
|
NumBytes - On input, indicates the requested write size. On
|
|
|
|
output, indicates the actual number of bytes Read
|
|
|
|
Buffer - Buffer containing source data for the Read.
|
|
|
|
|
|
|
|
Returns:
|
|
|
|
EFI_SUCCESS - The firmware volume was read successfully and
|
|
|
|
contents are in Buffer
|
|
|
|
EFI_BAD_BUFFER_SIZE - Read attempted across a LBA boundary. On output,
|
|
|
|
NumBytes contains the total number of bytes
|
|
|
|
returned in Buffer
|
|
|
|
EFI_ACCESS_DENIED - The firmware volume is in the ReadDisabled state
|
|
|
|
EFI_DEVICE_ERROR - The block device is not functioning correctly and
|
|
|
|
could not be read
|
|
|
|
EFI_INVALID_PARAMETER - NumBytes or Buffer are NULL
|
2013-11-12 19:34:52 +01:00
|
|
|
|
|
|
|
--*/
|
|
|
|
{
|
2015-10-26 15:58:08 +01:00
|
|
|
return QemuFlashRead ((EFI_LBA)Lba, (UINTN)Offset, NumBytes,
|
|
|
|
(UINT8 *)Buffer);
|
2013-11-12 19:34:52 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
ValidateFvHeader (
|
|
|
|
EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader
|
|
|
|
)
|
|
|
|
/*++
|
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Routine Description:
|
|
|
|
Check the integrity of firmware volume header
|
2013-11-12 19:34:52 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Arguments:
|
|
|
|
FwVolHeader - A pointer to a firmware volume header
|
2013-11-12 19:34:52 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Returns:
|
|
|
|
EFI_SUCCESS - The firmware volume is consistent
|
|
|
|
EFI_NOT_FOUND - The firmware volume has corrupted. So it is not an
|
|
|
|
FV
|
2013-11-12 19:34:52 +01:00
|
|
|
|
|
|
|
--*/
|
|
|
|
{
|
|
|
|
UINT16 Checksum;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Verify the header revision, header signature, length
|
|
|
|
// Length of FvBlock cannot be 2**64-1
|
|
|
|
// HeaderLength cannot be an odd number
|
|
|
|
//
|
|
|
|
if ((FwVolHeader->Revision != EFI_FVH_REVISION) ||
|
|
|
|
(FwVolHeader->Signature != EFI_FVH_SIGNATURE) ||
|
|
|
|
(FwVolHeader->FvLength == ((UINTN) -1)) ||
|
|
|
|
((FwVolHeader->HeaderLength & 0x01) != 0)
|
|
|
|
) {
|
|
|
|
return EFI_NOT_FOUND;
|
|
|
|
}
|
2015-10-26 15:58:01 +01:00
|
|
|
|
2013-11-12 19:34:52 +01:00
|
|
|
//
|
|
|
|
// Verify the header checksum
|
|
|
|
//
|
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Checksum = CalculateSum16 ((UINT16 *) FwVolHeader,
|
|
|
|
FwVolHeader->HeaderLength);
|
2013-11-12 19:34:52 +01:00
|
|
|
if (Checksum != 0) {
|
|
|
|
UINT16 Expected;
|
|
|
|
|
2014-09-25 04:29:10 +02:00
|
|
|
Expected =
|
|
|
|
(UINT16) (((UINTN) FwVolHeader->Checksum + 0x10000 - Checksum) & 0xffff);
|
2013-11-12 19:34:52 +01:00
|
|
|
|
|
|
|
DEBUG ((EFI_D_INFO, "FV@%p Checksum is 0x%x, expected 0x%x\n",
|
|
|
|
FwVolHeader, FwVolHeader->Checksum, Expected));
|
|
|
|
return EFI_NOT_FOUND;
|
|
|
|
}
|
|
|
|
|
|
|
|
return EFI_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
STATIC
|
|
|
|
EFI_STATUS
|
|
|
|
MarkMemoryRangeForRuntimeAccess (
|
|
|
|
EFI_PHYSICAL_ADDRESS BaseAddress,
|
2014-11-14 11:23:21 +01:00
|
|
|
UINTN Length
|
2013-11-12 19:34:52 +01:00
|
|
|
)
|
|
|
|
{
|
|
|
|
EFI_STATUS Status;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Mark flash region as runtime memory
|
|
|
|
//
|
|
|
|
Status = gDS->RemoveMemorySpace (
|
|
|
|
BaseAddress,
|
|
|
|
Length
|
|
|
|
);
|
|
|
|
|
|
|
|
Status = gDS->AddMemorySpace (
|
|
|
|
EfiGcdMemoryTypeSystemMemory,
|
|
|
|
BaseAddress,
|
|
|
|
Length,
|
|
|
|
EFI_MEMORY_UC | EFI_MEMORY_RUNTIME
|
|
|
|
);
|
|
|
|
ASSERT_EFI_ERROR (Status);
|
|
|
|
|
|
|
|
Status = gBS->AllocatePages (
|
|
|
|
AllocateAddress,
|
|
|
|
EfiRuntimeServicesData,
|
2014-11-14 11:23:21 +01:00
|
|
|
EFI_SIZE_TO_PAGES (Length),
|
2013-11-12 19:34:52 +01:00
|
|
|
&BaseAddress
|
|
|
|
);
|
|
|
|
ASSERT_EFI_ERROR (Status);
|
|
|
|
|
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
|
|
|
STATIC
|
|
|
|
EFI_STATUS
|
|
|
|
InitializeVariableFvHeader (
|
|
|
|
VOID
|
|
|
|
)
|
|
|
|
{
|
|
|
|
EFI_STATUS Status;
|
|
|
|
EFI_FIRMWARE_VOLUME_HEADER *GoodFwVolHeader;
|
|
|
|
EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader;
|
|
|
|
UINTN Length;
|
|
|
|
UINTN WriteLength;
|
|
|
|
UINTN BlockSize;
|
|
|
|
|
|
|
|
FwVolHeader =
|
|
|
|
(EFI_FIRMWARE_VOLUME_HEADER *) (UINTN)
|
|
|
|
PcdGet32 (PcdOvmfFlashNvStorageVariableBase);
|
|
|
|
|
2015-10-26 15:58:01 +01:00
|
|
|
Length =
|
2013-11-12 19:34:52 +01:00
|
|
|
(FixedPcdGet32 (PcdFlashNvStorageVariableSize) +
|
|
|
|
FixedPcdGet32 (PcdFlashNvStorageFtwWorkingSize) +
|
|
|
|
FixedPcdGet32 (PcdFlashNvStorageFtwSpareSize) +
|
|
|
|
FixedPcdGet32 (PcdOvmfFlashNvStorageEventLogSize));
|
|
|
|
|
|
|
|
BlockSize = PcdGet32 (PcdOvmfFirmwareBlockSize);
|
|
|
|
|
|
|
|
Status = ValidateFvHeader (FwVolHeader);
|
|
|
|
if (!EFI_ERROR (Status)) {
|
|
|
|
if (FwVolHeader->FvLength != Length ||
|
|
|
|
FwVolHeader->BlockMap[0].Length != BlockSize) {
|
|
|
|
Status = EFI_VOLUME_CORRUPTED;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (EFI_ERROR (Status)) {
|
|
|
|
UINTN Offset;
|
|
|
|
UINTN Start;
|
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
DEBUG ((EFI_D_INFO,
|
|
|
|
"Variable FV header is not valid. It will be reinitialized.\n"));
|
2013-11-12 19:34:52 +01:00
|
|
|
|
|
|
|
//
|
|
|
|
// Get FvbInfo to provide in FwhInstance.
|
|
|
|
//
|
|
|
|
Status = GetFvbInfo (Length, &GoodFwVolHeader);
|
|
|
|
ASSERT (!EFI_ERROR (Status));
|
|
|
|
|
|
|
|
Start = (UINTN)(UINT8*) FwVolHeader - PcdGet32 (PcdOvmfFdBaseAddress);
|
|
|
|
ASSERT (Start % BlockSize == 0 && Length % BlockSize == 0);
|
|
|
|
ASSERT (GoodFwVolHeader->HeaderLength <= BlockSize);
|
|
|
|
|
|
|
|
//
|
|
|
|
// Erase all the blocks
|
|
|
|
//
|
|
|
|
for (Offset = Start; Offset < Start + Length; Offset += BlockSize) {
|
2014-11-14 11:23:33 +01:00
|
|
|
Status = QemuFlashEraseBlock (Offset / BlockSize);
|
2013-11-12 19:34:52 +01:00
|
|
|
ASSERT_EFI_ERROR (Status);
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// Write good FV header
|
|
|
|
//
|
|
|
|
WriteLength = GoodFwVolHeader->HeaderLength;
|
|
|
|
Status = QemuFlashWrite (
|
2014-11-14 11:23:33 +01:00
|
|
|
Start / BlockSize,
|
2013-11-12 19:34:52 +01:00
|
|
|
0,
|
|
|
|
&WriteLength,
|
|
|
|
(UINT8 *) GoodFwVolHeader);
|
|
|
|
ASSERT_EFI_ERROR (Status);
|
|
|
|
ASSERT (WriteLength == GoodFwVolHeader->HeaderLength);
|
|
|
|
}
|
|
|
|
|
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
FvbInitialize (
|
|
|
|
IN EFI_HANDLE ImageHandle,
|
|
|
|
IN EFI_SYSTEM_TABLE *SystemTable
|
|
|
|
)
|
|
|
|
/*++
|
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Routine Description:
|
|
|
|
This function does common initialization for FVB services
|
2013-11-12 19:34:52 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Arguments:
|
2013-11-12 19:34:52 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
Returns:
|
2013-11-12 19:34:52 +01:00
|
|
|
|
|
|
|
--*/
|
|
|
|
{
|
|
|
|
EFI_STATUS Status;
|
|
|
|
EFI_FW_VOL_INSTANCE *FwhInstance;
|
|
|
|
EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader;
|
|
|
|
UINT32 BufferSize;
|
|
|
|
EFI_FV_BLOCK_MAP_ENTRY *PtrBlockMapEntry;
|
|
|
|
EFI_FW_VOL_BLOCK_DEVICE *FvbDevice;
|
|
|
|
UINT32 MaxLbaSize;
|
|
|
|
EFI_PHYSICAL_ADDRESS BaseAddress;
|
2014-11-14 11:23:21 +01:00
|
|
|
UINTN Length;
|
2013-11-12 19:34:52 +01:00
|
|
|
UINTN NumOfBlocks;
|
|
|
|
|
|
|
|
if (EFI_ERROR (QemuFlashInitialize ())) {
|
|
|
|
//
|
|
|
|
// Return an error so image will be unloaded
|
|
|
|
//
|
2015-10-26 15:58:08 +01:00
|
|
|
DEBUG ((EFI_D_INFO,
|
|
|
|
"QEMU flash was not detected. Writable FVB is not being installed.\n"));
|
2013-11-12 19:34:52 +01:00
|
|
|
return EFI_WRITE_PROTECTED;
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// Allocate runtime services data for global variable, which contains
|
|
|
|
// the private data of all firmware volume block instances
|
|
|
|
//
|
|
|
|
mFvbModuleGlobal = AllocateRuntimePool (sizeof (ESAL_FWB_GLOBAL));
|
|
|
|
ASSERT (mFvbModuleGlobal != NULL);
|
|
|
|
|
|
|
|
BaseAddress = (UINTN) PcdGet32 (PcdOvmfFdBaseAddress);
|
|
|
|
Length = PcdGet32 (PcdOvmfFirmwareFdSize);
|
|
|
|
|
|
|
|
Status = InitializeVariableFvHeader ();
|
|
|
|
if (EFI_ERROR (Status)) {
|
2015-10-26 15:58:08 +01:00
|
|
|
DEBUG ((EFI_D_INFO,
|
|
|
|
"QEMU Flash: Unable to initialize variable FV header\n"));
|
2013-11-12 19:34:52 +01:00
|
|
|
return EFI_WRITE_PROTECTED;
|
|
|
|
}
|
|
|
|
|
|
|
|
FwVolHeader = (EFI_FIRMWARE_VOLUME_HEADER *) (UINTN) BaseAddress;
|
|
|
|
Status = ValidateFvHeader (FwVolHeader);
|
|
|
|
if (EFI_ERROR (Status)) {
|
|
|
|
//
|
|
|
|
// Get FvbInfo
|
|
|
|
//
|
|
|
|
Status = GetFvbInfo (Length, &FwVolHeader);
|
|
|
|
if (EFI_ERROR (Status)) {
|
|
|
|
DEBUG ((EFI_D_INFO, "EFI_ERROR (GetFvbInfo (Length, &FwVolHeader))\n"));
|
|
|
|
return EFI_WRITE_PROTECTED;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
BufferSize = (sizeof (EFI_FW_VOL_INSTANCE) +
|
|
|
|
FwVolHeader->HeaderLength -
|
|
|
|
sizeof (EFI_FIRMWARE_VOLUME_HEADER)
|
|
|
|
);
|
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
|
|
|
mFvbModuleGlobal->FvInstance = AllocateRuntimePool (BufferSize);
|
|
|
|
ASSERT (mFvbModuleGlobal->FvInstance != NULL);
|
2013-11-12 19:34:52 +01:00
|
|
|
|
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
|
|
|
FwhInstance = mFvbModuleGlobal->FvInstance;
|
2013-11-12 19:34:52 +01:00
|
|
|
|
|
|
|
mFvbModuleGlobal->NumFv = 0;
|
|
|
|
MaxLbaSize = 0;
|
|
|
|
|
|
|
|
FwVolHeader =
|
|
|
|
(EFI_FIRMWARE_VOLUME_HEADER *) (UINTN)
|
|
|
|
PcdGet32 (PcdOvmfFlashNvStorageVariableBase);
|
|
|
|
|
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
|
|
|
FwhInstance->FvBase = (UINTN) BaseAddress;
|
2013-11-12 19:34:52 +01:00
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
CopyMem ((UINTN *) &(FwhInstance->VolumeHeader), (UINTN *) FwVolHeader,
|
|
|
|
FwVolHeader->HeaderLength);
|
2013-11-12 19:34:52 +01:00
|
|
|
FwVolHeader = &(FwhInstance->VolumeHeader);
|
|
|
|
|
|
|
|
NumOfBlocks = 0;
|
|
|
|
|
2015-10-26 15:58:08 +01:00
|
|
|
for (PtrBlockMapEntry = FwVolHeader->BlockMap;
|
|
|
|
PtrBlockMapEntry->NumBlocks != 0;
|
|
|
|
PtrBlockMapEntry++) {
|
2013-11-12 19:34:52 +01:00
|
|
|
//
|
|
|
|
// Get the maximum size of a block.
|
|
|
|
//
|
|
|
|
if (MaxLbaSize < PtrBlockMapEntry->Length) {
|
|
|
|
MaxLbaSize = PtrBlockMapEntry->Length;
|
|
|
|
}
|
|
|
|
|
|
|
|
NumOfBlocks = NumOfBlocks + PtrBlockMapEntry->NumBlocks;
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// The total number of blocks in the FV.
|
|
|
|
//
|
|
|
|
FwhInstance->NumOfBlocks = NumOfBlocks;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Add a FVB Protocol Instance
|
|
|
|
//
|
|
|
|
FvbDevice = AllocateRuntimePool (sizeof (EFI_FW_VOL_BLOCK_DEVICE));
|
|
|
|
ASSERT (FvbDevice != NULL);
|
|
|
|
|
|
|
|
CopyMem (FvbDevice, &mFvbDeviceTemplate, sizeof (EFI_FW_VOL_BLOCK_DEVICE));
|
|
|
|
|
|
|
|
FvbDevice->Instance = mFvbModuleGlobal->NumFv;
|
|
|
|
mFvbModuleGlobal->NumFv++;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Set up the devicepath
|
|
|
|
//
|
|
|
|
if (FwVolHeader->ExtHeaderOffset == 0) {
|
2015-10-26 15:58:08 +01:00
|
|
|
FV_MEMMAP_DEVICE_PATH *FvMemmapDevicePath;
|
|
|
|
|
2013-11-12 19:34:52 +01:00
|
|
|
//
|
|
|
|
// FV does not contains extension header, then produce MEMMAP_DEVICE_PATH
|
|
|
|
//
|
2015-10-26 15:58:08 +01:00
|
|
|
FvMemmapDevicePath = AllocateCopyPool (sizeof (FV_MEMMAP_DEVICE_PATH),
|
|
|
|
&mFvMemmapDevicePathTemplate);
|
|
|
|
FvMemmapDevicePath->MemMapDevPath.StartingAddress = BaseAddress;
|
|
|
|
FvMemmapDevicePath->MemMapDevPath.EndingAddress =
|
|
|
|
BaseAddress + FwVolHeader->FvLength - 1;
|
|
|
|
FvbDevice->DevicePath = (EFI_DEVICE_PATH_PROTOCOL *)FvMemmapDevicePath;
|
2013-11-12 19:34:52 +01:00
|
|
|
} else {
|
2015-10-26 15:58:08 +01:00
|
|
|
FV_PIWG_DEVICE_PATH *FvPiwgDevicePath;
|
|
|
|
|
|
|
|
FvPiwgDevicePath = AllocateCopyPool (sizeof (FV_PIWG_DEVICE_PATH),
|
|
|
|
&mFvPIWGDevicePathTemplate);
|
2013-11-12 19:34:52 +01:00
|
|
|
CopyGuid (
|
2015-10-26 15:58:08 +01:00
|
|
|
&FvPiwgDevicePath->FvDevPath.FvName,
|
2013-11-12 19:34:52 +01:00
|
|
|
(GUID *)(UINTN)(BaseAddress + FwVolHeader->ExtHeaderOffset)
|
|
|
|
);
|
2015-10-26 15:58:08 +01:00
|
|
|
FvbDevice->DevicePath = (EFI_DEVICE_PATH_PROTOCOL *)FvPiwgDevicePath;
|
2013-11-12 19:34:52 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
//
|
2015-10-26 15:58:39 +01:00
|
|
|
// Module type specific hook.
|
2013-11-12 19:34:52 +01:00
|
|
|
//
|
2015-10-26 15:58:39 +01:00
|
|
|
InstallProtocolInterfaces (FvbDevice);
|
2013-11-12 19:34:52 +01:00
|
|
|
|
|
|
|
MarkMemoryRangeForRuntimeAccess (BaseAddress, Length);
|
|
|
|
|
|
|
|
//
|
|
|
|
// Set several PCD values to point to flash
|
|
|
|
//
|
|
|
|
PcdSet64 (
|
|
|
|
PcdFlashNvStorageVariableBase64,
|
|
|
|
(UINTN) PcdGet32 (PcdOvmfFlashNvStorageVariableBase)
|
|
|
|
);
|
|
|
|
PcdSet32 (
|
|
|
|
PcdFlashNvStorageFtwWorkingBase,
|
|
|
|
PcdGet32 (PcdOvmfFlashNvStorageFtwWorkingBase)
|
|
|
|
);
|
|
|
|
PcdSet32 (
|
|
|
|
PcdFlashNvStorageFtwSpareBase,
|
|
|
|
PcdGet32 (PcdOvmfFlashNvStorageFtwSpareBase)
|
|
|
|
);
|
|
|
|
|
|
|
|
FwhInstance = (EFI_FW_VOL_INSTANCE *)
|
|
|
|
(
|
|
|
|
(UINTN) ((UINT8 *) FwhInstance) + FwVolHeader->HeaderLength +
|
|
|
|
(sizeof (EFI_FW_VOL_INSTANCE) - sizeof (EFI_FIRMWARE_VOLUME_HEADER))
|
|
|
|
);
|
|
|
|
|
2015-10-26 15:58:39 +01:00
|
|
|
//
|
|
|
|
// Module type specific hook.
|
|
|
|
//
|
|
|
|
InstallVirtualAddressChangeHandler ();
|
2013-11-12 19:34:52 +01:00
|
|
|
|
2013-11-12 19:35:23 +01:00
|
|
|
PcdSetBool (PcdOvmfFlashVariablesEnable, TRUE);
|
2013-11-12 19:34:52 +01:00
|
|
|
return EFI_SUCCESS;
|
|
|
|
}
|