Hi,
I managed to trace down the issues with my UEFI ported code for a Cortex-A9 MP
core based SoC.
I see two issues (after solving a few on the way) on which I cannot seem to
make any headway.
1. gST->ConOut is NULL causing the Print routines inside
StartDefaultBootOnTimeout
(https://gith
LockBoxLib has two sets of implementations. The Null implementation (which
is the OVMF default) is not useful for us any longer; we need the library
instances that back the LockBox structure with SMRAM -- the SmmLockBoxLib
variants.
These variants (library instances) are for:
- DXE_DRIVER, DXE_RUN
This is a rogue SMM driver. It runs in SMM mode and has access to
confidential SMM data. It saves the address of the SMST for the next
patch, in runtime storage pointed-to by the PCD added in the previous
patch, and exits.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Lasz
In the next patch we'll add a driver that exposes the SMM System
Management System Table (normally only accessible in SMM) to the world.
For this purpose we allocate a PCD called PcdDiscloseSmstPtrPtr that
contains a pointer to the pointer to the SMST.
PCD value, pointer to
lost at warm
This mostly no-op runtime DXE driver produces the EFI_SMM_ACCESS2_PROTOCOL
and EFI_SMM_CONTROL2_PROTOCOL protocols, enabling the SMM core to be
loaded in the next patch.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek
---
OvmfPkg/EmuSmmDxe/EmuSmmDxe.inf | 55
"MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf" produces
gEfiSmmLockBoxCommunicationGuid, implementing LockBox services in SMRAM
for the SmmLockBoxLib library (used in the following patches).
gEfiSmmLockBoxCommunicationGuid
EFI_SMM_ACCESS2_PROTOCOL [EmuSmmDxe]
gEfiSmmSwDispatc
"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/Generic
Data is transferred between S3 Suspend and S3 Resume as follows:
S3 Suspend (DXE):
(1) prepare boot script:
EFI_S3_SAVE_STATE_PROTOCOL.Write() [S3SaveStateDxe]
S3BootScriptLib [PiDxeS3BootScriptLib]
- opcodes & arguments are saved in NVS. -+
"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
"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()
"MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" is the library
instance that implements the LockBoxLib library class with SMRAM access
for the PEI phase.
Introduce a PEIM that produces the EFI_PEI_SMM_COMMUNICATION_PPI and
PEI_SMM_ACCESS_PPI interfaces, enabling SmmLockBoxPeiLib to work.
Please refer to the last patch in the series to appreciate the
complexity here. I'd like to ask interested people in the community to
read through the commit messages (*) and point out if I'm missing
something.
(*) There isn't much code in the series, it's mostly duct tape. The
difficulty is figur
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
The SmmLockBox driver in
"MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf" currently
specifies a DepEx on EFI_SMM_SW_DISPATCH2_PROTOCOL.
However, the driver doesn't use this protocol at all, either directly or
indirectly. It calls SmiHandlerRegister()
[MdeModulePkg/Core/PiSmmCore/Smi.c] t
"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.
S3SaveStat
The same trick is used as for the original NvVars emulation; the
allocation is done early so that it ends up at an invariant address across
warm reboot.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek
---
OvmfPkg/PlatformPei/PlatformPei.inf | 2 ++
OvmfPkg/Pl
The low-level data transfer between S3 Suspend and S3 Resume happens thru
SMRAM. SMRAM is theoretically accessible to SMM drivers only; other
("untrusted") drivers can only talk to the former via
EFI_SMM_COMMUNICATION_PROTOCOL.
"MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf" implements the SMM Initial
On Dec 2, 2013, at 3:08 AM, Bhupesh Sharma wrote:
> Hi,
>
> I managed to trace down the issues with my UEFI ported code for a Cortex-A9
> MP core based SoC.
>
> I see two issues (after solving a few on the way) on which I cannot seem to
> make any headway.
>
> 1. gST->ConOut is NULL causing
Jordan,
Only rule is that TokenNumber must be unique within the TokenSpaceGuid.
Reviewed-by: Michael Kinney <>
Mike
-Original Message-
From: Jordan Justen [mailto:jljus...@gmail.com]
Sent: Saturday, November 30, 2013 3:56 PM
To: Kinney, Michael D; Wei Liu
Cc: xen-devel; edk2-devel@list
On Mon, Dec 2, 2013 at 9:04 AM, Laszlo Ersek wrote:
> Please refer to the last patch in the series to appreciate the
> complexity here. I'd like to ask interested people in the community to
> read through the commit messages (*) and point out if I'm missing
> something.
>
> (*) There isn't much co
Reviewed-by: Jaben Carsey
14926
From: Phillips, Chris J (BCS CFE) [mailto:chr...@hp.com]
Sent: Tuesday, November 26, 2013 4:12 PM
To: edk2-devel@lists.sourceforge.net; Carsey, Jaben
Subject: ShellPkg: Fix pci command to parse arguments as hex
Importance: High
Please review the attached patch f
As Jordan mentioned, one must add the statement
!include StdLib/StdLib.inc
to their .dsc file. This will cause the necessary Library Classes to be
defined as well as setting up the build options needed for StdLib based
applications. This should go at the end of the .dsc file.
T
Hi Laszlo
Thanks! This update seems good.
And we need more test to see if there is any impact on real platforms, because
of dependency change.
Reviewed-by: Jiewen Yao
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Monday, December 02, 2013 9:05 AM
To: edk2-devel
Hi Justen,
No, it is not even returning an error. The GUIDs match, I have verified
them.
Regards,
Nishit
On Sun, Dec 1, 2013 at 3:12 AM, Jordan Justen wrote:
> On Sat, Nov 30, 2013 at 10:35 AM, Nishit Patira
> wrote:
> > Hii,
> >
> > Yes, it is by a DXE Driver. However, it is not returning a
Nishit,
#1. Can you verify that the first 8 bytes of SystemTable are 0x5453595320494249?
#2. What did you do before calling LocateProtocol?
Thanks,
Ray
From: Nishit Patira [mailto:nishitpat...@gmail.com]
Sent: Tuesday, December 03, 2013 12:09 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [
Nishit,
Could you please attach your draft source where the locate protocol works and
doesn't work. That might give us some idea where are going wrong.
Thanks,
Ramesh
From: Nishit Patira [mailto:nishitpat...@gmail.com]
Sent: Tuesday, December 03, 2013 9:39 AM
To: edk2-devel@lists.sourceforge.
26 matches
Mail list logo
