* [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency
@ 2019-06-11 1:43 Wu, Hao A
2019-06-11 1:43 ` [PATCH v2 1/6] OvmfPkg/PlatformPei: Remove redundant reference of framework pkg DEC Wu, Hao A
` (7 more replies)
0 siblings, 8 replies; 24+ messages in thread
From: Wu, Hao A @ 2019-06-11 1:43 UTC (permalink / raw)
To: devel
Cc: Hao A Wu, Ray Ni, David Woodhouse, Jordan Justen, Laszlo Ersek,
Ard Biesheuvel
The series is also available at:
https://github.com/hwu25/edk2/tree/ovmf_drop_framework_v2
V2 changes:
* Update to module OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf has been
dropped, since the module is proposed to be removed in another series:
https://edk2.groups.io/g/devel/message/42142
* Copy LegacyBios protocol definitions from IntelFrameworkPkg, since
OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
has a dependency on it. This was not done in V1 series since such copy
was previous covered by another series to duplicate the required CSM
modules into OvmfPkg. (Now this series has been dropped.)
V1 history:
The series will drop the IntelFramework[Module]Pkg dependency for below
modules within OvmfPkg:
OvmfPkg/PlatformPei/PlatformPei.inf
OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf
Verification done for the series:
* Build pass for OvmfPkg;
* Boot to shell with the built images.
Cc: Ray Ni <ray.ni@intel.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Hao A Wu (6):
OvmfPkg/PlatformPei: Remove redundant reference of framework pkg DEC
OvmfPkg/OvmfPkg.dec: Add PcdShellFile in OVMF DEC file
OvmfPkg/PlatformBootManagerLib: Use PcdShellFile defined in OvmfPkg
OvmfPkg/DSC: Remove the consume of PcdShellFile in framework package
OvmfPkg: Copy LegacyBios protocol definitions from IntelFrameworkPkg
OvmfPkg/IncompatiblePciDeviceSupportDxe: Drop framework pkg dependency
OvmfPkg/OvmfPkg.dec | 4 +
OvmfPkg/OvmfPkgIa32.dsc | 2 -
OvmfPkg/OvmfPkgIa32X64.dsc | 2 -
OvmfPkg/OvmfPkgX64.dsc | 2 -
OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf | 1 -
OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf | 5 +-
OvmfPkg/PlatformPei/PlatformPei.inf | 3 +-
OvmfPkg/Include/Protocol/LegacyBios.h | 1553 ++++++++++++++++++++
8 files changed, 1560 insertions(+), 12 deletions(-)
create mode 100644 OvmfPkg/Include/Protocol/LegacyBios.h
--
2.12.0.windows.1
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH v2 1/6] OvmfPkg/PlatformPei: Remove redundant reference of framework pkg DEC
2019-06-11 1:43 [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency Wu, Hao A
@ 2019-06-11 1:43 ` Wu, Hao A
2019-06-11 1:43 ` [PATCH v2 2/6] OvmfPkg/OvmfPkg.dec: Add PcdShellFile in OVMF DEC file Wu, Hao A
` (6 subsequent siblings)
7 siblings, 0 replies; 24+ messages in thread
From: Wu, Hao A @ 2019-06-11 1:43 UTC (permalink / raw)
To: devel; +Cc: Hao A Wu, Ray Ni, Jordan Justen, Laszlo Ersek, Ard Biesheuvel
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1843
For the driver's INF file, this commit will remove the redundant reference
to 'IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec'.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
---
OvmfPkg/PlatformPei/PlatformPei.inf | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf b/OvmfPkg/PlatformPei/PlatformPei.inf
index f660c2d9e4..d9fd9c8f05 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
@@ -2,7 +2,7 @@
# Platform PEI driver
#
# This module provides platform specific function to detect boot mode.
-# Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.<BR>
+# Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.<BR>
#
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
@@ -36,7 +36,6 @@ [Sources]
Xen.h
[Packages]
- IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
MdePkg/MdePkg.dec
MdeModulePkg/MdeModulePkg.dec
SecurityPkg/SecurityPkg.dec
--
2.12.0.windows.1
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH v2 2/6] OvmfPkg/OvmfPkg.dec: Add PcdShellFile in OVMF DEC file
2019-06-11 1:43 [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency Wu, Hao A
2019-06-11 1:43 ` [PATCH v2 1/6] OvmfPkg/PlatformPei: Remove redundant reference of framework pkg DEC Wu, Hao A
@ 2019-06-11 1:43 ` Wu, Hao A
2019-06-11 1:43 ` [PATCH v2 3/6] OvmfPkg/PlatformBootManagerLib: Use PcdShellFile defined in OvmfPkg Wu, Hao A
` (5 subsequent siblings)
7 siblings, 0 replies; 24+ messages in thread
From: Wu, Hao A @ 2019-06-11 1:43 UTC (permalink / raw)
To: devel; +Cc: Hao A Wu, Ray Ni, Jordan Justen, Laszlo Ersek, Ard Biesheuvel
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1843
OVMF is currently using the PCD 'PcdShellFile' defined in
IntelFrameworkModulePkg.
This commit will add this PCD into the OVMF DEC file in order to drop
OVMF's dependency on IntelFrameworkModulePkg. The PCD token value 0x17 is
selected to fill the hole (seems the only one left) in OvmfPkg.
Please note that, instead of adding the PCD under section:
[PcdsFixedAtBuild, PcdsPatchableInModule]
as in IntelFrameworkModulePkg.dec file, it is added in section:
[PcdsFixedAtBuild]
in OvmfPkg.dec instead.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
---
OvmfPkg/OvmfPkg.dec | 3 +++
1 file changed, 3 insertions(+)
diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 0e555c5c78..8d6a5ededc 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -150,6 +150,9 @@ [PcdsFixedAtBuild]
# For the corresponding bits, 0 = Edge triggered and 1 = Level triggered.
gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0000|UINT16|0x5
+ ## FFS filename to find the shell application.
+ gUefiOvmfPkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }|VOID*|0x17
+
[PcdsDynamic, PcdsDynamicEx]
gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10
--
2.12.0.windows.1
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH v2 3/6] OvmfPkg/PlatformBootManagerLib: Use PcdShellFile defined in OvmfPkg
2019-06-11 1:43 [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency Wu, Hao A
2019-06-11 1:43 ` [PATCH v2 1/6] OvmfPkg/PlatformPei: Remove redundant reference of framework pkg DEC Wu, Hao A
2019-06-11 1:43 ` [PATCH v2 2/6] OvmfPkg/OvmfPkg.dec: Add PcdShellFile in OVMF DEC file Wu, Hao A
@ 2019-06-11 1:43 ` Wu, Hao A
2019-06-11 1:43 ` [PATCH v2 4/6] OvmfPkg/DSC: Remove the consume of PcdShellFile in framework package Wu, Hao A
` (4 subsequent siblings)
7 siblings, 0 replies; 24+ messages in thread
From: Wu, Hao A @ 2019-06-11 1:43 UTC (permalink / raw)
To: devel; +Cc: Hao A Wu, Ray Ni, Jordan Justen, Laszlo Ersek, Ard Biesheuvel
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1843
This commit will update the PlatformBootManagerLib to consume the PCD
'PcdShellFile' defined in OvmfPkg (rather than the one in
IntelFrameworkModulePkg). And will update the driver to drop its
dependency on IntelFrameworkModulePkg.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
---
OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
index d25e0a417f..681ff7e88d 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
@@ -1,7 +1,7 @@
## @file
# Platform BDS customizations library.
#
-# Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.<BR>
+# Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.<BR>
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
##
@@ -29,7 +29,6 @@ [Sources]
[Packages]
MdePkg/MdePkg.dec
MdeModulePkg/MdeModulePkg.dec
- IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
SourceLevelDebugPkg/SourceLevelDebugPkg.dec
OvmfPkg/OvmfPkg.dec
SecurityPkg/SecurityPkg.dec
@@ -60,7 +59,7 @@ [Pcd]
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut
- gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile
+ gUefiOvmfPkgTokenSpaceGuid.PcdShellFile
[Pcd.IA32, Pcd.X64]
gEfiMdePkgTokenSpaceGuid.PcdFSBClock
--
2.12.0.windows.1
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH v2 4/6] OvmfPkg/DSC: Remove the consume of PcdShellFile in framework package
2019-06-11 1:43 [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency Wu, Hao A
` (2 preceding siblings ...)
2019-06-11 1:43 ` [PATCH v2 3/6] OvmfPkg/PlatformBootManagerLib: Use PcdShellFile defined in OvmfPkg Wu, Hao A
@ 2019-06-11 1:43 ` Wu, Hao A
2019-06-11 1:43 ` [PATCH v2 5/6] OvmfPkg: Copy LegacyBios protocol definitions from IntelFrameworkPkg Wu, Hao A
` (3 subsequent siblings)
7 siblings, 0 replies; 24+ messages in thread
From: Wu, Hao A @ 2019-06-11 1:43 UTC (permalink / raw)
To: devel; +Cc: Hao A Wu, Ray Ni, Jordan Justen, Laszlo Ersek, Ard Biesheuvel
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1843
This commit will remove the consume of:
gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile
from OvmfPkg DSC files.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
---
OvmfPkg/OvmfPkgIa32.dsc | 2 --
OvmfPkg/OvmfPkgIa32X64.dsc | 2 --
OvmfPkg/OvmfPkgX64.dsc | 2 --
3 files changed, 6 deletions(-)
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 8281f409f2..4d2c8359e1 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -503,8 +503,6 @@ [PcdsFixedAtBuild]
#
!include NetworkPkg/NetworkPcds.dsc.inc
- gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
-
!if $(SMM_REQUIRE) == TRUE
gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStackSize|0x4000
!endif
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 30d094d217..c78b0d5f63 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -509,8 +509,6 @@ [PcdsFixedAtBuild.X64]
#
!include NetworkPkg/NetworkPcds.dsc.inc
- gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
-
!if $(SMM_REQUIRE) == TRUE
gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStackSize|0x4000
!endif
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 705795f0da..72874aaa19 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -508,8 +508,6 @@ [PcdsFixedAtBuild]
#
!include NetworkPkg/NetworkPcds.dsc.inc
- gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
-
!if $(SMM_REQUIRE) == TRUE
gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStackSize|0x4000
!endif
--
2.12.0.windows.1
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH v2 5/6] OvmfPkg: Copy LegacyBios protocol definitions from IntelFrameworkPkg
2019-06-11 1:43 [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency Wu, Hao A
` (3 preceding siblings ...)
2019-06-11 1:43 ` [PATCH v2 4/6] OvmfPkg/DSC: Remove the consume of PcdShellFile in framework package Wu, Hao A
@ 2019-06-11 1:43 ` Wu, Hao A
2019-06-11 1:43 ` [PATCH v2 6/6] OvmfPkg/IncompatiblePciDeviceSupportDxe: Drop framework pkg dependency Wu, Hao A
` (2 subsequent siblings)
7 siblings, 0 replies; 24+ messages in thread
From: Wu, Hao A @ 2019-06-11 1:43 UTC (permalink / raw)
To: devel; +Cc: Hao A Wu, Ray Ni, Jordan Justen, Laszlo Ersek, Ard Biesheuvel
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1843
This commit copies the exact LegacyBios protocol header file from
IntelFrameworkPkg to OvmfPkg. Also, the protocol GUID definition is
duplicated in the OvmfPkg DEC file.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
---
OvmfPkg/OvmfPkg.dec | 1 +
OvmfPkg/Include/Protocol/LegacyBios.h | 1553 ++++++++++++++++++++
2 files changed, 1554 insertions(+)
diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 8d6a5ededc..fa58fa5160 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -86,6 +86,7 @@ [Protocols]
gXenIoProtocolGuid = {0x6efac84f, 0x0ab0, 0x4747, {0x81, 0xbe, 0x85, 0x55, 0x62, 0x59, 0x04, 0x49}}
gIoMmuAbsentProtocolGuid = {0xf8775d50, 0x8abd, 0x4adf, {0x92, 0xac, 0x85, 0x3e, 0x51, 0xf6, 0xc8, 0xdc}}
gEfiLegacy8259ProtocolGuid = {0x38321dba, 0x4fe0, 0x4e17, {0x8a, 0xec, 0x41, 0x30, 0x55, 0xea, 0xed, 0xc1}}
+ gEfiLegacyBiosProtocolGuid = {0xdb9a1e3d, 0x45cb, 0x4abb, {0x85, 0x3b, 0xe5, 0x38, 0x7f, 0xdb, 0x2e, 0x2d}}
[PcdsFixedAtBuild]
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|0x0|UINT32|0
diff --git a/OvmfPkg/Include/Protocol/LegacyBios.h b/OvmfPkg/Include/Protocol/LegacyBios.h
new file mode 100644
index 0000000000..36761da397
--- /dev/null
+++ b/OvmfPkg/Include/Protocol/LegacyBios.h
@@ -0,0 +1,1553 @@
+/** @file
+ The EFI Legacy BIOS Protocol is used to abstract legacy Option ROM usage
+ under EFI and Legacy OS boot. This file also includes all the related
+ COMPATIBILIY16 structures and defintions.
+
+ Note: The names for EFI_IA32_REGISTER_SET elements were picked to follow
+ well known naming conventions.
+
+ Thunk is the code that switches from 32-bit protected environment into the 16-bit real-mode
+ environment. Reverse thunk is the code that does the opposite.
+
+Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.<BR>
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+ @par Revision Reference:
+ This protocol is defined in Framework for EFI Compatibility Support Module spec
+ Version 0.98.
+
+**/
+
+#ifndef _EFI_LEGACY_BIOS_H_
+#define _EFI_LEGACY_BIOS_H_
+
+///
+///
+///
+#pragma pack(1)
+
+typedef UINT8 SERIAL_MODE;
+typedef UINT8 PARALLEL_MODE;
+
+#define EFI_COMPATIBILITY16_TABLE_SIGNATURE SIGNATURE_32 ('I', 'F', 'E', '$')
+
+///
+/// There is a table located within the traditional BIOS in either the 0xF000:xxxx or 0xE000:xxxx
+/// physical address range. It is located on a 16-byte boundary and provides the physical address of the
+/// entry point for the Compatibility16 functions. These functions provide the platform-specific
+/// information that is required by the generic EfiCompatibility code. The functions are invoked via
+/// thunking by using EFI_LEGACY_BIOS_PROTOCOL.FarCall86() with the 32-bit physical
+/// entry point.
+///
+typedef struct {
+ ///
+ /// The string "$EFI" denotes the start of the EfiCompatibility table. Byte 0 is "I," byte
+ /// 1 is "F," byte 2 is "E," and byte 3 is "$" and is normally accessed as a DWORD or UINT32.
+ ///
+ UINT32 Signature;
+
+ ///
+ /// The value required such that byte checksum of TableLength equals zero.
+ ///
+ UINT8 TableChecksum;
+
+ ///
+ /// The length of this table.
+ ///
+ UINT8 TableLength;
+
+ ///
+ /// The major EFI revision for which this table was generated.
+ ///
+ UINT8 EfiMajorRevision;
+
+ ///
+ /// The minor EFI revision for which this table was generated.
+ ///
+ UINT8 EfiMinorRevision;
+
+ ///
+ /// The major revision of this table.
+ ///
+ UINT8 TableMajorRevision;
+
+ ///
+ /// The minor revision of this table.
+ ///
+ UINT8 TableMinorRevision;
+
+ ///
+ /// Reserved for future usage.
+ ///
+ UINT16 Reserved;
+
+ ///
+ /// The segment of the entry point within the traditional BIOS for Compatibility16 functions.
+ ///
+ UINT16 Compatibility16CallSegment;
+
+ ///
+ /// The offset of the entry point within the traditional BIOS for Compatibility16 functions.
+ ///
+ UINT16 Compatibility16CallOffset;
+
+ ///
+ /// The segment of the entry point within the traditional BIOS for EfiCompatibility
+ /// to invoke the PnP installation check.
+ ///
+ UINT16 PnPInstallationCheckSegment;
+
+ ///
+ /// The Offset of the entry point within the traditional BIOS for EfiCompatibility
+ /// to invoke the PnP installation check.
+ ///
+ UINT16 PnPInstallationCheckOffset;
+
+ ///
+ /// EFI system resources table. Type EFI_SYSTEM_TABLE is defined in the IntelPlatform
+ ///Innovation Framework for EFI Driver Execution Environment Core Interface Specification (DXE CIS).
+ ///
+ UINT32 EfiSystemTable;
+
+ ///
+ /// The address of an OEM-provided identifier string. The string is null terminated.
+ ///
+ UINT32 OemIdStringPointer;
+
+ ///
+ /// The 32-bit physical address where ACPI RSD PTR is stored within the traditional
+ /// BIOS. The remained of the ACPI tables are located at their EFI addresses. The size
+ /// reserved is the maximum for ACPI 2.0. The EfiCompatibility will fill in the ACPI
+ /// RSD PTR with either the ACPI 1.0b or 2.0 values.
+ ///
+ UINT32 AcpiRsdPtrPointer;
+
+ ///
+ /// The OEM revision number. Usage is undefined but provided for OEM module usage.
+ ///
+ UINT16 OemRevision;
+
+ ///
+ /// The 32-bit physical address where INT15 E820 data is stored within the traditional
+ /// BIOS. The EfiCompatibility code will fill in the E820Pointer value and copy the
+ /// data to the indicated area.
+ ///
+ UINT32 E820Pointer;
+
+ ///
+ /// The length of the E820 data and is filled in by the EfiCompatibility code.
+ ///
+ UINT32 E820Length;
+
+ ///
+ /// The 32-bit physical address where the $PIR table is stored in the traditional BIOS.
+ /// The EfiCompatibility code will fill in the IrqRoutingTablePointer value and
+ /// copy the data to the indicated area.
+ ///
+ UINT32 IrqRoutingTablePointer;
+
+ ///
+ /// The length of the $PIR table and is filled in by the EfiCompatibility code.
+ ///
+ UINT32 IrqRoutingTableLength;
+
+ ///
+ /// The 32-bit physical address where the MP table is stored in the traditional BIOS.
+ /// The EfiCompatibility code will fill in the MpTablePtr value and copy the data
+ /// to the indicated area.
+ ///
+ UINT32 MpTablePtr;
+
+ ///
+ /// The length of the MP table and is filled in by the EfiCompatibility code.
+ ///
+ UINT32 MpTableLength;
+
+ ///
+ /// The segment of the OEM-specific INT table/code.
+ ///
+ UINT16 OemIntSegment;
+
+ ///
+ /// The offset of the OEM-specific INT table/code.
+ ///
+ UINT16 OemIntOffset;
+
+ ///
+ /// The segment of the OEM-specific 32-bit table/code.
+ ///
+ UINT16 Oem32Segment;
+
+ ///
+ /// The offset of the OEM-specific 32-bit table/code.
+ ///
+ UINT16 Oem32Offset;
+
+ ///
+ /// The segment of the OEM-specific 16-bit table/code.
+ ///
+ UINT16 Oem16Segment;
+
+ ///
+ /// The offset of the OEM-specific 16-bit table/code.
+ ///
+ UINT16 Oem16Offset;
+
+ ///
+ /// The segment of the TPM binary passed to 16-bit CSM.
+ ///
+ UINT16 TpmSegment;
+
+ ///
+ /// The offset of the TPM binary passed to 16-bit CSM.
+ ///
+ UINT16 TpmOffset;
+
+ ///
+ /// A pointer to a string identifying the independent BIOS vendor.
+ ///
+ UINT32 IbvPointer;
+
+ ///
+ /// This field is NULL for all systems not supporting PCI Express. This field is the base
+ /// value of the start of the PCI Express memory-mapped configuration registers and
+ /// must be filled in prior to EfiCompatibility code issuing the Compatibility16 function
+ /// Compatibility16InitializeYourself().
+ /// Compatibility16InitializeYourself() is defined in Compatability16
+ /// Functions.
+ ///
+ UINT32 PciExpressBase;
+
+ ///
+ /// Maximum PCI bus number assigned.
+ ///
+ UINT8 LastPciBus;
+
+ ///
+ /// Start Address of Upper Memory Area (UMA) to be set as Read/Write. If
+ /// UmaAddress is a valid address in the shadow RAM, it also indicates that the region
+ /// from 0xC0000 to (UmaAddress - 1) can be used for Option ROM.
+ ///
+ UINT32 UmaAddress;
+
+ ///
+ /// Upper Memory Area size in bytes to be set as Read/Write. If zero, no UMA region
+ /// will be set as Read/Write (i.e. all Shadow RAM is set as Read-Only).
+ ///
+ UINT32 UmaSize;
+
+ ///
+ /// Start Address of high memory that can be used for permanent allocation. If zero,
+ /// high memory is not available for permanent allocation.
+ ///
+ UINT32 HiPermanentMemoryAddress;
+
+ ///
+ /// Size of high memory that can be used for permanent allocation in bytes. If zero,
+ /// high memory is not available for permanent allocation.
+ ///
+ UINT32 HiPermanentMemorySize;
+} EFI_COMPATIBILITY16_TABLE;
+
+///
+/// Functions provided by the CSM binary which communicate between the EfiCompatibility
+/// and Compatability16 code.
+///
+/// Inconsistent with the specification here:
+/// The member's name started with "Compatibility16" [defined in Intel Framework
+/// Compatibility Support Module Specification / 0.97 version]
+/// has been changed to "Legacy16" since keeping backward compatible.
+///
+typedef enum {
+ ///
+ /// Causes the Compatibility16 code to do any internal initialization required.
+ /// Input:
+ /// AX = Compatibility16InitializeYourself
+ /// ES:BX = Pointer to EFI_TO_COMPATIBILITY16_INIT_TABLE
+ /// Return:
+ /// AX = Return Status codes
+ ///
+ Legacy16InitializeYourself = 0x0000,
+
+ ///
+ /// Causes the Compatibility16 BIOS to perform any drive number translations to match the boot sequence.
+ /// Input:
+ /// AX = Compatibility16UpdateBbs
+ /// ES:BX = Pointer to EFI_TO_COMPATIBILITY16_BOOT_TABLE
+ /// Return:
+ /// AX = Returned status codes
+ ///
+ Legacy16UpdateBbs = 0x0001,
+
+ ///
+ /// Allows the Compatibility16 code to perform any final actions before booting. The Compatibility16
+ /// code is read/write.
+ /// Input:
+ /// AX = Compatibility16PrepareToBoot
+ /// ES:BX = Pointer to EFI_TO_COMPATIBILITY16_BOOT_TABLE structure
+ /// Return:
+ /// AX = Returned status codes
+ ///
+ Legacy16PrepareToBoot = 0x0002,
+
+ ///
+ /// Causes the Compatibility16 BIOS to boot. The Compatibility16 code is Read/Only.
+ /// Input:
+ /// AX = Compatibility16Boot
+ /// Output:
+ /// AX = Returned status codes
+ ///
+ Legacy16Boot = 0x0003,
+
+ ///
+ /// Allows the Compatibility16 code to get the last device from which a boot was attempted. This is
+ /// stored in CMOS and is the priority number of the last attempted boot device.
+ /// Input:
+ /// AX = Compatibility16RetrieveLastBootDevice
+ /// Output:
+ /// AX = Returned status codes
+ /// BX = Priority number of the boot device.
+ ///
+ Legacy16RetrieveLastBootDevice = 0x0004,
+
+ ///
+ /// Allows the Compatibility16 code rehook INT13, INT18, and/or INT19 after dispatching a legacy OpROM.
+ /// Input:
+ /// AX = Compatibility16DispatchOprom
+ /// ES:BX = Pointer to EFI_DISPATCH_OPROM_TABLE
+ /// Output:
+ /// AX = Returned status codes
+ /// BX = Number of non-BBS-compliant devices found. Equals 0 if BBS compliant.
+ ///
+ Legacy16DispatchOprom = 0x0005,
+
+ ///
+ /// Finds a free area in the 0xFxxxx or 0xExxxx region of the specified length and returns the address
+ /// of that region.
+ /// Input:
+ /// AX = Compatibility16GetTableAddress
+ /// BX = Allocation region
+ /// 00 = Allocate from either 0xE0000 or 0xF0000 64 KB blocks.
+ /// Bit 0 = 1 Allocate from 0xF0000 64 KB block
+ /// Bit 1 = 1 Allocate from 0xE0000 64 KB block
+ /// CX = Requested length in bytes.
+ /// DX = Required address alignment. Bit mapped. First non-zero bit from the right is the alignment.
+ /// Output:
+ /// AX = Returned status codes
+ /// DS:BX = Address of the region
+ ///
+ Legacy16GetTableAddress = 0x0006,
+
+ ///
+ /// Enables the EfiCompatibility module to do any nonstandard processing of keyboard LEDs or state.
+ /// Input:
+ /// AX = Compatibility16SetKeyboardLeds
+ /// CL = LED status.
+ /// Bit 0 Scroll Lock 0 = Off
+ /// Bit 1 NumLock
+ /// Bit 2 Caps Lock
+ /// Output:
+ /// AX = Returned status codes
+ ///
+ Legacy16SetKeyboardLeds = 0x0007,
+
+ ///
+ /// Enables the EfiCompatibility module to install an interrupt handler for PCI mass media devices that
+ /// do not have an OpROM associated with them. An example is SATA.
+ /// Input:
+ /// AX = Compatibility16InstallPciHandler
+ /// ES:BX = Pointer to EFI_LEGACY_INSTALL_PCI_HANDLER structure
+ /// Output:
+ /// AX = Returned status codes
+ ///
+ Legacy16InstallPciHandler = 0x0008
+} EFI_COMPATIBILITY_FUNCTIONS;
+
+
+///
+/// EFI_DISPATCH_OPROM_TABLE
+///
+typedef struct {
+ UINT16 PnPInstallationCheckSegment; ///< A pointer to the PnpInstallationCheck data structure.
+ UINT16 PnPInstallationCheckOffset; ///< A pointer to the PnpInstallationCheck data structure.
+ UINT16 OpromSegment; ///< The segment where the OpROM was placed. Offset is assumed to be 3.
+ UINT8 PciBus; ///< The PCI bus.
+ UINT8 PciDeviceFunction; ///< The PCI device * 0x08 | PCI function.
+ UINT8 NumberBbsEntries; ///< The number of valid BBS table entries upon entry and exit. The IBV code may
+ ///< increase this number, if BBS-compliant devices also hook INTs in order to force the
+ ///< OpROM BIOS Setup to be executed.
+ UINT32 BbsTablePointer; ///< A pointer to the BBS table.
+ UINT16 RuntimeSegment; ///< The segment where the OpROM can be relocated to. If this value is 0x0000, this
+ ///< means that the relocation of this run time code is not supported.
+ ///< Inconsistent with specification here:
+ ///< The member's name "OpromDestinationSegment" [defined in Intel Framework Compatibility Support Module Specification / 0.97 version]
+ ///< has been changed to "RuntimeSegment" since keeping backward compatible.
+
+} EFI_DISPATCH_OPROM_TABLE;
+
+///
+/// EFI_TO_COMPATIBILITY16_INIT_TABLE
+///
+typedef struct {
+ ///
+ /// Starting address of memory under 1 MB. The ending address is assumed to be 640 KB or 0x9FFFF.
+ ///
+ UINT32 BiosLessThan1MB;
+
+ ///
+ /// The starting address of the high memory block.
+ ///
+ UINT32 HiPmmMemory;
+
+ ///
+ /// The length of high memory block.
+ ///
+ UINT32 HiPmmMemorySizeInBytes;
+
+ ///
+ /// The segment of the reverse thunk call code.
+ ///
+ UINT16 ReverseThunkCallSegment;
+
+ ///
+ /// The offset of the reverse thunk call code.
+ ///
+ UINT16 ReverseThunkCallOffset;
+
+ ///
+ /// The number of E820 entries copied to the Compatibility16 BIOS.
+ ///
+ UINT32 NumberE820Entries;
+
+ ///
+ /// The amount of usable memory above 1 MB, e.g., E820 type 1 memory.
+ ///
+ UINT32 OsMemoryAbove1Mb;
+
+ ///
+ /// The start of thunk code in main memory. Memory cannot be used by BIOS or PMM.
+ ///
+ UINT32 ThunkStart;
+
+ ///
+ /// The size of the thunk code.
+ ///
+ UINT32 ThunkSizeInBytes;
+
+ ///
+ /// Starting address of memory under 1 MB.
+ ///
+ UINT32 LowPmmMemory;
+
+ ///
+ /// The length of low Memory block.
+ ///
+ UINT32 LowPmmMemorySizeInBytes;
+} EFI_TO_COMPATIBILITY16_INIT_TABLE;
+
+///
+/// DEVICE_PRODUCER_SERIAL.
+///
+typedef struct {
+ UINT16 Address; ///< I/O address assigned to the serial port.
+ UINT8 Irq; ///< IRQ assigned to the serial port.
+ SERIAL_MODE Mode; ///< Mode of serial port. Values are defined below.
+} DEVICE_PRODUCER_SERIAL;
+
+///
+/// DEVICE_PRODUCER_SERIAL's modes.
+///@{
+#define DEVICE_SERIAL_MODE_NORMAL 0x00
+#define DEVICE_SERIAL_MODE_IRDA 0x01
+#define DEVICE_SERIAL_MODE_ASK_IR 0x02
+#define DEVICE_SERIAL_MODE_DUPLEX_HALF 0x00
+#define DEVICE_SERIAL_MODE_DUPLEX_FULL 0x10
+///@)
+
+///
+/// DEVICE_PRODUCER_PARALLEL.
+///
+typedef struct {
+ UINT16 Address; ///< I/O address assigned to the parallel port.
+ UINT8 Irq; ///< IRQ assigned to the parallel port.
+ UINT8 Dma; ///< DMA assigned to the parallel port.
+ PARALLEL_MODE Mode; ///< Mode of the parallel port. Values are defined below.
+} DEVICE_PRODUCER_PARALLEL;
+
+///
+/// DEVICE_PRODUCER_PARALLEL's modes.
+///@{
+#define DEVICE_PARALLEL_MODE_MODE_OUTPUT_ONLY 0x00
+#define DEVICE_PARALLEL_MODE_MODE_BIDIRECTIONAL 0x01
+#define DEVICE_PARALLEL_MODE_MODE_EPP 0x02
+#define DEVICE_PARALLEL_MODE_MODE_ECP 0x03
+///@}
+
+///
+/// DEVICE_PRODUCER_FLOPPY
+///
+typedef struct {
+ UINT16 Address; ///< I/O address assigned to the floppy.
+ UINT8 Irq; ///< IRQ assigned to the floppy.
+ UINT8 Dma; ///< DMA assigned to the floppy.
+ UINT8 NumberOfFloppy; ///< Number of floppies in the system.
+} DEVICE_PRODUCER_FLOPPY;
+
+///
+/// LEGACY_DEVICE_FLAGS
+///
+typedef struct {
+ UINT32 A20Kybd : 1; ///< A20 controller by keyboard controller.
+ UINT32 A20Port90 : 1; ///< A20 controlled by port 0x92.
+ UINT32 Reserved : 30; ///< Reserved for future usage.
+} LEGACY_DEVICE_FLAGS;
+
+///
+/// DEVICE_PRODUCER_DATA_HEADER
+///
+typedef struct {
+ DEVICE_PRODUCER_SERIAL Serial[4]; ///< Data for serial port x. Type DEVICE_PRODUCER_SERIAL is defined below.
+ DEVICE_PRODUCER_PARALLEL Parallel[3]; ///< Data for parallel port x. Type DEVICE_PRODUCER_PARALLEL is defined below.
+ DEVICE_PRODUCER_FLOPPY Floppy; ///< Data for floppy. Type DEVICE_PRODUCER_FLOPPY is defined below.
+ UINT8 MousePresent; ///< Flag to indicate if mouse is present.
+ LEGACY_DEVICE_FLAGS Flags; ///< Miscellaneous Boolean state information passed to CSM.
+} DEVICE_PRODUCER_DATA_HEADER;
+
+///
+/// ATAPI_IDENTIFY
+///
+typedef struct {
+ UINT16 Raw[256]; ///< Raw data from the IDE IdentifyDrive command.
+} ATAPI_IDENTIFY;
+
+///
+/// HDD_INFO
+///
+typedef struct {
+ ///
+ /// Status of IDE device. Values are defined below. There is one HDD_INFO structure
+ /// per IDE controller. The IdentifyDrive is per drive. Index 0 is master and index
+ /// 1 is slave.
+ ///
+ UINT16 Status;
+
+ ///
+ /// PCI bus of IDE controller.
+ ///
+ UINT32 Bus;
+
+ ///
+ /// PCI device of IDE controller.
+ ///
+ UINT32 Device;
+
+ ///
+ /// PCI function of IDE controller.
+ ///
+ UINT32 Function;
+
+ ///
+ /// Command ports base address.
+ ///
+ UINT16 CommandBaseAddress;
+
+ ///
+ /// Control ports base address.
+ ///
+ UINT16 ControlBaseAddress;
+
+ ///
+ /// Bus master address.
+ ///
+ UINT16 BusMasterAddress;
+
+ UINT8 HddIrq;
+
+ ///
+ /// Data that identifies the drive data; one per possible attached drive.
+ ///
+ ATAPI_IDENTIFY IdentifyDrive[2];
+} HDD_INFO;
+
+///
+/// HDD_INFO status bits
+///
+#define HDD_PRIMARY 0x01
+#define HDD_SECONDARY 0x02
+#define HDD_MASTER_ATAPI_CDROM 0x04
+#define HDD_SLAVE_ATAPI_CDROM 0x08
+#define HDD_MASTER_IDE 0x20
+#define HDD_SLAVE_IDE 0x40
+#define HDD_MASTER_ATAPI_ZIPDISK 0x10
+#define HDD_SLAVE_ATAPI_ZIPDISK 0x80
+
+///
+/// BBS_STATUS_FLAGS;\.
+///
+typedef struct {
+ UINT16 OldPosition : 4; ///< Prior priority.
+ UINT16 Reserved1 : 4; ///< Reserved for future use.
+ UINT16 Enabled : 1; ///< If 0, ignore this entry.
+ UINT16 Failed : 1; ///< 0 = Not known if boot failure occurred.
+ ///< 1 = Boot attempted failed.
+
+ ///
+ /// State of media present.
+ /// 00 = No bootable media is present in the device.
+ /// 01 = Unknown if a bootable media present.
+ /// 10 = Media is present and appears bootable.
+ /// 11 = Reserved.
+ ///
+ UINT16 MediaPresent : 2;
+ UINT16 Reserved2 : 4; ///< Reserved for future use.
+} BBS_STATUS_FLAGS;
+
+///
+/// BBS_TABLE, device type values & boot priority values.
+///
+typedef struct {
+ ///
+ /// The boot priority for this boot device. Values are defined below.
+ ///
+ UINT16 BootPriority;
+
+ ///
+ /// The PCI bus for this boot device.
+ ///
+ UINT32 Bus;
+
+ ///
+ /// The PCI device for this boot device.
+ ///
+ UINT32 Device;
+
+ ///
+ /// The PCI function for the boot device.
+ ///
+ UINT32 Function;
+
+ ///
+ /// The PCI class for this boot device.
+ ///
+ UINT8 Class;
+
+ ///
+ /// The PCI Subclass for this boot device.
+ ///
+ UINT8 SubClass;
+
+ ///
+ /// Segment:offset address of an ASCIIZ description string describing the manufacturer.
+ ///
+ UINT16 MfgStringOffset;
+
+ ///
+ /// Segment:offset address of an ASCIIZ description string describing the manufacturer.
+ ///
+ UINT16 MfgStringSegment;
+
+ ///
+ /// BBS device type. BBS device types are defined below.
+ ///
+ UINT16 DeviceType;
+
+ ///
+ /// Status of this boot device. Type BBS_STATUS_FLAGS is defined below.
+ ///
+ BBS_STATUS_FLAGS StatusFlags;
+
+ ///
+ /// Segment:Offset address of boot loader for IPL devices or install INT13 handler for
+ /// BCV devices.
+ ///
+ UINT16 BootHandlerOffset;
+
+ ///
+ /// Segment:Offset address of boot loader for IPL devices or install INT13 handler for
+ /// BCV devices.
+ ///
+ UINT16 BootHandlerSegment;
+
+ ///
+ /// Segment:offset address of an ASCIIZ description string describing this device.
+ ///
+ UINT16 DescStringOffset;
+
+ ///
+ /// Segment:offset address of an ASCIIZ description string describing this device.
+ ///
+ UINT16 DescStringSegment;
+
+ ///
+ /// Reserved.
+ ///
+ UINT32 InitPerReserved;
+
+ ///
+ /// The use of these fields is IBV dependent. They can be used to flag that an OpROM
+ /// has hooked the specified IRQ. The OpROM may be BBS compliant as some SCSI
+ /// BBS-compliant OpROMs also hook IRQ vectors in order to run their BIOS Setup
+ ///
+ UINT32 AdditionalIrq13Handler;
+
+ ///
+ /// The use of these fields is IBV dependent. They can be used to flag that an OpROM
+ /// has hooked the specified IRQ. The OpROM may be BBS compliant as some SCSI
+ /// BBS-compliant OpROMs also hook IRQ vectors in order to run their BIOS Setup
+ ///
+ UINT32 AdditionalIrq18Handler;
+
+ ///
+ /// The use of these fields is IBV dependent. They can be used to flag that an OpROM
+ /// has hooked the specified IRQ. The OpROM may be BBS compliant as some SCSI
+ /// BBS-compliant OpROMs also hook IRQ vectors in order to run their BIOS Setup
+ ///
+ UINT32 AdditionalIrq19Handler;
+
+ ///
+ /// The use of these fields is IBV dependent. They can be used to flag that an OpROM
+ /// has hooked the specified IRQ. The OpROM may be BBS compliant as some SCSI
+ /// BBS-compliant OpROMs also hook IRQ vectors in order to run their BIOS Setup
+ ///
+ UINT32 AdditionalIrq40Handler;
+ UINT8 AssignedDriveNumber;
+ UINT32 AdditionalIrq41Handler;
+ UINT32 AdditionalIrq46Handler;
+ UINT32 IBV1;
+ UINT32 IBV2;
+} BBS_TABLE;
+
+///
+/// BBS device type values
+///@{
+#define BBS_FLOPPY 0x01
+#define BBS_HARDDISK 0x02
+#define BBS_CDROM 0x03
+#define BBS_PCMCIA 0x04
+#define BBS_USB 0x05
+#define BBS_EMBED_NETWORK 0x06
+#define BBS_BEV_DEVICE 0x80
+#define BBS_UNKNOWN 0xff
+///@}
+
+///
+/// BBS boot priority values
+///@{
+#define BBS_DO_NOT_BOOT_FROM 0xFFFC
+#define BBS_LOWEST_PRIORITY 0xFFFD
+#define BBS_UNPRIORITIZED_ENTRY 0xFFFE
+#define BBS_IGNORE_ENTRY 0xFFFF
+///@}
+
+///
+/// SMM_ATTRIBUTES
+///
+typedef struct {
+ ///
+ /// Access mechanism used to generate the soft SMI. Defined types are below. The other
+ /// values are reserved for future usage.
+ ///
+ UINT16 Type : 3;
+
+ ///
+ /// The size of "port" in bits. Defined values are below.
+ ///
+ UINT16 PortGranularity : 3;
+
+ ///
+ /// The size of data in bits. Defined values are below.
+ ///
+ UINT16 DataGranularity : 3;
+
+ ///
+ /// Reserved for future use.
+ ///
+ UINT16 Reserved : 7;
+} SMM_ATTRIBUTES;
+
+///
+/// SMM_ATTRIBUTES type values.
+///@{
+#define STANDARD_IO 0x00
+#define STANDARD_MEMORY 0x01
+///@}
+
+///
+/// SMM_ATTRIBUTES port size constants.
+///@{
+#define PORT_SIZE_8 0x00
+#define PORT_SIZE_16 0x01
+#define PORT_SIZE_32 0x02
+#define PORT_SIZE_64 0x03
+///@}
+
+///
+/// SMM_ATTRIBUTES data size constants.
+///@{
+#define DATA_SIZE_8 0x00
+#define DATA_SIZE_16 0x01
+#define DATA_SIZE_32 0x02
+#define DATA_SIZE_64 0x03
+///@}
+
+///
+/// SMM_FUNCTION & relating constants.
+///
+typedef struct {
+ UINT16 Function : 15;
+ UINT16 Owner : 1;
+} SMM_FUNCTION;
+
+///
+/// SMM_FUNCTION Function constants.
+///@{
+#define INT15_D042 0x0000
+#define GET_USB_BOOT_INFO 0x0001
+#define DMI_PNP_50_57 0x0002
+///@}
+
+///
+/// SMM_FUNCTION Owner constants.
+///@{
+#define STANDARD_OWNER 0x0
+#define OEM_OWNER 0x1
+///@}
+
+///
+/// This structure assumes both port and data sizes are 1. SmmAttribute must be
+/// properly to reflect that assumption.
+///
+typedef struct {
+ ///
+ /// Describes the access mechanism, SmmPort, and SmmData sizes. Type
+ /// SMM_ATTRIBUTES is defined below.
+ ///
+ SMM_ATTRIBUTES SmmAttributes;
+
+ ///
+ /// Function Soft SMI is to perform. Type SMM_FUNCTION is defined below.
+ ///
+ SMM_FUNCTION SmmFunction;
+
+ ///
+ /// SmmPort size depends upon SmmAttributes and ranges from2 bytes to 16 bytes.
+ ///
+ UINT8 SmmPort;
+
+ ///
+ /// SmmData size depends upon SmmAttributes and ranges from2 bytes to 16 bytes.
+ ///
+ UINT8 SmmData;
+} SMM_ENTRY;
+
+///
+/// SMM_TABLE
+///
+typedef struct {
+ UINT16 NumSmmEntries; ///< Number of entries represented by SmmEntry.
+ SMM_ENTRY SmmEntry; ///< One entry per function. Type SMM_ENTRY is defined below.
+} SMM_TABLE;
+
+///
+/// UDC_ATTRIBUTES
+///
+typedef struct {
+ ///
+ /// This bit set indicates that the ServiceAreaData is valid.
+ ///
+ UINT8 DirectoryServiceValidity : 1;
+
+ ///
+ /// This bit set indicates to use the Reserve Area Boot Code Address (RACBA) only if
+ /// DirectoryServiceValidity is 0.
+ ///
+ UINT8 RabcaUsedFlag : 1;
+
+ ///
+ /// This bit set indicates to execute hard disk diagnostics.
+ ///
+ UINT8 ExecuteHddDiagnosticsFlag : 1;
+
+ ///
+ /// Reserved for future use. Set to 0.
+ ///
+ UINT8 Reserved : 5;
+} UDC_ATTRIBUTES;
+
+///
+/// UD_TABLE
+///
+typedef struct {
+ ///
+ /// This field contains the bit-mapped attributes of the PARTIES information. Type
+ /// UDC_ATTRIBUTES is defined below.
+ ///
+ UDC_ATTRIBUTES Attributes;
+
+ ///
+ /// This field contains the zero-based device on which the selected
+ /// ServiceDataArea is present. It is 0 for master and 1 for the slave device.
+ ///
+ UINT8 DeviceNumber;
+
+ ///
+ /// This field contains the zero-based index into the BbsTable for the parent device.
+ /// This index allows the user to reference the parent device information such as PCI
+ /// bus, device function.
+ ///
+ UINT8 BbsTableEntryNumberForParentDevice;
+
+ ///
+ /// This field contains the zero-based index into the BbsTable for the boot entry.
+ ///
+ UINT8 BbsTableEntryNumberForBoot;
+
+ ///
+ /// This field contains the zero-based index into the BbsTable for the HDD diagnostics entry.
+ ///
+ UINT8 BbsTableEntryNumberForHddDiag;
+
+ ///
+ /// The raw Beer data.
+ ///
+ UINT8 BeerData[128];
+
+ ///
+ /// The raw data of selected service area.
+ ///
+ UINT8 ServiceAreaData[64];
+} UD_TABLE;
+
+#define EFI_TO_LEGACY_MAJOR_VERSION 0x02
+#define EFI_TO_LEGACY_MINOR_VERSION 0x00
+#define MAX_IDE_CONTROLLER 8
+
+///
+/// EFI_TO_COMPATIBILITY16_BOOT_TABLE
+///
+typedef struct {
+ UINT16 MajorVersion; ///< The EfiCompatibility major version number.
+ UINT16 MinorVersion; ///< The EfiCompatibility minor version number.
+ UINT32 AcpiTable; ///< The location of the RSDT ACPI table. < 4G range.
+ UINT32 SmbiosTable; ///< The location of the SMBIOS table in EFI memory. < 4G range.
+ UINT32 SmbiosTableLength;
+ //
+ // Legacy SIO state
+ //
+ DEVICE_PRODUCER_DATA_HEADER SioData; ///< Standard traditional device information.
+ UINT16 DevicePathType; ///< The default boot type.
+ UINT16 PciIrqMask; ///< Mask of which IRQs have been assigned to PCI.
+ UINT32 NumberE820Entries; ///< Number of E820 entries. The number can change from the
+ ///< Compatibility16InitializeYourself() function.
+ //
+ // Controller & Drive Identify[2] per controller information
+ //
+ HDD_INFO HddInfo[MAX_IDE_CONTROLLER]; ///< Hard disk drive information, including raw Identify Drive data.
+ UINT32 NumberBbsEntries; ///< Number of entries in the BBS table
+ UINT32 BbsTable; ///< A pointer to the BBS table. Type BBS_TABLE is defined below.
+ UINT32 SmmTable; ///< A pointer to the SMM table. Type SMM_TABLE is defined below.
+ UINT32 OsMemoryAbove1Mb; ///< The amount of usable memory above 1 MB, i.e. E820 type 1 memory. This value can
+ ///< differ from the value in EFI_TO_COMPATIBILITY16_INIT_TABLE as more
+ ///< memory may have been discovered.
+ UINT32 UnconventionalDeviceTable; ///< Information to boot off an unconventional device like a PARTIES partition. Type
+ ///< UD_TABLE is defined below.
+} EFI_TO_COMPATIBILITY16_BOOT_TABLE;
+
+///
+/// EFI_LEGACY_INSTALL_PCI_HANDLER
+///
+typedef struct {
+ UINT8 PciBus; ///< The PCI bus of the device.
+ UINT8 PciDeviceFun; ///< The PCI device in bits 7:3 and function in bits 2:0.
+ UINT8 PciSegment; ///< The PCI segment of the device.
+ UINT8 PciClass; ///< The PCI class code of the device.
+ UINT8 PciSubclass; ///< The PCI subclass code of the device.
+ UINT8 PciInterface; ///< The PCI interface code of the device.
+ //
+ // Primary section
+ //
+ UINT8 PrimaryIrq; ///< The primary device IRQ.
+ UINT8 PrimaryReserved; ///< Reserved.
+ UINT16 PrimaryControl; ///< The primary device control I/O base.
+ UINT16 PrimaryBase; ///< The primary device I/O base.
+ UINT16 PrimaryBusMaster; ///< The primary device bus master I/O base.
+ //
+ // Secondary Section
+ //
+ UINT8 SecondaryIrq; ///< The secondary device IRQ.
+ UINT8 SecondaryReserved; ///< Reserved.
+ UINT16 SecondaryControl; ///< The secondary device control I/O base.
+ UINT16 SecondaryBase; ///< The secondary device I/O base.
+ UINT16 SecondaryBusMaster; ///< The secondary device bus master I/O base.
+} EFI_LEGACY_INSTALL_PCI_HANDLER;
+
+//
+// Restore default pack value
+//
+#pragma pack()
+
+#define EFI_LEGACY_BIOS_PROTOCOL_GUID \
+ { \
+ 0xdb9a1e3d, 0x45cb, 0x4abb, {0x85, 0x3b, 0xe5, 0x38, 0x7f, 0xdb, 0x2e, 0x2d } \
+ }
+
+typedef struct _EFI_LEGACY_BIOS_PROTOCOL EFI_LEGACY_BIOS_PROTOCOL;
+
+///
+/// Flags returned by CheckPciRom().
+///
+#define NO_ROM 0x00
+#define ROM_FOUND 0x01
+#define VALID_LEGACY_ROM 0x02
+#define ROM_WITH_CONFIG 0x04 ///< Not defined in the Framework CSM Specification.
+
+///
+/// The following macros do not appear in the Framework CSM Specification and
+/// are kept for backward compatibility only. They convert 32-bit address (_Adr)
+/// to Segment:Offset 16-bit form.
+///
+///@{
+#define EFI_SEGMENT(_Adr) (UINT16) ((UINT16) (((UINTN) (_Adr)) >> 4) & 0xf000)
+#define EFI_OFFSET(_Adr) (UINT16) (((UINT16) ((UINTN) (_Adr))) & 0xffff)
+///@}
+
+#define CARRY_FLAG 0x01
+
+///
+/// EFI_EFLAGS_REG
+///
+typedef struct {
+ UINT32 CF:1;
+ UINT32 Reserved1:1;
+ UINT32 PF:1;
+ UINT32 Reserved2:1;
+ UINT32 AF:1;
+ UINT32 Reserved3:1;
+ UINT32 ZF:1;
+ UINT32 SF:1;
+ UINT32 TF:1;
+ UINT32 IF:1;
+ UINT32 DF:1;
+ UINT32 OF:1;
+ UINT32 IOPL:2;
+ UINT32 NT:1;
+ UINT32 Reserved4:2;
+ UINT32 VM:1;
+ UINT32 Reserved5:14;
+} EFI_EFLAGS_REG;
+
+///
+/// EFI_DWORD_REGS
+///
+typedef struct {
+ UINT32 EAX;
+ UINT32 EBX;
+ UINT32 ECX;
+ UINT32 EDX;
+ UINT32 ESI;
+ UINT32 EDI;
+ EFI_EFLAGS_REG EFlags;
+ UINT16 ES;
+ UINT16 CS;
+ UINT16 SS;
+ UINT16 DS;
+ UINT16 FS;
+ UINT16 GS;
+ UINT32 EBP;
+ UINT32 ESP;
+} EFI_DWORD_REGS;
+
+///
+/// EFI_FLAGS_REG
+///
+typedef struct {
+ UINT16 CF:1;
+ UINT16 Reserved1:1;
+ UINT16 PF:1;
+ UINT16 Reserved2:1;
+ UINT16 AF:1;
+ UINT16 Reserved3:1;
+ UINT16 ZF:1;
+ UINT16 SF:1;
+ UINT16 TF:1;
+ UINT16 IF:1;
+ UINT16 DF:1;
+ UINT16 OF:1;
+ UINT16 IOPL:2;
+ UINT16 NT:1;
+ UINT16 Reserved4:1;
+} EFI_FLAGS_REG;
+
+///
+/// EFI_WORD_REGS
+///
+typedef struct {
+ UINT16 AX;
+ UINT16 ReservedAX;
+ UINT16 BX;
+ UINT16 ReservedBX;
+ UINT16 CX;
+ UINT16 ReservedCX;
+ UINT16 DX;
+ UINT16 ReservedDX;
+ UINT16 SI;
+ UINT16 ReservedSI;
+ UINT16 DI;
+ UINT16 ReservedDI;
+ EFI_FLAGS_REG Flags;
+ UINT16 ReservedFlags;
+ UINT16 ES;
+ UINT16 CS;
+ UINT16 SS;
+ UINT16 DS;
+ UINT16 FS;
+ UINT16 GS;
+ UINT16 BP;
+ UINT16 ReservedBP;
+ UINT16 SP;
+ UINT16 ReservedSP;
+} EFI_WORD_REGS;
+
+///
+/// EFI_BYTE_REGS
+///
+typedef struct {
+ UINT8 AL, AH;
+ UINT16 ReservedAX;
+ UINT8 BL, BH;
+ UINT16 ReservedBX;
+ UINT8 CL, CH;
+ UINT16 ReservedCX;
+ UINT8 DL, DH;
+ UINT16 ReservedDX;
+} EFI_BYTE_REGS;
+
+///
+/// EFI_IA32_REGISTER_SET
+///
+typedef union {
+ EFI_DWORD_REGS E;
+ EFI_WORD_REGS X;
+ EFI_BYTE_REGS H;
+} EFI_IA32_REGISTER_SET;
+
+/**
+ Thunk to 16-bit real mode and execute a software interrupt with a vector
+ of BiosInt. Regs will contain the 16-bit register context on entry and
+ exit.
+
+ @param[in] This The protocol instance pointer.
+ @param[in] BiosInt The processor interrupt vector to invoke.
+ @param[in,out] Reg Register contexted passed into (and returned) from thunk to
+ 16-bit mode.
+
+ @retval TRUE Thunk completed with no BIOS errors in the target code. See Regs for status.
+ @retval FALSE There was a BIOS error in the target code.
+**/
+typedef
+BOOLEAN
+(EFIAPI *EFI_LEGACY_BIOS_INT86)(
+ IN EFI_LEGACY_BIOS_PROTOCOL *This,
+ IN UINT8 BiosInt,
+ IN OUT EFI_IA32_REGISTER_SET *Regs
+ );
+
+/**
+ Thunk to 16-bit real mode and call Segment:Offset. Regs will contain the
+ 16-bit register context on entry and exit. Arguments can be passed on
+ the Stack argument
+
+ @param[in] This The protocol instance pointer.
+ @param[in] Segment The segemnt of 16-bit mode call.
+ @param[in] Offset The offset of 16-bit mdoe call.
+ @param[in] Reg Register contexted passed into (and returned) from thunk to
+ 16-bit mode.
+ @param[in] Stack The caller allocated stack used to pass arguments.
+ @param[in] StackSize The size of Stack in bytes.
+
+ @retval FALSE Thunk completed with no BIOS errors in the target code. See Regs for status. @retval TRUE There was a BIOS error in the target code.
+**/
+typedef
+BOOLEAN
+(EFIAPI *EFI_LEGACY_BIOS_FARCALL86)(
+ IN EFI_LEGACY_BIOS_PROTOCOL *This,
+ IN UINT16 Segment,
+ IN UINT16 Offset,
+ IN EFI_IA32_REGISTER_SET *Regs,
+ IN VOID *Stack,
+ IN UINTN StackSize
+ );
+
+/**
+ Test to see if a legacy PCI ROM exists for this device. Optionally return
+ the Legacy ROM instance for this PCI device.
+
+ @param[in] This The protocol instance pointer.
+ @param[in] PciHandle The PCI PC-AT OPROM from this devices ROM BAR will be loaded
+ @param[out] RomImage Return the legacy PCI ROM for this device.
+ @param[out] RomSize The size of ROM Image.
+ @param[out] Flags Indicates if ROM found and if PC-AT. Multiple bits can be set as follows:
+ - 00 = No ROM.
+ - 01 = ROM Found.
+ - 02 = ROM is a valid legacy ROM.
+
+ @retval EFI_SUCCESS The Legacy Option ROM available for this device
+ @retval EFI_UNSUPPORTED The Legacy Option ROM is not supported.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_LEGACY_BIOS_CHECK_ROM)(
+ IN EFI_LEGACY_BIOS_PROTOCOL *This,
+ IN EFI_HANDLE PciHandle,
+ OUT VOID **RomImage, OPTIONAL
+ OUT UINTN *RomSize, OPTIONAL
+ OUT UINTN *Flags
+ );
+
+/**
+ Load a legacy PC-AT OPROM on the PciHandle device. Return information
+ about how many disks were added by the OPROM and the shadow address and
+ size. DiskStart & DiskEnd are INT 13h drive letters. Thus 0x80 is C:
+
+ @param[in] This The protocol instance pointer.
+ @param[in] PciHandle The PCI PC-AT OPROM from this devices ROM BAR will be loaded.
+ This value is NULL if RomImage is non-NULL. This is the normal
+ case.
+ @param[in] RomImage A PCI PC-AT ROM image. This argument is non-NULL if there is
+ no hardware associated with the ROM and thus no PciHandle,
+ otherwise is must be NULL.
+ Example is PXE base code.
+ @param[out] Flags The type of ROM discovered. Multiple bits can be set, as follows:
+ - 00 = No ROM.
+ - 01 = ROM found.
+ - 02 = ROM is a valid legacy ROM.
+ @param[out] DiskStart The disk number of first device hooked by the ROM. If DiskStart
+ is the same as DiskEnd no disked were hooked.
+ @param[out] DiskEnd disk number of the last device hooked by the ROM.
+ @param[out] RomShadowAddress Shadow address of PC-AT ROM.
+ @param[out] RomShadowSize Size of RomShadowAddress in bytes.
+
+ @retval EFI_SUCCESS Thunk completed, see Regs for status.
+ @retval EFI_INVALID_PARAMETER PciHandle not found
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_LEGACY_BIOS_INSTALL_ROM)(
+ IN EFI_LEGACY_BIOS_PROTOCOL *This,
+ IN EFI_HANDLE PciHandle,
+ IN VOID **RomImage,
+ OUT UINTN *Flags,
+ OUT UINT8 *DiskStart, OPTIONAL
+ OUT UINT8 *DiskEnd, OPTIONAL
+ OUT VOID **RomShadowAddress, OPTIONAL
+ OUT UINT32 *ShadowedRomSize OPTIONAL
+ );
+
+/**
+ This function attempts to traditionally boot the specified BootOption. If the EFI context has
+ been compromised, this function will not return. This procedure is not used for loading an EFI-aware
+ OS off a traditional device. The following actions occur:
+ - Get EFI SMBIOS data structures, convert them to a traditional format, and copy to
+ Compatibility16.
+ - Get a pointer to ACPI data structures and copy the Compatibility16 RSD PTR to F0000 block.
+ - Find the traditional SMI handler from a firmware volume and register the traditional SMI
+ handler with the EFI SMI handler.
+ - Build onboard IDE information and pass this information to the Compatibility16 code.
+ - Make sure all PCI Interrupt Line registers are programmed to match 8259.
+ - Reconfigure SIO devices from EFI mode (polled) into traditional mode (interrupt driven).
+ - Shadow all PCI ROMs.
+ - Set up BDA and EBDA standard areas before the legacy boot.
+ - Construct the Compatibility16 boot memory map and pass it to the Compatibility16 code.
+ - Invoke the Compatibility16 table function Compatibility16PrepareToBoot(). This
+ invocation causes a thunk into the Compatibility16 code, which sets all appropriate internal
+ data structures. The boot device list is a parameter.
+ - Invoke the Compatibility16 Table function Compatibility16Boot(). This invocation
+ causes a thunk into the Compatibility16 code, which does an INT19.
+ - If the Compatibility16Boot() function returns, then the boot failed in a graceful
+ manner--meaning that the EFI code is still valid. An ungraceful boot failure causes a reset because the state
+ of EFI code is unknown.
+
+ @param[in] This The protocol instance pointer.
+ @param[in] BootOption The EFI Device Path from BootXXXX variable.
+ @param[in] LoadOptionSize The size of LoadOption in size.
+ @param[in] LoadOption LThe oadOption from BootXXXX variable.
+
+ @retval EFI_DEVICE_ERROR Failed to boot from any boot device and memory is uncorrupted. Note: This function normally does not returns. It will either boot the OS or reset the system if memory has been "corrupted" by loading a boot sector and passing control to it.
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_LEGACY_BIOS_BOOT)(
+ IN EFI_LEGACY_BIOS_PROTOCOL *This,
+ IN BBS_BBS_DEVICE_PATH *BootOption,
+ IN UINT32 LoadOptionsSize,
+ IN VOID *LoadOptions
+ );
+
+/**
+ This function takes the Leds input parameter and sets/resets the BDA accordingly.
+ Leds is also passed to Compatibility16 code, in case any special processing is required.
+ This function is normally called from EFI Setup drivers that handle user-selectable
+ keyboard options such as boot with NUM LOCK on/off. This function does not
+ touch the keyboard or keyboard LEDs but only the BDA.
+
+ @param[in] This The protocol instance pointer.
+ @param[in] Leds The status of current Scroll, Num & Cap lock LEDS:
+ - Bit 0 is Scroll Lock 0 = Not locked.
+ - Bit 1 is Num Lock.
+ - Bit 2 is Caps Lock.
+
+ @retval EFI_SUCCESS The BDA was updated successfully.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_LEGACY_BIOS_UPDATE_KEYBOARD_LED_STATUS)(
+ IN EFI_LEGACY_BIOS_PROTOCOL *This,
+ IN UINT8 Leds
+ );
+
+/**
+ Retrieve legacy BBS info and assign boot priority.
+
+ @param[in] This The protocol instance pointer.
+ @param[out] HddCount The number of HDD_INFO structures.
+ @param[out] HddInfo Onboard IDE controller information.
+ @param[out] BbsCount The number of BBS_TABLE structures.
+ @param[in,out] BbsTable Points to List of BBS_TABLE.
+
+ @retval EFI_SUCCESS Tables were returned.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_LEGACY_BIOS_GET_BBS_INFO)(
+ IN EFI_LEGACY_BIOS_PROTOCOL *This,
+ OUT UINT16 *HddCount,
+ OUT HDD_INFO **HddInfo,
+ OUT UINT16 *BbsCount,
+ IN OUT BBS_TABLE **BbsTable
+ );
+
+/**
+ Assign drive number to legacy HDD drives prior to booting an EFI
+ aware OS so the OS can access drives without an EFI driver.
+
+ @param[in] This The protocol instance pointer.
+ @param[out] BbsCount The number of BBS_TABLE structures
+ @param[out] BbsTable List of BBS entries
+
+ @retval EFI_SUCCESS Drive numbers assigned.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_LEGACY_BIOS_PREPARE_TO_BOOT_EFI)(
+ IN EFI_LEGACY_BIOS_PROTOCOL *This,
+ OUT UINT16 *BbsCount,
+ OUT BBS_TABLE **BbsTable
+ );
+
+/**
+ To boot from an unconventional device like parties and/or execute
+ HDD diagnostics.
+
+ @param[in] This The protocol instance pointer.
+ @param[in] Attributes How to interpret the other input parameters.
+ @param[in] BbsEntry The 0-based index into the BbsTable for the parent
+ device.
+ @param[in] BeerData A pointer to the 128 bytes of ram BEER data.
+ @param[in] ServiceAreaData A pointer to the 64 bytes of raw Service Area data. The
+ caller must provide a pointer to the specific Service
+ Area and not the start all Service Areas.
+
+ @retval EFI_INVALID_PARAMETER If error. Does NOT return if no error.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_LEGACY_BIOS_BOOT_UNCONVENTIONAL_DEVICE)(
+ IN EFI_LEGACY_BIOS_PROTOCOL *This,
+ IN UDC_ATTRIBUTES Attributes,
+ IN UINTN BbsEntry,
+ IN VOID *BeerData,
+ IN VOID *ServiceAreaData
+ );
+
+/**
+ Shadow all legacy16 OPROMs that haven't been shadowed.
+ Warning: Use this with caution. This routine disconnects all EFI
+ drivers. If used externally, then the caller must re-connect EFI
+ drivers.
+
+ @param[in] This The protocol instance pointer.
+
+ @retval EFI_SUCCESS OPROMs were shadowed.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_LEGACY_BIOS_SHADOW_ALL_LEGACY_OPROMS)(
+ IN EFI_LEGACY_BIOS_PROTOCOL *This
+ );
+
+/**
+ Get a region from the LegacyBios for S3 usage.
+
+ @param[in] This The protocol instance pointer.
+ @param[in] LegacyMemorySize The size of required region.
+ @param[in] Region The region to use.
+ 00 = Either 0xE0000 or 0xF0000 block.
+ - Bit0 = 1 0xF0000 block.
+ - Bit1 = 1 0xE0000 block.
+ @param[in] Alignment Address alignment. Bit mapped. The first non-zero
+ bit from right is alignment.
+ @param[out] LegacyMemoryAddress The Region Assigned
+
+ @retval EFI_SUCCESS The Region was assigned.
+ @retval EFI_ACCESS_DENIED The function was previously invoked.
+ @retval Other The Region was not assigned.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_LEGACY_BIOS_GET_LEGACY_REGION)(
+ IN EFI_LEGACY_BIOS_PROTOCOL *This,
+ IN UINTN LegacyMemorySize,
+ IN UINTN Region,
+ IN UINTN Alignment,
+ OUT VOID **LegacyMemoryAddress
+ );
+
+/**
+ Get a region from the LegacyBios for Tiano usage. Can only be invoked once.
+
+ @param[in] This The protocol instance pointer.
+ @param[in] LegacyMemorySize The size of data to copy.
+ @param[in] LegacyMemoryAddress The Legacy Region destination address.
+ Note: must be in region assigned by
+ LegacyBiosGetLegacyRegion.
+ @param[in] LegacyMemorySourceAddress The source of the data to copy.
+
+ @retval EFI_SUCCESS The Region assigned.
+ @retval EFI_ACCESS_DENIED Destination was outside an assigned region.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_LEGACY_BIOS_COPY_LEGACY_REGION)(
+ IN EFI_LEGACY_BIOS_PROTOCOL *This,
+ IN UINTN LegacyMemorySize,
+ IN VOID *LegacyMemoryAddress,
+ IN VOID *LegacyMemorySourceAddress
+ );
+
+///
+/// Abstracts the traditional BIOS from the rest of EFI. The LegacyBoot()
+/// member function allows the BDS to support booting a traditional OS.
+/// EFI thunks drivers that make EFI bindings for BIOS INT services use
+/// all the other member functions.
+///
+struct _EFI_LEGACY_BIOS_PROTOCOL {
+ ///
+ /// Performs traditional software INT. See the Int86() function description.
+ ///
+ EFI_LEGACY_BIOS_INT86 Int86;
+
+ ///
+ /// Performs a far call into Compatibility16 or traditional OpROM code.
+ ///
+ EFI_LEGACY_BIOS_FARCALL86 FarCall86;
+
+ ///
+ /// Checks if a traditional OpROM exists for this device.
+ ///
+ EFI_LEGACY_BIOS_CHECK_ROM CheckPciRom;
+
+ ///
+ /// Loads a traditional OpROM in traditional OpROM address space.
+ ///
+ EFI_LEGACY_BIOS_INSTALL_ROM InstallPciRom;
+
+ ///
+ /// Boots a traditional OS.
+ ///
+ EFI_LEGACY_BIOS_BOOT LegacyBoot;
+
+ ///
+ /// Updates BDA to reflect the current EFI keyboard LED status.
+ ///
+ EFI_LEGACY_BIOS_UPDATE_KEYBOARD_LED_STATUS UpdateKeyboardLedStatus;
+
+ ///
+ /// Allows an external agent, such as BIOS Setup, to get the BBS data.
+ ///
+ EFI_LEGACY_BIOS_GET_BBS_INFO GetBbsInfo;
+
+ ///
+ /// Causes all legacy OpROMs to be shadowed.
+ ///
+ EFI_LEGACY_BIOS_SHADOW_ALL_LEGACY_OPROMS ShadowAllLegacyOproms;
+
+ ///
+ /// Performs all actions prior to boot. Used when booting an EFI-aware OS
+ /// rather than a legacy OS.
+ ///
+ EFI_LEGACY_BIOS_PREPARE_TO_BOOT_EFI PrepareToBootEfi;
+
+ ///
+ /// Allows EFI to reserve an area in the 0xE0000 or 0xF0000 block.
+ ///
+ EFI_LEGACY_BIOS_GET_LEGACY_REGION GetLegacyRegion;
+
+ ///
+ /// Allows EFI to copy data to the area specified by GetLegacyRegion.
+ ///
+ EFI_LEGACY_BIOS_COPY_LEGACY_REGION CopyLegacyRegion;
+
+ ///
+ /// Allows the user to boot off an unconventional device such as a PARTIES partition.
+ ///
+ EFI_LEGACY_BIOS_BOOT_UNCONVENTIONAL_DEVICE BootUnconventionalDevice;
+};
+
+//
+// Legacy BIOS needs to access memory in page 0 (0-4095), which is disabled if
+// NULL pointer detection feature is enabled. Following macro can be used to
+// enable/disable page 0 before/after accessing it.
+//
+#define ACCESS_PAGE0_CODE(statements) \
+ do { \
+ EFI_STATUS Status_; \
+ EFI_GCD_MEMORY_SPACE_DESCRIPTOR Desc_; \
+ \
+ Desc_.Attributes = 0; \
+ Status_ = gDS->GetMemorySpaceDescriptor (0, &Desc_); \
+ ASSERT_EFI_ERROR (Status_); \
+ if ((Desc_.Attributes & EFI_MEMORY_RP) != 0) { \
+ Status_ = gDS->SetMemorySpaceAttributes ( \
+ 0, \
+ EFI_PAGES_TO_SIZE(1), \
+ Desc_.Attributes & ~(UINT64)EFI_MEMORY_RP \
+ ); \
+ ASSERT_EFI_ERROR (Status_); \
+ } \
+ \
+ { \
+ statements; \
+ } \
+ \
+ if ((Desc_.Attributes & EFI_MEMORY_RP) != 0) { \
+ Status_ = gDS->SetMemorySpaceAttributes ( \
+ 0, \
+ EFI_PAGES_TO_SIZE(1), \
+ Desc_.Attributes \
+ ); \
+ ASSERT_EFI_ERROR (Status_); \
+ } \
+ } while (FALSE)
+
+extern EFI_GUID gEfiLegacyBiosProtocolGuid;
+
+#endif
--
2.12.0.windows.1
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH v2 6/6] OvmfPkg/IncompatiblePciDeviceSupportDxe: Drop framework pkg dependency
2019-06-11 1:43 [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency Wu, Hao A
` (4 preceding siblings ...)
2019-06-11 1:43 ` [PATCH v2 5/6] OvmfPkg: Copy LegacyBios protocol definitions from IntelFrameworkPkg Wu, Hao A
@ 2019-06-11 1:43 ` Wu, Hao A
2019-06-11 6:49 ` [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency Ard Biesheuvel
2019-06-11 7:35 ` Jordan Justen
7 siblings, 0 replies; 24+ messages in thread
From: Wu, Hao A @ 2019-06-11 1:43 UTC (permalink / raw)
To: devel; +Cc: Hao A Wu, Ray Ni, Jordan Justen, Laszlo Ersek, Ard Biesheuvel
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1843
This commit will drop the driver's dependency on the IntelFrameworkPkg:
gEfiLegacyBiosProtocolGuid
Such dependency has already been addressed by the previous commit that
duplicates the LegacyBios protocol header file from IntelFrameworkPkg into
the OvmfPkg.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
---
OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf | 1 -
1 file changed, 1 deletion(-)
diff --git a/OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf b/OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
index e13577530d..f08b6f4bd4 100644
--- a/OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
+++ b/OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
@@ -20,7 +20,6 @@ [Sources]
IncompatiblePciDeviceSupport.c
[Packages]
- IntelFrameworkPkg/IntelFrameworkPkg.dec
MdeModulePkg/MdeModulePkg.dec
MdePkg/MdePkg.dec
OvmfPkg/OvmfPkg.dec
--
2.12.0.windows.1
^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency
2019-06-11 1:43 [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency Wu, Hao A
` (5 preceding siblings ...)
2019-06-11 1:43 ` [PATCH v2 6/6] OvmfPkg/IncompatiblePciDeviceSupportDxe: Drop framework pkg dependency Wu, Hao A
@ 2019-06-11 6:49 ` Ard Biesheuvel
2019-06-11 7:35 ` Jordan Justen
7 siblings, 0 replies; 24+ messages in thread
From: Ard Biesheuvel @ 2019-06-11 6:49 UTC (permalink / raw)
To: Hao A Wu
Cc: edk2-devel-groups-io, Ray Ni, David Woodhouse, Jordan Justen,
Laszlo Ersek
On Tue, 11 Jun 2019 at 03:43, Hao A Wu <hao.a.wu@intel.com> wrote:
>
> The series is also available at:
> https://github.com/hwu25/edk2/tree/ovmf_drop_framework_v2
>
> V2 changes:
>
> * Update to module OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf has been
> dropped, since the module is proposed to be removed in another series:
> https://edk2.groups.io/g/devel/message/42142
>
> * Copy LegacyBios protocol definitions from IntelFrameworkPkg, since
> OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
> has a dependency on it. This was not done in V1 series since such copy
> was previous covered by another series to duplicate the required CSM
> modules into OvmfPkg. (Now this series has been dropped.)
>
>
> V1 history:
>
> The series will drop the IntelFramework[Module]Pkg dependency for below
> modules within OvmfPkg:
>
> OvmfPkg/PlatformPei/PlatformPei.inf
> OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
> OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf
>
>
> Verification done for the series:
> * Build pass for OvmfPkg;
> * Boot to shell with the built images.
>
> Cc: Ray Ni <ray.ni@intel.com>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Laszlo Ersek <lersek@redhat.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
> Hao A Wu (6):
> OvmfPkg/PlatformPei: Remove redundant reference of framework pkg DEC
> OvmfPkg/OvmfPkg.dec: Add PcdShellFile in OVMF DEC file
> OvmfPkg/PlatformBootManagerLib: Use PcdShellFile defined in OvmfPkg
> OvmfPkg/DSC: Remove the consume of PcdShellFile in framework package
> OvmfPkg: Copy LegacyBios protocol definitions from IntelFrameworkPkg
> OvmfPkg/IncompatiblePciDeviceSupportDxe: Drop framework pkg dependency
>
As before
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
but Laszlo needs to ack this as well.
> OvmfPkg/OvmfPkg.dec | 4 +
> OvmfPkg/OvmfPkgIa32.dsc | 2 -
> OvmfPkg/OvmfPkgIa32X64.dsc | 2 -
> OvmfPkg/OvmfPkgX64.dsc | 2 -
> OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf | 1 -
> OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf | 5 +-
> OvmfPkg/PlatformPei/PlatformPei.inf | 3 +-
> OvmfPkg/Include/Protocol/LegacyBios.h | 1553 ++++++++++++++++++++
> 8 files changed, 1560 insertions(+), 12 deletions(-)
> create mode 100644 OvmfPkg/Include/Protocol/LegacyBios.h
>
> --
> 2.12.0.windows.1
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency
2019-06-11 1:43 [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency Wu, Hao A
` (6 preceding siblings ...)
2019-06-11 6:49 ` [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency Ard Biesheuvel
@ 2019-06-11 7:35 ` Jordan Justen
2019-06-11 7:37 ` David Woodhouse
7 siblings, 1 reply; 24+ messages in thread
From: Jordan Justen @ 2019-06-11 7:35 UTC (permalink / raw)
To: Hao A Wu, devel
Cc: Hao A Wu, Ray Ni, David Woodhouse, Laszlo Ersek, Ard Biesheuvel,
D Scott Phillips
On 2019-06-10 18:43:07, Hao A Wu wrote:
> The series is also available at:
> https://github.com/hwu25/edk2/tree/ovmf_drop_framework_v2
>
> V2 changes:
>
> * Update to module OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf has been
> dropped, since the module is proposed to be removed in another series:
> https://edk2.groups.io/g/devel/message/42142
I see that https://bugzilla.tianocore.org/show_bug.cgi?id=1811
mentions that there is "missing of reviewer/maintainer of the CSM
modules in OvmfPkg", so it will be dropped. Yet, I thought David
agreed to maintain that support as recently as May 20:
https://edk2.groups.io/g/devel/message/41049
Maybe he changed his mind about it?
By the way, I know that Scott (Cc'd) was interested in leveraging CSM
support of OVMF for a fork that supports the BSD bhyve hypervisor.
-Jordan
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency
2019-06-11 7:35 ` Jordan Justen
@ 2019-06-11 7:37 ` David Woodhouse
2019-06-11 7:49 ` Wu, Hao A
0 siblings, 1 reply; 24+ messages in thread
From: David Woodhouse @ 2019-06-11 7:37 UTC (permalink / raw)
To: Jordan Justen, Hao A Wu, devel
Cc: Ray Ni, Laszlo Ersek, Ard Biesheuvel, D Scott Phillips
[-- Attachment #1: Type: text/plain, Size: 608 bytes --]
On Tue, 2019-06-11 at 00:35 -0700, Jordan Justen wrote:
> I see that https://bugzilla.tianocore.org/show_bug.cgi?id=1811
> mentions that there is "missing of reviewer/maintainer of the CSM
> modules in OvmfPkg", so it will be dropped. Yet, I thought David
> agreed to maintain that support as recently as May 20:
>
> https://edk2.groups.io/g/devel/message/41049
>
> Maybe he changed his mind about it?
No, I'm happy to do it. Just been fairly busy recently.
There appears to be nothing actually on fire this week. I may actually
get to spend some quality time making sure it works again.
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency
2019-06-11 7:37 ` David Woodhouse
@ 2019-06-11 7:49 ` Wu, Hao A
2019-06-11 8:01 ` David Woodhouse
0 siblings, 1 reply; 24+ messages in thread
From: Wu, Hao A @ 2019-06-11 7:49 UTC (permalink / raw)
To: David Woodhouse, Justen, Jordan L, devel@edk2.groups.io
Cc: Ni, Ray, Laszlo Ersek, Ard Biesheuvel, Phillips, D Scott
> -----Original Message-----
> From: David Woodhouse [mailto:dwmw2@infradead.org]
> Sent: Tuesday, June 11, 2019 3:37 PM
> To: Justen, Jordan L; Wu, Hao A; devel@edk2.groups.io
> Cc: Ni, Ray; Laszlo Ersek; Ard Biesheuvel; Phillips, D Scott
> Subject: Re: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg
> dependency
>
> On Tue, 2019-06-11 at 00:35 -0700, Jordan Justen wrote:
> > I see that https://bugzilla.tianocore.org/show_bug.cgi?id=1811
> > mentions that there is "missing of reviewer/maintainer of the CSM
> > modules in OvmfPkg", so it will be dropped. Yet, I thought David
> > agreed to maintain that support as recently as May 20:
> >
> > https://edk2.groups.io/g/devel/message/41049
> >
> > Maybe he changed his mind about it?
>
> No, I'm happy to do it. Just been fairly busy recently.
>
> There appears to be nothing actually on fire this week. I may actually
> get to spend some quality time making sure it works again.
Hello all,
For the series:
[PATCH v2 00/10] Duplicate required CSM components for OVMF
https://edk2.groups.io/g/devel/message/41385
I sent it out on May 27th, and did not receive a confirmation from David
for about 2 weeks. I think maybe the CSM support on OVMF is no longer
cared, and thus I sent another series today to drop such support:
[PATCH v1 0/2] OVMF: Drop CSM support
https://edk2.groups.io/g/devel/message/42142
Please help to provide some feedbacks/confirmation on what should I do for
the next step. (This task actually blocks our proposal to remove
IntelFramework[Module]Pkg from edk2.)
Thanks in advance.
Best Regards,
Hao Wu
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency
2019-06-11 7:49 ` Wu, Hao A
@ 2019-06-11 8:01 ` David Woodhouse
2019-06-11 8:06 ` Wu, Hao A
2019-06-12 1:19 ` Wu, Hao A
0 siblings, 2 replies; 24+ messages in thread
From: David Woodhouse @ 2019-06-11 8:01 UTC (permalink / raw)
To: Wu, Hao A, Justen, Jordan L, devel@edk2.groups.io
Cc: Ni, Ray, Laszlo Ersek, Ard Biesheuvel, Phillips, D Scott
[-- Attachment #1: Type: text/plain, Size: 1466 bytes --]
On Tue, 2019-06-11 at 07:49 +0000, Wu, Hao A wrote:
> Hello all,
>
> For the series:
> [PATCH v2 00/10] Duplicate required CSM components for OVMF
> https://edk2.groups.io/g/devel/message/41385
>
> I sent it out on May 27th, and did not receive a confirmation from David
> for about 2 weeks. I think maybe the CSM support on OVMF is no longer
> cared, and thus I sent another series today to drop such support:
> [PATCH v1 0/2] OVMF: Drop CSM support
> https://edk2.groups.io/g/devel/message/42142
>
> Please help to provide some feedbacks/confirmation on what should I do for
> the next step. (This task actually blocks our proposal to remove
> IntelFramework[Module]Pkg from edk2.)
Apologies for the delay. It wasn't clear that the first series was
actually tested by booting with a CSM, and I was reluctant to ack it
without knowing that it didn't cause a regression.
This is, of course, complicated by the fact that I can't actually get a
CSM boot to complete at the moment. But it gets a long way into the
boot process before something goes wrong, so confirmation that it still
gets at least that far with your 'Duplicate required CSM components'
series would be good.
Is there a git tree I can pull from? I seem to recall that last time I
spent serious time working on OVMF, life was horribly complicated by
CRLF line endings, and it was extremely painful to just apply patches
from email... is that still the case?
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency
2019-06-11 8:01 ` David Woodhouse
@ 2019-06-11 8:06 ` Wu, Hao A
2019-06-12 1:19 ` Wu, Hao A
1 sibling, 0 replies; 24+ messages in thread
From: Wu, Hao A @ 2019-06-11 8:06 UTC (permalink / raw)
To: David Woodhouse, Justen, Jordan L, devel@edk2.groups.io
Cc: Ni, Ray, Laszlo Ersek, Ard Biesheuvel, Phillips, D Scott
> -----Original Message-----
> From: David Woodhouse [mailto:dwmw2@infradead.org]
> Sent: Tuesday, June 11, 2019 4:01 PM
> To: Wu, Hao A; Justen, Jordan L; devel@edk2.groups.io
> Cc: Ni, Ray; Laszlo Ersek; Ard Biesheuvel; Phillips, D Scott
> Subject: Re: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg
> dependency
>
> On Tue, 2019-06-11 at 07:49 +0000, Wu, Hao A wrote:
> > Hello all,
> >
> > For the series:
> > [PATCH v2 00/10] Duplicate required CSM components for OVMF
> > https://edk2.groups.io/g/devel/message/41385
> >
> > I sent it out on May 27th, and did not receive a confirmation from David
> > for about 2 weeks. I think maybe the CSM support on OVMF is no longer
> > cared, and thus I sent another series today to drop such support:
> > [PATCH v1 0/2] OVMF: Drop CSM support
> > https://edk2.groups.io/g/devel/message/42142
> >
> > Please help to provide some feedbacks/confirmation on what should I do
> for
> > the next step. (This task actually blocks our proposal to remove
> > IntelFramework[Module]Pkg from edk2.)
>
>
> Apologies for the delay. It wasn't clear that the first series was
> actually tested by booting with a CSM, and I was reluctant to ack it
> without knowing that it didn't cause a regression.
Agree, I understand that.
>
> This is, of course, complicated by the fact that I can't actually get a
> CSM boot to complete at the moment. But it gets a long way into the
> boot process before something goes wrong, so confirmation that it still
> gets at least that far with your 'Duplicate required CSM components'
> series would be good.
>
> Is there a git tree I can pull from? I seem to recall that last time I
> spent serious time working on OVMF, life was horribly complicated by
> CRLF line endings, and it was extremely painful to just apply patches
> from email... is that still the case?
Yes, you can get the first series at:
https://github.com/hwu25/edk2/commits/ovmf_csm_v2
Best Regards,
Hao Wu
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency
2019-06-11 8:01 ` David Woodhouse
2019-06-11 8:06 ` Wu, Hao A
@ 2019-06-12 1:19 ` Wu, Hao A
2019-06-12 2:04 ` Ni, Ray
1 sibling, 1 reply; 24+ messages in thread
From: Wu, Hao A @ 2019-06-12 1:19 UTC (permalink / raw)
To: David Woodhouse, Justen, Jordan L, devel@edk2.groups.io
Cc: Ni, Ray, Laszlo Ersek, Ard Biesheuvel, Phillips, D Scott
> -----Original Message-----
> From: Wu, Hao A
> Sent: Tuesday, June 11, 2019 4:06 PM
> To: 'David Woodhouse'; Justen, Jordan L; devel@edk2.groups.io
> Cc: Ni, Ray; Laszlo Ersek; Ard Biesheuvel; Phillips, D Scott
> Subject: RE: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg
> dependency
>
> > -----Original Message-----
> > From: David Woodhouse [mailto:dwmw2@infradead.org]
> > Sent: Tuesday, June 11, 2019 4:01 PM
> > To: Wu, Hao A; Justen, Jordan L; devel@edk2.groups.io
> > Cc: Ni, Ray; Laszlo Ersek; Ard Biesheuvel; Phillips, D Scott
> > Subject: Re: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg
> > dependency
> >
> > On Tue, 2019-06-11 at 07:49 +0000, Wu, Hao A wrote:
> > > Hello all,
> > >
> > > For the series:
> > > [PATCH v2 00/10] Duplicate required CSM components for OVMF
> > > https://edk2.groups.io/g/devel/message/41385
> > >
> > > I sent it out on May 27th, and did not receive a confirmation from David
> > > for about 2 weeks. I think maybe the CSM support on OVMF is no longer
> > > cared, and thus I sent another series today to drop such support:
> > > [PATCH v1 0/2] OVMF: Drop CSM support
> > > https://edk2.groups.io/g/devel/message/42142
> > >
> > > Please help to provide some feedbacks/confirmation on what should I do
> > for
> > > the next step. (This task actually blocks our proposal to remove
> > > IntelFramework[Module]Pkg from edk2.)
> >
> >
> > Apologies for the delay. It wasn't clear that the first series was
> > actually tested by booting with a CSM, and I was reluctant to ack it
> > without knowing that it didn't cause a regression.
>
> Agree, I understand that.
>
> >
> > This is, of course, complicated by the fact that I can't actually get a
> > CSM boot to complete at the moment. But it gets a long way into the
> > boot process before something goes wrong, so confirmation that it still
> > gets at least that far with your 'Duplicate required CSM components'
> > series would be good.
> >
> > Is there a git tree I can pull from? I seem to recall that last time I
> > spent serious time working on OVMF, life was horribly complicated by
> > CRLF line endings, and it was extremely painful to just apply patches
> > from email... is that still the case?
>
> Yes, you can get the first series at:
> https://github.com/hwu25/edk2/commits/ovmf_csm_v2
Hello David,
May I know how long will it take for your verification and acknowledging
the series that duplicate the required CSM modules under OvmfPkg?
Thanks in advance.
Best Regards,
Hao Wu
>
> Best Regards,
> Hao Wu
>
> >
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency
2019-06-12 1:19 ` Wu, Hao A
@ 2019-06-12 2:04 ` Ni, Ray
2019-06-12 2:13 ` Wu, Hao A
0 siblings, 1 reply; 24+ messages in thread
From: Ni, Ray @ 2019-06-12 2:04 UTC (permalink / raw)
To: Wu, Hao A, David Woodhouse, Justen, Jordan L,
devel@edk2.groups.io
Cc: Laszlo Ersek, Ard Biesheuvel, Phillips, D Scott
Hao,
Will the CSM duplication cause any code change that may impact CSM functionality?
If no, how about firstly duplicate them first?
David,
Will this approach work for you?
Thanks,
Ray
> -----Original Message-----
> From: Wu, Hao A <hao.a.wu@intel.com>
> Sent: Wednesday, June 12, 2019 9:19 AM
> To: David Woodhouse <dwmw2@infradead.org>; Justen, Jordan L
> <jordan.l.justen@intel.com>; devel@edk2.groups.io
> Cc: Ni, Ray <ray.ni@intel.com>; Laszlo Ersek <lersek@redhat.com>; Ard
> Biesheuvel <ard.biesheuvel@linaro.org>; Phillips, D Scott
> <d.scott.phillips@intel.com>
> Subject: RE: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg
> dependency
>
> > -----Original Message-----
> > From: Wu, Hao A
> > Sent: Tuesday, June 11, 2019 4:06 PM
> > To: 'David Woodhouse'; Justen, Jordan L; devel@edk2.groups.io
> > Cc: Ni, Ray; Laszlo Ersek; Ard Biesheuvel; Phillips, D Scott
> > Subject: RE: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg
> > dependency
> >
> > > -----Original Message-----
> > > From: David Woodhouse [mailto:dwmw2@infradead.org]
> > > Sent: Tuesday, June 11, 2019 4:01 PM
> > > To: Wu, Hao A; Justen, Jordan L; devel@edk2.groups.io
> > > Cc: Ni, Ray; Laszlo Ersek; Ard Biesheuvel; Phillips, D Scott
> > > Subject: Re: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg
> > > dependency
> > >
> > > On Tue, 2019-06-11 at 07:49 +0000, Wu, Hao A wrote:
> > > > Hello all,
> > > >
> > > > For the series:
> > > > [PATCH v2 00/10] Duplicate required CSM components for OVMF
> > > > https://edk2.groups.io/g/devel/message/41385
> > > >
> > > > I sent it out on May 27th, and did not receive a confirmation from
> > > > David for about 2 weeks. I think maybe the CSM support on OVMF is
> > > > no longer cared, and thus I sent another series today to drop such
> support:
> > > > [PATCH v1 0/2] OVMF: Drop CSM support
> > > > https://edk2.groups.io/g/devel/message/42142
> > > >
> > > > Please help to provide some feedbacks/confirmation on what should
> > > > I do
> > > for
> > > > the next step. (This task actually blocks our proposal to remove
> > > > IntelFramework[Module]Pkg from edk2.)
> > >
> > >
> > > Apologies for the delay. It wasn't clear that the first series was
> > > actually tested by booting with a CSM, and I was reluctant to ack it
> > > without knowing that it didn't cause a regression.
> >
> > Agree, I understand that.
> >
> > >
> > > This is, of course, complicated by the fact that I can't actually
> > > get a CSM boot to complete at the moment. But it gets a long way
> > > into the boot process before something goes wrong, so confirmation
> > > that it still gets at least that far with your 'Duplicate required CSM
> components'
> > > series would be good.
> > >
> > > Is there a git tree I can pull from? I seem to recall that last time
> > > I spent serious time working on OVMF, life was horribly complicated
> > > by CRLF line endings, and it was extremely painful to just apply
> > > patches from email... is that still the case?
> >
> > Yes, you can get the first series at:
> > https://github.com/hwu25/edk2/commits/ovmf_csm_v2
>
> Hello David,
>
> May I know how long will it take for your verification and acknowledging the
> series that duplicate the required CSM modules under OvmfPkg?
>
> Thanks in advance.
>
> Best Regards,
> Hao Wu
>
> >
> > Best Regards,
> > Hao Wu
> >
> > >
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency
2019-06-12 2:04 ` Ni, Ray
@ 2019-06-12 2:13 ` Wu, Hao A
2019-06-12 7:58 ` Laszlo Ersek
0 siblings, 1 reply; 24+ messages in thread
From: Wu, Hao A @ 2019-06-12 2:13 UTC (permalink / raw)
To: Ni, Ray, David Woodhouse, Justen, Jordan L, devel@edk2.groups.io
Cc: Laszlo Ersek, Ard Biesheuvel, Phillips, D Scott
> -----Original Message-----
> From: Ni, Ray
> Sent: Wednesday, June 12, 2019 10:04 AM
> To: Wu, Hao A; David Woodhouse; Justen, Jordan L; devel@edk2.groups.io
> Cc: Laszlo Ersek; Ard Biesheuvel; Phillips, D Scott
> Subject: RE: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg
> dependency
>
> Hao,
> Will the CSM duplication cause any code change that may impact CSM
> functionality?
Hello Ray,
I think there should be no functional impact for the duplication.
There is no change to the .C/.H files.
Best Regards,
Hao Wu
> If no, how about firstly duplicate them first?
>
> David,
> Will this approach work for you?
>
> Thanks,
> Ray
>
> > -----Original Message-----
> > From: Wu, Hao A <hao.a.wu@intel.com>
> > Sent: Wednesday, June 12, 2019 9:19 AM
> > To: David Woodhouse <dwmw2@infradead.org>; Justen, Jordan L
> > <jordan.l.justen@intel.com>; devel@edk2.groups.io
> > Cc: Ni, Ray <ray.ni@intel.com>; Laszlo Ersek <lersek@redhat.com>; Ard
> > Biesheuvel <ard.biesheuvel@linaro.org>; Phillips, D Scott
> > <d.scott.phillips@intel.com>
> > Subject: RE: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg
> > dependency
> >
> > > -----Original Message-----
> > > From: Wu, Hao A
> > > Sent: Tuesday, June 11, 2019 4:06 PM
> > > To: 'David Woodhouse'; Justen, Jordan L; devel@edk2.groups.io
> > > Cc: Ni, Ray; Laszlo Ersek; Ard Biesheuvel; Phillips, D Scott
> > > Subject: RE: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg
> > > dependency
> > >
> > > > -----Original Message-----
> > > > From: David Woodhouse [mailto:dwmw2@infradead.org]
> > > > Sent: Tuesday, June 11, 2019 4:01 PM
> > > > To: Wu, Hao A; Justen, Jordan L; devel@edk2.groups.io
> > > > Cc: Ni, Ray; Laszlo Ersek; Ard Biesheuvel; Phillips, D Scott
> > > > Subject: Re: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg
> > > > dependency
> > > >
> > > > On Tue, 2019-06-11 at 07:49 +0000, Wu, Hao A wrote:
> > > > > Hello all,
> > > > >
> > > > > For the series:
> > > > > [PATCH v2 00/10] Duplicate required CSM components for OVMF
> > > > > https://edk2.groups.io/g/devel/message/41385
> > > > >
> > > > > I sent it out on May 27th, and did not receive a confirmation from
> > > > > David for about 2 weeks. I think maybe the CSM support on OVMF is
> > > > > no longer cared, and thus I sent another series today to drop such
> > support:
> > > > > [PATCH v1 0/2] OVMF: Drop CSM support
> > > > > https://edk2.groups.io/g/devel/message/42142
> > > > >
> > > > > Please help to provide some feedbacks/confirmation on what should
> > > > > I do
> > > > for
> > > > > the next step. (This task actually blocks our proposal to remove
> > > > > IntelFramework[Module]Pkg from edk2.)
> > > >
> > > >
> > > > Apologies for the delay. It wasn't clear that the first series was
> > > > actually tested by booting with a CSM, and I was reluctant to ack it
> > > > without knowing that it didn't cause a regression.
> > >
> > > Agree, I understand that.
> > >
> > > >
> > > > This is, of course, complicated by the fact that I can't actually
> > > > get a CSM boot to complete at the moment. But it gets a long way
> > > > into the boot process before something goes wrong, so confirmation
> > > > that it still gets at least that far with your 'Duplicate required CSM
> > components'
> > > > series would be good.
> > > >
> > > > Is there a git tree I can pull from? I seem to recall that last time
> > > > I spent serious time working on OVMF, life was horribly complicated
> > > > by CRLF line endings, and it was extremely painful to just apply
> > > > patches from email... is that still the case?
> > >
> > > Yes, you can get the first series at:
> > > https://github.com/hwu25/edk2/commits/ovmf_csm_v2
> >
> > Hello David,
> >
> > May I know how long will it take for your verification and acknowledging
> the
> > series that duplicate the required CSM modules under OvmfPkg?
> >
> > Thanks in advance.
> >
> > Best Regards,
> > Hao Wu
> >
> > >
> > > Best Regards,
> > > Hao Wu
> > >
> > > >
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency
2019-06-12 2:13 ` Wu, Hao A
@ 2019-06-12 7:58 ` Laszlo Ersek
2019-06-12 8:03 ` David Woodhouse
2019-06-12 9:50 ` [edk2-devel] " Ni, Ray
0 siblings, 2 replies; 24+ messages in thread
From: Laszlo Ersek @ 2019-06-12 7:58 UTC (permalink / raw)
To: Wu, Hao A, Ni, Ray, David Woodhouse, Justen, Jordan L,
devel@edk2.groups.io
Cc: Ard Biesheuvel, Phillips, D Scott
Ray,
On 06/12/19 04:13, Wu, Hao A wrote:
>> -----Original Message-----
>> From: Ni, Ray
>> Sent: Wednesday, June 12, 2019 10:04 AM
>> To: Wu, Hao A; David Woodhouse; Justen, Jordan L; devel@edk2.groups.io
>> Cc: Laszlo Ersek; Ard Biesheuvel; Phillips, D Scott
>> Subject: RE: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg
>> dependency
>>
>> Hao,
>> Will the CSM duplication cause any code change that may impact CSM
>> functionality?
>
> Hello Ray,
>
> I think there should be no functional impact for the duplication.
> There is no change to the .C/.H files.
>
> Best Regards,
> Hao Wu
>
>> If no, how about firstly duplicate them first?
>>
>> David,
>> Will this approach work for you?
It will not work for me.
Here's the problem:
- I'm not comfortable approving the duplication (or move) under OvmfPkg,
until David ACKs the patch -- the first patch in the series -- that
spells out his reviewership for the CSM modules,
- I believe David is not comfortable ACKing that patch until he can get
the CSM build to work again.
Thanks
Laszlo
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency
2019-06-12 7:58 ` Laszlo Ersek
@ 2019-06-12 8:03 ` David Woodhouse
2019-06-12 11:52 ` Laszlo Ersek
2019-06-12 9:50 ` [edk2-devel] " Ni, Ray
1 sibling, 1 reply; 24+ messages in thread
From: David Woodhouse @ 2019-06-12 8:03 UTC (permalink / raw)
To: Laszlo Ersek, Wu, Hao A, Ni, Ray, Justen, Jordan L,
devel@edk2.groups.io
Cc: Ard Biesheuvel, Phillips, D Scott
[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]
On Wed, 2019-06-12 at 09:58 +0200, Laszlo Ersek wrote:
> Ray,
>
> On 06/12/19 04:13, Wu, Hao A wrote:
> > > -----Original Message-----
> > > From: Ni, Ray
> > > Sent: Wednesday, June 12, 2019 10:04 AM
> > > To: Wu, Hao A; David Woodhouse; Justen, Jordan L; devel@edk2.groups.io
> > > Cc: Laszlo Ersek; Ard Biesheuvel; Phillips, D Scott
> > > Subject: RE: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg
> > > dependency
> > >
> > > Hao,
> > > Will the CSM duplication cause any code change that may impact CSM
> > > functionality?
> >
> > Hello Ray,
> >
> > I think there should be no functional impact for the duplication.
> > There is no change to the .C/.H files.
> >
> > Best Regards,
> > Hao Wu
> >
> > > If no, how about firstly duplicate them first?
> > >
> > > David,
> > > Will this approach work for you?
>
> It will not work for me.
>
> Here's the problem:
>
> - I'm not comfortable approving the duplication (or move) under OvmfPkg,
> until David ACKs the patch -- the first patch in the series -- that
> spells out his reviewership for the CSM modules,
I'll certainly ack that.
> - I believe David is not comfortable ACKing that patch until he can get
> the CSM build to work again.
I'm OK with it as long as the submitter has done their own testing and
confirms that it works at least as well as it did before. It does get
quite a long way into 16-bit code and then does somewhere in the CSM
itself, after a few legacy BIOS calls.
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [edk2-devel] [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency
2019-06-12 7:58 ` Laszlo Ersek
2019-06-12 8:03 ` David Woodhouse
@ 2019-06-12 9:50 ` Ni, Ray
1 sibling, 0 replies; 24+ messages in thread
From: Ni, Ray @ 2019-06-12 9:50 UTC (permalink / raw)
To: devel@edk2.groups.io, 'lersek@redhat.com', Wu, Hao A,
David Woodhouse, Justen, Jordan L
Cc: Ard Biesheuvel, Phillips, D Scott
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo
> Ersek
> Sent: Wednesday, June 12, 2019 3:58 PM
> To: Wu, Hao A <hao.a.wu@intel.com>; Ni, Ray <ray.ni@intel.com>; David
> Woodhouse <dwmw2@infradead.org>; Justen, Jordan L
> <jordan.l.justen@intel.com>; devel@edk2.groups.io
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Phillips, D Scott
> <d.scott.phillips@intel.com>
> Subject: Re: [edk2-devel] [PATCH v2 0/6] Ovmf: Drop
> IntelFramework[Module]Pkg dependency
>
> Ray,
>
> On 06/12/19 04:13, Wu, Hao A wrote:
> >> -----Original Message-----
> >> From: Ni, Ray
> >> Sent: Wednesday, June 12, 2019 10:04 AM
> >> To: Wu, Hao A; David Woodhouse; Justen, Jordan L;
> >> devel@edk2.groups.io
> >> Cc: Laszlo Ersek; Ard Biesheuvel; Phillips, D Scott
> >> Subject: RE: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg
> >> dependency
> >>
> >> Hao,
> >> Will the CSM duplication cause any code change that may impact CSM
> >> functionality?
> >
> > Hello Ray,
> >
> > I think there should be no functional impact for the duplication.
> > There is no change to the .C/.H files.
> >
> > Best Regards,
> > Hao Wu
> >
> >> If no, how about firstly duplicate them first?
> >>
> >> David,
> >> Will this approach work for you?
>
> It will not work for me.
>
> Here's the problem:
>
> - I'm not comfortable approving the duplication (or move) under OvmfPkg,
> until David ACKs the patch -- the first patch in the series -- that spells out his
> reviewership for the CSM modules,
>
> - I believe David is not comfortable ACKing that patch until he can get the
> CSM build to work again.
I thought there is a dead lock but maybe not.
I think the below things need to be done in order:
1. David gets the CSM build work again.
2. Hao sends out the patch to duplicate CSM in OvmfPkg.
3. David ACKs the patch
4. Hao pushes the patch.
But when will #1 finish?
I don't expect we stop here for a very long period.
(I cannot remember when we started this conversation, maybe several months ago.)
>
> Thanks
> Laszlo
>
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency
2019-06-12 8:03 ` David Woodhouse
@ 2019-06-12 11:52 ` Laszlo Ersek
2019-06-12 12:08 ` [edk2-devel] " David Woodhouse
2019-06-12 15:15 ` David Woodhouse
0 siblings, 2 replies; 24+ messages in thread
From: Laszlo Ersek @ 2019-06-12 11:52 UTC (permalink / raw)
To: David Woodhouse, Wu, Hao A, Ni, Ray, Justen, Jordan L,
devel@edk2.groups.io
Cc: Ard Biesheuvel, Phillips, D Scott
On 06/12/19 10:03, David Woodhouse wrote:
> On Wed, 2019-06-12 at 09:58 +0200, Laszlo Ersek wrote:
>> Ray,
>>
>> On 06/12/19 04:13, Wu, Hao A wrote:
>>>> -----Original Message-----
>>>> From: Ni, Ray
>>>> Sent: Wednesday, June 12, 2019 10:04 AM
>>>> To: Wu, Hao A; David Woodhouse; Justen, Jordan L;
>>>> devel@edk2.groups.io
>>>> Cc: Laszlo Ersek; Ard Biesheuvel; Phillips, D Scott
>>>> Subject: RE: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg
>>>> dependency
>>>>
>>>> Hao,
>>>> Will the CSM duplication cause any code change that may impact CSM
>>>> functionality?
>>>
>>> Hello Ray,
>>>
>>> I think there should be no functional impact for the duplication.
>>> There is no change to the .C/.H files.
>>>
>>> Best Regards,
>>> Hao Wu
>>>
>>>> If no, how about firstly duplicate them first?
>>>>
>>>> David,
>>>> Will this approach work for you?
>>
>> It will not work for me.
>>
>> Here's the problem:
>>
>> - I'm not comfortable approving the duplication (or move) under
>> OvmfPkg, until David ACKs the patch -- the first patch in the series
>> -- that spells out his reviewership for the CSM modules,
>
> I'll certainly ack that.
>
>> - I believe David is not comfortable ACKing that patch until he can
>> get the CSM build to work again.
>
> I'm OK with it as long as the submitter has done their own testing and
> confirms that it works at least as well as it did before.
Is that testing burden really on Hao though?
You write "it works at least as well as it did before", and I generally
agree with that -- but I doubt that Hao has *ever* built the SeaBIOS CSM
(in itself first, and then into the OVMF binary second).
IOW I consider Hao doing OvmfPkg users a favor by submitting these code
movement patch sets. When some modules become unmaintained / orphaned
and are about to be deleted, the minimum we can expect from the earlier
module maintainers is to cleanly remove all in-tree platform references.
But code movement under OvmfPkg is more than that minimum; it's a
courtesy. I don't think we should expect Hao to do this before-after
testing.
> It does get quite a long way into 16-bit code and then does somewhere
> in the CSM itself, after a few legacy BIOS calls.
FWIW, I'm getting the following results, *without* Hao's patches:
(1) QEMU is built at commit 47fbad45d47a ("Merge remote-tracking branch
'remotes/kevin/tags/for-upstream' into staging", 2019-06-04)
(2a) SeaBIOS is built at commit 85137fb5f2df ("virtio-pci: Use %pP
format in dprintf() calls", 2019-05-23)
(2b) The following out-of-tree patch is applied to SeaBIOS on top of
(2a):
> diff --git a/src/hw/serialio.c b/src/hw/serialio.c
> index 31633443780a..ed918ade9306 100644
> --- a/src/hw/serialio.c
> +++ b/src/hw/serialio.c
> @@ -116,7 +116,7 @@ qemu_debug_preinit(void)
> void
> qemu_debug_putc(char c)
> {
> - if (!CONFIG_DEBUG_IO || !runningOnQEMU())
> + if (!CONFIG_DEBUG_IO)
> return;
> u16 port = GET_GLOBAL(DebugOutputPort);
> if (port)
This is because runningOnQEMU() evaluates to false if SeaBIOS is built
as CSM (IIRC), yet I'd like to get debug output.
(2c) SeaBIOS is built *twice*, once for the CSM, and another time for
the Cirrus VGABIOS. Parts of my build script are:
> make distclean
> cat >.config <<-EOT
> CONFIG_CSM=y
> CONFIG_QEMU_HARDWARE=y
> CONFIG_PERMIT_UNALIGNED_PCIROM=y
> CONFIG_DEBUG_LEVEL=20
> CONFIG_ROM_SIZE=192
> EOT
> yes "" | make oldconfig
> make -j2 out/bios.bin
The "bios.bin" file built by this step is copied into the edk2 tree as
"OvmfPkg/Csm/Csm16/Csm16.bin".
> make distclean
> cat >.config <<-EOT
> CONFIG_QEMU=y
> CONFIG_BUILD_VGABIOS=y
> CONFIG_VGA_CIRRUS=y
> CONFIG_VGA_PCI=y
> CONFIG_DEBUG_LEVEL=20
> EOT
> yes "" | make oldconfig
> make -j2 out/vgabios.bin
The "vgabios.bin" file built by this step is copied to a different
directory under the name "vgabios-cirrus.csm.bin".
(3a) OVMF is built at edk2 commit e5b4d825afc4 ("MdeModulePkg/PciBusDxe:
catch unimplemented extended config space reads", 2019-06-11).
(3b) The following out-of-tree patch is applied on top of (3a):
> diff --git a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBootSupport.c b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> index 211750c0123b..119b5c9b6fe8 100644
> --- a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> +++ b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> @@ -1231,8 +1231,8 @@ GenericLegacyBoot (
> //
> Private->LegacyRegion->Lock (
> Private->LegacyRegion,
> - 0xc0000,
> - 0x40000,
> + 0xe0000,
> + 0x10000,
> &Granularity
> );
>
(3c) "OvmfPkg/Csm/Csm16/Csm16.bin" comes from step (2c).
(3d) The OVMF build command line is:
> build \
> -a X64 \
> -b NOOPT \
> -p OvmfPkg/OvmfPkgX64.dsc \
> -t GCC48 \
> --cmd-len=65536 \
> -D CSM_ENABLE \
> -D FD_SIZE_2MB
(4) The QEMU command line is:
> qemu-system-x86_64 \
> -nodefaults \
> -m 1024 \
> -M pc,accel=kvm \
> -device cirrus-vga,romfile=vgabios-cirrus.csm.bin \
> -drive if=pflash,readonly,format=raw,file=OVMF_CODE.fd \
> -drive if=pflash,snapshot,format=raw,file=OVMF_VARS.fd \
> -debugcon file:debug.log \
> -global isa-debugcon.iobase=0x402 \
> -chardev stdio,signal=off,mux=on,id=char0 \
> -mon chardev=char0,mode=readline \
> -serial chardev:char0 \
> -drive if=none,readonly,format=raw,file=RHEL5.11-Server-20140827.0-x86_64-DVD.iso,id=cdrom0 \
> -device ide-cd,drive=cdrom0
With these, grub is booted successfully from the RHEL5 installer ISO
(which does not support UEFI at all). Unfortunately, after grub loads
vmlinuz + initrd, it fails with "Not enough memory to load specified
image", and returns to the grub prompt. (If I double the argument to
QEMU's "-m" option, to 2048, that makes no difference.)
This is at least a graceful failure.
(5) The last time I built OVMF with the SeaBIOS CSM, edk2 was checked
out at commit 7548947d040e ("SecurityPkg/TcgPei: drop
PeiReadOnlyVariable from Depex", 2018-03-10), and SeaBIOS was checked
out at commit ec6cb17f8949 ("pci: enable RedHat PCI bridges to reserve
additional resources on PCI init", 2017-09-14).
I've retested that combination now (in place of (3a) and (2a),
respectively), and the results are identical to those from (4) (i.e.
what I'm getting with the current master HEADs).
I didn't experiment with different QEMU releases, or different versions
of the "pc" (i440fx) machine type.
I don't think it's on Hao to determine an (edk2 base commit, SeaBIOS
base commit) pair from the past at which the CSM functionality worked
"flawlessly".
Thanks
Laszlo
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [edk2-devel] [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency
2019-06-12 11:52 ` Laszlo Ersek
@ 2019-06-12 12:08 ` David Woodhouse
2019-06-13 5:47 ` Wu, Hao A
2019-06-12 15:15 ` David Woodhouse
1 sibling, 1 reply; 24+ messages in thread
From: David Woodhouse @ 2019-06-12 12:08 UTC (permalink / raw)
To: devel, lersek, Wu, Hao A, Ni, Ray, Justen, Jordan L
Cc: Ard Biesheuvel, Phillips, D Scott
[-- Attachment #1: Type: text/plain, Size: 693 bytes --]
On Wed, 2019-06-12 at 13:52 +0200, Laszlo Ersek wrote:
>
> I don't think it's on Hao to determine an (edk2 base commit, SeaBIOS
> base commit) pair from the past at which the CSM functionality worked
> "flawlessly".
Absolutely!
I was only suggesting that Hao should make sure it doesn't get worse.
When I first did it, I had various versions of Windows and Linux and
*BSD working correctly. I'm still working when time allows on working
out how to get back to that state.
But right now it does at least show that it's getting correctly into
SeaBIOS and handling a bunch of requests before it crashes. As long as
it still gets that far after Hao's patches, that's fine.
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency
2019-06-12 11:52 ` Laszlo Ersek
2019-06-12 12:08 ` [edk2-devel] " David Woodhouse
@ 2019-06-12 15:15 ` David Woodhouse
2019-06-12 16:28 ` Laszlo Ersek
1 sibling, 1 reply; 24+ messages in thread
From: David Woodhouse @ 2019-06-12 15:15 UTC (permalink / raw)
To: Laszlo Ersek, Wu, Hao A, Ni, Ray, Justen, Jordan L,
devel@edk2.groups.io
Cc: Ard Biesheuvel, Phillips, D Scott
[-- Attachment #1: Type: text/plain, Size: 6780 bytes --]
On Wed, 2019-06-12 at 13:52 +0200, Laszlo Ersek wrote:
> (2c) SeaBIOS is built *twice*, once for the CSM, and another time for
> the Cirrus VGABIOS.
We shouldn't need to rebuild the VGA BIOS, should we? Any Legacy VGA
BIOS should work — and indeed UEFI should be able to use the Legacy VGA
BIOS even if it doesn't have native support for the video hardware.
ISTR Windows 2008 even called legacy INT10 as part of the boot process
and was part of my testing at the time?
> (3b) The following out-of-tree patch is applied on top of (3a):
>
> > diff --git a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBootSupport.c b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> > index 211750c0123b..119b5c9b6fe8 100644
> > --- a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> > +++ b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> > @@ -1231,8 +1231,8 @@ GenericLegacyBoot (
> > //
> > Private->LegacyRegion->Lock (
> > Private->LegacyRegion,
> > - 0xc0000,
> > - 0x40000,
> > + 0xe0000,
> > + 0x10000,
> > &Granularity
> > );
> >
I didn't need this part.
> With these, grub is booted successfully from the RHEL5 installer ISO
> (which does not support UEFI at all). Unfortunately, after grub loads
> vmlinuz + initrd, it fails with "Not enough memory to load specified
> image", and returns to the grub prompt. (If I double the argument to
> QEMU's "-m" option, to 2048, that makes no difference.)
>
> This is at least a graceful failure.
It's because the E820 table isn't being passed through to the CSM.
Start of legacy boot
E820[ 0]: 0x0000000000000000 - 0x000000000009F000, Type = 1
E820[ 1]: 0x000000000009F000 - 0x00000000000A0000, Type = 2
E820[ 2]: 0x00000000000E0000 - 0x0000000000100000, Type = 2
E820[ 3]: 0x0000000000100000 - 0x0000000000800000, Type = 1
E820[ 4]: 0x0000000000800000 - 0x0000000000808000, Type = 4
E820[ 5]: 0x0000000000808000 - 0x0000000000810000, Type = 1
E820[ 6]: 0x0000000000810000 - 0x0000000000900000, Type = 4
E820[ 7]: 0x0000000000900000 - 0x000000007E874000, Type = 1
E820[ 8]: 0x000000007E874000 - 0x000000007E88C000, Type = 4
E820[ 9]: 0x000000007E88C000 - 0x000000007E8B0000, Type = 2
E820[10]: 0x000000007E8B0000 - 0x000000007FBEF000, Type = 1
E820[11]: 0x000000007FBEF000 - 0x000000007FBF3000, Type = 2
E820[12]: 0x000000007FBF3000 - 0x000000007FBFB000, Type = 3
E820[13]: 0x000000007FBFB000 - 0x000000007FBFF000, Type = 4
E820[14]: 0x000000007FBFF000 - 0x000000007FF78000, Type = 1
E820[15]: 0x000000007FF78000 - 0x0000000080000000, Type = 4
E820[16]: 0x0000000080000000 - 0x00000000FC000000, Type = 2
E820[17]: 0x00000000FEC00000 - 0x00000000FEC01000, Type = 2
E820[18]: 0x00000000FED00000 - 0x00000000FED00400, Type = 2
E820[19]: 0x00000000FEE00000 - 0x00000000FEF00000, Type = 2
handle_hwpic1 irq=1
handle_csm regs 0x0005ffd4 AX=0006
Legacy16GetTableAddress size 190 align 0 region 3
ebda moved from 9f000 to fffffc00
Legacy16GetTableAddress size 190 align 0 region 3 yields 0x00000000
handle_csm returning AX=0001
enter handle_15:
a=00002401 b=00000000 c=00000190 d=00000003 ds=0000 es=0000 ss=5000
si=00000000 di=00000000 bp=00000000 sp=0000ffc6 cs=5f00 ip=0030 f=3002
Legacy16 E820 length insufficient
...
handle_csm regs 0x0005ffd4 AX=0002
PrepareToBoot table 580a:0008
Add to e820 map: f000ff53f000ff53 f000ff53f000e2c3 -268370093
Add to e820 map: f000ff53f000ff54 f000ce45f000ff53 -268382651
Add to e820 map: f000ce45f000ce45 f000ce45f000ce45 -268382651
Add to e820 map: c0005212f000ce45 f000f841f000f84d -268377090
Add to e820 map: f000f859f000e739 f000efd2f000e82e -268382614
Add to e820 map: f000fe6ef000e6f2 f000ff53f000ff53 -268370093
Add to e820 map: c0009200f000ff53 f000ff53f000ff53 -268370093
Add to e820 map: f000ff53f000ff53 f000ff53f000ff53 -268370093
Add to e820 map: f000ff53f000ff53 f000ff53f000ff53 -268370093
Add to e820 map: f000ff53f000ff53 f000ff53f000ff53 -268370093
Add to e820 map: f000ff53f000ff53 f000ff53f000ff53 -268370093
Add to e820 map: f000ff53f000ff53 f000ff53f000ff53 -268370093
Add to e820 map: f000ff53f000ff53 f000ff53f000ff53 -268374951
Add to e820 map: f000ff53f000ff53 f000ff53c0007000 -268370093
Add to e820 map: f000ff53f000ff53 f000ff53f000ff53 -268370093
Add to e820 map: f000ff53f000ff53 f000ff53f000ff53 -268370093
Add to e820 map: f000ff53f000ff53 f000ff53f000ff53 -268370093
Add to e820 map: f000ff53f000ff53 f000ff53f000ff53 -268370093
Add to e820 map: f000ff53f000ff53 f000ff53f000ff53 -268370093
Add to e820 map: f000ff53 00000000 0
Add to e820 map: 007c0000 00040000 2
CSM PIRQ table at 0x000f6340
CSM ACPI RSDP at 0x000f6440
Completely bogus E820 information tends to lead to confusing out-of-
memory errors. Film at 11 :)
This fixes it:
diff --git a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBootSupport.c b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
index 211750c012..3a84fa0258 100644
--- a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
+++ b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
@@ -929,6 +929,7 @@ GenericLegacyBoot (
ZeroMem (&Regs, sizeof (EFI_IA32_REGISTER_SET));
Regs.X.AX = Legacy16GetTableAddress;
Regs.X.CX = (UINT16) CopySize;
+ Regs.X.DX = (UINT16) 1;
Private->LegacyBios.FarCall86 (
&Private->LegacyBios,
Private->Legacy16Table->Compatibility16CallSegment,
I'm going to dig out the specification and see what an align field of 0
is actually intended to mean, and whether I should really be fixing it
in SeaBIOS instead. This would also fix it:
diff --git a/src/fw/csm.c b/src/fw/csm.c
index 03b4bb8..5288096 100644
--- a/src/fw/csm.c
+++ b/src/fw/csm.c
@@ -265,9 +265,9 @@ handle_csm_0006(struct bregs *regs)
size, align, region);
if (region & 2)
- chunk = _malloc(&ZoneLow, size, align);
+ chunk = _malloc(&ZoneLow, size, align ? align : 1);
if (!chunk && (region & 1))
- chunk = _malloc(&ZoneFSeg, size, align);
+ chunk = _malloc(&ZoneFSeg, size, align ? align : 1);
dprintf(3, "Legacy16GetTableAddress size %x align %x region %d yields %p\n",
size, align, region, chunk);
I have various things booting fine with CSM again now. Thanks for
helping me work through this.
Aside from the actual allocation issue, perhaps the UEFI side should
bail out properly when it can't pass E820 information to the CSM. And
perhaps SeaBIOS should abort more cleanly if it's passed nonsense.
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]
^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency
2019-06-12 15:15 ` David Woodhouse
@ 2019-06-12 16:28 ` Laszlo Ersek
0 siblings, 0 replies; 24+ messages in thread
From: Laszlo Ersek @ 2019-06-12 16:28 UTC (permalink / raw)
To: David Woodhouse, Wu, Hao A, Ni, Ray, Justen, Jordan L,
devel@edk2.groups.io
Cc: Ard Biesheuvel, Phillips, D Scott
On 06/12/19 17:15, David Woodhouse wrote:
> On Wed, 2019-06-12 at 13:52 +0200, Laszlo Ersek wrote:
>> (2c) SeaBIOS is built *twice*, once for the CSM, and another time for
>> the Cirrus VGABIOS.
>
> We shouldn't need to rebuild the VGA BIOS, should we? Any Legacy VGA
> BIOS should work — and indeed UEFI should be able to use the Legacy VGA
> BIOS even if it doesn't have native support for the video hardware.
>
> ISTR Windows 2008 even called legacy INT10 as part of the boot process
> and was part of my testing at the time?
Agreed on both counts. But, given that both the CSM binary and the
vgabios come from the same project (SeaBIOS), and that all software has
bugs :) , I thought it prudent to build all SeaBIOS artifacts in sync,
at any given SeaBIOS commit. I was preparing for a SeaBIOS bisection too
(expecting a regression), and I wanted to cover all SeaBIOS code with
that bisection.
Thanks
Laszlo
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [edk2-devel] [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency
2019-06-12 12:08 ` [edk2-devel] " David Woodhouse
@ 2019-06-13 5:47 ` Wu, Hao A
0 siblings, 0 replies; 24+ messages in thread
From: Wu, Hao A @ 2019-06-13 5:47 UTC (permalink / raw)
To: David Woodhouse, devel@edk2.groups.io, lersek@redhat.com, Ni, Ray,
Justen, Jordan L
Cc: Ard Biesheuvel, Phillips, D Scott
> -----Original Message-----
> From: David Woodhouse [mailto:dwmw2@infradead.org]
> Sent: Wednesday, June 12, 2019 8:08 PM
> To: devel@edk2.groups.io; lersek@redhat.com; Wu, Hao A; Ni, Ray; Justen,
> Jordan L
> Cc: Ard Biesheuvel; Phillips, D Scott
> Subject: Re: [edk2-devel] [PATCH v2 0/6] Ovmf: Drop
> IntelFramework[Module]Pkg dependency
>
> On Wed, 2019-06-12 at 13:52 +0200, Laszlo Ersek wrote:
> >
> > I don't think it's on Hao to determine an (edk2 base commit, SeaBIOS
> > base commit) pair from the past at which the CSM functionality worked
> > "flawlessly".
>
> Absolutely!
>
> I was only suggesting that Hao should make sure it doesn't get worse.
The test I performed is to verify booting legacy Windows 7 on a real
platform consuming the CSM components under IntelFrameworkModulePkg.
But I do not have much idea on what should I do to verify the duplicated
components under OvmfPkg when proposing this series. Is there any
suggestion here? I tried (but not with great effort) on building a SeaBIOS
binary, but failed to do so due to limited document on how to get it done.
(Maybe an update to OvmfPkg/Csm/Csm16/ReadMe.txt?)
Best Regards,
Hao Wu
>
> When I first did it, I had various versions of Windows and Linux and
> *BSD working correctly. I'm still working when time allows on working
> out how to get back to that state.
>
> But right now it does at least show that it's getting correctly into
> SeaBIOS and handling a bunch of requests before it crashes. As long as
> it still gets that far after Hao's patches, that's fine.
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2019-06-13 5:47 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-06-11 1:43 [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency Wu, Hao A
2019-06-11 1:43 ` [PATCH v2 1/6] OvmfPkg/PlatformPei: Remove redundant reference of framework pkg DEC Wu, Hao A
2019-06-11 1:43 ` [PATCH v2 2/6] OvmfPkg/OvmfPkg.dec: Add PcdShellFile in OVMF DEC file Wu, Hao A
2019-06-11 1:43 ` [PATCH v2 3/6] OvmfPkg/PlatformBootManagerLib: Use PcdShellFile defined in OvmfPkg Wu, Hao A
2019-06-11 1:43 ` [PATCH v2 4/6] OvmfPkg/DSC: Remove the consume of PcdShellFile in framework package Wu, Hao A
2019-06-11 1:43 ` [PATCH v2 5/6] OvmfPkg: Copy LegacyBios protocol definitions from IntelFrameworkPkg Wu, Hao A
2019-06-11 1:43 ` [PATCH v2 6/6] OvmfPkg/IncompatiblePciDeviceSupportDxe: Drop framework pkg dependency Wu, Hao A
2019-06-11 6:49 ` [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency Ard Biesheuvel
2019-06-11 7:35 ` Jordan Justen
2019-06-11 7:37 ` David Woodhouse
2019-06-11 7:49 ` Wu, Hao A
2019-06-11 8:01 ` David Woodhouse
2019-06-11 8:06 ` Wu, Hao A
2019-06-12 1:19 ` Wu, Hao A
2019-06-12 2:04 ` Ni, Ray
2019-06-12 2:13 ` Wu, Hao A
2019-06-12 7:58 ` Laszlo Ersek
2019-06-12 8:03 ` David Woodhouse
2019-06-12 11:52 ` Laszlo Ersek
2019-06-12 12:08 ` [edk2-devel] " David Woodhouse
2019-06-13 5:47 ` Wu, Hao A
2019-06-12 15:15 ` David Woodhouse
2019-06-12 16:28 ` Laszlo Ersek
2019-06-12 9:50 ` [edk2-devel] " Ni, Ray
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox