Laszlo Ersek [Tue, 4 Mar 2014 08:04:13 +0000 (08:04 +0000)]
OvmfPkg: S3 Resume: pull in BootScriptExecutorDxe
This driver (from
"MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf")
is first loaded normally during DXE. When the
EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL is installed by any DXE driver (purely
as a form of notification), the driver reloads itself to reserved memory.
During S3 Resume / PEI, the driver image is executed from there. In order
to access the boot script saved during S3 Suspend, LockBox access is
needed.
The boot script is transferred internal to PiDxeS3BootScriptLib:
Both S3SaveStateDxe and BootScriptExecutorDxe are statically linked
against PiDxeS3BootScriptLib. Whichever is loaded first (during normal
boot, in the DXE phase), allocates the root storage for the script. The
address is then passed between the PiDxeS3BootScriptLib instances living
in the two separate drivers thru the dynamic
PcdS3BootScriptTablePrivateDataPtr PCD.
Laszlo Ersek [Tue, 4 Mar 2014 08:04:04 +0000 (08:04 +0000)]
OvmfPkg: S3 Resume: fake LockBox protocol for BootScriptExecutorDxe
BootScriptExecutorDxe, to be pulled in in the next patch, was written with
the SMM implementation of LockBox in mind. That implementation is split in
the following three parts:
- client side (DXE/PEI) library,
- SMM driver producing gEfiLockBoxProtocolGuid,
- driver side (SMM) library.
BootScriptExecutorDxe includes the client side LockBoxLib. So that the
library can communicate with the SMM LockBox driver, BootScriptExecutorDxe
has a Depex on gEfiLockBoxProtocolGuid, normally installed by the SMM
LockBox driver. This is actually not a hard dependency, it just ensures
correct load order between BootScriptExecutorDxe and
MdeModulePkg/Universal/LockBox/SmmLockBox.
The (client side) LockBox library instance in OVMF doesn't depend on a
separate driver that produces gEfiLockBoxProtocolGuid. Nothing produces
that GUID right now in OVMF. This prevents BootScriptExecutorDxe from
loading.
Install gEfiLockBoxProtocolGuid in our only S3-specific, custom DXE
driver, in order to enable loading of BootScriptExecutorDxe.
Laszlo Ersek [Tue, 4 Mar 2014 08:03:56 +0000 (08:03 +0000)]
OvmfPkg: S3 Suspend: save boot script after ACPI context
The trigger to actually save the boot script is the installation of
EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL, to be performed by any DXE driver.
Installation of the protocol also locks down SMM (as its name indicates)
and (in theory) prevents further LockBox access.
We cannot install this protocol before BdsLibBootViaBootOption() is called
(eg. in OVMF's PlatformBdsPolicyBehavior()), because
BdsLibBootViaBootOption() calls EFI_ACPI_S3_SAVE_PROTOCOL.S3Save(), which
needs LockBox access.
We also can't install the protocol after BdsLibBootViaBootOption()
returns, simply because control is never returned to us.
Therefore modify our EFI_ACPI_S3_SAVE_PROTOCOL implementation so that the
boot script is prepared and installed internally to S3Save().
(The boot script must contain at least one opcode, otherwise
S3BootScriptLib runs into an assertion failure. We add a harmless (no-op)
"information" opcode.)
Laszlo Ersek [Tue, 4 Mar 2014 08:03:50 +0000 (08:03 +0000)]
OvmfPkg: S3 Suspend: enable creation/saving of an S3 Boot Script
"MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf" produces
the EFI_S3_SAVE_STATE_PROTOCOL which allows creation and saving of an S3
Boot Script, to be replayed in PEI during S3 Resume. The script contains
opcodes and opcode arguments to configure CPU, PCI and IO resources.
S3SaveStateDxe relies on the S3BootScriptLib library. The Null
implementation is not useful for actually saving the boot script, we need
the PiDxeS3BootScriptLib instance.
The PiDxeS3BootScriptLib library instance depends on LockBoxLib,
implemented for OVMF in one of the previous patches.
PiDxeS3BootScriptLib also depends on SmbusLib. For now we opt for the Null
instance of the latter. It means that SMBus commands in the boot script
will have no effect when interpreted during S3 Resume. This should be fine
for OvmfPkg and QEMU.
When the EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL is installed by any DXE driver
(purely as a form of notification), the S3SaveStateDxe driver saves the
boot script to EfiACPIMemoryNVS, and links it into the LockBox.
Laszlo Ersek [Tue, 4 Mar 2014 08:03:38 +0000 (08:03 +0000)]
OvmfPkg: S3 Suspend: save ACPI context
"OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf" (originally:
"IntelFrameworkModulePkg/Universal/Acpi/AcpiS3SaveDxe/AcpiS3SaveDxe.inf")
produces the EFI_ACPI_S3_SAVE_PROTOCOL.
When found, this protocol is automatically invoked by
BdsLibBootViaBootOption(), in file
"IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c", right before
booting a boot option, to save ACPI S3 context.
At that point during BDS, our AcpiPlatformDxe driver will have installed
the FACS table (which AcpiS3SaveDxe has a use-time dependency upon).
With regard to dependencies: AcpiS3SaveDxe implements
EFI_ACPI_S3_SAVE_PROTOCOL by relying on LockBoxLib.
Laszlo Ersek [Tue, 4 Mar 2014 08:03:31 +0000 (08:03 +0000)]
OvmfPkg: S3 Suspend: import specialized copy of AcpiS3SaveDxe
"IntelFrameworkModulePkg/Universal/Acpi/AcpiS3SaveDxe/AcpiS3SaveDxe.inf"
currently specifies a DepEx on gEfiMpServiceProtocolGuid (MP Services).
The justification is the following code sequence:
InstallAcpiS3Save()
if PcdFrameworkCompatibilitySupport is set:
InstallAcpiS3SaveThunk()
if EFI_MP_SERVICES_PROTOCOL is available:
GetVariable(ACPI_GLOBAL_VARIABLE)
In English, the AcpiS3SaveDxe driver insists on the presence of MP
Services *unconditionally* because,
- if PcdFrameworkCompatibilitySupport is set (the default is false),
- and MP Services are available (which is constant true under the above
condition),
then the AcpiS3SaveDxe driver would like to get the ACPI_GLOBAL_VARIABLE
variable from the MP Services driver, rather than setting it itself.
The DepEx prevents AcpiS3SaveDxe from loading under OvmfPkg, since we
provide no MP Services implementation. This is particularly broken since
the default PcdFrameworkCompatibilitySupport value is FALSE, making the
entire code that would look at EFI_MP_SERVICES_PROTOCOL dead.
Copy AcpiS3SaveDxe to OvmfPkg, substitute PcdFrameworkCompatibilitySupport
with constant FALSE, and remove all code that becomes dead, including the
DepEx.
Laszlo Ersek [Tue, 4 Mar 2014 08:03:23 +0000 (08:03 +0000)]
OvmfPkg: implement LockBoxLib
The S3 suspend/resume infrastructure depends on the LockBox library class.
The edk2 tree currently contains Null and SMM instances. The Null instance
is useless, and the SMM instance would require SMM emulation by including
the SMM core and adding several new drivers, which is deemed too complex.
Hence add a simple LockBoxLib instance for OVMF.
jordan.l.justen@intel.com:
* use PCDs instead of EmuNvramLib
- clear memory in PlatformPei on non S3 boots
* allocate NVS memory and store a pointer to that memory
- reduces memory use at fixed locations
Laszlo Ersek [Tue, 4 Mar 2014 08:03:06 +0000 (08:03 +0000)]
OvmfPkg: S3 Resume: pull in PEIM orchestrating S3 Resume
"UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf" produces the
EFI_PEI_S3_RESUME2 PEIM-to-PEIM Interface.
When the platform-specific initialization code (in PEI) sets the Boot Mode
to BOOT_ON_S3_RESUME, the DXE IPL (which is the last step in PEI) skips
the DXE phase entirely, and executes the S3 Resume PEIM through the
EFI_PEI_S3_RESUME2 interface instead. (See DxeLoadCore() in
"MdeModulePkg/Core/DxeIplPeim/DxeLoad.c".)
Jordan Justen [Tue, 4 Mar 2014 08:02:59 +0000 (08:02 +0000)]
OvmfPkg/PlatformPei: Allocate PEI FV as ACPI NVS if S3 is supported
On S3 resume, we skip decompression of the PEI FV, and expect
to jump directly into it. For this to work, we need the OS to
leave the memory range untouched.
Laszlo Ersek [Tue, 4 Mar 2014 08:02:52 +0000 (08:02 +0000)]
OvmfPkg: PlatformPei: reserve early page tables on X64
On X64, the reset vector code in
"OvmfPkg/ResetVector/Ia32/PageTables64.asm" identity maps the first 4GB of
RAM for PEI, consuming six frames starting at 8MB.
This range is declared by the PcdOvmfSecPageTablesBase/Size PCDs.
Jordan Justen [Tue, 4 Mar 2014 08:02:30 +0000 (08:02 +0000)]
OvmfPkg/PlatformPei: Skip various items for S3 resume
We will not be running DXE on S3 resume, so we don't
need to do these initialization items:
* Reserve EMU Variable memory range
* Declare Firmware volumes
* Add memory HOBs
v5:
* Move MiscInitialization back to running on S3 resume
because the compatibility framebuffer can't cover more than half of PCI
BAR #0. The latter defaults to 64MB in size, and is controlled by
"ram_size_mb".
The field name "ModeNumber" in QEMU_VIDEO_MODE_DATA is misleading -- it is
not immediately obvious whether this field carries a client-visible mode
number, in the GOP sense, or an internal, card type specific mode index.
After checking all references, rename the field to "InternalModeIndex".
Also, when filling in the card type independent QEMU_VIDEO_MODE_DATA array
from the card type specific mode array, distinguish the GOP mode number
from the internal mode index in the debug message.
Currently, QemuVideoGraphicsOutputQueryMode() reports EFI_NOT_STARTED when
this boolean field is set.
However, QemuVideoGraphicsOutputQueryMode() is only available to callers
after the GOP interface has been installed. That in turn implies that the
following partial call tree has succeeded without errors:
Laszlo Ersek [Mon, 3 Mar 2014 08:40:35 +0000 (08:40 +0000)]
OvmfPkg: QemuVideoDxe: disentangle UEFI driver model use in Stop()
A bus driver needs to pay attention whether its Stop() function is being
called on the "main" controller handle (NumberOfChildren == 0) or on the
child handles (NumberOfChildren > 0).
In QemuVideoDxe, all our resources are associated with the one child
handle (and the Private data structure) *except* the top-level PciIo
protocol reference. Be conscious of which mode Stop() is being called for.
Laszlo Ersek [Mon, 3 Mar 2014 08:40:28 +0000 (08:40 +0000)]
OvmfPkg: QemuVideoDxe: simplify UEFI driver model use in Supported() / Start()
A bus driver is allowed to ignore the actual value of RemainingDevicePath
in Supported() and Start(), and to produce all child handles at once.
This in effect means the following invariants for QemuVideoDxe:
- (RemainingDevicePath == NULL), and
- (Private->GopDevicePath != NULL)
Simplify Supported() and Start() by substituting constant TRUE and FALSE
(as appropriate) in expressions that check RemainingDevicePath and/or
Private->GopDevicePath.
In QemuVideoGraphicsOutputConstructor(), called by Start():
- supplement missing error checks:
- QemuVideoGraphicsOutputSetMode() retval (it can fail with
out-of-resources)
In QemuVideoCirrusModeSetup() and QemuVideoBochsModeSetup(), both called
by Start():
- supplement missing error checks:
- AllocatePool() can fail in both
In QemuVideoGraphicsOutputDestructor(), called by Start() on the error
path:
- plug leaks:
- free Private->LineBuffer, which is allocated in
Start() -> Constructor() -> SetMode()
In QemuVideoGraphicsOutputSetMode(), called by Start() indirectly:
- remove redundant zero-assignment to:
- Private->LineBuffer
Olivier Martin [Sat, 1 Mar 2014 11:00:07 +0000 (11:00 +0000)]
ArmPkg/ArmLib: Rationalise ArmReadMidr and cognate functions.
The function ArmReadMidr has been recently added, but that functionality was
already present under other names such as Cp15IdCode and ArmMainIdCode. This
change removes redundant code and moves the function to the Common library.
Olivier Martin [Sat, 1 Mar 2014 10:57:55 +0000 (10:57 +0000)]
ArmPkg: Replace single dead loop.
Several assembler macros use a loop at the label "dead" to trap an error.
This is difficult to debug as there is no indication of how one arrived at the loop.
This change replaces dead with distinct loops locally in the macro,
which means the cause of the hang is detectable to the debugger.
Olivier Martin [Mon, 24 Feb 2014 14:14:13 +0000 (14:14 +0000)]
edksetup.bat: Fixed corrupts CYGWIN_HOME
The .BAT file checks for existance of the directory c:\cygwin and,
if it exists, always resets CYGWIN_HOME to that path.
That means that if CYGWIN_HOME is set to say c:\cygwin64, it gets corrupted.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com>
Reviewed-by Yingke Liu <yingke.d.liu@intel.com>
Jaben Carsey [Tue, 18 Feb 2014 21:53:00 +0000 (21:53 +0000)]
ShellPkg: Update "ls" command to better handle "-r" parameter
This makes sure that recursion into sub directories looks through all subdirectories, not just those that match the initial search pass. Also only prints out any information for directories in which at least one matching file is found.
Olivier Martin [Mon, 17 Feb 2014 16:01:41 +0000 (16:01 +0000)]
Add flag to make UEFI run from DRAM or FLASH for FVPs
- By setting the 'ARM_FVP_RUN_NORFLASH' flag at compile time UEFI will
be linked to run from NOR FLASH0 on FVPs.
- The RAM load location is currently set to 128MB from base of DRAM.
Jaben Carsey [Wed, 12 Feb 2014 18:27:07 +0000 (18:27 +0000)]
ShellPkg: refactor elimination of non-replaced environment variables
This changes how non-replaced environment variables are found and eliminated from the command line. This new method makes sure that the found environment variables are not using escaped characters and that they do not stretch over quoted strings
Eric Dong [Wed, 12 Feb 2014 01:45:35 +0000 (01:45 +0000)]
Update the logic, only check the value change status for user input action, not detect the change caused by Hii driver change through SetBrowserData function.
Brendan Jackman [Tue, 11 Feb 2014 22:39:49 +0000 (22:39 +0000)]
ShellPkg: Manually parse parameters
We can't use ShellCommandLineParse as it would error out when the shell was
called with args like "cp -r foo bar", because "-r" is not a recognised shell
option
A different way to avoid some of this manual parsing would be to prepend '^' to
each argument, but that would still require the degree of parsing necessary to work
out which words are part of the command and which are shell options.
ShellPkg: patch to the "for" command when used with "in" iterating files in a folder. (for %x in *.txt). The result values (%x) have misplaced quotation marks and some spaces.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Leandro G. Biss Becker <lbecker@positivo.com.br> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15212 6f19259b-4bc3-4df7-8a09-765794883524