Re: [edk2] [Patch] UefiCpuPkg/MpInitLib: Direct allocate buffer for Wake up Buffer.
Just an idea to avoid hard code value 0x88000.
Before EndOfDxe: Allocate buffer in AllocateResetVector(), and free buffer in
FreeResetVector().
At EndOfDxe (it is after LegacyBiosDxe driver entry point) callback: Allocate
buffer and record it to CpuMpData->WakeupBuffer, and always occupy the buffer,
that means no free.
After EndOfDxe: Use CpuMpData->WakeupBuffer.
Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Eric Dong
Sent: Tuesday, March 5, 2019 10:07 AM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch] UefiCpuPkg/MpInitLib: Direct allocate buffer for Wake
up Buffer.
https://bugzilla.tianocore.org/show_bug.cgi?id=1538
Current CpuDxe driver "borrows" Wakeup Buffer (through Allocate & free to get
the buffer pointer, backup the buffer data before using it and restore it after
using). Now this logic met a problem described in the above BZ because the
test tool and the CpuDxe both use the same memory at the same time.
In order to fix the above issue, CpuDxe changed to allocate the buffer below 1M
instead of borrow it. After investigation, we found below
0x88000 is the possible space which can be used. For now, range
0x6 ~ 0x88000 used for Legacy OPROMs by LegacyBios driver. And it tries to
allocate these range page(4K size) by page. It just reports warning message if
specific page been used by others already.
Also CpuDxe driver will produce CPU arch protocol and LegacyBios driver has
dependency for this protocol. So CpuDxe driver will start before LegacyBios
driver and CpuDxe driver can allocate that space successful.
With this change, CpuDxe driver will use 0x87000 ~ 0x88000 as wakeup buffer.
Cc: Ray Ni
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong
---
UefiCpuPkg/Library/MpInitLib/DxeMpLib.c | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
index b2307cbb61..5bc9a47efb 100644
--- a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
+++ b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
@@ -76,7 +76,7 @@ SaveCpuMpData (
}
/**
- Get available system memory below 1MB by specified size.
+ Get available system memory below 0x88000 by specified size.
@param[in] WakeupBufferSize Wakeup buffer size required
@@ -91,7 +91,19 @@ GetWakeupBuffer (
EFI_STATUS Status;
EFI_PHYSICAL_ADDRESSStartAddress;
- StartAddress = BASE_1MB;
+ //
+ // Current "Borrow" space mechanism caused potential race condition
+ if both // AP and the original owner use the share space.
+ //
+ // LegacyBios driver tries to allocate 4K pages between 0x6 ~
+ 0x88000 // space. It will just report an waring message if the page
+ has been allocate // by other drivers.
+ // LagacyBios driver depends on CPU Arch protocol, so it will start
+ after // CpuDxe driver which produce Cpu Arch Protocol and use this library.
+ // So below allocate logic will be trigged before LegacyBios driver
+ and it // will always return success.
+ //
+ StartAddress = BASE_512KB + BASE_32KB;
Status = gBS->AllocatePages (
AllocateMaxAddress,
EfiBootServicesData,
@@ -99,17 +111,13 @@ GetWakeupBuffer (
);
ASSERT_EFI_ERROR (Status);
- if (!EFI_ERROR (Status)) {
-Status = gBS->FreePages(
- StartAddress,
- EFI_SIZE_TO_PAGES (WakeupBufferSize)
- );
-ASSERT_EFI_ERROR (Status);
-DEBUG ((DEBUG_INFO, "WakeupBufferStart = %x, WakeupBufferSize = %x\n",
-(UINTN) StartAddress, WakeupBufferSize));
- } else {
+ if (EFI_ERROR (Status)) {
StartAddress = (EFI_PHYSICAL_ADDRESS) -1;
}
+
+ DEBUG ((DEBUG_INFO, "WakeupBufferStart = %x, WakeupBufferSize = %x\n",
+ (UINTN) StartAddress, WakeupBufferSize));
+
return (UINTN) StartAddress;
}
--
2.15.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-platforms 2/2] Platforms/ARM/SgiPkg: Rename SgiClarkHelios to RdE1Edge
Replace all usage of 'SgiClark' with 'RdN1E1Edge' and 'SgiClarkHelios
with 'RdE1Edge' as per the updated product names.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jagadeesh Ujja
---
Platform/ARM/SgiPkg/AcpiTables/{SgiClarkHelios => RdE1Edge}/Dsdt.asl
| 66 ++--
Platform/ARM/SgiPkg/AcpiTables/{SgiClarkHelios => RdE1Edge}/Madt.aslc
| 0
Platform/ARM/SgiPkg/AcpiTables/{SgiClarkHeliosAcpiTables.inf =>
RdE1EdgeAcpiTables.inf} | 6 +-
Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c
| 4 +-
Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf
| 2 +-
Platform/ARM/SgiPkg/Include/SgiPlatform.h
| 2 +-
Platform/ARM/SgiPkg/SgiPlatform.dec
| 2 +-
Platform/ARM/SgiPkg/SgiPlatform.dsc
| 2 +-
Platform/ARM/SgiPkg/SgiPlatform.fdf
| 2 +-
9 files changed, 43 insertions(+), 43 deletions(-)
diff --git a/Platform/ARM/SgiPkg/AcpiTables/SgiClarkHelios/Dsdt.asl
b/Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Dsdt.asl
similarity index 68%
rename from Platform/ARM/SgiPkg/AcpiTables/SgiClarkHelios/Dsdt.asl
rename to Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Dsdt.asl
index 7cfc419..c2f2dfb 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/SgiClarkHelios/Dsdt.asl
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Dsdt.asl
@@ -20,195 +20,195 @@ DefinitionBlock ("DsdtTable.aml", "DSDT", 1, "ARMLTD",
"ARMSGI",
EFI_ACPI_ARM_OEM_REVISION) {
Scope (_SB) {
//
-// HeliosCores 8X2 Processor declaration
+// Neoverse-E1 8X2 Processor declaration
//
-Device (CP00) { // HeliosCore: Cluster 0, Cpu 0, Thread 0
+Device (CP00) { // Neoverse-E1: Cluster 0, Cpu 0, Thread 0
Name (_HID, "ACPI0007")
Name (_UID, 0)
Name (_STA, 0xF)
}
-Device (CP01) { // HeliosCore: Cluster 0, Cpu 0, Thread 1
+Device (CP01) { // Neoverse-E1: Cluster 0, Cpu 0, Thread 1
Name (_HID, "ACPI0007")
Name (_UID, 1)
Name (_STA, 0xF)
}
-Device (CP02) { // HeliosCore: Cluster 0, Cpu 1, Thread 0
+Device (CP02) { // Neoverse-E1: Cluster 0, Cpu 1, Thread 0
Name (_HID, "ACPI0007")
Name (_UID, 2)
Name (_STA, 0xF)
}
-Device (CP03) { // HeliosCore: Cluster 0, Cpu 1, Thread 1
+Device (CP03) { // Neoverse-E1: Cluster 0, Cpu 1, Thread 1
Name (_HID, "ACPI0007")
Name (_UID, 3)
Name (_STA, 0xF)
}
-Device (CP04) { // HeliosCore: Cluster 0, Cpu 2, Thread 0
+Device (CP04) { // Neoverse-E1: Cluster 0, Cpu 2, Thread 0
Name (_HID, "ACPI0007")
Name (_UID, 4)
Name (_STA, 0xF)
}
-Device (CP05) { // HeliosCore: Cluster 0, Cpu 2, Thread 1
+Device (CP05) { // Neoverse-E1: Cluster 0, Cpu 2, Thread 1
Name (_HID, "ACPI0007")
Name (_UID, 5)
Name (_STA, 0xF)
}
-Device (CP06) { // HeliosCore: Cluster 0, Cpu 3, Thread 0
+Device (CP06) { // Neoverse-E1: Cluster 0, Cpu 3, Thread 0
Name (_HID, "ACPI0007")
Name (_UID, 6)
Name (_STA, 0xF)
}
-Device (CP07) { // HeliosCore: Cluster 0, Cpu 3, Thread 1
+Device (CP07) { // Neoverse-E1: Cluster 0, Cpu 3, Thread 1
Name (_HID, "ACPI0007")
Name (_UID, 7)
Name (_STA, 0xF)
}
-Device (CP08) { // HeliosCore: Cluster 0, Cpu 4, Thread 0
+Device (CP08) { // Neoverse-E1: Cluster 0, Cpu 4, Thread 0
Name (_HID, "ACPI0007")
Name (_UID, 8)
Name (_STA, 0xF)
}
-Device (CP09) { // HeliosCore: Cluster 0, Cpu 4, Thread 1
+Device (CP09) { // Neoverse-E1: Cluster 0, Cpu 4, Thread 1
Name (_HID, "ACPI0007")
Name (_UID, 9)
Name (_STA, 0xF)
}
-Device (CP10) { // HeliosCore: Cluster 0, Cpu 5, Thread 0
+Device (CP10) { // Neoverse-E1: Cluster 0, Cpu 5, Thread 0
Name (_HID, "ACPI0007")
Name (_UID, 10)
Name (_STA, 0xF)
}
-Device (CP11) { // HeliosCore: Cluster 0, Cpu 5, Thread 1
+Device (CP11) { // Neoverse-E1: Cluster 0, Cpu 5, Thread 1
Name (_HID, "ACPI0007")
Name (_UID, 11)
Name (_STA, 0xF)
}
-Device (CP12) { // HeliosCore: Cluster 0, Cpu 6, Thread 0
+Device (CP12) { // Neoverse-E1: Cluster 0, Cpu 6, Thread 0
Name (_HID, "ACPI0007")
Name (_UID, 12)
Name (_STA, 0xF)
}
-Device (CP13) { // HeliosCore: Cluster 0, Cpu 6, Thread 1
+Device (CP13) { // Neoverse-E1: Cluster 0, Cpu 6, Thread 1
Name (_HID, "ACPI0007")
Name (_UID, 13)
Name (_STA, 0xF)
}
-Device (CP14) { // HeliosCore: Cluster 0, Cpu 7, Thread 0
+Device (CP14) { // Neoverse-E1: Cluster 0, Cpu 7, Thread 0
Name (_HID, "ACPI0007")
Name (_UID,
[edk2] [PATCH edk2-platforms 1/2] Platforms/ARM/SgiPkg: Rename SgiClarkAres to RdN1Edge
Replace all usage of 'SgiClark' with 'RdN1E1Edge' and 'SgiClarkAres'
with 'RdN1Edge' as per the updated product names.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jagadeesh Ujja
---
Platform/ARM/SgiPkg/AcpiTables/{SgiClarkAres => RdN1Edge}/Dsdt.asl
| 16
Platform/ARM/SgiPkg/AcpiTables/{SgiClarkAres => RdN1Edge}/Madt.aslc
| 16
Platform/ARM/SgiPkg/AcpiTables/{SgiClarkAresAcpiTables.inf =>
RdN1EdgeAcpiTables.inf} | 6 +++---
Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c
| 8
Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf
| 2 +-
Platform/ARM/SgiPkg/Include/SgiPlatform.h
| 6 +++---
Platform/ARM/SgiPkg/SgiPlatform.dec
| 2 +-
Platform/ARM/SgiPkg/SgiPlatform.dsc
| 2 +-
Platform/ARM/SgiPkg/SgiPlatform.fdf
| 2 +-
9 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/Platform/ARM/SgiPkg/AcpiTables/SgiClarkAres/Dsdt.asl
b/Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Dsdt.asl
similarity index 85%
rename from Platform/ARM/SgiPkg/AcpiTables/SgiClarkAres/Dsdt.asl
rename to Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Dsdt.asl
index 69dc33c..9226229 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/SgiClarkAres/Dsdt.asl
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Dsdt.asl
@@ -20,49 +20,49 @@ DefinitionBlock ("DsdtTable.aml", "DSDT", 1, "ARMLTD",
"ARMSGI",
EFI_ACPI_ARM_OEM_REVISION) {
Scope (_SB) {
-Device (CP00) { // Ares: Cluster 0, Cpu 0
+Device (CP00) { // Neoverse-N1: Cluster 0, Cpu 0
Name (_HID, "ACPI0007")
Name (_UID, 0)
Name (_STA, 0xF)
}
-Device (CP01) { // Ares: Cluster 0, Cpu 1
+Device (CP01) { // Neoverse-N1: Cluster 0, Cpu 1
Name (_HID, "ACPI0007")
Name (_UID, 1)
Name (_STA, 0xF)
}
-Device (CP02) { // Ares: Cluster 0, Cpu 2
+Device (CP02) { // Neoverse-N1: Cluster 0, Cpu 2
Name (_HID, "ACPI0007")
Name (_UID, 2)
Name (_STA, 0xF)
}
-Device (CP03) { // Ares: Cluster 0, Cpu 3
+Device (CP03) { // Neoverse-N1: Cluster 0, Cpu 3
Name (_HID, "ACPI0007")
Name (_UID, 3)
Name (_STA, 0xF)
}
-Device (CP04) { // Ares: Cluster 1, Cpu 0
+Device (CP04) { // Neoverse-N1: Cluster 1, Cpu 0
Name (_HID, "ACPI0007")
Name (_UID, 4)
Name (_STA, 0xF)
}
-Device (CP05) { // Ares: Cluster 1, Cpu 1
+Device (CP05) { // Neoverse-N1: Cluster 1, Cpu 1
Name (_HID, "ACPI0007")
Name (_UID, 5)
Name (_STA, 0xF)
}
-Device (CP06) { // Ares: Cluster 1, Cpu 2
+Device (CP06) { // Neoverse-N1: Cluster 1, Cpu 2
Name (_HID, "ACPI0007")
Name (_UID, 6)
Name (_STA, 0xF)
}
-Device (CP07) { // Ares: Cluster 1, Cpu 3
+Device (CP07) { // Neoverse-N1: Cluster 1, Cpu 3
Name (_HID, "ACPI0007")
Name (_UID, 7)
Name (_STA, 0xF)
diff --git a/Platform/ARM/SgiPkg/AcpiTables/SgiClarkAres/Madt.aslc
b/Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Madt.aslc
similarity index 93%
rename from Platform/ARM/SgiPkg/AcpiTables/SgiClarkAres/Madt.aslc
rename to Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Madt.aslc
index f60b62d..d29eda5 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/SgiClarkAres/Madt.aslc
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Madt.aslc
@@ -120,36 +120,36 @@ STATIC EFI_ACPI_6_2_MULTIPLE_APIC_DESCRIPTION_TABLE Madt
= {
// Efficiency)
// Note: The GIC Structure of the primary CPU must be the first entry
// (see note in 5.2.12.14 GICC Structure of ACPI v6.2).
-EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Ares-0
+EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Neoverse-N1-0
0, 0, GET_MPID(0x0, 0x0), EFI_ACPI_6_2_GIC_ENABLED, 23,
FixedPcdGet32 (PcdGicDistributorBase),
0x2c02, 0x2c01, 25, 0 /* GicRBase */, 0 /* Efficiency */),
-EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Ares-1
+EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Neoverse-N1-1
0, 1, GET_MPID(0x0, 0x100), EFI_ACPI_6_2_GIC_ENABLED, 23,
FixedPcdGet32 (PcdGicDistributorBase),
0x2c02, 0x2c01, 25, 0 /* GicRBase */, 0 /* Efficiency */),
-EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Ares-2
+EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Neoverse-N1-2
0, 2, GET_MPID(0x0, 0x200), EFI_ACPI_6_2_GIC_ENABLED, 23,
FixedPcdGet32 (PcdGicDistributorBase),
0x2c02, 0x2c01, 25, 0 /* GicRBase */, 0 /* Efficiency */),
-EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Ares-3
+EFI_ACPI_6_2_GICC_STRUCTURE_INIT( // Neoverse-N1-3
0, 3, GET_MPID(0x0, 0x300), EFI_ACPI_6_2_GIC_ENABLED, 23,
FixedPcdGet32 (PcdGicDistributorBase),
[edk2] [PATCH edk2-platforms 0/2] Platforms/ARM/SgiPkg: apply product names for sgiclarka and sgiclarkh platforms
This patchset updates the product names for SGI-Clark.Ares and
SGI-Clark.Helios platforms.
The first patch replaces all uses of sgiclarka with rdn1edge.
The second patch replaces all use of sgiclarkh with rde1edge.
Jagadeesh Ujja (2):
Platforms/ARM/SgiPkg: Rename SgiClarkAres to RdN1Edge
Platforms/ARM/SgiPkg: Rename SgiClarkHelios to RdE1Edge
Platform/ARM/SgiPkg/AcpiTables/{SgiClarkHelios => RdE1Edge}/Dsdt.asl
| 66 ++--
Platform/ARM/SgiPkg/AcpiTables/{SgiClarkHelios => RdE1Edge}/Madt.aslc
| 0
Platform/ARM/SgiPkg/AcpiTables/{SgiClarkHeliosAcpiTables.inf =>
RdE1EdgeAcpiTables.inf} | 6 +-
Platform/ARM/SgiPkg/AcpiTables/{SgiClarkAres => RdN1Edge}/Dsdt.asl
| 16 ++---
Platform/ARM/SgiPkg/AcpiTables/{SgiClarkAres => RdN1Edge}/Madt.aslc
| 16 ++---
Platform/ARM/SgiPkg/AcpiTables/{SgiClarkAresAcpiTables.inf =>
RdN1EdgeAcpiTables.inf} | 6 +-
Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c
| 12 ++--
Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf
| 4 +-
Platform/ARM/SgiPkg/Include/SgiPlatform.h
| 8 +--
Platform/ARM/SgiPkg/SgiPlatform.dec
| 4 +-
Platform/ARM/SgiPkg/SgiPlatform.dsc
| 4 +-
Platform/ARM/SgiPkg/SgiPlatform.fdf
| 4 +-
12 files changed, 73 insertions(+), 73 deletions(-)
rename Platform/ARM/SgiPkg/AcpiTables/{SgiClarkHelios => RdE1Edge}/Dsdt.asl
(68%)
rename Platform/ARM/SgiPkg/AcpiTables/{SgiClarkHelios => RdE1Edge}/Madt.aslc
(100%)
rename Platform/ARM/SgiPkg/AcpiTables/{SgiClarkHeliosAcpiTables.inf =>
RdE1EdgeAcpiTables.inf} (91%)
rename Platform/ARM/SgiPkg/AcpiTables/{SgiClarkAres => RdN1Edge}/Dsdt.asl (85%)
rename Platform/ARM/SgiPkg/AcpiTables/{SgiClarkAres => RdN1Edge}/Madt.aslc
(93%)
rename Platform/ARM/SgiPkg/AcpiTables/{SgiClarkAresAcpiTables.inf =>
RdN1EdgeAcpiTables.inf} (92%)
--
2.7.4
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch] Document: Update Build spec to remove EDK related contents
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1453 Remove EDK related contents from Build spec. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Bob Feng Cc: Liming Gao Cc: Jaben Carsey --- .../103_build_intermediate_images.md | 3 +- 12_build_changes_and_customizations/README.md | 4 +- .../42_build_process_overview.md | 6 +- .../46_file_specifications.md | 20 + 6_quick_start/61_environment_variables.md | 24 +- .../82_auto-generation_process.md | 76 +++ .../83_auto-generated_code.md | 43 +++ .../85_auto-generated_makefiles.md| 23 +++--- 9_build_or_make_stage/README.md | 9 +-- appendix_a_variables.md | 3 +- 10 files changed, 43 insertions(+), 168 deletions(-) diff --git a/10_post-build_imagegen_stage_-_flash/103_build_intermediate_images.md b/10_post-build_imagegen_stage_-_flash/103_build_intermediate_images.md index 5f5aefc..9253cde 100644 --- a/10_post-build_imagegen_stage_-_flash/103_build_intermediate_images.md +++ b/10_post-build_imagegen_stage_-_flash/103_build_intermediate_images.md @@ -1,9 +1,9 @@ # 12 Build Changes and Customizations This chapter deals with customizing a build, including options and settings for -debugging, using custom tools as well as how to customize EDK component builds +debugging, using custom tools. diff --git a/4_edk_ii_build_process_overview/42_build_process_overview.md b/4_edk_ii_build_process_overview/42_build_process_overview.md index d0725d3..17ed278 100644 --- a/4_edk_ii_build_process_overview/42_build_process_overview.md +++ b/4_edk_ii_build_process_overview/42_build_process_overview.md @@ -1,9 +1,9 @@ ## 4.2 Build Process Overview Prior to executing a build command, specific system environment variables must -be initialized: `WORKSPACE`, `EDK_TOOLS_PATH` are required for all builds, -while `ECP_SOURCE`, `EFI_SOURCE` and `EDK_SOURCE` are only required to build -EDK II platforms that contain EDK components and EDK libraries. Additionally, +be initialized: `WORKSPACE`, `EDK_TOOLS_PATH` are required for all builds. Additionally, the provided EDK II tool set must be present in a directory that is in the system environment variable: PATH. The edksetup scripts provided in the root directory of the EDK II development tree will set the `WORKSPACE` and `EDK_TOOLS_PATH`, as well as modify the system environment variable, PATH to ensure that the tools can execute. Refer to "_Build Environment_" for more diff --git a/4_edk_ii_build_process_overview/46_file_specifications.md b/4_edk_ii_build_process_overview/46_file_specifications.md index a606488..f30f806 100644 --- a/4_edk_ii_build_process_overview/46_file_specifications.md +++ b/4_edk_ii_build_process_overview/46_file_specifications.md @@ -1,9 +1,9 @@
[edk2] [Patch] Document: Update DSC spec to remove EDK related contents
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1453
Remove EDK related contents inf Dsc spec.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng
Cc: Liming Gao
Cc: Jaben Carsey
---
1_introduction/11_overview.md | 14 +--
...=> 210_[components]_section_processing.md} | 27 +-
...ion.md => 211_[userextensions]_section.md} | 4 +-
...212_[defaultstores]_section_processing.md} | 4 +-
.../22_build_description_file_format.md | 50 ++
.../23_[defines]_section_processing.md| 12 +--
2_dsc_overview/24_[buildoptions]_section.md | 72 ++
.../26_[libraries]_section_processing.md | 69 --
...26_[libraryclasses]_section_processing.md} | 4 +-
...essing.md => 27_pcd_section_processing.md} | 34 +++
...{29_pcd_sections.md => 28_pcd_sections.md} | 26 ++---
...210_pcd_database.md => 29_pcd_database.md} | 4 +-
...ctions.md => 310_[components]_sections.md} | 62 +---
...ns.md => 311_[userextensions]_sections.md} | 4 +-
...tion.md => 312_[defaultstores]_section.md} | 4 +-
3_edk_ii_dsc_file_format/32_general_rules.md | 13 +--
.../33_platform_dsc_definition.md | 17 +---
.../35_[defines]_section.md | 12 +--
.../36_[buildoptions]_sections.md | 19 ++--
.../38_[libraries]_sections.md| 94 ---
...ons.md => 38_[libraryclasses]_sections.md} | 4 +-
...310_pcd_sections.md => 39_pcd_sections.md} | 14 +--
22 files changed, 101 insertions(+), 462 deletions(-)
rename 2_dsc_overview/{211_[components]_section_processing.md =>
210_[components]_section_processing.md} (84%)
rename 2_dsc_overview/{212_[userextensions]_section.md =>
211_[userextensions]_section.md} (93%)
rename 2_dsc_overview/{213_[defaultstores]_section_processing.md =>
212_[defaultstores]_section_processing.md} (93%)
delete mode 100644 2_dsc_overview/26_[libraries]_section_processing.md
rename 2_dsc_overview/{27_[libraryclasses]_section_processing.md =>
26_[libraryclasses]_section_processing.md} (96%)
rename 2_dsc_overview/{28_pcd_section_processing.md =>
27_pcd_section_processing.md} (94%)
rename 2_dsc_overview/{29_pcd_sections.md => 28_pcd_sections.md} (93%)
rename 2_dsc_overview/{210_pcd_database.md => 29_pcd_database.md} (96%)
rename 3_edk_ii_dsc_file_format/{311_[components]_sections.md =>
310_[components]_sections.md} (81%)
rename 3_edk_ii_dsc_file_format/{312_[userextensions]_sections.md =>
311_[userextensions]_sections.md} (94%)
rename 3_edk_ii_dsc_file_format/{313_[defaultstores]_section.md =>
312_[defaultstores]_section.md} (93%)
delete mode 100644 3_edk_ii_dsc_file_format/38_[libraries]_sections.md
rename 3_edk_ii_dsc_file_format/{39_[libraryclasses]_sections.md =>
38_[libraryclasses]_sections.md} (95%)
rename 3_edk_ii_dsc_file_format/{310_pcd_sections.md => 39_pcd_sections.md}
(97%)
diff --git a/1_introduction/11_overview.md b/1_introduction/11_overview.md
index d9006df..ff2b517 100644
--- a/1_introduction/11_overview.md
+++ b/1_introduction/11_overview.md
@@ -1,9 +1,9 @@
-## 2.11 [Components] Section Processing
+## 2.10 [Components] Section Processing
-One or more `[Components]` sections contain lists of EDK components and EDK II
-Modules. The format for specifying the INF file for EDK II modules incorporates
-new scoping capabilities.
+One or more `[Components]` sections contain lists of EDK II Modules. The
format
+for specifying the INF file for EDK II modules incorporates new scoping
capabilities.
This section uses one or more of the following section definitions:
* `[Components]`
* `[Components.IA32]`
* `[Components.X64]`
* `[Components.EBC]`
* `[Components.common]`
-EDK components are specified using a fully qualified path to the EDK INF file.
-
-`$(EDK_SOURCE)/Path/and/Filename.inf`
-
-Because EDK II modules have different requirements than EDK I components,
-specifying the INF filename in the extended DSC file may require more than just
-the INF filename and options. A scoping structure, that binds library class
+A scoping structure, that binds library class
(with an optional override instance,) PCD settings (also overriding the values
specified in the `[PcdsPatchableInModule]` or `[PcdsFixedAtBuild]` sections)
and build options for an EDK II module may be required. This scoping structure,
containing sub-elements, is enclosed within curly braces: "{}". The opening
curly brace, "{", must appear at the end of the inf filename line, before any
@@ -79,20 +72,10 @@ Path/and/Filename.inf {
There are four valid, optional sub-elements for EDK II modules. These
sub-element are enclosed within angle brackets: `, `,
`` and ``.
-For EDK component INF files, an optional sub-element of
-`` has been defined. If this element is specified, files
-listed in the directory are used instead of the "same-named" files in the
-component's directory. If an EDK component directory lists files, A.c, B.c and
-C.h,
Re: [edk2] [PATCH] EmulatorPkg/Sec: Don't install TemporaryRamSupport PPI
> -Original Message- > From: edk2-devel On Behalf Of Jordan > Justen > Sent: Sunday, March 3, 2019 5:45 AM > To: Ni, Ray ; edk2-devel@lists.01.org > Subject: Re: [edk2] [PATCH] EmulatorPkg/Sec: Don't install > TemporaryRamSupport PPI > > On 2019-03-02 04:11:11, Ray Ni wrote: > > > > So this patch removes TemporaryRamSupport PPI implementation from > > EmulatorPkg/Sec module to fix the boot failure when using GCC5. > > I don't think we should just hide the known bug with the > TemporaryRamSupport PPI implementation in the PEI Core. > > I would agree that we should make this change after addressing that. Jordan, I have a goal to replace Nt32 with EmulatorPkg before Q2 stable tag release. I understand we need more discussions on how to fix the PeiCore bug. So I don't want this blocks the Nt32 deletion. And in my opinion, the TemporaryRamSupport PPI that requires being called from assembly code is a design bug. I suggest to change the PI spec instead of changing PeiCore by introducing more assembly code to hide this design bug. Thanks, Ray ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH V2] BaseTools:Run packagedoc_cli.py to generate doc failed
This is a bug. I agree to fix it for Q1 stable tag.
> -Original Message-
> From: Feng, Bob C
> Sent: Monday, March 4, 2019 5:02 PM
> To: Gao, Liming ; Fan, ZhijuX ;
> edk2-devel@lists.01.org
> Cc: Feng, Bob C
> Subject: RE: [edk2] [PATCH V2] BaseTools:Run packagedoc_cli.py to generate
> doc failed
>
> Hi,
>
> This patch is to fix the a regression issue introduced by python3 patch set.
> I'd like to push this patch for Q1 stable tag.
> Would you approve it?
>
> Thanks,
> Bob
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Feng,
> Bob C
> Sent: Monday, March 4, 2019 3:30 PM
> To: Fan, ZhijuX ; edk2-devel@lists.01.org
> Cc: Gao, Liming
> Subject: Re: [edk2] [PATCH V2] BaseTools:Run packagedoc_cli.py to generate
> doc failed
>
> Reviewed-by: Bob Feng
>
>
> -Original Message-
> From: Fan, ZhijuX
> Sent: Friday, March 1, 2019 10:52 AM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming ; Feng, Bob C
> Subject: [edk2][PATCH V2] BaseTools:Run packagedoc_cli.py to generate doc
> failed
>
> The reason for this problem is that the file was opened incorrectly.
>
> Cc: Bob Feng
> Cc: Liming Gao
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhiju.Fan
> ---
> .../plugins/EdkPlugins/edk2/model/doxygengen.py| 7
> ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git
> a/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/doxygengen.py
> b/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/doxygengen.py
> index e31df262bc..73349e2f48 100644
> ---
> a/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/doxygengen.py
> +++
> b/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/doxygengen.py
> @@ -376,9 +376,10 @@ class PackageDocumentAction(DoxygenAction):
> return
>
> try:
> -f = open(path, 'r')
> -lines = f.readlines()
> -f.close()
> +with open(path, 'r') as f:
> +lines = f.readlines()
> +except UnicodeDecodeError:
> +return
> except IOError:
> ErrorMsg('Fail to open file %s' % path)
> return
> --
> 2.14.1.windows.1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 0/1] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems
> -Original Message- > From: Wu, Hao A > Sent: Tuesday, March 05, 2019 9:14 AM > To: edk2-devel@lists.01.org > Cc: Wu, Hao A; Eugene Cohen; Ard Biesheuvel; Ashish Singhal > Subject: [PATCH v2 0/1] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC > v3 64-bit systems Since Ashish already posted a patch to add the 64-bit System Address support for V3 mode SDHC: https://www.mail-archive.com/edk2-devel@lists.01.org/msg52057.html I think this patch can be dropped. But since Ashish's patch above is considered as a new feature addition, it will be pushed (if passes the review process) after the 19`Q1 release tag. So Eugene, Ard and Ashish, do you have concern on this? Best Regards, Hao Wu > > V2 changes: > > On behalf of Eugene, V2 patch does not have functional changes compared > with V1, only the reference Bugzilla tracker link is added in the commit > log message. > > I added the previous 'Ack' tag from Ard and Ashish, I added my > 'Reviewed-by' as well. > > Cc: Eugene Cohen > Cc: Ard Biesheuvel > Cc: Ashish Singhal > > Cohen, Eugene (1): > MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems > > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > -- > 2.12.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 0/3] MdePkg: Remove inline X86 assembly code
Shenglei: The request is for X86, IA32 and X64. Please don't change ARM or AARCH64. Thanks Liming > -Original Message- > From: Zhang, Shenglei > Sent: Monday, March 4, 2019 5:41 PM > To: edk2-devel@lists.01.org > Cc: Kinney, Michael D ; Gao, Liming > > Subject: [PATCH 0/3] MdePkg: Remove inline X86 assembly code > > MdePkg BaseLib, BaseCpuLib and BaseSynchronizationLib still use > the inline X86 assembly code in C code files. They should be updated > to consume nasm only. > https://bugzilla.tianocore.org/show_bug.cgi?id=1163 > > Cc: Michael D Kinney > Cc: Liming Gao > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Shenglei Zhang > Shenglei Zhang (3): > MdePkg/BaseCpuLib: Remove inline X86 assembly code > MdePkg/BaseLib: Remove inline X86 assembly code > MdePkg/BaseSynchronizationLib: Remove inline X86 assembly code > > MdePkg/Library/BaseCpuLib/BaseCpuLib.inf | 6 - > MdePkg/Library/BaseLib/BaseLib.inf| 27 --- > .../BaseSynchronizationLib.inf| 2 -- > 3 files changed, 35 deletions(-) > > -- > 2.18.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch] UefiCpuPkg/MpInitLib: Direct allocate buffer for Wake up Buffer.
https://bugzilla.tianocore.org/show_bug.cgi?id=1538
Current CpuDxe driver "borrows" Wakeup Buffer (through Allocate & free
to get the buffer pointer, backup the buffer data before using it and
restore it after using). Now this logic met a problem described in
the above BZ because the test tool and the CpuDxe both use the same
memory at the same time.
In order to fix the above issue, CpuDxe changed to allocate the buffer
below 1M instead of borrow it. After investigation, we found below
0x88000 is the possible space which can be used. For now, range
0x6 ~ 0x88000 used for Legacy OPROMs by LegacyBios driver. And it
tries to allocate these range page(4K size) by page. It just reports
warning message if specific page been used by others already.
Also CpuDxe driver will produce CPU arch protocol and LegacyBios driver
has dependency for this protocol. So CpuDxe driver will start before
LegacyBios driver and CpuDxe driver can allocate that space successful.
With this change, CpuDxe driver will use 0x87000 ~ 0x88000 as wakeup
buffer.
Cc: Ray Ni
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong
---
UefiCpuPkg/Library/MpInitLib/DxeMpLib.c | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
index b2307cbb61..5bc9a47efb 100644
--- a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
+++ b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
@@ -76,7 +76,7 @@ SaveCpuMpData (
}
/**
- Get available system memory below 1MB by specified size.
+ Get available system memory below 0x88000 by specified size.
@param[in] WakeupBufferSize Wakeup buffer size required
@@ -91,7 +91,19 @@ GetWakeupBuffer (
EFI_STATUS Status;
EFI_PHYSICAL_ADDRESSStartAddress;
- StartAddress = BASE_1MB;
+ //
+ // Current "Borrow" space mechanism caused potential race condition if both
+ // AP and the original owner use the share space.
+ //
+ // LegacyBios driver tries to allocate 4K pages between 0x6 ~ 0x88000
+ // space. It will just report an waring message if the page has been allocate
+ // by other drivers.
+ // LagacyBios driver depends on CPU Arch protocol, so it will start after
+ // CpuDxe driver which produce Cpu Arch Protocol and use this library.
+ // So below allocate logic will be trigged before LegacyBios driver and it
+ // will always return success.
+ //
+ StartAddress = BASE_512KB + BASE_32KB;
Status = gBS->AllocatePages (
AllocateMaxAddress,
EfiBootServicesData,
@@ -99,17 +111,13 @@ GetWakeupBuffer (
);
ASSERT_EFI_ERROR (Status);
- if (!EFI_ERROR (Status)) {
-Status = gBS->FreePages(
- StartAddress,
- EFI_SIZE_TO_PAGES (WakeupBufferSize)
- );
-ASSERT_EFI_ERROR (Status);
-DEBUG ((DEBUG_INFO, "WakeupBufferStart = %x, WakeupBufferSize = %x\n",
-(UINTN) StartAddress, WakeupBufferSize));
- } else {
+ if (EFI_ERROR (Status)) {
StartAddress = (EFI_PHYSICAL_ADDRESS) -1;
}
+
+ DEBUG ((DEBUG_INFO, "WakeupBufferStart = %x, WakeupBufferSize = %x\n",
+ (UINTN) StartAddress, WakeupBufferSize));
+
return (UINTN) StartAddress;
}
--
2.15.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch] MdeModulePkg/PiSmmCore: Control S3 related functionality with flag.
https://bugzilla.tianocore.org/show_bug.cgi?id=1590
Use PcdAcpiS3Enable to control whether need to enable S3 related functionality
in Pi SMM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong
---
MdeModulePkg/Core/PiSmmCore/PiSmmCore.c | 70 ++-
MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf | 1 +
2 files changed, 51 insertions(+), 20 deletions(-)
diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
index d0bc65b564..bd19803c37 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
@@ -77,6 +77,12 @@ BOOLEAN mInLegacyBoot = FALSE;
//
BOOLEAN mDuringS3Resume = FALSE;
+//
+// Flag to determine if platform enabled S3.
+// Get the value from PcdAcpiS3Enable.
+//
+BOOLEAN mAcpiS3Enable = FALSE;
+
//
// Table of SMI Handlers that are registered by the SMM Core when it is
initialized
//
@@ -87,6 +93,13 @@ SMM_CORE_SMI_HANDLERS mSmmCoreSmiHandlers[] = {
{ SmmExitBootServicesHandler, , NULL,
FALSE },
{ SmmReadyToBootHandler, , NULL,
FALSE },
{ SmmEndOfDxeHandler, , NULL,
TRUE },
+ { NULL, NULL,NULL,
FALSE }
+};
+
+//
+// Table of SMI Handlers that are registered by the SMM Core when it is
initialized
+//
+SMM_CORE_SMI_HANDLERS mSmmCoreS3SmiHandlers[] = {
{ SmmS3SmmInitDoneHandler,,NULL,
FALSE },
{ SmmEndOfS3ResumeHandler,,NULL,
FALSE },
{ NULL, NULL,NULL,
FALSE }
@@ -445,28 +458,30 @@ SmmEndOfDxeHandler (
NULL
);
- //
- // Locate SmmSxDispatch2 protocol.
- //
- Status = SmmLocateProtocol (
- ,
- NULL,
- (VOID **)
- );
- if (!EFI_ERROR (Status) && (SxDispatch != NULL)) {
+ if (mAcpiS3Enable) {
//
-// Register a S3 entry callback function to
-// determine if it will be during S3 resume.
+// Locate SmmSxDispatch2 protocol.
//
-EntryRegisterContext.Type = SxS3;
-EntryRegisterContext.Phase = SxEntry;
-Status = SxDispatch->Register (
- SxDispatch,
- SmmS3EntryCallBack,
- ,
-
- );
-ASSERT_EFI_ERROR (Status);
+Status = SmmLocateProtocol (
+ ,
+ NULL,
+ (VOID **)
+ );
+if (!EFI_ERROR (Status) && (SxDispatch != NULL)) {
+ //
+ // Register a S3 entry callback function to
+ // determine if it will be during S3 resume.
+ //
+ EntryRegisterContext.Type = SxS3;
+ EntryRegisterContext.Phase = SxEntry;
+ Status = SxDispatch->Register (
+ SxDispatch,
+ SmmS3EntryCallBack,
+ ,
+
+ );
+ ASSERT_EFI_ERROR (Status);
+}
}
return EFI_SUCCESS;
@@ -883,6 +898,21 @@ SmmMain (
ASSERT_EFI_ERROR (Status);
}
+ mAcpiS3Enable = PcdGetBool (PcdAcpiS3Enable);
+ if (mAcpiS3Enable) {
+//
+// Register all S3 related SMI Handlers required by the SMM Core
+//
+for (Index = 0; mSmmCoreS3SmiHandlers[Index].HandlerType != NULL; Index++)
{
+ Status = SmiHandlerRegister (
+ mSmmCoreS3SmiHandlers[Index].Handler,
+ mSmmCoreS3SmiHandlers[Index].HandlerType,
+ [Index].DispatchHandle
+ );
+ ASSERT_EFI_ERROR (Status);
+}
+ }
+
RegisterSmramProfileHandler ();
SmramProfileInstallProtocol ();
diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
index f3ece22121..9a31cb79d6 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
@@ -101,6 +101,7 @@
gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPageType ##
CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPoolType ##
CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask ##
CONSUMES
+ gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiS3Enable##
CONSUMES
[Guids]
gAprioriGuid ## SOMETIMES_CONSUMES ## File
--
2.15.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH] ShellPkg: Correct a parameter's name
The parameter FilePath of ShellOpenFileByName defined in ShellLib.h is incorrect. It should be FileName. https://bugzilla.tianocore.org/show_bug.cgi?id=1221 Cc: Jaben Carsey Cc: Ruiyu Ni Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Shenglei Zhang --- ShellPkg/Include/Library/ShellLib.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ShellPkg/Include/Library/ShellLib.h b/ShellPkg/Include/Library/ShellLib.h index 2ecc5ee006..78bdcc8c53 100644 --- a/ShellPkg/Include/Library/ShellLib.h +++ b/ShellPkg/Include/Library/ShellLib.h @@ -161,7 +161,7 @@ ShellOpenFileByDevicePath( otherwise, the Filehandle is NULL. Attributes is valid only for EFI_FILE_MODE_CREATE. - @param[in] FilePath The pointer to file name. + @param[in] FileName The pointer to file name. @param[out] FileHandleThe pointer to the file handle. @param[in] OpenMode The mode to open the file with. @param[in] Attributes The file's file attributes. @@ -186,7 +186,7 @@ ShellOpenFileByDevicePath( EFI_STATUS EFIAPI ShellOpenFileByName( - IN CONST CHAR16 *FilePath, + IN CONST CHAR16 *FileName, OUT SHELL_FILE_HANDLE *FileHandle, IN UINT64 OpenMode, IN UINT64 Attributes -- 2.18.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 0/3] MdePkg: Remove inline X86 assembly code
MdePkg BaseLib, BaseCpuLib and BaseSynchronizationLib still use the inline X86 assembly code in C code files. They should be updated to consume nasm only. https://bugzilla.tianocore.org/show_bug.cgi?id=1163 Cc: Michael D Kinney Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Shenglei Zhang Shenglei Zhang (3): MdePkg/BaseCpuLib: Remove inline X86 assembly code MdePkg/BaseLib: Remove inline X86 assembly code MdePkg/BaseSynchronizationLib: Remove inline X86 assembly code MdePkg/Library/BaseCpuLib/BaseCpuLib.inf | 6 - MdePkg/Library/BaseLib/BaseLib.inf| 27 --- .../BaseSynchronizationLib.inf| 2 -- 3 files changed, 35 deletions(-) -- 2.18.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 1/3] MdePkg/BaseCpuLib: Remove inline X86 assembly code
MdePkg BaseCpuLib still uses the inline X86 assembly code in C code files.It should be updated to consume nasm only. https://bugzilla.tianocore.org/show_bug.cgi?id=1163 Cc: Michael D Kinney Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Shenglei Zhang --- MdePkg/Library/BaseCpuLib/BaseCpuLib.inf | 6 -- 1 file changed, 6 deletions(-) diff --git a/MdePkg/Library/BaseCpuLib/BaseCpuLib.inf b/MdePkg/Library/BaseCpuLib/BaseCpuLib.inf index af2f09617a..bc6585d8dd 100644 --- a/MdePkg/Library/BaseCpuLib/BaseCpuLib.inf +++ b/MdePkg/Library/BaseCpuLib/BaseCpuLib.inf @@ -55,18 +55,12 @@ Ebc/CpuSleepFlushTlb.c [Sources.ARM] - Arm/CpuFlushTlb.asm | RVCT - Arm/CpuSleep.asm| RVCT - Arm/CpuFlushTlb.asm | MSFT - Arm/CpuSleep.asm| MSFT Arm/CpuFlushTlb.S | GCC Arm/CpuSleep.S | GCC [Sources.AARCH64] AArch64/CpuFlushTlb.S | GCC AArch64/CpuSleep.S | GCC - AArch64/CpuFlushTlb.asm | MSFT - AArch64/CpuSleep.asm| MSFT [Packages] MdePkg/MdePkg.dec -- 2.18.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 2/3] MdePkg/BaseLib: Remove inline X86 assembly code
MdePkg BaseLib still uses the inline X86 assembly code in C code files.It should be updated to consume nasm only. https://bugzilla.tianocore.org/show_bug.cgi?id=1163 Cc: Michael D Kinney Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Shenglei Zhang --- MdePkg/Library/BaseLib/BaseLib.inf | 27 --- 1 file changed, 27 deletions(-) diff --git a/MdePkg/Library/BaseLib/BaseLib.inf b/MdePkg/Library/BaseLib/BaseLib.inf index a0d6c372f9..80e312fb34 100644 --- a/MdePkg/Library/BaseLib/BaseLib.inf +++ b/MdePkg/Library/BaseLib/BaseLib.inf @@ -555,26 +555,8 @@ Math64.c | RVCT Math64.c | MSFT - Arm/SwitchStack.asm| RVCT - Arm/SetJumpLongJump.asm| RVCT - Arm/DisableInterrupts.asm | RVCT - Arm/EnableInterrupts.asm | RVCT - Arm/GetInterruptsState.asm | RVCT - Arm/CpuPause.asm | RVCT - Arm/CpuBreakpoint.asm | RVCT - Arm/MemoryFence.asm| RVCT Arm/SpeculationBarrier.S | RVCT - Arm/SwitchStack.asm| MSFT - Arm/SetJumpLongJump.asm| MSFT - Arm/DisableInterrupts.asm | MSFT - Arm/EnableInterrupts.asm | MSFT - Arm/GetInterruptsState.asm | MSFT - Arm/CpuPause.asm | MSFT - Arm/CpuBreakpoint.asm | MSFT - Arm/MemoryFence.asm| MSFT - Arm/SpeculationBarrier.asm | MSFT - Arm/Math64.S | GCC Arm/SwitchStack.S | GCC Arm/EnableInterrupts.S| GCC @@ -599,15 +581,6 @@ AArch64/CpuBreakpoint.S | GCC AArch64/SpeculationBarrier.S | GCC - AArch64/MemoryFence.asm | MSFT - AArch64/SwitchStack.asm | MSFT - AArch64/EnableInterrupts.asm | MSFT - AArch64/DisableInterrupts.asm | MSFT - AArch64/GetInterruptsState.asm| MSFT - AArch64/SetJumpLongJump.asm | MSFT - AArch64/CpuBreakpoint.asm | MSFT - AArch64/SpeculationBarrier.asm| MSFT - [Packages] MdePkg/MdePkg.dec -- 2.18.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline X86 assembly code
MdePkg BaseSynchronizationLib still uses the inline X86 assembly code in C code files.It should be updated to consume nasm only. https://bugzilla.tianocore.org/show_bug.cgi?id=1163 Cc: Michael D Kinney Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Shenglei Zhang --- .../Library/BaseSynchronizationLib/BaseSynchronizationLib.inf | 2 -- 1 file changed, 2 deletions(-) diff --git a/MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf b/MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf index 32414b29fa..719dc1938d 100755 --- a/MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf +++ b/MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf @@ -75,13 +75,11 @@ [Sources.ARM] Synchronization.c - Arm/Synchronization.asm | RVCT Arm/Synchronization.S | GCC [Sources.AARCH64] Synchronization.c AArch64/Synchronization.S | GCC - AArch64/Synchronization.asm | MSFT [Packages] MdePkg/MdePkg.dec -- 2.18.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2 1/1] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems
From: "Cohen, Eugene"
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1583
The SdMmcPciHcDriverBindingStart function was checking two different
capability bits in determining whether 64-bit DMA modes were supported,
one mode is defined in the SDHC version 3 specification (using 96-bit
descriptors) and another is defined in the SDHC version 4 specification
(using 128-bit descriptors).
Since the currently implementation of 64-bit ADMA2 only supports the SDHC
version 4 implementation, it is incorrect to check the V3 64-bit
capability bit since this will activate V4 ADMA2 on V3 controllers which
then causes buffers to be allocated that cannot be DMAed.
Cc: Ard Biesheuvel
Cc: Ashish Singhal
Cc: Hao Wu
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eugene Cohen
Acked-by: Ard Biesheuvel
Acked-by: Ashish Singhal
Reviewed-by: Hao Wu
---
MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
index b474f8decd..5bc91c5337 100644
--- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
+++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
@@ -666,8 +666,7 @@ SdMmcPciHcDriverBindingStart (
// If any of the slots does not support 64b system bus
// do not enable 64b DMA in the PCI layer.
//
-if (Private->Capability[Slot].SysBus64V3 == 0 &&
-Private->Capability[Slot].SysBus64V4 == 0) {
+if (Private->Capability[Slot].SysBus64V4 == 0) {
Support64BitDma = FALSE;
}
--
2.12.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2 0/1] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems
V2 changes: On behalf of Eugene, V2 patch does not have functional changes compared with V1, only the reference Bugzilla tracker link is added in the commit log message. I added the previous 'Ack' tag from Ard and Ashish, I added my 'Reviewed-by' as well. Cc: Eugene Cohen Cc: Ard Biesheuvel Cc: Ashish Singhal Cohen, Eugene (1): MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -- 2.12.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH V2] BaseTools:Run packagedoc_cli.py to generate doc failed
Hi,
This patch is to fix the a regression issue introduced by python3 patch set.
I'd like to push this patch for Q1 stable tag.
Would you approve it?
Thanks,
Bob
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Feng,
Bob C
Sent: Monday, March 4, 2019 3:30 PM
To: Fan, ZhijuX ; edk2-devel@lists.01.org
Cc: Gao, Liming
Subject: Re: [edk2] [PATCH V2] BaseTools:Run packagedoc_cli.py to generate doc
failed
Reviewed-by: Bob Feng
-Original Message-
From: Fan, ZhijuX
Sent: Friday, March 1, 2019 10:52 AM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Feng, Bob C
Subject: [edk2][PATCH V2] BaseTools:Run packagedoc_cli.py to generate doc failed
The reason for this problem is that the file was opened incorrectly.
Cc: Bob Feng
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhiju.Fan
---
.../plugins/EdkPlugins/edk2/model/doxygengen.py| 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git
a/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/doxygengen.py
b/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/doxygengen.py
index e31df262bc..73349e2f48 100644
---
a/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/doxygengen.py
+++
b/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/doxygengen.py
@@ -376,9 +376,10 @@ class PackageDocumentAction(DoxygenAction):
return
try:
-f = open(path, 'r')
-lines = f.readlines()
-f.close()
+with open(path, 'r') as f:
+lines = f.readlines()
+except UnicodeDecodeError:
+return
except IOError:
ErrorMsg('Fail to open file %s' % path)
return
--
2.14.1.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH] UefiCpuPkg/Microcode.c: Add verification before calculate CheckSum32
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1020
Should make sure the TotalSize of Microcode is aligned with 4 bytes
before calling CalculateSum32 function.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chen A Chen
Cc: Ray Ni
Cc: Eric Dong
---
UefiCpuPkg/Library/MpInitLib/Microcode.c | 31 ---
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/UefiCpuPkg/Library/MpInitLib/Microcode.c
b/UefiCpuPkg/Library/MpInitLib/Microcode.c
index 5f9ae22794..643a6f94f4 100644
--- a/UefiCpuPkg/Library/MpInitLib/Microcode.c
+++ b/UefiCpuPkg/Library/MpInitLib/Microcode.c
@@ -166,20 +166,29 @@ MicrocodeDetect (
//
CorrectMicrocode = FALSE;
-//
-// Save an in-complete CheckSum32 from CheckSum Part1 for common parts.
-//
if (MicrocodeEntryPoint->DataSize == 0) {
- InCompleteCheckSum32 = CalculateSum32 (
- (UINT32 *) MicrocodeEntryPoint,
- sizeof (CPU_MICROCODE_HEADER) + 2000
- );
+ TotalSize = sizeof (CPU_MICROCODE_HEADER) + 2000;
} else {
- InCompleteCheckSum32 = CalculateSum32 (
- (UINT32 *) MicrocodeEntryPoint,
- sizeof (CPU_MICROCODE_HEADER) +
MicrocodeEntryPoint->DataSize
- );
+ TotalSize = sizeof (CPU_MICROCODE_HEADER) +
MicrocodeEntryPoint->DataSize;
}
+
+///
+/// Check overflow and whether TotalSize is aligned with 4 bytes.
+///
+if ( ((UINTN)MicrocodeEntryPoint + TotalSize) > MicrocodeEnd ||
+ (TotalSize & 0x3) != 0
+ ) {
+ MicrocodeEntryPoint = (CPU_MICROCODE_HEADER *) (((UINTN)
MicrocodeEntryPoint) + SIZE_1KB);
+ continue;
+}
+
+//
+// Save an in-complete CheckSum32 from CheckSum Part1 for common parts.
+//
+InCompleteCheckSum32 = CalculateSum32 (
+ (UINT32 *) MicrocodeEntryPoint,
+ TotalSize
+ );
InCompleteCheckSum32 -= MicrocodeEntryPoint->ProcessorSignature.Uint32;
InCompleteCheckSum32 -= MicrocodeEntryPoint->ProcessorFlags;
InCompleteCheckSum32 -= MicrocodeEntryPoint->Checksum;
--
2.16.2.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms 3/3] Platform/ARM/SgiPkg: add MM based UEFI secure boot support
On Mon, 4 Mar 2019 at 11:12, Jagadeesh Ujja wrote: > > This implements support for UEFI secure boot on SGI platforms using > the standalone MM framework. This moves all of the software handling > of the UEFI authenticated variable store into the standalone MM > context residing in a secure partition. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Jagadeesh Ujja > --- > Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc | 33 +++- > Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf | 5 +++ > Platform/ARM/SgiPkg/SgiPlatform.dsc | 18 ++- > Platform/ARM/SgiPkg/SgiPlatform.fdf | 9 +- > 4 files changed, 62 insertions(+), 3 deletions(-) > > diff --git a/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc > b/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc > index 65dd6ac..889be2f 100644 > --- a/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc > +++ b/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc > @@ -75,7 +75,17 @@ >HobLib|StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.inf > > MmServicesTableLib|MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.inf > > MemoryAllocationLib|StandaloneMmPkg/Library/StandaloneMmMemoryAllocationLib/StandaloneMmMemoryAllocationLib.inf > - > +!if $(MM_SECURE_STORAGE_ENABLE) == TRUE Does it make sense to make this conditional? Would you build PlatformStandaloneMm.dsc if MM_SECURE_STORAGE_ENABLE is FALSE? > + AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf > + BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf > + IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf > + > NorFlashPlatformLib|Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.inf > + OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf > + > PlatformSecureLib|SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.inf > + > SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf > + > TimerLib|MdePkg/Library/BaseTimerLibNullTemplate/BaseTimerLibNullTemplate.inf > + VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf > +!endif > > > # > # Pcd Section - list of all EDK II PCD Entries defined by this Platform > @@ -93,6 +103,21 @@ >gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x7FF7 >gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|115200 > > +!if $(MM_SECURE_STORAGE_ENABLE) == TRUE Same here > + #Secure Storage > + gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x2000 > + gEfiSecurityPkgTokenSpaceGuid.PcdUserPhysicalPresence|TRUE > + gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x2800 > + > + ## NV Storage - 1MB*3 in NOR2 Flash > + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x1040 > + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0010 > + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0x1050 > + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x0010 > + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0x1060 > + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x0010 > +!endif > + > > ### > # > # Components Section - list of the modules and components that will be > processed by compilation > @@ -118,6 +143,12 @@ >StandaloneMmPkg/Core/StandaloneMmCore.inf > > [Components.AARCH64] > +!if $(MM_SECURE_STORAGE_ENABLE) == TRUE Same here > + ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashStandaloneMm.inf > + > MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf > + MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf > +!endif > + >StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.inf > > > ### > diff --git a/Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf > b/Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf > index 810460c..04aa5cd 100644 > --- a/Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf > +++ b/Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf > @@ -55,6 +55,11 @@ READ_LOCK_CAP = TRUE > READ_LOCK_STATUS = TRUE > >INF StandaloneMmPkg/Core/StandaloneMmCore.inf > +!if $(MM_SECURE_STORAGE_ENABLE) == TRUE and here > + INF ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashStandaloneMm.inf > + INF > MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf > + INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf > +!endif >INF StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.inf > > > > diff --git a/Platform/ARM/SgiPkg/SgiPlatform.dsc >
Re: [edk2] [PATCH edk2-platforms 2/3] Platform/ARM/Sgi: allow MM_STANDALONE modules to use NorFlashPlatformLib
On Mon, 4 Mar 2019 at 11:12, Jagadeesh Ujja wrote:
>
> “NorFlashPlatformLib” library can be used by MM_STANDALONE drivers as
> well. When used in MM mode, the third instance of the NOR flash is used as
> the non-volatile storage. This NOR flash instance is partitioned into
> two regions - first 4MB space is used for secure boot and next 3MB for
> secure variable storage
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jagadeesh Ujja
> ---
> Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.c | 63
>
> Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.inf | 35
> +++
> 2 files changed, 98 insertions(+)
>
> diff --git
> a/Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.c
> b/Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.c
> new file mode 100644
> index 000..06e3f97
> --- /dev/null
> +++ b/Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.c
> @@ -0,0 +1,63 @@
> +/** @file
> +
> + Copyright (c) 2019, ARM Ltd. All rights reserved.
> +
> + This program and the accompanying materials are licensed and made available
> + under the terms and conditions of the BSD License which accompanies this
> + distribution. The full text of the license may be found at
> + http://opensource.org/licenses/bsd-license.php
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
> IMPLIED.
> +
> + **/
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +STATIC NOR_FLASH_DESCRIPTION mNorFlashDevices[] = {
> + {
> +// Secure Boot storage space of 4MB
> +SGI_EXP_SMC_CS2_BASE,
> +SGI_EXP_SMC_CS2_BASE,
> +SIZE_256KB * 16,
> +SIZE_256KB,
> + },
> + {
> +//Secure variable storage space of 1MB*3
> +SGI_EXP_SMC_CS2_BASE,
> +SGI_EXP_SMC_CS2_BASE + SIZE_256KB * 16,
> +SIZE_256KB * 12,
> +SIZE_256KB,
> + },
> +};
> +
> +EFI_STATUS
> +NorFlashPlatformInitialization (
> + VOID
> + )
> +{
> + UINT64 SysRegFlash;
> +
> + SysRegFlash = SGI_EXP_SYSPH_SYSTEM_REGISTERS + SGI_SYSPH_SYS_REG_FLASH;
> + MmioOr32 (SysRegFlash, SGI_SYSPH_SYS_REG_FLASH_RWEN);
> + return EFI_SUCCESS;
> +}
> +
> +EFI_STATUS
> +NorFlashPlatformGetDevices (
> + OUT NOR_FLASH_DESCRIPTION **NorFlashDevices,
> + OUT UINT32 *Count
> + )
> +{
> + if ((NorFlashDevices == NULL) || (Count == NULL)) {
> +return EFI_INVALID_PARAMETER;
> + }
> +
> + *NorFlashDevices = mNorFlashDevices;
> + *Count = ARRAY_SIZE (mNorFlashDevices);
> + return EFI_SUCCESS;
> +}
> diff --git
> a/Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.inf
> b/Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.inf
> new file mode 100644
> index 000..eedfacc
> --- /dev/null
> +++ b/Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.inf
> @@ -0,0 +1,35 @@
> +#/** @file
> +#
> +# Copyright (c) 2019, ARM Ltd. All rights reserved.
> +
> +# This program and the accompanying materials are licensed and made
> available
> +# under the terms and conditions of the BSD License which accompanies this
> +# distribution. The full text of the license may be found at
> +# http://opensource.org/licenses/bsd-license.php
> +#
> +# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
> IMPLIED.
> +#
> +#**/
> +
> +[Defines]
> + INF_VERSION= 0x0001001A
> + BASE_NAME = NorFlashSgiLib
> + FILE_GUID = 2ce22190-b933-4d1e-99ba-8bf1f0768255
> + MODULE_TYPE= MM_STANDALONE
Could this be BASE ?
> + VERSION_STRING = 1.0
> + PI_SPECIFICATION_VERSION = 0x00010032
Can we drop this?
> + LIBRARY_CLASS = NorFlashPlatformLib
> +
> +[Sources.common]
> + StandaloneMmNorFlashLib.c
> +
> +[Packages]
> + ArmPlatformPkg/ArmPlatformPkg.dec
> + MdePkg/MdePkg.dec
> + Platform/ARM/SgiPkg/SgiPlatform.dec
> +
> +[LibraryClasses]
> + BaseLib
> + DebugLib
> + IoLib
> --
> 2.7.4
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms 1/3] Platform/ARM/Sgi: define nor2 flash controller memory map
On Mon, 4 Mar 2019 at 11:12, Jagadeesh Ujja wrote: > > Add the definitions of NOR2 flash controller memory map. The NO2 flash > can be used as an additional non-volatile storage by non-secure code or > used as a non-volatile storage for secure variables by the StandaloneMM. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Jagadeesh Ujja Reviewed-by: Ard Biesheuvel > --- > Platform/ARM/SgiPkg/Include/SgiPlatform.h | 4 > 1 file changed, 4 insertions(+) > > diff --git a/Platform/ARM/SgiPkg/Include/SgiPlatform.h > b/Platform/ARM/SgiPkg/Include/SgiPlatform.h > index b9a662a..2a7b79d 100644 > --- a/Platform/ARM/SgiPkg/Include/SgiPlatform.h > +++ b/Platform/ARM/SgiPkg/Include/SgiPlatform.h > @@ -27,6 +27,10 @@ > #define SGI_EXP_SMC_CS1_BASE 0x0C00 > #define SGI_EXP_SMC_CS1_SZSIZE_64MB > > +// Expansion AXI - SMC Chip Select 2 > +#define SGI_EXP_SMC_CS2_BASE 0x1000 > +#define SGI_EXP_SMC_CS2_SZSIZE_64MB > + > // Expansion AXI - SMSC 91C111 (Ethernet) > #define SGI_EXP_SMSC91X_BASE 0x1800 > #define SGI_EXP_SMSC91X_SZSIZE_64MB > -- > 2.7.4 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch] Document: Update DEC spec to remove EDK related contents
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1453 Remove EDK related contents from DEC spec. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Bob Feng Cc: Liming Gao Cc: Jaben Carsey --- 2_dec_file_overview/210_pcd_usage.md | 4 +--- 2_dec_file_overview/25_[includes]_usage.md | 6 +- 2_dec_file_overview/26_[guids]_usage.md | 6 +- 2_dec_file_overview/27_[protocols]_usage.md | 6 +- 2_dec_file_overview/28_[ppis]_usage.md | 6 +- 2_dec_file_overview/29_[libraryclasses]_usage.md | 4 +--- 3_edk_ii_dec_file_format/310_pcd_sections.md | 8 ++-- 3_edk_ii_dec_file_format/35_[includes]_sections.md | 5 + 3_edk_ii_dec_file_format/39_[libraryclasses]_sections.md | 5 + 9 files changed, 10 insertions(+), 40 deletions(-) diff --git a/2_dec_file_overview/210_pcd_usage.md b/2_dec_file_overview/210_pcd_usage.md index 9b554be..e600db2 100644 --- a/2_dec_file_overview/210_pcd_usage.md +++ b/2_dec_file_overview/210_pcd_usage.md @@ -1,9 +1,9 @@
[edk2] [PATCH 3/3] OvmfPkg/XenSupport: turn off address decoding before BAR sizing
On Xen, hvmloader firmware leaves address decoding enabled for
enumerated PCI device before jumping into OVMF. OVMF seems to
expect it to be disabled and tries to size PCI BARs in several places
without disabling it which causes BAR64, for example, being
incorrectly placed by QEMU.
Fix it by disabling PCI address decoding explicitly before the
first attempt to size BARs on Xen.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Igor Druzhinin
---
OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 34 +++
1 file changed, 34 insertions(+)
diff --git a/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
b/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
index 408fb24..9940335 100644
--- a/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
+++ b/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
@@ -55,6 +55,33 @@ PcatPciRootBridgeBarExisted (
EnableInterrupts ();
}
+#define EFI_PCI_COMMAND_DECODE ((UINT16)(EFI_PCI_COMMAND_IO_SPACE | \
+ EFI_PCI_COMMAND_MEMORY_SPACE))
+STATIC
+VOID
+PcatPciRootBridgeDecoding (
+ IN UINTN Address,
+ IN BOOLEANEnabled,
+ OUT UINT16 *OriginalValue
+ )
+{
+ UINT16Value;
+
+ //
+ // Preserve the original value
+ //
+ Value = *OriginalValue;
+ *OriginalValue = PciRead16 (Address);
+
+ if (!Enabled) {
+if (*OriginalValue & EFI_PCI_COMMAND_DECODE)
+ PciWrite16 (Address, *OriginalValue & ~EFI_PCI_COMMAND_DECODE);
+ } else {
+if (Value & EFI_PCI_COMMAND_DECODE)
+ PciWrite16 (Address, Value);
+ }
+}
+
STATIC
VOID
PcatPciRootBridgeParseBars (
@@ -76,6 +103,7 @@ PcatPciRootBridgeParseBars (
UINT32Value;
UINT32OriginalUpperValue;
UINT32UpperValue;
+ UINT16OriginalCommand;
UINT64Mask;
UINTN Offset;
UINT64Base;
@@ -83,6 +111,12 @@ PcatPciRootBridgeParseBars (
UINT64Limit;
PCI_ROOT_BRIDGE_APERTURE *MemAperture;
+ // Disable address decoding for every device before OVMF starts sizing it
+ PcatPciRootBridgeDecoding (
+PCI_LIB_ADDRESS (Bus, Device, Function, PCI_COMMAND_OFFSET),
+FALSE,
+ );
+
for (Offset = BarOffsetBase; Offset < BarOffsetEnd; Offset += sizeof
(UINT32)) {
PcatPciRootBridgeBarExisted (
PCI_LIB_ADDRESS (Bus, Device, Function, Offset),
--
2.7.4
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 1/3] OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge aperture
This aperture doesn't exist in OVMF and trying to use it causes
failing assertions later in cases there are prefetchable and
non-prefetchable BARs following each other. This configuration is
quite likely with some PCI passthrough devices.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Igor Druzhinin
---
OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
b/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
index 9204179..c23c46d 100644
--- a/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
+++ b/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
@@ -129,11 +129,7 @@ PcatPciRootBridgeParseBars (
//
Length = ((~Length) + 1) & 0x;
- if ((Value & BIT3) == BIT3) {
-MemAperture = PMem;
- } else {
-MemAperture = Mem;
- }
+ MemAperture = Mem;
} else {
//
// 64bit
@@ -149,11 +145,7 @@ PcatPciRootBridgeParseBars (
Length = Length | LShiftU64 ((UINT64) UpperValue, 32);
Length = (~Length) + 1;
- if ((Value & BIT3) == BIT3) {
-MemAperture = PMemAbove4G;
- } else {
-MemAperture = MemAbove4G;
- }
+ MemAperture = MemAbove4G;
}
Limit = Base + Length - 1;
--
2.7.4
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 0/3] Xen PCI passthrough fixes
Igor Druzhinin (3): OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge aperture OvmfPkg/XenSupport: use a correct PCI host bridge aperture for BAR64 OvmfPkg/XenSupport: turn off address decoding before BAR sizing OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 44 ++- 1 file changed, 37 insertions(+), 7 deletions(-) -- 2.7.4 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 2/3] OvmfPkg/XenSupport: use a correct PCI host bridge aperture for BAR64
In case BAR64 is placed below 4G choose the correct aperture.
This fixes a failed assertion down the code path.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Igor Druzhinin
---
OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
b/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
index c23c46d..408fb24 100644
--- a/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
+++ b/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
@@ -145,7 +145,11 @@ PcatPciRootBridgeParseBars (
Length = Length | LShiftU64 ((UINT64) UpperValue, 32);
Length = (~Length) + 1;
- MemAperture = MemAbove4G;
+ if (Base < 0x1) {
+MemAperture = Mem;
+ } else {
+MemAperture = MemAbove4G;
+ }
}
Limit = Base + Length - 1;
--
2.7.4
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch] Document: Update FDF spec to remove EDK related contents
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1453
Remove EDK related contents inf Fdf spec.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng
Cc: Liming Gao
Cc: Jaben Carsey
---
1_introduction/11_overview.md | 22 +-
1_introduction/12_terms.md| 8 +-
1_introduction/README.md | 9 +-
.../22_flash_description_file_format.md | 34 +--
2_fdf_design_discussion/24_[fd]_sections.md | 9 +-
2_fdf_design_discussion/25_[fv]_sections.md | 9 +-
...ule]_sections.md => 27_[rule]_sections.md} | 232 +-
2_fdf_design_discussion/27_[vtf]_sections.md | 82 ---
...sections.md => 28_[optionrom]_sections.md} | 112 -
2_fdf_design_discussion/README.md | 2 -
3_edk_ii_fdf_file_format/310_[vtf]_section.md | 203 ---
...ection.md => 310_pci_optionrom_section.md} | 228 -
3_edk_ii_fdf_file_format/31_general_rules.md | 13 +-
3_edk_ii_fdf_file_format/32_fdf_definition.md | 67 +
appendix_a_nt32pkg_flash_description_file.md | 4 +-
15 files changed, 317 insertions(+), 717 deletions(-)
rename 2_fdf_design_discussion/{28_[rule]_sections.md =>
27_[rule]_sections.md} (96%)
delete mode 100644 2_fdf_design_discussion/27_[vtf]_sections.md
rename 2_fdf_design_discussion/{29_[optionrom]_sections.md =>
28_[optionrom]_sections.md} (94%)
delete mode 100644 3_edk_ii_fdf_file_format/310_[vtf]_section.md
rename 3_edk_ii_fdf_file_format/{311_pci_optionrom_section.md =>
310_pci_optionrom_section.md} (93%)
diff --git a/1_introduction/11_overview.md b/1_introduction/11_overview.md
index 6db8a26..d7dbb20 100644
--- a/1_introduction/11_overview.md
+++ b/1_introduction/11_overview.md
@@ -1,9 +1,9 @@
-
-## 2.8 [Rule] Sections
-
-The optional `[Rule]` sections in the FDF file are used for combining binary
-images, not for compiling code. Rules are use with the `[FV]` section's module
-INF type to define how an FFS file is created for a given INF file. The EDK II
-Build Specification defines the default rules that are implicitly used for
-creating FFS files. The implicit rules follow the _PI Specification_ and
-_UEFI Specification_.
-
-The `[Rule]` section of the FDF file is used to define custom rules, which may
-be applied to a given INF file listed in an `[FV]` section. This section is
-also used to define rules for module types that permit the user to define the
-content of the FFS file - when an FFS type is not specified by either PI or
-UEFI specifications.
-
-The Rules can have multiple modifiers as shown below.
-
-`[Rule.ARCH.MODULE_TYPE.TEMPLATE_NAME]`
-
-If no `TEMPLATE_NAME` is given then the match is based on `ARCH` and
-`MODULE_TYPE` modifiers. `BINARY` is a reserved `TEMPLATE_NAME` as a default
rule
-name for binary modules. The `TEMPLATE_NAME` must be unique to the `ARCH` and
-`MODULE_TYPE`. It is permissible to use the same `TEMPLATE_NAME` for two or
-more `[Rule]` sections if the `ARCH` or the `MODULE_TYPE` listed are different
-for each of the sections.
-
-A `[Rule]` section is terminated by another section header or the end of file.
-
-The content of the `[Rule]` section is based on the `FILE` and section grammar
-of the FV section. The difference is the `FILE` referenced in the `[RULE]` is a
-`MACRO`. The section grammar is extended to include an optional argument,
-`Optional`. The `Optional` argument is used to say a section is optional. That
-is to say, if it does not exist, then it is O.K.
-
-**
-**Note:** The `!include` statement is valid for any part of the `[Rule]`
-section, including an entire `[Rule]` section.
-**
-
-The generic form of the entries for leaf sections is:
-
-` [Options] [{} {}]`
-
-When processing the FDF file, the following rules apply (in order):
-
-1. If `` not defined or not a legal name, then error
-2. If `` not defined or not a legal name, then error
-3. If `[FilePath/FileName]`, then:
- Add one section to FFS with a section type of ``
-4. Else:
- Find all files defined by the INF file whose file type is `` and
- add each one to the FFS with a section type of `` in
- alphabetical order.
- Add files defined in `[Sources]` followed by files defined in `[Binaries]`
-
-5. If > 1 `UI` section in final FFS, then error
-6. If > 1 `VER` section in final FFS, then error
-7. If > 1 `PEI_DEPEX` section in final FFS, then error
-8. If > 1 `DXE_DEPEX` section in final FFS, then error
-9. If > 1 `SMM_DEPEX` section in final FFS, then error
-
-If a rule specifies a file type, instead of specifying specific file names, the
-files that match the extension must be processed in alphabetical order.
-
- Example
-
-```ini
-[Rule.Common.ACPITABLE]
- FILE FREEFORM = $(NAMED_GUID) {
-RAW ACPI Optional |.acpi
-RAW ASL Optional |.aml
- }
-```
-
-Tools must add the processed .acpi files alphabetically, followed by the .aml
-files which must also be added alphabetically.
-
-The file
Re: [edk2] [RFC 0/3] Enable runtime serial debug for ArmVirtQemu
On 2019/3/1 23:27, Laszlo Ersek wrote: +Peter, for the last few paragraphs On 02/28/19 13:10, Ard Biesheuvel wrote: On Thu, 28 Feb 2019 at 09:06, Heyi Guo wrote: Serial port output is useful when debugging UEFI runtime services in OS runtime. The patches are trying to provide a handy method to enable runtime serial port debug for ArmVirtQemu. Cc: Jian J Wang Cc: Hao Wu Cc: Laszlo Ersek Cc: Ard Biesheuvel Cc: Julien Grall Heyi Guo (3): MdeModulePkg/StatusCode: Add PCD to enable runtime serial debug ArmVirtPkg: add runtime instance of FdtPL011SerialPortLib ArmVirtQemu: enable runtime debug by build flag Hello Heyi, We have had this discussion before, and IIRC, the proposed solution was to use status codes. I'm not sure how that is supposed to work though - hopefully Laszlo or one of the MdeModulePkg maintainers can elaborate. Here's the basic idea. Status Code reporting and routing are defined by the PI spec for OS runtime as well, not just boot time. Recently we added status code *routing* to ArmVirtPkg, in commit 5c574b222ec2, via the generic runtime driver "ReportStatusCodeRouterRuntimeDxe". We also added the library resolution ReportStatusCodeLib --> MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf (for some module types). As a result, when modules of those types report status codes, they now reach the ReportStatusCodeRouterRuntimeDxe driver, which "routes" the status codes. In the same series, we also modified ArmVirtPkg's PlatformBootManagerLib (built into BdsDxe) to register a status code *handler* callback with ReportStatusCodeRouterRuntimeDxe -- but only for boot time (not runtime), and only for a very specific group of status codes. As a result, when a module of suitable type reports a status code, ReportStatusCodeRouterRuntimeDxe "routes it" to BdsDxe, and then BdsDxe "handles it" (in our implementation, we simply format it to the UEFI console), assuming the status code is the kind we are interested in. Now we come to the current series. First, the series adds the following DebugLib class resolution: DebugLib --> MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf This will cause modules to publish their DEBUG messages as status codes via ReportStatusCodeLib, rather than log them via SerialPortLib. (I'm too lazy to check the exact status code classes etc that PeiDxeDebugLibReportStatusCode embeds the DEBUG messages into.) As a result, DEBUG messages will reach ReportStatusCodeRouterRuntimeDxe for "routing". As another result, until we reach a late enough stage in the boot, those messages will not be printed by anything (because there's not going to be any "handling" for them). (The present series also updates the ReportStatusCodeLib resolution so it can be used at runtime too, but that's quite auxiliary to this discussion.) Second, this series includes the generic Status Code *handling* driver (also a runtime driver): "StatusCodeHandlerRuntimeDxe". Independently of the particular handling that we already have in BdsDxe via the earlier series, this generic status handler driver registers a handler callback that simply prints status codes to the serial port (dependent on a PCD setting), via SerialPortLib. With the modification from the first patch, this generic status code *handler* driver is extended to runtime serial port operation. And, the second patch in the series provides a SerialPortLib instance for it that can work at runtime. All in all, when a runtime driver calls DEBUG, this happens: runtime driver calls DEBUG -> PeiDxeDebugLibReportStatusCode -> RuntimeDxeReportStatusCodeLib [status code reporting] => ReportStatusCodeRouterRuntimeDxe [status code routing] => StatusCodeHandlerRuntimeDxe [status code handling, such as SerialPortWrite():] -> FdtPL011SerialPortLibRuntime This is actually a good idea, but it would be nice if: - QEMU had two PL011 ports, - the boot time firmware log, and the OS log, went to one port - the runtme firmware log went to the other port. This makes sense. I'll try the 2nd serial port. Thanks, Heyi Given that this series provides the SerialPortLib instance for StatusCodeHandlerRuntimeDxe anyway, we could implement it so that it locate a "special" PL011 in QEMU's DTB -- the port that we'd only use for runtime firmware logging. I don't insist that this series implement all of that, but it should either prevent a conflict on the one PL011 between the firmware and the OS, or else be very explicit about the possible conflict in the commit messages. Thanks Laszlo . ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch] Document: Update Inf spec to remove EDK related contents
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1453 Remove EDK related contents Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Bob Feng Cc: Liming Gao Cc: Jaben Carsey --- 1_introduction/11_overview.md | 2 +- 2_inf_overview/210_[ppis]_section.md | 1 - 2_inf_overview/211_[guids]_section.md | 1 - .../212_[libraryclasses]_section.md | 1 - 2_inf_overview/213_[packages]_section.md | 1 - 2_inf_overview/214_pcd_sections.md| 14 +- 2_inf_overview/215_[depex]_section.md | 4 - 2_inf_overview/21_processing_overview.md | 19 +- .../22_information_file_general_rules.md | 30 +- 2_inf_overview/24_[defines]_section.md| 4 +- 2_inf_overview/25_[sources]_section.md| 4 - 2_inf_overview/26_[buildoptions]_section.md | 9 +- 2_inf_overview/27_[binaries]_section.md | 5 - 2_inf_overview/29_[protocols]_section.md | 1 - 2_inf_overview/README.md | 11 - .../314_[depex]_sections.md | 6 +- .../315_[binaries]_section.md | 5 - .../32_component_inf_definition.md| 4 +- .../34_[defines]_section.md | 6 +- .../35_[buildoptions]_sections.md | 5 +- .../39_[sources]_sections.md | 7 +- 3_edk_ii_inf_file_format/README.md| 4 - ...ndix_a_build_changes_and_customizations.md | 0 .../README.md | 40 -- .../a1_design_discussion.md | 317 .../a2_edk_file_specification.md | 461 -- ...ndix_c_symbols.md => appendix_b_symbols.md | 0 ...d => appendix_c_sample_driver_inf_files.md | 0 ... => appendix_d_sample_library_inf_files.md | 0 ...d => appendix_e_sample_binary_inf_files.md | 0 ...ule_types.md => appendix_f_module_types.md | 0 31 files changed, 30 insertions(+), 932 deletions(-) rename appendix_b_build_changes_and_customizations.md => appendix_a_build_changes_and_customizations.md (100%) delete mode 100644 appendix_a_edk_inf_file_specification/README.md delete mode 100644 appendix_a_edk_inf_file_specification/a1_design_discussion.md delete mode 100644 appendix_a_edk_inf_file_specification/a2_edk_file_specification.md rename appendix_c_symbols.md => appendix_b_symbols.md (100%) rename appendix_d_sample_driver_inf_files.md => appendix_c_sample_driver_inf_files.md (100%) rename appendix_e_sample_library_inf_files.md => appendix_d_sample_library_inf_files.md (100%) rename appendix_f_sample_binary_inf_files.md => appendix_e_sample_binary_inf_files.md (100%) rename appendix_g_module_types.md => appendix_f_module_types.md (100%) diff --git a/1_introduction/11_overview.md b/1_introduction/11_overview.md index 9239080..7349614 100644 --- a/1_introduction/11_overview.md +++ b/1_introduction/11_overview.md @@ -40,11 +40,11 @@ Backward compatibility with the existing INF file formats. Changes made to this specification must not require changes to existing INF files. **Simplified platform build and configuration** Simplify the build setup and configuration for a given platform. The process of -adding EDK and EDK II firmware components to a firmware volume on any given +adding EDK II firmware components to a firmware volume on any given platform was also simplified. **Distributing Modules** Enable easy distribution of modules, both in source and binary form. Individual diff --git a/2_inf_overview/210_[ppis]_section.md b/2_inf_overview/210_[ppis]_section.md index bbdd2a4..1ab84eb 100644 --- a/2_inf_overview/210_[ppis]_section.md +++ b/2_inf_overview/210_[ppis]_section.md @@ -46,11 +46,10 @@ This section uses one of the following section definitions: ```ini [Ppis] [Ppis.common] [Ppis.IA32] [Ppis.X64] -[Ppis.IPF] [Ppis.EBC] ``` The formats for entries in this section is: diff --git a/2_inf_overview/211_[guids]_section.md b/2_inf_overview/211_[guids]_section.md index 7f53f6c..4176310 100644 --- a/2_inf_overview/211_[guids]_section.md +++ b/2_inf_overview/211_[guids]_section.md @@ -46,11 +46,10 @@ This section uses one of the following section definitions: ```ini [Guids] [Guids.common] [Guids.IA32] [Guids.X64] -[Guids.IPF] [Guids.EBC] ``` The formats for entries in this section is: diff --git a/2_inf_overview/212_[libraryclasses]_section.md b/2_inf_overview/212_[libraryclasses]_section.md index 8d2fd06..8a77463 100644 --- a/2_inf_overview/212_[libraryclasses]_section.md +++ b/2_inf_overview/212_[libraryclasses]_section.md @@ -46,11 +46,10 @@ This section uses one of the following section definitions: ```ini [LibraryClasses] [LibraryClasses.common] [LibraryClasses.IA32] [LibraryClasses.X64] -[LibraryClasses.IPF] [LibraryClasses.EBC] ``` The format for entries in this section is: diff --git a/2_inf_overview/213_[packages]_section.md b/2_inf_overview/213_[packages]_section.md
Re: [edk2] [PATCH v3] StandaloneMmPkg/Library: Install Variable Arch Protocol
(add StandaloneMmPkg maintainers)
On Mon, 4 Mar 2019 at 09:54, Jagadeesh Ujja wrote:
>
> In a system implementing the variable store in MM, there are no variable
> arch protocol and variable write arch protocol installed into the
> DXE_SMM protocol database. On such systems, it is not required to
> locate these protocols by the DXE runtime variable drivers because
> it can be assumed that these protocols are already installed in the
> MM context. But then such an implementation will deviate from the
> existing traditional MM based variable driver implementation.
>
> So in order to maintain consistency with the traditional MM variable
> driver implementation, allow platforms to install these protocols into
> the DXE protocol database but these protocol will not be consumed
> by non-secure variable service runtime driver.
>
> The Platform which uses StandaloneMM based secure variable storage
> have to include this library
>
> Example
> In edk2-platforms/Platform/ARM/SgiPkg/SgiPlatform.dsc
>
> ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf {
>
>
> NULL|StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.inf
> }
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jagadeesh Ujja
Reviewed-by: Ard Biesheuvel
> ---
> Changes since v2:
> - Addressed the comments from Ard Biesheuvel and Zeng Star
>
> Changes since v1:
> - This is a next version of patch
>“MdeModulePkg/VariableSmmRuntimeDxe: Refactor locating Variable Arch
> Protocol”.
>[https://lists.01.org/pipermail/edk2-devel/2019-February/036885.html]
> - Addressed the comments from Ard Biesheuvel and Zeng Star
> - Can this library be placed in MdePkg rather then the StandaloneMmPkg?
>
> StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.c | 54
>
> StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.inf | 46
> +
> 2 files changed, 100 insertions(+)
>
> diff --git
> a/StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.c
> b/StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.c
> new file mode 100644
> index 000..7e0f31b
> --- /dev/null
> +++ b/StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.c
> @@ -0,0 +1,54 @@
> +/** @file
> + Runtime DXE part corresponding to StanaloneMM variable module.
> +
> +This module installs variable arch protocol and variable write arch protocol
> +to StandaloneMM runtime variable service.
> +
> +Copyright (c) 2019, ARM Ltd. All rights reserved.
> +
> +This program and the accompanying materials
> +are licensed and made available under the terms and conditions of the BSD
> License
> +which accompanies this distribution. The full text of the license may be
> found at
> +http://opensource.org/licenses/bsd-license.php.
> +
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#include
> +#include
> +
> +/**
> + The constructor function installs variable arch protocol and variable
> + write arch protocol to StandaloneMM runtime variable service
> +
> + @param ImageHandle The firmware allocated handle for the EFI image.
> + @param SystemTable A pointer to the Management mode System Table.
> +
> + @retval EFI_SUCCESS The constructor always returns EFI_SUCCESS.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +VariableMmDependencyLibConstructor (
> + IN EFI_HANDLE ImageHandle,
> + IN EFI_SYSTEM_TABLE *SystemTable
> + )
> +{
> + EFI_STATUSStatus;
> + EFI_HANDLEHandle;
> +
> + Handle = NULL;
> + Status = gBS->InstallMultipleProtocolInterfaces (
> + ,
> + ,
> + NULL,
> + ,
> + NULL,
> + NULL
> + );
> + ASSERT_EFI_ERROR (Status);
> + return EFI_SUCCESS;
> +}
> +
> diff --git
> a/StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.inf
> b/StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.inf
> new file mode 100644
> index 000..e71c44d
> --- /dev/null
> +++ b/StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.inf
> @@ -0,0 +1,46 @@
> +## @file
> +# Runtime DXE part corresponding to StanaloneMM variable module.
> +#
> +# This module installs variable arch protocol and variable write arch
> protocol
> +# to StandaloneMM runtime variable service.
> +#
> +# Copyright (c) 2019, ARM Ltd. All rights reserved.
> +# This program and the accompanying materials
> +# are licensed and made available under the terms and conditions of the BSD
> License
> +# which accompanies this distribution. The full text of the license may be
> found at
> +# http://opensource.org/licenses/bsd-license.php
> +# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +# WITHOUT WARRANTIES OR
[edk2] [PATCH edk2-platforms 3/3] Platform/ARM/SgiPkg: add MM based UEFI secure boot support
This implements support for UEFI secure boot on SGI platforms using the standalone MM framework. This moves all of the software handling of the UEFI authenticated variable store into the standalone MM context residing in a secure partition. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jagadeesh Ujja --- Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc | 33 +++- Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf | 5 +++ Platform/ARM/SgiPkg/SgiPlatform.dsc | 18 ++- Platform/ARM/SgiPkg/SgiPlatform.fdf | 9 +- 4 files changed, 62 insertions(+), 3 deletions(-) diff --git a/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc b/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc index 65dd6ac..889be2f 100644 --- a/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc +++ b/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc @@ -75,7 +75,17 @@ HobLib|StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.inf MmServicesTableLib|MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.inf MemoryAllocationLib|StandaloneMmPkg/Library/StandaloneMmMemoryAllocationLib/StandaloneMmMemoryAllocationLib.inf - +!if $(MM_SECURE_STORAGE_ENABLE) == TRUE + AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf + BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf + IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf + NorFlashPlatformLib|Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.inf + OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf + PlatformSecureLib|SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.inf + SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf + TimerLib|MdePkg/Library/BaseTimerLibNullTemplate/BaseTimerLibNullTemplate.inf + VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf +!endif # # Pcd Section - list of all EDK II PCD Entries defined by this Platform @@ -93,6 +103,21 @@ gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x7FF7 gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|115200 +!if $(MM_SECURE_STORAGE_ENABLE) == TRUE + #Secure Storage + gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x2000 + gEfiSecurityPkgTokenSpaceGuid.PcdUserPhysicalPresence|TRUE + gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x2800 + + ## NV Storage - 1MB*3 in NOR2 Flash + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x1040 + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0010 + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0x1050 + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x0010 + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0x1060 + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x0010 +!endif + ### # # Components Section - list of the modules and components that will be processed by compilation @@ -118,6 +143,12 @@ StandaloneMmPkg/Core/StandaloneMmCore.inf [Components.AARCH64] +!if $(MM_SECURE_STORAGE_ENABLE) == TRUE + ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashStandaloneMm.inf + MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf + MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf +!endif + StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.inf ### diff --git a/Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf b/Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf index 810460c..04aa5cd 100644 --- a/Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf +++ b/Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf @@ -55,6 +55,11 @@ READ_LOCK_CAP = TRUE READ_LOCK_STATUS = TRUE INF StandaloneMmPkg/Core/StandaloneMmCore.inf +!if $(MM_SECURE_STORAGE_ENABLE) == TRUE + INF ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashStandaloneMm.inf + INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf + INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf +!endif INF StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.inf diff --git a/Platform/ARM/SgiPkg/SgiPlatform.dsc b/Platform/ARM/SgiPkg/SgiPlatform.dsc index bdb4ecb..cba2e1f 100644 --- a/Platform/ARM/SgiPkg/SgiPlatform.dsc +++ b/Platform/ARM/SgiPkg/SgiPlatform.dsc @@ -260,7 +260,15 @@ MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf +!if $(SECURE_BOOT_ENABLE) == TRUE +
[edk2] [PATCH edk2-platforms 2/3] Platform/ARM/Sgi: allow MM_STANDALONE modules to use NorFlashPlatformLib
“NorFlashPlatformLib” library can be used by MM_STANDALONE drivers as
well. When used in MM mode, the third instance of the NOR flash is used as
the non-volatile storage. This NOR flash instance is partitioned into
two regions - first 4MB space is used for secure boot and next 3MB for
secure variable storage
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jagadeesh Ujja
---
Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.c | 63
Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.inf | 35
+++
2 files changed, 98 insertions(+)
diff --git a/Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.c
b/Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.c
new file mode 100644
index 000..06e3f97
--- /dev/null
+++ b/Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.c
@@ -0,0 +1,63 @@
+/** @file
+
+ Copyright (c) 2019, ARM Ltd. All rights reserved.
+
+ This program and the accompanying materials are licensed and made available
+ under the terms and conditions of the BSD License which accompanies this
+ distribution. The full text of the license may be found at
+ http://opensource.org/licenses/bsd-license.php
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+ **/
+
+#include
+#include
+#include
+#include
+#include
+
+STATIC NOR_FLASH_DESCRIPTION mNorFlashDevices[] = {
+ {
+// Secure Boot storage space of 4MB
+SGI_EXP_SMC_CS2_BASE,
+SGI_EXP_SMC_CS2_BASE,
+SIZE_256KB * 16,
+SIZE_256KB,
+ },
+ {
+//Secure variable storage space of 1MB*3
+SGI_EXP_SMC_CS2_BASE,
+SGI_EXP_SMC_CS2_BASE + SIZE_256KB * 16,
+SIZE_256KB * 12,
+SIZE_256KB,
+ },
+};
+
+EFI_STATUS
+NorFlashPlatformInitialization (
+ VOID
+ )
+{
+ UINT64 SysRegFlash;
+
+ SysRegFlash = SGI_EXP_SYSPH_SYSTEM_REGISTERS + SGI_SYSPH_SYS_REG_FLASH;
+ MmioOr32 (SysRegFlash, SGI_SYSPH_SYS_REG_FLASH_RWEN);
+ return EFI_SUCCESS;
+}
+
+EFI_STATUS
+NorFlashPlatformGetDevices (
+ OUT NOR_FLASH_DESCRIPTION **NorFlashDevices,
+ OUT UINT32 *Count
+ )
+{
+ if ((NorFlashDevices == NULL) || (Count == NULL)) {
+return EFI_INVALID_PARAMETER;
+ }
+
+ *NorFlashDevices = mNorFlashDevices;
+ *Count = ARRAY_SIZE (mNorFlashDevices);
+ return EFI_SUCCESS;
+}
diff --git
a/Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.inf
b/Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.inf
new file mode 100644
index 000..eedfacc
--- /dev/null
+++ b/Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.inf
@@ -0,0 +1,35 @@
+#/** @file
+#
+# Copyright (c) 2019, ARM Ltd. All rights reserved.
+
+# This program and the accompanying materials are licensed and made available
+# under the terms and conditions of the BSD License which accompanies this
+# distribution. The full text of the license may be found at
+# http://opensource.org/licenses/bsd-license.php
+#
+# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
IMPLIED.
+#
+#**/
+
+[Defines]
+ INF_VERSION= 0x0001001A
+ BASE_NAME = NorFlashSgiLib
+ FILE_GUID = 2ce22190-b933-4d1e-99ba-8bf1f0768255
+ MODULE_TYPE= MM_STANDALONE
+ VERSION_STRING = 1.0
+ PI_SPECIFICATION_VERSION = 0x00010032
+ LIBRARY_CLASS = NorFlashPlatformLib
+
+[Sources.common]
+ StandaloneMmNorFlashLib.c
+
+[Packages]
+ ArmPlatformPkg/ArmPlatformPkg.dec
+ MdePkg/MdePkg.dec
+ Platform/ARM/SgiPkg/SgiPlatform.dec
+
+[LibraryClasses]
+ BaseLib
+ DebugLib
+ IoLib
--
2.7.4
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-platforms 1/3] Platform/ARM/Sgi: define nor2 flash controller memory map
Add the definitions of NOR2 flash controller memory map. The NO2 flash can be used as an additional non-volatile storage by non-secure code or used as a non-volatile storage for secure variables by the StandaloneMM. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jagadeesh Ujja --- Platform/ARM/SgiPkg/Include/SgiPlatform.h | 4 1 file changed, 4 insertions(+) diff --git a/Platform/ARM/SgiPkg/Include/SgiPlatform.h b/Platform/ARM/SgiPkg/Include/SgiPlatform.h index b9a662a..2a7b79d 100644 --- a/Platform/ARM/SgiPkg/Include/SgiPlatform.h +++ b/Platform/ARM/SgiPkg/Include/SgiPlatform.h @@ -27,6 +27,10 @@ #define SGI_EXP_SMC_CS1_BASE 0x0C00 #define SGI_EXP_SMC_CS1_SZSIZE_64MB +// Expansion AXI - SMC Chip Select 2 +#define SGI_EXP_SMC_CS2_BASE 0x1000 +#define SGI_EXP_SMC_CS2_SZSIZE_64MB + // Expansion AXI - SMSC 91C111 (Ethernet) #define SGI_EXP_SMSC91X_BASE 0x1800 #define SGI_EXP_SMSC91X_SZSIZE_64MB -- 2.7.4 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-platforms 0/3] Platform/ARM/SgiPkg: Implement StandaloneMm based secure boot
Integrating various pieces together so that the authenticated variable store runs entirely in standalone MM context residing in a secure partition. This primarily involves adding all required library and drivers to platform specific .DSC and .FDF files. This creates separate Nor flash region which is visible to only StandaoneMm drivers, this Nor Flash will co-exist along with general Nor flash region. Jagadeesh Ujja (3): Platform/ARM/Sgi: define nor2 flash controller memory map Platform/ARM/Sgi: allow MM_STANDALONE modules to use NorFlashPlatformLib Platform/ARM/SgiPkg: add MM based UEFI secure boot support Platform/ARM/SgiPkg/Include/SgiPlatform.h | 4 ++ Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.c | 63 Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.inf | 35 +++ Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc| 33 +- Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf| 5 ++ Platform/ARM/SgiPkg/SgiPlatform.dsc | 18 +- Platform/ARM/SgiPkg/SgiPlatform.fdf | 9 ++- 7 files changed, 164 insertions(+), 3 deletions(-) create mode 100644 Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.c create mode 100644 Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.inf -- 2.7.4 In-Reply-To: ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v3] StandaloneMmPkg/Library: Install Variable Arch Protocol
In a system implementing the variable store in MM, there are no variable
arch protocol and variable write arch protocol installed into the
DXE_SMM protocol database. On such systems, it is not required to
locate these protocols by the DXE runtime variable drivers because
it can be assumed that these protocols are already installed in the
MM context. But then such an implementation will deviate from the
existing traditional MM based variable driver implementation.
So in order to maintain consistency with the traditional MM variable
driver implementation, allow platforms to install these protocols into
the DXE protocol database but these protocol will not be consumed
by non-secure variable service runtime driver.
The Platform which uses StandaloneMM based secure variable storage
have to include this library
Example
In edk2-platforms/Platform/ARM/SgiPkg/SgiPlatform.dsc
ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf {
NULL|StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.inf
}
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jagadeesh Ujja
---
Changes since v2:
- Addressed the comments from Ard Biesheuvel and Zeng Star
Changes since v1:
- This is a next version of patch
“MdeModulePkg/VariableSmmRuntimeDxe: Refactor locating Variable Arch
Protocol”.
[https://lists.01.org/pipermail/edk2-devel/2019-February/036885.html]
- Addressed the comments from Ard Biesheuvel and Zeng Star
- Can this library be placed in MdePkg rather then the StandaloneMmPkg?
StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.c | 54
StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.inf | 46
+
2 files changed, 100 insertions(+)
diff --git
a/StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.c
b/StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.c
new file mode 100644
index 000..7e0f31b
--- /dev/null
+++ b/StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.c
@@ -0,0 +1,54 @@
+/** @file
+ Runtime DXE part corresponding to StanaloneMM variable module.
+
+This module installs variable arch protocol and variable write arch protocol
+to StandaloneMM runtime variable service.
+
+Copyright (c) 2019, ARM Ltd. All rights reserved.
+
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD
License
+which accompanies this distribution. The full text of the license may be
found at
+http://opensource.org/licenses/bsd-license.php.
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include
+#include
+
+/**
+ The constructor function installs variable arch protocol and variable
+ write arch protocol to StandaloneMM runtime variable service
+
+ @param ImageHandle The firmware allocated handle for the EFI image.
+ @param SystemTable A pointer to the Management mode System Table.
+
+ @retval EFI_SUCCESS The constructor always returns EFI_SUCCESS.
+
+**/
+EFI_STATUS
+EFIAPI
+VariableMmDependencyLibConstructor (
+ IN EFI_HANDLE ImageHandle,
+ IN EFI_SYSTEM_TABLE *SystemTable
+ )
+{
+ EFI_STATUSStatus;
+ EFI_HANDLEHandle;
+
+ Handle = NULL;
+ Status = gBS->InstallMultipleProtocolInterfaces (
+ ,
+ ,
+ NULL,
+ ,
+ NULL,
+ NULL
+ );
+ ASSERT_EFI_ERROR (Status);
+ return EFI_SUCCESS;
+}
+
diff --git
a/StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.inf
b/StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.inf
new file mode 100644
index 000..e71c44d
--- /dev/null
+++ b/StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.inf
@@ -0,0 +1,46 @@
+## @file
+# Runtime DXE part corresponding to StanaloneMM variable module.
+#
+# This module installs variable arch protocol and variable write arch protocol
+# to StandaloneMM runtime variable service.
+#
+# Copyright (c) 2019, ARM Ltd. All rights reserved.
+# This program and the accompanying materials
+# are licensed and made available under the terms and conditions of the BSD
License
+# which accompanies this distribution. The full text of the license may be
found at
+# http://opensource.org/licenses/bsd-license.php
+# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+#
+##
+
+[Defines]
+ INF_VERSION= 0x0001001A
+ BASE_NAME = VariableMmDependency
+ FILE_GUID = 64BC4129-778E-4867-BA07-13999A4DEC3F
+ MODULE_TYPE= DXE_DRIVER
+ LIBRARY_CLASS = NULL
+ CONSTRUCTOR=
