Revert previous fix in AuthVariable driver init which breaks SecureBootEnable original behavior. Add more error handling logic in SecureBootConfigDxe to prevent wrong display info when SecureBootEnable & PK inconsistency happens.
Commit hash for the reverted patch in AuthVariable driver is
SHA-1: a6811666b0bef18871fa62b6c5abf18fb076fd0d
Thomas Palmer [Sat, 16 Apr 2016 01:45:02 +0000 (09:45 +0800)]
BaseTools/Build: Consider only build-specified architectures
When building for any specific architecture, the build script today
is loading DSC sections for other architectures not in the build.
The build process should disregard DSC sections that are not
relevant to the build.
This fixes scenario whereby a build occurs in a source tree that was
been cleaned of non-essential directories. For instance, X64 builds
do not require the ArmPkg directory to build a firmware image. This
condition (build break when ArmPkg is absent) occurs when included
DSCs have sections for multiple architectures.
ShellPkg: Update ping command options to sync with Spec
This patch is used to update ping command options to sync
with shell2.2 Spec.
Considering the backward compatible issue, the patch keeps
‘-_s’ command option unchanged, only add the new option '-s'
and make the old option '-_s' function same as new one.
The 64-bit version of the DS-5 debug script that retrieves the debug file
path from the PE/COFF image in memory assumes that the PE/COFF header is
packed, and that the debug directory entry in the optional header appears
at a fixed offset into the file. This is no longer true, now that we pad
between the file header and the PE header if the section alignment exceeds
the size of the header (which may be the case when the module contains a
vector table or small model code, which requires 2 KB or 4 KB section
alignment, respectively), to allow this padding to be emitted if the image
is subsequently converted to TE format.
So replace the fixed offset with a dereference of the appropriate header
field.
PerformancePkg: Make Dp print help information with -? flag in Shell.
Since Shell supports finding help information from resource section
of application image. We enhance the Dp to add help information
string. After the Dp are loaded in system the help string will
be stored in resource section of the application image.
ShellPkg : Cache the environment variable into memory to enhance
the performance.
Currently UEFI Shell reads variable storage to get the environment
variables every time running a new command. And reading(writing)
UEFI variables is a high cost operation on most platforms. In order
to enhance the performance this patch read the variable storage once
and cache the environment variables in memory. Every further 'set'
command will save the variable not only to Shell cache, but also the
flash variable storage.
In commit 017fb1cd4c5e3c8b914eb217ac1760223687dad7, the PLATFORM_DIR
macro has been updated to resolve to the correct path. However, it is
incorrectly accessed via curved rather than curly braces by GenMake.
ArmPkg/AArch64Mmu: disable MMU during page table manipulations
On ARM, manipulating live page tables is cumbersome since the architecture
mandates the use of break-before-make, i.e., replacing a block entry with
a table entry requires an intermediate step via an invalid entry, or TLB
conflicts may occur.
Since it is not generally feasible to decide in the page table manipulation
routines whether such an invalid entry will result in those routines
themselves to become unavailable, use a function that is callable with
the MMU off (i.e., a leaf function that does not access the stack) to
perform the change of a block entry into a table entry.
Note that the opposite should never occur, i.e., table entries are never
coalesced into block entries.
ArmPkg/AArch64Mmu: Fix XN attribute for device memory
Now XN attribute will be set automatically if the region is declared
as device memory. However, the function ArmMemoryAttributeToPageAttribute
is to get attribute for block and page descriptors, not for table
descriptors, so attribute TT_TABLE_*XN does not really take effect.
EFI_NOT_READY should not be treated as an error status
returned from SetData for Ip6ConfigDataTypeManualAddress
since there is an asynchronous operation for DAD process.
Cc: Ye Ting <ting.ye@intel.com> Cc: Fu Siyuan <siyuan.fu@intel.com> Cc: Hegde Nagaraj P <nagaraj-p.hegde@hpe.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Hegde Nagaraj P <nagaraj-p.hegde@hpe.com> Reviewed-by: Sriram Subramanian <sriram-s@hpe.com> Tested-by: Hegde Nagaraj P <nagaraj-p.hegde@hpe.com>
BaseTools: fix the bug for [BuildOptions] of multiple workspace support
when enable Multiple workspace and there have other option(eg: -I) before
$(WORKSPACE), handleWsMacro cannot return correct which cause the
ArmVirtPkg build failure.
example:
[BuildOptions]
*_*_AARCH64_PLATFORM_FLAGS == -I$(WORKSPACE)/ArmVirtPkg/Include
BaseTools: fix PLATFORM_DIR variable value for multiple workspace
when enable the multiple workspace, the PLATFORM_DIR still is
$(WORKSPACE)\AnyPkg, even though it is in a PACKAGES_PATH folder. this
patch fix this issue to use the real path.
ArmVirtPkg/VirtFdtDxe: remove Xenio handling and rename to VirtioFdtDxe
Now that we have moved the handling of the xen,xen DT node to XenioFdtDxe,
remove its handling from VirtFdtDxe. Since the only functionality that
remains is handling the virtio,mmio DT node, rename VirtFdtDxe to
VirtioFdtDxe to reflect that. Also update the platforms that use this
driver.
ArmVirtPkg/ArmVirtXen: move from VirtFdtDxe to new XenioFdtDxe driver
Now that the only functionality that remains in VirtFdtDxe is enumerating
the respective virtual I/O buses, it no longer makes sense to have a driver
that is shared between Xen domU and QEMU. So move the Xen I/O DT node
handling to a new driver, and update ArmVirtXen to switch to it.
ArmVirtPkg/VirtFdtDxe: move FDT config table installation to FdtClientDxe
Now that FdtClientDxe is the core driver that takes ownership of the host
supplied FDT, it makes sense to put it in charge of installing the FDT
configuration table as well.
ArmVirtPkg: get rid of A PRIORI DXE declarations for VirtFdtDxe
We no longer care when VirtFdtDxe executes, since
- the driver sets no dynamic PCDs any longer, and
- the only remaining functionality centers on VirtioMmioInstallDevice()
and XenIoMmioInstall() function calls and FDT configuration table
installation.
ArmVirtPkg: move QEMU based platforms to ArmVirtPL031FdtClientLib
This moves QEMU based platforms to ArmVirtPL031FdtClientLib, so that we no
longer have to rely on VirtFdtDxe to execute first and set the PL031 base
address in a dynamic PCD.
The only driver which [transitively] depends on this PcdPL031RtcBase PCD is
EmbeddedPkg/RealTimeClockRuntimeDxe, so this conversion cannot affect any
other users and is thus safe.
This implements a library ArmVirtPL031FdtClientLib which is intended to
be incorporated into RealTimeClockRuntimeDxe via NULL library class
resolution. This allows us to make RealTimeClockRuntimeDxe depend on the
FDT client protocol, and discover the PL031 base address from the device tree
directly rather than relying on VirtFdtDxe to set the dynamic PCDs.
The NULL library class resolution approach to strictly order production and
consumption of dynamic PCDs is not generally safe in cases such as this one,
where the producer and the consumer of the PCD are both libraries. However,
since the PCD is produced in this library's constructor, and the consumer
library's constructor 'LibRtcInitialize' is not a 'true' constructor (it is
invoked explicitly by RealTimeClockRuntimeDxe), this case is guaranteed to
be safe after all.
ArmVirtPkg/RelocatableVirtHelper: use correct FindMemNode argument order
Commit 03b6bed17ea6 ArmVirtPkg/XenRelocatablePlatformLib: rewrite DTB
memory node retrieval in C") introduced a FindMemNode () C function
that takes pointers to system memory base and size as arguments, but the
calling code passes them in the wrong order.
Count is initially 1 but is assigned to 2 in case PS2_READ_DATA_BYTE.
Though the state machine doesn't go back from PS2_READ_DATA_BYTE to
PS2_READ_BYTE_ONE (not a true bug), force assign Count to 1 to avoid
potential buffer overflow issue.
ArmVirtPkg/VirtFdtDxe: drop PCI host bridge handling
Now that the PCI host bridge driver parses the DT node that describes
the PCI host bridge directly via the FDT client protocol, we can drop the
handling from VirtFdtDxe completely.
This means some PCI related PCDs are no longer set, such as PcdPciBusMin,
PcdPciBusMax, PcdPciIoBase, PcdPciIoSize, PcdPciIoTranslation,
PcdPciMmio32Base and PcdPciMmio32Size. Since these PCDs are specific to
ARM (and declared in ArmPlatformPkg), and not used anywhere else by the
ArmVirtPkg platforms, we can simply stop populating them, and drop all
references to them.
It also means that we can no longer rely on PcdPciDisableBusEnumeration
to be set before it is consumed by PciBusDxe and QemuFwCfgAcpiPlatformDxe,
so make those depend on FdtPciPcdProducerLib explicitly via NULL library
class resolution.
ArmVirtPkg/PciHostBridgeDxe: move to FDT client protocol
Instead of relying on VirtFdtDxe to populate various dynamic PCDs with
information retrieved from the host-provided device tree, perform the
PCI ECAM related DT node parsing directly in PciHostBridgeDxe.
ArmVirtPkg/BaseCachingPciExpressLib: depend on PciPcdProducerLib
Make BaseCachingPciExpressLib depend on PciPcdProducerLib, so that we
have a chance to populate PcdPciExpressBaseAddress based on the contents
of the device tree.
Also update the platforms under ArmVirtPkg that support PCI to use the
special MAX_UINT64 value as the build time default for
PcdPciExpressBaseAddress.
This implements a library FdtPciPcdProducerLib which is intended to
be incorporated into modules that consume the PCI related dynamic PCDs
PcdPciExpressBaseAddress and PcdPciDisableBusEnumeration, either via NULL
library class resolution or via a direct dependency (for other libraries
or modules in ArmVirtPkg). This allows us to make them depend on the FDT
client protocol, and populate these PCDs based on the presence and the
contents of a 'pci-host-ecam-generic' DT node.
This also overloads the meaning of PcdPciExpressBaseAddress, which we will
set to MAX_UINT64 to signify that the actual values of these two PCDs have
not been assigned yet.
ArmVirtPkg/VirtFdtDxe: remove handling of fw_cfg DT node
Remove the handling of the fw_cfg DT node from VirtFdtDxe now that the
fw_cfg client library has been moved to the FDT client protocol, and no
longer relies on VirtFdtDxe to pass this information via dynamic PCDs.
Since the PCDs in question are now no longer used, remove them from the
various DEC and DSC files as well.
ArmVirtPkg/QemuFwCfgLib: move to FDT client protocol
Make this library depend on the FDT client protocol to access the
host supplied device tree directly rather than depending on VirtFdtDxe
to set them using dynamic PCDs.
Since this library is used by several drivers (BdsDxe, SmbiosPlatformDxe,
SmbiosDxe and QemuFwCfgAcpiPlatformDxe), we will end up parsing the device
tree and the fwcfg node at least four times. However, no dynamic PCDs are
involved anymore, and will even be removed completely in a subsequent
patch. So the conversion is not optimal, but guaranteed to be safe.
Leif Lindholm [Thu, 17 Mar 2016 13:22:52 +0000 (21:22 +0800)]
BaseTools: use unsigned chars on ARM architectures
By default, the ARM architectures have unsigned chars, whereas the other
architectures supported by EDK2 by default have signed chars.
However, EDK2 uses -funsigned-chars on those architectures to change the
default behaviour.
Unfortunately, the ARM architectures explicitly break their default
behaviour by specifying -fsigned-chars (I presume in a pre-emptive
attempt at avoiding incompatibility).
Since this situation is already confusing enough, switch the ARM
architectures to also specify -funsigned-chars explicitly rather than
just dropping the current parameter.
BaseTools/VolInfo: generate HASH value for each PE image
VolInfo Tool add new option --hash to use openssl to generate hash value
for each PE image. If the image base address is not zero, we will rebase
its base address to zero before generate hash value.
Move to the new dedicated ArmVirtTimerFdtClientLib to populate the
various timer related PCDs at driver load time rather than relying on
VirtFdtDxe to do it. Since ArmPkg/TimerDxe is the only consumer of these
PCDs, which is the DXE driver ArmVirtTimerFdtClientLib is intended to
complement, this conversion is guaranteed to be safe.
This implements a library ArmVirtTimerFdtClientLib which is intended to
be incorporated into TimerDxe via NULL library class resolution. This
allows us to make TimerDxe depend on the FDT client protocol, and
discover the timer interrupts from the device tree directly rather than
relying on VirtFdtDxe to set the dynamic PCDs.
ArmVirtPkg/VirtFdtDxe: drop detection of PSCI method
The detection of the PSCI method has been moved to the EfiResetSystemLib
implementation, so drop the handling from VirtFdtDxe. Since no users
remain of gArmVirtTokenSpaceGuid.PcdArmPsciMethod, remove that as well.
ArmVirtPkg/ArmVirtPsciResetSystemLib: move to FDT client protocol
Instead of relying on VirtFdtDxe to detect the PSCI method, move our
EfiResetSystemLib to the FDT client protocol to interrogate the device
tree directly.
Since this library is only consumed by EmbeddedPkg/ResetRuntimeDxe, and
considering that the PCD is no longer set, and even removed completely in a
subsequent patch, this conversion is guaranteed to be safe.
Now that we moved the GIC discovery to our ArmGicArchLib implementation,
we can remove it from VirtFdtDxe, since it is no longer used. Remove the
PcdArmGicRevision declaration and definitions as well: VirtFdtDxe no longer
sets it, and no other drivers consume its value.
ArmVirtPkg/ArmGicArchLib: move to FdtClient protocol
Instead of relying on VirtFdtDxe to populate the GIC related PCDs, move
this handling to our implementation of ArmGicArchLib, and retrieve the
required DT info using the new FDT client protocol.
This removes one of the reasons we need to load VirtFdtDxe first using
an 'A PRIORI' declaration in the platform FDF.
As Laszlo kindly confirms:
So, ultimately, the only user of this library instance is
"ArmPkg/Drivers/ArmGic/ArmGicDxe.inf". ... Indeed, checking the build
report file for ArmVirtQemu (AARCH64), I find ArmVirtGicArchLib (and
ArmGicLib too) only under "ArmPkg/Drivers/ArmGic/ArmGicDxe.inf".
which means that the constructor is only invoked once, and so the dynamic
PCDs are set in time for ArmGicDxe to consume them, and never afterwards.
ArmVirtPkg: add FdtClientDxe to the ArmVirtPkg platforms
Add FdtClientDxe to the various platforms under ArmVirtPkg, so that the
drivers we will update to depend on the FDT client protocol in subsequent
patches will remain in working order.
UefiCpuPkg: CpuIo2Dxe: optimize FIFO reads and writes of IO ports
* Short description:
The CpuIoServiceRead() and CpuIoServiceWrite() functions transfer data
between memory and IO ports with individual Io(Read|Write)(8|16|32)
function calls, each in an appropriately set up loop.
On the Ia32 and X64 platforms however, FIFO reads and writes can be
optimized, by coding them in assembly, and delegating the loop to the
CPU, with the REP prefix.
On KVM virtualization hosts, this difference has a huge performance
impact: if the loop is open-coded, then the virtual machine traps to the
hypervisor on every single UINT8 / UINT16 / UINT32 transfer, whereas
with the REP prefix, KVM can transfer up to a page of data per VM trap.
This is especially noticeable with IDE PIO transfers, where all the data
are squeezed through IO ports.
* Long description:
The RootBridgeIoIoRW() function in
PcAtChipsetPkg/PciHostBridgeDxe/PciRootBridgeIo.c
used to have the exact same IO port acces optimization, dating back
verbatim to commit 1fd376d9792:
and OvmfPkg too was rebased to the new core Pci Host Bridge Driver, in
commit 4014885ffd:
OvmfPkg: switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe
This caused the optimization to go lost. Namely, the
RootBridgeIoIoRead() and RootBridgeIoIoWrite() functions in the new core
Pci Host Bridge Driver delegate IO port accesses to
EFI_CPU_IO2_PROTOCOL. And, in OvmfPkg (and likely most other Ia32 / X64
edk2 platforms), this protocol is provided by "UefiCpuPkg/CpuIo2Dxe",
which lacks the optimization.
Therefore, this patch ports the C source code logic from commit 1fd376d9792 (see above) to "UefiCpuPkg/CpuIo2Dxe", plus it ports the
NASM-converted assembly helper functions from OvmfPkg commits 6026bf460037 and ace1d0517b65:
OvmfPkg PciHostBridgeDxe: Convert Ia32/IoFifo.asm to NASM
OvmfPkg PciHostBridgeDxe: Convert X64/IoFifo.asm to NASM
In order to support the MSFT and INTEL toolchains as well, the *.asm
files are ported from OvmfPkg as well, immediately from before the above
conversion (that is, at 6026bf460037^).
* Notes about the port:
- The write and read branches from commit 1fd376d9792 are split to the
separate functions CpuIoServiceWrite() and CpuIoServiceRead().
- The EfiPciWidthUintXX constants are replaced with EfiCpuIoWidthUintXX.
- The cast expression "(UINTN) Address" is replaced with
"(UINTN)Address" (i.e., no space), because that's how the receiving
functions spell it as well.
- The labels in the switch statements are unindented by one level, to
match the edk2 coding style (and the rest of UefiCpuPkg) better.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Ref: https://www.redhat.com/archives/vfio-users/2016-April/msg00029.html Reported-by: Mark <kram321@gmail.com>
Ref: http://thread.gmane.org/gmane.comp.bios.edk2.devel/10424/focus=10432 Reported-by: Jordan Justen <jordan.l.justen@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Jeff Fan <jeff.fan@intel.com> Cc: Mark <kram321@gmail.com> Tested-by: Mark <kram321@gmail.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Ruiyu Ni [Mon, 11 Apr 2016 02:55:31 +0000 (10:55 +0800)]
MdeModulePkg/Ps2Keyboard: Add missing PCD and protocol to DEC file
gEfiPs2PolicyProtocolGuid and PcdFastPS2Detection was missed when
resolving the conflict.
Check in the two definition to MdeModulePkg.dec to fix build failure.
Jeff Fan [Thu, 31 Mar 2016 11:15:05 +0000 (19:15 +0800)]
UefiCpuPkg/CpuMpPei: Fix potential AP mwait wakeup issue
If ApLoopMode is set to ApInMwaitLoop, AP will be placed into C-State by mwait
instruction. BSP will wakeup AP by write start-up signal in monitor address.
However, AP maybe waken by SMI/NMI/MCE and other condition. On this case, AP
will check if BSP wants to wakeup itself really. If not, AP will continue to
execute mwait to C-State.
One potential issue: BSP may not recognize AP was wakeup from C-State by other
event and BSP still writes start-up signal to wakeup AP. But AP does not aware
it and still execute mwait instruction to C-State. So, AP cannot be wakeup on
this case.
This fix is let AP to clear start-up signal when it really is wakeup to execute
AP function. And BSP will write start-up signal till AP clears it.
Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@intel.com>
Fu Siyuan [Tue, 22 Mar 2016 05:30:58 +0000 (13:30 +0800)]
NetworkPkg: Add RAM disk boot support to HTTP Boot driver.
This patch updates the HTTP Boot driver to support the download and boot
a RAM disk image from HTTP server.
The HTTP RAM disk boot is described in section 23.7 "HTTP Boot" in
UEFI 2.6. HTTP server could provide either an UEFI image or a RAM disk image
for the HTTP boot client to use. The RAM disk image must contain a UEFI
compliant file system in it.
HTTP boot driver will identify the image type either by the "Content-Type"
entity header filed or by the file name extension as below:
"application/efi" or *.efi -> EFI Image
*.iso -> CD/DVD Image
*.img -> Virtual Disk Image
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com> Reviewed-by: El-Haj-Mahmoud Samer <samer.el-haj-mahmoud@hpe.com>
Add 2 macros inNetLib.h
#define IP4_MASK_MAX 32
#define IP6_PREFIX_MAX 128
we will use these two macros to check the max mask/prefix length,
instead of
#define IP4_MASK_NUM 33
#define IP6_PREFIX_NUM 129
which means a valid number.
This will make the code readability and maintainability.
Add 2 macros in NetLib.h
#define IP4_MASK_MAX 32
#define IP6_PREFIX_MAX 128
we will use these two macros to check the max mask/prefix length,
instead of
#define IP4_MASK_NUM 33
#define IP6_PREFIX_NUM 129
which means a valid number
This will make the code readability and maintainability.
Thomas Palmer [Mon, 4 Apr 2016 19:51:42 +0000 (03:51 +0800)]
MdeModulePkg/UefiBootManagerLib: API BmIsValidLoadOptionVariableName
Redfine the BmIsValidLoadOptionVariableName function to allow public use. Change name to EfiBootManagerIsValidLoadOptionVariableName to match naming scheme. Check that VariableName is never NULL and allow OptionType and OptionNumber to be optional.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Thomas Palmer <thomas.palmer@hpe.com> Reviewed-by: Sunny Wang <sunnywang@hpe.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cinnamon Shia [Wed, 16 Mar 2016 08:23:02 +0000 (16:23 +0800)]
BaseTools: Remove /Oi from Visual Studio tool chains.
Remove /Oi from Visual Studio tool chains. because of the following reasons:
1. Intrinsic is Compiler-dependent.
2. Adding /Oi (Generate Intrinsic Functions) doesn't promise 100% replacing
the function call with inline functions.
/Oi is only a request, but doesn't force, the compilers to use the intrinsic.
The visual studio optimizer can still use the library version.
3. Since EDK2 doesn't include Visual Studio header files, intrinsic function
should not be used.
Built Nt32Pkg, OvmfPkg, ShellPkg, MdeModulePkg and CryptoPkg successfully.
It's been a month since the following commits appeared in the repo:
4014885ffdfa8 OvmfPkg: switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe c47ed6fcb5e60 OvmfPkg: match PCI config access to machine type (if not
USE_OLD_PCI_HOST)
in which we introduced the USE_OLD_PCI_HOST fallback, and made other work
depend on it. I have not heard of any problems (primarily from the
vfio-users group that uses Gerd's daily / hourly OVMF builds), so it's
time to drop the fallback.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Jordan Justen [Wed, 6 Apr 2016 06:18:57 +0000 (23:18 -0700)]
EmulatorPkg: Convert to always build FatPkg
Now that FatPkg is open source (and therefore can be included in the
EDK II tree) we always build and use it directly.
Build and boot tested with GCC 5.3 on X64, but I did not test
attaching a disk image with a FAT filesystem.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Cc: Andrew Fish <afish@apple.com> Reviewed-by: Andrew Fish <afish@apple.com>
ArmVirtPkg: drop dependency on PeiPcdLib for PEI Pcd.inf
The PcdPeim dynamic PCD driver is dispatched explicitly via an 'A PRIORI'
declaration in the platform DSC. Without that declaration, the PEI module
can never be dispatched since it transitively (via PeiPcdLib) depends on
a PPI it produces itself. So use the NULL PcdLib explicitly only for
this driver.
ArmVirtPkg: drop dependency on DxePcdLib for DXE Pcd.inf
The PcdDxe dynamic PCD driver is dispatched explicitly via an 'A PRIORI'
declaration in the platform DSC. Without that declaration, the DXE driver
can never be dispatched since it transitively (via DxePcdLib) depends on
protocols it produces itself. So use the NULL PcdLib explicitly only for
this driver.
The S3Ready() functional code has been moved to S3SaveStateDxe in
MdeModulePkg, the ACPI global variable related code is leaved as is
for compatibility.
PcdS3BootScriptStackSize is also moved to MdeModulePkg.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jeff Fan <jeff.fan@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Star Zeng [Thu, 7 Apr 2016 10:19:28 +0000 (18:19 +0800)]
IntelFrameworkModulePkg AcpiS3SaveDxe: Consume PcdAcpiS3Enable to control the code
Cc: Jeff Fan <jeff.fan@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Star Zeng [Thu, 7 Apr 2016 10:19:26 +0000 (18:19 +0800)]
MdeModulePkg S3SaveStateDxe: Move S3Ready() functional code from AcpiS3SaveDxe
The S3Ready() functional code in AcpiS3SaveDxe of IntelFrameworkModulePkg
is to do ACPI S3 Context save. In fact, that is not really related to
Intel framework ACPI S3 protocol.
IntelFrameworkModulePkg will be deprecated step by step, so move the
functional code to MdeModulePkg and S3SaveStateDxe is a good place.
The ACPI global variable related code is leaved as is in IntelFrameworkModulePkg
AcpiS3SaveDxe for compatibility.
PcdS3BootScriptStackSize is also moved from IntelFrameworkModulePkg.
The functional code need to get ACPI FACS table and consume LockBoxLib,
so need to be before DxeSmmReadyToLock that will shut down SMM lock box
interface, EndOfDxe is a good point (OVMF AcpiS3SaveDxe has the reference
implementation).
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
projects / mirror_edk2.git / log