[edk2] [PATCH edk2-platforms v3 00/18] Fix issues and improve D0x
Main Changes since v2 : 1 Move tidy and delete header file patch to the first of the series. Code can also be found in github: https://github.com/hisilicon/OpenPlatformPkg.git branch: 1902-platforms-v3 Jason Zhang (1): Hisilicon/D06: Fix access variable fail issue Ming Huang (16): Hisilicon/D0x: Remove and tidy some codes about SerdesLib Hisilicon/D0x: Delete some header files Hisilicon/D0x: Add DriverHealthManagerDxe Hisilicon/D06: Optimize SAS driver for reducing boot time Hisilicon/D06: Drop the leading 0 (0x0 -> 0x) Hisilicon/D06: Add more PCIe port INT-x support Hisilicon/D0x: Rename StartupAp() function Hisilicon/D06: Use HCCS speed with 2.6G Hisilicon/D06: Add PCI_OSC_SUPPORT Hisilicon/D06: Modify for IMP self-Adapte support Hisilicon/D06: Add Setup Item "Support DPC" and delete some PCIe menus Hisilicon/D06: Use new flash layout Hisilicon/D06: Remove SECURE_BOOT_ENABLE definition Hisilicon/D0x: Remove SP805 watchdog pcd Hisilicon/D06: Fix USB crash issue(4079) Hisilicon/D0x: Modify version to 19.02 xingjiang tang (1): Hisilicon/D06: Add OemGetCpuFreq to encapsulate difference Platform/Hisilicon/D03/D03.dsc | 8 +- Platform/Hisilicon/D05/D05.dsc | 8 +- Platform/Hisilicon/D06/D06.dsc | 19 +- Platform/Hisilicon/D03/D03.fdf | 1 + Platform/Hisilicon/D05/D05.fdf | 1 + Platform/Hisilicon/D06/D06.fdf | 18 +- Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.inf | 1 + Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.inf | 2 +- Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.inf | 1 + Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.inf | 1 + Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.inf | 1 + Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.inf | 1 + Silicon/Hisilicon/Drivers/Smbios/MemorySubClassDxe/MemorySubClassDxe.inf | 1 + Silicon/Hisilicon/Drivers/Smbios/ProcessorSubClassDxe/ProcessorSubClassDxe.inf | 1 + Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf | 4 +- Silicon/Hisilicon/Drivers/VirtualEhciPciIo/VirtualEhciPciIo.inf | 1 + Silicon/Hisilicon/Hi1610/Drivers/IoInitDxe/IoInitDxe.inf | 1 + Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLib.inf | 1 - Silicon/Hisilicon/Library/BmcConfigBootLib/BmcConfigBootLib.inf | 1 + Silicon/Hisilicon/Library/I2CLib/I2CLib.inf | 1 + Silicon/Hisilicon/Library/I2CLib/I2CLibRuntime.inf | 1 + Platform/Hisilicon/D06/Include/Library/CpldD06.h | 4 + Silicon/Hisilicon/Hi1610/Include/Library/SerdesLib.h | 131 - Silicon/Hisilicon/Hi1616/Include/Library/SerdesLib.h | 86 -- Silicon/Hisilicon/Hi1620/Include/Library/SerdesLib.h | 85 -- Silicon/Hisilicon/Include/Library/IpmiCmdLib.h | 110 --- Silicon/Hisilicon/Include/Library/LpcLib.h | 113 --- Silicon/Hisilicon/Include/Library/OemAddressMapLib.h | 45 --- Silicon/Hisilicon/Include/Library/OemConfigData.h | 1 + Silicon/Hisilicon/Include/Library/OemMiscLib.h | 75 + Silicon/Hisilicon/Include/Library/PlatformSysCtrlLib.h | 112 --- Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr | 4 +- Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.c | 2 +- Platform/Hisilicon/D03/Library/OemMiscLib2P/BoardFeature2PHi1610.c | 1 - Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.c | 2 +- Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.c | 2 +- Platform/Hisilicon/D05/Library/OemMiscLibD05/BoardFeatureD05.c | 1 - Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.c | 3 +- Pl
[edk2] [PATCH edk2-platforms v3 05/18] Hisilicon/D06: Fix access variable fail issue
From: Jason Zhang BmcWdtEnable is a field of OemConfigData structure, need have runtime service attribution if use it during exit boot service Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ming Huang --- Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr | 2 +- Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr index 470e9ace3dcf..08236704fbfe 100644 --- a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr +++ b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr @@ -23,7 +23,7 @@ formset help = STRING_TOKEN(STR_OEM_CONFIG), classguid = gEfiIfrFrontPageGuid, // for MdeModule Bds. efivarstore OEM_CONFIG_DATA, -attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_NON_VOLATILE, +attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_RUNTIME_ACCESS, name = OemConfig, guid = gOemConfigGuid; diff --git a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c index 012d45bc0214..6668103af027 100644 --- a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c +++ b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c @@ -316,7 +316,7 @@ OemConfigUiLibConstructor ( Status = gRT->SetVariable ( OEM_CONFIG_NAME, &gOemConfigGuid, - EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS, + EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS, sizeof (OEM_CONFIG_DATA), &Configuration ); -- 2.9.5 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-platforms v3 01/18] Hisilicon/D0x: Remove and tidy some codes about SerdesLib
As some definitions are about OemMiscLib, so move them from
SerdesLib.h to OemMiscLib.h and drop some useless function
definitions. After doing this, some unnecessary references
can be removed for D03/D05.
SerdesLib is useless for SmbiosMiscDxe and D06, so remove it and
delete SerdesLib.h for D06.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ming Huang
---
Platform/Hisilicon/D06/D06.dsc
| 2 -
Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf
| 2 +-
Silicon/Hisilicon/Hi1610/Include/Library/SerdesLib.h
| 109
Silicon/Hisilicon/Hi1616/Include/Library/SerdesLib.h
| 64
Silicon/Hisilicon/Hi1620/Include/Library/SerdesLib.h
| 85 ---
Silicon/Hisilicon/Include/Library/OemMiscLib.h
| 75 ++
Platform/Hisilicon/D03/Library/OemMiscLib2P/BoardFeature2PHi1610.c
| 1 -
Platform/Hisilicon/D05/Library/OemMiscLibD05/BoardFeatureD05.c
| 1 -
Platform/Hisilicon/D06/Library/OemMiscLibD06/BoardFeatureD06.c
| 1 -
Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
| 1 -
Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/Type09/MiscSystemSlotDesignationFunction.c
| 2 +-
11 files changed, 77 insertions(+), 266 deletions(-)
diff --git a/Platform/Hisilicon/D06/D06.dsc b/Platform/Hisilicon/D06/D06.dsc
index 396bd03c9d24..cbbd99e4a659 100644
--- a/Platform/Hisilicon/D06/D06.dsc
+++ b/Platform/Hisilicon/D06/D06.dsc
@@ -64,8 +64,6 @@ [LibraryClasses.common]
CpldIoLib|Silicon/Hisilicon/Library/CpldIoLib/CpldIoLib.inf
- SerdesLib|Silicon/Hisilicon/Hi1620/Library/Hi1620Serdes/Hi1620SerdesLib.inf
-
TimeBaseLib|EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.inf
RealTimeClockLib|Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClockLib.inf
OemMiscLib|Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.inf
diff --git a/Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf
b/Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf
index 61cead7779b9..669e6a2d52cc 100644
--- a/Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf
+++ b/Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf
@@ -69,6 +69,7 @@ [LibraryClasses]
BaseMemoryLib
BaseLib
DebugLib
+ OemMiscLib
UefiBootServicesTableLib
UefiRuntimeServicesTableLib
UefiDriverEntryPoint
@@ -77,7 +78,6 @@ [LibraryClasses]
IpmiCmdLib
- SerdesLib
[Protocols]
gEfiSmbiosProtocolGuid # PROTOCOL ALWAYS_CONSUMED
diff --git a/Silicon/Hisilicon/Hi1610/Include/Library/SerdesLib.h
b/Silicon/Hisilicon/Hi1610/Include/Library/SerdesLib.h
index 077dd5edc847..b493dd9ac090 100755
--- a/Silicon/Hisilicon/Hi1610/Include/Library/SerdesLib.h
+++ b/Silicon/Hisilicon/Hi1610/Include/Library/SerdesLib.h
@@ -16,116 +16,7 @@
#ifndef _SERDES_LIB_H_
#define _SERDES_LIB_H_
-typedef enum {
- EmHilink0Hccs1X8 = 0,
- EmHilink0Pcie1X8 = 2,
- EmHilink0Pcie1X4Pcie2X4 = 3,
- EmHilink0Sas2X8 = 4,
- EmHilink0Hccs1X8Width16,
- EmHilink0Hccs1X8Width32,
-} HILINK0_MODE_TYPE;
-
-typedef enum {
- EmHilink1Sas2X1 = 0,
- EmHilink1Hccs0X8 = 1,
- EmHilink1Pcie0X8 = 2,
- EmHilink1Hccs0X8Width16,
- EmHilink1Hccs0X8Width32,
-} HILINK1_MODE_TYPE;
-
-typedef enum {
- EmHilink2Pcie2X8 = 0,
- EmHilink2Sas0X8 = 2,
-} HILINK2_MODE_TYPE;
-
-typedef enum {
- EmHilink5Pcie3X4 = 0,
- EmHilink5Pcie2X2Pcie3X2 = 1,
- EmHilink5Sas1X4 = 2,
-} HILINK5_MODE_TYPE;
-
-typedef enum {
- Em32coreEvbBoard = 0,
- Em16coreEvbBoard = 1,
- EmV2R1CO5Borad = 2,
- EmOtherBorad
-} BOARD_TYPE;
-
-
-typedef struct {
- HILINK0_MODE_TYPE Hilink0Mode;
- HILINK1_MODE_TYPE Hilink1Mode;
- HILINK2_MODE_TYPE Hilink2Mode;
- UINT32 Hilink3Mode;
- UINT32 Hilink4Mode;
- HILINK5_MODE_TYPE Hilink5Mode;
- UINT32 Hilink6Mode;
- UINT32 UseSsc;
-} SERDES_PARAM;
-
-
-#define SERDES_INVALID_MACRO_ID 0x
-#define SERDES_INVALID_LANE_NUM 0x
-#define SERDES_INVALID_RATE_MODE 0x
-
-typedef struct {
- UINT32 MacroId;
- UINT32 DsNum;
- UINT32 DsCfg;
-} SERDES_POLARITY_INVERT;
-
-EFI_STATUS OemGetSerdesParam (SERDES_PARAM *ParamA, SERDES_PARAM *ParamB,
UINT32 SocketId);
-extern SERDES_POLARITY_INVERT gSerdesPolarityTxDesc[];
-extern SERDES_POLARITY_INVERT gSerdesPolarityRxDesc[];
-UINT32 GetEthType(UINT8 EthChannel);
-
EFI_STATUS
EfiSerdesInitWrap (VOID);
-void SRE_SerdesEnableCTLEDFE(UINT32 macro, UINT32 lane, UINT32 ulDsCfg);
-
-//EYE test
-UINT32 serdes_eye_test(UINT32 uwMacroId, UINT32 uwDsNum, UINT32 eyemode,
UINT32 scanwindowvalue, UINT32 uwRateData);
-
-UINT32 Serdes_ReadBert(UINT32 ulMacroId , UINT32 ulDsNum);
-
-//P
[edk2] [PATCH edk2-platforms v3 07/18] Hisilicon/D06: Add more PCIe port INT-x support
Since NVMe riser width is 6*X4, need add the related
port's INT-x support to match OS driver.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ming Huang
---
Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl | 37
+++-
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
index 0f2d11bb952b..4d9d9d95be68 100644
--- a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
+++ b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
@@ -41,11 +41,21 @@ Scope(_SB)
// adding RPx INTx configure deponds on hardware board topology,
// if UEFI enables RPx, RPy, RPz... related INTx configure
// should be added
+ Package () {0x2,0,0,640}, // INT_A
+ Package () {0x2,1,0,641}, // INT_B
+ Package () {0x2,2,0,642}, // INT_C
+ Package () {0x2,3,0,643}, // INT_D
+
Package () {0x4,0,0,640}, // INT_A
Package () {0x4,1,0,641}, // INT_B
Package () {0x4,2,0,642}, // INT_C
Package () {0x4,3,0,643}, // INT_D
+ Package () {0x6,0,0,640}, // INT_A
+ Package () {0x6,1,0,641}, // INT_B
+ Package () {0x6,2,0,642}, // INT_C
+ Package () {0x6,3,0,643}, // INT_D
+
Package () {0x8,0,0,640}, // INT_A
Package () {0x8,1,0,641}, // INT_B
Package () {0x8,2,0,642}, // INT_C
@@ -56,6 +66,11 @@ Scope(_SB)
Package () {0xC,2,0,642}, // INT_C
Package () {0xC,3,0,643}, // INT_D
+ Package () {0xE,0,0,640}, // INT_A
+ Package () {0xE,1,0,641}, // INT_B
+ Package () {0xE,2,0,642}, // INT_C
+ Package () {0xE,3,0,643}, // INT_D
+
Package () {0x10,0,0,640}, // INT_A
Package () {0x10,1,0,641}, // INT_B
Package () {0x10,2,0,642}, // INT_C
@@ -759,11 +774,21 @@ Device (PCI6)
// adding RPx INTx configure deponds on hardware board topology,
// if UEFI enables RPx, RPy, RPz... related INTx configure
// should be added
+Package () {0x2,0,0,640}, // INT_A
+Package () {0x2,1,0,641}, // INT_B
+Package () {0x2,2,0,642}, // INT_C
+Package () {0x2,3,0,643}, // INT_D
+
Package () {0x4,0,0,640}, // INT_A
Package () {0x4,1,0,641}, // INT_B
Package () {0x4,2,0,642}, // INT_C
Package () {0x4,3,0,643}, // INT_D
+Package () {0x6,0,0,640}, // INT_A
+Package () {0x6,1,0,641}, // INT_B
+Package () {0x6,2,0,642}, // INT_C
+Package () {0x6,3,0,643}, // INT_D
+
Package () {0x8,0,0,640}, // INT_A
Package () {0x8,1,0,641}, // INT_B
Package () {0x8,2,0,642}, // INT_C
@@ -774,11 +799,21 @@ Device (PCI6)
Package () {0xC,2,0,642}, // INT_C
Package () {0xC,3,0,643}, // INT_D
+Package () {0xE,0,0,640}, // INT_A
+Package () {0xE,1,0,641}, // INT_B
+Package () {0xE,2,0,642}, // INT_C
+Package () {0xE,3,0,643}, // INT_D
+
Package () {0x10,0,0,640}, // INT_A
Package () {0x10,1,0,641}, // INT_B
Package () {0x10,2,0,642}, // INT_C
Package () {0x10,3,0,643}, // INT_D
- })
+
+Package () {0x12,0,0,640}, // INT_A
+Package () {0x12,1,0,641}, // INT_B
+Package () {0x12,2,0,642}, // INT_C
+Package () {0x12,3,0,643}, // INT_D
+})
Method (_CRS, 0, Serialized) { // Root complex resources, _CRS:
current resource setting
Name (RBUF, ResourceTemplate () { // Name: 19.6.87, ResourceTemplate:
19.6.111,
--
2.9.5
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-platforms v3 04/18] Hisilicon/D06: Optimize SAS driver for reducing boot time
SAS controller is always existed, so accessing SAS register don't depend on PciBusDxe (pci enumeration). Move the SAS module early in D06.fdf for dispatching SAS driver early. This can avoid wait in BDS normally and reduce boot time. This change is only valid after the update to SasDriverDxe in edk2-non-osi has been applied. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ming Huang --- Platform/Hisilicon/D06/D06.fdf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Platform/Hisilicon/D06/D06.fdf b/Platform/Hisilicon/D06/D06.fdf index a937660a09e2..d495ad7f264c 100644 --- a/Platform/Hisilicon/D06/D06.fdf +++ b/Platform/Hisilicon/D06/D06.fdf @@ -165,6 +165,7 @@ [FV.FvMain] INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf INF Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.inf + INF Platform/Hisilicon/D06/Drivers/Sas/SasDxeDriver.inf # # PI DXE Drivers producing Architectural Protocols (EFI Services) # @@ -296,7 +297,6 @@ [FV.FvMain] # INF Platform/Hisilicon/D06/Drivers/Sm750Dxe/UefiSmi.inf INF MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf - INF Platform/Hisilicon/D06/Drivers/Sas/SasDxeDriver.inf INF MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf INF MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf INF MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf -- 2.9.5 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-platforms v3 06/18] Hisilicon/D06: Drop the leading 0 (0x0 -> 0x)
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ming Huang
---
Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl | 24
++--
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
index 27fde2e09bfe..0f2d11bb952b 100644
--- a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
+++ b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
@@ -759,20 +759,20 @@ Device (PCI6)
// adding RPx INTx configure deponds on hardware board topology,
// if UEFI enables RPx, RPy, RPz... related INTx configure
// should be added
-Package () {0x04,0,0,640}, // INT_A
-Package () {0x04,1,0,641}, // INT_B
-Package () {0x04,2,0,642}, // INT_C
-Package () {0x04,3,0,643}, // INT_D
+Package () {0x4,0,0,640}, // INT_A
+Package () {0x4,1,0,641}, // INT_B
+Package () {0x4,2,0,642}, // INT_C
+Package () {0x4,3,0,643}, // INT_D
-Package () {0x08,0,0,640}, // INT_A
-Package () {0x08,1,0,641}, // INT_B
-Package () {0x08,2,0,642}, // INT_C
-Package () {0x08,3,0,643}, // INT_D
+Package () {0x8,0,0,640}, // INT_A
+Package () {0x8,1,0,641}, // INT_B
+Package () {0x8,2,0,642}, // INT_C
+Package () {0x8,3,0,643}, // INT_D
-Package () {0x0C,0,0,640}, // INT_A
-Package () {0x0C,1,0,641}, // INT_B
-Package () {0x0C,2,0,642}, // INT_C
-Package () {0x0C,3,0,643}, // INT_D
+Package () {0xC,0,0,640}, // INT_A
+Package () {0xC,1,0,641}, // INT_B
+Package () {0xC,2,0,642}, // INT_C
+Package () {0xC,3,0,643}, // INT_D
Package () {0x10,0,0,640}, // INT_A
Package () {0x10,1,0,641}, // INT_B
--
2.9.5
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-platforms v3 08/18] Hisilicon/D06: Add OemGetCpuFreq to encapsulate difference
From: xingjiang tang
Implementation OemGetCpuFreq() to get cpu frequency from cpld to
encapsulate project difference, for some projects don't support
get cpu frequency by this way.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ming Huang
---
Platform/Hisilicon/D06/Include/Library/CpldD06.h | 4
Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c | 16
2 files changed, 20 insertions(+)
diff --git a/Platform/Hisilicon/D06/Include/Library/CpldD06.h
b/Platform/Hisilicon/D06/Include/Library/CpldD06.h
index ec9b49f4e70d..8eb333de529c 100644
--- a/Platform/Hisilicon/D06/Include/Library/CpldD06.h
+++ b/Platform/Hisilicon/D06/Include/Library/CpldD06.h
@@ -36,4 +36,8 @@
#define CPLD_X8_X8_X8_BOARD_ID0x92
#define CPLD_X16_X8_BOARD_ID 0x93
+#define CPLD_CLOCK_FLAG 0xFD
+#define CPLD_BOM_VER_FLAG0x0B
+#define CPLD_BOARD_REVISION_4TH 0x4
+
#endif /* __CPLDD06_H__ */
diff --git a/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
b/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
index c5cb77696031..c8f71ecf890a 100644
--- a/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
+++ b/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
@@ -206,3 +206,19 @@ OemIsNeedDisableExpanderBuffer (
{
return TRUE;
}
+
+UINTN OemGetCpuFreq (UINT8 Socket)
+{
+ UINT8 BoardRevision;
+
+ BoardRevision = MmioRead8 (CPLD_BASE_ADDRESS + CPLD_BOM_VER_FLAG);
+
+ // Board revision 4 and higher run at 2.5GHz
+ // Earlier revisions run at 2GHz
+ if (BoardRevision >= CPLD_BOARD_REVISION_4TH) {
+return 25;
+ } else {
+return 20;
+ }
+}
+
--
2.9.5
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-platforms v3 03/18] Hisilicon/D0x: Add DriverHealthManagerDxe
DriverHealthManagerDxe Collect driver health form of third party
drivers to repair no healthy card.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ming Huang
Reviewed-by: Leif Lindholm
---
Platform/Hisilicon/D03/D03.dsc | 1 +
Platform/Hisilicon/D05/D05.dsc | 1 +
Platform/Hisilicon/D06/D06.dsc | 1 +
Platform/Hisilicon/D03/D03.fdf | 1 +
Platform/Hisilicon/D05/D05.fdf | 1 +
Platform/Hisilicon/D06/D06.fdf | 1 +
6 files changed, 6 insertions(+)
diff --git a/Platform/Hisilicon/D03/D03.dsc b/Platform/Hisilicon/D03/D03.dsc
index 3f59be22ec8e..fe443dd929ad 100644
--- a/Platform/Hisilicon/D03/D03.dsc
+++ b/Platform/Hisilicon/D03/D03.dsc
@@ -492,6 +492,7 @@ [Components.common]
MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
+ MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareUpdateDxe.inf {
diff --git a/Platform/Hisilicon/D05/D05.dsc b/Platform/Hisilicon/D05/D05.dsc
index 25db1c38d287..0c4f21fbe056 100644
--- a/Platform/Hisilicon/D05/D05.dsc
+++ b/Platform/Hisilicon/D05/D05.dsc
@@ -638,6 +638,7 @@ [Components.common]
MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
+ MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareUpdateDxe.inf {
diff --git a/Platform/Hisilicon/D06/D06.dsc b/Platform/Hisilicon/D06/D06.dsc
index cbbd99e4a659..6d581337f199 100644
--- a/Platform/Hisilicon/D06/D06.dsc
+++ b/Platform/Hisilicon/D06/D06.dsc
@@ -435,6 +435,7 @@ [Components.common]
Silicon/Hisilicon/Hi1620/Drivers/Pl011DebugSerialPortInitDxe/Pl011DebugSerialPortInitDxe.inf
MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
+ MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareUpdateDxe.inf {
diff --git a/Platform/Hisilicon/D03/D03.fdf b/Platform/Hisilicon/D03/D03.fdf
index f453f9e46321..3f07b2e57778 100644
--- a/Platform/Hisilicon/D03/D03.fdf
+++ b/Platform/Hisilicon/D03/D03.fdf
@@ -295,6 +295,7 @@ [FV.FvMain]
INF MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
+ INF MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
[FV.FVMAIN_COMPACT]
diff --git a/Platform/Hisilicon/D05/D05.fdf b/Platform/Hisilicon/D05/D05.fdf
index 85dd791564a4..9632aea4b00e 100644
--- a/Platform/Hisilicon/D05/D05.fdf
+++ b/Platform/Hisilicon/D05/D05.fdf
@@ -314,6 +314,7 @@ [FV.FvMain]
INF MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
+ INF MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
[FV.FVMAIN_COMPACT]
diff --git a/Platform/Hisilicon/D06/D06.fdf b/Platform/Hisilicon/D06/D06.fdf
index fda29ab322e9..a937660a09e2 100644
--- a/Platform/Hisilicon/D06/D06.fdf
+++ b/Platform/Hisilicon/D06/D06.fdf
@@ -319,6 +319,7 @@ [FV.FvMain]
INF MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
+ INF MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
[FV.FVMAIN_COMPACT]
--
2.9.5
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-platforms v3 02/18] Hisilicon/D0x: Delete some header files
As some interfaces exposed only by implementations in edk2-non-osi, so delete corresponding header files and modify code to make build. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ming Huang --- Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.inf | 1 + Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.inf | 2 +- Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.inf | 1 + Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.inf | 1 + Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.inf | 1 + Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.inf | 1 + Silicon/Hisilicon/Drivers/Smbios/MemorySubClassDxe/MemorySubClassDxe.inf | 1 + Silicon/Hisilicon/Drivers/Smbios/ProcessorSubClassDxe/ProcessorSubClassDxe.inf | 1 + Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf | 2 +- Silicon/Hisilicon/Drivers/VirtualEhciPciIo/VirtualEhciPciIo.inf | 1 + Silicon/Hisilicon/Hi1610/Drivers/IoInitDxe/IoInitDxe.inf | 1 + Silicon/Hisilicon/Library/BmcConfigBootLib/BmcConfigBootLib.inf | 1 + Silicon/Hisilicon/Library/I2CLib/I2CLib.inf | 1 + Silicon/Hisilicon/Library/I2CLib/I2CLibRuntime.inf | 1 + Silicon/Hisilicon/Hi1610/Include/Library/SerdesLib.h | 22 Silicon/Hisilicon/Hi1616/Include/Library/SerdesLib.h | 22 Silicon/Hisilicon/Include/Library/IpmiCmdLib.h | 110 --- Silicon/Hisilicon/Include/Library/LpcLib.h | 113 Silicon/Hisilicon/Include/Library/OemAddressMapLib.h | 45 Silicon/Hisilicon/Include/Library/PlatformSysCtrlLib.h | 112 --- 20 files changed, 14 insertions(+), 426 deletions(-) diff --git a/Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.inf b/Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.inf index c65cf7b6dd9f..90e40ae2b393 100644 --- a/Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.inf +++ b/Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.inf @@ -30,6 +30,7 @@ [Packages] MdeModulePkg/MdeModulePkg.dec ArmPkg/ArmPkg.dec + Silicon/Hisilicon/HisiliconNonOsi.dec Silicon/Hisilicon/HisiPkg.dec [LibraryClasses] diff --git a/Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.inf b/Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.inf index 0fa7fdf80fa8..c0195b2fa9cf 100644 --- a/Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.inf +++ b/Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.inf @@ -30,7 +30,7 @@ [Packages] MdePkg/MdePkg.dec MdeModulePkg/MdeModulePkg.dec ArmPkg/ArmPkg.dec - + Silicon/Hisilicon/HisiliconNonOsi.dec Silicon/Hisilicon/HisiPkg.dec [LibraryClasses] diff --git a/Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.inf b/Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.inf index 0f6b68d4c88d..e82c9204d5d6 100644 --- a/Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.inf +++ b/Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.inf @@ -29,6 +29,7 @@ [Packages] ArmPkg/ArmPkg.dec MdePkg/MdePkg.dec MdeModulePkg/MdeModulePkg.dec + Silicon/Hisilicon/HisiliconNonOsi.dec Silicon/Hisilicon/HisiPkg.dec [LibraryClasses] diff --git a/Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.inf b/Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.inf index 022c3e940a31..7ec577530610 100644 --- a/Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.inf +++ b/Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.inf @@ -30,6 +30,7 @@ [Packages] ArmPkg/ArmPkg.dec MdeModulePkg/MdeModulePkg.dec MdePkg/MdePkg.dec + Silicon/Hisilicon/HisiliconNonOsi.dec Silicon/Hisilicon/HisiPkg.dec [LibraryClasses] diff --git a/Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.inf b/Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.inf index 8296ee02de4e..715a4efadde8 100644 --- a/Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.inf +++ b/Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.inf @@ -29,6 +29,7 @@ [Packages] ArmPkg/ArmPkg.dec MdeModulePkg/MdeModulePkg.dec MdePkg/MdePkg.dec + Silicon/Hisilicon/HisiliconNonOsi.dec Silicon/Hisilicon/HisiPkg.dec [LibraryClasses] diff --git a/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.inf b/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.inf index 75c5054bbfd1..9bc6eb549c41 100644 --- a/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.inf +++ b/Platform/Hisilicon/D06/Library/OemMi
[edk2] [PATCH edk2-platforms v3 10/18] Hisilicon/D06: Use HCCS speed with 2.6G
Follow chip team suggestion, HCCS(Huawei Cache-Coherent System)
may be unstable while speed is 3.0G, so use 2.6G to avoid some
unstable stress issue.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ming Huang
---
Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c | 8
1 file changed, 8 insertions(+)
diff --git a/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
b/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
index c8f71ecf890a..758157525f40 100644
--- a/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
+++ b/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
@@ -222,3 +222,11 @@ UINTN OemGetCpuFreq (UINT8 Socket)
}
}
+UINTN
+OemGetHccsFreq (
+ VOID
+ )
+{
+ return HCCS_PLL_VALUE_2600;
+}
+
--
2.9.5
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-platforms v3 14/18] Hisilicon/D06: Use new flash layout
In new flash layout, BIOS fd change from offset 1M to 8M in 16M spi flash. Use the new CustomData.Fv which indicate the offset of fd and which flash area can be updated for BMC. This patch is relative with patch "Use new flash layout" in edk2-non-osi. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ming Huang --- Platform/Hisilicon/D06/D06.fdf | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Platform/Hisilicon/D06/D06.fdf b/Platform/Hisilicon/D06/D06.fdf index d495ad7f264c..f72b513352fb 100644 --- a/Platform/Hisilicon/D06/D06.fdf +++ b/Platform/Hisilicon/D06/D06.fdf @@ -29,7 +29,7 @@ [DEFINES] [FD.D06] -BaseAddress = 0x20410|gArmTokenSpaceGuid.PcdFdBaseAddress # The base address of the Firmware in NOR Flash. +BaseAddress = 0x20480|gArmTokenSpaceGuid.PcdFdBaseAddress # The base address of the Firmware in NOR Flash. Size = 0x0040|gArmTokenSpaceGuid.PcdFdSize # The size in bytes of the FLASH Device ErasePolarity = 1 @@ -124,7 +124,7 @@ [FD.D06] 0x003E|0x0001 0x003F|0x0001 -FILE = Platform/Hisilicon/D0x-CustomData.Fv +FILE = Platform/Hisilicon/D06/CustomData.Fv # -- 2.9.5 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-platforms v3 09/18] Hisilicon/D0x: Rename StartupAp() function
As suggestion of community, 'AP' is a bit unfortunate to use in EDK2
context. PI specifies 'BSP' for Boot-strap Processor, as the one
executing all of the EDK2 code. It then uses 'AP' to refer to
Additional Processors, which can be assigned tasks using the
EFI_MP_SERVICES_PROTOCOL. In a TianoCore context, this should be 'BSP'.
So, Rename StartupAp() to StartUpBSP.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ming Huang
Reviewed-by: Leif Lindholm
---
Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.c | 2 +-
Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.c | 2 +-
Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.c | 2 +-
Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.c | 3 ++-
Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.c | 2 +-
5 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.c
b/Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.c
index 97cf6b8d8757..dacd9e871faf 100644
--- a/Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.c
+++ b/Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.c
@@ -83,7 +83,7 @@ void QResetAp(VOID)
//SCCL A
if (!PcdGet64 (PcdTrustedFirmwareEnable))
{
-StartupAp();
+StartUpBSP ();
}
}
diff --git a/Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.c
b/Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.c
index b57fdfa68e45..c8a9da73bbca 100644
--- a/Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.c
+++ b/Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.c
@@ -133,7 +133,7 @@ VOID CoreSelectBoot(VOID)
{
if (!PcdGet64 (PcdTrustedFirmwareEnable))
{
-StartupAp ();
+StartUpBSP ();
}
return;
diff --git a/Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.c
b/Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.c
index 76a055cbe980..b374347e5c4d 100644
--- a/Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.c
+++ b/Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.c
@@ -35,7 +35,7 @@ QResetAp (
(VOID)WriteBackInvalidateDataCacheRange((VOID *)
FixedPcdGet64(PcdMailBoxAddress), 8);
if (!PcdGet64 (PcdTrustedFirmwareEnable)) {
-StartupAp();
+StartUpBSP ();
}
}
diff --git a/Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.c
b/Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.c
index 4c4c944dbead..a1458da7f0a3 100644
--- a/Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.c
+++ b/Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.c
@@ -96,7 +96,7 @@ UINTN OemGetDimmSlot(UINTN Socket, UINTN Channel)
VOID CoreSelectBoot(VOID)
{
if (!PcdGet64 (PcdTrustedFirmwareEnable)) {
- StartupAp ();
+ StartUpBSP ();
}
return;
@@ -128,3 +128,4 @@ BOOLEAN OemIsNeedDisableExpanderBuffer(VOID)
{
return TRUE;
}
+
diff --git a/Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.c
b/Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.c
index 0790f7941ae7..a8261d370626 100644
--- a/Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.c
+++ b/Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.c
@@ -78,7 +78,7 @@ QResetAp (
//SCCL A
if (!PcdGet64 (PcdTrustedFirmwareEnable)) {
-StartupAp ();
+StartUpBSP ();
}
}
--
2.9.5
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-platforms v3 13/18] Hisilicon/D06: Add Setup Item "Support DPC" and delete some PCIe menus
Add setup item "Support DPC" to enable or disable PCIe DPC
(Downstream Port Containment).
The pcie menu is suppressed for original code as these menus
are not ready. This patch remove the suppression for pcie menu,
so delete these menus for now.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ming Huang
---
Silicon/Hisilicon/Include/Library/OemConfigData.h | 1 +
Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr | 2 -
Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c | 4 +
Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/PcieConfig.hfr| 197
+---
Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/PcieConfigStrings.uni | 3 +-
5 files changed, 10 insertions(+), 197 deletions(-)
diff --git a/Silicon/Hisilicon/Include/Library/OemConfigData.h
b/Silicon/Hisilicon/Include/Library/OemConfigData.h
index f120e3123c83..c0097d0829f0 100644
--- a/Silicon/Hisilicon/Include/Library/OemConfigData.h
+++ b/Silicon/Hisilicon/Include/Library/OemConfigData.h
@@ -49,6 +49,7 @@ typedef struct {
UINT8 OSWdtAction;
/*PCIe Config*/
UINT8 PcieSRIOVSupport;
+ UINT8 PcieDPCSupport;
UINT8 PciePort[PCIE_MAX_TOTAL_PORTS];
UINT8 PcieLinkSpeedPort[PCIE_MAX_TOTAL_PORTS];
UINT8 PcieLinkDeEmphasisPort[PCIE_MAX_TOTAL_PORTS];
diff --git a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr
b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr
index 08236704fbfe..93ccb99bdc67 100644
--- a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr
+++ b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr
@@ -62,11 +62,9 @@ formset
prompt = STRING_TOKEN(STR_IBMC_CONFIG_FORM_TITLE),
help = STRING_TOKEN(STR_IBMC_CONFIG_FORM_HELP);
-suppressif TRUE;
goto PCIE_CONFIG_FORM_ID,
prompt = STRING_TOKEN(STR_PCIE_CONFIG_FORM_TITLE),
help= STRING_TOKEN(STR_PCIE_CONFIG_FORM_HELP);
-endif;
goto MISC_CONFIG_FORM_ID,
prompt = STRING_TOKEN(STR_MISC_CONFIG_FORM_TITLE),
diff --git a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c
b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c
index 6668103af027..be4ce8820f73 100644
--- a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c
+++ b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c
@@ -290,6 +290,10 @@ OemConfigUiLibConstructor (
Configuration.OSWdtTimeout = 5;
Configuration.OSWdtAction = 1;
//
+ //Set the default value of the PCIe option
+ //
+ Configuration.PcieDPCSupport = 0;
+ //
//Set the default value of the Misc option
//
Configuration.EnableSmmu = 1;
diff --git a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/PcieConfig.hfr
b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/PcieConfig.hfr
index 7cf7cdd29ba2..c65907fe846e 100644
--- a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/PcieConfig.hfr
+++ b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/PcieConfig.hfr
@@ -17,203 +17,12 @@
form formid = PCIE_CONFIG_FORM_ID,
title = STRING_TOKEN (STR_PCIE_CONFIG_FORM_TITLE);
- goto VFR_FORMID_PCIE_SOCKET0,
-prompt = STRING_TOKEN (STR_PCIE_CPU_0_PROMPT),
-help= STRING_TOKEN (STR_PCIE_CPU_PROMPT_HELP);
-
- goto VFR_FORMID_PCIE_SOCKET1,
-prompt = STRING_TOKEN (STR_PCIE_CPU_1_PROMPT),
-help= STRING_TOKEN (STR_PCIE_CPU_PROMPT_HELP);
-
- oneof varid = OEM_CONFIG_DATA.PcieSRIOVSupport,
-prompt = STRING_TOKEN (STR_SRIOV_SUPPORT_PROMPT),
-help = STRING_TOKEN (STR_SRIOV_SUPPORT_HELP),
+ oneof varid = OEM_CONFIG_DATA.PcieDPCSupport,
+prompt = STRING_TOKEN (STR_DPC_SUPPORT_PROMPT),
+help = STRING_TOKEN (STR_DPC_SUPPORT_HELP),
option text = STRING_TOKEN (STR_DISABLE), value = 0, flags =
MANUFACTURING | DEFAULT | RESET_REQUIRED;
option text = STRING_TOKEN (STR_ENABLE), value = 1, flags =
RESET_REQUIRED;
endoneof;
endform;
-form formid = VFR_FORMID_PCIE_SOCKET0,
- title = STRING_TOKEN(STR_PCIE_CPU_0_PROMPT);
-
- goto VFR_FORMID_PCIE_PORT2,
-prompt = STRING_TOKEN(STR_PCIE_PORT_2_PROMPT),
-help= STRING_TOKEN(STR_PCIE_PORT_PROMPT_HELP);
-
- goto VFR_FORMID_PCIE_PORT4,
-prompt = STRING_TOKEN(STR_PCIE_PORT_4_PROMPT),
-help= STRING_TOKEN(STR_PCIE_PORT_PROMPT_HELP);
-
- goto VFR_FORMID_PCIE_PORT5,
-prompt = STRING_TOKEN(STR_PCIE_PORT_5_PROMPT),
-help= STRING_TOKEN(STR_PCIE_PORT_PROMPT_HELP);
-
- goto VFR_FORMID_PCIE_PORT6,
-prompt = STRING_TOKEN(STR_PCIE_PORT_6_PROMPT),
-help= STRING_TOKEN(STR_PCIE_PORT_PROMPT_HELP);
-
- goto VFR_FORMID_PCIE_PORT7,
-prompt = STRING_TOKEN(STR_PCIE_PORT_7_PROMPT),
-help= STRING_TOKEN(STR_PCIE_PORT_PROMPT_HELP);
-
-endform;
-
-form formid = VFR_FORMID_PCIE_SOCKET1,
- title = STRING_TOKEN(STR_PCIE_CPU_1_PROMPT);
- goto VFR_FORMID_PCIE_PORT10,
-prompt = STRIN
[edk2] [PATCH edk2-platforms v3 11/18] Hisilicon/D06: Add PCI_OSC_SUPPORT
Add PCI_OSC_SUPPORT for remaining host bridges to remove fail
output in kernel:
[ 103.478893] acpi PNP0A08:01: _OSC failed (AE_NOT_FOUND);
Add PCI_OSC_SUPPORT_HOTPLUG to rewrite _OSC of PCI0 and PCI6.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ming Huang
---
Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl | 200
+++-
1 file changed, 106 insertions(+), 94 deletions(-)
diff --git a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
index 4d9d9d95be68..6dc380f27fa2 100644
--- a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
+++ b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
@@ -17,6 +17,90 @@
**/
//#include "ArmPlatform.h"
+
+/*
+ See ACPI 6.1 Spec, 6.2.11, PCI Firmware Spec 3.0, 4.5
+*/
+#define PCI_OSC_SUPPORT() \
+ Name(SUPP, Zero) /* PCI _OSC Support Field value */ \
+ Name(CTRL, Zero) /* PCI _OSC Control Field value */ \
+ Method(_OSC,4) { \
+If(LEqual(Arg0,ToUUID("33DB4D5B-1FF7-401C-9657-7441C03DD766"))) { \
+ /* Create DWord-adressable fields from the Capabilities Buffer */ \
+ CreateDWordField(Arg3,0,CDW1) \
+ CreateDWordField(Arg3,4,CDW2) \
+ CreateDWordField(Arg3,8,CDW3) \
+ /* Save Capabilities DWord2 & 3 */ \
+ Store(CDW2,SUPP) \
+ Store(CDW3,CTRL) \
+ /* Only allow native hot plug control if OS supports: */ \
+ /* ASPM */ \
+ /* Clock PM */ \
+ /* MSI/MSI-X */ \
+ If(LNotEqual(And(SUPP, 0x16), 0x16)) { \
+And(CTRL,0x1E,CTRL) \
+ }\
+ \
+ /* Do not allow native PME, AER */ \
+ /* Never allow SHPC (no SHPC controller in this system)*/ \
+ And(CTRL,0x10,CTRL) \
+ If(LNotEqual(Arg1,One)) { /* Unknown revision */ \
+Or(CDW1,0x08,CDW1) \
+ } \
+ \
+ If(LNotEqual(CDW3,CTRL)) { /* Capabilities bits were masked */ \
+Or(CDW1,0x10,CDW1) \
+ } \
+ \
+ /* Update DWORD3 in the buffer */ \
+ Store(CTRL,CDW3) \
+ Return(Arg3) \
+} Else { \
+ Or(CDW1,4,CDW1) /* Unrecognized UUID */ \
+ Return(Arg3) \
+} \
+ } // End _OSC
+
+#define PCI_OSC_SUPPORT_HOTPLUG() \
+ Name(SUPP, Zero) /* PCI _OSC Support Field value */ \
+ Name(CTRL, Zero) /* PCI _OSC Control Field value */ \
+ Method(_OSC,4) { \
+If(LEqual(Arg0,ToUUID("33DB4D5B-1FF7-401C-9657-7441C03DD766"))) { \
+ /* Create DWord-adressable fields from the Capabilities Buffer */ \
+ CreateDWordField(Arg3,0,CDW1) \
+ CreateDWordField(Arg3,4,CDW2) \
+ CreateDWordField(Arg3,8,CDW3) \
+ /* Save Capabilities DWord2 & 3 */ \
+ Store(CDW2,SUPP) \
+ Store(CDW3,CTRL) \
+ /* Only allow native hot plug control if OS supports: */ \
+ /* ASPM */ \
+ /* Clock PM */ \
+ /* MSI/MSI-X */ \
+ If(LNotEqual(And(SUPP, 0x16), 0x16)) { \
+And(CTRL,0x1E,CTRL) \
+ }\
+ \
+ /* Always allow native PME, AER (no dependencies) */ \
+ /* Never allow SHPC (no SHPC controller in this system)*/ \
+ And(CTRL,0x1D,CTRL) \
+ If(LNotEqual(Arg1,One)) { /* Unknown revision */ \
+Or(CDW1,0x08,CDW1) \
+ } \
+ \
+ If(LNotEqual(CDW3,CTRL)) { /* Capabilities bits were masked */ \
+Or(CDW1,0x10,CDW1) \
+ } \
+ \
+ /* Update DWORD3 in the buffer */ \
+ Store(CTRL,CDW3) \
+ Return(Arg3) \
+} Else { \
+ Or(CDW1,4,CDW1) /* Unrecognized UUID */ \
+ Return(Arg3) \
+} \
+ } // End _OSC
+
Scope(_SB)
{
Device (PCI0)
@@ -139,53 +223,7 @@ Scope(_SB)
Return (RBUF)
}// Method(_CRS), this method
return RBUF!
- //
- // OS Control Handoff
- //
- Name(SUPP, Zero) // PCI _OSC Support Field value
- Name(CTRL, Zero) // PCI _OSC Control Field value
-
- Method(_OSC,4) {
-// Check for proper UUID
-If(LEqual(Arg0,ToUUID("33DB4D5B-1FF7-401C-9657-7441C03DD766"))) {
- // Create DWord-adressable fields from the Capabilities Buffer
- CreateDWordField(Arg3,0,CDW1)
- CreateDWordField(Arg3,4,CDW2)
- CreateDWordField(Arg3,8,CDW3)
-
- // Save Capabilities DWord2 & 3
- Store(CDW2,SUPP)
- Store(CDW3,CTRL)
-
- // Only allow native hot plug control if OS supports:
- // ASPM
- // Clock PM
- // MSI/MSI-X
- If(LNotEqual(And(SUPP, 0x16), 0x16)) {
-And(CTRL,0x1E,CTRL) // Mask bit 0 (and undefined bits)
- }
-
- // Always allow native PME, AER (no dependencies)
-
- // Never allow SHPC (no SHPC controller in this system)
- And(CTRL,0x1D,CTRL)
-
- If(LNotEqual(Arg1,One)) { // Unknown revision
-Or(CDW1,0x08,CDW1)
- }
-
- If(LNotEqual(CDW3,CTRL)) { // Capabilities bits were masked
-Or(CDW1,0x10,CDW1)
- }
-
- // Update DWORD3 in the buffer
- Store(CTRL,CDW3)
- Return(Arg3)
-} Else {
- Or(CDW1,4,CDW1) // Unrecognized
[edk2] [PATCH edk2-platforms v3 15/18] Hisilicon/D06: Remove SECURE_BOOT_ENABLE definition
As secure boot is not ready, remove SECURE_BOOT_ENABLE and
relative code.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ming Huang
Reviewed-by: Leif Lindholm
---
Platform/Hisilicon/D06/D06.dsc | 12
Platform/Hisilicon/D06/D06.fdf | 11 ---
2 files changed, 23 deletions(-)
diff --git a/Platform/Hisilicon/D06/D06.dsc b/Platform/Hisilicon/D06/D06.dsc
index 6d581337f199..a3a01bfb1e23 100644
--- a/Platform/Hisilicon/D06/D06.dsc
+++ b/Platform/Hisilicon/D06/D06.dsc
@@ -30,7 +30,6 @@ [Defines]
FLASH_DEFINITION =
Platform/Hisilicon/$(PLATFORM_NAME)/$(PLATFORM_NAME).fdf
DEFINE NETWORK_IP6_ENABLE = FALSE
DEFINE HTTP_BOOT_ENABLE= FALSE
- DEFINE SECURE_BOOT_ENABLE = FALSE
!include Silicon/Hisilicon/Hisilicon.dsc.inc
@@ -87,9 +86,6 @@ [LibraryClasses.common]
LpcLib|Silicon/Hisilicon/Hi1620/Library/LpcLibHi1620/LpcLib.inf
SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
OemNicLib|Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.inf
-!if $(SECURE_BOOT_ENABLE) == TRUE
- FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
-!endif
PciExpressLib|MdePkg/Library/BasePciExpressLib/BasePciExpressLib.inf
PciPlatformLib|Silicon/Hisilicon/Hi1620/Library/Hi1620PciPlatformLib/Hi1620PciPlatformLib.inf
@@ -290,15 +286,7 @@ [Components.common]
MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
Platform/Hisilicon/D06/Drivers/OemNicConfig2PHi1620/OemNicConfig2P.inf
-!if $(SECURE_BOOT_ENABLE) == TRUE
- MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
-
-
NULL|SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf
- }
- SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
-!else
MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
-!endif
Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.inf
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
diff --git a/Platform/Hisilicon/D06/D06.fdf b/Platform/Hisilicon/D06/D06.fdf
index f72b513352fb..e402628a1b35 100644
--- a/Platform/Hisilicon/D06/D06.fdf
+++ b/Platform/Hisilicon/D06/D06.fdf
@@ -88,17 +88,10 @@ [FD.D06]
#Blockmap[1]: End
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
## This is the VARIABLE_STORE_HEADER
-!if $(SECURE_BOOT_ENABLE) == TRUE
- #Signature: gEfiAuthenticatedVariableGuid =
- # { 0xaaf32c78, 0x947b, 0x439a, { 0xa1, 0x80, 0x2e, 0x14, 0x4e, 0xc3, 0x77,
0x92 }}
- 0x78, 0x2c, 0xf3, 0xaa, 0x7b, 0x94, 0x9a, 0x43,
- 0xa1, 0x80, 0x2e, 0x14, 0x4e, 0xc3, 0x77, 0x92,
-!else
#Signature: gEfiVariableGuid =
# { 0xddcf3616, 0x3275, 0x4164, { 0x98, 0xb6, 0xfe, 0x85, 0x70, 0x7f, 0xfe,
0x7d }}
0x16, 0x36, 0xcf, 0xdd, 0x75, 0x32, 0x64, 0x41,
0x98, 0xb6, 0xfe, 0x85, 0x70, 0x7f, 0xfe, 0x7d,
-!endif
#Size: 0xe000 (gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize)
- 0x48 (size of EFI_FIRMWARE_VOLUME_HEADER) = 0xdFB8
0xB8, 0xdF, 0x00, 0x00,
#FORMATTED: 0x5A #HEALTHY: 0xFE #Reserved: UINT16 #Reserved1: UINT32
@@ -183,10 +176,6 @@ [FV.FvMain]
INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
INF
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
-!if $(SECURE_BOOT_ENABLE) == TRUE
- INF
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
-!endif
-
INF MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
INF EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
INF EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf
--
2.9.5
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-platforms v3 16/18] Hisilicon/D0x: Remove SP805 watchdog pcd
SP805 watchdog is no used for D0x, so remove it. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ming Huang Reviewed-by: Leif Lindholm --- Platform/Hisilicon/D03/D03.dsc | 3 --- Platform/Hisilicon/D05/D05.dsc | 3 --- Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLib.inf | 1 - 3 files changed, 7 deletions(-) diff --git a/Platform/Hisilicon/D03/D03.dsc b/Platform/Hisilicon/D03/D03.dsc index fe443dd929ad..35b54f8c83be 100644 --- a/Platform/Hisilicon/D03/D03.dsc +++ b/Platform/Hisilicon/D03/D03.dsc @@ -149,9 +149,6 @@ [PcdsFixedAtBuild.common] gHisiTokenSpaceGuid.PcdPcieRootBridgeMask|0x7 # bit0:HB0RB0,bit1:HB0RB1,bit2:HB0RB2,bit3:HB0RB3,bit4:HB1RB0,bit5:HB1RB1,bit6:HB1RB2,bit7:HB1RB3 - ## SP805 Watchdog - Motherboard Watchdog - gArmPlatformTokenSpaceGuid.PcdSP805WatchdogBase|0x601e - ## Serial Terminal gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x2F8 gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|115200 diff --git a/Platform/Hisilicon/D05/D05.dsc b/Platform/Hisilicon/D05/D05.dsc index 0c4f21fbe056..49bd5b37ea34 100644 --- a/Platform/Hisilicon/D05/D05.dsc +++ b/Platform/Hisilicon/D05/D05.dsc @@ -163,9 +163,6 @@ [PcdsFixedAtBuild.common] gHisiTokenSpaceGuid.PcdPcieRootBridgeMask2P|0x34F4 # bit0:HB0RB0,bit1:HB0RB1,bit2:HB0RB2,bit3:HB0RB3,bit4:HB0RB4,bit5:HB0RB5,bit6:HB0RB6,bit7:HB0RB7 # bit8:HB1RB0,bit9:HB1RB1,bit10:HB1RB2,bit11:HB1RB3,bit12:HB1RB4,bit13:HB1RB5,bit14:HB1RB6,bit14:HB1RB15 - ## SP805 Watchdog - Motherboard Watchdog - gArmPlatformTokenSpaceGuid.PcdSP805WatchdogBase|0x601e - ## Serial Terminal gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x602B gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|115200 diff --git a/Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLib.inf b/Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLib.inf index 3563df6e10d1..4ce5f5fea1f3 100644 --- a/Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLib.inf +++ b/Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLib.inf @@ -61,5 +61,4 @@ [FixedPcd] gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase gHisiTokenSpaceGuid.PcdSysControlBaseAddress gHisiTokenSpaceGuid.PcdPeriSubctrlAddress - gArmPlatformTokenSpaceGuid.PcdSP805WatchdogBase -- 2.9.5 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-platforms v3 18/18] Hisilicon/D0x: Modify version to 19.02
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ming Huang Reviewed-by: Leif Lindholm --- Platform/Hisilicon/D03/D03.dsc | 4 ++-- Platform/Hisilicon/D05/D05.dsc | 4 ++-- Platform/Hisilicon/D06/D06.dsc | 4 ++-- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/Platform/Hisilicon/D03/D03.dsc b/Platform/Hisilicon/D03/D03.dsc index 35b54f8c83be..07ff461277df 100644 --- a/Platform/Hisilicon/D03/D03.dsc +++ b/Platform/Hisilicon/D03/D03.dsc @@ -171,12 +171,12 @@ [PcdsFixedAtBuild.common] !ifdef $(FIRMWARE_VER) gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"$(FIRMWARE_VER)" !else -gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"Development build 18.08 for Hisilicon D03" +gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"Development build 19.02 for Hisilicon D03" !endif gHisiTokenSpaceGuid.PcdBiosVersionString|L"10.01.01T18" - gHisiTokenSpaceGuid.PcdBiosVersionForBmc|L"1.12" + gHisiTokenSpaceGuid.PcdBiosVersionForBmc|L"19.02" gHisiTokenSpaceGuid.PcdSystemProductName|L"D03" gHisiTokenSpaceGuid.PcdSystemVersion|L"Estuary" diff --git a/Platform/Hisilicon/D05/D05.dsc b/Platform/Hisilicon/D05/D05.dsc index 49bd5b37ea34..70b044c7e33a 100644 --- a/Platform/Hisilicon/D05/D05.dsc +++ b/Platform/Hisilicon/D05/D05.dsc @@ -187,12 +187,12 @@ [PcdsFixedAtBuild.common] !ifdef $(FIRMWARE_VER) gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"$(FIRMWARE_VER)" !else -gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"Development build 18.08 for Hisilicon D05" +gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"Development build 19.02 for Hisilicon D05" !endif gHisiTokenSpaceGuid.PcdBiosVersionString|L"10.01.01T18" - gHisiTokenSpaceGuid.PcdBiosVersionForBmc|L"1.12" + gHisiTokenSpaceGuid.PcdBiosVersionForBmc|L"19.02" gHisiTokenSpaceGuid.PcdSystemProductName|L"D05" gHisiTokenSpaceGuid.PcdSystemVersion|L"Estuary" diff --git a/Platform/Hisilicon/D06/D06.dsc b/Platform/Hisilicon/D06/D06.dsc index a3a01bfb1e23..73bea728b0f6 100644 --- a/Platform/Hisilicon/D06/D06.dsc +++ b/Platform/Hisilicon/D06/D06.dsc @@ -156,12 +156,12 @@ [PcdsFixedAtBuild.common] !ifdef $(FIRMWARE_VER) gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"$(FIRMWARE_VER)" !else -gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"Development build 18.08 for Hisilicon D06" +gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"Development build 19.02 for Hisilicon D06" !endif gHisiTokenSpaceGuid.PcdBiosVersionString|L"10.01.01T18" - gHisiTokenSpaceGuid.PcdBiosVersionForBmc|L"0.42" + gHisiTokenSpaceGuid.PcdBiosVersionForBmc|L"19.02" gHisiTokenSpaceGuid.PcdSystemProductName|L"D06" gHisiTokenSpaceGuid.PcdSystemVersion|L"VER.A" -- 2.9.5 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-platforms v3 17/18] Hisilicon/D06: Fix USB crash issue(4079)
Last patch "Modify IORT" change revision id of node type 2 to 1,
and 4.19 later kernel will judge the revision id to get root pci
bridge DMA informations from IORT. As Hi1620 USB 2.0 don't support
64 bit DMA, but the DMA attribute get from IORT node type 2 is 64
bit. So add _DMA method in USB pci bridge 3 and pci bridge 8 to
fix usb crash when usb device is present issue.
https://bugs.linaro.org/show_bug.cgi?id=4079
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ming Huang
---
Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl | 46
1 file changed, 46 insertions(+)
diff --git a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
index 6dc380f27fa2..c1083dc16a2a 100644
--- a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
+++ b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
@@ -375,6 +375,29 @@ Device (PCI2)
PCI_OSC_SUPPORT ()
+ Method(_DMA, 0, Serialized)
+ {
+Return (ResourceTemplate()
+{
+ QWORDMemory(
+ ResourceConsumer,
+ PosDecode, // _DEC
+ MinFixed, // _MIF
+ MaxFixed, // _MAF
+ Prefetchable, // _MEM
+ ReadWrite, // _RW
+ 0, // _GRA
+ 0x, // _MIN
+ 0x, // _MAX
+ 0x,// _TRA
+ 0x1, // _LEN
+ ,
+ ,
+ ,
+ )
+})
+ }
+
Method (_STA, 0x0, NotSerialized)
{
Return (0xf)
@@ -1077,6 +1100,29 @@ Device (PCI8)
Return (0xf)
}
+ Method(_DMA, 0, Serialized)
+ {
+Return (ResourceTemplate()
+{
+ QWORDMemory(
+ ResourceConsumer,
+ PosDecode, // _DEC
+ MinFixed, // _MIF
+ MaxFixed, // _MAF
+ Prefetchable, // _MEM
+ ReadWrite, // _RW
+ 0, // _GRA
+ 0x, // _MIN
+ 0x, // _MAX
+ 0x,// _TRA
+ 0x1, // _LEN
+ ,
+ ,
+ ,
+ )
+})
+ }
+
Method (_PXM, 0, NotSerialized)
{
Return(0x02)
--
2.9.5
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-platforms v3 12/18] Hisilicon/D06: Modify for IMP self-Adapte support
As new IMP(Cortex-M7) firmware support self-adapte, so do not
need BIOS to implement some function, remove useless funtions
and report CPU0/CPU1 Nic NCL offset to IMP.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ming Huang
---
Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c | 281
1 file changed, 54 insertions(+), 227 deletions(-)
diff --git a/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
b/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
index aaf990216982..678c2107bdd3 100644
--- a/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
+++ b/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
@@ -21,44 +21,21 @@
#include
#define CPU2_SFP2_100G_CARD_OFFSET 0x25
-#define CPU1_SFP1_LOCATE_OFFSET 0x16
-#define CPU1_SFP0_LOCATE_OFFSET 0x12
-#define CPU2_SFP1_LOCATE_OFFSET 0x21
-#define CPU2_SFP0_LOCATE_OFFSET 0x19
-#define CPU2_SFP2_10G_GE_CARD_OFFSET 0x25
-#define SFP_10G_SPEED 10
-#define SFP_25G_SPEED 25
-#define SFP_100G_SPEED 100
-#define SFP_GE_SPEED1
-
-#define SFP_GE_SPEED_VAL_VENDOR_FINISAR 0x0C
-#define SFP_GE_SPEED_VAL0x0D
-#define SFP_10G_SPEED_VAL 0x67
-#define SFP_25G_SPEED_VAL 0xFF
+#define SOCKET1_NET_PORT_100G 1
+#define SOCKET0_NET_PORT_NUM 4
+#define SOCKET1_NET_PORT_NUM 2
#define CARD_PRESENT_100G (BIT7)
-#define CARD_PRESENT_10G(BIT0)
-#define SELECT_SFP_BY_INDEX(index) (1 << (index - 1))
-#define SPF_SPEED_OFFSET12
-
-#define SFP_DEVICE_ADDRESS 0x50
-#define CPU1_9545_I2C_ADDR 0x70
-#define CPU2_9545_I2C_ADDR 0x71
-
-#define FIBER_PRESENT 0
-#define CARD_PRESENT 1
-#define I2C_PORT_SFP 4
-#define CPU2_I2C_PORT_SFP 5
-
-#define SOCKET_0 0
-#define SOCKET_1 1
#define EEPROM_I2C_PORT 4
#define EEPROM_PAGE_SIZE 0x40
#define MAC_ADDR_LEN 6
#define I2C_OFFSET_EEPROM_ETH0 (0xc00)
#define I2C_SLAVEADDR_EEPROM (0x52)
+#define SRAM_NIC_NCL1_OFFSET_ADDRESS 0xA0E87FE0
+#define SRAM_NIC_NCL2_OFFSET_ADDRESS 0xA0E87FE4
+
#pragma pack(1)
typedef struct {
UINT16 Crc16;
@@ -114,204 +91,6 @@ UINT16 CrcTable16[256] = {
0x6E17, 0x7E36, 0x4E55, 0x5E74, 0x2E93, 0x3EB2, 0x0ED1, 0x1EF0,
};
-EFI_STATUS
-GetSfpSpeed (
- UINT16 Socket,
- UINT16 SfpNum,
- UINT8* FiberSpeed
- )
-{
- EFI_STATUS Status;
- I2C_DEVICE SpdDev;
- UINT8 SfpSelect;
- UINT8 SfpSpeed;
- UINT32 RegAddr;
- UINT16 I2cAddr;
- UINT32 SfpPort;
-
- SfpSpeed = 0x0;
- if (Socket == SOCKET_1) {
-I2cAddr = CPU2_9545_I2C_ADDR;
-SfpPort = CPU2_I2C_PORT_SFP;
- } else {
-I2cAddr = CPU1_9545_I2C_ADDR;
-SfpPort = I2C_PORT_SFP;
- }
-
- Status = I2CInit (Socket, SfpPort, Normal);
- if (EFI_ERROR (Status)) {
-DEBUG ((DEBUG_ERROR, "[%a]:[%dL] Socket%d Call I2CInit failed! p1=0x%x.\n",
-__FUNCTION__, __LINE__, Socket, Status));
-return Status;
- }
-
- SpdDev.Socket = Socket;
- SpdDev.DeviceType = DEVICE_TYPE_SPD;
- SpdDev.Port = SfpPort;
- SpdDev.SlaveDeviceAddress = I2cAddr;
- RegAddr = 0x0;
- SfpSelect = SELECT_SFP_BY_INDEX (SfpNum);
-
- Status = I2CWrite (&SpdDev, RegAddr, 1, &SfpSelect);
- if (EFI_ERROR (Status)) {
-DEBUG ((DEBUG_ERROR, "I2CWrite Error =%r.\n", Status));
-return Status;
- }
-
- SpdDev.Socket = Socket;
- SpdDev.DeviceType = DEVICE_TYPE_SPD;
- SpdDev.Port = SfpPort;
- SpdDev.SlaveDeviceAddress = SFP_DEVICE_ADDRESS;
-
- RegAddr = SPF_SPEED_OFFSET;
- Status = I2CRead (&SpdDev, RegAddr, 1, &SfpSpeed);
- if (EFI_ERROR (Status)) {
-DEBUG ((DEBUG_ERROR, "I2CRead Error =%r.\n", Status));
-return Status;
- }
-
- DEBUG ((DEBUG_INFO, "BR, Nominal, Nominal signalling rate, SfpSpeed:
0x%x\n",
- SfpSpeed));
-
- if (SfpSpeed == SFP_10G_SPEED_VAL) {
-*FiberSpeed = SFP_10G_SPEED;
- } else if (SfpSpeed == SFP_25G_SPEED_VAL) {
-*FiberSpeed = SFP_25G_SPEED;
- } else if ((SfpSpeed == SFP_GE_SPEED_VAL) ||
- (SfpSpeed == SFP_GE_SPEED_VAL_VENDOR_FINISAR)) {
-*FiberSpeed = SFP_GE_SPEED;
- }
-
- return EFI_SUCCESS;
-}
-
-//Fiber1Type/Fiber2Type/Fiber3Type return: SFP_10G_SPEED, SFP_100G_SPEED,
SFP_GE_SPEED
-UINT32
-GetCpu2FiberType (
- UINT8* Fiber1Type,
- UINT8* Fiber2Type,
- UINT8* Fiber100Ge
- )
-{
- EFI_STATUS Status;
- UINT16 SfpNum1;
- UINT8 SfpSpeed1;
- UINT16 SfpNum2;
- UINT8 SfpSpeed2;
-
- SfpNum1 = 0x1;
- SfpSpeed1 = SFP_10G_SPEED;
- SfpNum2 = 0x2;
- SfpSpeed2 = SFP_10G_SPEED;
- *Fiber100Ge = 0x0;
- *Fiber1Type = SFP_10G_SPEED;
- *Fiber2Type = SFP_10G_SPEED;
-
- if ((ReadCpldReg (CPU2_SFP2_100G_CARD_OFFSET) & CARD_PRESENT_100G) != 0) {
-// 100 Ge card
-*Fiber1Type = SFP_10G_SPEED;
-*Fiber2Type = SFP_10G_SPEED;
-*Fiber100Ge = SFP_100G_SPEED;
-DEBUG ((DEBUG_ERROR,"Detect Fiber SFP_100G is Present, Set 100Ge\n"));
- } els
[edk2] [PATCH edk2-non-osi v3 0/8] Upload D0x binary modules
Main Changes since v2 : 1 Move "Add some header files" patch to the first of this series; Code can also be found in github: https://github.com/hisilicon/OpenPlatformPkg.git branch: 1902-non-osi-v3 Ming Huang (8): Hisilicon/D0x: Add some header files Hisilicon/D06: Remove PCI enumeration dependency from SAS driver Hisilicon/D0x: Update PlatformSysCtrlLib binary Hisilicon/D06: Update Mbigen and gic RAS register Hisilicon/D06: Support PCIe local RAS Hisilicon/D06: Use new flash layout Hisilicon/D06: Fix numa node wrong issue Hisilicon/D06: Add Setup Item "Support DPC" Silicon/Hisilicon/Include/Library/IpmiCmdLib.h | 110 +++ Silicon/Hisilicon/Include/Library/LpcLib.h | 113 Silicon/Hisilicon/Include/Library/OemAddressMapLib.h | 45 Silicon/Hisilicon/Include/Library/PlatformSysCtrlLib.h | 112 +++ Silicon/Hisilicon/Include/Library/SerdesLib.h | 21 Platform/Hisilicon/D06/CustomData.Fv | Bin 0 -> 65536 bytes Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi | Bin 232832 -> 226784 bytes Platform/Hisilicon/D06/Drivers/PcieRasInitDxe/PcieRasInitDxe.efi | Bin 21248 -> 22048 bytes Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi | Bin 17984 -> 18720 bytes Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.depex | Bin 216 -> 36 bytes Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.efi | Bin 221312 -> 220640 bytes Platform/Hisilicon/D06/Library/OemAddressMapD06/OemAddressMapD06.lib | Bin 61892 -> 31696 bytes Platform/Hisilicon/D06/MemoryInitPei/MemoryInit.efi | Bin 297696 -> 358656 bytes Platform/Hisilicon/D06/Sec/FVMAIN_SEC.Fv | Bin 1048576 -> 1048576 bytes Platform/Hisilicon/D06/bl1.bin | Bin 12432 -> 12432 bytes Platform/Hisilicon/D06/fip.bin | Bin 113450 -> 121866 bytes Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib | Bin 297590 -> 229128 bytes Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib | Bin 344310 -> 275312 bytes Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib | Bin 356032 -> 375916 bytes 19 files changed, 401 insertions(+) create mode 100644 Silicon/Hisilicon/Include/Library/IpmiCmdLib.h create mode 100755 Silicon/Hisilicon/Include/Library/LpcLib.h create mode 100644 Silicon/Hisilicon/Include/Library/OemAddressMapLib.h create mode 100644 Silicon/Hisilicon/Include/Library/PlatformSysCtrlLib.h create mode 100644 Silicon/Hisilicon/Include/Library/SerdesLib.h create mode 100644 Platform/Hisilicon/D06/CustomData.Fv -- 2.9.5 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-non-osi v3 3/8] Hisilicon/D0x: Update PlatformSysCtrlLib binary
As suggestion of community, 'AP' is a bit unfortunate to use in EDK2 context. PI specifies 'BSP' for Boot-strap Processor, as the one executing all of the EDK2 code. It then uses 'AP' to refer to Additional Processors, which can be assigned tasks using the EFI_MP_SERVICES_PROTOCOL. In a TianoCore context, this should be 'BSP'. So, Rename StartupAp() to StartUpBSP. This patch applies to D0x PlatformSysCtrlLib. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ming Huang --- Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib | Bin 297590 -> 229128 bytes Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib | Bin 344310 -> 275312 bytes Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib | Bin 356032 -> 375916 bytes 3 files changed, 0 insertions(+), 0 deletions(-) diff --git a/Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib b/Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib index 68be770..4c63a26 100644 Binary files a/Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib and b/Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib differ diff --git a/Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib b/Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib index b3cc88e..cb2c652 100644 Binary files a/Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib and b/Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib differ diff --git a/Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib b/Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib index 50d453a..d643f7b 100644 Binary files a/Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib and b/Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib differ -- 2.9.5 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-non-osi v3 2/8] Hisilicon/D06: Remove PCI enumeration dependency from SAS driver
SAS controller is always existed, so accessing SAS register don't depend on PciBusDxe (pci enumeration). Modify SAS driver remove the dependence on pci enumeration. This patch is done to improve boot times. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ming Huang --- Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.depex | Bin 216 -> 36 bytes Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.efi | Bin 221312 -> 220640 bytes 2 files changed, 0 insertions(+), 0 deletions(-) diff --git a/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.depex b/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.depex index 1a5bc1e..e076777 100644 Binary files a/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.depex and b/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.depex differ diff --git a/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.efi b/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.efi index ac6bae7..4a29e8c 100644 Binary files a/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.efi and b/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.efi differ -- 2.9.5 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-non-osi v3 4/8] Hisilicon/D06: Update Mbigen and gic RAS register
As chip group suggestions, update Mbigen and gic RAS configuration flow. Add below flow: 1 Reset Mbigen; 2 Disable Mbigen clock; 3 Deassert reset Mbigen; 4 Enable Mbigen clock; Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ming Huang --- Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi | Bin 17984 -> 18720 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi b/Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi index 19adbc9..9ea21e9 100644 Binary files a/Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi and b/Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi differ -- 2.9.5 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-non-osi v3 6/8] Hisilicon/D06: Use new flash layout
In new flash layout, BIOS fd change from offset 1M to 8M in 16M spi flash. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ming Huang --- Platform/Hisilicon/D06/CustomData.Fv | Bin 0 -> 65536 bytes Platform/Hisilicon/D06/Library/OemAddressMapD06/OemAddressMapD06.lib | Bin 61892 -> 31696 bytes Platform/Hisilicon/D06/Sec/FVMAIN_SEC.Fv | Bin 1048576 -> 1048576 bytes 3 files changed, 0 insertions(+), 0 deletions(-) diff --git a/Platform/Hisilicon/D06/CustomData.Fv b/Platform/Hisilicon/D06/CustomData.Fv new file mode 100644 index 000..22ef62b Binary files /dev/null and b/Platform/Hisilicon/D06/CustomData.Fv differ diff --git a/Platform/Hisilicon/D06/Library/OemAddressMapD06/OemAddressMapD06.lib b/Platform/Hisilicon/D06/Library/OemAddressMapD06/OemAddressMapD06.lib index 7e1f6b2..851c2c3 100644 Binary files a/Platform/Hisilicon/D06/Library/OemAddressMapD06/OemAddressMapD06.lib and b/Platform/Hisilicon/D06/Library/OemAddressMapD06/OemAddressMapD06.lib differ diff --git a/Platform/Hisilicon/D06/Sec/FVMAIN_SEC.Fv b/Platform/Hisilicon/D06/Sec/FVMAIN_SEC.Fv index 247e44e..7f75bc6 100644 Binary files a/Platform/Hisilicon/D06/Sec/FVMAIN_SEC.Fv and b/Platform/Hisilicon/D06/Sec/FVMAIN_SEC.Fv differ -- 2.9.5 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-non-osi v3 7/8] Hisilicon/D06: Fix numa node wrong issue
Numa informations are acquired from HOB that build from memory initialization module. Correct numa informations to match booting from TA(Totem A or super cpu cluster A). Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ming Huang --- Platform/Hisilicon/D06/MemoryInitPei/MemoryInit.efi | Bin 297696 -> 358656 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/Platform/Hisilicon/D06/MemoryInitPei/MemoryInit.efi b/Platform/Hisilicon/D06/MemoryInitPei/MemoryInit.efi index 5fba353..fea1475 100644 Binary files a/Platform/Hisilicon/D06/MemoryInitPei/MemoryInit.efi and b/Platform/Hisilicon/D06/MemoryInitPei/MemoryInit.efi differ -- 2.9.5 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-non-osi v3 1/8] Hisilicon/D0x: Add some header files
As interfaces exposed only by implementations in edk2-non-osi,
so move some header files from edk2-platforms to edk2-non-osi.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ming Huang
---
Silicon/Hisilicon/Include/Library/IpmiCmdLib.h | 110
+++
Silicon/Hisilicon/Include/Library/LpcLib.h | 113
Silicon/Hisilicon/Include/Library/OemAddressMapLib.h | 45
Silicon/Hisilicon/Include/Library/PlatformSysCtrlLib.h | 112
+++
Silicon/Hisilicon/Include/Library/SerdesLib.h | 21
5 files changed, 401 insertions(+)
diff --git a/Silicon/Hisilicon/Include/Library/IpmiCmdLib.h
b/Silicon/Hisilicon/Include/Library/IpmiCmdLib.h
new file mode 100644
index 000..b956ee6
--- /dev/null
+++ b/Silicon/Hisilicon/Include/Library/IpmiCmdLib.h
@@ -0,0 +1,110 @@
+/** @file
+*
+* Copyright (c) 2017, Hisilicon Limited. All rights reserved.
+* Copyright (c) 2017, Linaro Limited. 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.
+*
+**/
+
+#ifndef _IPMI_CMD_LIB_H_
+#define _IPMI_CMD_LIB_H_
+
+#define BOOT_OPTION_BOOT_FLAG_VALID 1
+#define BOOT_OPTION_BOOT_FLAG_INVALID 0
+
+typedef enum {
+ EfiReserved,
+ EfiBiosFrb2,
+ EfiBiosPost,
+ EfiOsLoad,
+ EfiSmsOs,
+ EfiOem,
+ EfiFrbReserved1,
+ EfiFrbReserved2
+} EFI_WDT_USER_TYPE;
+
+typedef enum {
+ NoOverride = 0x0,
+ ForcePxe,
+ ForceDefaultHardDisk,
+ ForceDefaultHardDiskSafeMode,
+ ForceDefaultDiagnosticPartition,
+ ForceDefaultCD,
+ ForceSetupUtility,
+ ForceRemoteRemovableMedia,
+ ForceRemoteCD,
+ ForcePrimaryRemoteMedia,
+ ForceRemoteHardDisk = 0xB,
+ ForcePrimaryRemovableMedia = 0xF
+} BOOT_DEVICE_SELECTOR;
+
+//
+// Get System Boot Option data structure
+//
+typedef struct {
+ UINT8 ParameterVersion :4;
+ UINT8 Reserved1 :4;
+ UINT8 ParameterSelector :7;
+ UINT8 ParameterValid :1;
+ //
+ // Boot Flags Data 1
+ //
+ UINT8 Reserved2 :5;
+ UINT8 BiosBootType :1;
+ UINT8 Persistent :1;
+ UINT8 BootFlagsValid :1;
+ //
+ // Boot Flags Data 2
+ //
+ UINT8 LockResetBtn :1;
+ UINT8 ScreenBlank:1;
+ UINT8 BootDeviceSelector :4;
+ UINT8 LockKeyboard :1;
+ UINT8 ClearCmos :1;
+ //
+ // Boot Flags Data 3
+ //
+ UINT8 ConsoleRedirectionControl :2;
+ UINT8 LockSleepBtn :1;
+ UINT8 UserPasswordByPass :1;
+ UINT8 Reserved3 :1;
+ UINT8 FirmwareVerbosity :2;
+ UINT8 LockPowerBtn :1;
+ //
+ // Boot Flags Data 4
+ //
+ UINT8 MuxControlOverride :3;
+ UINT8 ShareModeOverride :1;
+ UINT8 Reserved4 :4;
+ //
+ // Boot Flags Data 5
+ //
+ UINT8 DeviceInstanceSelector :5;
+ UINT8 Reserved5 :3;
+} IPMI_GET_BOOT_OPTION;
+
+EFI_STATUS
+EFIAPI
+IpmiCmdSetSysBootOptions (
+ OUT IPMI_GET_BOOT_OPTION *BootOption
+ );
+
+EFI_STATUS
+EFIAPI
+IpmiCmdGetSysBootOptions (
+ IN IPMI_GET_BOOT_OPTION *BootOption
+ );
+
+EFI_STATUS
+IpmiCmdStopWatchdogTimer (
+ IN EFI_WDT_USER_TYPE UserType
+ );
+
+#endif
diff --git a/Silicon/Hisilicon/Include/Library/LpcLib.h
b/Silicon/Hisilicon/Include/Library/LpcLib.h
new file mode 100755
index 000..236a52b
--- /dev/null
+++ b/Silicon/Hisilicon/Include/Library/LpcLib.h
@@ -0,0 +1,113 @@
+/** @file
+*
+* Copyright (c) 2016, Hisilicon Limited. All rights reserved.
+* Copyright (c) 2016, Linaro Limited. 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.
+*
+**/
+
+#ifndef _LPC_LIB_H_
+#define _LPC_LIB_H_
+
+#include
+
+#define PCIE_SUBSYS_IO_MUX 0xA017
+#define PCIE_SUBSYS_IOMG033 (PCIE_SUBSYS_IO_MUX + 0x84)
+#define PCIE_SUBSYS_IOMG035 (PCIE_SUBSYS_IO_MUX + 0x8C)
+#define PCIE_SUBSYS_IOMG036 (PCIE_SUBSYS_IO_MUX + 0x90)
+#define PCIE_SUBSYS_IOMG045 (PCIE_SUBSYS_IO_MUX + 0xB4)
+#define PCIE_SUBSYS_IOMG046 (PCIE_SUBSYS_IO_MUX + 0xB8)
+#define PCIE_SUBSYS_IOMG047 (PCIE_SUBSYS_IO_MUX + 0xBC)
+#define PCIE_SUBSYS_IOMG048 (PCIE_SUBSYS_IO_MUX + 0xC0)
+#defi
[edk2] [PATCH edk2-non-osi v3 8/8] Hisilicon/D06: Add Setup Item "Support DPC"
Add setup item "Support DPC" to enable or disable PCIe DPC (Downstream Port Containment). Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ming Huang Reviewed-by: Leif Lindholm --- Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi | Bin 232832 -> 226784 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi b/Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi index e32c056..4511f6b 100644 Binary files a/Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi and b/Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi differ -- 2.9.5 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-non-osi v3 5/8] Hisilicon/D06: Support PCIe local RAS
Add some registers configuration in PcieRasInitDxe and add PCIe local RAS interrupt handle in trusted firmware to support PCIe local RAS. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ming Huang Reviewed-by: Leif Lindholm --- Platform/Hisilicon/D06/Drivers/PcieRasInitDxe/PcieRasInitDxe.efi | Bin 21248 -> 22048 bytes Platform/Hisilicon/D06/bl1.bin | Bin 12432 -> 12432 bytes Platform/Hisilicon/D06/fip.bin | Bin 113450 -> 121866 bytes 3 files changed, 0 insertions(+), 0 deletions(-) diff --git a/Platform/Hisilicon/D06/Drivers/PcieRasInitDxe/PcieRasInitDxe.efi b/Platform/Hisilicon/D06/Drivers/PcieRasInitDxe/PcieRasInitDxe.efi index 0e22237..f9ceff2 100644 Binary files a/Platform/Hisilicon/D06/Drivers/PcieRasInitDxe/PcieRasInitDxe.efi and b/Platform/Hisilicon/D06/Drivers/PcieRasInitDxe/PcieRasInitDxe.efi differ diff --git a/Platform/Hisilicon/D06/bl1.bin b/Platform/Hisilicon/D06/bl1.bin index 416535f..d0970e5 100644 Binary files a/Platform/Hisilicon/D06/bl1.bin and b/Platform/Hisilicon/D06/bl1.bin differ diff --git a/Platform/Hisilicon/D06/fip.bin b/Platform/Hisilicon/D06/fip.bin index c9b7ca0..795cfb5 100644 Binary files a/Platform/Hisilicon/D06/fip.bin and b/Platform/Hisilicon/D06/fip.bin differ -- 2.9.5 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 1/2] MdeModulePkg/CapsuleRuntimeDxe: Merge changes form arm to all ARCH
On Wed, 20 Mar 2019 at 02:43, Zhichao Gao wrote:
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1462
>
> The arm ARCH has already to add a function CapsuleCacheWriteBack to
> flush the cache data to DRAM. That is also required in IA32 ARCH. So
> merge the changes. And this function do not support in runtime phase.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Liming Gao
After this patch, platforms may return TRUE from
QueryCapsuleCapabilities() while they returned FALSE before, i.e., at
runtime. This behavior change will surely break ARM, but I don't see
how it doesn't break IA32 as well if it now relies on this cache
maintenance to occur in the context of UpdateCapsule().
> ---
> .../Universal/CapsuleRuntimeDxe/CapsuleReset.c | 21
> .../{Arm/CapsuleReset.c => CapsuleResetNull.c} | 29
> +++---
> .../CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf| 14 +--
> 3 files changed, 30 insertions(+), 34 deletions(-)
> rename MdeModulePkg/Universal/CapsuleRuntimeDxe/{Arm/CapsuleReset.c =>
> CapsuleResetNull.c} (51%)
>
> diff --git a/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleReset.c
> b/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleReset.c
> index 353f6f2090..8c45f6665e 100644
> --- a/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleReset.c
> +++ b/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleReset.c
> @@ -16,6 +16,8 @@
>
> #include "CapsuleService.h"
>
> +#include
> +
> /**
>Whether the platform supports capsules that persist across reset. Note that
>some platforms only support such capsules at boot time.
> @@ -46,4 +48,23 @@ CapsuleCacheWriteBack (
>IN EFI_PHYSICAL_ADDRESSScatterGatherList
>)
> {
> + EFI_CAPSULE_BLOCK_DESCRIPTOR*Desc;
> +
> + if (!EfiAtRuntime()) {
> +Desc = (EFI_CAPSULE_BLOCK_DESCRIPTOR *)(UINTN)ScatterGatherList;
> +do {
> + WriteBackDataCacheRange (Desc, sizeof *Desc);
> +
> + if (Desc->Length > 0) {
> +WriteBackDataCacheRange ((VOID *)(UINTN)Desc->Union.DataBlock,
> + Desc->Length
> + );
> +Desc++;
> + } else if (Desc->Union.ContinuationPointer > 0) {
> +Desc = (EFI_CAPSULE_BLOCK_DESCRIPTOR
> *)(UINTN)Desc->Union.ContinuationPointer;
> + }
> +} while (Desc->Length > 0 || Desc->Union.ContinuationPointer > 0);
> +
> +WriteBackDataCacheRange (Desc, sizeof *Desc);
> + }
> }
> diff --git a/MdeModulePkg/Universal/CapsuleRuntimeDxe/Arm/CapsuleReset.c
> b/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleResetNull.c
> similarity index 51%
> rename from MdeModulePkg/Universal/CapsuleRuntimeDxe/Arm/CapsuleReset.c
> rename to MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleResetNull.c
> index d79d2fc693..3c5cfc1a16 100644
> --- a/MdeModulePkg/Universal/CapsuleRuntimeDxe/Arm/CapsuleReset.c
> +++ b/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleResetNull.c
> @@ -1,8 +1,9 @@
> /** @file
> - ARM implementation of architecture specific routines related to
> + Default implementation of architecture specific routines related to
>PersistAcrossReset capsules
>
>Copyright (c) 2018, Linaro, Ltd. All rights reserved.
> + Copyright (c) 2019, Intel Corporation. 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
> @@ -31,14 +32,7 @@ IsPersistAcrossResetCapsuleSupported (
>VOID
>)
> {
> - //
> - // ARM requires the capsule payload to be cleaned to the point of coherency
> - // (PoC), but only permits doing so using cache maintenance instructions
> that
> - // operate on virtual addresses. Since at runtime, we don't know the
> virtual
> - // addresses of the data structures that make up the scatter/gather list,
> we
> - // cannot perform the maintenance, and all we can do is give up.
> - //
> - return FeaturePcdGet (PcdSupportUpdateCapsuleReset) && !EfiAtRuntime ();
> + return FeaturePcdGet (PcdSupportUpdateCapsuleReset);
> }
>
> /**
> @@ -55,21 +49,4 @@ CapsuleCacheWriteBack (
>IN EFI_PHYSICAL_ADDRESSScatterGatherList
>)
> {
> - EFI_CAPSULE_BLOCK_DESCRIPTOR*Desc;
> -
> - Desc = (EFI_CAPSULE_BLOCK_DESCRIPTOR *)(UINTN)ScatterGatherList;
> - do {
> -WriteBackDataCacheRange (Desc, sizeof *Desc);
> -
> -if (Desc->Length > 0) {
> - WriteBackDataCacheRange ((VOID *)(UINTN)Desc->Union.DataBlock,
> - Desc->Length
> - );
> - Desc++;
> -} else if (Desc->Union.ContinuationPointer > 0) {
> - Desc = (EFI_CAPSULE_BLOCK_DESCRIPTOR
> *)(UINTN)Desc->Union.ContinuationPointer;
> -}
> - } while (Desc->Length > 0 || Desc->Union.ContinuationPointer > 0);
> -
> - WriteBackDataCacheRange (Desc, sizeof *Desc);
> }
> diff --
Re: [edk2] [RFC 0/3] Enable runtime serial debug for ArmVirtQemu
On 03/16/19 10:41, Heyi Guo wrote: > On 2019/3/13 1:05, Laszlo Ersek wrote: >> Given that you'd have to implement a "special" SerialPortLib instance >> just for StatusCodeHandlerRuntimeDxe anyway, can we perhaps: >> >> (1) Undo -- dependent on a build flag? -- commit ebfca258f5d7; i.e., >> stick universally with BaseDebugLibSerialPort, for DebugLib, >> >> (2) add a new implementation of "FdtPL011SerialPortLib.inf" with both >> (a) runtime behavior and (b) handling of a special serial port? >> >> In other words, push down the "runtime?" distinction from DebugLib (see >> commit 7f029e1b31ee) to SerialPortLib. The new SerialPortLib instance >> would be used only with DXE_RUNTIME_DRIVERs. >> >> The lib instance would prepare everything in advance for accessing the >> "special" serial port at runtime (which could require allocating runtime >> memory in advance). Once ExitBootServices() is called, a callback should >> switch over the behavior of the lib instance, without allocating further >> memory. (The switched-over behavior would not have to be functional >> until the virtual address map is set.) > My first idea was also simply implement a runtime serial port instance, > but the problem is for the initialization. > > Since serial port lib is only a library, it seems we can only initialize > everything in SerialPortInitialize() or library constructor, but either > of which could no work in current EDK2 code framework. Please see my > explanation in earlier mail as below: > > "The long story is: at first I proposed to still use > BaseSerialPortDebugLib, so I added RuntimePrepare() function into the > constructor directly, but the builder complained about looped > constructors, for RuntimePrepare() invokes gBS and some RunTime > libraries. Then I tried disabling the constructor and moved > RuntimePrepare() into SerialPortInitialize() which could complete the > build, but still couldn't guarantee the calling order of these > constructors, for BaseSerialPortDebugLib has a constructor to call > SerialPortInitialize()." (Sorry about the late response (I've been away for a few days), and also for missing that construction loop that you apparently mentioned earlier.) You mention that "RuntimePrepare() invokes gBS and some RunTime libraries". How important is it to rely on those libraries? For example, "gBS" is simply a convenience; you can get at the same thing from the parameter list of the constructor function too (assuming you use a MODULE_TYPE of (minimally) DXE_DRIVER, in the lib instance's INF file). If we don't have to flatten a ridiculous amount of other library code into the RuntimePrepare() function, I think such flattening would be a viable approach. We've run into this constructor loop several times before, and -- if I remember correctly anyway! -- one approach has been to declare SerialPortLib the "lowest level abstraction", and make the affected lib instance self-contained. > Can we use event notify or protocol notify to do the runtime > intialization? Like EndOfDxe event group. Any other advice? I guess this could work too. I'm not really a fan of callbacks as long as we can manage otherwise (for example, we can't propagate errors out of callbacks), but if the lib flattening thing gets too complex, we could do this as well. Regarding EndOfDxe -- I think EndOfDxe is considered a trust barrier (namely between platform fw modules and 3rd party modules), so I wouldn't tie our initialization to that, for clarity's sake. ReadyToBoot seems a tiny bit less "forced" -- it is sufficiently late, you can still allocate resources, and we can claim it is "on the path towards OS runtime". Just be aware that ReadyToBoot can be signaled multiple times, e.g. if some boot options fail (so uninstall the handler / close the event when serving the first callback I guess). Thanks Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH RESEND 1/3] OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge aperture
On 03/19/19 15:03, Anthony PERARD wrote: > On Thu, Mar 14, 2019 at 07:45:56PM +, Igor Druzhinin wrote: >> On 14/03/2019 17:41, Anthony PERARD wrote: >>> Hi, >>> >>> On Wed, Mar 06, 2019 at 12:40:54PM +, Igor Druzhinin wrote: This aperture doesn't exist in OVMF and trying to use it causes >>> >>> I'm trying to understand what you mean by writing "doesn't exist in >>> OVMF". Are prefetchable BAR not handled by ScanForRootBridges() ? >>> Or is it the emulation of the config space that isn't correct? >>> Maybe QEMU should lies about a BAR been prefetchable? >> >> The problem here is: hvmloader places BARs initially disregarding >> prefetchable bit in an arbitrary order because essentially there is only >> 1 aperture for the host bridge in emulated system under Xen (and KVM as >> well). In PcatPciRootBridgeParseBars() we construct apertures for high >> level OVMF code by reading the BAR placement information after >> hvmloader. It often appears that there are prefetchable and >> non-prefetchable BARs coexist with each other and make prefetchable and >> non-prefetchable apertures overlap. This eventually triggers an >> assertion in high level OVMF code because that shouldn't happen. > > Thanks for the explanation. Could you add it to the patch description? > >> OVMF for KVM is not using prefetchable BAR at all - see >> PciHostBridgeGetRootBridges() in which it passes mNonExistAperture dummy >> object to high level code. I think it's wrong to construct a >> prefetchable aperture for Xen and this code should be removed as it's >> done for QEMU-KVM. Do you think this patch needs to do that? > > It would be nice to remove the code that isn't useful so feel free to do > it and/or keep the current patch with the description updated. Right -- I'd like to add one keyword here, for background: EFI_PCI_HOST_BRIDGE_COMBINE_MEM_PMEM. (It's documented in both edk2 [MdePkg/Include/Protocol/PciHostBridgeResourceAllocation.h] and the PI spec [EFI_PCI_HOST_BRIDGE_RESOURCE_ALLOCATION_PROTOCOL.GetAllocAttributes()].) Thanks Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] PATCH] Change EDK II to BSD+Patent License
On 03/15/19 18:48, Lars Kurth wrote: > > > On 15/03/2019, 10:18, "Julien Grall" wrote: > > > > > EDK2 is converting the full copyright in each file to SDPX > identifier. While the > > copyright looks like an MIT license, it has never been confirmed. > Andrew Cooper > > suggested you might be able to confirm. > > > > Is there a web-link to the files/repos such that I don’t have to clone > the repo > > Lars > > Here an example of files from Xen public headers: > > > https://xenbits.xen.org/gitweb/?p=xen.git;a=tree;f=xen/include/public;h=0618b0134d2b9babcba71a3f0f86be5a84468b50;hb=HEAD > > OK, this makes this easy then. Because in all likelihood, the files were > copied from xen/include/public and then the COPYING file > https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/COPYING > applies, which states that everything in this directory is MIT, unless stated > otherwise in the file. > > So as long as someone confirms that the files in OvmfPkg/Include came from > xen/include/public, this is a clear case of a MIT license > If they are files from other directories in Xen, check the COPYING file in > the original directory (or if there is none in the parent directory) and > check the COPYING file > > I am not so clear about where the files in XenBusDxe came from, but the same > principle applies. > > If someone groups these files by "original directory in Xen" to File ... I am > happy to do a final sanity check and sign it off and/or deal with any unclear > cases Replacing MIT license blocks with SPDX identifiers is something we should do later -- I think it's out of scope for Mike's current patch series, it's just something I noticed and pointed out for the future, while I was verifying the "license block -> SPDX ID" replacements for 2-BSDL (i.e., *not* MIT). Mike mentioned that he was going to file a number of TianoCore BZs as a result of the discussion in this thread. Mike, can you please file one for the MIT->SPDX "refactoring" (under OvmfPkg) as well? If not, I can file it myself later, I just wouldn't like us to end up with duplicates. Once we have that separate BZ, we can discuss it in isolation. Thanks Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [RFC 0/3] Enable runtime serial debug for ArmVirtQemu
On 2019/3/20 17:55, Laszlo Ersek wrote: On 03/16/19 10:41, Heyi Guo wrote: On 2019/3/13 1:05, Laszlo Ersek wrote: Given that you'd have to implement a "special" SerialPortLib instance just for StatusCodeHandlerRuntimeDxe anyway, can we perhaps: (1) Undo -- dependent on a build flag? -- commit ebfca258f5d7; i.e., stick universally with BaseDebugLibSerialPort, for DebugLib, (2) add a new implementation of "FdtPL011SerialPortLib.inf" with both (a) runtime behavior and (b) handling of a special serial port? In other words, push down the "runtime?" distinction from DebugLib (see commit 7f029e1b31ee) to SerialPortLib. The new SerialPortLib instance would be used only with DXE_RUNTIME_DRIVERs. The lib instance would prepare everything in advance for accessing the "special" serial port at runtime (which could require allocating runtime memory in advance). Once ExitBootServices() is called, a callback should switch over the behavior of the lib instance, without allocating further memory. (The switched-over behavior would not have to be functional until the virtual address map is set.) My first idea was also simply implement a runtime serial port instance, but the problem is for the initialization. Since serial port lib is only a library, it seems we can only initialize everything in SerialPortInitialize() or library constructor, but either of which could no work in current EDK2 code framework. Please see my explanation in earlier mail as below: "The long story is: at first I proposed to still use BaseSerialPortDebugLib, so I added RuntimePrepare() function into the constructor directly, but the builder complained about looped constructors, for RuntimePrepare() invokes gBS and some RunTime libraries. Then I tried disabling the constructor and moved RuntimePrepare() into SerialPortInitialize() which could complete the build, but still couldn't guarantee the calling order of these constructors, for BaseSerialPortDebugLib has a constructor to call SerialPortInitialize()." (Sorry about the late response (I've been away for a few days), and also for missing that construction loop that you apparently mentioned earlier.) Nothing at all, and thanks for your time in reading and replying the mails even when out of office :) You mention that "RuntimePrepare() invokes gBS and some RunTime libraries". How important is it to rely on those libraries? For example, "gBS" is simply a convenience; you can get at the same thing from the parameter list of the constructor function too (assuming you use a MODULE_TYPE of (minimally) DXE_DRIVER, in the lib instance's INF file). If we don't have to flatten a ridiculous amount of other library code into the RuntimePrepare() function, I think such flattening would be a viable approach. We've run into this constructor loop several times before, and -- if I remember correctly anyway! -- one approach has been to declare SerialPortLib the "lowest level abstraction", and make the affected lib instance self-contained. In my RFC, we need to use gDS which is from DxeServicesTableLib->EfiGetSystemConfigurationTable()->UefiLib, so that we need to flatten EfiGetSystemConfigurationTable(). And gDS->SetMemorySpaceAttributes() actually relies on gEfiCpuArchProtocolGuid or it will return EFI_NOT_AVAILABLE_YET. Thanks, Heyi Can we use event notify or protocol notify to do the runtime intialization? Like EndOfDxe event group. Any other advice? I guess this could work too. I'm not really a fan of callbacks as long as we can manage otherwise (for example, we can't propagate errors out of callbacks), but if the lib flattening thing gets too complex, we could do this as well. Regarding EndOfDxe -- I think EndOfDxe is considered a trust barrier (namely between platform fw modules and 3rd party modules), so I wouldn't tie our initialization to that, for clarity's sake. ReadyToBoot seems a tiny bit less "forced" -- it is sufficiently late, you can still allocate resources, and we can claim it is "on the path towards OS runtime". Just be aware that ReadyToBoot can be signaled multiple times, e.g. if some boot options fail (so uninstall the handler / close the event when serving the first callback I guess). Thanks Laszlo . ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v1 0/2] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg
On 03/18/19 04:45, Wu, Hao A wrote: >> -Original Message- >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] >> Sent: Friday, March 15, 2019 7:10 PM >> To: Wu, Hao A >> Cc: edk2-devel@lists.01.org; Justen, Jordan L; Laszlo Ersek; Ni, Ray >> Subject: Re: [PATCH v1 0/2] Ovmf: Stop using ISA drivers within >> IntelFrameworkModulePkg >> >> On Fri, 15 Mar 2019 at 08:16, Hao Wu wrote: >>> >>> This series will update the OVMF to stop using the ISA drivers within >>> IntelFrameworkModulePkg. >>> >>> As the replacement, a new OVMF Super I/O bus driver has been add which >>> will install the Super I/O protocol for ISA serial and PS2 keyboard >>> devices. By doing so, these devices can be managed by: >>> >>> MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf >>> MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxe.inf >>> >>> respectively. >>> >> >> Just a couple of notes from my side - I'm sure Laszlo will have a much >> longer list :-) >> >> - Dropping the floppy driver is fine with me. >> - What is OVMF specific about this driver? Is it only the hardcoded >> list of COM1/COM2/PS2 keyboard? If so, should we split this into a >> driver and a library class, where the driver lives in MdeModulePkg, >> and the library is implemented in the context of OVMF? > > Hello Ard, > > I think the special thing for this one is that: > For QEMU, it does not have a Super I/O (SIO) chip. While, as far as I > know, the SIO chip exists on other platforms. The driver proposed here > simulates the behavior of an SIO chip. IMO, if we find more platforms that > do not have a SIO chip, we can convert the driver into a general one. > > Also, for the implementation of the services in the Super I/O protocol, > the proposed driver just does the minimal effort in order to support the > serial/PS2 keyboard. Here's why I'd like the majority of this driver to live under MdeModulePkg (for example through a lib class separation like Ard suggests): Because then its maintenance would not be the responsibility of OvmfPkg maintainers. Consider, this driver is absolutely huge (1.5-2 kLOC), for doing "the minimal effort in order to support the serial/PS2 keyboard". The risk of regressions is extreme (the PS/2 keyboard is the default one, and if it breaks *subtly*, almost all users will be inconvenienced, but not necessarily soon enough for us to get reports about it *early* in the current development cycle). I realize that IntelFrameworkModulePkg/Bus/Isa/* drivers are frowned upon nowadays, they may be ugly / platform specific / etc etc etc, but they have also proved themselves to *work*, and (as far as I remember) they have required practically zero fixes in order to function well on QEMU. It is very unwelcome by me to take on the maintenance burden for a driver that is all of: - not widely tested, - replacing a proven set of drivers that is critical to users, - large. I understand that Intel wants to stop maintaining IntelFrameworkModulePkg/Bus/Isa/*, but the above price is too high for me. Compare the case if we simply moved the IntelFrameworkModulePkg/Bus/Isa/* drivers under OvmfPkg: - still large, - but widely tested (with minimal churn in the past), - and no risk of regressions. So in this form, I'm generally opposed to the switch. The two sets of drivers need to coexist for a while, and we must expose the new drivers to users while providing them with some sort of easy fallback. (I'd prefer that fallback to be dynamically configurable, but, again, if your keyboard breaks, how do you interact with e.g. the UEFI shell? So I guess a static build flag would do as well.) I think the old drivers should be removed only in the edk2 stable tag that comes *after* the next one, once we've given the drivers enough time to "prove themselves". (We did something similar when we switched to the central PCI root bridge driver in OVMF as well -- an OVMF lib instance for it was implemented, so the maintenance burden wasn't fully under OvmfPkg to begin with, plus we kept the old driver around with a build flag for a while. IIRC.) Obviously I might feel safer if I could do a thorough review of the driver, but I *absolutely* don't have time for it now. I'm sorry about that. Thanks, Laszlo >> - Regardless of the previous, adding the new driver should be a patch >> of its own. > > Agree. I will adopt the detailed approach suggested by Jordan for this one. > Thanks for the feedback. > >> - I spotted an incorrect reference to PCI_IO_DEV in a comment (patch #2) > > Thanks for the catch. I will address this comment typo in the next version of > the series. > > > I will wait a little longer to see if Laszlo has additional > comments/feedbacks on this. > > Best Regards, > Hao Wu > >> >> >> >>> >>> Tests done: >>> A. GCC5 & VS2015x86 tool chains build pass >>> B. Launch QEMU (2.4.50, Windows) with command: >>>> qemu-system-x86_64.exe -pflash \OVMF.fd -serial >> file:1.txt -serial file:2.txt >>> >>>Able to see the ISA COM1/CO
Re: [edk2] [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64 in .dsc
Hi Leif,
On 03/18/19 15:56, Leif Lindholm wrote:
> Commit 05fd2a926833
> ("MdeModulePkg/NvmExpressPei: Consume S3StorageDeviceInitList LockBox")
> added a dependency on LockBoxLib to NvmExpressPei, causing builds using
> MdeModulePkg.dsc to fail on architectures other than IA32/X64 with
> missing reference to
> gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode.
>
> Add a resolution for LockBoxNullLib for ARM/AARCH64 to restore builds.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Leif Lindholm
> ---
>
> Note: this patch hides the symptom, but this isn't really the fix I
> would like to see.
>
> The build error is caused by the chain of:
> 1) NvmExpressPei depending on LockBoxLib
> 2) LockBoxLib being mapped to SmmLockBoxPeiLib in [LibraryClasses.common.PEIM]
> 3) SmmLockBoxPeiLib depending on PcdDxeIplSwitchToLongMode
> 4) PcdDxeIplSwitchToLongMode being declared in
>[PcdsFeatureFlag.IA32, PcdsFeatureFlag.X64] in MdeModulePkg.dsc
>
> Now, an alternative quick-fix would be to move the PEIM LockBoxLib mapping
> into a [LibraryClasses.IA32.PEIM, LibraryClasses.X64.PEIM]
> section. But that would leave NvmExpressPei unbuildable on anything not
> IA32/X64.
>
> Another option would be to add default declaration (for all other
> architectures) of FALSE for PcdDxeIplSwitchToLongMode in MdeModulePkg.dec,
> but the current way this is expressed seems to treat this as an
> architecture-specific feature (which it is).
>
> What I believe would be the cleanest solution would be to abstract
> NvmExpressPei to the point where it can function without the LockBoxLib.
> But regardless, it does not look valid to me for something as
> architecture-specific as MdeModulePkg/Library/SmmLockBoxLib/ to live under
> .common sections in the .dsc. (And if this changes at some point, because we
> implement an ARM/AARCH64 equivalent based on StandaloneMmPkg, we will need
> a major refactoring of that library anyway.)
>
> /
> Leif
>
> MdeModulePkg/MdeModulePkg.dsc | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
> index 6cd1727a0d..6e27e9cb68 100644
> --- a/MdeModulePkg/MdeModulePkg.dsc
> +++ b/MdeModulePkg/MdeModulePkg.dsc
> @@ -178,6 +178,7 @@ [LibraryClasses.common.MM_STANDALONE]
> [LibraryClasses.ARM, LibraryClasses.AARCH64]
>ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
>ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
> + LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
>
>#
># It is not possible to prevent ARM compiler calls to generic intrinsic
> functions.
>
I think this patch is exactly the right solution.
The code added in commit 05fd2a926833 is gated by (BootMode ==
BOOT_ON_S3_RESUME). That condition can never evaluate to TRUE on
ARM/AARCH64, presently. Accordingly, the stated goal of the commit
doesn't apply to ARM/AARCH64:
The purpose is to perform an on-demand (partial) NVM Express device
enumeration/initialization to benefit the S3 resume performance.
Given that the RestoreLockBox() calls are never reached (which is
correct, by design, at the present level of ACPI S3 enablement in edk2
for ARM/AARCH64), causing the lockbox APIs to "do nothing beyond
compile" is exactly right. IMO anyway.
Once ARM/AARCH64 grow S3 support, a functional and secure LockBox will
have to be part of that. Perhaps it will use "standalone MM"; I'm not
sure. The point is, once the goal of the commit starts applying to
ARM/AARCH64, a functional LockBox will have been implemented for
ARM/AARCH64; and that lib instance will certainly not depend on
PcdDxeIplSwitchToLongMode.
Until such time, this patch is fine.
Reviewed-by: Laszlo Ersek
Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64 in .dsc
Same case for AhciPei.
I am ok with the patch. Reviewed-by: Star Zeng
Thanks,
Star
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Wednesday, March 20, 2019 10:52 PM
To: Leif Lindholm ; edk2-devel@lists.01.org
Cc: ard.biesheu...@linaro.org; Wang, Jian J ; Wu, Hao A
; Ni, Ray ; Zeng, Star
; Andrew Fish ; Kinney, Michael D
Subject: Re: [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64 in .dsc
Hi Leif,
On 03/18/19 15:56, Leif Lindholm wrote:
> Commit 05fd2a926833
> ("MdeModulePkg/NvmExpressPei: Consume S3StorageDeviceInitList
> LockBox") added a dependency on LockBoxLib to NvmExpressPei, causing
> builds using MdeModulePkg.dsc to fail on architectures other than
> IA32/X64 with missing reference to
> gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode.
>
> Add a resolution for LockBoxNullLib for ARM/AARCH64 to restore builds.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Leif Lindholm
> ---
>
> Note: this patch hides the symptom, but this isn't really the fix I
> would like to see.
>
> The build error is caused by the chain of:
> 1) NvmExpressPei depending on LockBoxLib
> 2) LockBoxLib being mapped to SmmLockBoxPeiLib in
> [LibraryClasses.common.PEIM]
> 3) SmmLockBoxPeiLib depending on PcdDxeIplSwitchToLongMode
> 4) PcdDxeIplSwitchToLongMode being declared in
>[PcdsFeatureFlag.IA32, PcdsFeatureFlag.X64] in MdeModulePkg.dsc
>
> Now, an alternative quick-fix would be to move the PEIM LockBoxLib
> mapping into a [LibraryClasses.IA32.PEIM, LibraryClasses.X64.PEIM]
> section. But that would leave NvmExpressPei unbuildable on anything
> not IA32/X64.
>
> Another option would be to add default declaration (for all other
> architectures) of FALSE for PcdDxeIplSwitchToLongMode in
> MdeModulePkg.dec, but the current way this is expressed seems to treat
> this as an architecture-specific feature (which it is).
>
> What I believe would be the cleanest solution would be to abstract
> NvmExpressPei to the point where it can function without the LockBoxLib.
> But regardless, it does not look valid to me for something as
> architecture-specific as MdeModulePkg/Library/SmmLockBoxLib/ to live
> under .common sections in the .dsc. (And if this changes at some
> point, because we implement an ARM/AARCH64 equivalent based on
> StandaloneMmPkg, we will need a major refactoring of that library
> anyway.)
>
> /
> Leif
>
> MdeModulePkg/MdeModulePkg.dsc | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MdeModulePkg/MdeModulePkg.dsc
> b/MdeModulePkg/MdeModulePkg.dsc index 6cd1727a0d..6e27e9cb68 100644
> --- a/MdeModulePkg/MdeModulePkg.dsc
> +++ b/MdeModulePkg/MdeModulePkg.dsc
> @@ -178,6 +178,7 @@ [LibraryClasses.common.MM_STANDALONE]
> [LibraryClasses.ARM, LibraryClasses.AARCH64]
>ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
>ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
> + LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
>
>#
># It is not possible to prevent ARM compiler calls to generic intrinsic
> functions.
>
I think this patch is exactly the right solution.
The code added in commit 05fd2a926833 is gated by (BootMode ==
BOOT_ON_S3_RESUME). That condition can never evaluate to TRUE on ARM/AARCH64,
presently. Accordingly, the stated goal of the commit doesn't apply to
ARM/AARCH64:
The purpose is to perform an on-demand (partial) NVM Express device
enumeration/initialization to benefit the S3 resume performance.
Given that the RestoreLockBox() calls are never reached (which is correct, by
design, at the present level of ACPI S3 enablement in edk2 for ARM/AARCH64),
causing the lockbox APIs to "do nothing beyond compile" is exactly right. IMO
anyway.
Once ARM/AARCH64 grow S3 support, a functional and secure LockBox will have to
be part of that. Perhaps it will use "standalone MM"; I'm not sure. The point
is, once the goal of the commit starts applying to ARM/AARCH64, a functional
LockBox will have been implemented for ARM/AARCH64; and that lib instance will
certainly not depend on PcdDxeIplSwitchToLongMode.
Until such time, this patch is fine.
Reviewed-by: Laszlo Ersek
Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH V2 09/17] OvmfPkg/PlatformDebugLibIoPort: Add a new api DebugVPrint
On 03/15/19 06:17, Zhichao Gao wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
>
> Add a new api DebugVPrint implementation in the
> DebugLib instance. This api would expose a print
> routine with VaList parameter.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao
> Cc: Jordan Justen
> Cc: Laszlo Ersek
> Cc: Ard Biesheuvel
> Cc: Liming Gao
> Cc: Sean Brogan
> Cc: Michael Turner
> Cc: Bret Barkelew
> ---
> OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c | 38
> ---
> 1 file changed, 33 insertions(+), 5 deletions(-)
>
> diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
> b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
> index 36cde54976..74013c28a2 100644
> --- a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
> +++ b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
> @@ -2,7 +2,7 @@
>Base Debug library instance for QEMU debug port.
>It uses PrintLib to send debug messages to a fixed I/O port.
>
> - Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
> + Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>Copyright (c) 2012, Red Hat, Inc.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
> @@ -51,9 +51,38 @@ DebugPrint (
>IN CONST CHAR8 *Format,
>...
>)
> +{
> + VA_LIST Marker;
> +
> + VA_START (Marker, Format);
> + DebugVPrint (ErrorLevel, Format, Marker);
> + VA_END (Marker);
> +}
> +
> +
> +/**
> + Prints a debug message to the debug output device if the specified error
> level is enabled.
> +
> + If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib function
> + GetDebugPrintErrorLevel (), then print the message specified by Format and
> the
> + associated variable argument list to the debug output device.
> +
> + If Format is NULL, then ASSERT().
> +
> + @param ErrorLevelThe error level of the debug message.
> + @param FormatFormat string for the debug message to print.
> + @param VaListMarker VA_LIST marker for the variable argument list.
> +
> +**/
> +VOID
> +EFIAPI
> +DebugVPrint (
> + IN UINTNErrorLevel,
> + IN CONST CHAR8 *Format,
> + IN VA_LIST VaListMarker
> + )
> {
>CHAR8Buffer[MAX_DEBUG_MESSAGE_LENGTH];
> - VA_LIST Marker;
>UINTNLength;
>
>//
> @@ -72,9 +101,7 @@ DebugPrint (
>//
>// Convert the DEBUG() message to an ASCII String
>//
> - VA_START (Marker, Format);
> - Length = AsciiVSPrint (Buffer, sizeof (Buffer), Format, Marker);
> - VA_END (Marker);
> + Length = AsciiVSPrint (Buffer, sizeof (Buffer), Format, VaListMarker);
>
>//
>// Send the print string to the debug I/O port
> @@ -270,6 +297,7 @@ DebugPrintLevelEnabled (
>return (BOOLEAN) ((ErrorLevel & PcdGet32(PcdFixedDebugPrintErrorLevel)) !=
> 0);
> }
>
> +
> /**
>Return the result of detecting the debug I/O port device.
>
>
Thanks for addressing my v1 comments.
Reviewed-by: Laszlo Ersek
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v4] UefiCpuPkg\CpuSmm: Save & restore CR2 on-demand paging in SMM
On 03/18/19 15:38, nkvangup wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1593
>
> For every SMI occurrence, save and restore CR2 register only when SMM
> on-demand paging support is enabled in 64 bit operation mode.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Vanguput Narendra K
> Cc: Eric Dong
> Cc: Ray Ni
> Cc: Laszlo Ersek
> Cc: Yao Jiewen
> ---
> UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c | 22 ++
> UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c | 2 +-
> 2 files changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> index 3b0b3b52ac..0c07b31c4f 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> @@ -28,6 +28,7 @@ UINTN mSemaphoreSize;
> SPIN_LOCK *mPFLock = NULL;
> SMM_CPU_SYNC_MODE mCpuSmmSyncMode;
> BOOLEAN mMachineCheckSupported = FALSE;
> +BOOLEAN mCpuSmmStaticPageTable = TRUE;
Hmmm. This change is a bit daring, but I think it could be valid.
- In the IA32 build, mCpuSmmStaticPageTable would never be modified, or
read, by *preexistent* code (because all that code is in X64/PageTbl.c).
And the new code, added by this patch, would (presumably) work fine,
with the initial TRUE value.
- In the X64 build, the preexistent code would never read the initial
value (which we now set to TRUE here), i.e. before overwriting the
variable from the PCD -- because that would mean a bug in the
preexistent code. (Well, unless that code relied on the zero initial
value of the variable).
(1) I think I'd like to defer on this to other UefiCpuPkg reviewers.
Honestly I find this style questionable. It makes me feel uncomfortable.
I'd prefer the new APIs with the separate IA32/X64 implementations that
I suggested in my v2 review. But if other reviewers like this one
better, I won't mind.
(After hearing their opinions, I'd attempt to find the time to
regression test the patch (or maybe v5), too.)
Assuming other reviewers prefer this approach over my suggestion, I have
some other comments:
>
> /**
>Performs an atomic compare exchange operation to get semaphore.
> @@ -,10 +1112,13 @@ SmiRendezvous (
>
>ASSERT(CpuIndex < mMaxNumberOfCpus);
>
> - //
> - // Save Cr2 because Page Fault exception in SMM may override its value
> - //
> - Cr2 = AsmReadCr2 ();
> +if (!mCpuSmmStaticPageTable) {
> +//
> +// Save and restore Cr2 when using on-demand paging for above 4G memory
> because Page Fault
> +// exception in SMM may override its value
> +//
> +Cr2 = AsmReadCr2 ();
> + }
(2) The indentation of the "if" is broken.
(3) Given that we're already using two comment lines, I'd suggest not
exceeding 80 characters per line.
>
>//
>// Perform CPU specific entry hooks
> @@ -1253,10 +1257,12 @@ SmiRendezvous (
>
> Exit:
>SmmCpuFeaturesRendezvousExit (CpuIndex);
> - //
> - // Restore Cr2
> - //
> - AsmWriteCr2 (Cr2);
> +if (!mCpuSmmStaticPageTable) {
(4) same as (2).
> +//
> +// Restore Cr2
> +//
> +AsmWriteCr2 (Cr2);
> + }
> }
>
> /**
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> index 2c77cb47a4..e444b8a031 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> @@ -21,7 +21,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
>
> LIST_ENTRY mPagePool =
> INITIALIZE_LIST_HEAD_VARIABLE (mPagePool);
> BOOLEAN m1GPageTableSupport = FALSE;
> -BOOLEAN mCpuSmmStaticPageTable;
> +extern BOOLEAN mCpuSmmStaticPageTable;
(5) This is generally not great style, and it conflicts with the
existent code of this driver. Namely, declarations of variables with
file scope, static storage duration, and external linkage, should go
into "PiSmmCpuDxeSmm.h"-- we already got a bunch of them there.
Thanks
Laszlo
>
> /**
>Disable CET.
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH V3 09/17] OvmfPkg/PlatformDebugLibIoPort: Add new APIs
On 03/19/19 16:25, Zhichao Gao wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
>
> Add new APIs' implementation (DebugVPrint, DebugBPrint)
> in the DebugLib instance. These APIs would expose print
> routines with VaList parameter and BaseList parameter.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao
> Cc: Jordan Justen
> Cc: Laszlo Ersek
> Cc: Ard Biesheuvel
> Cc: Liming Gao
> Cc: Sean Brogan
> Cc: Michael Turner
> Cc: Bret Barkelew
> ---
> OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c | 106
> +-
> 1 file changed, 101 insertions(+), 5 deletions(-)
>
> diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
> b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
> index 36cde54976..cda35faf66 100644
> --- a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
> +++ b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
> @@ -2,7 +2,7 @@
>Base Debug library instance for QEMU debug port.
>It uses PrintLib to send debug messages to a fixed I/O port.
>
> - Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
> + Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>Copyright (c) 2012, Red Hat, Inc.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
> @@ -29,6 +29,12 @@
> //
> #define MAX_DEBUG_MESSAGE_LENGTH 0x100
>
> +//
> +// VA_LIST can not initialize to NULL for all compiler, so we use this to
> +// indicate a null VA_LIST
> +//
> +VA_LIST mVaListNull;
> +
> /**
>Prints a debug message to the debug output device if the specified error
> level is enabled.
>
> @@ -51,9 +57,41 @@ DebugPrint (
>IN CONST CHAR8 *Format,
>...
>)
> +{
> + VA_LIST Marker;
> +
> + VA_START (Marker, Format);
> + DebugVPrint (ErrorLevel, Format, Marker);
> + VA_END (Marker);
> +}
> +
> +
> +/**
> + Prints a debug message to the debug output device if the specified
> + error level is enabled base on Null-terminated format string and a
> + VA_LIST argument list or a BASE_LIST argument list.
> +
> + If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib function
> + GetDebugPrintErrorLevel (), then print the message specified by Format and
> + the associated variable argument list to the debug output device.
> +
> + If Format is NULL, then ASSERT().
> +
> + @param ErrorLevel The error level of the debug message.
> + @param Format Format string for the debug message to print.
> + @param VaListMarkerVA_LIST marker for the variable argument list.
> + @param BaseListMarker BASE_LIST marker for the variable argument list.
> +
> +**/
> +VOID
> +DebugPrintMarker (
> + IN UINTN ErrorLevel,
> + IN CONST CHAR8 *Format,
> + IN VA_LIST VaListMarker,
> + IN BASE_LIST BaseListMarker
> + )
> {
>CHAR8Buffer[MAX_DEBUG_MESSAGE_LENGTH];
> - VA_LIST Marker;
>UINTNLength;
>
>//
> @@ -72,9 +110,11 @@ DebugPrint (
>//
>// Convert the DEBUG() message to an ASCII String
>//
> - VA_START (Marker, Format);
> - Length = AsciiVSPrint (Buffer, sizeof (Buffer), Format, Marker);
> - VA_END (Marker);
> + if (BaseListMarker == NULL) {
> +Length = AsciiVSPrint (Buffer, sizeof (Buffer), Format, VaListMarker);
> + } else {
> +Length = AsciiBSPrint (Buffer, sizeof (Buffer), Format, BaseListMarker);
> + }
>
>//
>// Send the print string to the debug I/O port
> @@ -83,6 +123,62 @@ DebugPrint (
> }
>
>
> +/**
> + Prints a debug message to the debug output device if the specified
> + error level is enabled.
> +
> + If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib function
> + GetDebugPrintErrorLevel (), then print the message specified by Format and
> + the associated variable argument list to the debug output device.
> +
> + If Format is NULL, then ASSERT().
> +
> + @param ErrorLevelThe error level of the debug message.
> + @param FormatFormat string for the debug message to print.
> + @param VaListMarker VA_LIST marker for the variable argument list.
> +
> +**/
> +VOID
> +EFIAPI
> +DebugVPrint (
> + IN UINTN ErrorLevel,
> + IN CONST CHAR8 *Format,
> + IN VA_LIST VaListMarker
> + )
> +{
> + DebugPrintMarker (ErrorLevel, Format, VaListMarker, NULL);
> +}
> +
> +
> +/**
> + Prints a debug message to the debug output device if the specified
> + error level is enabled.
> + This function use BASE_LIST which would provide a more compatible
> + service than VA_LIST.
> +
> + If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib function
> + GetDebugPrintErrorLevel (), then print the message specified by Format and
> + the associated variable argument list to the debug output device.
> +
> + If Format is NULL, then ASSERT().
> +
> + @param ErrorLevel The error level of the debug message.
> + @par
[edk2] [PATCH] BaseTools: Add embedded driver support to GenerateCapsule.py
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Tomas Pilar
---
.../Source/Python/Capsule/GenerateCapsule.py | 25 ---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/BaseTools/Source/Python/Capsule/GenerateCapsule.py
b/BaseTools/Source/Python/Capsule/GenerateCapsule.py
index 7b08918857..4b275b092b 100644
--- a/BaseTools/Source/Python/Capsule/GenerateCapsule.py
+++ b/BaseTools/Source/Python/Capsule/GenerateCapsule.py
@@ -9,8 +9,7 @@
# system firmware or device firmware for integrated devices. In order to
# keep the tool as simple as possible, it has the following limitations:
# * Do not support multiple payloads in a capsule.
-# * Do not support optional drivers in a capsule.
-# * Do not support vendor code bytes in a capsule.
+# * Support at most one optional driver in a capsule.
#
# Copyright (c) 2018, Intel Corporation. All rights reserved.
# This program and the accompanying materials
@@ -236,6 +235,12 @@ if __name__ == '__main__':
help = "Input binary payload filename.")
parser.add_argument("-o", "--output", dest = 'OutputFile', type =
argparse.FileType('wb'),
help = "Output filename.")
+
+#
+# Add optional embedded driver and vendor code arguments
+#
+parser.add_argument("--driver", dest = 'Driver', type =
argparse.FileType('rb'),
+help = "Input binary embedded driver to package
alongside the image")
#
# Add group for -e and -d flags that are mutually exclusive and required
#
@@ -355,7 +360,7 @@ if __name__ == '__main__':
parser.error ('the following option is not supported for dumpinfo
operations: --output')
#
-# Read binary input file
+# Read binary input files
#
try:
if args.Verbose:
@@ -366,6 +371,17 @@ if __name__ == '__main__':
print ('GenerateCapsule: error: can not read binary input file
{File}'.format (File = args.InputFile.name))
sys.exit (1)
+DriverBuffer = b''
+if args.Driver:
+try:
+if args.Verbose:
+print ('Read binary embedded driver {File}'.format (File =
args.Driver.name))
+DriverBuffer = args.Driver.read ()
+args.Driver.close ()
+except:
+print ('GenerateCapsule: error: can not read supplied binary
embedded driver file {File}'.format (File = args.Driver.name))
+sys.exit (1)
+
#
# Create objects
#
@@ -423,6 +439,9 @@ if __name__ == '__main__':
try:
FmpCapsuleHeader.AddPayload (args.Guid, Result, HardwareInstance =
args.HardwareInstance)
+if args.Driver:
+FmpCapsuleHeader.AddEmbeddedDriver(DriverBuffer)
+
Result = FmpCapsuleHeader.Encode ()
if args.Verbose:
FmpCapsuleHeader.DumpInfo ()
--
2.17.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v4] UefiCpuPkg\CpuSmm: Save & restore CR2 on-demand paging in SMM
Hi Laszlo,
Thanks for your comments.
For your comment #1, My thoughts are when we add two functions (SaveCr2 &
RestoreCr2). For IA32, it actually don't save and restore, simply returns.
Later, it might be confusing unless if we know the background and gone through
64 bit supported code. And also its kind of adding more code while we have
alternate solution.
In the proposed changes, I felt its straight forward and light changes needed.
Yes, I would like to hear from other reviewers too to take the right option.
For comments #2 & #4, Yes, I notified it, waiting to update along with other
comments.
For comments #3 & #5, will consider them. Will adjust the no. characters and
will move extern of mCpuSmmStaticPageTable to PiSmmCpuDxeSmm.h file.
Thanks,
Naren
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Wednesday, March 20, 2019 10:01 PM
To: Vanguput, Narendra K ;
edk2-devel@lists.01.org
Cc: Yao, Jiewen ; Dong, Eric
Subject: Re: [edk2] [PATCH v4] UefiCpuPkg\CpuSmm: Save & restore CR2 on-demand
paging in SMM
On 03/18/19 15:38, nkvangup wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1593
>
> For every SMI occurrence, save and restore CR2 register only when SMM
> on-demand paging support is enabled in 64 bit operation mode.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Vanguput Narendra K
> Cc: Eric Dong
> Cc: Ray Ni
> Cc: Laszlo Ersek
> Cc: Yao Jiewen
> ---
> UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c | 22 ++
> UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c | 2 +-
> 2 files changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> index 3b0b3b52ac..0c07b31c4f 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> @@ -28,6 +28,7 @@ UINTN mSemaphoreSize;
> SPIN_LOCK *mPFLock = NULL;
> SMM_CPU_SYNC_MODE mCpuSmmSyncMode;
> BOOLEAN mMachineCheckSupported = FALSE;
> +BOOLEAN mCpuSmmStaticPageTable = TRUE;
Hmmm. This change is a bit daring, but I think it could be valid.
- In the IA32 build, mCpuSmmStaticPageTable would never be modified, or read,
by *preexistent* code (because all that code is in X64/PageTbl.c).
And the new code, added by this patch, would (presumably) work fine, with the
initial TRUE value.
- In the X64 build, the preexistent code would never read the initial value
(which we now set to TRUE here), i.e. before overwriting the variable from the
PCD -- because that would mean a bug in the preexistent code. (Well, unless
that code relied on the zero initial value of the variable).
(1) I think I'd like to defer on this to other UefiCpuPkg reviewers.
Honestly I find this style questionable. It makes me feel uncomfortable.
I'd prefer the new APIs with the separate IA32/X64 implementations that I
suggested in my v2 review. But if other reviewers like this one better, I won't
mind.
(After hearing their opinions, I'd attempt to find the time to regression test
the patch (or maybe v5), too.)
Assuming other reviewers prefer this approach over my suggestion, I have some
other comments:
>
> /**
>Performs an atomic compare exchange operation to get semaphore.
> @@ -,10 +1112,13 @@ SmiRendezvous (
>
>ASSERT(CpuIndex < mMaxNumberOfCpus);
>
> - //
> - // Save Cr2 because Page Fault exception in SMM may override its
> value
> - //
> - Cr2 = AsmReadCr2 ();
> +if (!mCpuSmmStaticPageTable) {
> +//
> +// Save and restore Cr2 when using on-demand paging for above 4G memory
> because Page Fault
> +// exception in SMM may override its value
> +//
> +Cr2 = AsmReadCr2 ();
> + }
(2) The indentation of the "if" is broken.
(3) Given that we're already using two comment lines, I'd suggest not exceeding
80 characters per line.
>
>//
>// Perform CPU specific entry hooks @@ -1253,10 +1257,12 @@
> SmiRendezvous (
>
> Exit:
>SmmCpuFeaturesRendezvousExit (CpuIndex);
> - //
> - // Restore Cr2
> - //
> - AsmWriteCr2 (Cr2);
> +if (!mCpuSmmStaticPageTable) {
(4) same as (2).
> +//
> +// Restore Cr2
> +//
> +AsmWriteCr2 (Cr2);
> + }
> }
>
> /**
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> index 2c77cb47a4..e444b8a031 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> @@ -21,7 +21,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
>
> LIST_ENTRY mPagePool =
> INITIALIZE_LIST_HEAD_VARIABLE (mPagePool);
> BOOLEAN m1GPageTableSupport = FALSE;
> -BOOLEAN mCpuSmmStaticPageTable;
> +extern BOOLE
Re: [edk2] [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64 in .dsc
On Wed, Mar 20, 2019 at 03:51:39PM +0100, Laszlo Ersek wrote:
> Hi Leif,
>
> On 03/18/19 15:56, Leif Lindholm wrote:
> > Commit 05fd2a926833
> > ("MdeModulePkg/NvmExpressPei: Consume S3StorageDeviceInitList LockBox")
> > added a dependency on LockBoxLib to NvmExpressPei, causing builds using
> > MdeModulePkg.dsc to fail on architectures other than IA32/X64 with
> > missing reference to
> > gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode.
> >
> > Add a resolution for LockBoxNullLib for ARM/AARCH64 to restore builds.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Leif Lindholm
> > ---
> >
> > Note: this patch hides the symptom, but this isn't really the fix I
> > would like to see.
> >
> > The build error is caused by the chain of:
> > 1) NvmExpressPei depending on LockBoxLib
> > 2) LockBoxLib being mapped to SmmLockBoxPeiLib in
> > [LibraryClasses.common.PEIM]
> > 3) SmmLockBoxPeiLib depending on PcdDxeIplSwitchToLongMode
> > 4) PcdDxeIplSwitchToLongMode being declared in
> >[PcdsFeatureFlag.IA32, PcdsFeatureFlag.X64] in MdeModulePkg.dsc
> >
> > Now, an alternative quick-fix would be to move the PEIM LockBoxLib mapping
> > into a [LibraryClasses.IA32.PEIM, LibraryClasses.X64.PEIM]
> > section. But that would leave NvmExpressPei unbuildable on anything not
> > IA32/X64.
> >
> > Another option would be to add default declaration (for all other
> > architectures) of FALSE for PcdDxeIplSwitchToLongMode in MdeModulePkg.dec,
> > but the current way this is expressed seems to treat this as an
> > architecture-specific feature (which it is).
> >
> > What I believe would be the cleanest solution would be to abstract
> > NvmExpressPei to the point where it can function without the LockBoxLib.
> > But regardless, it does not look valid to me for something as
> > architecture-specific as MdeModulePkg/Library/SmmLockBoxLib/ to live under
> > .common sections in the .dsc. (And if this changes at some point, because
> > we implement an ARM/AARCH64 equivalent based on StandaloneMmPkg, we will
> > need
> > a major refactoring of that library anyway.)
> >
> > /
> > Leif
> >
> > MdeModulePkg/MdeModulePkg.dsc | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
> > index 6cd1727a0d..6e27e9cb68 100644
> > --- a/MdeModulePkg/MdeModulePkg.dsc
> > +++ b/MdeModulePkg/MdeModulePkg.dsc
> > @@ -178,6 +178,7 @@ [LibraryClasses.common.MM_STANDALONE]
> > [LibraryClasses.ARM, LibraryClasses.AARCH64]
> >ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
> >ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
> > + LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
> >
> >#
> ># It is not possible to prevent ARM compiler calls to generic intrinsic
> > functions.
> >
>
> I think this patch is exactly the right solution.
>
> The code added in commit 05fd2a926833 is gated by (BootMode ==
> BOOT_ON_S3_RESUME). That condition can never evaluate to TRUE on
> ARM/AARCH64, presently. Accordingly, the stated goal of the commit
> doesn't apply to ARM/AARCH64:
>
> The purpose is to perform an on-demand (partial) NVM Express device
> enumeration/initialization to benefit the S3 resume performance.
>
> Given that the RestoreLockBox() calls are never reached (which is
> correct, by design, at the present level of ACPI S3 enablement in edk2
> for ARM/AARCH64), causing the lockbox APIs to "do nothing beyond
> compile" is exactly right. IMO anyway.
>
> Once ARM/AARCH64 grow S3 support, a functional and secure LockBox will
> have to be part of that. Perhaps it will use "standalone MM"; I'm not
> sure. The point is, once the goal of the commit starts applying to
> ARM/AARCH64, a functional LockBox will have been implemented for
> ARM/AARCH64; and that lib instance will certainly not depend on
> PcdDxeIplSwitchToLongMode.
>
> Until such time, this patch is fine.
OK, I buy that argument.
*But* I still think the IA32/X64 specific library mappings should be
moved out of .common LibraryClass sections.
Regards,
Leif
> Reviewed-by: Laszlo Ersek
>
> Thanks
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [RFC 0/3] Enable runtime serial debug for ArmVirtQemu
On 03/20/19 13:16, Heyi Guo wrote: > > > On 2019/3/20 17:55, Laszlo Ersek wrote: >> If we don't have to flatten a ridiculous amount of other library code >> into the RuntimePrepare() function, I think such flattening would be a >> viable approach. We've run into this constructor loop several times >> before, and -- if I remember correctly anyway! -- one approach has been >> to declare SerialPortLib the "lowest level abstraction", and make the >> affected lib instance self-contained. > In my RFC, we need to use gDS which is from > DxeServicesTableLib->EfiGetSystemConfigurationTable()->UefiLib, so that > we need to flatten EfiGetSystemConfigurationTable(). I think that's acceptable. > And > gDS->SetMemorySpaceAttributes() actually relies on > gEfiCpuArchProtocolGuid or it will return EFI_NOT_AVAILABLE_YET. This is a valid dependency (even the PI spec spells it out). The way to deal with it is to add gEfiCpuArchProtocolGuid to the DEPEX section of the INF file -- this is possible for INF files of library instances as well, but you have to be careful about module types. Please see the INF spec on that. Once you do this, modules linked against the lib instance will inherit the lib instance's DEPEX, and "and it" together with the rest of their DEPEX. IOW using the library will delay the containing driver module until the CPU Arch protocol is available in the protocol database. Then the constructor can rely on the related DXE services. Thanks Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] PATCH] Change EDK II to BSD+Patent License
On 03/20/19 14:03, Lars Kurth wrote:
>
>
> On 15/03/2019, 17:48, "Lars Kurth" wrote:
>
>
>
> On 15/03/2019, 10:18, "Julien Grall" wrote:
>
> >
> > EDK2 is converting the full copyright in each file to SDPX
> identifier. While the
> > copyright looks like an MIT license, it has never been
> confirmed. Andrew Cooper
> > suggested you might be able to confirm.
> >
> > Is there a web-link to the files/repos such that I don’t have to
> clone the repo
> > Lars
>
> Here an example of files from Xen public headers:
>
>
> https://xenbits.xen.org/gitweb/?p=xen.git;a=tree;f=xen/include/public;h=0618b0134d2b9babcba71a3f0f86be5a84468b50;hb=HEAD
>
> OK, this makes this easy then. Because in all likelihood, the files were
> copied from xen/include/public and then the COPYING file
> https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/COPYING
> applies, which states that everything in this directory is MIT, unless stated
> otherwise in the file.
>
> So as long as someone confirms that the files in OvmfPkg/Include came
> from xen/include/public, this is a clear case of a MIT license
> If they are files from other directories in Xen, check the COPYING file
> in the original directory (or if there is none in the parent directory) and
> check the COPYING file
>
> I am not so clear about where the files in XenBusDxe came from, but the
> same principle applies.
>
> If someone groups these files by "original directory in Xen" to File ...
> I am happy to do a final sanity check and sign it off and/or deal with any
> unclear cases
>
> Nobody stepped up, sigh.
Sorry, no capacity. I suggested to handle this in a separate TianoCore
BZ, with much more focused context. I asked Mike to file that BZ (he had
offered earlier, if I understood correctly), or else to notify me to
file it.
> I am also VERY confused by this thread.
Not surprising -- this is a side topic in the thread we're in.
> Is the issue that you don’t trust that the license specified in the files are
> correct?
No -- the question is whether the license included in the files
mentioned is indeed the MIT license, suitable for a replacement with the
appropriate SPDX license ID.
>
> > (2.2.2) Files that seem to be covered by the MIT license.
> >
> >OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h
>
> I can't identify where in the Xen tree this file came from. There is no
> corresponding xen.h file in the Xen tree at [xen.git] / xen / include /
> public / arch-arm /
> @Julien, @Anthony: can you clarify
This file was first added to edk2 in b94c3ac93d57 ("Ovmf/Xen: implement
XenHypercallLib for ARM", 2015-02-28).
https://github.com/tianocore/edk2/commit/b94c3ac93d57
And from the Xen project (I think), it was Reviewed-by: Stefano
Stabellini . (I vaguely recall that
Stefano's emai has changed since.)
>
> >OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen-x86_32.h
> >OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen-x86_64.h
> >OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen.h
> >OvmfPkg/Include/IndustryStandard/Xen/event_channel.h
> >OvmfPkg/Include/IndustryStandard/Xen/grant_table.h
> >OvmfPkg/Include/IndustryStandard/Xen/hvm/hvm_op.h
> >OvmfPkg/Include/IndustryStandard/Xen/hvm/params.h
> >OvmfPkg/Include/IndustryStandard/Xen/io/blkif.h
> >OvmfPkg/Include/IndustryStandard/Xen/io/console.h
> >OvmfPkg/Include/IndustryStandard/Xen/io/protocols.h
> >OvmfPkg/Include/IndustryStandard/Xen/io/ring.h
> >OvmfPkg/Include/IndustryStandard/Xen/io/xenbus.h
> >OvmfPkg/Include/IndustryStandard/Xen/io/xs_wire.h
> >OvmfPkg/Include/IndustryStandard/Xen/memory.h
> >OvmfPkg/Include/IndustryStandard/Xen/xen-compat.h
> >OvmfPkg/Include/IndustryStandard/Xen/xen.h
>
> These all appear to originate from [xen.git] / xen / include / public
> In the Xen tree these all have explicit MIT licenses, which implies that the
> license headers are indeed correct.
Thanks -- so can we replace the license blocks with
SPDX-License-Identifier: MIT
? (See e.g. .)
But, again, this should be discussed in that separate BZ then.
>
> >OvmfPkg/XenBusDxe/XenBus.c
> >OvmfPkg/XenBusDxe/XenStore.c
> >OvmfPkg/XenBusDxe/XenStore.h
>
> I do not know where these files come from. The files do not appear to come
> from a Xen project repo.
See commit a9090a94bb4a ("OvmfPkg/XenBusDxe: Add XenStore client
implementation", 2014-10-29), by Anthony.
https://github.com/tianocore/edk2/commit/a9090a94bb4a
The commit message states,
> Orig
Re: [edk2] PATCH] Change EDK II to BSD+Patent License
Hi,
On 20/03/2019 18:25, Laszlo Ersek wrote:
On 03/20/19 14:03, Lars Kurth wrote:
On 15/03/2019, 17:48, "Lars Kurth" wrote:
On 15/03/2019, 10:18, "Julien Grall" wrote:
Is the issue that you don’t trust that the license specified in the files are
correct?
No -- the question is whether the license included in the files
mentioned is indeed the MIT license, suitable for a replacement with the
appropriate SPDX license ID.
> (2.2.2) Files that seem to be covered by the MIT license.
>
>OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h
I can't identify where in the Xen tree this file came from. There is no
corresponding xen.h file in the Xen tree at [xen.git] / xen / include / public
/ arch-arm /
@Julien, @Anthony: can you clarify
This file was first added to edk2 in b94c3ac93d57 ("Ovmf/Xen: implement
XenHypercallLib for ARM", 2015-02-28).
It is a copy of public/arch-arm.h. Somehow all the other projects created the
file under arch-arm/xen.h.
https://github.com/tianocore/edk2/commit/b94c3ac93d57
And from the Xen project (I think), it was Reviewed-by: Stefano
Stabellini . (I vaguely recall that
Stefano's emai has changed since.)
That's correct. He is working for Xilinx now.
>OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen-x86_32.h
>OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen-x86_64.h
>OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen.h
>OvmfPkg/Include/IndustryStandard/Xen/event_channel.h
>OvmfPkg/Include/IndustryStandard/Xen/grant_table.h
>OvmfPkg/Include/IndustryStandard/Xen/hvm/hvm_op.h
>OvmfPkg/Include/IndustryStandard/Xen/hvm/params.h
>OvmfPkg/Include/IndustryStandard/Xen/io/blkif.h
>OvmfPkg/Include/IndustryStandard/Xen/io/console.h
>OvmfPkg/Include/IndustryStandard/Xen/io/protocols.h
>OvmfPkg/Include/IndustryStandard/Xen/io/ring.h
>OvmfPkg/Include/IndustryStandard/Xen/io/xenbus.h
>OvmfPkg/Include/IndustryStandard/Xen/io/xs_wire.h
>OvmfPkg/Include/IndustryStandard/Xen/memory.h
>OvmfPkg/Include/IndustryStandard/Xen/xen-compat.h
>OvmfPkg/Include/IndustryStandard/Xen/xen.h
These all appear to originate from [xen.git] / xen / include / public
In the Xen tree these all have explicit MIT licenses, which implies that the
license headers are indeed correct.
Thanks -- so can we replace the license blocks with
SPDX-License-Identifier: MIT
? (See e.g. .)
I spoke with Lars today, this identifier would be suitable for the headers.
Cheers,
--
Julien Grall
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] SerialDxe with BaseSerialPortLib16550 and standard PC com port
What are the PCDs settings you are using for the
SerialPortLib?
Thanks,
Mike
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> On Behalf Of Jacob Burkholder
> Sent: Tuesday, March 19, 2019 7:06 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] SerialDxe with BaseSerialPortLib16550 and
> standard PC com port
>
> Greetings!
>
> I had trouble using SerialDxe.efi with
> BaseSerialPortLib16550 on a standard
> PC com port (com1). The PC is an asrock motherboard
> running whatever EFI
> bios it came with. I changed MdeModulePkg.dsc so that
> BaseSerialPortLib16550 would be used instead of
> BaseSerialPortLibNull and
> then rebuilt SerialDxe.efi and loaded and started it
> using
> BootServices->{LoadImage,StartImage}.
>
> Output works but input doesn't work, typed characters
> aren't received by
> the uart. I looked at the code briefly and it seems like
> the uart isn't
> initialized properly. I used this script to get input
> working (the
> commands should be self explanatory, they're not efi
> shell commands though):
>
> image SerialDxe.efi
> outb 0x3fb 0x83
> outw 0x3f8 1
> outb 0x3fb 0x3
> outb 0x3fc 0x3
>
> Any chance it can be fixed upstream?
>
> Thanks,
>
> Jake
> ___
> 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] BaseTools: Add embedded driver support to GenerateCapsule.py
Hi Tomas,
Thanks for the contribution. I agree we need this feature.
We have been working on updates to GenerateCapsule that
add support for one or more embedded drivers and multiple
payloads and the option to provide all the configuration
information in a JSON file. It also extends decode
and dumpinfo to show the embedded drivers. We will post
patch with all those features very soon.
Thanks,
Mike
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> On Behalf Of Tomas Pilar (tpilar)
> Sent: Wednesday, March 20, 2019 10:18 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [PATCH] BaseTools: Add embedded driver
> support to GenerateCapsule.py
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Tomas Pilar
> ---
> .../Source/Python/Capsule/GenerateCapsule.py | 25
> ---
> 1 file changed, 22 insertions(+), 3 deletions(-)
>
> diff --git
> a/BaseTools/Source/Python/Capsule/GenerateCapsule.py
> b/BaseTools/Source/Python/Capsule/GenerateCapsule.py
> index 7b08918857..4b275b092b 100644
> --- a/BaseTools/Source/Python/Capsule/GenerateCapsule.py
> +++ b/BaseTools/Source/Python/Capsule/GenerateCapsule.py
> @@ -9,8 +9,7 @@
> # system firmware or device firmware for integrated
> devices. In order to
> # keep the tool as simple as possible, it has the
> following limitations:
> # * Do not support multiple payloads in a capsule.
> -# * Do not support optional drivers in a capsule.
> -# * Do not support vendor code bytes in a capsule.
> +# * Support at most one optional driver in a capsule.
> #
> # Copyright (c) 2018, Intel Corporation. All rights
> reserved.
> # This program and the accompanying materials
> @@ -236,6 +235,12 @@ if __name__ == '__main__':
> help = "Input binary payload
> filename.")
> parser.add_argument("-o", "--output", dest =
> 'OutputFile', type = argparse.FileType('wb'),
> help = "Output filename.")
> +
> +#
> +# Add optional embedded driver and vendor code
> arguments
> +#
> +parser.add_argument("--driver", dest = 'Driver',
> type = argparse.FileType('rb'),
> +help = "Input binary embedded
> driver to package alongside the image")
> #
> # Add group for -e and -d flags that are mutually
> exclusive and required
> #
> @@ -355,7 +360,7 @@ if __name__ == '__main__':
> parser.error ('the following option is not
> supported for dumpinfo operations: --output')
>
> #
> -# Read binary input file
> +# Read binary input files
> #
> try:
> if args.Verbose:
> @@ -366,6 +371,17 @@ if __name__ == '__main__':
> print ('GenerateCapsule: error: can not read
> binary input file {File}'.format (File =
> args.InputFile.name))
> sys.exit (1)
>
> +DriverBuffer = b''
> +if args.Driver:
> +try:
> +if args.Verbose:
> +print ('Read binary embedded driver
> {File}'.format (File = args.Driver.name))
> +DriverBuffer = args.Driver.read ()
> +args.Driver.close ()
> +except:
> +print ('GenerateCapsule: error: can not read
> supplied binary embedded driver file {File}'.format (File
> = args.Driver.name))
> +sys.exit (1)
> +
> #
> # Create objects
> #
> @@ -423,6 +439,9 @@ if __name__ == '__main__':
>
> try:
> FmpCapsuleHeader.AddPayload (args.Guid,
> Result, HardwareInstance = args.HardwareInstance)
> +if args.Driver:
> +
> FmpCapsuleHeader.AddEmbeddedDriver(DriverBuffer)
> +
> Result = FmpCapsuleHeader.Encode ()
> if args.Verbose:
> FmpCapsuleHeader.DumpInfo ()
> --
> 2.17.2
>
> ___
> 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] Change EDK II to BSD+Patent License
On 03/20/19 19:42, Julien Grall wrote:
> Hi,
>
> On 20/03/2019 18:25, Laszlo Ersek wrote:
>> On 03/20/19 14:03, Lars Kurth wrote:
>>> On 15/03/2019, 17:48, "Lars Kurth" wrote:
>>> On 15/03/2019, 10:18, "Julien Grall" wrote:
>>> Is the issue that you don’t trust that the license specified in the
>>> files are correct?
>>
>> No -- the question is whether the license included in the files
>> mentioned is indeed the MIT license, suitable for a replacement with the
>> appropriate SPDX license ID.
>>
>>>
>>> > (2.2.2) Files that seem to be covered by the MIT license.
>>> >
>>> >Â Â Â OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h
>>>
>>> I can't identify where in the Xen tree this file came from. There is
>>> no corresponding xen.h file in the Xen tree at [xen.git] / xen /
>>> include / public / arch-arm /
>>> @Julien, @Anthony: can you clarify
>>
>> This file was first added to edk2 in b94c3ac93d57 ("Ovmf/Xen: implement
>> XenHypercallLib for ARM", 2015-02-28).
>
> It is a copy of public/arch-arm.h. Somehow all the other projects
> created the file under arch-arm/xen.h.
>
>>
>> https://github.com/tianocore/edk2/commit/b94c3ac93d57
>>
>> And from the Xen project (I think), it was Reviewed-by: Stefano
>> Stabellini . (I vaguely recall that
>> Stefano's emai has changed since.)
>
> That's correct. He is working for Xilinx now.
>
>>
>>>
>>> >Â Â Â
>>> OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen-x86_32.h
>>> >Â Â Â
>>> OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen-x86_64.h
>>> >Â Â Â OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen.h
>>> >Â Â Â OvmfPkg/Include/IndustryStandard/Xen/event_channel.h
>>> >Â Â Â OvmfPkg/Include/IndustryStandard/Xen/grant_table.h
>>> >Â Â Â OvmfPkg/Include/IndustryStandard/Xen/hvm/hvm_op.h
>>> >Â Â Â OvmfPkg/Include/IndustryStandard/Xen/hvm/params.h
>>> >Â Â Â OvmfPkg/Include/IndustryStandard/Xen/io/blkif.h
>>> >Â Â Â OvmfPkg/Include/IndustryStandard/Xen/io/console.h
>>> >Â Â Â OvmfPkg/Include/IndustryStandard/Xen/io/protocols.h
>>> >Â Â Â OvmfPkg/Include/IndustryStandard/Xen/io/ring.h
>>> >Â Â Â OvmfPkg/Include/IndustryStandard/Xen/io/xenbus.h
>>> >Â Â Â OvmfPkg/Include/IndustryStandard/Xen/io/xs_wire.h
>>> >Â Â Â OvmfPkg/Include/IndustryStandard/Xen/memory.h
>>> >Â Â Â OvmfPkg/Include/IndustryStandard/Xen/xen-compat.h
>>> >Â Â Â OvmfPkg/Include/IndustryStandard/Xen/xen.h
>>>
>>> These all appear to originate from [xen.git] / xen / include / public
>>> In the Xen tree these all have explicit MIT licenses, which implies
>>> that the license headers are indeed correct.
>>
>> Thanks -- so can we replace the license blocks with
>>
>> Â Â SPDX-License-Identifier: MIT
>>
>> ? (See e.g. .)
>
> I spoke with Lars today, this identifier would be suitable for the headers.
>
> Cheers,
>
Thanks!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v4] UefiCpuPkg\CpuSmm: Save & restore CR2 on-demand paging in SMM
Hi Naren,
I agree with Laszlo's comment for #1. I think separate functions for IA32/X64
are much clear than the current one. I think in current EDK2 codebase, many
similar cases already exits.
Thanks,
Eric
> -Original Message-
> From: Vanguput, Narendra K
> Sent: Thursday, March 21, 2019 1:28 AM
> To: Laszlo Ersek ; edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Dong, Eric ;
> Chinnusamy, Rajkumar K ; Ni, Ray
>
> Subject: RE: [edk2] [PATCH v4] UefiCpuPkg\CpuSmm: Save & restore CR2 on-
> demand paging in SMM
>
> Hi Laszlo,
>
> Thanks for your comments.
>
> For your comment #1, My thoughts are when we add two functions (SaveCr2
> & RestoreCr2). For IA32, it actually don't save and restore, simply returns.
> Later, it might be confusing unless if we know the background and gone
> through 64 bit supported code. And also its kind of adding more code while
> we have alternate solution.
> In the proposed changes, I felt its straight forward and light changes needed.
> Yes, I would like to hear from other reviewers too to take the right option.
>
> For comments #2 & #4, Yes, I notified it, waiting to update along with other
> comments.
>
> For comments #3 & #5, will consider them. Will adjust the no. characters and
> will move extern of mCpuSmmStaticPageTable to PiSmmCpuDxeSmm.h file.
>
> Thanks,
> Naren
>
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, March 20, 2019 10:01 PM
> To: Vanguput, Narendra K ; edk2-
> de...@lists.01.org
> Cc: Yao, Jiewen ; Dong, Eric
> Subject: Re: [edk2] [PATCH v4] UefiCpuPkg\CpuSmm: Save & restore CR2 on-
> demand paging in SMM
>
> On 03/18/19 15:38, nkvangup wrote:
> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1593
> >
> > For every SMI occurrence, save and restore CR2 register only when SMM
> > on-demand paging support is enabled in 64 bit operation mode.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Vanguput Narendra K
> > Cc: Eric Dong
> > Cc: Ray Ni
> > Cc: Laszlo Ersek
> > Cc: Yao Jiewen
> > ---
> > UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c | 22 ++-
> ---
> > UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c | 2 +-
> > 2 files changed, 15 insertions(+), 9 deletions(-)
> >
> > diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> > b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> > index 3b0b3b52ac..0c07b31c4f 100644
> > --- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> > +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> > @@ -28,6 +28,7 @@ UINTN
> > mSemaphoreSize;
> > SPIN_LOCK *mPFLock = NULL;
> > SMM_CPU_SYNC_MODE mCpuSmmSyncMode;
> > BOOLEAN mMachineCheckSupported = FALSE;
> > +BOOLEAN mCpuSmmStaticPageTable = TRUE;
>
> Hmmm. This change is a bit daring, but I think it could be valid.
>
> - In the IA32 build, mCpuSmmStaticPageTable would never be modified, or
> read, by *preexistent* code (because all that code is in X64/PageTbl.c).
> And the new code, added by this patch, would (presumably) work fine, with
> the initial TRUE value.
>
> - In the X64 build, the preexistent code would never read the initial value
> (which we now set to TRUE here), i.e. before overwriting the variable from
> the PCD -- because that would mean a bug in the preexistent code. (Well,
> unless that code relied on the zero initial value of the variable).
>
> (1) I think I'd like to defer on this to other UefiCpuPkg reviewers.
> Honestly I find this style questionable. It makes me feel uncomfortable.
> I'd prefer the new APIs with the separate IA32/X64 implementations that I
> suggested in my v2 review. But if other reviewers like this one better, I
> won't
> mind.
>
> (After hearing their opinions, I'd attempt to find the time to regression test
> the patch (or maybe v5), too.)
>
> Assuming other reviewers prefer this approach over my suggestion, I have
> some other comments:
>
> >
> > /**
> >Performs an atomic compare exchange operation to get semaphore.
> > @@ -,10 +1112,13 @@ SmiRendezvous (
> >
> >ASSERT(CpuIndex < mMaxNumberOfCpus);
> >
> > - //
> > - // Save Cr2 because Page Fault exception in SMM may override its
> > value
> > - //
> > - Cr2 = AsmReadCr2 ();
> > +if (!mCpuSmmStaticPageTable) {
> > +//
> > +// Save and restore Cr2 when using on-demand paging for above 4G
> memory because Page Fault
> > +// exception in SMM may override its value
> > +//
> > +Cr2 = AsmReadCr2 ();
> > + }
>
> (2) The indentation of the "if" is broken.
>
> (3) Given that we're already using two comment lines, I'd suggest not
> exceeding 80 characters per line.
>
> >
> >//
> >// Perform CPU specific entry hooks @@ -1253,10 +1257,12 @@
> > SmiRendezvous (
> >
> > Exit:
> >SmmCpuFeaturesRendezvousExit (CpuIndex);
> > - //
> > - // Restore Cr2
> > - //
> > - AsmWriteCr
Re: [edk2] [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64 in .dsc
Another way to update the file is
[LibraryClasses.EBC]
LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
->
[LibraryClasses.EBC, LibraryClasses.ARM, LibraryClasses.AARCH64]
LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
Thanks,
Star
-Original Message-
From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
Sent: Thursday, March 21, 2019 1:43 AM
To: Laszlo Ersek
Cc: edk2-devel@lists.01.org; ard.biesheu...@linaro.org; Wang, Jian J
; Wu, Hao A ; Ni, Ray
; Zeng, Star ; Andrew Fish
; Kinney, Michael D
Subject: Re: [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64 in .dsc
On Wed, Mar 20, 2019 at 03:51:39PM +0100, Laszlo Ersek wrote:
> Hi Leif,
>
> On 03/18/19 15:56, Leif Lindholm wrote:
> > Commit 05fd2a926833
> > ("MdeModulePkg/NvmExpressPei: Consume S3StorageDeviceInitList
> > LockBox") added a dependency on LockBoxLib to NvmExpressPei, causing
> > builds using MdeModulePkg.dsc to fail on architectures other than
> > IA32/X64 with missing reference to
> > gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode.
> >
> > Add a resolution for LockBoxNullLib for ARM/AARCH64 to restore builds.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Leif Lindholm
> > ---
> >
> > Note: this patch hides the symptom, but this isn't really the fix I
> > would like to see.
> >
> > The build error is caused by the chain of:
> > 1) NvmExpressPei depending on LockBoxLib
> > 2) LockBoxLib being mapped to SmmLockBoxPeiLib in
> > [LibraryClasses.common.PEIM]
> > 3) SmmLockBoxPeiLib depending on PcdDxeIplSwitchToLongMode
> > 4) PcdDxeIplSwitchToLongMode being declared in
> >[PcdsFeatureFlag.IA32, PcdsFeatureFlag.X64] in MdeModulePkg.dsc
> >
> > Now, an alternative quick-fix would be to move the PEIM LockBoxLib
> > mapping into a [LibraryClasses.IA32.PEIM, LibraryClasses.X64.PEIM]
> > section. But that would leave NvmExpressPei unbuildable on anything
> > not IA32/X64.
> >
> > Another option would be to add default declaration (for all other
> > architectures) of FALSE for PcdDxeIplSwitchToLongMode in
> > MdeModulePkg.dec, but the current way this is expressed seems to
> > treat this as an architecture-specific feature (which it is).
> >
> > What I believe would be the cleanest solution would be to abstract
> > NvmExpressPei to the point where it can function without the LockBoxLib.
> > But regardless, it does not look valid to me for something as
> > architecture-specific as MdeModulePkg/Library/SmmLockBoxLib/ to live
> > under .common sections in the .dsc. (And if this changes at some
> > point, because we implement an ARM/AARCH64 equivalent based on
> > StandaloneMmPkg, we will need a major refactoring of that library
> > anyway.)
> >
> > /
> > Leif
> >
> > MdeModulePkg/MdeModulePkg.dsc | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/MdeModulePkg/MdeModulePkg.dsc
> > b/MdeModulePkg/MdeModulePkg.dsc index 6cd1727a0d..6e27e9cb68 100644
> > --- a/MdeModulePkg/MdeModulePkg.dsc
> > +++ b/MdeModulePkg/MdeModulePkg.dsc
> > @@ -178,6 +178,7 @@ [LibraryClasses.common.MM_STANDALONE]
> > [LibraryClasses.ARM, LibraryClasses.AARCH64]
> >ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
> >ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
> > + LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
> >
> >#
> ># It is not possible to prevent ARM compiler calls to generic intrinsic
> > functions.
> >
>
> I think this patch is exactly the right solution.
>
> The code added in commit 05fd2a926833 is gated by (BootMode ==
> BOOT_ON_S3_RESUME). That condition can never evaluate to TRUE on
> ARM/AARCH64, presently. Accordingly, the stated goal of the commit
> doesn't apply to ARM/AARCH64:
>
> The purpose is to perform an on-demand (partial) NVM Express device
> enumeration/initialization to benefit the S3 resume performance.
>
> Given that the RestoreLockBox() calls are never reached (which is
> correct, by design, at the present level of ACPI S3 enablement in edk2
> for ARM/AARCH64), causing the lockbox APIs to "do nothing beyond
> compile" is exactly right. IMO anyway.
>
> Once ARM/AARCH64 grow S3 support, a functional and secure LockBox will
> have to be part of that. Perhaps it will use "standalone MM"; I'm not
> sure. The point is, once the goal of the commit starts applying to
> ARM/AARCH64, a functional LockBox will have been implemented for
> ARM/AARCH64; and that lib instance will certainly not depend on
> PcdDxeIplSwitchToLongMode.
>
> Until such time, this patch is fine.
OK, I buy that argument.
*But* I still think the IA32/X64 specific library mappings should be moved out
of .common LibraryClass sections.
Regards,
Leif
> Reviewed-by: Laszlo Ersek
>
> Thanks
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch MdeModulePkg/Library v1 1/1] MdeModulePkg/UefiBootManangerLib: Fix exception issue
Thanks Ming and Leif.
Reviewed-by: Hao Wu
Patch was committed at 6c27a4d337d0034cecf9f2c05d1f20c342d41e01.
Best Regards,
Hao Wu
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Tuesday, March 19, 2019 9:47 PM
> To: Ming Huang
> Cc: linaro-u...@lists.linaro.org; edk2-devel@lists.01.org; Wu, Hao A; Kinney,
> Michael D; Gao, Liming; ard.biesheu...@linaro.org;
> wanghuiqi...@huawei.com; huangmin...@huawei.com;
> zhangjinso...@huawei.com; mengfanr...@huawei.com;
> huangda...@hisilicon.com
> Subject: Re: [Patch MdeModulePkg/Library v1 1/1]
> MdeModulePkg/UefiBootManangerLib: Fix exception issue
>
> Thanks, Ming.
>
> On Tue, Mar 19, 2019 at 08:59:13PM +0800, Ming Huang wrote:
> > The system environment: virtual-CDROM(USB interface) via BMC, insert a
> > iso file to CDROM, like ubuntu-18.04.1-server-arm64.iso, change CDROM
> > to first boot option.
> > With release version bios, disconnecting CDROM when boot to
> > "1 seconds left, Press Esc or F2 to enter Setup"
> > then system will get a exception.
> >
> > The root cause is the EFI_BLOCK_IO_PROTOCOL for UsbMass will be
> uninstalled
> > in this situation after print some transfer error. The status will be
> > invalid parameter. This line will get a exception for BlockIo not point
> > to right address:
> > AllocatePool (BlockIo->Media->BlockSize)
> > So, here need to judge the status after ASSERT_EFI_ERROR.
> >
> > The Bugzilla tracker for this:
> > https://bugzilla.tianocore.org/show_bug.cgi?id=1631
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ming Huang
>
> Reviewed-by: Leif Lindholm
>
> > ---
> > MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > index 4ce83ce22d61..0535cd7335b4 100644
> > --- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > @@ -1069,6 +1069,9 @@ BmExpandMediaDevicePath (
> >//
> >Status = gBS->HandleProtocol (Handle, &gEfiBlockIoProtocolGuid, (VOID
> **) &BlockIo);
> >ASSERT_EFI_ERROR (Status);
> > + if (EFI_ERROR (Status)) {
> > +return NULL;
> > + }
> >Buffer = AllocatePool (BlockIo->Media->BlockSize);
> >if (Buffer != NULL) {
> > BlockIo->ReadBlocks (
> > --
> > 2.9.5
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] SerialDxe with BaseSerialPortLib16550 and standard PC com port
Hi Mike, I didn't change any of these because the defaults seemed to be
what I wanted, 115200, 8n1. I also wasn't sure which one of for example
PcdUartDefaultBaudRate or PcdSerialBaudRate would actually be used. In any
case both seemed to be set to the same sane default 115200, 8n1, which is
what I wanted. The baud rate seems to be set correctly because output
works, but this may also just be the hardware reset default for the divisor
(1). My edk2 checkout is a bit behind HEAD, the only local change I have
is what I mentioned before to use BaseSerialPortLib16550 instead of
BaseSerialPortLibNull.
Regards,
Jake
[jake@localhost edk2]$ git log -n 1
commit cce9d763580a955d294a5e3696cbe07a03965e2b (HEAD -> master,
origin/master, origin/HEAD)
Author: Feng, Bob C
Date: Wed Jan 16 19:12:00 2019 +0800
BaseTools: Allow empty value for HiiPcd in Dsc
https://bugzilla.tianocore.org/show_bug.cgi?id=1466
DEC file defines PCD default value and PCD supported type.
DSC can configure PCD type and value.
If the value is same to default value in DEC file,
DSC can only configure PCD type and leave empty for value.
This usage supports all type PCD except for DynamicHii type.
So, DynamicHii PCD should support this usage. Below is one example in
DSC.
for example,
[PcdsDynamicHii.common.DEFAULT]
PcdPkgTokenSpaceGuid.PcdCName|L"VarName"|gVarGuid|0x00||NV,BS
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng
Cc: Liming Gao
Cc: Jaben Carsey
Reviewed-by: Liming Gao
[jake@localhost edk2]$ git diff
diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
index 93eaf4b404..4bbc7517d7 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -76,7 +76,7 @@
DpcLib|MdeModulePkg/Library/DxeDpcLib/DxeDpcLib.inf
SecurityManagementLib|MdeModulePkg/Library/DxeSecurityManagementLib/DxeSecurityManagementLib.inf
TimerLib|MdePkg/Library/BaseTimerLibNullTemplate/BaseTimerLibNullTemplate.inf
-
SerialPortLib|MdePkg/Library/BaseSerialPortLibNull/BaseSerialPortLibNull.inf
+
SerialPortLib|MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf^M
CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
On Wed, Mar 20, 2019 at 12:06 PM Kinney, Michael D <
michael.d.kin...@intel.com> wrote:
> What are the PCDs settings you are using for the
> SerialPortLib?
>
> Thanks,
>
> Mike
>
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> > On Behalf Of Jacob Burkholder
> > Sent: Tuesday, March 19, 2019 7:06 PM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] SerialDxe with BaseSerialPortLib16550 and
> > standard PC com port
> >
> > Greetings!
> >
> > I had trouble using SerialDxe.efi with
> > BaseSerialPortLib16550 on a standard
> > PC com port (com1). The PC is an asrock motherboard
> > running whatever EFI
> > bios it came with. I changed MdeModulePkg.dsc so that
> > BaseSerialPortLib16550 would be used instead of
> > BaseSerialPortLibNull and
> > then rebuilt SerialDxe.efi and loaded and started it
> > using
> > BootServices->{LoadImage,StartImage}.
> >
> > Output works but input doesn't work, typed characters
> > aren't received by
> > the uart. I looked at the code briefly and it seems like
> > the uart isn't
> > initialized properly. I used this script to get input
> > working (the
> > commands should be self explanatory, they're not efi
> > shell commands though):
> >
> > image SerialDxe.efi
> > outb 0x3fb 0x83
> > outw 0x3f8 1
> > outb 0x3fb 0x3
> > outb 0x3fc 0x3
> >
> > Any chance it can be fixed upstream?
> >
> > Thanks,
> >
> > Jake
> > ___
> > 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 v4] UefiCpuPkg\CpuSmm: Save & restore CR2 on-demand paging in SMM
Thanks Eric!. Will go as per the comment #1 suggested and update further in the code review. Thanks, Naren > -Original Message- > From: Dong, Eric > Sent: Thursday, March 21, 2019 6:26 AM > To: Vanguput, Narendra K ; Laszlo Ersek > ; edk2-devel@lists.01.org > Cc: Yao, Jiewen ; Chinnusamy, Rajkumar K > ; Ni, Ray > Subject: RE: [edk2] [PATCH v4] UefiCpuPkg\CpuSmm: Save & restore CR2 on- > demand paging in SMM > > Hi Naren, > > I agree with Laszlo's comment for #1. I think separate functions for IA32/X64 > are much clear than the current one. I think in current EDK2 codebase, many > similar cases already exits. > > Thanks, > Eric > > > -Original Message- > > From: Vanguput, Narendra K > > Sent: Thursday, March 21, 2019 1:28 AM > > To: Laszlo Ersek ; edk2-devel@lists.01.org > > Cc: Yao, Jiewen ; Dong, Eric > > ; Chinnusamy, Rajkumar K > > ; Ni, Ray > > Subject: RE: [edk2] [PATCH v4] UefiCpuPkg\CpuSmm: Save & restore CR2 > > on- demand paging in SMM > > > > Hi Laszlo, > > > > Thanks for your comments. > > > > For your comment #1, My thoughts are when we add two functions > > (SaveCr2 & RestoreCr2). For IA32, it actually don't save and restore, simply > returns. > > Later, it might be confusing unless if we know the background and gone > > through 64 bit supported code. And also its kind of adding more code > > while we have alternate solution. > > In the proposed changes, I felt its straight forward and light changes > > needed. > > Yes, I would like to hear from other reviewers too to take the right option. > > > > For comments #2 & #4, Yes, I notified it, waiting to update along with > > other comments. > > > > For comments #3 & #5, will consider them. Will adjust the no. > > characters and will move extern of mCpuSmmStaticPageTable to > PiSmmCpuDxeSmm.h file. > > > > Thanks, > > Naren > > > > -Original Message- > > From: Laszlo Ersek [mailto:ler...@redhat.com] > > Sent: Wednesday, March 20, 2019 10:01 PM > > To: Vanguput, Narendra K ; edk2- > > de...@lists.01.org > > Cc: Yao, Jiewen ; Dong, Eric > > > > Subject: Re: [edk2] [PATCH v4] UefiCpuPkg\CpuSmm: Save & restore CR2 > > on- demand paging in SMM > > > > On 03/18/19 15:38, nkvangup wrote: > > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1593 > > > > > > For every SMI occurrence, save and restore CR2 register only when > > > SMM on-demand paging support is enabled in 64 bit operation mode. > > > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > > Signed-off-by: Vanguput Narendra K > > > Cc: Eric Dong > > > Cc: Ray Ni > > > Cc: Laszlo Ersek > > > Cc: Yao Jiewen > > > --- > > > UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c | 22 ++- > > --- > > > UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c | 2 +- > > > 2 files changed, 15 insertions(+), 9 deletions(-) > > > > > > diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c > > > b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c > > > index 3b0b3b52ac..0c07b31c4f 100644 > > > --- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c > > > +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c > > > @@ -28,6 +28,7 @@ UINTN > > > mSemaphoreSize; > > > SPIN_LOCK *mPFLock = NULL; > > > SMM_CPU_SYNC_MODE mCpuSmmSyncMode; > > > BOOLEAN mMachineCheckSupported = > > > FALSE; > > > +BOOLEAN mCpuSmmStaticPageTable = > > > TRUE; > > > > Hmmm. This change is a bit daring, but I think it could be valid. > > > > - In the IA32 build, mCpuSmmStaticPageTable would never be modified, > > or read, by *preexistent* code (because all that code is in X64/PageTbl.c). > > And the new code, added by this patch, would (presumably) work fine, > > with the initial TRUE value. > > > > - In the X64 build, the preexistent code would never read the initial > > value (which we now set to TRUE here), i.e. before overwriting the > > variable from the PCD -- because that would mean a bug in the > > preexistent code. (Well, unless that code relied on the zero initial value > > of > the variable). > > > > (1) I think I'd like to defer on this to other UefiCpuPkg reviewers. > > Honestly I find this style questionable. It makes me feel uncomfortable. > > I'd prefer the new APIs with the separate IA32/X64 implementations > > that I suggested in my v2 review. But if other reviewers like this one > > better, I won't mind. > > > > (After hearing their opinions, I'd attempt to find the time to > > regression test the patch (or maybe v5), too.) > > > > Assuming other reviewers prefer this approach over my suggestion, I > > have some other comments: > > > > > > > > /** > > >Performs an atomic compare exchange operation to get semaphore. > > > @@ -,10 +1112,13 @@ SmiRendezvous ( > > > > > >ASSERT(CpuIndex < mMaxNumberOfCpus); > > > > > > - // > > > - // Save Cr2 because Page Fault exception in SMM may override its > > > value > > > - // >
Re: [edk2] [RFC 0/3] Enable runtime serial debug for ArmVirtQemu
On 2019/3/21 1:47, Laszlo Ersek wrote: On 03/20/19 13:16, Heyi Guo wrote: On 2019/3/20 17:55, Laszlo Ersek wrote: If we don't have to flatten a ridiculous amount of other library code into the RuntimePrepare() function, I think such flattening would be a viable approach. We've run into this constructor loop several times before, and -- if I remember correctly anyway! -- one approach has been to declare SerialPortLib the "lowest level abstraction", and make the affected lib instance self-contained. In my RFC, we need to use gDS which is from DxeServicesTableLib->EfiGetSystemConfigurationTable()->UefiLib, so that we need to flatten EfiGetSystemConfigurationTable(). I think that's acceptable. And gDS->SetMemorySpaceAttributes() actually relies on gEfiCpuArchProtocolGuid or it will return EFI_NOT_AVAILABLE_YET. This is a valid dependency (even the PI spec spells it out). The way to deal with it is to add gEfiCpuArchProtocolGuid to the DEPEX section of the INF file -- this is possible for INF files of library instances as well, but you have to be careful about module types. Please see the INF spec on that. Once you do this, modules linked against the lib instance will inherit the lib instance's DEPEX, and "and it" together with the rest of their DEPEX. IOW using the library will delay the containing driver module until the CPU Arch protocol is available in the protocol database. Yes, one is VariableRuntimeDxe, whose DEPEX is TRUE right now, but I think it is acceptable. I can take a try for the above proposal. Thanks, Heyi Then the constructor can rely on the related DXE services. Thanks Laszlo . ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64 in .dsc
> -Original Message-
> From: Zeng, Star
> Sent: Thursday, March 21, 2019 9:03 AM
> To: Leif Lindholm; Laszlo Ersek
> Cc: edk2-devel@lists.01.org; ard.biesheu...@linaro.org; Wang, Jian J; Wu,
> Hao A; Ni, Ray; Andrew Fish; Kinney, Michael D; Zeng, Star
> Subject: RE: [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64
> in .dsc
>
> Another way to update the file is
>
> [LibraryClasses.EBC]
> LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
>
> ->
>
> [LibraryClasses.EBC, LibraryClasses.ARM, LibraryClasses.AARCH64]
> LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
Hello Leif,
The current proposed patch seems great to me.
Reviewed-by: Hao Wu
I am also fine with the above suggestion by Star. So if you prefer the
above approach, please feel free to propose another patch. Thanks in
advance.
Best Regards,
Hao Wu
>
>
> Thanks,
> Star
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Thursday, March 21, 2019 1:43 AM
> To: Laszlo Ersek
> Cc: edk2-devel@lists.01.org; ard.biesheu...@linaro.org; Wang, Jian J
> ; Wu, Hao A ; Ni, Ray
> ; Zeng, Star ; Andrew Fish
> ; Kinney, Michael D
> Subject: Re: [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64
> in .dsc
>
> On Wed, Mar 20, 2019 at 03:51:39PM +0100, Laszlo Ersek wrote:
> > Hi Leif,
> >
> > On 03/18/19 15:56, Leif Lindholm wrote:
> > > Commit 05fd2a926833
> > > ("MdeModulePkg/NvmExpressPei: Consume S3StorageDeviceInitList
> > > LockBox") added a dependency on LockBoxLib to NvmExpressPei, causing
> > > builds using MdeModulePkg.dsc to fail on architectures other than
> > > IA32/X64 with missing reference to
> > > gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode.
> > >
> > > Add a resolution for LockBoxNullLib for ARM/AARCH64 to restore builds.
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Leif Lindholm
> > > ---
> > >
> > > Note: this patch hides the symptom, but this isn't really the fix I
> > > would like to see.
> > >
> > > The build error is caused by the chain of:
> > > 1) NvmExpressPei depending on LockBoxLib
> > > 2) LockBoxLib being mapped to SmmLockBoxPeiLib in
> > > [LibraryClasses.common.PEIM]
> > > 3) SmmLockBoxPeiLib depending on PcdDxeIplSwitchToLongMode
> > > 4) PcdDxeIplSwitchToLongMode being declared in
> > >[PcdsFeatureFlag.IA32, PcdsFeatureFlag.X64] in MdeModulePkg.dsc
> > >
> > > Now, an alternative quick-fix would be to move the PEIM LockBoxLib
> > > mapping into a [LibraryClasses.IA32.PEIM, LibraryClasses.X64.PEIM]
> > > section. But that would leave NvmExpressPei unbuildable on anything
> > > not IA32/X64.
> > >
> > > Another option would be to add default declaration (for all other
> > > architectures) of FALSE for PcdDxeIplSwitchToLongMode in
> > > MdeModulePkg.dec, but the current way this is expressed seems to
> > > treat this as an architecture-specific feature (which it is).
> > >
> > > What I believe would be the cleanest solution would be to abstract
> > > NvmExpressPei to the point where it can function without the LockBoxLib.
> > > But regardless, it does not look valid to me for something as
> > > architecture-specific as MdeModulePkg/Library/SmmLockBoxLib/ to live
> > > under .common sections in the .dsc. (And if this changes at some
> > > point, because we implement an ARM/AARCH64 equivalent based on
> > > StandaloneMmPkg, we will need a major refactoring of that library
> > > anyway.)
> > >
> > > /
> > > Leif
> > >
> > > MdeModulePkg/MdeModulePkg.dsc | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/MdeModulePkg/MdeModulePkg.dsc
> > > b/MdeModulePkg/MdeModulePkg.dsc index 6cd1727a0d..6e27e9cb68
> 100644
> > > --- a/MdeModulePkg/MdeModulePkg.dsc
> > > +++ b/MdeModulePkg/MdeModulePkg.dsc
> > > @@ -178,6 +178,7 @@ [LibraryClasses.common.MM_STANDALONE]
> > > [LibraryClasses.ARM, LibraryClasses.AARCH64]
> > >ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
> > >ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
> > > + LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
> > >
> > >#
> > ># It is not possible to prevent ARM compiler calls to generic intrinsic
> functions.
> > >
> >
> > I think this patch is exactly the right solution.
> >
> > The code added in commit 05fd2a926833 is gated by (BootMode ==
> > BOOT_ON_S3_RESUME). That condition can never evaluate to TRUE on
> > ARM/AARCH64, presently. Accordingly, the stated goal of the commit
> > doesn't apply to ARM/AARCH64:
> >
> > The purpose is to perform an on-demand (partial) NVM Express device
> > enumeration/initialization to benefit the S3 resume performance.
> >
> > Given that the RestoreLockBox() calls are never reached (which is
> > correct, by design, at the present level of ACPI S3 enablement in edk2
> > for ARM/AARCH64), causing the lockbox APIs to "do nothing beyond
> > compile" is exactly right. IMO anyway.
> >
> > Once ARM/AARCH64 grow S3 s
Re: [edk2] [PATCH V3 13/17] MdeModulePkg/PeiDxeDebugLibReportStatusCode: Add new APIs
Sorry for the delayed response.
One minor comment below.
> -Original Message-
> From: Gao, Zhichao
> Sent: Tuesday, March 19, 2019 11:26 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Gao, Liming; Sean Brogan;
> Michael Turner; Bret Barkelew
> Subject: [PATCH V3 13/17]
> MdeModulePkg/PeiDxeDebugLibReportStatusCode: Add new APIs
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
>
> Add new APIs' implementation (DebugVPrint, DebugBPrint)
> in the DebugLib instance. These APIs would expose print
> routines with VaList parameter and BaseList parameter.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Liming Gao
> Cc: Sean Brogan
> Cc: Michael Turner
> Cc: Bret Barkelew
> ---
> .../PeiDxeDebugLibReportStatusCode/DebugLib.c | 144
> ++---
> 1 file changed, 128 insertions(+), 16 deletions(-)
>
> diff --git
> a/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> b/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> index 6f0f416273..f1d31cb619 100644
> --- a/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> +++
> b/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> @@ -4,7 +4,7 @@
>Note that if the debug message length is larger than the maximum
> allowable
>record length, then the debug message will be ignored directly.
>
> - Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> + Copyright (c) 2006 - 2019, Intel Corporation. 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
> @@ -27,6 +27,12 @@
> #include
> #include
>
> +//
> +// VA_LIST can not initialize to NULL for all compiler, so we use this to
> +// indicate a null VA_LIST
> +//
> +VA_LIST mVaListNull;
> +
> /**
>Prints a debug message to the debug output device if the specified error
> level is enabled.
>
> @@ -52,12 +58,43 @@ DebugPrint (
>IN CONST CHAR8 *Format,
>...
>)
> +{
> + VA_LIST Marker;
> +
> + VA_START (Marker, Format);
> + DebugVPrint (ErrorLevel, Format, Marker);
> + VA_END (Marker);
> +}
> +
> +/**
> + Prints a debug message to the debug output device if the specified
> + error level is enabled base on Null-terminated format string and a
> + VA_LIST argument list or a BASE_LIST argument list.
> +
> + If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib function
> + GetDebugPrintErrorLevel (), then print the message specified by Format
> and
> + the associated variable argument list to the debug output device.
> +
> + If Format is NULL, then ASSERT().
> +
> + @param ErrorLevel The error level of the debug message.
> + @param Format Format string for the debug message to print.
> + @param VaListMarkerVA_LIST marker for the variable argument list.
> + @param BaseListMarker BASE_LIST marker for the variable argument list.
> +
> +**/
> +VOID
> +DebugPrintMarker (
> + IN UINTN ErrorLevel,
> + IN CONST CHAR8 *Format,
> + IN VA_LIST VaListMarker,
> + IN BASE_LIST BaseListMarker
> + )
> {
>UINT64 Buffer[(EFI_STATUS_CODE_DATA_MAX_SIZE / sizeof (UINT64))
> + 1];
>EFI_DEBUG_INFO *DebugInfo;
>UINTN TotalSize;
> - VA_LIST VaListMarker;
> - BASE_LIST BaseListMarker;
> + BASE_LIST BaseListMarkerPointer;
Please help to update the comments in DebugPrintMarker() as well to
reflect the above name change of the variable.
Other than that, the patch is good to me:
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
>CHAR8 *FormatString;
>BOOLEAN Long;
>
> @@ -96,7 +133,7 @@ DebugPrint (
>// If the TotalSize is larger than the maximum record size, then return
>//
>if (TotalSize > sizeof (Buffer)) {
> -TotalSize = sizeof (Buffer);
> +return;
>}
>
>//
> @@ -109,7 +146,7 @@ DebugPrint (
>//
>DebugInfo = (EFI_DEBUG_INFO *)(Buffer) + 1;
>DebugInfo->ErrorLevel = (UINT32)ErrorLevel;
> - BaseListMarker= (BASE_LIST)(DebugInfo + 1);
> + BaseListMarkerPointer = (BASE_LIST)(DebugInfo + 1);
>FormatString = (CHAR8 *)((UINT64 *)(DebugInfo + 1) + 12);
>
>//
> @@ -125,7 +162,6 @@ DebugPrint (
>// of format in DEBUG string, which is followed by the DEBUG format string.
>// Here we will process the variable arguments and pack them in this area.
>//
> - VA_START (VaListMarker, Format);
>
>//
>// Use the actual format string.
> @@ -167,7 +203,11 @@ DebugPrint (
> // '*' in format field means the precision of the field is specified
> by
> // a UINTN argument in the argument list.
> //
> -BAS
Re: [edk2] [PATCH V3 14/17] MdeModulePkg: Add definitions for EDKII DEBUG PPI
> -Original Message-
> From: Gao, Zhichao
> Sent: Tuesday, March 19, 2019 11:26 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Gao, Liming; Sean Brogan;
> Michael Turner; Bret Barkelew
> Subject: [PATCH V3 14/17] MdeModulePkg: Add definitions for EDKII DEBUG
> PPI
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
>
> Add a debug PPI for PEI phase. This PPI will provide basic
> services of debug. PEI debug lib instance can use these
> services to implement debug function to reduce the PEIMs
> which consume the debug lib.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Liming Gao
> Cc: Sean Brogan
> Cc: Michael Turner
> Cc: Bret Barkelew
> ---
> MdeModulePkg/Include/Ppi/Debug.h | 90
>
> MdeModulePkg/MdeModulePkg.dec| 3 ++
> 2 files changed, 93 insertions(+)
> create mode 100644 MdeModulePkg/Include/Ppi/Debug.h
>
> diff --git a/MdeModulePkg/Include/Ppi/Debug.h
> b/MdeModulePkg/Include/Ppi/Debug.h
> new file mode 100644
> index 00..40db304f3d
> --- /dev/null
> +++ b/MdeModulePkg/Include/Ppi/Debug.h
> @@ -0,0 +1,90 @@
> +/** @file
> + Define the EDKII_DEBUG_PPI that PEIMs can use to dump info to debug
> port.
> +
> + Copyright (c) 2019, Intel Corporation. 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.
> +
> +**/
> +
> +#ifndef __EDKII_DEBUG_PPI_H__
> +#define __EDKII_DEBUG_PPI_H__
> +
> +#include
> +
> +//
> +// Global ID for the EDKII_DEBUG_PPI
> +//
> +#define EDKII_DEBUG_PPI_GUID \
> + { \
> +0x999e699c, 0xb013, 0x475e, {0xb1, 0x7b, 0xf3, 0xa8, 0xae, 0x5c, 0x48,
> 0x75} \
> + }
> +
> +///
> +/// Forward declaration for the PEI_DEBUG_LIB_DEBUG_PPI
> EDKII_DEBUG_PPI
> +///
> +typedef struct _EDKII_DEBUG_PPI EDKII_DEBUG_PPI;
> +
> +/**
> + Print a debug message to debug output device if the specified error level
> + is enabled.
> +
> + @param[in] PeiServices The pointer to the PEI Services Table.
> + @param[in] This The pointer to this instance of
> EDKII_DEBUG_PPI
> + @param[in] ErrorLevel The error level of the debug message.
> + @param[in] Format Format string for the debug message to
> print.
> + @param[in] Marker BASE_LIST marker for the variable
> argument
> list.
> +
> +**/
> +typedef
> +VOID
> +(EFIAPI *EDKII_DEBUG_BPRINT)(
> + IN CONST EFI_PEI_SERVICES **PeiServices,
> + IN EDKII_DEBUG_PPI*This,
> + IN UINTN ErrorLevel,
> + IN CONST CHAR8*Format,
> + IN BASE_LIST Marker
> + );
Hello,
I checked the PEIM that implements this PPI (patch 15/17), and I did not
find the parameters 'PeiServices' & 'This' are being used there.
Thus, I suggest to remove those 2 parameters from the interfaces of
EFIAPI *EDKII_DEBUG_BPRINT
EFIAPI *EDKII_DEBUG_ASSERT
Best Regards,
Hao Wu
> +
> +/**
> + Print an assert message containing a filename, line number, and
> description.
> + This may be followed by a breakpoint or a dead loop.
> +
> + @param[in] PeiServices The pointer to the PEI Services Table.
> + @param[in] This The pointer to this instance of
> EDKII_DEBUG_PPI
> + @param[in] FileName The pointer to the name of the source
> file
> that
> + generated the assert condition.
> + @param[in] LineNumber The line number in the source file that
> generated
> + the assert condition
> + @param[in] Description The pointer to the description of the
> assert
> condition.
> +
> +**/
> +typedef
> +VOID
> +(EFIAPI *EDKII_DEBUG_ASSERT)(
> + IN CONST EFI_PEI_SERVICES **PeiServices,
> + IN EDKII_DEBUG_PPI*This,
> + IN CONST CHAR8*FileName,
> + IN UINTN LineNumber,
> + IN CONST CHAR8*Description
> + );
> +
> +///
> +/// This PPI contains a set of services to print message to debug output
> device
> +///
> +struct _EDKII_DEBUG_PPI {
> + EDKII_DEBUG_BPRINTDebugBPrint;
> + EDKII_DEBUG_ASSERTDebugAssert;
> +};
> +
> +extern EFI_GUID gEdkiiDebugPpiGuid;
> +
> +#endif
> +
> diff --git a/MdeModulePkg/MdeModulePkg.dec
> b/MdeModulePkg/MdeModulePkg.dec
> index a2130bc439..9bbd0572f5 100644
> --- a/MdeModulePkg/MdeModuleP
Re: [edk2] [PATCH V3 17/17] MdeModulePkg: Add PEIM and lib to dsc file
Reviewed-by: Hao Wu Best Regards, Hao Wu > -Original Message- > From: Gao, Zhichao > Sent: Tuesday, March 19, 2019 11:26 PM > To: edk2-devel@lists.01.org > Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Gao, Liming; Sean Brogan; > Michael Turner; Bret Barkelew > Subject: [PATCH V3 17/17] MdeModulePkg: Add PEIM and lib to dsc file > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395 > > Add the new PEIM DebugServicePei and library instance > PeiDebugLibDebugPpi to dsc file to verify it can build > correctly. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Zhichao Gao > Cc: Jian J Wang > Cc: Hao Wu > Cc: Ray Ni > Cc: Star Zeng > Cc: Liming Gao > Cc: Sean Brogan > Cc: Michael Turner > Cc: Bret Barkelew > --- > MdeModulePkg/MdeModulePkg.dsc | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/MdeModulePkg/MdeModulePkg.dsc > b/MdeModulePkg/MdeModulePkg.dsc > index 6cd1727a0d..dec441e23e 100644 > --- a/MdeModulePkg/MdeModulePkg.dsc > +++ b/MdeModulePkg/MdeModulePkg.dsc > @@ -297,6 +297,7 @@ > > MdeModulePkg/Library/PlatformHookLibSerialPortPpi/PlatformHookLibSeria > lPortPpi.inf > > MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompr > essLib.inf > > MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLib > ReportStatusCode.inf > + MdeModulePkg/Library/PeiDebugLibDebugPpi/PeiDebugLibDebugPpi.inf >MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf > > MdeModulePkg/Library/PlatformBootManagerLibNull/PlatformBootManage > rLibNull.inf >MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf > @@ -423,6 +424,8 @@ >MdeModulePkg/Universal/SerialDxe/SerialDxe.inf >MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.inf > > + MdeModulePkg/Universal/DebugServicePei/DebugServicePei.inf > + >MdeModulePkg/Application/CapsuleApp/CapsuleApp.inf > > MdeModulePkg/Library/FmpAuthenticationLibNull/FmpAuthenticationLibNu > ll.inf >MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.inf > -- > 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 V3 15/17] MdeModulePkg: Add a PEIM to install Debug PPI
Hello,
Besides the comments in patch 14/17 to remove the 'PeiServices' & 'This'
parameters from the PPI services, some minor comments below:
> -Original Message-
> From: Gao, Zhichao
> Sent: Tuesday, March 19, 2019 11:26 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Gao, Liming; Sean Brogan;
> Michael Turner; Bret Barkelew
> Subject: [PATCH V3 15/17] MdeModulePkg: Add a PEIM to install Debug PPI
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
>
> Add a PEIM to install Debug PPI so that PEI debug library
> instance can locate gEdkiiDebugPpiGuid to implement the
> debug functions. Using this PPI can reduce the size of
> PEIMs which consume the debug library.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Liming Gao
> Cc: Sean Brogan
> Cc: Michael Turner
> Cc: Bret Barkelew
> ---
> .../Universal/DebugServicePei/DebugService.c | 68
> ++
> .../Universal/DebugServicePei/DebugService.h | 64
>
> .../Universal/DebugServicePei/DebugServicePei.c| 54
> +
> .../Universal/DebugServicePei/DebugServicePei.inf | 51
>
> .../Universal/DebugServicePei/DebugServicePei.uni | 20 +++
> 5 files changed, 257 insertions(+)
> create mode 100644
> MdeModulePkg/Universal/DebugServicePei/DebugService.c
> create mode 100644
> MdeModulePkg/Universal/DebugServicePei/DebugService.h
> create mode 100644
> MdeModulePkg/Universal/DebugServicePei/DebugServicePei.c
> create mode 100644
> MdeModulePkg/Universal/DebugServicePei/DebugServicePei.inf
> create mode 100644
> MdeModulePkg/Universal/DebugServicePei/DebugServicePei.uni
>
> diff --git a/MdeModulePkg/Universal/DebugServicePei/DebugService.c
> b/MdeModulePkg/Universal/DebugServicePei/DebugService.c
> new file mode 100644
> index 00..54ae6974d1
> --- /dev/null
> +++ b/MdeModulePkg/Universal/DebugServicePei/DebugService.c
> @@ -0,0 +1,68 @@
> +/** @file
> + Debug services instances for PEI phase.
> +
> + Copyright (c) 2019, Intel Corporation. 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
> +
> +/**
> + Print a debug message to debug output device if the specified error level
> + is enabled.
> +
> + @param[in] PeiServices The pointer to the PEI Services Table.
> + @param[in] This The pointer to this instance of
> EDKII_DEBUG_PPI
> + @param[in] ErrorLevel The error level of the debug message.
> + @param[in] Format Format string for the debug message to
> print.
> + @param[in] Marker BASE_LIST marker for the variable
> argument
> list.
> +
> +**/
> +VOID
> +EFIAPI
> +PeiDebugBPrint(
> + IN CONST EFI_PEI_SERVICES **PeiServices,
> + IN EDKII_DEBUG_PPI*This,
> + IN UINTN ErrorLevel,
> + IN CONST CHAR8*Format,
> + IN BASE_LIST Marker
> + )
> +{
> + DebugBPrint(ErrorLevel, Format, Marker);
> +}
> +
> +/**
> + Print an assert message containing a filename, line number, and
> description.
> + This may be followed by a breakpoint or a dead loop.
> +
> + @param[in] PeiServices The pointer to the PEI Services Table.
> + @param[in] This The pointer to this instance of
> EDKII_DEBUG_PPI
> + @param[in] FileName The pointer to the name of the source
> file
> that
> + generated the assert condition.
> + @param[in] LineNumber The line number in the source file that
> generated
> + the assert condition
> + @param[in] Description The pointer to the description of the
> assert
> condition.
> +
> +**/
> +VOID
> +EFIAPI
> +PeiDebugAssert(
> + IN CONST EFI_PEI_SERVICES **PeiServices,
> + IN EDKII_DEBUG_PPI*This,
> + IN CONST CHAR8*FileName,
> + IN UINTN LineNumber,
> + IN CONST CHAR8*Description
> + )
> +{
> + DebugAssert(FileName, LineNumber, Description);
> +}
> +
> diff --git a/MdeModulePkg/Universal/DebugServicePei/DebugService.h
> b/MdeModulePkg/Universal/DebugServicePei/DebugService.h
> new file mode 100644
> index 00..21b44248bb
> --- /dev/null
> +++ b/MdeModulePkg/Universal/DebugServicePei/DebugService.h
> @@ -0,0 +
Re: [edk2] [PATCH V3 16/17] MdeModulePkg/PeiDebugLibDebugPpi: Add PEI debug lib
Hello,
Besides the comments in patch 14/17 to remove the 'PeiServices' & 'This'
parameters from the PPI services, some minor comments below:
> -Original Message-
> From: Gao, Zhichao
> Sent: Tuesday, March 19, 2019 11:26 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming; Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Sean Brogan;
> Michael Turner; Bret Barkelew
> Subject: [PATCH V3 16/17] MdeModulePkg/PeiDebugLibDebugPpi: Add PEI
> debug lib
>
> From: Liming Gao
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
>
> Add a PEI debug library instance PeiDebugLibDebugPpi base on
> DebugPpi. Using the combination of the DebugServicePei and
> this lib instance can reduce the image size of PEI drivers.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Liming Gao
> Cc: Sean Brogan
> Cc: Michael Turner
> Cc: Bret Barkelew
> ---
> .../Library/PeiDebugLibDebugPpi/DebugLib.c | 469
> +
> .../PeiDebugLibDebugPpi/PeiDebugLibDebugPpi.inf| 55 +++
> 2 files changed, 524 insertions(+)
> create mode 100644
> MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c
> create mode 100644
> MdeModulePkg/Library/PeiDebugLibDebugPpi/PeiDebugLibDebugPpi.inf
>
> diff --git a/MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c
> b/MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c
> new file mode 100644
> index 00..839dff5268
> --- /dev/null
> +++ b/MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c
> @@ -0,0 +1,469 @@
> +/** @file
> + PEI debug lib instance base on DebugPpi to save size
> +
> + Copyright (c) 2019, Intel Corporation. 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
> +#include
> +#include
> +#include
> +
> +EDKII_DEBUG_PPI *mDebugPpi = NULL;
> +CONST EFI_PEI_SERVICES **mPeiServicesTablePointer = NULL;
If the EDKII_DEBUG_PPI interface changes, the above variable can be
removed.
> +
> +/**
> + Prints a debug message to the debug output device if the specified
> + error level is enabled.
> +
> + If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib function
> + GetDebugPrintErrorLevel (), then print the message specified by Format
> and
> + the associated variable argument list to the debug output device.
> +
> + If Format is NULL, then ASSERT().
> +
> + @param ErrorLevelThe error level of the debug message.
> + @param FormatFormat string for the debug message to print.
> + @param VaListMarker VA_LIST marker for the variable argument list.
> +
> +**/
> +VOID
> +EFIAPI
> +DebugPrint (
> + IN UINTNErrorLevel,
> + IN CONST CHAR8 *Format,
> + ...
> + )
> +{
> + VA_LIST Marker;
> +
> + VA_START (Marker, Format);
> + DebugVPrint (ErrorLevel, Format, Marker);
> + VA_END (Marker);
> +}
> +
> +
> +/**
> + Prints a debug message to the debug output device if the specified
> + error level is enabled.
> + This function use BASE_LIST which would provide a more compatible
> + service than VA_LIST.
> +
> + If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib function
> + GetDebugPrintErrorLevel (), then print the message specified by Format
> and
> + the associated variable argument list to the debug output device.
> +
> + If Format is NULL, then ASSERT().
> +
> + @param ErrorLevel The error level of the debug message.
> + @param Format Format string for the debug message to print.
> + @param BaseListMarker BASE_LIST marker for the variable argument list.
> +
> +**/
> +VOID
> +EFIAPI
> +DebugBPrint (
> + IN UINTN ErrorLevel,
> + IN CONST CHAR8 *Format,
> + IN BASE_LIST BaseListMarker
> + )
> +{
> + EFI_STATUS Status;
> +
> + //
> + // If Format is NULL, then ASSERT().
> + //
> + ASSERT (Format != NULL);
> +
> + //
> + // Check driver Debug Level value and global debug level
> + //
> + if ((ErrorLevel & GetDebugPrintErrorLevel ()) == 0) {
> +return;
> + }
> +
> + if (mDebugPpi == NULL) {
> +Status = PeiServicesLocatePpi (
> +&gEdkiiDebugPpiGuid,
> +0,
> +NULL,
> +(VOID **)&mDebugPpi
> +);
The indention seems not consistent for the above several lines.
> +if (EFI_ERROR (Status)) {
> + CpuDeadLoop();
> +}
> + }
> +
> + if (mPeiServicesTablePointer == NULL) {
> +mPeiServicesTablePointer = GetPeiSer
[edk2] [PATCH v2 2/3] BaseTools/C/Common: Improve performance of boundary validation
From: Shenglei Zhang
The boundary validation checking in MakeTable() performs on
every loop iteration. This could be improved by checking
just once before the loop.
https://bugzilla.tianocore.org/show_bug.cgi?id=1329
Cc: Bob Feng
Cc: Liming Gao
Cc: Yonghong Zhu
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang
---
BaseTools/Source/C/Common/Decompress.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/BaseTools/Source/C/Common/Decompress.c
b/BaseTools/Source/C/Common/Decompress.c
index 0e9ba0a982..e9ac1d58b3 100644
--- a/BaseTools/Source/C/Common/Decompress.c
+++ b/BaseTools/Source/C/Common/Decompress.c
@@ -254,10 +254,11 @@ Returns:
if (Len <= TableBits) {
+ if (Start[Len] >= NextCode || NextCode > MaxTableLength){
+return (UINT16) BAD_TABLE;
+ }
+
for (Index = Start[Len]; Index < NextCode; Index++) {
-if (Index >= MaxTableLength) {
- return (UINT16) BAD_TABLE;
-}
Table[Index] = Char;
}
--
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 0/3] Improve performance of boundary validation in MakeTable()
The boundary validation checking in MakeTable() performs on every loop iteration. This could be improved by checking just once before the loop. https://bugzilla.tianocore.org/show_bug.cgi?id=1329 v2:1.Change the the algorithm implementation of the judgement in all patches. 2.Remove previous 3/4 in v1. Cc: Bob Feng Cc: Liming Gao Cc: Yonghong Zhu Cc: Michael D Kinney Shenglei Zhang (3): BaseTools/TianoCompress: Improve performance of boundary validation BaseTools/C/Common: Improve performance of boundary validation MdePkg/BaseUefiDecompressLib: Improve performance of boundary validation BaseTools/Source/C/Common/Decompress.c | 7 --- BaseTools/Source/C/TianoCompress/TianoCompress.c | 7 --- .../Library/BaseUefiDecompressLib/BaseUefiDecompressLib.c | 7 --- 3 files changed, 12 insertions(+), 9 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 v2 1/3] BaseTools/TianoCompress: Improve performance of boundary validation
From: Shenglei Zhang
The boundary validation checking in MakeTable() performs on
every loop iteration. This could be improved by checking
just once before the loop.
https://bugzilla.tianocore.org/show_bug.cgi?id=1329
Cc: Bob Feng
Cc: Liming Gao
Cc: Yonghong Zhu
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang
---
BaseTools/Source/C/TianoCompress/TianoCompress.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/BaseTools/Source/C/TianoCompress/TianoCompress.c
b/BaseTools/Source/C/TianoCompress/TianoCompress.c
index 29b11c597f..ae88074360 100644
--- a/BaseTools/Source/C/TianoCompress/TianoCompress.c
+++ b/BaseTools/Source/C/TianoCompress/TianoCompress.c
@@ -2281,10 +2281,11 @@ Returns:
if (Len <= TableBits) {
+ if (Start[Len] >= NextCode || NextCode > MaxTableLength){
+return (UINT16) BAD_TABLE;
+ }
+
for (Index = Start[Len]; Index < NextCode; Index++) {
-if (Index >= MaxTableLength) {
- return (UINT16) BAD_TABLE;
-}
Table[Index] = Char;
}
--
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 3/3] MdePkg/BaseUefiDecompressLib: Improve performance of boundary validation
From: Shenglei Zhang
The boundary validation checking in MakeTable() performs on
every loop iteration. This could be improved by checking
just once before the loop.
https://bugzilla.tianocore.org/show_bug.cgi?id=1329
Cc: Michael D Kinney
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang
---
.../Library/BaseUefiDecompressLib/BaseUefiDecompressLib.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/MdePkg/Library/BaseUefiDecompressLib/BaseUefiDecompressLib.c
b/MdePkg/Library/BaseUefiDecompressLib/BaseUefiDecompressLib.c
index c1e8c5581a..3d5b7a737a 100644
--- a/MdePkg/Library/BaseUefiDecompressLib/BaseUefiDecompressLib.c
+++ b/MdePkg/Library/BaseUefiDecompressLib/BaseUefiDecompressLib.c
@@ -222,10 +222,11 @@ MakeTable (
if (Len <= TableBits) {
+ if (Start[Len] >= NextCode || NextCode > MaxTableLength){
+return (UINT16) BAD_TABLE;
+ }
+
for (Index = Start[Len]; Index < NextCode; Index++) {
-if (Index >= MaxTableLength) {
- return (UINT16) BAD_TABLE;
-}
Table[Index] = Char;
}
--
2.18.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v1 0/2] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg
> >> > >> Just a couple of notes from my side - I'm sure Laszlo will have a much > >> longer list :-) > >> > >> - Dropping the floppy driver is fine with me. > >> - What is OVMF specific about this driver? Is it only the hardcoded > >> list of COM1/COM2/PS2 keyboard? If so, should we split this into a > >> driver and a library class, where the driver lives in MdeModulePkg, > >> and the library is implemented in the context of OVMF? > > > > Hello Ard, > > > > I think the special thing for this one is that: > > For QEMU, it does not have a Super I/O (SIO) chip. While, as far as I > > know, the SIO chip exists on other platforms. The driver proposed here > > simulates the behavior of an SIO chip. IMO, if we find more platforms that > > do not have a SIO chip, we can convert the driver into a general one. > > > > Also, for the implementation of the services in the Super I/O protocol, > > the proposed driver just does the minimal effort in order to support the > > serial/PS2 keyboard. > > Here's why I'd like the majority of this driver to live under > MdeModulePkg (for example through a lib class separation like Ard suggests): > > Because then its maintenance would not be the responsibility of OvmfPkg > maintainers. > > Consider, this driver is absolutely huge (1.5-2 kLOC), for doing "the > minimal effort in order to support the serial/PS2 keyboard". > > The risk of regressions is extreme (the PS/2 keyboard is the default > one, and if it breaks *subtly*, almost all users will be inconvenienced, > but not necessarily soon enough for us to get reports about it *early* > in the current development cycle). > > I realize that IntelFrameworkModulePkg/Bus/Isa/* drivers are frowned > upon nowadays, they may be ugly / platform specific / etc etc etc, but > they have also proved themselves to *work*, and (as far as I remember) > they have required practically zero fixes in order to function well on QEMU. > > It is very unwelcome by me to take on the maintenance burden for a > driver that is all of: > - not widely tested, > - replacing a proven set of drivers that is critical to users, > - large. > > I understand that Intel wants to stop maintaining > IntelFrameworkModulePkg/Bus/Isa/*, but the above price is too high for me. > > Compare the case if we simply moved the > IntelFrameworkModulePkg/Bus/Isa/* drivers under OvmfPkg: > - still large, > - but widely tested (with minimal churn in the past), > - and no risk of regressions. > > So in this form, I'm generally opposed to the switch. The two sets of > drivers need to coexist for a while, and we must expose the new drivers > to users while providing them with some sort of easy fallback. (I'd > prefer that fallback to be dynamically configurable, but, again, if your > keyboard breaks, how do you interact with e.g. the UEFI shell? So I > guess a static build flag would do as well.) I think the old drivers Hello Laszlo, I agree with your point. So your suggestion is to: 1. Duplicate the below drivers into OvmfPkg: PcAtChipsetPkg/IsaAcpiDxe/IsaAcpi.inf IntelFrameworkModulePkg/Bus/Isa/IsaBusDxe/IsaBusDxe.inf IntelFrameworkModulePkg/Bus/Isa/IsaSerialDxe/IsaSerialDxe.inf IntelFrameworkModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2keyboardDxe.inf 2. Meanwhile, add the proposed SioBusDxe driver in the OvmfPkg as well 3. Add a static build flag within OvmfPkg to let users choose between: a) New OVMF SioBusDxe driver + ISA device drivers under MdeModulePkg/Bus/Isa; b) Legacy ISA stack copied from PcAtChipsetPkg & IntelFrameworkModulePkg Is my understanding correct? > should be removed only in the edk2 stable tag that comes *after* the > next one, once we've given the drivers enough time to "prove themselves". Do you mean we should keep the copy of the legacy ISA stack from PcAtChipsetPkg & IntelFrameworkModulePkg until the announcement of edk2-stable201905 tag? Best Regards, Hao Wu > > (We did something similar when we switched to the central PCI root > bridge driver in OVMF as well -- an OVMF lib instance for it was > implemented, so the maintenance burden wasn't fully under OvmfPkg to > begin with, plus we kept the old driver around with a build flag for a > while. IIRC.) > > Obviously I might feel safer if I could do a thorough review of the > driver, but I *absolutely* don't have time for it now. I'm sorry about that. > > Thanks, > Laszlo > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH V3 13/17] MdeModulePkg/PeiDxeDebugLibReportStatusCode: Add new APIs
Zhichao:
Why do below change? Seemly, this change is not related to add new APIs. In
fact, current log is added as the purpose by commit
137ed15511e2045a7333e33ae7f1e873ce1961dd.
if (TotalSize > sizeof (Buffer)) {
TotalSize = sizeof (Buffer); ==> return;
}
Thanks
Liming
>-Original Message-
>From: Gao, Zhichao
>Sent: Tuesday, March 19, 2019 11:26 PM
>To: edk2-devel@lists.01.org
>Cc: Wang, Jian J ; Wu, Hao A ;
>Ni, Ray ; Zeng, Star ; Gao, Liming
>; Sean Brogan ;
>Michael Turner ; Bret Barkelew
>
>Subject: [PATCH V3 13/17]
>MdeModulePkg/PeiDxeDebugLibReportStatusCode: Add new APIs
>
>REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
>
>Add new APIs' implementation (DebugVPrint, DebugBPrint)
>in the DebugLib instance. These APIs would expose print
>routines with VaList parameter and BaseList parameter.
>
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Zhichao Gao
>Cc: Jian J Wang
>Cc: Hao Wu
>Cc: Ray Ni
>Cc: Star Zeng
>Cc: Liming Gao
>Cc: Sean Brogan
>Cc: Michael Turner
>Cc: Bret Barkelew
>---
> .../PeiDxeDebugLibReportStatusCode/DebugLib.c | 144
>++---
> 1 file changed, 128 insertions(+), 16 deletions(-)
>
>diff --git
>a/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
>b/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
>index 6f0f416273..f1d31cb619 100644
>--- a/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
>+++
>b/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
>@@ -4,7 +4,7 @@
> Note that if the debug message length is larger than the maximum allowable
> record length, then the debug message will be ignored directly.
>
>- Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
>+ Copyright (c) 2006 - 2019, Intel Corporation. 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
>@@ -27,6 +27,12 @@
> #include
> #include
>
>+//
>+// VA_LIST can not initialize to NULL for all compiler, so we use this to
>+// indicate a null VA_LIST
>+//
>+VA_LIST mVaListNull;
>+
> /**
> Prints a debug message to the debug output device if the specified error
>level is enabled.
>
>@@ -52,12 +58,43 @@ DebugPrint (
> IN CONST CHAR8 *Format,
> ...
> )
>+{
>+ VA_LIST Marker;
>+
>+ VA_START (Marker, Format);
>+ DebugVPrint (ErrorLevel, Format, Marker);
>+ VA_END (Marker);
>+}
>+
>+/**
>+ Prints a debug message to the debug output device if the specified
>+ error level is enabled base on Null-terminated format string and a
>+ VA_LIST argument list or a BASE_LIST argument list.
>+
>+ If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib function
>+ GetDebugPrintErrorLevel (), then print the message specified by Format
>and
>+ the associated variable argument list to the debug output device.
>+
>+ If Format is NULL, then ASSERT().
>+
>+ @param ErrorLevel The error level of the debug message.
>+ @param Format Format string for the debug message to print.
>+ @param VaListMarkerVA_LIST marker for the variable argument list.
>+ @param BaseListMarker BASE_LIST marker for the variable argument list.
>+
>+**/
>+VOID
>+DebugPrintMarker (
>+ IN UINTN ErrorLevel,
>+ IN CONST CHAR8 *Format,
>+ IN VA_LIST VaListMarker,
>+ IN BASE_LIST BaseListMarker
>+ )
> {
> UINT64 Buffer[(EFI_STATUS_CODE_DATA_MAX_SIZE / sizeof (UINT64))
>+ 1];
> EFI_DEBUG_INFO *DebugInfo;
> UINTN TotalSize;
>- VA_LIST VaListMarker;
>- BASE_LIST BaseListMarker;
>+ BASE_LIST BaseListMarkerPointer;
> CHAR8 *FormatString;
> BOOLEAN Long;
>
>@@ -96,7 +133,7 @@ DebugPrint (
> // If the TotalSize is larger than the maximum record size, then return
> //
> if (TotalSize > sizeof (Buffer)) {
>-TotalSize = sizeof (Buffer);
>+return;
> }
>
> //
>@@ -109,7 +146,7 @@ DebugPrint (
> //
> DebugInfo = (EFI_DEBUG_INFO *)(Buffer) + 1;
> DebugInfo->ErrorLevel = (UINT32)ErrorLevel;
>- BaseListMarker= (BASE_LIST)(DebugInfo + 1);
>+ BaseListMarkerPointer = (BASE_LIST)(DebugInfo + 1);
> FormatString = (CHAR8 *)((UINT64 *)(DebugInfo + 1) + 12);
>
> //
>@@ -125,7 +162,6 @@ DebugPrint (
> // of format in DEBUG string, which is followed by the DEBUG format string.
> // Here we will process the variable arguments and pack them in this area.
> //
>- VA_START (VaListMarker, Format);
>
> //
> // Use the actual format string.
>@@ -167,7 +203,11 @@ DebugPrint (
> // '*' in format field means the precision of the field is specified
> by
> // a UINTN argument in the argument list.
> //
>-BASE_ARG (BaseListMarker, UINTN) = VA_ARG (VaListMarker, UINTN);
>+if (BaseListMarker == NULL) {
>+
Re: [edk2] [PATCH v2 02/10] UefiCpuPkg/BaseUefiCpuLib: Remove .S files for IA32 and X64 arch
Reviewed-by: Eric Dong > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Shenglei Zhang > Sent: Tuesday, March 19, 2019 2:59 PM > To: edk2-devel@lists.01.org > Cc: Kinney, Michael D ; Gao, Liming > > Subject: [edk2] [PATCH v2 02/10] UefiCpuPkg/BaseUefiCpuLib: Remove .S > files for IA32 and X64 arch > > .nasm file has been added for X86 arch. .S assembly code is not required any > more. > https://bugzilla.tianocore.org/show_bug.cgi?id=1594 > > Cc: Michael D Kinney > Cc: Liming Gao > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Shenglei Zhang > --- > .../Library/BaseUefiCpuLib/BaseUefiCpuLib.inf | 2 - > .../BaseUefiCpuLib/Ia32/InitializeFpu.S | 73 --- > .../BaseUefiCpuLib/X64/InitializeFpu.S| 57 --- > 3 files changed, 132 deletions(-) > delete mode 100644 > UefiCpuPkg/Library/BaseUefiCpuLib/Ia32/InitializeFpu.S > delete mode 100644 UefiCpuPkg/Library/BaseUefiCpuLib/X64/InitializeFpu.S > > diff --git a/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf > b/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf > index 5614452a88..2e9756e50e 100644 > --- a/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf > +++ b/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf > @@ -31,11 +31,9 @@ > > [Sources.IA32] >Ia32/InitializeFpu.nasm > - Ia32/InitializeFpu.S > > [Sources.X64] >X64/InitializeFpu.nasm > - X64/InitializeFpu.S > > [Packages] >MdePkg/MdePkg.dec > diff --git a/UefiCpuPkg/Library/BaseUefiCpuLib/Ia32/InitializeFpu.S > b/UefiCpuPkg/Library/BaseUefiCpuLib/Ia32/InitializeFpu.S > deleted file mode 100644 > index 0a1a9198f6..00 > --- a/UefiCpuPkg/Library/BaseUefiCpuLib/Ia32/InitializeFpu.S > +++ /dev/null > @@ -1,73 +0,0 @@ > -#-- > -#* > -#* Copyright (c) 2009 - 2018, Intel Corporation. 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. > -#* > -#* > -#-- > - > -# > -# Float control word initial value: > -# all exceptions masked, double-precision, round-to-nearest -# > -ASM_PFX(mFpuControlWord): .word 0x027F > -# > -# Multimedia-extensions control word: > -# all exceptions masked, round-to-nearest, flush to zero for masked > underflow -# > -ASM_PFX(mMmxControlWord): .long 0x01F80 > - > -# > -# Initializes floating point units for requirement of UEFI specification. > -# > -# This function initializes floating-point control word to 0x027F (all > exceptions -# masked,double-precision, round-to-nearest) and multimedia- > extensions control word -# (if supported) to 0x1F80 (all exceptions masked, > round-to-nearest, flush to zero -# for masked underflow). > -# > -ASM_GLOBAL ASM_PFX(InitializeFloatingPointUnits) > -ASM_PFX(InitializeFloatingPointUnits): > - > -pushl %ebx > - > -# > -# Initialize floating point units > -# > -finit > -fldcw ASM_PFX(mFpuControlWord) > - > -# > -# Use CpuId instructuion (CPUID.01H:EDX.SSE[bit 25] = 1) to test > -# whether the processor supports SSE instruction. > -# > -movl$1, %eax > -cpuid > -btl $25, %edx > -jnc Done > - > -# > -# Set OSFXSR bit 9 in CR4 > -# > -movl%cr4, %eax > -or $0x200, %eax > -movl%eax, %cr4 > - > -# > -# The processor should support SSE instruction and we can use > -# ldmxcsr instruction > -# > -ldmxcsr ASM_PFX(mMmxControlWord) > - > -Done: > -popl%ebx > - > -ret > - > -#END > - > diff --git a/UefiCpuPkg/Library/BaseUefiCpuLib/X64/InitializeFpu.S > b/UefiCpuPkg/Library/BaseUefiCpuLib/X64/InitializeFpu.S > deleted file mode 100644 > index f0b0d3e264..00 > --- a/UefiCpuPkg/Library/BaseUefiCpuLib/X64/InitializeFpu.S > +++ /dev/null > @@ -1,57 +0,0 @@ > -#-- > -#* > -#* Copyright (c) 2009 - 2018, Intel Corporation. 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 O
