summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg/QemuFlashFvbServices: factor out SetPcdFlashNvStorageBaseAddressesLaszlo Ersek2020-03-121-0/+5
| | | | | | | | | | | | | | | | | | | | Extract the dynamic setting of the - PcdFlashNvStorageVariableBase64 - PcdFlashNvStorageFtwWorkingBase - PcdFlashNvStorageFtwSpareBase addresses to a helper function. For now, the helper function is identical (duplicated) between the SMM flash driver and the runtime DXE flash driver. In subsequent patches, this will change. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=386 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200310222739.26717-3-lersek@redhat.com> Acked-by: Leif Lindholm <leif@nuviainc.com>
* OvmfPkg: Replace BSD License with BSD+Patent LicenseMichael D Kinney2019-04-091-7/+1
| | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1373 Replace BSD 2-Clause License with BSD+Patent License. This change is based on the following emails: https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html RFCs with detailed process for the license change: V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Do not expose MMIO in SMM buildBrijesh Singh2018-07-061-0/+7
| | | | | | | | | | | | | | | In the SMM build, only an SMM driver is using the address range hence we do not need to expose the flash MMIO range in EFI runtime mapping. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien.grall@linaro.org> Cc: Justen Jordan L <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: QemuFlashFvbServicesRuntimeDxe: split out runtime DXE specificsLaszlo Ersek2015-10-261-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for introducing an SMM interface to this driver, move the following traits to separate files, so that we can replace them in the new SMM INF file: - Protocol installations. The SMM driver will install protocol interfaces in the SMM protocol database, using SMM services. - Virtual address change handler and pointer conversions. SMM drivers run with physical mappings and pointers must not be converted. There are further restrictions and changes for an SMM driver, but the rest of the code either complies with those already, or will handle the changes transparently. For example: - SMM drivers have access to both UEFI and SMM protocols in their entry points (see the PI spec 1.4, "1.7 SMM Driver Initialization"), - MemoryAllocationLib has an SMM instance that serves allocation requests with the gSmst->SmmAllocatePool() service transparently, allocating runtime-marked SMRAM. 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@18671 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: QemuFlashFvbServicesRuntimeDxe: no dual addressing neededLaszlo Ersek2015-10-261-16/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* OvmfPkg: QemuFlashFvbServicesRuntimeDxe: remove FvbScratchSpace fieldLaszlo Ersek2015-10-261-1/+0
| | | | | | | | | | | | | | | The ESAL_FWB_GLOBAL.FvbScratchSpace array is never initialized (it contains garbage from AllocateRuntimePool()). Its element at subscript one (=FVB_VIRTUAL), containing garbage as well, is converted to virtual mapping. Then the array is never used again. Remove it. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18669 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: QemuFlashFvbServicesRuntimeDxe: remove FvbDevLock fieldLaszlo Ersek2015-10-261-1/+0
| | | | | | | | | | | The EFI_FW_VOL_INSTANCE.FvbDevLock member is initialized and then never used. Remove it. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18668 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: QemuFlashFvbServicesRuntimeDxe: rewrap source code to 79 charsLaszlo Ersek2015-10-261-13/+18
| | | | | | | | | | | | | | | | | | | Some of the line lengths in this driver are atrocious. While we have to put up with the status quo outside of OvmfPkg, we can at least rewrap this driver before refactoring it. In the FvbInitialize() function there's no way around introducing two local variables, just for the sake of sensibly rewrapping the code. Furthermore, in "FwBlockService.c" the function comment blocks are now indented; their original position causes diff to print bogus function names at the top of hunks. 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@18666 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: QemuFlashFvbServicesRuntimeDxe: strip trailing whitespaceLaszlo Ersek2015-10-261-8/+8
| | | | | | | | 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@18665 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Add QemuFlashFvbServicesRuntimeDxe driverJordan Justen2013-11-121-0/+184
If QEMU flash is detected, this module will install FirmwareVolumeBlock support for the QEMU flash device. It will also set PCDs with the results that: 1. OvmfPkg/EmuVariableFvbRuntimeDxe will be disabled 2. MdeModulePkg variable services will read/write flash directly Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14839 6f19259b-4bc3-4df7-8a09-765794883524