We are going to reduce reserved memory consumption by page table buffer,
then OS can have more available memory to use.
Take PhysicalAddressBits = 48 and 2MB page granularity as example,
1:1 Virtual to Physical identity mapping page table buffer needs to be
((512 + 1) * 512 + 1) * 4096 = 1075843072 bytes = 0x40201000 bytes.
The code is updated to build 4G page table by default and only use 8 extra
pages to handles > 4G request by page fault.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18069 6f19259b-4bc3-4df7-8a09-765794883524
Reduce reserved memory consumption by page table buffer,
then OS can have more available memory to use.
Take PhysicalAddressBits = 48 and 2MB page granularity as example,
1:1 Virtual to Physical identity mapping page table buffer needs to be
((512 + 1) * 512 + 1) * 4096 = 1075843072 bytes = 0x40201000 bytes.
When BIOS does not support long mode waking vector, only allocate
2 pages (1G page enabled) or 6 pages for 4G page table, and 8 extra
pages to handles > 4G request by page fault.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18068 6f19259b-4bc3-4df7-8a09-765794883524
We are going to reduce reserved memory consumption by page table buffer,
then OS can have more available memory to use.
Take PhysicalAddressBits = 48 and 2MB page granularity as example,
1:1 Virtual to Physical identity mapping page table buffer needs to be
((512 + 1) * 512 + 1) * 4096 = 1075843072 bytes = 0x40201000 bytes.
Current BootScriptExecutorDxe handles > 4G request by page fault because
S3ResumePeim only builds 4G page table when long mode waking vector is
not needed, but BootScriptExecutorDxe still assume the page table buffer for
page table is at 1:1 Virtual to Physical identity mapping.
To reduce reserved memory consumption, the code is updated to only use
8 extra pages to handles > 4G request by page fault.
Another, when both BIOS and OS wants long mode waking vector,
S3ResumePei should have established 1:1 Virtual to Physical identity mapping
page table for ACPI spec requirement, so no need to hook page fault handler.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18067 6f19259b-4bc3-4df7-8a09-765794883524
Fix an error which leads the building process crashes.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: fanwang2 <fan.wang@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18066 6f19259b-4bc3-4df7-8a09-765794883524
As variable HEADER_ALIGNMENT = 4, the MonotonicCount in
AUTHENTICATED_VARIABLE_HEADER may be not UINT64 aligned,
so go to use ReadUnaligned64() to ensure read data correctly.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18064 6f19259b-4bc3-4df7-8a09-765794883524
For AARCH64, do not define a memcpy function in stdlib because it is
already defined in CompilerIntrinsicsLib.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-by: Daryl McDaniel <edk2-lists@mc2research.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18063 6f19259b-4bc3-4df7-8a09-765794883524
When there are multiple network boot options, user will see multiple
"UEFI Network" boot options. It's hard to distinguish them using the
description.
The patch enhances the boot option generation logic to append " 2"
/" 3"/" 4"/... number suffix to the non-first network boot options.
So the 2nd one becomes "UEFI Network 2".
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18062 6f19259b-4bc3-4df7-8a09-765794883524
The recent patch titled
IntelFrameworkModulePkg/GenericBdsLib: remove AcpiS3->S3Save() call
has exposed a preexistent bug in the BdsLibBootViaBootOption() function,
and now the IA32 build of OVMF fails with:
In function 'BdsLibBootViaBootOption':
error: 'Status' may be used uninitialized in this function
Namely, we have the following (simplified) data flow:
//
// Status and ImageHandle both start out uninitialized
//
/* ... */
ImageHandle = BdsExpandUsbShortFormDevicePath (DevicePath);
/* ... */
if (ImageHandle == NULL) {
/* ... */
}
if ((ImageHandle == NULL) || (EFI_ERROR(Status))) {
/* ... */
*/
If BdsExpandUsbShortFormDevicePath() returns a non-NULL value, then the
second "if" statement will check Status without the function having
initialized or assigned it.
When BdsExpandUsbShortFormDevicePath() returns non-NULL, Status should be
EFI_SUCCESS; so let us assign it that value up-front.
Note that the bug existed before the patch
IntelFrameworkModulePkg/GenericBdsLib: remove AcpiS3->S3Save() call
That is, the bug was not introduced, only exposed, by the patch -- in the
pre-patch state, although the Status variable was set early and
unconditionally, the error code that it may have carried from the failed
gEfiAcpiS3SaveProtocolGuid lookup had nothing to do with the second "if"
statement above.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jeff Fan <jeff.fan@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18061 6f19259b-4bc3-4df7-8a09-765794883524
The Length parameter of 'GetNextParameter' is the buffer size in bytes.
While StrnCpys requires user to pass the max number of dest unicode char,
we should convert size in bytes to the number of char.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin <shumin.qiu@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
[lersek@redhat.com: updated commit message as requested by Jaben]
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18059 6f19259b-4bc3-4df7-8a09-765794883524
When a quoted string is used as initialization data in a DEC file PCD
entry, the PCD data type in that entry must be VOID*. The created
AutoGen.c defines the PCD data as UINT8[] or UINT16[], depending on
the string type. The created AutoGen.h, however, declares the PCD data
as VOID*. For a standard compile/link, this works because AutoGen.c
doesn't include AutoGen.h. But when GCC LTO is used, the link time
code generation detects the mismatch and the build fails. This
change makes the AutoGen.h PCD data declaration match the AutoGen.c
definition.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-by: Yingke Liu <yingke.d.liu@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18058 6f19259b-4bc3-4df7-8a09-765794883524
GatewayIpAddress and SubnetMask do not exist in old IPv4_DEVICE_PATH, this
will lead new IScsiDxe to error if IPv4_DEVICE_PATH in system is not
updated.
Following UEFI2.5 spec of IPv4_DEVICE_PATH do a check before accessing
fields only defined in new version, add a judgement here to make old
IPv4_DEVICE_PATH and new IScsiDxe can cowork.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: fanwang2 <fan.wang@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
[lersek@redhat.com: rewrapped commit message]
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18057 6f19259b-4bc3-4df7-8a09-765794883524
GatewayIpAddress and SubnetMask do not exist in old IPv4_DEVICE_PATH,
IPAddressOrigin, PrefixLength and GatewayIPAddress do not exist in old
IPv6_DEVICE_PATH. This will lead new IScsiDxe to error without updating
IPv4_DEVICE_PATH and IPv6_DEVICE_PATH in system.
Following UEFI2.5 spec of IPv4_DEVICE_PATH do a check before accessing
fields only defined in new version's IPv4_DEVICE_PATH, and revise the same
issue for IPv6_DEVICE_PATH in Iscsi driver.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: fanwang2 <fan.wang@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
[lersek@redhat.com: rewrapped commit message]
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18056 6f19259b-4bc3-4df7-8a09-765794883524
Originally, the double pointer (VOID **) is not correct for convert
address pointers, and also some address pointers were missing.
Cc: Jiewen Yao <jiewen.yao@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>
[lersek@redhat.com: fix up gcc build failure -- add more (VOID **) casts]
Tested-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18055 6f19259b-4bc3-4df7-8a09-765794883524
When mismatch happens,there exists one case that exit current
form and display last form.Assert code don't cover this case.
Now add check to handle this situation.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18053 6f19259b-4bc3-4df7-8a09-765794883524
The first parameter of match2 opcode should be the pattern
and the second one should be the string.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18052 6f19259b-4bc3-4df7-8a09-765794883524
EFI_UNSPECIFIED_TIMEZONE means display local time. TZ of 0 is UTC.
Thus EFI_UNSPECIFIED_TIMEZONE means ignore TZ, 0 means UTC. When this code is
fixed to adust file TZ to local TZ you need to preserve
EFI_UNSPECIFIED_TIMEZONE.
FAT always return EFI_UNSPECIFIED_TIMEZONE.
Modern filesystems, HFS+, NTFS, ext3, etc store time in UTC.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Andrew Fish <afish@apple.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18051 6f19259b-4bc3-4df7-8a09-765794883524
if the instance of the DHCP4 protocol driver is in the Dhcp4Bound
status that is DHCP configuration has completed, so the Dhcp4->Start
FUNC in the EfiPxcBcDhcp() will return EFI_ALREADY_STARTED status
which lead to EfiPxeBcDhcp FUNC not in correspondence with UEFI spec.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo <lubo.zhang@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
[lersek@redhat.com: updated copyright year as Siyuan asked]
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18050 6f19259b-4bc3-4df7-8a09-765794883524
if the instance of the EFI DHCP4 protocol driver is in the Dhcp4Bound status
that is DHCP configuration has completed, so the Dhcp4->Start FUNC in
the PxeBcDhcpDora() will return EFI_ALREADY_STARTED status which lead to
EfiPxeBcDhcp FUNC not in correspondence with UEFI spec.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo <lubo.zhang@intel.com>
Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
[lersek@redhat.com: updated copyright year as requested by Siyuan]
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18049 6f19259b-4bc3-4df7-8a09-765794883524
Fix git 59a8cfd4 (SVN r17869) removes DHCP4.TransmitReceive()and DORA
process dependency, but it updated TransmitReceive() to take the ownership
of DhcpSb->ActiveChild but never release it. This will break the retransmit
and lease time out counter of DORA.
To fix that, TransmitReceive() doesn't need to be the ActiveChild, and the
timer routine should be updated to handle the TransmitReceive specially.
Cc: Fu Siyuan <siyuan.fu@intel.com>
Cc: Ye Ting <ting.ye@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18048 6f19259b-4bc3-4df7-8a09-765794883524
ReadMemoryFileLine () appends a NULL character to the string
it returns, but it failed to account for it in the allocation.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Yingke Liu <yingke.d.liu@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18047 6f19259b-4bc3-4df7-8a09-765794883524
Retire Olivier Martin as maintainer, and add in
Ard Biesheuvel as a co-maintainer for the ARM packages.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18046 6f19259b-4bc3-4df7-8a09-765794883524
(This patch parallels OvmfPkg commit 37baf06b (SVN r17676).)
PcdSmbiosVersion controls the version number of the SMBIOS entry point
table (and other, related things) that the universal
"MdeModulePkg/Universal/SmbiosDxe" driver, providing EFI_SMBIOS_PROTOCOL,
installs.
The "virt" machine type of QEMU generates SMBIOS payload for the firmware
to install. The payload includes the entry point table ("anchor" table).
OvmfPkg/SmbiosPlatformDxe cannot install the anchor table (because that is
the jurisdiction of the generic "MdeModulePkg/Universal/SmbiosDxe"
driver); however, we can parse the entry point version from QEMU's anchor
table, and instruct "MdeModulePkg/Universal/SmbiosDxe" to adhere to that
version.
As default for PcdSmbiosVersion we should keep the current 0x0300 value
(ie. SMBIOS 3.0) from "MdeModulePkg/MdeModulePkg.dec"; that spec version
was specifically created for ARM / AARCH64 needs.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18043 6f19259b-4bc3-4df7-8a09-765794883524
Many universal DXE drivers in edk2 can be controlled by setting dynamic
PCDs. Such a PCD must be set before the consumer DXE driver is dispatched.
(In general we assume that the DXE driver will consume the PCD in its
entry point, or in the constructor of a library instance it links against.
In special cases this requirement can be relaxed a bit, if we know that
the DXE driver accesses the PCD only in a protocol member function that it
exports.)
On the QEMU platform, the PCD values to be set for the universal drivers
are frequently derived from fw_cfg files that QEMU exports.
In OvmfPkg we tend to handle this in the following way:
- For IA32 and X64, OvmfPkg provides a QemuFwCfgLib instance that is
usable in PEI.
- In PlatformPei, fw_cfg files can be loaded and transformed to PCD
values.
- Any DXE driver is bound to be dispatched after the PEI phase is done.
(In specific cases other ordering solutions might be possible, via Depex
or protocol notify, etc.)
In ArmVirtPkg/ArmVirtQemu, things differ a bit:
- We don't have an ArmVirtPkg-specific ("Platform") PEIM. This is actually
a good thing for now, so let's not introduce one just for this purpose.
- Even if we had such a PEIM, it could not easily access fw_cfg: the MMIO
addresses of the fw_cfg device are available only in the DTB that QEMU
exports.
(Accordingly, our QemuFwCfgLib instance is restricted to DXE_DRIVER
modules: VirtFdtDxe parses the DTB, stores the fw_cfg addresses in PCDs,
and then QemuFwCfgLib's constructor fetches those PCDs.)
There are some examples in ArmVirtPkg where early code is forced to
parse the DTB manually, but those examples are all painful, and our goal
here (controlling universal DXE drivers) doesn't justify more of that
pain.
Therefore, introduce a separate, minimal DXE driver that is dispatched
strictly after VirtFdtDxe (so that it can use QemuFwCfgLib), and strictly
before other DXE drivers (so that it can set dynamic PCDs for them).
Because VirtFdtDxe is already ordered with the APRIORI DXE file, it is
simplest to do the same for the new driver.
Actual fw_cfg files and PCDs shall be accessed in future patches.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18042 6f19259b-4bc3-4df7-8a09-765794883524
This driver is soon going to be built by ArmVirtPkg/ArmVirtQemu.dsc
(without any changes). Although VALID_ARCHITECTURES is not used by the
build system (it is just a comment), it is best kept up-to-date for human
readers' sake.
Cc: Feng Tian <feng.tian@intel.com>
Cc: Elvin Li <elvin.li@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18041 6f19259b-4bc3-4df7-8a09-765794883524
The Xen code in SmbiosPlatformDxe is centered on the informational HOB
with GUID gEfiXenInfoGuid, and the address constants
XEN_SMBIOS_PHYSICAL_ADDRESS=0x000EB000,
XEN_SMBIOS_PHYSICAL_END=0x000F0000.
This Xen hand-off mechanism is specific to the IA32 and X64 architectures,
and it is very unlikely that a future ARM / AARCH64 implementation would
follow it. Therefore, sequester the IA32 / X64 specific code from the rest
of the source, by renaming "Xen.c" to "X86Xen.c", and adding a
GetXenSmbiosTables() stub function in "ArmXen.c" that returns NULL.
(Those file names are inspired by
"OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c".)
The call site in SmbiosTablePublishEntry() [SmbiosPlatformDxe.c] is aware
that a NULL return value means "Xen SMBIOS tables not found", and will
continue to the QEMU tables (for which the retrieval mechanism is shared
by x86 and Arm).
This change enables SmbiosPlatformDxe for ARM architectures; update the
VALID_ARCHITECTURES comment accordingly.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Gabriel Somlo <somlo@cmu.edu>
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@18040 6f19259b-4bc3-4df7-8a09-765794883524
This function is only called from Xen.c, so it should be defined in Xen.c
and have internal linkage (ie. STATIC).
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Gabriel Somlo <somlo@cmu.edu>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18039 6f19259b-4bc3-4df7-8a09-765794883524
At this point, nothing in the OVMF build calls EFI_ACPI_S3_SAVE_PROTOCOL
member functions; simplify the code by dropping this protocol interface.
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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18038 6f19259b-4bc3-4df7-8a09-765794883524
Currently we have the following call chain in OVMF:
PlatformBdsPolicyBehavior()
[OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
//
// signals End-of-Dxe
//
OnEndOfDxe() [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c]
S3Ready() [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c]
//
// 1. saves S3 state
//
SaveS3BootScript() [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c]
//
// 2. saves INFO opcode in S3 boot script
// 3. installs DxeSmmReadyToLockProtocol
//
The bottom of this call chain was introduced in git commit 5a217a06 (SVN
r15305, "OvmfPkg: S3 Suspend: save boot script after ACPI context"). That
patch was necessary because there was no other way, due to GenericBdsLib
calling S3Save() from BdsLibBootViaBootOption(), to perform the necessary
steps in the right order:
- save S3 system information,
- save a final (well, only) boot script opcode,
- signal DxeSmmReadyToLock, closing the boot script, and locking down
LockBox and SMM.
The GenericBdsLib bug has been fixed in the previous patch -- the call in
BdsLibBootViaBootOption() has been eliminated.
Therefore, hoist the SaveS3BootScript() code, and call, from
OvmfPkg/AcpiS3SaveDxe, to PlatformBdsLib:
PlatformBdsPolicyBehavior()
[OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
//
// signals End-of-Dxe
//
OnEndOfDxe() [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c]
S3Ready() [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c]
//
// 1. saves S3 state
//
<---
SaveS3BootScript() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
//
// 2. saves INFO opcode in S3 boot script
// 3. installs DxeSmmReadyToLockProtocol
//
The installation of DxeSmmReadyToLockProtocol belongs with Platform BDS,
not AcpiS3SaveDxe, and we can now undo the hack in SVN r15305, without
upsetting the relative order of the steps.
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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18037 6f19259b-4bc3-4df7-8a09-765794883524
The AcpiS3->S3Save() call needs to occur before the end-of-DXE event
is signalled. The end-of-DXE event needs to be signalled prior to
invoking any UEFI drivers, applications, or connecting consoles.
This means the call to S3Save() that occurs in BdsLibBootViaBootOption()
violates the ordering constraints, and should be removed. Since it is
the responsibility of the platform BDS to signal the end-of-DXE event,
it should also perform the AcpiS3->S3Save() call at an appropriate time.
Commit message update from Laszlo Ersek <lersek@redhat.com>:
Following Jiewen Yao's idea in
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/16088/focus=16146
platforms that
(1) use this exact instance of GenericBdsLib, *and*
(2) support S3
should now collect the S3 state
(3) in an End-of-Dxe callback in their AcpiS3SaveDxe drivers, *or*
(4) with an explicit AcpiS3->S3Save() call made to their AcpiS3SaveDxe
drivers from their PlatformBdsLib instances.
OvmfPkg, which uses this GenericBdsLib instance, and has its own
AcpiS3SaveDxe fork, follows (3).
Vlv2TbltDevicePkg, which has a GenericBdsLib fork, and uses
IntelFrameworkModulePkg/Universal/Acpi/AcpiS3SaveDxe, follows (4).
There are no other platforms in the public edk2 repository that support
S3.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.Yao@intel.com>
[lersek@redhat.com: updated commit message]
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Jiewen Yao <Jiewen.Yao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18036 6f19259b-4bc3-4df7-8a09-765794883524
(Paraphrasing git commit 9cd7d3c5 / SVN r17713:)
Currently, OvmfPkg fails to signal the End-of-Dxe event group when
entering the BDS phase, which results in some loss of functionality, eg.
variable reclaim in the variable driver, and the memory region splitting
in the DXE core that belongs to the properties table feature specified in
UEFI-2.5.
As discussed on the edk2-devel mailing list here:
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/16088/focus=16109
it is up to the platform BDS to signal End-of-Dxe, since there may be
platform specific ordering constraints with respect to the signalling of
the event that are difficult to honor at the generic level.
(OvmfPkg specifics:)
(1) In OvmfPkg, we can't signal End-of-Dxe before PCI enumeration
completes. According to the previous patch, that would trigger
OvmfPkg/AcpiS3SaveDxe to save S3 state *before* the following chain of
action happened:
- PCI enumeration completes
- ACPI tables are installed by OvmfPkg/AcpiPlatformDxe
- the FACS table becomes available
Since OvmfPkg/AcpiS3SaveDxe can only save S3 state once the FACS table
is available, we must delay the End-of-Dxe signal until after PCI
enumeration completes (ie. root bridges are connected).
(2) Pre-patch, S3Ready() in OvmfPkg/AcpiS3SaveDxe is entered from
BdsLibBootViaBootOption()
[IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c].
After the patch, we enter S3Ready() earlier than that, by signaling
End-of-Dxe in PlatformBdsPolicyBehavior(). The timing / location of
this new call is correct as well, and the original call (that now
becomes the chronologically second call) becomes a no-op: S3Ready() is
protected against 2nd and later entries.
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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18035 6f19259b-4bc3-4df7-8a09-765794883524
Call S3Ready() whenever the first of the following occurs:
- a driver signals End-of-Dxe,
- a driver calls EFI_ACPI_S3_SAVE_PROTOCOL.S3Save().
S3Ready() already contains a static, function scope "latch" that causes it
to exit early when called for the second time or later.
(At the moment, the only platform in the edk2 tree that includes this
driver is OvmfPkg. That platform does not signal End-of-Dxe (yet).)
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/16088/focus=16146
Suggested-by: Yao Jiewen <jiewen.yao@intel.com>
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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18034 6f19259b-4bc3-4df7-8a09-765794883524
We are preparing for detaching the S3Ready() functionality from the
EFI_ACPI_S3_SAVE_PROTOCOL.S3Save() protocol member function. Instead, we
will hook the same logic to the End-of-Dxe event group.
The EFI_ACPI_S3_SAVE_PROTOCOL has another member: GetLegacyMemorySize().
According to the documenation,
This function returns the size of the legacy memory (meaning below 1 MB)
that is required during an S3 resume. Before the Framework-based
firmware transfers control to the OS, it has to transition from flat
mode into real mode in case the OS supplies only a real-mode waking
vector. This transition requires a certain amount of legacy memory.
After getting the size of legacy memory below, the caller is responsible
for allocating the legacy memory below 1 MB according to the size that
is returned. The specific implementation of allocating the legacy memory
is out of the scope of this specification.
When EFI_ACPI_S3_SAVE_PROTOCOL.S3Save() is called, the address of the
legacy memory allocated above must be passed to it, in the
LegacyMemoryAddress parameter.
In practice however:
- The S3Ready() function ignores the LegacyMemoryAddress completely.
- No code in the edk2 tree calls
EFI_ACPI_S3_SAVE_PROTOCOL.GetLegacyMemorySize(), ever.
- All callers of this specific implementation of
EFI_ACPI_S3_SAVE_PROTOCOL.S3Save() in the edk2 tree pass a NULL
LegacyMemoryAddress:
BdsLibBootViaBootOption()
[IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c]
For this reason, ASSERT() explicitly that LegacyGetS3MemorySize() is never
called, and that the LegacyMemoryAddress parameter is always NULL.
This fact is important to capture in the code, because in the End-of-Dxe
callback, no LegacyMemoryAddress parameter can be taken. So let's make it
clear that we actually don't even have any use for that parameter.
This patch ports the identical change from IntelFrameworkModulePkg to
OvmfPkg.
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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18033 6f19259b-4bc3-4df7-8a09-765794883524
that assumes the SMRAM reserved range is only at the end of the SMRAM descriptor.
//
// This range has reserved area, calculate the left free size
//
gSmmCorePrivate->SmramRanges[Index].PhysicalSize = SmramResRegion->SmramReservedStart - gSmmCorePrivate->SmramRanges[Index].CpuStart;
Imagine the following scenario where we just reserve the first page of the SMRAM range:
SMRAM Descriptor:
Start: 0x80000000
Size: 0x02000000
Reserved Range:
Start: 0x80000000
Size: 0x00001000
In this case the adjustment to the SMRAM range size yields zero: ReservedStart - SMRAM Start is 0x80000000 - 0x80000000 = 0.
So even though most of the range is still free the IPL code decides its unusable.
The problem comes from the email thread: [edk2] PiSmmIpl SMRAM Reservation Logic.
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/15268
Also to follow the idea in the email thread, the patch is to
1. Keep only one copy of full SMRAM ranges in gSmmCorePrivate->SmramRanges,
split record for SmmConfiguration->SmramReservedRegions and SMM Core that
will be marked to be EFI_ALLOCATED in gSmmCorePrivate->SmramRanges.
2. Handle SmmConfiguration->SmramReservedRegions at beginning of, at end of,
in the middle of, or cross multiple SmramRanges.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18031 6f19259b-4bc3-4df7-8a09-765794883524
LocateProtocol only gets the 1st SNP instance and this will be wrong
in a system with multiple SNP instances installed. Use HandleProtocol
instead.
Cc: Olivier Martin <olivier.martin@arm.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Heyi Guo <heyi.guo@linaro.org>
Reviewed-by: Olivier Martin <Olivier.Martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18030 6f19259b-4bc3-4df7-8a09-765794883524
Recent changes have made the A15-A7 firmware bigger...
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <Olivier.Martin@arm.com>
Reviewed-by: Ronald Cron <Ronald.Cron@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18029 6f19259b-4bc3-4df7-8a09-765794883524
Spurious error might appear during network transaction,
ignore them when there are not relevant.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ronald Cron <Ronald.Cron@arm.com>
Reviewed-by: Olivier Martin <Olivier.Martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18028 6f19259b-4bc3-4df7-8a09-765794883524
1. Get default terminal type from PCD rather than using PCANSI
directly in BuildTeminalDevpath;
2. Only terminal type is needed to create an TerminalDev instance, so
remove the useless code of creating and freeing DefaultNode.
3. Some white space refining.
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Heyi Guo <heyi.guo@linaro.org>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18027 6f19259b-4bc3-4df7-8a09-765794883524
This is bug fix for TerminalDxe: NullRemaining should be set to FALSE
by fault and then be set to TRUE conditionally.
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Heyi Guo <heyi.guo@linaro.org>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18026 6f19259b-4bc3-4df7-8a09-765794883524
Change default terminal type to be consistent with default
ConIn/ConOut device path, which is now determined by TTY_TERMINAL
flag, TTYTERM or VT100.
I can't say this is a bug, as we can pass the whole console device
path to ConnectController, and TerminalDxe driver will pick up the
terminal in the remaining device path. However, in rare circumstances,
the console devices may be disconnected with the driver, and they will
be ignored by ConPlatformDxe until we pass the device path explicitly
just as BDS.
Changing default terminal type to be the same with console device
path could help serial terminal be reconnected with normal connect
controller operation.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Heyi Guo <heyi.guo@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18025 6f19259b-4bc3-4df7-8a09-765794883524
Update comment for PcdDefaultTerminalType, as a new terminal type
TTYTERM has been added with type value of 4.
The new type is NOT defined in UEFI SPEC v2.5.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Andrew Fish <afish@apple.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Heyi Guo <heyi.guo@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18024 6f19259b-4bc3-4df7-8a09-765794883524
Update comment for PcdDefaultTerminalType, as a new terminal type
TTYTERM has been added with type value of 4.
The new type is NOT defined in UEFI SPEC v2.5.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Heyi Guo <heyi.guo@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18023 6f19259b-4bc3-4df7-8a09-765794883524
Change the type of mStatusString[] to reflect that it is a CONST
array of pointers to CONST.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18022 6f19259b-4bc3-4df7-8a09-765794883524
Change the type of mStatusString[] to reflect that it is a CONST
array of pointers to CONST.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18021 6f19259b-4bc3-4df7-8a09-765794883524
Star Zeng
fanwang2
Scott Duplichan
Ruiyu Ni
Laszlo Ersek
Jordan Justen
Qiu Shumin
Dandan Bi
Andrew Fish
Zhang Lubo
Jiaxin Wu
Ard Biesheuvel
Leif Lindholm
Bruce Cran
Jaben Carsey
Heyi Guo
Olivier Martin
Ronald Cron
Liming Gao