[edk2] [PATCH v2 1/3] IntelFrameworkModulePkg: Remove PeiS3Lib and PeiRecoveryLib
As was described in 5933acc3cb1ac1a344a34342d0ac46d3afed929a,
there was no code using AcpiS3ResumeOs() interface in S3Lib and
PeiRecoverFirmware() interface in RecoveryLib.
PeiS3Lib and PeiRecoveryLib were deprecated,so they should be removed.
https://bugzilla.tianocore.org/show_bug.cgi?id=1299
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang
---
.../IntelFrameworkModulePkg.dsc | 2 -
.../Library/PeiRecoveryLib/PeiRecoveryLib.c | 50 --
.../Library/PeiRecoveryLib/PeiRecoveryLib.inf | 50 --
.../Library/PeiRecoveryLib/PeiRecoveryLib.uni | 23 -
.../Library/PeiS3Lib/PeiS3Lib.c | 51 ---
.../Library/PeiS3Lib/PeiS3Lib.inf | 49 --
.../Library/PeiS3Lib/PeiS3Lib.uni | 23 -
7 files changed, 248 deletions(-)
delete mode 100644
IntelFrameworkModulePkg/Library/PeiRecoveryLib/PeiRecoveryLib.c
delete mode 100644
IntelFrameworkModulePkg/Library/PeiRecoveryLib/PeiRecoveryLib.inf
delete mode 100644
IntelFrameworkModulePkg/Library/PeiRecoveryLib/PeiRecoveryLib.uni
delete mode 100644 IntelFrameworkModulePkg/Library/PeiS3Lib/PeiS3Lib.c
delete mode 100644 IntelFrameworkModulePkg/Library/PeiS3Lib/PeiS3Lib.inf
delete mode 100644 IntelFrameworkModulePkg/Library/PeiS3Lib/PeiS3Lib.uni
diff --git a/IntelFrameworkModulePkg/IntelFrameworkModulePkg.dsc
b/IntelFrameworkModulePkg/IntelFrameworkModulePkg.dsc
index 894c5340a0..28e8a3f6e1 100644
--- a/IntelFrameworkModulePkg/IntelFrameworkModulePkg.dsc
+++ b/IntelFrameworkModulePkg/IntelFrameworkModulePkg.dsc
@@ -110,8 +110,6 @@
[Components]
IntelFrameworkModulePkg/Library/BaseUefiTianoCustomDecompressLib/BaseUefiTianoCustomDecompressLib.inf
IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
- IntelFrameworkModulePkg/Library/PeiS3Lib/PeiS3Lib.inf
- IntelFrameworkModulePkg/Library/PeiRecoveryLib/PeiRecoveryLib.inf
IntelFrameworkModulePkg/Library/DxeReportStatusCodeLibFramework/DxeReportStatusCodeLib.inf
IntelFrameworkModulePkg/Library/SmmRuntimeDxeReportStatusCodeLibFramework/SmmRuntimeDxeReportStatusCodeLibFramework.inf
IntelFrameworkModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
diff --git a/IntelFrameworkModulePkg/Library/PeiRecoveryLib/PeiRecoveryLib.c
b/IntelFrameworkModulePkg/Library/PeiRecoveryLib/PeiRecoveryLib.c
deleted file mode 100644
index d9430483d5..00
--- a/IntelFrameworkModulePkg/Library/PeiRecoveryLib/PeiRecoveryLib.c
+++ /dev/null
@@ -1,50 +0,0 @@
-/** @file
- This Library uses Framework RecoveryModule PPI to do system recovery.
-
- This library instance is no longer used and module using this library
- class should update to directly locate EFI_PEI_RECOVERY_MODULE_PPI defined
- in PI 1.2 specification.
-
-Copyright (c) 2006 - 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.
-
-**/
-#include
-#include
-#include
-#include
-
-#include
-
-/**
- Calling this function causes the system do recovery.
-
- @retval EFI_SUCESS Sucess to do recovery.
- @retval Others Fail to do recovery.
-**/
-EFI_STATUS
-EFIAPI
-PeiRecoverFirmware (
- VOID
- )
-{
- EFI_STATUS Status;
- EFI_PEI_RECOVERY_MODULE_PPI *PeiRecovery;
-
- Status = PeiServicesLocatePpi (
- &gEfiPeiRecoveryModulePpiGuid,
- 0,
- NULL,
- (VOID **)&PeiRecovery
- );
- ASSERT_EFI_ERROR (Status);
-
- return PeiRecovery->LoadRecoveryCapsule ((EFI_PEI_SERVICES **)
GetPeiServicesTablePointer(), PeiRecovery);
-}
-
diff --git a/IntelFrameworkModulePkg/Library/PeiRecoveryLib/PeiRecoveryLib.inf
b/IntelFrameworkModulePkg/Library/PeiRecoveryLib/PeiRecoveryLib.inf
deleted file mode 100644
index f62b42e40f..00
--- a/IntelFrameworkModulePkg/Library/PeiRecoveryLib/PeiRecoveryLib.inf
+++ /dev/null
@@ -1,50 +0,0 @@
-## @file
-# PEIM Recovery Library supports system recovery boot.
-#
-# This library instance is no longer used and module using this library
-# class should update to directly locate EFI_PEI_RECOVERY_MODULE_PPI defined
-# in PI 1.2 specification.
-#
-# Copyright (c) 2006 - 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
[edk2] [platforms: PATCH v6 8/8] Marvell/Drivers: XenonDxe: Switch to use generic SdMmcPciHcDxe
From: Tomasz Michalec XenonDxe was copy of SdMmcPciHcDxe from edk2/MdeModulePkg. Now it implements SdMmcOverride protocol which allows to add quirks to the generic SdMmcPciHcDxe. Platforms that were using XenonDxe/SdMmcPciHcDxe have fixed *.fdf and *.dsc.inc files to use new implementation of XenonDxe. In the new version of the driver apart from using SdMmcOverride protocol, this patch utilizes newly added controllers' description in MvBoardDesc protocol, as well as improved PHY configuration sequence. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marcin Wojtas --- Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc | 2 + Silicon/Marvell/Armada7k8k/Armada7k8k.fdf | 2 + Silicon/Marvell/Drivers/SdMmc/XenonDxe/XenonDxe.inf | 55 +++ Silicon/Marvell/Drivers/SdMmc/XenonDxe/XenonPciHci.h| 151 +++ Silicon/Marvell/Drivers/SdMmc/XenonDxe/XenonSdMmcOverride.h | 53 +++ Silicon/Marvell/Drivers/SdMmc/XenonDxe/XenonSdhci.h | 131 +- Silicon/Marvell/Drivers/SdMmc/XenonDxe/XenonPciHci.c| 321 +++ Silicon/Marvell/Drivers/SdMmc/XenonDxe/XenonSdMmcOverride.c | 429 Silicon/Marvell/Drivers/SdMmc/XenonDxe/XenonSdhci.c | 408 --- 9 files changed, 1399 insertions(+), 153 deletions(-) create mode 100644 Silicon/Marvell/Drivers/SdMmc/XenonDxe/XenonDxe.inf create mode 100644 Silicon/Marvell/Drivers/SdMmc/XenonDxe/XenonPciHci.h create mode 100644 Silicon/Marvell/Drivers/SdMmc/XenonDxe/XenonSdMmcOverride.h create mode 100644 Silicon/Marvell/Drivers/SdMmc/XenonDxe/XenonPciHci.c create mode 100644 Silicon/Marvell/Drivers/SdMmc/XenonDxe/XenonSdMmcOverride.c diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc index 041fe90..14a1bda 100644 --- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc +++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc @@ -509,6 +509,8 @@ # SD/MMC MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.inf MdeModulePkg/Bus/Sd/SdDxe/SdDxe.inf + MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf + Silicon/Marvell/Drivers/SdMmc/XenonDxe/XenonDxe.inf # Console packages MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.fdf b/Silicon/Marvell/Armada7k8k/Armada7k8k.fdf index 6ad7c87..e143517 100644 --- a/Silicon/Marvell/Armada7k8k/Armada7k8k.fdf +++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.fdf @@ -171,6 +171,8 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c # SD/MMC INF MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.inf INF MdeModulePkg/Bus/Sd/SdDxe/SdDxe.inf + INF MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf + INF Silicon/Marvell/Drivers/SdMmc/XenonDxe/XenonDxe.inf # Multiple Console IO support INF MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf diff --git a/Silicon/Marvell/Drivers/SdMmc/XenonDxe/XenonDxe.inf b/Silicon/Marvell/Drivers/SdMmc/XenonDxe/XenonDxe.inf new file mode 100644 index 000..00c738a --- /dev/null +++ b/Silicon/Marvell/Drivers/SdMmc/XenonDxe/XenonDxe.inf @@ -0,0 +1,55 @@ +## @file +# SdMmcPciHcDxe driver is used to manage those host controllers which comply with SD +# Host Controller Simplified Specifiction version 3.0. +# +# It will produce EFI_SD_MMC_PASS_THRU_PROTOCOL to allow sending SD/MMC/eMMC cmds +# to specified devices from upper layer. +# +# Copyright (c) 2015, Intel Corporation. All rights reserved. +# Copyright (C) 2018, Marvell International Ltd. All rights reserved. +# +# This program and the accompanying materials +# are licensed and made available under the terms and conditions of the BSD License +# which accompanies this distribution. The full text of the license may be found at +# http://opensource.org/licenses/bsd-license.php +# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, +# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. +# +# +## + +[Defines] + INF_VERSION= 0x0001001A + BASE_NAME = XenonDxe + FILE_GUID = 17f56b40-f7c1-435c-ab8d-404872da951e + MODULE_TYPE= UEFI_DRIVER + VERSION_STRING = 1.0 + ENTRY_POINT= InitializeXenonDxe + +[Sources] + XenonPciHci.c + XenonPciHci.h + XenonSdhci.c + XenonSdhci.h + XenonSdMmcOverride.c + XenonSdMmcOverride.h + +[Packages] + MdePkg/MdePkg.dec + MdeModulePkg/MdeModulePkg.dec + Silicon/Marvell/Marvell.dec + +[LibraryClasses] + BaseLib + DebugLib + MemoryAllocationLib + UefiBootServicesTableLib + UefiDriverEntryPoint + UefiLib + UefiRuntimeServicesTableLib + +[Protocols] + gEdkiiSdMmcOverrideProtocolGuid ## PRODUCES + gEdkiiNonDiscoverableDeviceProtocolGuid ## TO_START + gEfiPciIoProtocolGuid ## TO_START + gMarvellBoardDescProtocolGuid ## T
[edk2] [PATCH v2 2/3] Vlv2TbltDevicePkg: Remove PeiS3Lib in DSC
PeiS3Lib is not actually used in Vlv2TbltDevicePkg, so it is removed in DSC. https://bugzilla.tianocore.org/show_bug.cgi?id=1299 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Shenglei Zhang --- Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 3 --- Vlv2TbltDevicePkg/PlatformPkgIA32.dsc | 3 --- Vlv2TbltDevicePkg/PlatformPkgX64.dsc| 3 --- 3 files changed, 9 deletions(-) diff --git a/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc b/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc index f0a689c2c4..736155f4e0 100644 --- a/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc +++ b/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc @@ -180,9 +180,6 @@ TcpIoLib|MdeModulePkg/Library/DxeTcpIoLib/DxeTcpIoLib.inf DpcLib|MdeModulePkg/Library/DxeDpcLib/DxeDpcLib.inf !endif -!if $(S3_ENABLE) == TRUE - S3Lib|IntelFrameworkModulePkg/Library/PeiS3Lib/PeiS3Lib.inf -!endif OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf !if $(CAPSULE_ENABLE) == TRUE diff --git a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc index c7908818b4..3bb37a34ab 100644 --- a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc +++ b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc @@ -180,9 +180,6 @@ TcpIoLib|MdeModulePkg/Library/DxeTcpIoLib/DxeTcpIoLib.inf DpcLib|MdeModulePkg/Library/DxeDpcLib/DxeDpcLib.inf !endif -!if $(S3_ENABLE) == TRUE - S3Lib|IntelFrameworkModulePkg/Library/PeiS3Lib/PeiS3Lib.inf -!endif OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf !if $(CAPSULE_ENABLE) == TRUE diff --git a/Vlv2TbltDevicePkg/PlatformPkgX64.dsc b/Vlv2TbltDevicePkg/PlatformPkgX64.dsc index cc8ad9508e..1e405dfb1b 100644 --- a/Vlv2TbltDevicePkg/PlatformPkgX64.dsc +++ b/Vlv2TbltDevicePkg/PlatformPkgX64.dsc @@ -180,9 +180,6 @@ TcpIoLib|MdeModulePkg/Library/DxeTcpIoLib/DxeTcpIoLib.inf DpcLib|MdeModulePkg/Library/DxeDpcLib/DxeDpcLib.inf !endif -!if $(S3_ENABLE) == TRUE - S3Lib|IntelFrameworkModulePkg/Library/PeiS3Lib/PeiS3Lib.inf -!endif OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf !if $(CAPSULE_ENABLE) == TRUE -- 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] Remove S3Lib and RecoveryLib class
S3Lib and RecoveryLib have been deprecated since 2009. There is no code using AcpiS3ResumeOs() interface in S3Lib and PeiRecoverFirmware() interface in RecoveryLib. So they can be removed from edk2 repo. https://bugzilla.tianocore.org/show_bug.cgi?id=1299 v2:Remove S3Lib.h and RecoveryLib.h. in MdeModulePkg. Cc: Zailiang Sun Cc: Star Zeng Cc: Jian J Wang Cc: Ruiyu Ni Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Shenglei Zhang Shenglei Zhang (3): IntelFrameworkModulePkg: Remove PeiS3Lib and PeiRecoveryLib Vlv2TbltDevicePkg: Remove PeiS3Lib in DSC MdeModulePkg: Remove PeiS3LibNull and PeiRecoveryLibNull .../IntelFrameworkModulePkg.dsc | 2 - .../Library/PeiRecoveryLib/PeiRecoveryLib.c | 50 -- .../Library/PeiRecoveryLib/PeiRecoveryLib.inf | 50 -- .../Library/PeiRecoveryLib/PeiRecoveryLib.uni | 23 - .../Library/PeiS3Lib/PeiS3Lib.c | 51 --- .../Library/PeiS3Lib/PeiS3Lib.inf | 49 -- .../Library/PeiS3Lib/PeiS3Lib.uni | 23 - MdeModulePkg/Core/DxeIplPeim/DxeIpl.h | 2 - MdeModulePkg/Include/Library/RecoveryLib.h| 35 - MdeModulePkg/Include/Library/S3Lib.h | 34 - .../PeiRecoveryLibNull/PeiRecoveryLibNull.c | 34 - .../PeiRecoveryLibNull/PeiRecoveryLibNull.inf | 39 -- .../PeiRecoveryLibNull/PeiRecoveryLibNull.uni | 24 - .../Library/PeiS3LibNull/PeiS3LibNull.c | 35 - .../Library/PeiS3LibNull/PeiS3LibNull.inf | 40 --- .../Library/PeiS3LibNull/PeiS3LibNull.uni | 24 - MdeModulePkg/MdeModulePkg.dec | 10 MdeModulePkg/MdeModulePkg.dsc | 2 - Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 3 -- Vlv2TbltDevicePkg/PlatformPkgIA32.dsc | 3 -- Vlv2TbltDevicePkg/PlatformPkgX64.dsc | 3 -- 21 files changed, 536 deletions(-) delete mode 100644 IntelFrameworkModulePkg/Library/PeiRecoveryLib/PeiRecoveryLib.c delete mode 100644 IntelFrameworkModulePkg/Library/PeiRecoveryLib/PeiRecoveryLib.inf delete mode 100644 IntelFrameworkModulePkg/Library/PeiRecoveryLib/PeiRecoveryLib.uni delete mode 100644 IntelFrameworkModulePkg/Library/PeiS3Lib/PeiS3Lib.c delete mode 100644 IntelFrameworkModulePkg/Library/PeiS3Lib/PeiS3Lib.inf delete mode 100644 IntelFrameworkModulePkg/Library/PeiS3Lib/PeiS3Lib.uni delete mode 100644 MdeModulePkg/Include/Library/RecoveryLib.h delete mode 100644 MdeModulePkg/Include/Library/S3Lib.h delete mode 100644 MdeModulePkg/Library/PeiRecoveryLibNull/PeiRecoveryLibNull.c delete mode 100644 MdeModulePkg/Library/PeiRecoveryLibNull/PeiRecoveryLibNull.inf delete mode 100644 MdeModulePkg/Library/PeiRecoveryLibNull/PeiRecoveryLibNull.uni delete mode 100644 MdeModulePkg/Library/PeiS3LibNull/PeiS3LibNull.c delete mode 100644 MdeModulePkg/Library/PeiS3LibNull/PeiS3LibNull.inf delete mode 100644 MdeModulePkg/Library/PeiS3LibNull/PeiS3LibNull.uni -- 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] MdeModulePkg: Remove PeiS3LibNull and PeiRecoveryLibNull
As was described in 5933acc3cb1ac1a344a34342d0ac46d3afed929a, there was no code using AcpiS3ResumeOs() interface in S3Lib and PeiRecoverFirmware() interface in RecoveryLib. PeiS3LibNull and PeiRecoveryLibNull were deprecated, so they should be removed. https://bugzilla.tianocore.org/show_bug.cgi?id=1299 v2:Remove S3Lib.h and RecoveryLib.h. Cc: Star Zeng Cc: Jian J Wang Cc: Ruiyu Ni Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Shenglei Zhang --- MdeModulePkg/Core/DxeIplPeim/DxeIpl.h | 2 - MdeModulePkg/Include/Library/RecoveryLib.h| 35 MdeModulePkg/Include/Library/S3Lib.h | 34 .../PeiRecoveryLibNull/PeiRecoveryLibNull.c | 34 .../PeiRecoveryLibNull/PeiRecoveryLibNull.inf | 39 -- .../PeiRecoveryLibNull/PeiRecoveryLibNull.uni | 24 --- .../Library/PeiS3LibNull/PeiS3LibNull.c | 35 .../Library/PeiS3LibNull/PeiS3LibNull.inf | 40 --- .../Library/PeiS3LibNull/PeiS3LibNull.uni | 24 --- MdeModulePkg/MdeModulePkg.dec | 10 - MdeModulePkg/MdeModulePkg.dsc | 2 - 11 files changed, 279 deletions(-) delete mode 100644 MdeModulePkg/Include/Library/RecoveryLib.h delete mode 100644 MdeModulePkg/Include/Library/S3Lib.h delete mode 100644 MdeModulePkg/Library/PeiRecoveryLibNull/PeiRecoveryLibNull.c delete mode 100644 MdeModulePkg/Library/PeiRecoveryLibNull/PeiRecoveryLibNull.inf delete mode 100644 MdeModulePkg/Library/PeiRecoveryLibNull/PeiRecoveryLibNull.uni delete mode 100644 MdeModulePkg/Library/PeiS3LibNull/PeiS3LibNull.c delete mode 100644 MdeModulePkg/Library/PeiS3LibNull/PeiS3LibNull.inf delete mode 100644 MdeModulePkg/Library/PeiS3LibNull/PeiS3LibNull.uni diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h index 9ea88a399b..bd0c967d75 100644 --- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h +++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h @@ -44,8 +44,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. #include #include #include -#include -#include #include #include #include diff --git a/MdeModulePkg/Include/Library/RecoveryLib.h b/MdeModulePkg/Include/Library/RecoveryLib.h deleted file mode 100644 index da5cb771bf..00 --- a/MdeModulePkg/Include/Library/RecoveryLib.h +++ /dev/null @@ -1,35 +0,0 @@ -/** @file - Recovery library class defines a set of methods related recovery boot mode. - This library class is no longer used and modules using this library should - directly locate EFI_PEI_RECOVERY_MODULE_PPI, defined in the PI 1.2 specification. - -Copyright (c) 2005 - 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 that 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 __RECOVERY_LIB_H__ -#define __RECOVERY_LIB_H__ - -/** - Calling this function causes the system to carry out a recovery boot path. - - @retval EFI_SUCCESS Recovery boot path succeeded. - @retval OthersRecovery boot path failure. - -**/ -EFI_STATUS -EFIAPI -PeiRecoverFirmware ( - VOID - ); - -#endif - - diff --git a/MdeModulePkg/Include/Library/S3Lib.h b/MdeModulePkg/Include/Library/S3Lib.h deleted file mode 100644 index 2a309034fa..00 --- a/MdeModulePkg/Include/Library/S3Lib.h +++ /dev/null @@ -1,34 +0,0 @@ -/** @file - S3 library class defines a set of methods related to S3 boot mode. - This library class is no longer used and modules using this library should - directly locate EFI_PEI_S3_RESUME_PPI, defined in the PI 1.2 specification. - -Copyright (c) 2005 - 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 that 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 __S3_LIB_H__ -#define __S3_LIB_H__ - -/** - This function is responsible for calling the S3 resume vector in the ACPI Tables. - - @retval EFI_SUCCESS Successfully restored the configuration from S3. - @retval Others Failed to restore the configuration from S3. - -**/ -EFI_STATUS -EFIAPI -AcpiS3ResumeOs ( - VOID - ); - -#endif - diff --git a/MdeModulePkg/Library/PeiRecoveryLibNull/PeiRecoveryLibNull.c b/MdeModulePkg/Library/PeiRecoveryLibNull/PeiRecoveryLibNull.c deleted file mode 100644 index f39a21b71
Re: [edk2] [PATCH v2] MdeModulePkg: Remove PcdIdentifyMappingPageTablePtr
Pushed at 316b3a719fd2ee97a01b0d941bba15ef06840d78. Thanks, Star -Original Message- From: Zeng, Star Sent: Monday, November 19, 2018 1:48 PM To: Zhang, Shenglei ; edk2-devel@lists.01.org Cc: Ni, Ruiyu ; Zeng, Star Subject: RE: [edk2] [PATCH v2] MdeModulePkg: Remove PcdIdentifyMappingPageTablePtr Reviewed-by: Star Zeng -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Shenglei Zhang Sent: Monday, November 19, 2018 12:39 PM To: edk2-devel@lists.01.org Cc: Ni, Ruiyu ; Zeng, Star Subject: [edk2] [PATCH v2] MdeModulePkg: Remove PcdIdentifyMappingPageTablePtr PcdIdentifyMappingPageTablePtr was used to share page table buffer between modules. Buf after some changes on 2015/07/17, it was useless and could be removed. https://bugzilla.tianocore.org/show_bug.cgi?id=1304 v2: 1.Remove PcdIdentifyMappingPageTablePtr in MdeModulePkg.uni. 2.Update the commit message. Cc: Star Zeng Cc: Jian J Wang Cc: Ruiyu Ni Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: shenglei --- MdeModulePkg/MdeModulePkg.dec | 6 -- MdeModulePkg/MdeModulePkg.uni | 4 2 files changed, 10 deletions(-) diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec index 428eeeb670..0abacc1a90 100644 --- a/MdeModulePkg/MdeModulePkg.dec +++ b/MdeModulePkg/MdeModulePkg.dec @@ -2007,12 +2007,6 @@ # @ValidList 0x8001 | 0x0 gEfiMdeModulePkgTokenSpaceGuid.PcdS3BootScriptTablePrivateSmmDataPtr|0x0|UINT64|0x00030001 - ## This dynamic PCD hold an address to point to the memory of page table. The page table establishes a 1:1 - # Virtual to Physical mapping according to the processor physical address bits. - # @Prompt Identify Mapping Page Table pointer. - # @ValidList 0x8001 | 0x0 - gEfiMdeModulePkgTokenSpaceGuid.PcdIdentifyMappingPageTablePtr|0x0|UINT64|0x00030002 - ## This dynamic PCD holds the information if there is any test key used by the platform. # @Prompt If there is any test key used by the platform. gEfiMdeModulePkgTokenSpaceGuid.PcdTestKeyUsed|FALSE|BOOLEAN|0x00030003 diff --git a/MdeModulePkg/MdeModulePkg.uni b/MdeModulePkg/MdeModulePkg.uni index 5fa7a6ae30..038e848505 100644 --- a/MdeModulePkg/MdeModulePkg.uni +++ b/MdeModulePkg/MdeModulePkg.uni @@ -914,10 +914,6 @@ "this PCD to be TURE if and only if all runtime driver has seperated Code/Data\n" "section. If PE code/data sections are merged, the result is unpredictable.\n" -#string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdIdentifyMappingPageTablePtr_PROMPT #language en-US "Identify Mapping Page Table pointer." - -#string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdIdentifyMappingPageTablePtr_HELP #language en-US "This dynamic PCD hold an address to point to the memory of page table. The page table establishes a 1:1\n" - "Virtual to Physical mapping according to the processor physical address bits." #string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdShadowPeimOnBoot_HELP #language en-US "Indicates if to shadow PEIM and PeiCore after memory is ready.\n" "This PCD is used on other boot path except for S3 boot.\n" "TRUE - Shadow PEIM and PeiCore after memory is ready.\n" -- 2.18.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [edk2-announce][RFC] Collaboration Software
All of these reasons (along with scalability) is why the linux kernel development hasn't moved from email mailing lists and they have tried several times. Cheers, Tom On 16/11/2018 22:14, Philippe Mathieu-Daudé wrote: > On 16/11/18 21:46, stephano wrote: >> This looks great. >> >> I'm going to dig in a bit and see if we can export discussions for logging >> purposes or if they are locked into Github. > > For people on the move, having bad internet (3rd world countries), email > system is very powerful, you can download once and work offline, > reading/answering. You can also download the list archive and refers to it > offline. You also have access to all patches and can apply them offline too. > > Is this possible with GitHub? > > Maybe the open source alternative, GitLab, offers a such feature. > > Googling "gitlab offline" I get: > > "Many of our customers do not have regular Internet access and many of them, > being highly regulated, cannot install local copies of GitLab to be able to > run against the provided API. [...] The work, published as the > gitlab-ci-yaml_lint gem, is my attempt at a start to solving the issue." > > This is not what I expected, but it confirms some people have troubles > working with online-only services. > > Regards, > > Phil. > >> >> git clone git://tianocore.discussion ? :) >> >> On 11/16/2018 11:55 AM, Kinney, Michael D wrote: >>> Hi Stephano, >>> >>> GitHub supports discussions for teams. >>> >>> If we added a new team to the GitHub TianoCore >>> organization for all developers that want to be >>> involved in community topics and design discussions >>> (which should closely match the current members of >>> edk2-devel) then that may be a simple option that >>> uses services that already there. >>> >>> Another option is to use discussions for one of the >>> exiting teams (e.g. Tianocore Maintainers) and make >>> posts for these discussion topics public. >>> >>> https://blog.github.com/2017-11-20-introducing-team-discussions/ >>> >>> https://help.github.com/articles/about-team-discussions/ >>> >>> Best regards, >>> >>> Mike >>> >>> >>> >>> -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of stephano Sent: Friday, November 16, 2018 11:14 AM To: Zimmer, Vincent ; edk2- de...@lists.01.org Subject: Re: [edk2] [edk2-announce][RFC] Collaboration Software The only reason I didn't include Slack is that it will only log so much information before things start falling off into the ether. Does anyone in the community currently use Slack and know of an easy way of archiving conversations publicly? On 11/16/2018 9:56 AM, Zimmer, Vincent wrote: > https://slack.com/ > > -Original Message- > From: edk2-devel [mailto:edk2-devel- boun...@lists.01.org] On Behalf Of Kevin D Davis > Sent: Friday, November 16, 2018 9:35 AM > To: stephano ; edk2- de...@lists.01.org > Subject: Re: [edk2] [edk2-announce][RFC] Collaboration Software > > > > > > > If we get to vote, I’d vote against Google Groups. Their interface is very geared toward their internal work flow and seems to change on a whim. Thanks,Kevin > > > > > > On Fri, Nov 16, 2018 at 11:08 AM -0600, "stephano" wrote: > > > > > > > > > > > We are looking to augment our current communication methods (mailing list / IRC) with a modern solution for group collaboration. The goal is to allow folks to communicate effectively without interrupting the current patch review system, as well as enabling any future systems with more robust options. > > Specific features we are looking for include attachments (currently blocked by the list), robust logging, modern chat, and integration with tools like bug trackers and source repositories (APIs, or better yet, pre-rolled plugins). > > Our current contenders are Google Groups and Groups.io. This RFC is in hopes of finding other options to evaluate. > > Cheers, > Stephano > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > > > > > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > ___ edk2-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 v3 edk2-platforms 0/5] Platform/ARM/Sgi: Add support for Clark.Ares and Clark.Helios platforms
On Mon, Nov 12, 2018 at 9:57 PM Leif Lindholm wrote: > > Hi Chadni, > > I will disregard this set. > Please send out a new v3 containing the changes we've discussed, only > after I've completed reviewing the set. > > Best Regards, > > Leif > Hi Leif, Can I post the new v3 patchset containing the changes that we've discussed? Thanks Chandni > On Mon, Nov 12, 2018 at 05:11:51PM +0530, Chandni Cherukuri wrote: > > Changes since v2: > > - Added additional checks for platform-id and config-id values. > > > > Changes since v1: > > - No code changes, posting this series again with correct patch subject > > > > This patch series adds support for two new Arm's SGI platforms - > > SGI-Clark.Ares and SGI-Clark.Helios. The first patch in this > > series adds support to use a new binding added to the system-id > > node for Platform Identification. The rest of the patches add > > support for the two new SGI platforms. > > > > Chandni Cherukuri (5): > > Platform/ARM/Sgi: Adapt to changes in system-id DT node. > > Platform/ARM/Sgi: Add ACPI tables for SGI-Clark.Ares platform > > Platform/ARM/Sgi: Add initial support for SGI-Clark.Ares platform > > Platform/ARM/Sgi: Add ACPI tables for SGI-Clark.Helios platform > > Platform/ARM/Sgi: Add initial support for SGI-Clark.Helios platform > > > > Platform/ARM/SgiPkg/SgiPlatform.dec | 2 + > > Platform/ARM/SgiPkg/SgiPlatform.dsc | 2 + > > Platform/ARM/SgiPkg/SgiPlatform.fdf | 2 + > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/AcpiTables.inf | 58 + > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/AcpiTables.inf | 58 + > > Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf | 2 + > > Platform/ARM/SgiPkg/Include/SgiPlatform.h| 5 + > > Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c| 19 +- > > Platform/ARM/SgiPkg/Library/SgiPlatformPei/SgiPlatformPeim.c | 24 +- > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Dbg2.aslc | 90 +++ > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Dsdt.asl| 116 > > + > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Fadt.aslc | 87 +++ > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Gtdt.aslc | 152 > > +++ > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Iort.aslc | 106 > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Madt.aslc | 171 > > + > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Mcfg.aslc | 61 + > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Spcr.aslc | 77 ++ > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Ssdt.asl| 95 +++ > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Dbg2.aslc | 90 +++ > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Dsdt.asl| 262 > > +++ > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Fadt.aslc | 87 +++ > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Gtdt.aslc | 152 > > +++ > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Iort.aslc | 106 > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Madt.aslc | 266 > > > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Mcfg.aslc | 61 + > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Spcr.aslc | 77 ++ > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Ssdt.asl| 95 +++ > > 27 files changed, 2315 insertions(+), 8 deletions(-) > > create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/AcpiTables.inf > > create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/AcpiTables.inf > > create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Dbg2.aslc > > create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Dsdt.asl > > create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Fadt.aslc > > create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Gtdt.aslc > > create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Iort.aslc > > create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Madt.aslc > > create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Mcfg.aslc > > create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Spcr.aslc > > create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Ssdt.asl > > create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Dbg2.aslc > > create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Dsdt.asl > > create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Fadt.aslc > > create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Gtdt.aslc > > create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Iort.aslc > > create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Madt.aslc > > create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Mcfg.aslc > > create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Spcr.aslc > > create mode 1006
Re: [edk2] [PATCH v3 edk2-platforms 0/5] Platform/ARM/Sgi: Add support for Clark.Ares and Clark.Helios platforms
Hi Chandni, On Mon, Nov 19, 2018 at 05:00:39PM +0530, chandni cherukuri wrote: > On Mon, Nov 12, 2018 at 9:57 PM Leif Lindholm > wrote: > > > > Hi Chadni, > > > > I will disregard this set. > > Please send out a new v3 containing the changes we've discussed, only > > after I've completed reviewing the set. > > > > Best Regards, > > > > Leif > > > > Hi Leif, > > Can I post the new v3 patchset containing the changes that we've discussed? I have one more comment/question that applies to a few of the ACPI files. Last week I was at Linux Plumbers Conference with very patchy availability, so didn't get the time. Regards, Leif > Thanks > Chandni > > > On Mon, Nov 12, 2018 at 05:11:51PM +0530, Chandni Cherukuri wrote: > > > Changes since v2: > > > - Added additional checks for platform-id and config-id values. > > > > > > Changes since v1: > > > - No code changes, posting this series again with correct patch subject > > > > > > This patch series adds support for two new Arm's SGI platforms - > > > SGI-Clark.Ares and SGI-Clark.Helios. The first patch in this > > > series adds support to use a new binding added to the system-id > > > node for Platform Identification. The rest of the patches add > > > support for the two new SGI platforms. > > > > > > Chandni Cherukuri (5): > > > Platform/ARM/Sgi: Adapt to changes in system-id DT node. > > > Platform/ARM/Sgi: Add ACPI tables for SGI-Clark.Ares platform > > > Platform/ARM/Sgi: Add initial support for SGI-Clark.Ares platform > > > Platform/ARM/Sgi: Add ACPI tables for SGI-Clark.Helios platform > > > Platform/ARM/Sgi: Add initial support for SGI-Clark.Helios platform > > > > > > Platform/ARM/SgiPkg/SgiPlatform.dec | 2 + > > > Platform/ARM/SgiPkg/SgiPlatform.dsc | 2 + > > > Platform/ARM/SgiPkg/SgiPlatform.fdf | 2 + > > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/AcpiTables.inf | 58 + > > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/AcpiTables.inf | 58 + > > > Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf | 2 + > > > Platform/ARM/SgiPkg/Include/SgiPlatform.h| 5 + > > > Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c| 19 +- > > > Platform/ARM/SgiPkg/Library/SgiPlatformPei/SgiPlatformPeim.c | 24 +- > > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Dbg2.aslc | 90 > > > +++ > > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Dsdt.asl| 116 > > > + > > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Fadt.aslc | 87 > > > +++ > > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Gtdt.aslc | 152 > > > +++ > > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Iort.aslc | 106 > > > > > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Madt.aslc | 171 > > > + > > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Mcfg.aslc | 61 + > > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Spcr.aslc | 77 ++ > > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Ssdt.asl| 95 > > > +++ > > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Dbg2.aslc | 90 > > > +++ > > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Dsdt.asl| 262 > > > +++ > > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Fadt.aslc | 87 > > > +++ > > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Gtdt.aslc | 152 > > > +++ > > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Iort.aslc | 106 > > > > > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Madt.aslc | 266 > > > > > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Mcfg.aslc | 61 + > > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Spcr.aslc | 77 ++ > > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Ssdt.asl| 95 > > > +++ > > > 27 files changed, 2315 insertions(+), 8 deletions(-) > > > create mode 100644 > > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/AcpiTables.inf > > > create mode 100644 > > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/AcpiTables.inf > > > create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Dbg2.aslc > > > create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Dsdt.asl > > > create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Fadt.aslc > > > create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Gtdt.aslc > > > create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Iort.aslc > > > create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Madt.aslc > > > create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Mcfg.aslc > > > create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Spcr.aslc > > > create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Ssdt.asl > > > create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Dbg2.aslc > > > create mode 100644 Platf
[edk2] [PATCH v2] EmulatorPkg/Unix/Host fixed numeric pad function
From: Pedroa Liu
origin code in Unix Host numeric pad has no function in shell environment
since we can't get "XK_KP_0 ~ XK_KP_9" from XGetKeyboardMapping just can
get "numlock" key status.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pedroa Liu
---
EmulatorPkg/Unix/Host/X11GraphicsWindow.c | 54 ++-
1 file changed, 43 insertions(+), 11 deletions(-)
diff --git a/EmulatorPkg/Unix/Host/X11GraphicsWindow.c
b/EmulatorPkg/Unix/Host/X11GraphicsWindow.c
index a3cc28c223..573f0f1bfd 100644
--- a/EmulatorPkg/Unix/Host/X11GraphicsWindow.c
+++ b/EmulatorPkg/Unix/Host/X11GraphicsWindow.c
@@ -271,7 +271,14 @@ handleKeyEvent (
}
}
- // Skipping EFI_MENU_KEY_PRESSED and EFI_SYS_REQ_PRESSED
+ if ((ev->xkey.state & Mod2Mask) == 0) {
+Drv->KeyState.KeyToggleState &= ~EFI_NUM_LOCK_ACTIVE;
+ } else {
+if (Make) {
+ Drv->KeyState.KeyToggleState |= EFI_NUM_LOCK_ACTIVE;
+}
+ }
+ // Skipping EFI_MENU_KEY_PRESSED and EFI_SYS_REQ_PRESSED
switch (*KeySym) {
case XK_Control_R:
@@ -328,35 +335,70 @@ handleKeyEvent (
break;
case XK_KP_Home:
+if ((Drv->KeyState.KeyShiftState & (EFI_LEFT_SHIFT_PRESSED |
EFI_RIGHT_SHIFT_PRESSED)) ^ (Drv->KeyState.KeyToggleState &
(EFI_NUM_LOCK_ACTIVE))) {
+ KeyData.Key.UnicodeChar = L'7'; break;
+}
case XK_Home: KeyData.Key.ScanCode = SCAN_HOME; break;
case XK_KP_End:
+if ((Drv->KeyState.KeyShiftState & (EFI_LEFT_SHIFT_PRESSED |
EFI_RIGHT_SHIFT_PRESSED)) ^ (Drv->KeyState.KeyToggleState &
(EFI_NUM_LOCK_ACTIVE))) {
+ KeyData.Key.UnicodeChar = L'1'; break;
+}
case XK_End:KeyData.Key.ScanCode = SCAN_END;break;
case XK_KP_Left:
+if ((Drv->KeyState.KeyShiftState & (EFI_LEFT_SHIFT_PRESSED |
EFI_RIGHT_SHIFT_PRESSED)) ^ (Drv->KeyState.KeyToggleState &
(EFI_NUM_LOCK_ACTIVE))) {
+ KeyData.Key.UnicodeChar = L'4'; break;
+}
case XK_Left: KeyData.Key.ScanCode = SCAN_LEFT; break;
case XK_KP_Right:
+if((Drv->KeyState.KeyShiftState & (EFI_LEFT_SHIFT_PRESSED |
EFI_RIGHT_SHIFT_PRESSED)) ^ (Drv->KeyState.KeyToggleState &
(EFI_NUM_LOCK_ACTIVE)) ){
+ KeyData.Key.UnicodeChar = L'6'; break;
+}
case XK_Right: KeyData.Key.ScanCode = SCAN_RIGHT; break;
case XK_KP_Up:
+if((Drv->KeyState.KeyShiftState & (EFI_LEFT_SHIFT_PRESSED |
EFI_RIGHT_SHIFT_PRESSED)) ^ (Drv->KeyState.KeyToggleState &
(EFI_NUM_LOCK_ACTIVE)) ){
+ KeyData.Key.UnicodeChar = L'8'; break;
+}
case XK_Up: KeyData.Key.ScanCode = SCAN_UP; break;
case XK_KP_Down:
+if((Drv->KeyState.KeyShiftState & (EFI_LEFT_SHIFT_PRESSED |
EFI_RIGHT_SHIFT_PRESSED)) ^ (Drv->KeyState.KeyToggleState &
(EFI_NUM_LOCK_ACTIVE)) ){
+ KeyData.Key.UnicodeChar = L'2'; break;
+}
case XK_Down: KeyData.Key.ScanCode = SCAN_DOWN; break;
case XK_KP_Delete:
+if((Drv->KeyState.KeyShiftState & (EFI_LEFT_SHIFT_PRESSED |
EFI_RIGHT_SHIFT_PRESSED)) ^ (Drv->KeyState.KeyToggleState &
(EFI_NUM_LOCK_ACTIVE)) ){
+ KeyData.Key.UnicodeChar = L'.'; break;
+}
case XK_Delete: KeyData.Key.ScanCode = SCAN_DELETE; break;
case XK_KP_Insert:
+if((Drv->KeyState.KeyShiftState & (EFI_LEFT_SHIFT_PRESSED |
EFI_RIGHT_SHIFT_PRESSED)) ^ (Drv->KeyState.KeyToggleState &
(EFI_NUM_LOCK_ACTIVE)) ){
+ KeyData.Key.UnicodeChar = L'0';break;
+}
case XK_Insert: KeyData.Key.ScanCode = SCAN_INSERT; break;
case XK_KP_Page_Up:
+if((Drv->KeyState.KeyShiftState & (EFI_LEFT_SHIFT_PRESSED |
EFI_RIGHT_SHIFT_PRESSED)) ^ (Drv->KeyState.KeyToggleState &
(EFI_NUM_LOCK_ACTIVE)) ){
+ KeyData.Key.UnicodeChar = L'9'; break;
+}
case XK_Page_Up:KeyData.Key.ScanCode = SCAN_PAGE_UP;break;
case XK_KP_Page_Down:
+if((Drv->KeyState.KeyShiftState & (EFI_LEFT_SHIFT_PRESSED |
EFI_RIGHT_SHIFT_PRESSED)) ^ (Drv->KeyState.KeyToggleState &
(EFI_NUM_LOCK_ACTIVE)) ){
+ KeyData.Key.UnicodeChar = L'3'; break;
+}
case XK_Page_Down: KeyData.Key.ScanCode = SCAN_PAGE_DOWN; break;
+ case XK_KP_Begin:
+if((Drv->KeyState.KeyShiftState & (EFI_LEFT_SHIFT_PRESSED |
EFI_RIGHT_SHIFT_PRESSED)) ^ (Drv->KeyState.KeyToggleState &
(EFI_NUM_LOCK_ACTIVE)) ){
+ KeyData.Key.UnicodeChar = L'5'; break;
+}
+/* no map efi scan code */ break;
case XK_Escape: KeyData.Key.ScanCode = SCAN_ESC;break;
case XK_Pause: KeyData.Key.ScanCode = SCAN_PAUSE; break;
@@ -431,16 +473,6 @@ handleKeyEvent (
case XK_KP_Decimal: KeyData.Key.UnicodeChar = L'.'; break;
case XK_KP_Divide : KeyData.Key.UnicodeChar = L'/'; break;
- case XK_KP_0: KeyData.Key.UnicodeChar = L'0'; break;
- case XK_KP_1: KeyData.Key.UnicodeChar = L'1'; break;
- case XK_KP_2: KeyData.Key.UnicodeChar = L'2'; break;
- case XK_KP_3: KeyData.Key.UnicodeChar = L'3'; break;
-
Re: [edk2] [PATCH v3 edk2-platforms 3/5] Platform/ARM/Sgi: Add initial support for SGI-Clark.Ares platform
On Mon, Nov 12, 2018 at 05:11:54PM +0530, Chandni Cherukuri wrote:
> Add the initial support for ARM's System Guidance for Infrastructure
> SGI-Clark.Ares platform. The ACPI tables for this platform are
> installed.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Cc: Leif Lindholm
> Cc: Ard Biesheuvel
> Signed-off-by: Chandni Cherukuri
> ---
> Platform/ARM/SgiPkg/Include/SgiPlatform.h | 4
> Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c | 16 +---
> 2 files changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/Platform/ARM/SgiPkg/Include/SgiPlatform.h
> b/Platform/ARM/SgiPkg/Include/SgiPlatform.h
> index 1454018..b84709e 100644
> --- a/Platform/ARM/SgiPkg/Include/SgiPlatform.h
> +++ b/Platform/ARM/SgiPkg/Include/SgiPlatform.h
> @@ -72,6 +72,10 @@
> #define SGI575_CONF_NUM 0x3
> #define SGI575_PART_NUM 0x783
>
> +//SGI-Clark Platform Identification values
> +#define SGI_CLARK_PART_NUM0x786
> +#define SGI_CLARKA_CONF_NUM 0x1
I would prefer for this to be SGI_CLARK_CONF_NUM_A (assuming, of
course, this refers to "configuration A"). With that change:
Reviewed-by: Leif Lindholm
/
Leif
> +
> #define SGI_CONFIG_MASK 0x0F
> #define SGI_CONFIG_SHIFT 0x1C
> #define SGI_PART_NUM_MASK 0xFFF
> diff --git a/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c
> b/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c
> index 5ccd01d..1c56f65 100644
> --- a/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c
> +++ b/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c
> @@ -48,14 +48,16 @@ ArmSgiPkgEntryPoint (
>
>if ((PartNum == SGI575_PART_NUM) && (ConfigId == SGI575_CONF_NUM)) {
> Status = LocateAndInstallAcpiFromFv (&gSgi575AcpiTablesFileGuid);
> -if (EFI_ERROR (Status)) {
> - DEBUG ((DEBUG_ERROR, "%a: Failed to install ACPI tables\n",
> -__FUNCTION__));
> - return Status;
> -}
> + } else if ((PartNum == SGI_CLARK_PART_NUM) &&
> + (ConfigId == SGI_CLARKA_CONF_NUM)) {
> +Status = LocateAndInstallAcpiFromFv (&gSgiClarkAresAcpiTablesFileGuid);
>} else {
> -DEBUG ((DEBUG_ERROR, "PlatformDxe: Unsupported Platform Id\n"));
> -return EFI_UNSUPPORTED;
> +Status = EFI_UNSUPPORTED;
> + }
> +
> + if (EFI_ERROR (Status)) {
> +DEBUG ((DEBUG_ERROR, "%a: Failed to install ACPI tables\n",
> __FUNCTION__));
> +return Status;
>}
>
>Status = EFI_REQUEST_UNLOAD_IMAGE;
> --
> 2.7.4
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 edk2-platforms 2/5] Platform/ARM/Sgi: Add ACPI tables for SGI-Clark.Ares platform
On Mon, Nov 12, 2018 at 05:11:53PM +0530, Chandni Cherukuri wrote:
> Added ACPI tables and GUID name 'gSgiClarkAresAcpiTablesFileGuid'
> for SGI-Clark.Ares platform.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Cc: Leif Lindholm
> Cc: Ard Biesheuvel
> Signed-off-by: Chandni Cherukuri
> ---
> Platform/ARM/SgiPkg/SgiPlatform.dec | 1 +
> Platform/ARM/SgiPkg/SgiPlatform.dsc | 1 +
> Platform/ARM/SgiPkg/SgiPlatform.fdf | 1 +
> Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/AcpiTables.inf | 58 +++
> Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf | 1 +
> Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Dbg2.aslc | 90 +++
> Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Dsdt.asl | 116 +
> Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Fadt.aslc | 87 ++
> Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Gtdt.aslc | 152
> +
> Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Iort.aslc | 106
> Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Madt.aslc | 171
>
> Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Mcfg.aslc | 61 +++
> Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Spcr.aslc | 77 +
> Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Ssdt.asl | 95 +++
Again, if SgiClarkA is a configuration, I would prefer the
configuration as a subdirectory, not merged with the platform name.
But I would also add that I would hope the intent is not to duplicate
everything into a separate "B" directory if/when a new configuration
turns up? Surely 98% of the content would remain unchanged.
If so, can we just drop the A from the directory name?
> 14 files changed, 1017 insertions(+)
>
> diff --git a/Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Dbg2.aslc
> b/Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Dbg2.aslc
> new file mode 100644
> index 000..3970461
> --- /dev/null
> +++ b/Platform/ARM/SgiPkg/AcpiTables/SgiClarkA/Dbg2.aslc
> @@ -0,0 +1,90 @@
> +/** @file
> +* Debug Port Table 2 (DBG2)
> +*
> +* Copyright (c) 2018, ARM 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.
> +*
> +**/
> +
> +#include "SgiAcpiHeader.h"
> +#include
> +#include
> +#include
> +
> +#define SGI_DBG2_NUM_DEBUG_PORTS 1
> +#define SGI_DBG2_NUM_GAS 1
> +#define SGI_DBG2_NS_STR_LENGTH 8
> +#define SGI_PL011_REGISTER_SPACE 0x1000
> +
> +#define NAME_STR_UART1 {'C', 'O', 'M', '1', '\0', '\0', '\0', '\0'}
Here was the thing I was referring to earlier today:
Is this used the same as what is now being fixed in
https://lists.01.org/pipermail/edk2-devel/2018-November/032523.html ?
If so, please update here and get it right from the start.
/
Leif
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 edk2-platforms 4/5] Platform/ARM/Sgi: Add ACPI tables for SGI-Clark.Helios platform
On Mon, Nov 12, 2018 at 05:11:55PM +0530, Chandni Cherukuri wrote: > Added ACPI tables and GUID name 'gSgiClarkHeliosAcpiTablesFileGuid' > for SGI-Clark.Helios platform. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Cc: Leif Lindholm > Cc: Ard Biesheuvel > Signed-off-by: Chandni Cherukuri > --- > Platform/ARM/SgiPkg/SgiPlatform.dec | 1 + > Platform/ARM/SgiPkg/SgiPlatform.dsc | 1 + > Platform/ARM/SgiPkg/SgiPlatform.fdf | 1 + > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/AcpiTables.inf | 58 + > Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf | 1 + > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Dbg2.aslc | 90 +++ > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Dsdt.asl | 262 > +++ > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Fadt.aslc | 87 +++ > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Gtdt.aslc | 152 +++ > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Iort.aslc | 106 > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Madt.aslc | 266 > > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Mcfg.aslc | 61 + > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Spcr.aslc | 77 ++ > Platform/ARM/SgiPkg/AcpiTables/SgiClarkH/Ssdt.asl | 95 +++ > 14 files changed, 1258 insertions(+) Oh, right, the "A" wasn't a platform revision, it was "Ares". And this is "Helios". Then please, ignore previous comments - the other one needs to be written out ARES/Ares and this one needs to be written out HELIOS/Helios. At which point we are in dire need of deduplication of these ACPI tables: - DBG2, SPCR and MCFG are already identical between the new platforms, and Sgi575 should be modified to the same format. (This set leaving Sgi575 on ACPI6.1 definitions while the new platforms go to 6.2 should be enough explanation for why we need to refactor this.) - IORT has no functional differences at all for A/H, and 575 differs only in (incorrectly) using __builtin_offsetof instead of the OFFSET_OF macro, and the ACPI version. - SSDT differs only in coding style issues and the platform name (which could come in through an include file). - GTDT and FADT are identical between A/H, and only ACPI version differences compared to 575. - DSDT and MADT, I accept, are different enough that a per-configuration source file makes sense. So please resubmit this as a set that: - Moves Dbg2.aslc, Fadt.aslc, Gtdt.aslc, Iort.aslc, Mcfg.aslc, Spcr.aslc and Ssdt.asl directly under Platform/ARM/SgiPkg/AcpiTables/. Moves AcpiTables.inf to Platform/ARM/SgiPkg/AcpiTables/Sgi575AcpiTables.inf. Updates Platform/ARM/SgiPkg/SgiPlatform.dsc so that Sgi575 still builds. - Updates Sgi575 with whatever is required to pull the platform name in for SSDT. - Considers the COM1 name as mentioned in comment on previous patch. (I say considers: if I've misunderstood something, that one can be ignored.) - Brings in Ares and Helios platforms. (separate patches like now) - Brings in Ares and Helios ACPI tables, adding platform-specific Dsdt.asl and Madt.aslc under SgiClarkAres/SgiClarkHelios. (separate patches like now) With .inf files SgiClarkAresAcpiTables.inf and SgiClarkHeliosAcpiTables.inf. And once this is done, I no longer need to echo exactly the same comments I gave for the preceding patch, because everything will have alrady been addressed. Regards, Leif ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 edk2-platforms 5/5] Platform/ARM/Sgi: Add initial support for SGI-Clark.Helios platform
On Mon, Nov 12, 2018 at 05:11:56PM +0530, Chandni Cherukuri wrote:
> Add the initial support for ARM's System Guidance for Infrastructure
> SGI-Clark.Helios platform. The ACPI tables for this platform are
> installed.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Cc: Leif Lindholm
> Cc: Ard Biesheuvel
> Signed-off-by: Chandni Cherukuri
> ---
> Platform/ARM/SgiPkg/Include/SgiPlatform.h | 1 +
> Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c | 3 +++
> 2 files changed, 4 insertions(+)
>
> diff --git a/Platform/ARM/SgiPkg/Include/SgiPlatform.h
> b/Platform/ARM/SgiPkg/Include/SgiPlatform.h
> index b84709e..7b0bb4a 100644
> --- a/Platform/ARM/SgiPkg/Include/SgiPlatform.h
> +++ b/Platform/ARM/SgiPkg/Include/SgiPlatform.h
> @@ -75,6 +75,7 @@
> //SGI-Clark Platform Identification values
> #define SGI_CLARK_PART_NUM0x786
> #define SGI_CLARKA_CONF_NUM 0x1
> +#define SGI_CLARKH_CONF_NUM 0x2
So, this one should be
SGI_CLARK_CONF_NUM_HELIOS
_or_
SGI_CLARK_CONF_HELIOS
.
And SGI_CLARKA_CONF_NUM should be
SGI_CLARK_CONF_NUM_ARES
_or_
SGI_CLARK_CONF_ARES
.
/
Leif
>
> #define SGI_CONFIG_MASK 0x0F
> #define SGI_CONFIG_SHIFT 0x1C
> diff --git a/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c
> b/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c
> index 1c56f65..cf085f8 100644
> --- a/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c
> +++ b/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c
> @@ -51,6 +51,9 @@ ArmSgiPkgEntryPoint (
>} else if ((PartNum == SGI_CLARK_PART_NUM) &&
> (ConfigId == SGI_CLARKA_CONF_NUM)) {
> Status = LocateAndInstallAcpiFromFv (&gSgiClarkAresAcpiTablesFileGuid);
> + } else if ((PartNum == SGI_CLARK_PART_NUM) &&
> + (ConfigId == SGI_CLARKH_CONF_NUM)) {
> +Status = LocateAndInstallAcpiFromFv (&gSgiClarkHeliosAcpiTablesFileGuid);
>} else {
> Status = EFI_UNSUPPORTED;
>}
> --
> 2.7.4
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH] Silicon/SynQuacer: remove bogus PL011 _HID from DSDT ACPI table
PL011 is not a valid ACPI identifier so don't expose it as a _CID.
Since _CID (Comptable ID) is optional, let's just drop it.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
Silicon/Socionext/SynQuacer/AcpiTables/Dsdt.asl | 1 -
1 file changed, 1 deletion(-)
diff --git a/Silicon/Socionext/SynQuacer/AcpiTables/Dsdt.asl
b/Silicon/Socionext/SynQuacer/AcpiTables/Dsdt.asl
index 3f73c191d4d6..7c7677f1fea0 100644
--- a/Silicon/Socionext/SynQuacer/AcpiTables/Dsdt.asl
+++ b/Silicon/Socionext/SynQuacer/AcpiTables/Dsdt.asl
@@ -135,7 +135,6 @@ DefinitionBlock ("DsdtTable.aml", "DSDT", 1, "SNI",
"SYNQUACR",
// UART PL011
Device (COM0) {
Name (_HID, "ARMH0011")
- Name (_CID, "PL011")
Name (_UID, Zero)
Name (_CRS, ResourceTemplate () {
Memory32Fixed (ReadWrite, FixedPcdGet32 (PcdSerialRegisterBase),
0x1000)
--
2.17.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] Silicon/SynQuacer: remove bogus PL011 _HID from DSDT ACPI table
On Mon, Nov 19, 2018 at 08:03:38AM -0800, Ard Biesheuvel wrote:
> PL011 is not a valid ACPI identifier so don't expose it as a _CID.
> Since _CID (Comptable ID) is optional, let's just drop it.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
> ---
> Silicon/Socionext/SynQuacer/AcpiTables/Dsdt.asl | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/Silicon/Socionext/SynQuacer/AcpiTables/Dsdt.asl
> b/Silicon/Socionext/SynQuacer/AcpiTables/Dsdt.asl
> index 3f73c191d4d6..7c7677f1fea0 100644
> --- a/Silicon/Socionext/SynQuacer/AcpiTables/Dsdt.asl
> +++ b/Silicon/Socionext/SynQuacer/AcpiTables/Dsdt.asl
> @@ -135,7 +135,6 @@ DefinitionBlock ("DsdtTable.aml", "DSDT", 1, "SNI",
> "SYNQUACR",
> // UART PL011
> Device (COM0) {
>Name (_HID, "ARMH0011")
> - Name (_CID, "PL011")
>Name (_UID, Zero)
>Name (_CRS, ResourceTemplate () {
> Memory32Fixed (ReadWrite, FixedPcdGet32 (PcdSerialRegisterBase),
> 0x1000)
> --
> 2.17.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v2 07/15] Hisilicon/D0x: Fix secure boot bug in FlashFvbDxe
On Fri, Nov 16, 2018 at 02:56:54PM +0800, Ming Huang wrote:
> When SECURE_BOOT_ENABLE is TRUE, FlashFvbDxe should use
> gEfiAuthenticatedVariableGuid, When SECURE_BOOT_ENABLE
> is FALSE, gEfiVariableGuid should be used.
>
Other platforms seem to resolve this by doing something like:
!if $(SECURE_BOOT_ENABLE)
...
AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
!else
AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
!endif
Can the same mechanism be used here instead?
I _really_ don't like the idea of adding vendor-specific Pcds to
determine whether Secure Boot is enabled.
/
Leif
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
> ---
> Silicon/Hisilicon/HisiPkg.dec | 1 +
> Platform/Hisilicon/D03/D03.dsc| 5 +
> Platform/Hisilicon/D05/D05.dsc| 5 +
> Platform/Hisilicon/D06/D06.dsc| 5 +
> Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.inf | 2 ++
> Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.c | 14 --
> 6 files changed, 30 insertions(+), 2 deletions(-)
>
> diff --git a/Silicon/Hisilicon/HisiPkg.dec b/Silicon/Hisilicon/HisiPkg.dec
> index 404a3ae4af9d..af9359e4d0e0 100644
> --- a/Silicon/Hisilicon/HisiPkg.dec
> +++ b/Silicon/Hisilicon/HisiPkg.dec
> @@ -278,6 +278,7 @@ [PcdsFixedAtBuild]
>
>gHisiTokenSpaceGuid.Pcdsoctype|0|UINT32|0x0061
>gHisiTokenSpaceGuid.PcdSerDesFlowCtrlFlag|0|UINT32|0x4056
> + gHisiTokenSpaceGuid.PcdIsSecureBoot|FALSE|BOOLEAN|0x4058
>
> [PcdsFeatureFlag]
>gHisiTokenSpaceGuid.PcdIsItsSupported|FALSE|BOOLEAN|0x0065
> diff --git a/Platform/Hisilicon/D03/D03.dsc b/Platform/Hisilicon/D03/D03.dsc
> index aa1da5d61f83..ba3096672db0 100644
> --- a/Platform/Hisilicon/D03/D03.dsc
> +++ b/Platform/Hisilicon/D03/D03.dsc
> @@ -281,6 +281,11 @@ [PcdsFixedAtBuild.common]
>gHisiTokenSpaceGuid.PcdHb0Rb2IoSize|0x #64K
>
>gHisiTokenSpaceGuid.Pcdsoctype|0x1610
> + !if $(SECURE_BOOT_ENABLE) == TRUE
> +gHisiTokenSpaceGuid.PcdIsSecureBoot|TRUE
> + !else
> +gHisiTokenSpaceGuid.PcdIsSecureBoot|FALSE
> + !endif
>
>
>
> #
> diff --git a/Platform/Hisilicon/D05/D05.dsc b/Platform/Hisilicon/D05/D05.dsc
> index 1040466633ef..b8500cef8742 100644
> --- a/Platform/Hisilicon/D05/D05.dsc
> +++ b/Platform/Hisilicon/D05/D05.dsc
> @@ -422,6 +422,11 @@ [PcdsFixedAtBuild.common]
>gHisiTokenSpaceGuid.PcdHb1Rb7IoSize|0x1 #64K
>
>gHisiTokenSpaceGuid.Pcdsoctype|0x1610
> + !if $(SECURE_BOOT_ENABLE) == TRUE
> +gHisiTokenSpaceGuid.PcdIsSecureBoot|TRUE
> + !else
> +gHisiTokenSpaceGuid.PcdIsSecureBoot|FALSE
> + !endif
>
>
>
> #
> diff --git a/Platform/Hisilicon/D06/D06.dsc b/Platform/Hisilicon/D06/D06.dsc
> index 1a479c160e80..b6ef9fedf0a7 100644
> --- a/Platform/Hisilicon/D06/D06.dsc
> +++ b/Platform/Hisilicon/D06/D06.dsc
> @@ -243,6 +243,11 @@ [PcdsFixedAtBuild.common]
>
>gEfiMdeModulePkgTokenSpaceGuid.PcdSrIovSupport|FALSE
>gArmTokenSpaceGuid.PcdPciIoTranslation|0x0
> + !if $(SECURE_BOOT_ENABLE) == TRUE
> +gHisiTokenSpaceGuid.PcdIsSecureBoot|TRUE
> + !else
> +gHisiTokenSpaceGuid.PcdIsSecureBoot|FALSE
> + !endif
>
>
>
> #
> diff --git a/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.inf
> b/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.inf
> index f8be4741ef7c..47965a707032 100644
> --- a/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.inf
> +++ b/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.inf
> @@ -44,6 +44,7 @@ [LibraryClasses]
>UefiRuntimeLib
>
> [Guids]
> + gEfiAuthenticatedVariableGuid
>gEfiSystemNvDataFvGuid
>gEfiVariableGuid
>
> @@ -62,6 +63,7 @@ [Pcd.common]
>gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
>
>gArmPlatformTokenSpaceGuid.PcdNorFlashCheckBlockLocked
> + gHisiTokenSpaceGuid.PcdIsSecureBoot
>gHisiTokenSpaceGuid.PcdSFCMEM0BaseAddress
>
> [Depex]
> diff --git a/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.c
> b/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.c
> index e18cc9e06ec2..309941d6fe4d 100644
> --- a/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.c
> +++ b/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.c
> @@ -189,7 +189,11 @@ InitializeFvAndVariableStoreHeaders (
> // VARIABLE_STORE_HEADER
> //
> VariableStoreHeader = (VARIABLE_STORE_HEADER*)((UINTN)Headers +
> (UINTN)FirmwareVolumeHeader->HeaderLength);
> -CopyGuid (&VariableStoreHeader->Signature, &gEfiVariableGuid);
> +if (PcdGetBool (PcdIsSecureBoot)) {
> + CopyGuid (&VariableStoreHeader->Signature,
> &gEfiAuthenticatedVariableGuid);
> +} els
Re: [edk2] [PATCH edk2-platforms v2 07/15] Hisilicon/D0x: Fix secure boot bug in FlashFvbDxe
On Thu, 15 Nov 2018 at 22:57, Ming Huang wrote:
>
> When SECURE_BOOT_ENABLE is TRUE, FlashFvbDxe should use
> gEfiAuthenticatedVariableGuid, When SECURE_BOOT_ENABLE
> is FALSE, gEfiVariableGuid should be used.
>
Can we fix the driver instead so we don't need to make this distinction?
Please refer to commit 8753858f84768fa6fa17191b86c97538457723ce in the
EDK2 for some background.
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
> ---
> Silicon/Hisilicon/HisiPkg.dec | 1 +
> Platform/Hisilicon/D03/D03.dsc| 5 +
> Platform/Hisilicon/D05/D05.dsc| 5 +
> Platform/Hisilicon/D06/D06.dsc| 5 +
> Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.inf | 2 ++
> Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.c | 14 --
> 6 files changed, 30 insertions(+), 2 deletions(-)
>
> diff --git a/Silicon/Hisilicon/HisiPkg.dec b/Silicon/Hisilicon/HisiPkg.dec
> index 404a3ae4af9d..af9359e4d0e0 100644
> --- a/Silicon/Hisilicon/HisiPkg.dec
> +++ b/Silicon/Hisilicon/HisiPkg.dec
> @@ -278,6 +278,7 @@ [PcdsFixedAtBuild]
>
>gHisiTokenSpaceGuid.Pcdsoctype|0|UINT32|0x0061
>gHisiTokenSpaceGuid.PcdSerDesFlowCtrlFlag|0|UINT32|0x4056
> + gHisiTokenSpaceGuid.PcdIsSecureBoot|FALSE|BOOLEAN|0x4058
>
> [PcdsFeatureFlag]
>gHisiTokenSpaceGuid.PcdIsItsSupported|FALSE|BOOLEAN|0x0065
> diff --git a/Platform/Hisilicon/D03/D03.dsc b/Platform/Hisilicon/D03/D03.dsc
> index aa1da5d61f83..ba3096672db0 100644
> --- a/Platform/Hisilicon/D03/D03.dsc
> +++ b/Platform/Hisilicon/D03/D03.dsc
> @@ -281,6 +281,11 @@ [PcdsFixedAtBuild.common]
>gHisiTokenSpaceGuid.PcdHb0Rb2IoSize|0x #64K
>
>gHisiTokenSpaceGuid.Pcdsoctype|0x1610
> + !if $(SECURE_BOOT_ENABLE) == TRUE
> +gHisiTokenSpaceGuid.PcdIsSecureBoot|TRUE
> + !else
> +gHisiTokenSpaceGuid.PcdIsSecureBoot|FALSE
> + !endif
>
>
>
> #
> diff --git a/Platform/Hisilicon/D05/D05.dsc b/Platform/Hisilicon/D05/D05.dsc
> index 1040466633ef..b8500cef8742 100644
> --- a/Platform/Hisilicon/D05/D05.dsc
> +++ b/Platform/Hisilicon/D05/D05.dsc
> @@ -422,6 +422,11 @@ [PcdsFixedAtBuild.common]
>gHisiTokenSpaceGuid.PcdHb1Rb7IoSize|0x1 #64K
>
>gHisiTokenSpaceGuid.Pcdsoctype|0x1610
> + !if $(SECURE_BOOT_ENABLE) == TRUE
> +gHisiTokenSpaceGuid.PcdIsSecureBoot|TRUE
> + !else
> +gHisiTokenSpaceGuid.PcdIsSecureBoot|FALSE
> + !endif
>
>
>
> #
> diff --git a/Platform/Hisilicon/D06/D06.dsc b/Platform/Hisilicon/D06/D06.dsc
> index 1a479c160e80..b6ef9fedf0a7 100644
> --- a/Platform/Hisilicon/D06/D06.dsc
> +++ b/Platform/Hisilicon/D06/D06.dsc
> @@ -243,6 +243,11 @@ [PcdsFixedAtBuild.common]
>
>gEfiMdeModulePkgTokenSpaceGuid.PcdSrIovSupport|FALSE
>gArmTokenSpaceGuid.PcdPciIoTranslation|0x0
> + !if $(SECURE_BOOT_ENABLE) == TRUE
> +gHisiTokenSpaceGuid.PcdIsSecureBoot|TRUE
> + !else
> +gHisiTokenSpaceGuid.PcdIsSecureBoot|FALSE
> + !endif
>
>
>
> #
> diff --git a/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.inf
> b/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.inf
> index f8be4741ef7c..47965a707032 100644
> --- a/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.inf
> +++ b/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.inf
> @@ -44,6 +44,7 @@ [LibraryClasses]
>UefiRuntimeLib
>
> [Guids]
> + gEfiAuthenticatedVariableGuid
>gEfiSystemNvDataFvGuid
>gEfiVariableGuid
>
> @@ -62,6 +63,7 @@ [Pcd.common]
>gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
>
>gArmPlatformTokenSpaceGuid.PcdNorFlashCheckBlockLocked
> + gHisiTokenSpaceGuid.PcdIsSecureBoot
>gHisiTokenSpaceGuid.PcdSFCMEM0BaseAddress
>
> [Depex]
> diff --git a/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.c
> b/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.c
> index e18cc9e06ec2..309941d6fe4d 100644
> --- a/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.c
> +++ b/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.c
> @@ -189,7 +189,11 @@ InitializeFvAndVariableStoreHeaders (
> // VARIABLE_STORE_HEADER
> //
> VariableStoreHeader = (VARIABLE_STORE_HEADER*)((UINTN)Headers +
> (UINTN)FirmwareVolumeHeader->HeaderLength);
> -CopyGuid (&VariableStoreHeader->Signature, &gEfiVariableGuid);
> +if (PcdGetBool (PcdIsSecureBoot)) {
> + CopyGuid (&VariableStoreHeader->Signature,
> &gEfiAuthenticatedVariableGuid);
> +} else {
> + CopyGuid (&VariableStoreHeader->Signature, &gEfiVariableGuid);
> +}
> VariableStoreHeader->Size = PcdGet32(PcdFlashNvStorageVariableSize) -
> FirmwareVolumeHeader->HeaderLength;
> VariableStoreHeader->Format= VARIABLE_STORE_FORMATTED;
> VariableStoreH
Re: [edk2] [PATCH edk2-platforms v2 10/15] Hisilicon/D06: Modify Gic base
You said in reply to my comment on v1:
---
The PcdGicInterruptInterfaceBase(0xFE00) is wrong, it just copy
from D05/D03,
maybe somewhere will need the right value of Pcd.
---
Please split that out as a separate change, with the above mentioned
in the commit message.
But if I understand correctly, the remainder of the patch will be
incorrect until the other changes to book from TA have been applied
(in the subsequent patch).
So please move the MADT change to the other patch.
/
Leif
On Fri, Nov 16, 2018 at 02:56:57PM +0800, Ming Huang wrote:
> The values of PcdGicInterruptInterfaceBase and GICD are wrong, so modify it.
> Fix SBSA test case 21:
> 21 : Check GIC version
> GIC version is 0
> Failed on PE -0 for Level= 3 : Result: --FAIL-- 2
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
> ---
> Platform/Hisilicon/D06/D06.dsc| 2 +-
> Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/MadtHi1620.aslc | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Platform/Hisilicon/D06/D06.dsc b/Platform/Hisilicon/D06/D06.dsc
> index b6ef9fedf0a7..ac35564f4ac6 100644
> --- a/Platform/Hisilicon/D06/D06.dsc
> +++ b/Platform/Hisilicon/D06/D06.dsc
> @@ -183,7 +183,7 @@ [PcdsFixedAtBuild.common]
>gHisiTokenSpaceGuid.PcdArmPrimaryCoreTemp|0x8001
>gArmTokenSpaceGuid.PcdGicDistributorBase|0xAE00
>gArmTokenSpaceGuid.PcdGicRedistributorsBase|0xAE10
> - gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase|0xFE00
> + gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase|0x9B00
>
>
>
> diff --git a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/MadtHi1620.aslc
> b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/MadtHi1620.aslc
> index 43b43142aff4..d3de69a3ef6c 100644
> --- a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/MadtHi1620.aslc
> +++ b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/MadtHi1620.aslc
> @@ -361,7 +361,7 @@ EFI_ACPI_MULTIPLE_APIC_DESCRIPTION_TABLE Madt = {
> 0x0, 0x0, 25, 0x4000AA00 + 0x6C /* GicRBase */, 0),
>},
>
> - EFI_ACPI_6_1_GIC_DISTRIBUTOR_INIT(0, 0xAA00, 0, 0x4),
> + EFI_ACPI_6_1_GIC_DISTRIBUTOR_INIT(0, 0xAE00, 0, 0x4),
>{
> EFI_ACPI_6_1_GIC_ITS_INIT(0,0x20210), //peri a
> //EFI_ACPI_6_1_GIC_ITS_INIT(1,0x40020210), //peri a
> --
> 2.9.5
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 edk2-platforms] Silicon/SynQuacerPciCpuIo2Dxe: fix PCIe I/O translation
On Fri, 9 Nov 2018 at 05:34, Leif Lindholm wrote:
>
>
> On Fri, Nov 09, 2018 at 08:58:48AM +0100, Ard Biesheuvel wrote:
> > Commit 9dd8190e4995 ("Silicon/SynQuacer: tweak PCI I/O windows for
> > ACPI/Linux support") updated the min/max/offset definitions for the
> > PCIe I/O resource windows on SynQuacer, and updated the read path of
> > the platform's EfiCpuIo2 protocol implementation, but failed to update
> > the write path as well, resulting in spurious errors if when attempting
> > to write to PCIe I/O ports on PCIe RC #1, which uses translation for the
> > I/O BAR window.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel
>
> Much neater, thank you.
> Reviewed-by: Leif Lindholm
>
Thanks.
Pushed as 91b0299223a619cfec05a638f2c4197266d3cf1e
> > ---
> > v2: use helper function and temp vars
> >
> >
> > Silicon/Socionext/SynQuacer/Drivers/SynQuacerPciCpuIo2Dxe/SynQuacerPciCpuIo2Dxe.c
> > | 62
> > 1 file changed, 37 insertions(+), 26 deletions(-)
> >
> > diff --git
> > a/Silicon/Socionext/SynQuacer/Drivers/SynQuacerPciCpuIo2Dxe/SynQuacerPciCpuIo2Dxe.c
> >
> > b/Silicon/Socionext/SynQuacer/Drivers/SynQuacerPciCpuIo2Dxe/SynQuacerPciCpuIo2Dxe.c
> > index 736b20cd5129..049657231cab 100644
> > ---
> > a/Silicon/Socionext/SynQuacer/Drivers/SynQuacerPciCpuIo2Dxe/SynQuacerPciCpuIo2Dxe.c
> > +++
> > b/Silicon/Socionext/SynQuacer/Drivers/SynQuacerPciCpuIo2Dxe/SynQuacerPciCpuIo2Dxe.c
> > @@ -354,6 +354,37 @@ CpuMemoryServiceWrite (
> >return EFI_SUCCESS;
> > }
> >
> > +STATIC
> > +EFI_STATUS
> > +TranslateIoAddress (
> > + IN OUT UINT64 *Address
> > + )
> > +{
> > + UINT64 Start;
> > + UINT64 End;
> > + UINT64 Shift;
> > +
> > + Start = SYNQUACER_PCI_SEG0_PORTIO_MIN + SYNQUACER_PCI_SEG0_PORTIO_OFFSET;
> > + End = SYNQUACER_PCI_SEG0_PORTIO_MAX + SYNQUACER_PCI_SEG0_PORTIO_OFFSET;
> > + Shift = SYNQUACER_PCI_SEG0_PORTIO_MEMBASE -
> > SYNQUACER_PCI_SEG0_PORTIO_OFFSET;
> > +
> > + if (*Address >= Start && *Address <= End) {
> > +*Address += Shift;
> > +return EFI_SUCCESS;
> > + }
> > +
> > + Start = SYNQUACER_PCI_SEG1_PORTIO_MIN + SYNQUACER_PCI_SEG1_PORTIO_OFFSET;
> > + End = SYNQUACER_PCI_SEG1_PORTIO_MAX + SYNQUACER_PCI_SEG1_PORTIO_OFFSET;
> > + Shift = SYNQUACER_PCI_SEG1_PORTIO_MEMBASE -
> > SYNQUACER_PCI_SEG1_PORTIO_OFFSET;
> > +
> > + if (*Address >= Start && *Address <= End) {
> > +*Address += Shift;
> > +return EFI_SUCCESS;
> > + }
> > + ASSERT (FALSE);
> > + return EFI_INVALID_PARAMETER;
> > +}
> > +
> > /**
> >Reads I/O registers.
> >
> > @@ -415,22 +445,9 @@ CpuIoServiceRead (
> > return Status;
> >}
> >
> > - if ((Address >= (SYNQUACER_PCI_SEG0_PORTIO_MIN +
> > - SYNQUACER_PCI_SEG0_PORTIO_OFFSET)) &&
> > - (Address <= (SYNQUACER_PCI_SEG0_PORTIO_MAX +
> > - SYNQUACER_PCI_SEG0_PORTIO_OFFSET))) {
> > -Address += SYNQUACER_PCI_SEG0_PORTIO_MEMBASE -
> > - SYNQUACER_PCI_SEG0_PORTIO_OFFSET;
> > - } else if ((Address >= (SYNQUACER_PCI_SEG1_PORTIO_MIN +
> > - SYNQUACER_PCI_SEG1_PORTIO_OFFSET)) &&
> > - (Address <= (SYNQUACER_PCI_SEG1_PORTIO_MAX +
> > - SYNQUACER_PCI_SEG1_PORTIO_OFFSET))) {
> > -Address += SYNQUACER_PCI_SEG1_PORTIO_MEMBASE -
> > - SYNQUACER_PCI_SEG1_PORTIO_OFFSET;
> > -
> > - } else {
> > -ASSERT (FALSE);
> > -return EFI_INVALID_PARAMETER;
> > + Status = TranslateIoAddress (&Address);
> > + if (EFI_ERROR (Status)) {
> > +return Status;
> >}
> >
> >//
> > @@ -518,16 +535,9 @@ CpuIoServiceWrite (
> > return Status;
> >}
> >
> > - if ((Address >= SYNQUACER_PCI_SEG0_PORTIO_MIN) &&
> > - (Address <= SYNQUACER_PCI_SEG0_PORTIO_MAX)) {
> > -Address += SYNQUACER_PCI_SEG0_PORTIO_MEMBASE;
> > - } else if ((Address >= SYNQUACER_PCI_SEG1_PORTIO_MIN) &&
> > - (Address <= SYNQUACER_PCI_SEG1_PORTIO_MAX)) {
> > -Address += SYNQUACER_PCI_SEG1_PORTIO_MEMBASE;
> > -
> > - } else {
> > -ASSERT (FALSE);
> > -return EFI_INVALID_PARAMETER;
> > + Status = TranslateIoAddress (&Address);
> > + if (EFI_ERROR (Status)) {
> > +return Status;
> >}
> >
> >//
> > --
> > 2.19.1
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] Silicon/SynQuacer: remove bogus PL011 _HID from DSDT ACPI table
On Mon, 19 Nov 2018 at 09:48, Leif Lindholm wrote:
>
> On Mon, Nov 19, 2018 at 08:03:38AM -0800, Ard Biesheuvel wrote:
> > PL011 is not a valid ACPI identifier so don't expose it as a _CID.
> > Since _CID (Comptable ID) is optional, let's just drop it.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel
>
> Reviewed-by: Leif Lindholm
>
Thanks. Pushed as 46d3a977b931156a7155a879cdd2b0c95bb1aae0
> > ---
> > Silicon/Socionext/SynQuacer/AcpiTables/Dsdt.asl | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/Silicon/Socionext/SynQuacer/AcpiTables/Dsdt.asl
> > b/Silicon/Socionext/SynQuacer/AcpiTables/Dsdt.asl
> > index 3f73c191d4d6..7c7677f1fea0 100644
> > --- a/Silicon/Socionext/SynQuacer/AcpiTables/Dsdt.asl
> > +++ b/Silicon/Socionext/SynQuacer/AcpiTables/Dsdt.asl
> > @@ -135,7 +135,6 @@ DefinitionBlock ("DsdtTable.aml", "DSDT", 1, "SNI",
> > "SYNQUACR",
> > // UART PL011
> > Device (COM0) {
> >Name (_HID, "ARMH0011")
> > - Name (_CID, "PL011")
> >Name (_UID, Zero)
> >Name (_CRS, ResourceTemplate () {
> > Memory32Fixed (ReadWrite, FixedPcdGet32 (PcdSerialRegisterBase),
> > 0x1000)
> > --
> > 2.17.1
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v2 06/15] Hisilicon/D06: Move some functions to OemMiscLib
On Fri, Nov 16, 2018 at 02:56:53PM +0800, Ming Huang wrote:
> As M41T83RealTimeClockLib is common library, so move two cpld
> relative functions to OemMiscLib and rename this two functions.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
I did not see any of my review comments addressed, or any response
saying it was not being changed.
My feedback was:
---
This would be more clear as "platform specific" than "cpld relative".
I did not realise this wasn't a Hisilicon component when reviewing the
original set.
I approve of this change, but can you tell me why it is included in
this set? If the goal is to make the M41T83 support platform
independent, should the library also move to Silicon/ST/?
---
So could you please update the commit message, and add a subsequent
patch moving Library/M41T83RealTimeClockLib to
Silicon/STMicroelectronics (and updating D06.dsc to match)?
I do not care if it is not perfectly abstracted yet - we can deal with
that when we have other users of the component in the tree.
/
Leif
> ---
> Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClockLib.inf
> | 1 -
> Silicon/Hisilicon/Include/Library/OemMiscLib.h
> | 9 ++
> Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClock.h
> | 4 -
> Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
> | 82 ++
> Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClockLib.c
> | 90 ++--
> 5 files changed, 98 insertions(+), 88 deletions(-)
>
> diff --git
> a/Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClockLib.inf
> b/Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClockLib.inf
> index e0bf6b3f24db..4e963fd4531a 100644
> ---
> a/Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClockLib.inf
> +++
> b/Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClockLib.inf
> @@ -27,7 +27,6 @@ [Sources.common]
> [Packages]
>EmbeddedPkg/EmbeddedPkg.dec
>MdePkg/MdePkg.dec
> - Platform/Hisilicon/D06/D06.dec
>Silicon/Hisilicon/HisiPkg.dec
>
> [LibraryClasses]
> diff --git a/Silicon/Hisilicon/Include/Library/OemMiscLib.h
> b/Silicon/Hisilicon/Include/Library/OemMiscLib.h
> index 86ea6a1b3deb..0d7bf71b17d2 100644
> --- a/Silicon/Hisilicon/Include/Library/OemMiscLib.h
> +++ b/Silicon/Hisilicon/Include/Library/OemMiscLib.h
> @@ -53,4 +53,13 @@ BOOLEAN OemIsNeedDisableExpanderBuffer(VOID);
>
> extern EFI_STRING_ID gDimmToDevLocator[MAX_SOCKET][MAX_CHANNEL][MAX_DIMM];
> EFI_HII_HANDLE EFIAPI OemGetPackages ();
> +
> +VOID
> +OemReleaseOwnershipOfRtc (
> + VOID
> + );
> +EFI_STATUS
> +OemSwitchRtcI2cChannelAndLock (
> + VOID
> + );
> #endif
> diff --git
> a/Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClock.h
> b/Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClock.h
> index d985055d9bb6..f32910885856 100644
> --- a/Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClock.h
> +++ b/Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClock.h
> @@ -17,11 +17,7 @@
> #define __M41T83_REAL_TIME_CLOCK_H__
>
> // The delay is need for cpld and I2C. This is a empirical value.
> MemoryFence is no need.
> -#define RTC_DELAY_30_MS3
> -// The delay is need for cpld and I2C. This is a empirical value.
> MemoryFence is no need.
> #define RTC_DELAY_1000_MACROSECOND 1000
> -// The delay is need for cpld and I2C. This is a empirical value.
> MemoryFence is no need.
> -#define RTC_DELAY_2_MACROSECOND2
>
> #define M41T83_REGADDR_DOTSECONDS 0x00
> #define M41T83_REGADDR_SECONDS 0x01
> diff --git a/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
> b/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
> index 2a9db46d1ff9..64d167d18ae6 100644
> --- a/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
> +++ b/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -27,6 +28,12 @@
> #include
> #include
> #include
> +#include
> +
> +// The delay is need for cpld and I2C. This is a empirical value.
> MemoryFence is no need.
> +#define RTC_DELAY_30_MS3
> +// The delay is need for cpld and I2C. This is a empirical value.
> MemoryFence is no need.
> +#define RTC_DELAY_2_MACROSECOND2
>
> REPORT_PCIEDIDVID2BMC PcieDeviceToReport[PCIEDEVICE_REPORT_MAX] = {
>{67,0,0,0},
> @@ -207,3 +214,78 @@ OemIsNeedDisableExpanderBuffer (
> {
>return TRUE;
> }
> +
> +EFI_STATUS
> +OemSwitchRtcI2cChannelAndLock (
> + VOID
> + )
> +{
> + UINT8 Temp;
> + UINT8 Count;
> +
> + for (Count = 0; Count < 100; Count++) {
> +// To get the other side's state is idle first
> +Temp = ReadCpldReg (CPLD_I2C_SWITCH_FLAG);
> +if ((Temp & B
Re: [edk2] [PATCH edk2-platforms v2 00/15] Fix D06 SBSA/SBBR issue and improve
On Fri, Nov 16, 2018 at 02:56:47PM +0800, Ming Huang wrote: > Main Change since v1: > 1. Add IORT patch; > 2. Add HIDs/UIDs bug for PciHostBridgeLib; > 3. Drop Pv660; > 4. Drop two patchs: >Modify for SBBR fwts SetTime_Func test case; >Fix SBBR-SCT AuthVar issue > > Code can also be found in github: > https://github.com/hisilicon/OpenPlatformPkg.git > branch: d06-acs-platforms-v2 > > > Ming Huang (15): > Hisilicon/D0x: Modify IORT > Silicon/Hisilicon/D06: Add watchdog to GTDT > Silicon/Hisilicon/D06: Drop _CID for fwts issue > Silicon/Hisilicon/D06: Fix fwts issue in Dbg2 > Silicon/Hisilicon/D06: Fix fwts issue in FADT > Hisilicon/D06: Move some functions to OemMiscLib > Hisilicon/D0x: Fix secure boot bug in FlashFvbDxe > Silicon/Hisilicon/D06: Reserve ECAM resource in DSDT > Silicon/Hisilicon/D06: Modify GTDT timer flag > Hisilicon/D06: Modify Gic base > Silicon/Hisilicon/D06: Set TA as Node 0 for TA boot > Silicon/Hisilicon/D03: Drop _CID for fwts issue > Silicon/Hisilicon/D05: Drop _CID for fwts issue > Hisilicon: Drop Pv660 source code > Hisilicon/D06: Correct HIDs/UIDs of PCI host bridges The following patches (in this order): Hisilicon: Drop Pv660 source code Hisilicon/D0x: Modify IORT Silicon/Hisilicon/D03: Drop _CID for fwts issue Silicon/Hisilicon/D05: Drop _CID for fwts issue Silicon/Hisilicon/D06: Drop _CID for fwts issue Silicon/Hisilicon/D06: Add watchdog to GTDT Silicon/Hisilicon/D06: Fix fwts issue in Dbg2 Silicon/Hisilicon/D06: Fix fwts issue in FADT Silicon/Hisilicon/D06: Reserve ECAM resource in DSDT Silicon/Hisilicon/D06: Modify GTDT timer flag Hisilicon/D06: Correct HIDs/UIDs of PCI host bridges Reviewed-by: Leif Lindholm Pushed as 46d3a977b9..ce4f7528ed. Please rebase on new master and address comments for v3. If you can merge Silicon/Hisilicon/D06: Set TA as Node 0 for TA boot and Hisilicon/D06: Modify Gic base as requested and get those sent out before I start work tomorrow, we are in pretty good shape for me to roll out an -rc1 tomorrow. (Which would be good, because I hope to have Wednesday-Friday as holiday :) If you can also address "Fix secure boot bug in FlashFvbDxe", that should be all remaining functional changes. FYI: I am now working against edk2 tag edk2-stable201811. / Leif > Silicon/Hisilicon/HisiPkg.dec > |1 + > Platform/Hisilicon/D03/D03.dsc > |5 + > Platform/Hisilicon/D05/D05.dsc > |5 + > Platform/Hisilicon/D06/D06.dsc > |7 +- > Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.inf > |2 + > Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLib.inf > |2 +- > Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLibSec.inf > |2 +- > Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClockLib.inf > |1 - > Silicon/Hisilicon/Pv660/Drivers/IoInitDxe/IoInitDxe.inf > | 58 -- > Silicon/Hisilicon/Pv660/Drivers/PcieInitDxe/PcieInitDxe.inf > | 56 -- > Silicon/Hisilicon/Pv660/Drivers/SasInitDxe/SasV1Init.inf > | 48 - > Silicon/Hisilicon/Pv660/Drivers/UnInstallAcpiTableDxe/UnInstallAcpiTable.inf > | 57 -- > Silicon/Hisilicon/Pv660/Pv660AcpiTables/AcpiTables.inf > | 60 -- > Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Hi1620Platform.h > |2 +- > Silicon/Hisilicon/Include/Library/OemMiscLib.h > |9 + > Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClock.h > |4 - > Silicon/Hisilicon/Pv660/Drivers/IoInitDxe/Smmu.h > | 36 - > Silicon/Hisilicon/Pv660/Drivers/PcieInitDxe/PcieInit.h > | 93 -- > Silicon/Hisilicon/Pv660/Drivers/PcieInitDxe/PcieInitLib.h > | 239 - > Silicon/Hisilicon/Pv660/Drivers/PcieInitDxe/PcieKernelApi.h > | 346 --- > Silicon/Hisilicon/Pv660/Drivers/UnInstallAcpiTableDxe/UnInstallAcpiTable.h > | 30 - > Silicon/Hisilicon/Pv660/Include/Library/SerdesLib.h > | 120 --- > Silicon/Hisilicon/Pv660/Pv660AcpiTables/Pv660Platform.h > | 48 - > Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c > | 82 ++ > Platform/Hisilicon/D06/Library/PciHostBridgeLib/PciHostBridgeLib.c > | 28 +- > Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.c > | 14 +- > Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClockLib.c > | 90 +- > Silicon/Hisilicon/Pv660/Drivers/IoInitDxe/IoInitDxe.c > | 94 -- > Silicon/Hisilicon/Pv660/Drivers/IoInitDxe/Smmu.c
Re: [edk2] [PATCH edk2-non-osi v2 0/4] Upload D06 binary modules for SBSA test
On Fri, Nov 16, 2018 at 04:13:02PM +0800, Ming Huang wrote: > Main Change since v1: > 1 Modify comments; > > Code can also be found in github: > https://github.com/hisilicon/OpenPlatformPkg.git > branch: d06-acs-non-osi-v2 >From the black-box standpoint, this series look fine. Are there any implications of the TB->TA boot that means I need to synchronise pushing these with pushing that change for edk2-platforms? If not, for the series: Reviewed-by: Leif Lindholm and I'll push when I have confirmation. > Ming Huang (4): > Hisilicon/D06: Add cpu on/off feature in TrustedFirmware > Hisilicon/D06: Fix SBSA test case 42 failed issues > Hisilicon/D06: Fix set usb reg failed issue > Hisilicon/D06: Fix SBSA PE-15 failed issue > > Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi | Bin 229216 -> > 232832 bytes > Platform/Hisilicon/D06/bl1.bin | Bin 12432 -> 12432 > bytes > Platform/Hisilicon/D06/fip.bin | Bin 113578 -> > 113450 bytes > 3 files changed, 0 insertions(+), 0 deletions(-) > > -- > 2.9.5 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 0/2] Clear frame pointer in startup code on AARCH64 systems
On 11/16/18 23:55, Ard Biesheuvel wrote: > The backtrace code on AARCH64 does not sanitize the frame pointer values > it pulls of the stack when attempting to do a backtrace, and so junk left > in the frame pointer register may result in a recursive exception and a > truncated backtrace. > > Ard Biesheuvel (2): > ArmPlatformPkg: clear frame pointer in startup code > ArmVirtPkg/PrePi: clear frame pointer in startup code > > ArmPlatformPkg/PrePeiCore/AArch64/PrePeiCoreEntryPoint.S | 3 +++ > ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S | 3 +++ > ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S | 3 +++ > 3 files changed, 9 insertions(+) > Acked-by: Laszlo Ersek ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 0/2] Clear frame pointer in startup code on AARCH64 systems
On Fri, Nov 16, 2018 at 02:55:56PM -0800, Ard Biesheuvel wrote: > The backtrace code on AARCH64 does not sanitize the frame pointer values > it pulls of the stack when attempting to do a backtrace, and so junk left > in the frame pointer register may result in a recursive exception and a > truncated backtrace. If I was bikeshedding, I'd ask for a (NULL) in the comments next to the 0x0. But other than that, for the series: Reviewed-by: Leif Lindholm (be it green or black) > Ard Biesheuvel (2): > ArmPlatformPkg: clear frame pointer in startup code > ArmVirtPkg/PrePi: clear frame pointer in startup code > > ArmPlatformPkg/PrePeiCore/AArch64/PrePeiCoreEntryPoint.S | 3 +++ > ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S | 3 +++ > ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S | 3 +++ > 3 files changed, 9 insertions(+) > > -- > 2.17.1 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 1/2] ArmPlatformPkg/NorFlashDxe: use one GUID plus index to identify flash banks
On Fri, Nov 16, 2018 at 04:45:23PM -0800, Ard Biesheuvel wrote:
> Currently, each flash bank controlled by ArmPlatformPkg/NorFlashDxe
> has its own VendorHw GUID, and instances of NorFlashPlatformLib
> describe each bank to the driver, along with the GUID for each.
>
> This works ok for bare metal platforms, but it would be useful for
> virtual platforms if we could obtain this information from a
> device tree, which would require us to invent GUIDs on the fly,
> given that the 'cfi-flash' binding does not include a GUID.
>
> So instead, let's switch to a single GUID for all flash banks,
> and update the driver's device path handling to include an index
> to identify each bank uniquely.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> ---
> ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c | 15 +--
> ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h | 3 +++
> 2 files changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
> b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
> index 46e815beb343..60a06e4a5058 100644
> --- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
> +++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
> @@ -82,10 +82,14 @@ NOR_FLASH_INSTANCE mNorFlashInstanceTemplate = {
>{
> HARDWARE_DEVICE_PATH,
> HW_VENDOR_DP,
> -{ (UINT8)sizeof(VENDOR_DEVICE_PATH),
> (UINT8)((sizeof(VENDOR_DEVICE_PATH)) >> 8) }
> +{
> + (UINT8)(OFFSET_OF(NOR_FLASH_DEVICE_PATH, End)),
> + (UINT8)(OFFSET_OF(NOR_FLASH_DEVICE_PATH, End) >> 8)
> +}
>},
>{ 0x0, 0x0, 0x0, { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 } }, // GUID
> ... NEED TO BE FILLED
> },
> +0, // Index
> {
>END_DEVICE_PATH_TYPE,
>END_ENTIRE_DEVICE_PATH_SUBTYPE,
> @@ -99,10 +103,9 @@ NorFlashCreateInstance (
>IN UINTN NorFlashDeviceBase,
>IN UINTN NorFlashRegionBase,
>IN UINTN NorFlashSize,
> - IN UINT32 MediaId,
> + IN UINT32 Index,
>IN UINT32 BlockSize,
>IN BOOLEANSupportFvb,
> - IN CONST GUID *NorFlashGuid,
>OUT NOR_FLASH_INSTANCE** NorFlashInstance
>)
> {
> @@ -121,11 +124,12 @@ NorFlashCreateInstance (
>Instance->Size = NorFlashSize;
>
>Instance->BlockIoProtocol.Media = &Instance->Media;
> - Instance->Media.MediaId = MediaId;
> + Instance->Media.MediaId = Index;
>Instance->Media.BlockSize = BlockSize;
>Instance->Media.LastBlock = (NorFlashSize / BlockSize)-1;
>
> - CopyGuid (&Instance->DevicePath.Vendor.Guid, NorFlashGuid);
> + CopyGuid (&Instance->DevicePath.Vendor.Guid, &gEfiCallerIdGuid);
Just sanity checking: this sets the VendorGuid to the NorFlashDxe
GUID? (93E34C7E-B50E-11DF-9223-2443DFD72085)
If not, can you explain it to me slowly? :)
Thomas, Nariman: would this change cause any transient issues for
anything that has set Boot options in any of your configurations?
And if it would, is that a big deal?
(Ard has a separate patch that fixes up any default values.)
/
Leif
> + Instance->DevicePath.Index = Index;
>
>Instance->ShadowBuffer = AllocateRuntimePool (BlockSize);;
>if (Instance->ShadowBuffer == NULL) {
> @@ -1311,7 +1315,6 @@ NorFlashInitialise (
>Index,
>NorFlashDevices[Index].BlockSize,
>ContainVariableStorage,
> - &NorFlashDevices[Index].Guid,
>&mNorFlashInstances[Index]
> );
> if (EFI_ERROR(Status)) {
> diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
> b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
> index 5c07694fbfaa..8886aa43d9f3 100644
> --- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
> +++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
> @@ -122,10 +122,13 @@
>
> typedef struct _NOR_FLASH_INSTANCENOR_FLASH_INSTANCE;
>
> +#pragma pack(1)
> typedef struct {
>VENDOR_DEVICE_PATH Vendor;
> + UINT8 Index;
>EFI_DEVICE_PATH_PROTOCOLEnd;
> } NOR_FLASH_DEVICE_PATH;
> +#pragma pack()
>
> struct _NOR_FLASH_INSTANCE {
>UINT32 Signature;
> --
> 2.17.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 1/2] ArmPlatformPkg/NorFlashDxe: use one GUID plus index to identify flash banks
On Mon, 19 Nov 2018 at 11:05, Leif Lindholm wrote:
>
> On Fri, Nov 16, 2018 at 04:45:23PM -0800, Ard Biesheuvel wrote:
> > Currently, each flash bank controlled by ArmPlatformPkg/NorFlashDxe
> > has its own VendorHw GUID, and instances of NorFlashPlatformLib
> > describe each bank to the driver, along with the GUID for each.
> >
> > This works ok for bare metal platforms, but it would be useful for
> > virtual platforms if we could obtain this information from a
> > device tree, which would require us to invent GUIDs on the fly,
> > given that the 'cfi-flash' binding does not include a GUID.
> >
> > So instead, let's switch to a single GUID for all flash banks,
> > and update the driver's device path handling to include an index
> > to identify each bank uniquely.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel
> > ---
> > ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c | 15 +--
> > ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h | 3 +++
> > 2 files changed, 12 insertions(+), 6 deletions(-)
> >
> > diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
> > b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
> > index 46e815beb343..60a06e4a5058 100644
> > --- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
> > +++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
> > @@ -82,10 +82,14 @@ NOR_FLASH_INSTANCE mNorFlashInstanceTemplate = {
> >{
> > HARDWARE_DEVICE_PATH,
> > HW_VENDOR_DP,
> > -{ (UINT8)sizeof(VENDOR_DEVICE_PATH),
> > (UINT8)((sizeof(VENDOR_DEVICE_PATH)) >> 8) }
> > +{
> > + (UINT8)(OFFSET_OF(NOR_FLASH_DEVICE_PATH, End)),
> > + (UINT8)(OFFSET_OF(NOR_FLASH_DEVICE_PATH, End) >> 8)
> > +}
> >},
> >{ 0x0, 0x0, 0x0, { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 } }, //
> > GUID ... NEED TO BE FILLED
> > },
> > +0, // Index
> > {
> >END_DEVICE_PATH_TYPE,
> >END_ENTIRE_DEVICE_PATH_SUBTYPE,
> > @@ -99,10 +103,9 @@ NorFlashCreateInstance (
> >IN UINTN NorFlashDeviceBase,
> >IN UINTN NorFlashRegionBase,
> >IN UINTN NorFlashSize,
> > - IN UINT32 MediaId,
> > + IN UINT32 Index,
> >IN UINT32 BlockSize,
> >IN BOOLEANSupportFvb,
> > - IN CONST GUID *NorFlashGuid,
> >OUT NOR_FLASH_INSTANCE** NorFlashInstance
> >)
> > {
> > @@ -121,11 +124,12 @@ NorFlashCreateInstance (
> >Instance->Size = NorFlashSize;
> >
> >Instance->BlockIoProtocol.Media = &Instance->Media;
> > - Instance->Media.MediaId = MediaId;
> > + Instance->Media.MediaId = Index;
> >Instance->Media.BlockSize = BlockSize;
> >Instance->Media.LastBlock = (NorFlashSize / BlockSize)-1;
> >
> > - CopyGuid (&Instance->DevicePath.Vendor.Guid, NorFlashGuid);
> > + CopyGuid (&Instance->DevicePath.Vendor.Guid, &gEfiCallerIdGuid);
>
> Just sanity checking: this sets the VendorGuid to the NorFlashDxe
> GUID? (93E34C7E-B50E-11DF-9223-2443DFD72085)
>
Yes.
Before:
Mapping table
BLK1: Alias(s):
VenHw(F9B94AE2-8BA6-409B-9D56-B9B417F53CB3)
BLK0: Alias(s):
VenHw(8047DB4B-7E9C-4C0C-8EBC-DFBBAACACE8F)
After:
Mapping table
BLK0: Alias(s):
VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00)
BLK1: Alias(s):
VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,01)
> If not, can you explain it to me slowly? :)
>
> Thomas, Nariman: would this change cause any transient issues for
> anything that has set Boot options in any of your configurations?
> And if it would, is that a big deal?
> (Ard has a separate patch that fixes up any default values.)
>
> /
> Leif
>
> > + Instance->DevicePath.Index = Index;
> >
> >Instance->ShadowBuffer = AllocateRuntimePool (BlockSize);;
> >if (Instance->ShadowBuffer == NULL) {
> > @@ -1311,7 +1315,6 @@ NorFlashInitialise (
> >Index,
> >NorFlashDevices[Index].BlockSize,
> >ContainVariableStorage,
> > - &NorFlashDevices[Index].Guid,
> >&mNorFlashInstances[Index]
> > );
> > if (EFI_ERROR(Status)) {
> > diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
> > b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
> > index 5c07694fbfaa..8886aa43d9f3 100644
> > --- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
> > +++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
> > @@ -122,10 +122,13 @@
> >
> > typedef struct _NOR_FLASH_INSTANCENOR_FLASH_INSTANCE;
> >
> > +#pragma pack(1)
> > typedef struct {
> >VENDOR_DEVICE_PATH Vendor;
> > + UINT8 Index;
> >EFI_DEVICE_PATH_PROTOCOLEnd;
> > } NOR_FLASH_DEVICE_PATH;
> > +#pragma pack()
> >
> > struct _NOR_FLASH_INSTANCE {
> >UINT32 Signature;
> > --
> > 2.17.1
> >
__
Re: [edk2] [PATCH 2/2] ArmVirtPkg/NorFlashQemuLib: discover NOR flash banks dynamically
On Fri, Nov 16, 2018 at 05:29:05PM -0800, Ard Biesheuvel wrote:
> On Fri, 16 Nov 2018 at 16:45, Ard Biesheuvel
> wrote:
> >
> > NorFlashQemuLib is one of the last remaining drivers in ArmVirtPkg
> > that are not based on the device tree received from QEMU.
> >
> > For ArmVirtQemu, this does not really matter, given that the NOR
> > flash banks are always the same: the PEI code is linked to execute
> > in place from flash bank #0, and the fixed varstore PCDs refer to
> > flash bank #1 directly.
> >
> > However, ArmVirtQemuKernel can execute at any offset, and flash bank
>
> #0 is configured as secure-only when running with support for EL3 enabled.
Never gets old :)
> > In this case, NorFlashQemuLib should not expose the first flash bank
> > at all.
> >
> > To prevent introducing too much internal knowledge about which flash
> > bank is accessible under which circumstances, let's switch to using
> > the DTB to decide which flash banks to expose to the NOR flash driver.
Does this mean we as a side effect get rid of the limitation that the
pflash image needs to be exactly 64MB. Or does that require further
changes on the QEMU side?
If it does, please add a comment to the commit message.
Either way:
Reviewed-by: Leif Lindholm
/
Leif
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel
> > ---
> > ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c | 84
> > +++-
> > ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf | 12 +++
> > 2 files changed, 75 insertions(+), 21 deletions(-)
> >
> > diff --git a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> > b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> > index e3bbae5b06c5..dc0a15e77170 100644
> > --- a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> > +++ b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> > @@ -1,6 +1,6 @@
> > /** @file
> >
> > - Copyright (c) 2014, Linaro Ltd. All rights reserved.
> > + Copyright (c) 2014-2018, Linaro Ltd. All rights reserved.
> >
> > This program and the accompanying materials
> > are licensed and made available under the terms and conditions of the BSD
> > License
> > @@ -12,13 +12,16 @@
> >
> > **/
> >
> > +#include
> > +#include
> > #include
> > +#include
> > +
> > +#include
> >
> > #define QEMU_NOR_BLOCK_SIZESIZE_256KB
> > -#define QEMU_NOR0_BASE 0x0
> > -#define QEMU_NOR0_SIZE SIZE_64MB
> > -#define QEMU_NOR1_BASE 0x0400
> > -#define QEMU_NOR1_SIZE SIZE_64MB
> > +
> > +#define MAX_FLASH_BANKS4
> >
> > EFI_STATUS
> > NorFlashPlatformInitialization (
> > @@ -28,21 +31,7 @@ NorFlashPlatformInitialization (
> >return EFI_SUCCESS;
> > }
> >
> > -NOR_FLASH_DESCRIPTION mNorFlashDevices[] = {
> > - {
> > -QEMU_NOR0_BASE,
> > -QEMU_NOR0_BASE,
> > -QEMU_NOR0_SIZE,
> > -QEMU_NOR_BLOCK_SIZE,
> > -{0xF9B94AE2, 0x8BA6, 0x409B, {0x9D, 0x56, 0xB9, 0xB4, 0x17, 0xF5,
> > 0x3C, 0xB3}}
> > - }, {
> > -QEMU_NOR1_BASE,
> > -QEMU_NOR1_BASE,
> > -QEMU_NOR1_SIZE,
> > -QEMU_NOR_BLOCK_SIZE,
> > -{0x8047DB4B, 0x7E9C, 0x4C0C, {0x8E, 0xBC, 0xDF, 0xBB, 0xAA, 0xCA,
> > 0xCE, 0x8F}}
> > - }
> > -};
> > +NOR_FLASH_DESCRIPTION mNorFlashDevices[MAX_FLASH_BANKS];
> >
> > EFI_STATUS
> > NorFlashPlatformGetDevices (
> > @@ -50,7 +39,60 @@ NorFlashPlatformGetDevices (
> >OUT UINT32 *Count
> >)
> > {
> > + FDT_CLIENT_PROTOCOL *FdtClient;
> > + INT32 Node;
> > + EFI_STATUS Status;
> > + EFI_STATUS FindNodeStatus;
> > + CONST UINT64*Reg;
> > + UINT32 RegSize;
> > + CONST CHAR8 *NodeStatus;
> > + UINTN Num;
> > +
> > + Status = gBS->LocateProtocol (&gFdtClientProtocolGuid, NULL,
> > + (VOID **)&FdtClient);
> > + ASSERT_EFI_ERROR (Status);
> > +
> > + Num = 0;
> > + for (FindNodeStatus = FdtClient->FindCompatibleNode (FdtClient,
> > + "cfi-flash", &Node);
> > + !EFI_ERROR (FindNodeStatus);
> > + FindNodeStatus = FdtClient->FindNextCompatibleNode (FdtClient,
> > + "cfi-flash", Node, &Node)) {
> > +
> > +Status = FdtClient->GetNodeProperty (FdtClient, Node, "status",
> > + (CONST VOID **)&NodeStatus, NULL);
> > +if (!EFI_ERROR (Status) && AsciiStrnCmp (NodeStatus, "ok", 2) != 0) {
> > + continue;
> > +}
> > +
> > +Status = FdtClient->GetNodeProperty (FdtClient, Node, "reg",
> > + (CONST VOID **)&Reg, &RegSize);
> > +if (EFI_ERROR (Status)) {
> > + DEBUG ((EFI_D_ERROR, "%a: GetNodeProperty () failed (Status ==
> > %r)\n",
> > +__FUNCTION__, Status));
> > + continue;
> > +}
> > +
> > +ASSERT ((RegSize % (2 * sizeof(UINT64))) == 0);
> > +
> > +while (RegSize > 0) {
> > +
Re: [edk2] [PATCH edk2-platforms] Platform/ARM: replace hardcoded VenHW() device paths referring to NOR flash
On Fri, Nov 16, 2018 at 05:23:08PM -0800, Ard Biesheuvel wrote: > The ArmPlatformPkg NOR flash driver has been updated to use device paths > consisting of a fixed GUID and a numeric index rather than a separate GUID > for each flash bank on a given system. This means all explicit device path > references to NOR flash banks have to be brought up to date as well. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel This looks good to me, but I'd like a comment from Thomas/Nariman. With that: Reviewed-by: Leif Lindholm > --- > Platform/ARM/JunoPkg/ArmJuno.dec | 2 +- > Platform/ARM/JunoPkg/ArmJuno.dsc | 2 +- > Platform/ARM/SgiPkg/SgiPlatform.dsc | 2 +- > Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc | 2 +- > Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc | 2 +- > 5 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/Platform/ARM/JunoPkg/ArmJuno.dec > b/Platform/ARM/JunoPkg/ArmJuno.dec > index edbbb827ad45..c511796d8913 100644 > --- a/Platform/ARM/JunoPkg/ArmJuno.dec > +++ b/Platform/ARM/JunoPkg/ArmJuno.dec > @@ -44,7 +44,7 @@ > > gArmJunoTokenSpaceGuid.PcdSynopsysUsbEhciBaseAddress|0x7FFC|UINT32|0x0005 > ># Juno Device Trees are loaded from NOR Flash > - > gArmJunoTokenSpaceGuid.PcdJunoFdtDevicePath|L"VenHw(E7223039-5836-41E1-B542-D7EC736C5E59)/board.dtb"|VOID*|0x0008 > + > gArmJunoTokenSpaceGuid.PcdJunoFdtDevicePath|L"VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00)/board.dtb"|VOID*|0x0008 > ># MHU Register base used by SCMI Mailbox transport >gArmJunoTokenSpaceGuid.PcdArmMtlDoorBell|0x2B1F|UINT64|0x0024 > diff --git a/Platform/ARM/JunoPkg/ArmJuno.dsc > b/Platform/ARM/JunoPkg/ArmJuno.dsc > index ac3d63bd4d39..55b9d64d3deb 100644 > --- a/Platform/ARM/JunoPkg/ArmJuno.dsc > +++ b/Platform/ARM/JunoPkg/ArmJuno.dsc > @@ -176,7 +176,7 @@ >gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|24 > ># List of Device Paths that support BootMonFs > - > gArmBootMonFsTokenSpaceGuid.PcdBootMonFsSupportedDevicePaths|L"VenHw(E7223039-5836-41E1-B542-D7EC736C5E59)" > + > gArmBootMonFsTokenSpaceGuid.PcdBootMonFsSupportedDevicePaths|L"VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00)" > ># ># ARM Architectural Timer Frequency > diff --git a/Platform/ARM/SgiPkg/SgiPlatform.dsc > b/Platform/ARM/SgiPkg/SgiPlatform.dsc > index 3f0ca9872e79..06d866d6dc30 100644 > --- a/Platform/ARM/SgiPkg/SgiPlatform.dsc > +++ b/Platform/ARM/SgiPkg/SgiPlatform.dsc > @@ -163,7 +163,7 @@ >gArmPlatformTokenSpaceGuid.PcdPL031RtcBase|0x1C17 > ># List of Device Paths that support BootMonFs > - > gArmBootMonFsTokenSpaceGuid.PcdBootMonFsSupportedDevicePaths|L"VenHw(E7223039-5836-41E1-B542-D7EC736C5E59)" > + > gArmBootMonFsTokenSpaceGuid.PcdBootMonFsSupportedDevicePaths|L"VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00)" > ># ARM OS Loader >gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|3 > diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc > b/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc > index 0542808f7d0c..3a3b4e3dbbc8 100644 > --- a/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc > +++ b/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc > @@ -172,7 +172,7 @@ ># ># Define the device path to the FDT for the platform ># > - > gFdtPlatformDxeTokenSpaceGuid.PcdFdtDevicePaths|L"VenHw(E7223039-5836-41E1-B542-D7EC736C5E59)/ca15a7" > + > gFdtPlatformDxeTokenSpaceGuid.PcdFdtDevicePaths|L"VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00)/ca15a7" > ># ># ARM Architectural Timer Frequency > diff --git a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc > b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc > index 752e525c3469..713c5637b074 100644 > --- a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc > +++ b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc > @@ -355,7 +355,7 @@ ># > ># List of Device Paths that support BootMonFs > - > gArmBootMonFsTokenSpaceGuid.PcdBootMonFsSupportedDevicePaths|L"VenHw(E7223039-5836-41E1-B542-D7EC736C5E59);VenHw(1F15DA3C-37FF-4070-B471-BB4AF12A724A)" > + > gArmBootMonFsTokenSpaceGuid.PcdBootMonFsSupportedDevicePaths|L"VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00);VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,02)" > ># RunAxf support via Dynamic Shell Command protocol ># We want to use the Shell Libraries but don't want it to initialise > -- > 2.17.1 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 2/2] ArmVirtPkg/NorFlashQemuLib: discover NOR flash banks dynamically
On Mon, 19 Nov 2018 at 11:10, Leif Lindholm wrote:
>
> On Fri, Nov 16, 2018 at 05:29:05PM -0800, Ard Biesheuvel wrote:
> > On Fri, 16 Nov 2018 at 16:45, Ard Biesheuvel
> > wrote:
> > >
> > > NorFlashQemuLib is one of the last remaining drivers in ArmVirtPkg
> > > that are not based on the device tree received from QEMU.
> > >
> > > For ArmVirtQemu, this does not really matter, given that the NOR
> > > flash banks are always the same: the PEI code is linked to execute
> > > in place from flash bank #0, and the fixed varstore PCDs refer to
> > > flash bank #1 directly.
> > >
> > > However, ArmVirtQemuKernel can execute at any offset, and flash bank
> >
> > #0 is configured as secure-only when running with support for EL3 enabled.
>
> Never gets old :)
>
No this is entirely reasonable: it makes perfect sense for a NOR flash
at address 0x0 to be secure only on a system that implements EL3,
since mach-virt's default reset vector is 0x0.
> > > In this case, NorFlashQemuLib should not expose the first flash bank
> > > at all.
> > >
> > > To prevent introducing too much internal knowledge about which flash
> > > bank is accessible under which circumstances, let's switch to using
> > > the DTB to decide which flash banks to expose to the NOR flash driver.
>
> Does this mean we as a side effect get rid of the limitation that the
> pflash image needs to be exactly 64MB. Or does that require further
> changes on the QEMU side?
>
No that is a QEMU thing.
> If it does, please add a comment to the commit message.
> Either way:
> Reviewed-by: Leif Lindholm
>
Thanks
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Ard Biesheuvel
> > > ---
> > > ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c | 84
> > > +++-
> > > ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf | 12 +++
> > > 2 files changed, 75 insertions(+), 21 deletions(-)
> > >
> > > diff --git a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> > > b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> > > index e3bbae5b06c5..dc0a15e77170 100644
> > > --- a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> > > +++ b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> > > @@ -1,6 +1,6 @@
> > > /** @file
> > >
> > > - Copyright (c) 2014, Linaro Ltd. All rights reserved.
> > > + Copyright (c) 2014-2018, Linaro Ltd. All rights reserved.
> > >
> > > This program and the accompanying materials
> > > are licensed and made available under the terms and conditions of the
> > > BSD License
> > > @@ -12,13 +12,16 @@
> > >
> > > **/
> > >
> > > +#include
> > > +#include
> > > #include
> > > +#include
> > > +
> > > +#include
> > >
> > > #define QEMU_NOR_BLOCK_SIZESIZE_256KB
> > > -#define QEMU_NOR0_BASE 0x0
> > > -#define QEMU_NOR0_SIZE SIZE_64MB
> > > -#define QEMU_NOR1_BASE 0x0400
> > > -#define QEMU_NOR1_SIZE SIZE_64MB
> > > +
> > > +#define MAX_FLASH_BANKS4
> > >
> > > EFI_STATUS
> > > NorFlashPlatformInitialization (
> > > @@ -28,21 +31,7 @@ NorFlashPlatformInitialization (
> > >return EFI_SUCCESS;
> > > }
> > >
> > > -NOR_FLASH_DESCRIPTION mNorFlashDevices[] = {
> > > - {
> > > -QEMU_NOR0_BASE,
> > > -QEMU_NOR0_BASE,
> > > -QEMU_NOR0_SIZE,
> > > -QEMU_NOR_BLOCK_SIZE,
> > > -{0xF9B94AE2, 0x8BA6, 0x409B, {0x9D, 0x56, 0xB9, 0xB4, 0x17, 0xF5,
> > > 0x3C, 0xB3}}
> > > - }, {
> > > -QEMU_NOR1_BASE,
> > > -QEMU_NOR1_BASE,
> > > -QEMU_NOR1_SIZE,
> > > -QEMU_NOR_BLOCK_SIZE,
> > > -{0x8047DB4B, 0x7E9C, 0x4C0C, {0x8E, 0xBC, 0xDF, 0xBB, 0xAA, 0xCA,
> > > 0xCE, 0x8F}}
> > > - }
> > > -};
> > > +NOR_FLASH_DESCRIPTION mNorFlashDevices[MAX_FLASH_BANKS];
> > >
> > > EFI_STATUS
> > > NorFlashPlatformGetDevices (
> > > @@ -50,7 +39,60 @@ NorFlashPlatformGetDevices (
> > >OUT UINT32 *Count
> > >)
> > > {
> > > + FDT_CLIENT_PROTOCOL *FdtClient;
> > > + INT32 Node;
> > > + EFI_STATUS Status;
> > > + EFI_STATUS FindNodeStatus;
> > > + CONST UINT64*Reg;
> > > + UINT32 RegSize;
> > > + CONST CHAR8 *NodeStatus;
> > > + UINTN Num;
> > > +
> > > + Status = gBS->LocateProtocol (&gFdtClientProtocolGuid, NULL,
> > > + (VOID **)&FdtClient);
> > > + ASSERT_EFI_ERROR (Status);
> > > +
> > > + Num = 0;
> > > + for (FindNodeStatus = FdtClient->FindCompatibleNode (FdtClient,
> > > + "cfi-flash", &Node);
> > > + !EFI_ERROR (FindNodeStatus);
> > > + FindNodeStatus = FdtClient->FindNextCompatibleNode (FdtClient,
> > > + "cfi-flash", Node, &Node)) {
> > > +
> > > +Status = FdtClient->GetNodeProperty (FdtClient, Node, "status",
> > > + (CONST VOID **)&NodeStatus, NULL);
> > > +if (!EFI_ERROR (Statu
Re: [edk2] [PATCH 1/2] ArmPlatformPkg/NorFlashDxe: use one GUID plus index to identify flash banks
On 11/17/18 01:45, Ard Biesheuvel wrote:
> Currently, each flash bank controlled by ArmPlatformPkg/NorFlashDxe
> has its own VendorHw GUID, and instances of NorFlashPlatformLib
> describe each bank to the driver, along with the GUID for each.
>
> This works ok for bare metal platforms, but it would be useful for
> virtual platforms if we could obtain this information from a
> device tree, which would require us to invent GUIDs on the fly,
> given that the 'cfi-flash' binding does not include a GUID.
>
> So instead, let's switch to a single GUID for all flash banks,
> and update the driver's device path handling to include an index
> to identify each bank uniquely.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> ---
> ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c | 15 +--
> ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h | 3 +++
> 2 files changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
> b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
> index 46e815beb343..60a06e4a5058 100644
> --- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
> +++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
> @@ -82,10 +82,14 @@ NOR_FLASH_INSTANCE mNorFlashInstanceTemplate = {
>{
> HARDWARE_DEVICE_PATH,
> HW_VENDOR_DP,
> -{ (UINT8)sizeof(VENDOR_DEVICE_PATH),
> (UINT8)((sizeof(VENDOR_DEVICE_PATH)) >> 8) }
> +{
> + (UINT8)(OFFSET_OF(NOR_FLASH_DEVICE_PATH, End)),
> + (UINT8)(OFFSET_OF(NOR_FLASH_DEVICE_PATH, End) >> 8)
> +}
(1) Please add a space character after OFFSET_OF (both instances).
(2) OFFSET_OF suggests a now-missing #pragma pack (1)... added at the
bottom, great.
(3) Normally I would prefer to split this hunk to a prior patch, as a
no-op refactoring. Up to you.
>},
>{ 0x0, 0x0, 0x0, { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 } }, // GUID
> ... NEED TO BE FILLED
> },
> +0, // Index
> {
>END_DEVICE_PATH_TYPE,
>END_ENTIRE_DEVICE_PATH_SUBTYPE,
> @@ -99,10 +103,9 @@ NorFlashCreateInstance (
>IN UINTN NorFlashDeviceBase,
>IN UINTN NorFlashRegionBase,
>IN UINTN NorFlashSize,
> - IN UINT32 MediaId,
> + IN UINT32 Index,
(4) Same as (3), also up to you.
>IN UINT32 BlockSize,
>IN BOOLEANSupportFvb,
> - IN CONST GUID *NorFlashGuid,
>OUT NOR_FLASH_INSTANCE** NorFlashInstance
>)
> {
> @@ -121,11 +124,12 @@ NorFlashCreateInstance (
>Instance->Size = NorFlashSize;
>
>Instance->BlockIoProtocol.Media = &Instance->Media;
> - Instance->Media.MediaId = MediaId;
> + Instance->Media.MediaId = Index;
(5) Ditto.
>Instance->Media.BlockSize = BlockSize;
>Instance->Media.LastBlock = (NorFlashSize / BlockSize)-1;
>
> - CopyGuid (&Instance->DevicePath.Vendor.Guid, NorFlashGuid);
> + CopyGuid (&Instance->DevicePath.Vendor.Guid, &gEfiCallerIdGuid);
> + Instance->DevicePath.Index = Index;
>
>Instance->ShadowBuffer = AllocateRuntimePool (BlockSize);;
>if (Instance->ShadowBuffer == NULL) {
> @@ -1311,7 +1315,6 @@ NorFlashInitialise (
>Index,
>NorFlashDevices[Index].BlockSize,
>ContainVariableStorage,
> - &NorFlashDevices[Index].Guid,
>&mNorFlashInstances[Index]
> );
> if (EFI_ERROR(Status)) {
> diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
> b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
> index 5c07694fbfaa..8886aa43d9f3 100644
> --- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
> +++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
> @@ -122,10 +122,13 @@
>
> typedef struct _NOR_FLASH_INSTANCENOR_FLASH_INSTANCE;
>
> +#pragma pack(1)
> typedef struct {
>VENDOR_DEVICE_PATH Vendor;
> + UINT8 Index;
>EFI_DEVICE_PATH_PROTOCOLEnd;
> } NOR_FLASH_DEVICE_PATH;
> +#pragma pack()
>
> struct _NOR_FLASH_INSTANCE {
>UINT32 Signature;
>
(6) Given that you introduce this field as UINT8, the
"Instance->DevicePath.Index = Index" assignment in
NorFlashCreateInstance() is liable to trigger UINT32-->UINT8
"truncation" warnings under at least some toolchains, IMO. Can you add
an explicit cast to that assignment (assuming you deem the assignment
safe otherwise)?
If you decide to ignore (3) through (5), I think (1) and (6) can be
fixed up before pushing. In that case:
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] EmulatorPkg Unix Host Segmentation fault.
On 2018-11-18 17:13:21, Jordan Justen wrote:
> On 2018-11-18 14:37:09, Andrew Fish wrote:
> >
> >
> > > On Nov 18, 2018, at 4:07 AM, Liu Yu wrote:
> > >
> > > sorry your path can't fix this issue. if this path just turn off
> > > optimization option within sec.c not global project.
> > >
> > > I have tested different version GCC such as (GCC4,8, GCC5.x, GCC7.x)
> > > and all of them can duplicate this issue (Ubuntu 16.04, 16.10,18.04 )
> > >
> > > I have traced this issue on my hand.
> > >
> > > you can see Dispatcher.c (MdeModulePkg/Pei/DIspatcher/) Line 792:
> > >
> > >
> > > 790 if (StackOffsetPositive) {
> > > 791 SecCoreData = (CONST EFI_SEC_PEI_HAND_OFF *)((UINTN)(VOID
> > > *)SecCoreData + StackOffset);
> > > 792 Private = (PEI_CORE_INSTANCE *)((UINTN)(VOID *)Private +
> > > StackOffset);
> > > 793 } else {
> > > 794 ..
> > > 795 ..
> > > 796}
> > >
> > > 790 --792 disassembly code
> > >
> > > 0x10200f2ca :test %r14b,%r14b
> > > 0x10200f2cd :je 0x10200f2df
> > >
> > > 0x10200f2cf :mov 0x38(%rsp),%rax
> > > 0x10200f2d4 :lea 0x0(%rbp,%rax,1),%r14
> > > 0x10200f2d9 :lea (%rbx,%rax,1),%rbp
> > >
> > > we can see Private value have been stored in %rbp (rbp register be
> > > used as general register ) so when call
> > > TemporaryRamSupportPpi->TemporaryRamMigration()
> > >
> >
> > The calling conventions define RBP as non-volatile must be preserved
> > by callee. Using RBP as the frame pointer is optional.
>
> This is kind of a mess. I think the definition of
> EFI_PEI_TEMPORARY_RAM_SUPPORT_PPI is really to blame. It probably
> should not have been spec'd as 'change stack and return'. Instead, it
> should have been given a new function pointer to switch-stack and call
> into.
Andrew, Mike,
I developed a PEI Core fix for this issue, which Liu Yu verified.
Unfortunately, it involves add assembly code in a key area of the PEI
Core. See the top 2 commits of:
https://github.com/jljusten/edk2/commits/emulator-temp-ram
I only wrote assembly for X64 nasm. But, I notice that neither the PEI
or DXE Core modules include any assembly code. So, I want to make sure
I'm heading in the right direction before working on it further.
As I mentioned below, I think PIWG could consider an new
TemporarayRemSupport interface that might work better, but that also
may not be worth the effort.
Can something like this change be integrated into the PEI Core?
Thanks for your time,
-Jordan
> By returning with a switched stack, we don't really know what the
> returning code could do with regard to the stack. For example, it
> could have saved the stack value on the stack and then pop it into a
> register and somehow switch the stack back to the old stack. It seems
> unlikely, but I don't think anything prevents it.
>
> Additionally, there is the issue of rbp/ebp being used as a frame
> pointer. This can lead to some variables being used from the temp ram
> location after we return from TemporaryRamMigration. (Assuming rbp/ebp
> is not adjusted to point to the new stack.)
>
> So, is it safe to adjust rbp? Unknown. It may not be if rbp is not
> used as a frame pointer. Is it safe to *not* adjust rbp and
> potentially allow the old temp ram stack to be used? Unknown.
>
> Now, if TemporaryRamMigration received a new function to call into, we
> can safely assume that the new stack transition would proceed as
> expected without having to worry if a compiler is using rbp/ebp as a
> framepointer or not.
>
> Another advantage could have been that something like the BasePkg
> SwitchStack function could have been used, hopefully preventing people
> from trying to write error prone assembly code for
> TemporaryRamMigration.
>
> -Jordan
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 1/2] ArmPlatformPkg/NorFlashDxe: use one GUID plus index to identify flash banks
On Mon, Nov 19, 2018 at 11:09:32AM -0800, Ard Biesheuvel wrote:
> > > @@ -121,11 +124,12 @@ NorFlashCreateInstance (
> > >Instance->Size = NorFlashSize;
> > >
> > >Instance->BlockIoProtocol.Media = &Instance->Media;
> > > - Instance->Media.MediaId = MediaId;
> > > + Instance->Media.MediaId = Index;
> > >Instance->Media.BlockSize = BlockSize;
> > >Instance->Media.LastBlock = (NorFlashSize / BlockSize)-1;
> > >
> > > - CopyGuid (&Instance->DevicePath.Vendor.Guid, NorFlashGuid);
> > > + CopyGuid (&Instance->DevicePath.Vendor.Guid, &gEfiCallerIdGuid);
> >
> > Just sanity checking: this sets the VendorGuid to the NorFlashDxe
> > GUID? (93E34C7E-B50E-11DF-9223-2443DFD72085)
> >
>
> Yes.
>
> Before:
>
> Mapping table
> BLK1: Alias(s):
> VenHw(F9B94AE2-8BA6-409B-9D56-B9B417F53CB3)
> BLK0: Alias(s):
> VenHw(8047DB4B-7E9C-4C0C-8EBC-DFBBAACACE8F)
>
> After:
>
> Mapping table
> BLK0: Alias(s):
> VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00)
> BLK1: Alias(s):
> VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,01)
OK, I'm happy with that.
If Thomas/Nariman don't object:
Reviewed-by: Leif Lindholm
/
Leif
> > If not, can you explain it to me slowly? :)
> >
> > Thomas, Nariman: would this change cause any transient issues for
> > anything that has set Boot options in any of your configurations?
> > And if it would, is that a big deal?
> > (Ard has a separate patch that fixes up any default values.)
> >
> > /
> > Leif
> >
> > > + Instance->DevicePath.Index = Index;
> > >
> > >Instance->ShadowBuffer = AllocateRuntimePool (BlockSize);;
> > >if (Instance->ShadowBuffer == NULL) {
> > > @@ -1311,7 +1315,6 @@ NorFlashInitialise (
> > >Index,
> > >NorFlashDevices[Index].BlockSize,
> > >ContainVariableStorage,
> > > - &NorFlashDevices[Index].Guid,
> > >&mNorFlashInstances[Index]
> > > );
> > > if (EFI_ERROR(Status)) {
> > > diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
> > > b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
> > > index 5c07694fbfaa..8886aa43d9f3 100644
> > > --- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
> > > +++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
> > > @@ -122,10 +122,13 @@
> > >
> > > typedef struct _NOR_FLASH_INSTANCENOR_FLASH_INSTANCE;
> > >
> > > +#pragma pack(1)
> > > typedef struct {
> > >VENDOR_DEVICE_PATH Vendor;
> > > + UINT8 Index;
> > >EFI_DEVICE_PATH_PROTOCOLEnd;
> > > } NOR_FLASH_DEVICE_PATH;
> > > +#pragma pack()
> > >
> > > struct _NOR_FLASH_INSTANCE {
> > >UINT32 Signature;
> > > --
> > > 2.17.1
> > >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 2/2] ArmVirtPkg/NorFlashQemuLib: discover NOR flash banks dynamically
On Mon, Nov 19, 2018 at 11:16:09AM -0800, Ard Biesheuvel wrote:
> On Mon, 19 Nov 2018 at 11:10, Leif Lindholm wrote:
> >
> > On Fri, Nov 16, 2018 at 05:29:05PM -0800, Ard Biesheuvel wrote:
> > > On Fri, 16 Nov 2018 at 16:45, Ard Biesheuvel
> > > wrote:
> > > >
> > > > NorFlashQemuLib is one of the last remaining drivers in ArmVirtPkg
> > > > that are not based on the device tree received from QEMU.
> > > >
> > > > For ArmVirtQemu, this does not really matter, given that the NOR
> > > > flash banks are always the same: the PEI code is linked to execute
> > > > in place from flash bank #0, and the fixed varstore PCDs refer to
> > > > flash bank #1 directly.
> > > >
> > > > However, ArmVirtQemuKernel can execute at any offset, and flash bank
> > >
> > > #0 is configured as secure-only when running with support for EL3 enabled.
> >
> > Never gets old :)
>
> No this is entirely reasonable: it makes perfect sense for a NOR flash
> at address 0x0 to be secure only on a system that implements EL3,
> since mach-virt's default reset vector is 0x0.
*cough* sorry, I was referring to the leading #.
> > > > In this case, NorFlashQemuLib should not expose the first flash bank
> > > > at all.
> > > >
> > > > To prevent introducing too much internal knowledge about which flash
> > > > bank is accessible under which circumstances, let's switch to using
> > > > the DTB to decide which flash banks to expose to the NOR flash driver.
> >
> > Does this mean we as a side effect get rid of the limitation that the
> > pflash image needs to be exactly 64MB. Or does that require further
> > changes on the QEMU side?
>
> No that is a QEMU thing.
OK, thanks for confirming.
But this should mean that we don't need any changes on the guest sides
if/when we do fix this in QEMU?
/
Leif
> > If it does, please add a comment to the commit message.
> > Either way:
> > Reviewed-by: Leif Lindholm
> >
>
> Thanks
>
> > > >
> > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > Signed-off-by: Ard Biesheuvel
> > > > ---
> > > > ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c | 84
> > > > +++-
> > > > ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf | 12 +++
> > > > 2 files changed, 75 insertions(+), 21 deletions(-)
> > > >
> > > > diff --git a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> > > > b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> > > > index e3bbae5b06c5..dc0a15e77170 100644
> > > > --- a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> > > > +++ b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> > > > @@ -1,6 +1,6 @@
> > > > /** @file
> > > >
> > > > - Copyright (c) 2014, Linaro Ltd. All rights reserved.
> > > > + Copyright (c) 2014-2018, Linaro Ltd. All rights reserved.
> > > >
> > > > This program and the accompanying materials
> > > > are licensed and made available under the terms and conditions of the
> > > > BSD License
> > > > @@ -12,13 +12,16 @@
> > > >
> > > > **/
> > > >
> > > > +#include
> > > > +#include
> > > > #include
> > > > +#include
> > > > +
> > > > +#include
> > > >
> > > > #define QEMU_NOR_BLOCK_SIZESIZE_256KB
> > > > -#define QEMU_NOR0_BASE 0x0
> > > > -#define QEMU_NOR0_SIZE SIZE_64MB
> > > > -#define QEMU_NOR1_BASE 0x0400
> > > > -#define QEMU_NOR1_SIZE SIZE_64MB
> > > > +
> > > > +#define MAX_FLASH_BANKS4
> > > >
> > > > EFI_STATUS
> > > > NorFlashPlatformInitialization (
> > > > @@ -28,21 +31,7 @@ NorFlashPlatformInitialization (
> > > >return EFI_SUCCESS;
> > > > }
> > > >
> > > > -NOR_FLASH_DESCRIPTION mNorFlashDevices[] = {
> > > > - {
> > > > -QEMU_NOR0_BASE,
> > > > -QEMU_NOR0_BASE,
> > > > -QEMU_NOR0_SIZE,
> > > > -QEMU_NOR_BLOCK_SIZE,
> > > > -{0xF9B94AE2, 0x8BA6, 0x409B, {0x9D, 0x56, 0xB9, 0xB4, 0x17, 0xF5,
> > > > 0x3C, 0xB3}}
> > > > - }, {
> > > > -QEMU_NOR1_BASE,
> > > > -QEMU_NOR1_BASE,
> > > > -QEMU_NOR1_SIZE,
> > > > -QEMU_NOR_BLOCK_SIZE,
> > > > -{0x8047DB4B, 0x7E9C, 0x4C0C, {0x8E, 0xBC, 0xDF, 0xBB, 0xAA, 0xCA,
> > > > 0xCE, 0x8F}}
> > > > - }
> > > > -};
> > > > +NOR_FLASH_DESCRIPTION mNorFlashDevices[MAX_FLASH_BANKS];
> > > >
> > > > EFI_STATUS
> > > > NorFlashPlatformGetDevices (
> > > > @@ -50,7 +39,60 @@ NorFlashPlatformGetDevices (
> > > >OUT UINT32 *Count
> > > >)
> > > > {
> > > > + FDT_CLIENT_PROTOCOL *FdtClient;
> > > > + INT32 Node;
> > > > + EFI_STATUS Status;
> > > > + EFI_STATUS FindNodeStatus;
> > > > + CONST UINT64*Reg;
> > > > + UINT32 RegSize;
> > > > + CONST CHAR8 *NodeStatus;
> > > > + UINTN Num;
> > > > +
> > > > + Status = gBS->LocateProtocol (&gFdtClientProtocolGuid, NULL,
> > > > + (VOID **)&FdtClient);
> > > > + ASSERT_EFI_ERROR (Status);
> > > > +
> > > > + Num = 0;
>
Re: [edk2] [PATCH 2/2] ArmVirtPkg/NorFlashQemuLib: discover NOR flash banks dynamically
On Mon, 19 Nov 2018 at 11:24, Leif Lindholm wrote: > > > On Mon, Nov 19, 2018 at 11:16:09AM -0800, Ard Biesheuvel wrote: > > On Mon, 19 Nov 2018 at 11:10, Leif Lindholm > > wrote: > > > > > > On Fri, Nov 16, 2018 at 05:29:05PM -0800, Ard Biesheuvel wrote: > > > > On Fri, 16 Nov 2018 at 16:45, Ard Biesheuvel > > > > wrote: > > > > > > > > > > NorFlashQemuLib is one of the last remaining drivers in ArmVirtPkg > > > > > that are not based on the device tree received from QEMU. > > > > > > > > > > For ArmVirtQemu, this does not really matter, given that the NOR > > > > > flash banks are always the same: the PEI code is linked to execute > > > > > in place from flash bank #0, and the fixed varstore PCDs refer to > > > > > flash bank #1 directly. > > > > > > > > > > However, ArmVirtQemuKernel can execute at any offset, and flash bank > > > > > > > > #0 is configured as secure-only when running with support for EL3 > > > > enabled. > > > > > > Never gets old :) > > > > No this is entirely reasonable: it makes perfect sense for a NOR flash > > at address 0x0 to be secure only on a system that implements EL3, > > since mach-virt's default reset vector is 0x0. > > *cough* sorry, I was referring to the leading #. > Ah yes :-) Been caught by that a couple of times already. > > > > > In this case, NorFlashQemuLib should not expose the first flash bank > > > > > at all. > > > > > > > > > > To prevent introducing too much internal knowledge about which flash > > > > > bank is accessible under which circumstances, let's switch to using > > > > > the DTB to decide which flash banks to expose to the NOR flash driver. > > > > > > Does this mean we as a side effect get rid of the limitation that the > > > pflash image needs to be exactly 64MB. Or does that require further > > > changes on the QEMU side? > > > > No that is a QEMU thing. > > OK, thanks for confirming. > But this should mean that we don't need any changes on the guest sides > if/when we do fix this in QEMU? > This would indeed get rid of any discrepancies between what QEMU exposes and what the firmware assumes, so yes, it's an improvement in that sense. However, I don't think the QEMU side of this is likely to change any time soon. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 0/2] Clear frame pointer in startup code on AARCH64 systems
On Mon, 19 Nov 2018 at 10:56, Leif Lindholm wrote: > > On Fri, Nov 16, 2018 at 02:55:56PM -0800, Ard Biesheuvel wrote: > > The backtrace code on AARCH64 does not sanitize the frame pointer values > > it pulls of the stack when attempting to do a backtrace, and so junk left > > in the frame pointer register may result in a recursive exception and a > > truncated backtrace. > > If I was bikeshedding, I'd ask for a (NULL) in the comments next to > the 0x0. But other than that, for the series: > Reviewed-by: Leif Lindholm > (be it green or black) > Thanks all. Series pushed as 316b3a719fd2..81c6f1dfbac1 (after s/0x0/NULL/ in the comments) ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms] Platform/ARM: replace hardcoded VenHW() device paths referring to NOR flash
Hmm, a follow-up question (which does not affect my r-b): We still keep the manually generated GUIDs in ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c, Platform/ARM/JunoPkg/Library/NorFlashJunoLib/NorFlashJuno.c, Platform/ARM/SgiPkg/Library/NorFlashLib/NorFlashLib.c, Platform/ARM/VExpressPkg/Library/NorFlashArmVExpressLib/NorFlashArmVExpress.c, Silicon/Socionext/SynQuacer/Library/NorFlashSynQuacerLib/NorFlashSynQuacer.c, and indeed in the NOR_FLASH_DESCRIPTION struct in ArmPlatformPkg/Include/Library/NorFlashPlatformLib.h Is this an opportunity for a negative diffstat? / Leif On Mon, Nov 19, 2018 at 07:12:47PM +, Leif Lindholm wrote: > On Fri, Nov 16, 2018 at 05:23:08PM -0800, Ard Biesheuvel wrote: > > The ArmPlatformPkg NOR flash driver has been updated to use device paths > > consisting of a fixed GUID and a numeric index rather than a separate GUID > > for each flash bank on a given system. This means all explicit device path > > references to NOR flash banks have to be brought up to date as well. > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Ard Biesheuvel > > This looks good to me, but I'd like a comment from Thomas/Nariman. > > With that: > Reviewed-by: Leif Lindholm > > > --- > > Platform/ARM/JunoPkg/ArmJuno.dec | 2 +- > > Platform/ARM/JunoPkg/ArmJuno.dsc | 2 +- > > Platform/ARM/SgiPkg/SgiPlatform.dsc | 2 +- > > Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc | 2 +- > > Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc | 2 +- > > 5 files changed, 5 insertions(+), 5 deletions(-) > > > > diff --git a/Platform/ARM/JunoPkg/ArmJuno.dec > > b/Platform/ARM/JunoPkg/ArmJuno.dec > > index edbbb827ad45..c511796d8913 100644 > > --- a/Platform/ARM/JunoPkg/ArmJuno.dec > > +++ b/Platform/ARM/JunoPkg/ArmJuno.dec > > @@ -44,7 +44,7 @@ > > > > gArmJunoTokenSpaceGuid.PcdSynopsysUsbEhciBaseAddress|0x7FFC|UINT32|0x0005 > > > ># Juno Device Trees are loaded from NOR Flash > > - > > gArmJunoTokenSpaceGuid.PcdJunoFdtDevicePath|L"VenHw(E7223039-5836-41E1-B542-D7EC736C5E59)/board.dtb"|VOID*|0x0008 > > + > > gArmJunoTokenSpaceGuid.PcdJunoFdtDevicePath|L"VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00)/board.dtb"|VOID*|0x0008 > > > ># MHU Register base used by SCMI Mailbox transport > >gArmJunoTokenSpaceGuid.PcdArmMtlDoorBell|0x2B1F|UINT64|0x0024 > > diff --git a/Platform/ARM/JunoPkg/ArmJuno.dsc > > b/Platform/ARM/JunoPkg/ArmJuno.dsc > > index ac3d63bd4d39..55b9d64d3deb 100644 > > --- a/Platform/ARM/JunoPkg/ArmJuno.dsc > > +++ b/Platform/ARM/JunoPkg/ArmJuno.dsc > > @@ -176,7 +176,7 @@ > >gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|24 > > > ># List of Device Paths that support BootMonFs > > - > > gArmBootMonFsTokenSpaceGuid.PcdBootMonFsSupportedDevicePaths|L"VenHw(E7223039-5836-41E1-B542-D7EC736C5E59)" > > + > > gArmBootMonFsTokenSpaceGuid.PcdBootMonFsSupportedDevicePaths|L"VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00)" > > > ># > ># ARM Architectural Timer Frequency > > diff --git a/Platform/ARM/SgiPkg/SgiPlatform.dsc > > b/Platform/ARM/SgiPkg/SgiPlatform.dsc > > index 3f0ca9872e79..06d866d6dc30 100644 > > --- a/Platform/ARM/SgiPkg/SgiPlatform.dsc > > +++ b/Platform/ARM/SgiPkg/SgiPlatform.dsc > > @@ -163,7 +163,7 @@ > >gArmPlatformTokenSpaceGuid.PcdPL031RtcBase|0x1C17 > > > ># List of Device Paths that support BootMonFs > > - > > gArmBootMonFsTokenSpaceGuid.PcdBootMonFsSupportedDevicePaths|L"VenHw(E7223039-5836-41E1-B542-D7EC736C5E59)" > > + > > gArmBootMonFsTokenSpaceGuid.PcdBootMonFsSupportedDevicePaths|L"VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00)" > > > ># ARM OS Loader > >gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|3 > > diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc > > b/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc > > index 0542808f7d0c..3a3b4e3dbbc8 100644 > > --- a/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc > > +++ b/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc > > @@ -172,7 +172,7 @@ > ># > ># Define the device path to the FDT for the platform > ># > > - > > gFdtPlatformDxeTokenSpaceGuid.PcdFdtDevicePaths|L"VenHw(E7223039-5836-41E1-B542-D7EC736C5E59)/ca15a7" > > + > > gFdtPlatformDxeTokenSpaceGuid.PcdFdtDevicePaths|L"VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00)/ca15a7" > > > ># > ># ARM Architectural Timer Frequency > > diff --git a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc > > b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc > > index 752e525c3469..713c5637b074 100644 > > --- a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc > > +++ b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc > > @@ -355,7 +355,7 @@ > ># > > > ># List of Device Paths that support BootMonFs > > - > > gArmBootMonFsTokenSpaceGuid.PcdBootMonFsSupportedDevicePaths|L"VenHw(E7223039-5836-41E1-B542-D7EC736C5E59);VenHw(1F15DA3C-37FF-4070-B471-BB4AF12A724A)" > >
Re: [edk2] [PATCH edk2-platforms] Platform/ARM: replace hardcoded VenHW() device paths referring to NOR flash
On Mon, 19 Nov 2018 at 11:30, Leif Lindholm wrote: > > Hmm, a follow-up question (which does not affect my r-b): > > We still keep the manually generated GUIDs in > ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c, > Platform/ARM/JunoPkg/Library/NorFlashJunoLib/NorFlashJuno.c, > Platform/ARM/SgiPkg/Library/NorFlashLib/NorFlashLib.c, > Platform/ARM/VExpressPkg/Library/NorFlashArmVExpressLib/NorFlashArmVExpress.c, > Silicon/Socionext/SynQuacer/Library/NorFlashSynQuacerLib/NorFlashSynQuacer.c, > > and indeed in the NOR_FLASH_DESCRIPTION struct in > ArmPlatformPkg/Include/Library/NorFlashPlatformLib.h > > Is this an opportunity for a negative diffstat? > Yes. I was anticipating some discussion on renaming the NOR flash blocks, but indeed, we can drop all of the above once the rename change is in. > On Mon, Nov 19, 2018 at 07:12:47PM +, Leif Lindholm wrote: > > On Fri, Nov 16, 2018 at 05:23:08PM -0800, Ard Biesheuvel wrote: > > > The ArmPlatformPkg NOR flash driver has been updated to use device paths > > > consisting of a fixed GUID and a numeric index rather than a separate GUID > > > for each flash bank on a given system. This means all explicit device path > > > references to NOR flash banks have to be brought up to date as well. > > > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > > Signed-off-by: Ard Biesheuvel > > > > This looks good to me, but I'd like a comment from Thomas/Nariman. > > > > With that: > > Reviewed-by: Leif Lindholm > > > > > --- > > > Platform/ARM/JunoPkg/ArmJuno.dec | 2 +- > > > Platform/ARM/JunoPkg/ArmJuno.dsc | 2 +- > > > Platform/ARM/SgiPkg/SgiPlatform.dsc | 2 +- > > > Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc | 2 +- > > > Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc | 2 +- > > > 5 files changed, 5 insertions(+), 5 deletions(-) > > > > > > diff --git a/Platform/ARM/JunoPkg/ArmJuno.dec > > > b/Platform/ARM/JunoPkg/ArmJuno.dec > > > index edbbb827ad45..c511796d8913 100644 > > > --- a/Platform/ARM/JunoPkg/ArmJuno.dec > > > +++ b/Platform/ARM/JunoPkg/ArmJuno.dec > > > @@ -44,7 +44,7 @@ > > > > > > gArmJunoTokenSpaceGuid.PcdSynopsysUsbEhciBaseAddress|0x7FFC|UINT32|0x0005 > > > > > ># Juno Device Trees are loaded from NOR Flash > > > - > > > gArmJunoTokenSpaceGuid.PcdJunoFdtDevicePath|L"VenHw(E7223039-5836-41E1-B542-D7EC736C5E59)/board.dtb"|VOID*|0x0008 > > > + > > > gArmJunoTokenSpaceGuid.PcdJunoFdtDevicePath|L"VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00)/board.dtb"|VOID*|0x0008 > > > > > ># MHU Register base used by SCMI Mailbox transport > > >gArmJunoTokenSpaceGuid.PcdArmMtlDoorBell|0x2B1F|UINT64|0x0024 > > > diff --git a/Platform/ARM/JunoPkg/ArmJuno.dsc > > > b/Platform/ARM/JunoPkg/ArmJuno.dsc > > > index ac3d63bd4d39..55b9d64d3deb 100644 > > > --- a/Platform/ARM/JunoPkg/ArmJuno.dsc > > > +++ b/Platform/ARM/JunoPkg/ArmJuno.dsc > > > @@ -176,7 +176,7 @@ > > >gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|24 > > > > > ># List of Device Paths that support BootMonFs > > > - > > > gArmBootMonFsTokenSpaceGuid.PcdBootMonFsSupportedDevicePaths|L"VenHw(E7223039-5836-41E1-B542-D7EC736C5E59)" > > > + > > > gArmBootMonFsTokenSpaceGuid.PcdBootMonFsSupportedDevicePaths|L"VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00)" > > > > > ># > > ># ARM Architectural Timer Frequency > > > diff --git a/Platform/ARM/SgiPkg/SgiPlatform.dsc > > > b/Platform/ARM/SgiPkg/SgiPlatform.dsc > > > index 3f0ca9872e79..06d866d6dc30 100644 > > > --- a/Platform/ARM/SgiPkg/SgiPlatform.dsc > > > +++ b/Platform/ARM/SgiPkg/SgiPlatform.dsc > > > @@ -163,7 +163,7 @@ > > >gArmPlatformTokenSpaceGuid.PcdPL031RtcBase|0x1C17 > > > > > ># List of Device Paths that support BootMonFs > > > - > > > gArmBootMonFsTokenSpaceGuid.PcdBootMonFsSupportedDevicePaths|L"VenHw(E7223039-5836-41E1-B542-D7EC736C5E59)" > > > + > > > gArmBootMonFsTokenSpaceGuid.PcdBootMonFsSupportedDevicePaths|L"VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00)" > > > > > ># ARM OS Loader > > >gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|3 > > > diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc > > > b/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc > > > index 0542808f7d0c..3a3b4e3dbbc8 100644 > > > --- a/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc > > > +++ b/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc > > > @@ -172,7 +172,7 @@ > > ># > > ># Define the device path to the FDT for the platform > > ># > > > - > > > gFdtPlatformDxeTokenSpaceGuid.PcdFdtDevicePaths|L"VenHw(E7223039-5836-41E1-B542-D7EC736C5E59)/ca15a7" > > > + > > > gFdtPlatformDxeTokenSpaceGuid.PcdFdtDevicePaths|L"VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00)/ca15a7" > > > > > ># > > ># ARM Architectural Timer Frequency > > > diff --git a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc > > > b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc > > > index 752e525c3469..713c5637b074
Re: [edk2] [PATCH 2/2] ArmVirtPkg/NorFlashQemuLib: discover NOR flash banks dynamically
On Mon, Nov 19, 2018 at 11:27:22AM -0800, Ard Biesheuvel wrote: > > > > > > In this case, NorFlashQemuLib should not expose the first flash bank > > > > > > at all. > > > > > > > > > > > > To prevent introducing too much internal knowledge about which flash > > > > > > bank is accessible under which circumstances, let's switch to using > > > > > > the DTB to decide which flash banks to expose to the NOR flash > > > > > > driver. > > > > > > > > Does this mean we as a side effect get rid of the limitation that the > > > > pflash image needs to be exactly 64MB. Or does that require further > > > > changes on the QEMU side? > > > > > > No that is a QEMU thing. > > > > OK, thanks for confirming. > > But this should mean that we don't need any changes on the guest sides > > if/when we do fix this in QEMU? > > This would indeed get rid of any discrepancies between what QEMU > exposes and what the firmware assumes, so yes, it's an improvement in > that sense. However, I don't think the QEMU side of this is likely to > change any time soon. Sure. But it does decrease the amount of reward delay required for someone to consider having a look at it :) Thanks! / Leif ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 2/2] ArmVirtPkg/NorFlashQemuLib: discover NOR flash banks dynamically
On 11/17/18 01:45, Ard Biesheuvel wrote:
> NorFlashQemuLib is one of the last remaining drivers in ArmVirtPkg
> that are not based on the device tree received from QEMU.
>
> For ArmVirtQemu, this does not really matter, given that the NOR
> flash banks are always the same: the PEI code is linked to execute
> in place from flash bank #0, and the fixed varstore PCDs refer to
> flash bank #1 directly.
>
> However, ArmVirtQemuKernel can execute at any offset, and flash bank
> In this case, NorFlashQemuLib should not expose the first flash bank
> at all.
>
> To prevent introducing too much internal knowledge about which flash
> bank is accessible under which circumstances, let's switch to using
> the DTB to decide which flash banks to expose to the NOR flash driver.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> ---
> ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c | 84
> +++-
> ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf | 12 +++
> 2 files changed, 75 insertions(+), 21 deletions(-)
>
> diff --git a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> index e3bbae5b06c5..dc0a15e77170 100644
> --- a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> +++ b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> @@ -1,6 +1,6 @@
> /** @file
>
> - Copyright (c) 2014, Linaro Ltd. All rights reserved.
> + Copyright (c) 2014-2018, Linaro Ltd. All rights reserved.
>
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD
> License
> @@ -12,13 +12,16 @@
>
> **/
>
> +#include
> +#include
> #include
> +#include
> +
> +#include
>
> #define QEMU_NOR_BLOCK_SIZESIZE_256KB
> -#define QEMU_NOR0_BASE 0x0
> -#define QEMU_NOR0_SIZE SIZE_64MB
> -#define QEMU_NOR1_BASE 0x0400
> -#define QEMU_NOR1_SIZE SIZE_64MB
> +
> +#define MAX_FLASH_BANKS4
>
> EFI_STATUS
> NorFlashPlatformInitialization (
> @@ -28,21 +31,7 @@ NorFlashPlatformInitialization (
>return EFI_SUCCESS;
> }
>
> -NOR_FLASH_DESCRIPTION mNorFlashDevices[] = {
> - {
> -QEMU_NOR0_BASE,
> -QEMU_NOR0_BASE,
> -QEMU_NOR0_SIZE,
> -QEMU_NOR_BLOCK_SIZE,
> -{0xF9B94AE2, 0x8BA6, 0x409B, {0x9D, 0x56, 0xB9, 0xB4, 0x17, 0xF5, 0x3C,
> 0xB3}}
> - }, {
> -QEMU_NOR1_BASE,
> -QEMU_NOR1_BASE,
> -QEMU_NOR1_SIZE,
> -QEMU_NOR_BLOCK_SIZE,
> -{0x8047DB4B, 0x7E9C, 0x4C0C, {0x8E, 0xBC, 0xDF, 0xBB, 0xAA, 0xCA, 0xCE,
> 0x8F}}
> - }
> -};
> +NOR_FLASH_DESCRIPTION mNorFlashDevices[MAX_FLASH_BANKS];
>
> EFI_STATUS
> NorFlashPlatformGetDevices (
> @@ -50,7 +39,60 @@ NorFlashPlatformGetDevices (
>OUT UINT32 *Count
>)
> {
> + FDT_CLIENT_PROTOCOL *FdtClient;
> + INT32 Node;
> + EFI_STATUS Status;
> + EFI_STATUS FindNodeStatus;
> + CONST UINT64*Reg;
> + UINT32 RegSize;
> + CONST CHAR8 *NodeStatus;
> + UINTN Num;
> +
> + Status = gBS->LocateProtocol (&gFdtClientProtocolGuid, NULL,
> + (VOID **)&FdtClient);
> + ASSERT_EFI_ERROR (Status);
> +
> + Num = 0;
> + for (FindNodeStatus = FdtClient->FindCompatibleNode (FdtClient,
> + "cfi-flash", &Node);
> + !EFI_ERROR (FindNodeStatus);
> + FindNodeStatus = FdtClient->FindNextCompatibleNode (FdtClient,
> + "cfi-flash", Node, &Node)) {
> +
> +Status = FdtClient->GetNodeProperty (FdtClient, Node, "status",
> + (CONST VOID **)&NodeStatus, NULL);
> +if (!EFI_ERROR (Status) && AsciiStrnCmp (NodeStatus, "ok", 2) != 0) {
> + continue;
> +}
(1) Do you intend to silently continue if the "status" property is missing?
(2) Assuming the "status" property exists, I think we could improve the
comparison against "ok". Can you allow GetNodeProperty() to output
PropSize as well? And then,
if (!EFI_ERROR (Status) &&
AsciiStrnCmp (NodeStatus, "ok", PropSize) != 0) {
continue;
}
Because, if the status property is guaranteed to be NUL-terminated, then
we don't need AsciiStrnCmp(), we can use AsciiStrCmp() -- because both
strings are NUL-terminated. Or else, if we want to be careful about the
property (yes, we should be), then we should pass PropSize to
AsciiStrnCmp(). (Or maybe PropSize-1, dependent on libfdt...)
Either way it bothers me that in theory, the status property can be
shorter than 2 chars, it may not be NUL-terminated, and we pass constant
2 to AsciiStrnCmp().
I'm OK if we use an ASSERT() rather than an "if", in some of the above.
> +
> +Status = FdtClient->GetNodeProperty (FdtClient, Node, "reg",
> + (CONST VOID **)&Reg, &RegSize);
> +if (EFI_ERROR (Status)) {
> +
Re: [edk2] [PATCH 6/8] IntelFrameworkPkg: Remove the redundant INFs
Liming, We need to look at how to remove those dependencies now so the entire package can be retired. For example the only consumer of 8259 is the 8254 driver. The 8254 module can be replaced with the HPET driver that does not use 8259 at all. If we can convert all platforms that are currently using 8254 to use HPET instead, we can make a big step towards removing the entire package. Mike > -Original Message- > From: Gao, Liming > Sent: Sunday, November 18, 2018 9:16 PM > To: Kinney, Michael D ; > Zhang, Shenglei ; Ni, Ruiyu > ; edk2-devel@lists.01.org > Cc: Gao, Liming > Subject: RE: [edk2] [PATCH 6/8] IntelFrameworkPkg: Remove > the redundant INFs > > Mike: > The long term goal is to remove IntelFrameworkPkg. I > propose to remove its contents step by step. Now, some > unused modules or header files are very clear. They can > be removed now. But, others (such as Legacy definitions) > are still consumed by LegacyBios and 8259/8254 drivers. > We have no solution or clear plan to drop legacy support. > They may still be kept for a while. > > Thanks > Liming > >-Original Message- > >From: Kinney, Michael D > >Sent: Wednesday, November 14, 2018 1:18 PM > >To: Zhang, Shenglei ; Ni, > Ruiyu > >; edk2-devel@lists.01.org; Kinney, > Michael D > > > >Cc: Gao, Liming > >Subject: RE: [edk2] [PATCH 6/8] IntelFrameworkPkg: > Remove the redundant > >INFs > > > >Shenglei, > > > >I would prefer we work towards the goal of removing > >the use of the Intel Framework Packages by all platforms > >so the entire packages can be removed from edk2/master. > > > >This would be better than trying to remove a few items > >at a time. > > > >Thanks, > > > >Mike > > > >> -Original Message- > >> From: Zhang, Shenglei > >> Sent: Tuesday, November 13, 2018 7:32 PM > >> To: Ni, Ruiyu ; edk2- > >> de...@lists.01.org > >> Cc: Kinney, Michael D ; > >> Gao, Liming > >> Subject: RE: [edk2] [PATCH 6/8] IntelFrameworkPkg: > >> Remove the redundant INFs > >> > >> Ray > >> Thanks for your constructive comments. I'll improve it > >> in next version. > >> > >> Thanks, > >> Shenglei > >> > -Original Message- > >> > From: Ni, Ruiyu > >> > Sent: Wednesday, November 14, 2018 11:12 AM > >> > To: Zhang, Shenglei ; > edk2- > >> de...@lists.01.org > >> > Cc: Kinney, Michael D ; > >> Gao, Liming > >> > > >> > Subject: Re: [edk2] [PATCH 6/8] IntelFrameworkPkg: > >> Remove the redundant > >> > INFs > >> > > >> > On 11/13/2018 4:35 PM, Shenglei Zhang wrote: > >> > > All INFs of unused Library instances in > >> IntelFrameworkPkg > >> > > are removed as they are not actually used. > >> > > > https://bugzilla.tianocore.org/show_bug.cgi?id=1190 > >> > > > >> > > Cc: Liming Gao > >> > > Cc: Michael D Kinney > >> > > Contributed-under: TianoCore Contribution > Agreement > >> 1.1 > >> > > Signed-off-by: Shenglei Zhang > >> > >> > > --- > >> > > IntelFrameworkPkg/IntelFrameworkPkg.dsc | 7 > - > >> -- > >> > > 1 file changed, 7 deletions(-) > >> > > > >> > > diff --git > >> a/IntelFrameworkPkg/IntelFrameworkPkg.dsc > >> > b/IntelFrameworkPkg/IntelFrameworkPkg.dsc > >> > > index bd5df8c5d9..802a80e3eb 100644 > >> > > --- a/IntelFrameworkPkg/IntelFrameworkPkg.dsc > >> > > +++ b/IntelFrameworkPkg/IntelFrameworkPkg.dsc > >> > > @@ -63,13 +63,6 @@ > >> > > # generated for it, but the binary will > not > >> be put into any firmware > >> > volume. > >> > > # > >> > > > >> > > >> > ### > >> ### > >> > # > >> > > -[Components] > >> > > - > >> > IntelFrameworkPkg/Library/DxeIoLibCpuIo/DxeIoLibCpuIo.i > >> nf > >> > > - > >> > IntelFrameworkPkg/Library/FrameworkUefiLib/FrameworkUef > >> iLib.inf > >> > > - > >> > > >> > IntelFrameworkPkg/Library/DxeSmmDriverEntryPoint/DxeSmm > >> DriverEntryP > >> > oint.inf > >> > > - > >> > > >> > IntelFrameworkPkg/Library/PeiSmbusLibSmbusPpi/PeiSmbusL > >> ibSmbusPpi.in > >> > f > >> > > - > >> > > >> > IntelFrameworkPkg/Library/PeiHobLibFramework/PeiHobLibF > >> ramework.inf > >> > > - > >> > > [BuildOptions] > >> > > *_*_*_CC_FLAGS = -D > >> DISABLE_NEW_DEPRECATED_INTERFACES > >> > > > >> > > > >> > Shenglei, > >> > You cannot remove the INF in the separate patch like > >> this. > >> > You should either put this patch in the first patch > >> in your serial, > >> > or combine the DSC change with your library removal. > >> > The goal is the the build won't fail when committing > >> the patches one by one. > >> > > >> > -- > >> > Thanks, > >> > Ray ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [edk2-announce] December Community Meeting
Hi Stephano, On 11/15/18 22:06, stephano wrote: > We will be holding monthly community meetings starting in December on > the first Thursday of the month. Details for the next meeting are here: > > https://github.com/tianocore/tianocore.github.io/wiki/Community-Virtual-Meetings the second ICS link in the article says "Asia Pacific / Europe Meeting" on the tin, but inside, it references "TianoCore-December-Community-Meeting-APAC-NAMO.ics". Thus, "APAC" is fine, but "Europe" should be replaced with "North America", IMO. Thanks! Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 2/2] ArmVirtPkg/NorFlashQemuLib: discover NOR flash banks dynamically
On Mon, 19 Nov 2018 at 12:02, Laszlo Ersek wrote:
>
> On 11/17/18 01:45, Ard Biesheuvel wrote:
> > NorFlashQemuLib is one of the last remaining drivers in ArmVirtPkg
> > that are not based on the device tree received from QEMU.
> >
> > For ArmVirtQemu, this does not really matter, given that the NOR
> > flash banks are always the same: the PEI code is linked to execute
> > in place from flash bank #0, and the fixed varstore PCDs refer to
> > flash bank #1 directly.
> >
> > However, ArmVirtQemuKernel can execute at any offset, and flash bank
> > In this case, NorFlashQemuLib should not expose the first flash bank
> > at all.
> >
> > To prevent introducing too much internal knowledge about which flash
> > bank is accessible under which circumstances, let's switch to using
> > the DTB to decide which flash banks to expose to the NOR flash driver.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel
> > ---
> > ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c | 84
> > +++-
> > ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf | 12 +++
> > 2 files changed, 75 insertions(+), 21 deletions(-)
> >
> > diff --git a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> > b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> > index e3bbae5b06c5..dc0a15e77170 100644
> > --- a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> > +++ b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> > @@ -1,6 +1,6 @@
> > /** @file
> >
> > - Copyright (c) 2014, Linaro Ltd. All rights reserved.
> > + Copyright (c) 2014-2018, Linaro Ltd. All rights reserved.
> >
> > This program and the accompanying materials
> > are licensed and made available under the terms and conditions of the BSD
> > License
> > @@ -12,13 +12,16 @@
> >
> > **/
> >
> > +#include
> > +#include
> > #include
> > +#include
> > +
> > +#include
> >
> > #define QEMU_NOR_BLOCK_SIZESIZE_256KB
> > -#define QEMU_NOR0_BASE 0x0
> > -#define QEMU_NOR0_SIZE SIZE_64MB
> > -#define QEMU_NOR1_BASE 0x0400
> > -#define QEMU_NOR1_SIZE SIZE_64MB
> > +
> > +#define MAX_FLASH_BANKS4
> >
> > EFI_STATUS
> > NorFlashPlatformInitialization (
> > @@ -28,21 +31,7 @@ NorFlashPlatformInitialization (
> >return EFI_SUCCESS;
> > }
> >
> > -NOR_FLASH_DESCRIPTION mNorFlashDevices[] = {
> > - {
> > -QEMU_NOR0_BASE,
> > -QEMU_NOR0_BASE,
> > -QEMU_NOR0_SIZE,
> > -QEMU_NOR_BLOCK_SIZE,
> > -{0xF9B94AE2, 0x8BA6, 0x409B, {0x9D, 0x56, 0xB9, 0xB4, 0x17, 0xF5,
> > 0x3C, 0xB3}}
> > - }, {
> > -QEMU_NOR1_BASE,
> > -QEMU_NOR1_BASE,
> > -QEMU_NOR1_SIZE,
> > -QEMU_NOR_BLOCK_SIZE,
> > -{0x8047DB4B, 0x7E9C, 0x4C0C, {0x8E, 0xBC, 0xDF, 0xBB, 0xAA, 0xCA,
> > 0xCE, 0x8F}}
> > - }
> > -};
> > +NOR_FLASH_DESCRIPTION mNorFlashDevices[MAX_FLASH_BANKS];
> >
> > EFI_STATUS
> > NorFlashPlatformGetDevices (
> > @@ -50,7 +39,60 @@ NorFlashPlatformGetDevices (
> >OUT UINT32 *Count
> >)
> > {
> > + FDT_CLIENT_PROTOCOL *FdtClient;
> > + INT32 Node;
> > + EFI_STATUS Status;
> > + EFI_STATUS FindNodeStatus;
> > + CONST UINT64*Reg;
> > + UINT32 RegSize;
> > + CONST CHAR8 *NodeStatus;
> > + UINTN Num;
> > +
> > + Status = gBS->LocateProtocol (&gFdtClientProtocolGuid, NULL,
> > + (VOID **)&FdtClient);
> > + ASSERT_EFI_ERROR (Status);
> > +
> > + Num = 0;
> > + for (FindNodeStatus = FdtClient->FindCompatibleNode (FdtClient,
> > + "cfi-flash", &Node);
> > + !EFI_ERROR (FindNodeStatus);
> > + FindNodeStatus = FdtClient->FindNextCompatibleNode (FdtClient,
> > + "cfi-flash", Node, &Node)) {
> > +
> > +Status = FdtClient->GetNodeProperty (FdtClient, Node, "status",
> > + (CONST VOID **)&NodeStatus, NULL);
> > +if (!EFI_ERROR (Status) && AsciiStrnCmp (NodeStatus, "ok", 2) != 0) {
> > + continue;
> > +}
>
> (1) Do you intend to silently continue if the "status" property is missing?
>
Yes. Absent implies 'ok'
> (2) Assuming the "status" property exists, I think we could improve the
> comparison against "ok". Can you allow GetNodeProperty() to output
> PropSize as well? And then,
>
> if (!EFI_ERROR (Status) &&
> AsciiStrnCmp (NodeStatus, "ok", PropSize) != 0) {
> continue;
> }
>
> Because, if the status property is guaranteed to be NUL-terminated, then
> we don't need AsciiStrnCmp(), we can use AsciiStrCmp() -- because both
> strings are NUL-terminated. Or else, if we want to be careful about the
> property (yes, we should be), then we should pass PropSize to
> AsciiStrnCmp(). (Or maybe PropSize-1, dependent on libfdt...)
>
> Either way it bothers me that in theory, the status property can be
> shorter than 2 char
[edk2] [PATCH v2 1/2] MdeModulePkg/SdMmcPciHcDxe: Declare V4 64 bit address capability
Add capability declaration for V4.x 64 bit system address support.
This would be used for host controllers working in version 4. Enable
64 bit DMA support in PCI layer if V3 or V4 64 bit support is
enabled in host capability register.
The usage of this new field does not need a guard for version check as
spec for previous SDMMC versions defines this field as reserved with
default value of 0.
Change-Id: I64fcb674ec566c46a37ea6597ae06cb194625cae
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ashish Singhal
---
MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 4 ++--
MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 3 ++-
MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h | 10 +-
3 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
index bf9869d..1c18ea4 100644
--- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
+++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
@@ -617,7 +617,6 @@ SdMmcPciHcDriverBindingStart (
}
}
- Support64BitDma = TRUE;
for (Slot = FirstBar; Slot < (FirstBar + SlotNum); Slot++) {
Private->Slot[Slot].Enable = TRUE;
@@ -638,7 +637,8 @@ SdMmcPciHcDriverBindingStart (
}
DumpCapabilityReg (Slot, &Private->Capability[Slot]);
-Support64BitDma &= Private->Capability[Slot].SysBus64;
+Support64BitDma = (Private->Capability[Slot].SysBus64V3 |
+ Private->Capability[Slot].SysBus64V4);
Status = SdMmcHcGetMaxCurrent (PciIo, Slot, &Private->MaxCurrent[Slot]);
if (EFI_ERROR (Status)) {
diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
index bedc968..e506875 100644
--- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
+++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
@@ -45,7 +45,8 @@ DumpCapabilityReg (
DEBUG ((DEBUG_INFO, " Voltage 3.3 %a\n", Capability->Voltage33 ?
"TRUE" : "FALSE"));
DEBUG ((DEBUG_INFO, " Voltage 3.0 %a\n", Capability->Voltage30 ?
"TRUE" : "FALSE"));
DEBUG ((DEBUG_INFO, " Voltage 1.8 %a\n", Capability->Voltage18 ?
"TRUE" : "FALSE"));
- DEBUG ((DEBUG_INFO, " 64-bit Sys Bus%a\n", Capability->SysBus64 ?
"TRUE" : "FALSE"));
+ DEBUG ((DEBUG_INFO, " V4 64-bit Sys Bus %a\n", Capability->SysBus64V4 ?
"TRUE" : "FALSE"));
+ DEBUG ((DEBUG_INFO, " V3 64-bit Sys Bus %a\n", Capability->SysBus64V3 ?
"TRUE" : "FALSE"));
DEBUG ((DEBUG_INFO, " Async Interrupt %a\n", Capability->AsyncInt ?
"TRUE" : "FALSE"));
DEBUG ((DEBUG_INFO, " SlotType "));
if (Capability->SlotType == 0x00) {
diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h
b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h
index 7e3f588..cc138fc 100644
--- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h
+++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h
@@ -114,24 +114,24 @@ typedef struct {
UINT32 Voltage33:1; // bit 24
UINT32 Voltage30:1; // bit 25
UINT32 Voltage18:1; // bit 26
- UINT32 Reserved3:1; // bit 27
- UINT32 SysBus64:1;// bit 28
+ UINT32 SysBus64V4:1; // bit 27
+ UINT32 SysBus64V3:1; // bit 28
UINT32 AsyncInt:1;// bit 29
UINT32 SlotType:2;// bit 30:31
UINT32 Sdr50:1; // bit 32
UINT32 Sdr104:1; // bit 33
UINT32 Ddr50:1; // bit 34
- UINT32 Reserved4:1; // bit 35
+ UINT32 Reserved3:1; // bit 35
UINT32 DriverTypeA:1; // bit 36
UINT32 DriverTypeC:1; // bit 37
UINT32 DriverTypeD:1; // bit 38
UINT32 DriverType4:1; // bit 39
UINT32 TimerCount:4; // bit 40:43
- UINT32 Reserved5:1; // bit 44
+ UINT32 Reserved4:1; // bit 44
UINT32 TuningSDR50:1; // bit 45
UINT32 RetuningMod:2; // bit 46:47
UINT32 ClkMultiplier:8; // bit 48:55
- UINT32 Reserved6:7; // bit 56:62
+ UINT32 Reserved5:7; // bit 56:62
UINT32 Hs400:1; // bit 63
} SD_MMC_HC_SLOT_CAP;
--
2.7.4
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2 2/2] MdeModulePkg/SdMmcPciHcDxe: Add V4 64bit SDMA and ADMA2 support.
If V4 64 bit address mode is enabled in compatibility register,
program controller to enable V4 host mode.
Use appropriate ADMA2 descriptors supporting 64 bit addresses.
Use appropriate registers for SDMA mode operation.
Change-Id: I1f6c984368988e51999eb289aa29677f9b0cdf49
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ashish Singhal
---
MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 4 +-
MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 273 +
MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h | 28 ++-
3 files changed, 260 insertions(+), 45 deletions(-)
diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
index c683600..22795df 100644
--- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
+++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
@@ -2,6 +2,7 @@
Provides some data structure definitions used by the SD/MMC host controller
driver.
+Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
Copyright (c) 2015, 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
@@ -144,7 +145,8 @@ typedef struct {
BOOLEAN Started;
UINT64 Timeout;
- SD_MMC_HC_ADMA_DESC_LINE*AdmaDesc;
+ SD_MMC_HC_ADMA_32_DESC_LINE *Adma32Desc;
+ SD_MMC_HC_ADMA_64_DESC_LINE *Adma64Desc;
EFI_PHYSICAL_ADDRESSAdmaDescPhy;
VOID*AdmaMap;
UINT32 AdmaPages;
diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
index e506875..9fef3fb 100644
--- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
+++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
@@ -4,6 +4,7 @@
It would expose EFI_SD_MMC_PASS_THRU_PROTOCOL for upper layer use.
+ Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
Copyright (c) 2015 - 2017, 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
@@ -418,6 +419,36 @@ SdMmcHcWaitMmioSet (
}
/**
+ Get the controller version information from the specified slot.
+
+ @param[in] PciIo The PCI IO protocol instance.
+ @param[in] SlotThe slot number of the SD card to send the
command to.
+ @param[out] Version The buffer to store the version information.
+
+ @retval EFI_SUCCESS The operation executes successfully.
+ @retval Others The operation fails.
+
+**/
+EFI_STATUS
+SdMmcHcGetControllerVersion (
+ IN EFI_PCI_IO_PROTOCOL *PciIo,
+ IN UINT8Slot,
+ OUT UINT16 *Version
+ )
+{
+ EFI_STATUSStatus;
+
+ Status = SdMmcHcRwMmio (PciIo, Slot, SD_MMC_HC_CTRL_VER, TRUE, sizeof
(UINT16), Version);
+ if (EFI_ERROR (Status)) {
+return Status;
+ }
+
+ *Version &= 0xFF;
+
+ return EFI_SUCCESS;
+}
+
+/**
Software reset the specified SD/MMC host controller and enable all
interrupts.
@param[in] PrivateA pointer to the SD_MMC_HC_PRIVATE_DATA instance.
@@ -776,18 +807,18 @@ SdMmcHcClockSupply (
DEBUG ((DEBUG_INFO, "BaseClkFreq %dMHz Divisor %d ClockFreq %dKhz\n",
BaseClkFreq, Divisor, ClockFreq));
- Status = SdMmcHcRwMmio (PciIo, Slot, SD_MMC_HC_CTRL_VER, TRUE, sizeof
(ControllerVer), &ControllerVer);
+ Status = SdMmcHcGetControllerVersion (PciIo, Slot, &ControllerVer);
if (EFI_ERROR (Status)) {
return Status;
}
//
// Set SDCLK Frequency Select and Internal Clock Enable fields in Clock
Control register.
//
- if (((ControllerVer & 0xFF) >= SD_MMC_HC_CTRL_VER_300) &&
- ((ControllerVer & 0xFF) <= SD_MMC_HC_CTRL_VER_420)) {
+ if ((ControllerVer >= SD_MMC_HC_CTRL_VER_300) &&
+ (ControllerVer <= SD_MMC_HC_CTRL_VER_420)) {
ASSERT (Divisor <= 0x3FF);
ClockCtrl = ((Divisor & 0xFF) << 8) | ((Divisor & 0x300) >> 2);
- } else if (((ControllerVer & 0xFF) == 0) || ((ControllerVer & 0xFF) == 1)) {
+ } else if ((ControllerVer == 0) || (ControllerVer == 1)) {
//
// Only the most significant bit can be used as divisor.
//
@@ -935,6 +966,54 @@ SdMmcHcSetBusWidth (
}
/**
+ Configure V4 64 bit system address support at initialization.
+
+ @param[in] PciIo The PCI IO protocol instance.
+ @param[in] Slot The slot number of the SD card to send the command
to.
+ @param[in] Capability The capability of the slot.
+
+ @retval EFI_SUCCESS The clock is supplied successfully.
+
+**/
+EFI_STATUS
+SdMmcHcV4Init64BitSupport (
+ IN EFI_PCI_IO_PROTOCOL*PciIo,
+ IN UINT8 Slot,
+ IN SD_MMC_HC_SLOT_CAP Capability
+ )
+{
+ EFI_STATUSStatus;
+ UINT16
Re: [edk2] [PATCH 2/2] MdeModulePkg/SdMmcPciHcDxe: Add V4 64bit ADMA2 support.
Hi,
I was planning on submitting SDMA changes as a separate patch but that would
have broken SDMA if only ADMA2 patch would have been picked. I have sent V2
patches which combine SDMA as well as ADMA2 changes. I have tested the changes
to be working on V3 as well V4 mode usage both with and without enabling 64b
addressing support.
Thanks
Ashish
-Original Message-
From: Wu, Hao A
Sent: Friday, November 16, 2018 1:27 AM
To: Ashish Singhal ; edk2-devel@lists.01.org
Subject: RE: [edk2] [PATCH 2/2] MdeModulePkg/SdMmcPciHcDxe: Add V4 64bit ADMA2
support.
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ashish Singhal
> Sent: Friday, November 09, 2018 2:58 AM
> To: edk2-devel@lists.01.org
> Cc: Ashish Singhal
> Subject: [edk2] [PATCH 2/2] MdeModulePkg/SdMmcPciHcDxe: Add V4 64bit
> ADMA2 support.
>
> If V4 64 bit address mode is enabled in compatibility register,
> program controller to enable V4 host mode and use appropriate ADMA
> descriptors supporting 64 bit addresses.
Hi,
I have a quick check on the SD Host Controller Simplified Specification Version
4.20. When the 'Host Version 4 Enable' bit in the HC2 Register is set, for host
controller with version newer than 3.0:
SDMA mode transfer no longer use SDMA System Address Register for system
address, and this SDMA System Address Register will be used as 32-bit Block
Count instead under certain case.
So I think the way to start an SDMA mode transfer is not the same between host
controllers with different versions. However, I do not see this patch handle
this potential behavior change. Please correct me if my understanding is
incorrect here.
Also, could you help to provide information on what tests have been performed
on this series?
Thanks in advance.
Best Regards,
Hao Wu
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ashish Singhal
> ---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 4 +-
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 183
> +
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h | 28 +++-
> 3 files changed, 183 insertions(+), 32 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> index c683600..22795df 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> @@ -2,6 +2,7 @@
>
>Provides some data structure definitions used by the SD/MMC host
> controller driver.
>
> +Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> Copyright (c) 2015, 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 @@ -144,7
> +145,8 @@ typedef struct {
>BOOLEAN Started;
>UINT64 Timeout;
>
> - SD_MMC_HC_ADMA_DESC_LINE*AdmaDesc;
> + SD_MMC_HC_ADMA_32_DESC_LINE *Adma32Desc;
> + SD_MMC_HC_ADMA_64_DESC_LINE *Adma64Desc;
>EFI_PHYSICAL_ADDRESSAdmaDescPhy;
>VOID*AdmaMap;
>UINT32 AdmaPages;
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> index e506875..bcd2707 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> @@ -4,6 +4,7 @@
>
>It would expose EFI_SD_MMC_PASS_THRU_PROTOCOL for upper layer use.
>
> + Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
>Copyright (c) 2015 - 2017, 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 @@ -418,6 +419,36 @@ SdMmcHcWaitMmioSet ( }
>
> /**
> + Get the controller version information from the specified slot.
> +
> + @param[in] PciIo The PCI IO protocol instance.
> + @param[in] SlotThe slot number of the SD card to send the
> command to.
> + @param[out] Version The buffer to store the version information.
> +
> + @retval EFI_SUCCESS The operation executes successfully.
> + @retval Others The operation fails.
> +
> +**/
> +EFI_STATUS
> +SdMmcHcGetControllerVersion (
> + IN EFI_PCI_IO_PROTOCOL *PciIo,
> + IN UINT8Slot,
> + OUT UINT16 *Version
> + )
> +{
> + EFI_STATUSStatus;
> +
> + Status = SdMmcHcRwMmio (PciIo, Slot, SD_MMC_HC_CTRL_VER, TRUE,
> sizeof (UINT16), Version);
> + if (EFI_ERROR (Status)) {
> +return Status;
> + }
> +
> + *Version &= 0xFF;
> +
> + return EFI_SUCCESS;
> +}
> +
> +/**
>Software reset the specified SD/MMC host controller and enable all
> interrupts.
>
>
Re: [edk2] [edk2-announce] December Community Meeting
Ops, mea culpa. Updated to reflect "APAC/NAMO" in the link. Good catch, thank you! Cheers, Stephano On 11/19/2018 12:23 PM, Laszlo Ersek wrote: Hi Stephano, On 11/15/18 22:06, stephano wrote: We will be holding monthly community meetings starting in December on the first Thursday of the month. Details for the next meeting are here: https://github.com/tianocore/tianocore.github.io/wiki/Community-Virtual-Meetings the second ICS link in the article says "Asia Pacific / Europe Meeting" on the tin, but inside, it references "TianoCore-December-Community-Meeting-APAC-NAMO.ics". Thus, "APAC" is fine, but "Europe" should be replaced with "North America", IMO. Thanks! Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] EmulatorPkg Unix Host Segmentation fault.
> On Nov 19, 2018, at 11:16 AM, Jordan Justen wrote:
>
> On 2018-11-18 17:13:21, Jordan Justen wrote:
>> On 2018-11-18 14:37:09, Andrew Fish wrote:
>>>
>>>
On Nov 18, 2018, at 4:07 AM, Liu Yu wrote:
sorry your path can't fix this issue. if this path just turn off
optimization option within sec.c not global project.
I have tested different version GCC such as (GCC4,8, GCC5.x, GCC7.x)
and all of them can duplicate this issue (Ubuntu 16.04, 16.10,18.04 )
I have traced this issue on my hand.
you can see Dispatcher.c (MdeModulePkg/Pei/DIspatcher/) Line 792:
790 if (StackOffsetPositive) {
791 SecCoreData = (CONST EFI_SEC_PEI_HAND_OFF *)((UINTN)(VOID
*)SecCoreData + StackOffset);
792 Private = (PEI_CORE_INSTANCE *)((UINTN)(VOID *)Private +
StackOffset);
793 } else {
794 ..
795 ..
796}
790 --792 disassembly code
0x10200f2ca :test %r14b,%r14b
0x10200f2cd :je 0x10200f2df
0x10200f2cf :mov 0x38(%rsp),%rax
0x10200f2d4 :lea 0x0(%rbp,%rax,1),%r14
0x10200f2d9 :lea (%rbx,%rax,1),%rbp
we can see Private value have been stored in %rbp (rbp register be
used as general register ) so when call
TemporaryRamSupportPpi->TemporaryRamMigration()
>>>
>>> The calling conventions define RBP as non-volatile must be preserved
>>> by callee. Using RBP as the frame pointer is optional.
>>
>> This is kind of a mess. I think the definition of
>> EFI_PEI_TEMPORARY_RAM_SUPPORT_PPI is really to blame. It probably
>> should not have been spec'd as 'change stack and return'. Instead, it
>> should have been given a new function pointer to switch-stack and call
>> into.
>
> Andrew, Mike,
>
> I developed a PEI Core fix for this issue, which Liu Yu verified.
>
> Unfortunately, it involves add assembly code in a key area of the PEI
> Core. See the top 2 commits of:
>
> https://github.com/jljusten/edk2/commits/emulator-temp-ram
>
>
> I only wrote assembly for X64 nasm. But, I notice that neither the PEI
> or DXE Core modules include any assembly code. So, I want to make sure
> I'm heading in the right direction before working on it further.
>
Mike,
I seem to remember we hit an issue like this a long time ago? Do you remember
the details? Maybe it was we needed to write the TempRamSupport code in
assembly?
The issue we are hitting is the gEfiTemporaryRamSupportPpiGuid
TemporaryRamMigration() function call does a stack switch, but it returns. This
causes an issue with the C calling conventions as RBP is optionally a frame
pointer. To quote the MSFT spec: "May be used as a frame pointer; must be
preserved by callee"
1) It is used as a frame pointer. It looks like our existing code fixes up the
frame pointer to match the new location the stack got moved to.
2) Used as a general purpose register, and the value must be preserved.
> As I mentioned below, I think PIWG could consider an new
> TemporarayRemSupport interface that might work better, but that also
> may not be worth the effort.
If the current API is not really portable I don;t think it is a bad idea to
update it.
>
> Can something like this change be integrated into the PEI Core?
Jordan,
I'm not sure? For the RBP == frame pointer case the frame pointer is no longer
valid (it is in temp RAM, not DRAM). It seems like the point of
SecTemporaryRamSupport() fixing up the callers RBP is for the benefit of the
caller. It looks to me like your fix is just negating that fixup. So that would
imply that either we could just fix this in SecTemporaryRamSupport() or we have
2 code gen paths and we need to know how the compiler is using RBP to "do the
right thing"
Do we have other code that supports X64 PEI? Is see OvmfPkg
https://github.com/tianocore/edk2/blob/master/OvmfPkg/Sec/SecMain.c#L875
Looks like OvmfPkg uses SetJump()/LongJump() to change the stack.
//
// Use SetJump()/LongJump() to switch to a new stack.
//
if (SetJump (&JumpBuffer) == 0) {
#if defined (MDE_CPU_IA32)
JumpBuffer.Esp = JumpBuffer.Esp + DebugAgentContext.StackMigrateOffset;
JumpBuffer.Ebp = JumpBuffer.Ebp + DebugAgentContext.StackMigrateOffset;
#endif
#if defined (MDE_CPU_X64)
JumpBuffer.Rsp = JumpBuffer.Rsp + DebugAgentContext.StackMigrateOffset;
JumpBuffer.Rbp = JumpBuffer.Rbp + DebugAgentContext.StackMigrateOffset;
#endif
LongJump (&JumpBuffer, (UINTN)-1);
}
SaveAndSetDebugTimerInterrupt (OldStatus);
return EFI_SUCCESS;
}
But given the above code is C code RBP is going to be restored on return. This
would seem to imply that the adjusting of the callers RBP is not required? So
maybe try changing over Emulator to the OvmfPkg TemporaryRamMigration()
algorithm?
Thanks,
Andrew Fish
>
> Thanks for your time
Re: [edk2] [edk2-wiki PATCH v2] release planning: announce the soft and hard feature freezes
On 11/14/18 01:06, Gao, Liming wrote:
> Reviewed-by: Liming Gao
Thank you, pushed as commit 8e311ba71992.
Laszlo
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Laszlo Ersek
>> Sent: Tuesday, November 13, 2018 11:30 PM
>> To: edk2-devel@lists.01.org
>> Cc: Cetola, Stephano ; Richardson, Brian
>> ; Gao, Liming ; Kinney,
>> Michael D
>> Subject: [edk2] [edk2-wiki PATCH v2] release planning: announce the soft and
>> hard feature freezes
>>
>> Add a paragraph to each of the SoftFeatureFreeze and HardFeatureFreeze
>> articles about the respective announcements on edk2-devel.
>>
>> Cc: Andrew Fish
>> Cc: Brian Richardson
>> Cc: Leif Lindholm
>> Cc: Liming Gao
>> Cc: Michael Kinney
>> Cc: Stephano Cetola
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Laszlo Ersek
>> ---
>>
>> Notes:
>>v2:
>>- with Liming's edk2 commit da2c81ee96eb ("Maintainers.txt: Update EDK
>> II Releases to EDK-II-Release-Planning wiki", 2018-11-12) up-stream,
>> identify the announcer via "Maintainers.txt" [Mike]
>>
>>v1:
>>- Check out the rendered pages in my clone of the wiki:
>> - https://github.com/lersek/edk2/wiki/SoftFeatureFreeze
>> - https://github.com/lersek/edk2/wiki/HardFeatureFreeze
>>
>> HardFeatureFreeze.md | 10 ++
>> SoftFeatureFreeze.md | 10 ++
>> 2 files changed, 20 insertions(+)
>>
>> diff --git a/HardFeatureFreeze.md b/HardFeatureFreeze.md
>> index 01288dd03f71..dae9f664b5d9 100644
>> --- a/HardFeatureFreeze.md
>> +++ b/HardFeatureFreeze.md
>> @@ -4,3 +4,13 @@ tag](EDK-II#stable-tags).
>>
>> (This definition is modeled after QEMU's [hard feature
>> freeze](https://wiki.qemu.org/Planning/HardFeatureFreeze)).
>> +
>> +# Announcing the hard feature freeze
>> +
>> +The proposed schedule for the active development cycle is shown in the
>> [EDK II
>> +Release Planning](EDK-II-Release-Planning) article. Shortly before the hard
>> +feature freeze, an announcement email is sent to the
>> +[edk2-devel](https://lists.01.org/mailman/listinfo/edk2-devel) mailing list.
>> +The announcement is posted by one of the maintainers that are listed in
>> +[Maintainers.txt](https://github.com/tianocore/edk2/blob/master/Maintain
>> ers.txt),
>> +in section `EDK II Releases`.
>> diff --git a/SoftFeatureFreeze.md b/SoftFeatureFreeze.md
>> index 9dc7d9c19369..9047a73c1d69 100644
>> --- a/SoftFeatureFreeze.md
>> +++ b/SoftFeatureFreeze.md
>> @@ -40,3 +40,13 @@ communicate with the maintainer about their intentions.
>> It also helps if you:
>>
>> (This definition is modeled after QEMU's [soft feature
>> freeze](https://wiki.qemu.org/Planning/SoftFeatureFreeze).)
>> +
>> +# Announcing the soft feature freeze
>> +
>> +The proposed schedule for the active development cycle is shown in the
>> [EDK II
>> +Release Planning](EDK-II-Release-Planning) article. Shortly before the soft
>> +feature freeze, an announcement email is sent to the
>> +[edk2-devel](https://lists.01.org/mailman/listinfo/edk2-devel) mailing list.
>> +The announcement is posted by one of the maintainers that are listed in
>> +[Maintainers.txt](https://github.com/tianocore/edk2/blob/master/Maintain
>> ers.txt),
>> +in section `EDK II Releases`.
>> --
>> 2.19.1.3.g30247aa5d201
>>
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] EmulatorPkg Unix Host Segmentation fault.
Jordan wrote:
>>> So, is it safe to adjust rbp? Unknown. It may not be if rbp is not
>>> used as a frame pointer. Is it safe to *not* adjust rbp and
>>> potentially allow the old temp ram stack to be used? Unknown.
Andrew wrote:
> Looks like OvmfPkg uses SetJump()/LongJump() to change the stack.
>
> //
> // Use SetJump()/LongJump() to switch to a new stack.
> //
> if (SetJump (&JumpBuffer) == 0) {
> #if defined (MDE_CPU_IA32)
> JumpBuffer.Esp = JumpBuffer.Esp + DebugAgentContext.StackMigrateOffset;
> JumpBuffer.Ebp = JumpBuffer.Ebp + DebugAgentContext.StackMigrateOffset;
> #endif
> #if defined (MDE_CPU_X64)
> JumpBuffer.Rsp = JumpBuffer.Rsp + DebugAgentContext.StackMigrateOffset;
> JumpBuffer.Rbp = JumpBuffer.Rbp + DebugAgentContext.StackMigrateOffset;
> #endif
> LongJump (&JumpBuffer, (UINTN)-1);
> }
>
> SaveAndSetDebugTimerInterrupt (OldStatus);
>
> return EFI_SUCCESS;
> }
>
> But given the above code is C code RBP is going to be restored on return.
> This would seem to imply that the adjusting of the callers RBP is not
> required? [...]
The Ebp/Rbp assignments were added in a separate bugfix, namely
https://github.com/tianocore/edk2/commit/89796c69d9fd
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] EmulatorPkg Unix Host Segmentation fault.
On 2018-11-19 13:22:27, Andrew Fish wrote:
>
>
> > On Nov 19, 2018, at 11:16 AM, Jordan Justen
> > wrote:
> >
> > On 2018-11-18 17:13:21, Jordan Justen wrote:
> >> On 2018-11-18 14:37:09, Andrew Fish wrote:
> >>>
> >>>
> On Nov 18, 2018, at 4:07 AM, Liu Yu wrote:
>
> sorry your path can't fix this issue. if this path just turn off
> optimization option within sec.c not global project.
>
> I have tested different version GCC such as (GCC4,8, GCC5.x, GCC7.x)
> and all of them can duplicate this issue (Ubuntu 16.04, 16.10,18.04 )
>
> I have traced this issue on my hand.
>
> you can see Dispatcher.c (MdeModulePkg/Pei/DIspatcher/) Line 792:
>
>
> 790 if (StackOffsetPositive) {
> 791 SecCoreData = (CONST EFI_SEC_PEI_HAND_OFF *)((UINTN)(VOID
> *)SecCoreData + StackOffset);
> 792 Private = (PEI_CORE_INSTANCE *)((UINTN)(VOID *)Private +
> StackOffset);
> 793 } else {
> 794 ..
> 795 ..
> 796}
>
> 790 --792 disassembly code
>
> 0x10200f2ca :test %r14b,%r14b
> 0x10200f2cd :je 0x10200f2df
>
> 0x10200f2cf :mov 0x38(%rsp),%rax
> 0x10200f2d4 :lea 0x0(%rbp,%rax,1),%r14
> 0x10200f2d9 :lea (%rbx,%rax,1),%rbp
>
> we can see Private value have been stored in %rbp (rbp register be
> used as general register ) so when call
> TemporaryRamSupportPpi->TemporaryRamMigration()
>
> >>>
> >>> The calling conventions define RBP as non-volatile must be preserved
> >>> by callee. Using RBP as the frame pointer is optional.
> >>
> >> This is kind of a mess. I think the definition of
> >> EFI_PEI_TEMPORARY_RAM_SUPPORT_PPI is really to blame. It probably
> >> should not have been spec'd as 'change stack and return'. Instead, it
> >> should have been given a new function pointer to switch-stack and call
> >> into.
> >
> > Andrew, Mike,
> >
> > I developed a PEI Core fix for this issue, which Liu Yu verified.
> >
> > Unfortunately, it involves add assembly code in a key area of the PEI
> > Core. See the top 2 commits of:
> >
> > https://github.com/jljusten/edk2/commits/emulator-temp-ram
> >
> >
> > I only wrote assembly for X64 nasm. But, I notice that neither the PEI
> > or DXE Core modules include any assembly code. So, I want to make sure
> > I'm heading in the right direction before working on it further.
> >
>
> Mike,
>
> I seem to remember we hit an issue like this a long time ago? Do you
> remember the details? Maybe it was we needed to write the
> TempRamSupport code in assembly?
It does also creep up there, which is why we also adjust ebp/rbp in
the TemporaryRamMigration function in OVMF.
In that case, it helps prevent the stack from reverting to the old
stack when TemporaryRamMigration is returning to it's caller. (As
opposed to after it returns, which I think is what is happening now.)
> The issue we are hitting is the gEfiTemporaryRamSupportPpiGuid
> TemporaryRamMigration() function call does a stack switch, but it
> returns. This causes an issue with the C calling conventions as RBP
> is optionally a frame pointer. To quote the MSFT spec: "May be used
> as a frame pointer; must be preserved by callee"
> 1) It is used as a frame pointer. It looks like our existing code
> fixes up the frame pointer to match the new location the stack got
> moved to.
> 2) Used as a general purpose register, and the value must be
> preserved.
This is true, and I think it makes writing TemporaryRamMigration in C
unsafe. Nevertheless, we've been doing that in OVMF for a while now.
>
> > As I mentioned below, I think PIWG could consider an new
> > TemporarayRemSupport interface that might work better, but that also
> > may not be worth the effort.
>
> If the current API is not really portable I don;t think it is a bad
> idea to update it.
The trickier part is that the C ABI doesn't cover exactly how the
stack may be used after the call to TemporaryRamMigration returns. For
example, there's no reason that the compiler couldn't have saved the
stack pointer onto the stack (which was migrated) and somehow restore
it to an old value from the migrated stack.
I think the only safe way to implement calling the current
TemporaryRamMigration is by using assembly code, and then calling into
a new function from the assembly code. Once we call into a new C
function, there is no way C code-gen can accidentally restore the old
stack pointer.
> >
> > Can something like this change be integrated into the PEI Core?
>
> Jordan,
>
> I'm not sure?
Part of my question was whether assembly code was allowed in the PEI
Core.
> For the RBP == frame pointer case the frame pointer is
> no longer valid (it is in temp RAM, not DRAM). It seems like the
> point of SecTemporaryRamSupport() fixing up the callers RBP is for
Re: [edk2] EmulatorPkg Unix Host Segmentation fault.
> On Nov 19, 2018, at 2:12 PM, Laszlo Ersek wrote:
>
> Jordan wrote:
>
So, is it safe to adjust rbp? Unknown. It may not be if rbp is not
used as a frame pointer. Is it safe to *not* adjust rbp and
potentially allow the old temp ram stack to be used? Unknown.
>
> Andrew wrote:
>
>> Looks like OvmfPkg uses SetJump()/LongJump() to change the stack.
>>
>> //
>> // Use SetJump()/LongJump() to switch to a new stack.
>> //
>> if (SetJump (&JumpBuffer) == 0) {
>> #if defined (MDE_CPU_IA32)
>>JumpBuffer.Esp = JumpBuffer.Esp + DebugAgentContext.StackMigrateOffset;
>>JumpBuffer.Ebp = JumpBuffer.Ebp + DebugAgentContext.StackMigrateOffset;
>> #endif
>> #if defined (MDE_CPU_X64)
>>JumpBuffer.Rsp = JumpBuffer.Rsp + DebugAgentContext.StackMigrateOffset;
>>JumpBuffer.Rbp = JumpBuffer.Rbp + DebugAgentContext.StackMigrateOffset;
>> #endif
>>LongJump (&JumpBuffer, (UINTN)-1);
>> }
>>
>> SaveAndSetDebugTimerInterrupt (OldStatus);
>>
>> return EFI_SUCCESS;
>> }
>>
>> But given the above code is C code RBP is going to be restored on return.
>> This would seem to imply that the adjusting of the callers RBP is not
>> required? [...]
>
> The Ebp/Rbp assignments were added in a separate bugfix, namely
>
> https://github.com/tianocore/edk2/commit/89796c69d9fd
>
Laszlo,
This makes sense since as the post-amble when using frame pointers is either:
addq$288, %rsp ## imm = 0x120
popq%rbp
retq
or
>0xfffcd42f <+403>: c9 leaveq
>0xfffcd430 <+404>: c3 retq
I've noticed that clang does not seem to be a big fan of the leave function and
it adjusts the stack pointer using math rather than using %rbp.
The stack unwind algorithm implies that the frame point, %rbp in our case, is
valid while the function is running. Even for the clang code gen not switching
the frame point would break the stack unwind.
Thanks,
Andrew Fish
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] BaseTools: Fix the problem using FILE_GUID override in .dsc
Reviewed-by: Liming Gao
>-Original Message-
>From: Feng, Bob C
>Sent: Friday, November 16, 2018 10:12 AM
>To: edk2-devel@lists.01.org
>Cc: Gao, Liming ; Carsey, Jaben
>
>Subject: [Patch] BaseTools: Fix the problem using FILE_GUID override in .dsc
>
>https://bugzilla.tianocore.org/show_bug.cgi?id=1330
>
>This patch is going to fix the problem using FILE_GUID override in .dsc.
>
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: BobCF
>Cc: Liming Gao
>Cc: Jaben Carsey
>---
> BaseTools/Source/Python/GenFds/FdfParser.py | 18 +-
> 1 file changed, 13 insertions(+), 5 deletions(-)
>
>diff --git a/BaseTools/Source/Python/GenFds/FdfParser.py
>b/BaseTools/Source/Python/GenFds/FdfParser.py
>index 44cc8f63d0..2fbbad114c 100644
>--- a/BaseTools/Source/Python/GenFds/FdfParser.py
>+++ b/BaseTools/Source/Python/GenFds/FdfParser.py
>@@ -22,11 +22,11 @@ from re import compile, DOTALL
> from string import hexdigits
> from uuid import UUID
>
> from Common.BuildToolError import *
> from Common import EdkLogger
>-from Common.Misc import PathClass, tdict
>+from Common.Misc import PathClass, tdict, ProcessDuplicatedInf
> from Common.StringUtils import NormPath, ReplaceMacro
> from Common import GlobalData
> from Common.Expression import *
> from Common.DataType import *
> from Common.MultipleWorkspace import MultipleWorkspace as mws
>@@ -2414,12 +2414,16 @@ class FdfParser:
> #do case sensitive check for file path
> ErrorCode, ErrorInfo = PathClass(NormPath(ffsInf.InfFileName),
>GenFdsGlobalVariable.WorkSpaceDir).Validate()
> if ErrorCode != 0:
> EdkLogger.error("GenFds", ErrorCode, ExtraData=ErrorInfo)
>
>-if not ffsInf.InfFileName in self.Profile.InfList:
>-self.Profile.InfList.append(ffsInf.InfFileName)
>+NewFileName = ffsInf.InfFileName
>+if ffsInf.OverrideGuid:
>+NewFileName =
>ProcessDuplicatedInf(PathClass(ffsInf.InfFileName,GenFdsGlobalVariable.Wo
>rkSpaceDir), ffsInf.OverrideGuid, GenFdsGlobalVariable.WorkSpaceDir).Path
>+
>+if not NewFileName in self.Profile.InfList:
>+self.Profile.InfList.append(NewFileName)
> FileLineTuple = GetRealFileLine(self.FileName,
> self.CurrentLineNumber)
> self.Profile.InfFileLineList.append(FileLineTuple)
> if ffsInf.UseArch:
> if ffsInf.UseArch not in self.Profile.InfDict:
> self.Profile.InfDict[ffsInf.UseArch] =
> [ffsInf.InfFileName]
>@@ -4344,12 +4348,16 @@ class FdfParser:
> #check for file path
> ErrorCode, ErrorInfo = PathClass(NormPath(ffsInf.InfFileName),
>GenFdsGlobalVariable.WorkSpaceDir).Validate()
> if ErrorCode != 0:
> EdkLogger.error("GenFds", ErrorCode, ExtraData=ErrorInfo)
>
>-if not ffsInf.InfFileName in self.Profile.InfList:
>-self.Profile.InfList.append(ffsInf.InfFileName)
>+NewFileName = ffsInf.InfFileName
>+if ffsInf.OverrideGuid:
>+NewFileName =
>ProcessDuplicatedInf(PathClass(ffsInf.InfFileName,GenFdsGlobalVariable.Wo
>rkSpaceDir), ffsInf.OverrideGuid, GenFdsGlobalVariable.WorkSpaceDir).Path
>+
>+if not NewFileName in self.Profile.InfList:
>+self.Profile.InfList.append(NewFileName)
> FileLineTuple = GetRealFileLine(self.FileName,
> self.CurrentLineNumber)
> self.Profile.InfFileLineList.append(FileLineTuple)
> if ffsInf.UseArch:
> if ffsInf.UseArch not in self.Profile.InfDict:
> self.Profile.InfDict[ffsInf.UseArch] =
> [ffsInf.InfFileName]
>--
>2.19.1.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] EmulatorPkg Unix Host Segmentation fault.
> On Nov 19, 2018, at 2:29 PM, Jordan Justen wrote:
>
> On 2018-11-19 13:22:27, Andrew Fish wrote:
>>
>>
>>> On Nov 19, 2018, at 11:16 AM, Jordan Justen
>>> wrote:
>>>
>>> On 2018-11-18 17:13:21, Jordan Justen wrote:
On 2018-11-18 14:37:09, Andrew Fish wrote:
>
>
>> On Nov 18, 2018, at 4:07 AM, Liu Yu wrote:
>>
>> sorry your path can't fix this issue. if this path just turn off
>> optimization option within sec.c not global project.
>>
>> I have tested different version GCC such as (GCC4,8, GCC5.x, GCC7.x)
>> and all of them can duplicate this issue (Ubuntu 16.04, 16.10,18.04 )
>>
>> I have traced this issue on my hand.
>>
>> you can see Dispatcher.c (MdeModulePkg/Pei/DIspatcher/) Line 792:
>>
>>
>> 790 if (StackOffsetPositive) {
>> 791 SecCoreData = (CONST EFI_SEC_PEI_HAND_OFF *)((UINTN)(VOID
>> *)SecCoreData + StackOffset);
>> 792 Private = (PEI_CORE_INSTANCE *)((UINTN)(VOID *)Private +
>> StackOffset);
>> 793 } else {
>> 794 ..
>> 795 ..
>> 796}
>>
>> 790 --792 disassembly code
>>
>> 0x10200f2ca :test %r14b,%r14b
>> 0x10200f2cd :je 0x10200f2df
>>
>> 0x10200f2cf :mov 0x38(%rsp),%rax
>> 0x10200f2d4 :lea 0x0(%rbp,%rax,1),%r14
>> 0x10200f2d9 :lea (%rbx,%rax,1),%rbp
>>
>> we can see Private value have been stored in %rbp (rbp register be
>> used as general register ) so when call
>> TemporaryRamSupportPpi->TemporaryRamMigration()
>>
>
> The calling conventions define RBP as non-volatile must be preserved
> by callee. Using RBP as the frame pointer is optional.
This is kind of a mess. I think the definition of
EFI_PEI_TEMPORARY_RAM_SUPPORT_PPI is really to blame. It probably
should not have been spec'd as 'change stack and return'. Instead, it
should have been given a new function pointer to switch-stack and call
into.
>>>
>>> Andrew, Mike,
>>>
>>> I developed a PEI Core fix for this issue, which Liu Yu verified.
>>>
>>> Unfortunately, it involves add assembly code in a key area of the PEI
>>> Core. See the top 2 commits of:
>>>
>>> https://github.com/jljusten/edk2/commits/emulator-temp-ram
>>>
>>>
>>> I only wrote assembly for X64 nasm. But, I notice that neither the PEI
>>> or DXE Core modules include any assembly code. So, I want to make sure
>>> I'm heading in the right direction before working on it further.
>>>
>>
>> Mike,
>>
>> I seem to remember we hit an issue like this a long time ago? Do you
>> remember the details? Maybe it was we needed to write the
>> TempRamSupport code in assembly?
>
> It does also creep up there, which is why we also adjust ebp/rbp in
> the TemporaryRamMigration function in OVMF.
>
> In that case, it helps prevent the stack from reverting to the old
> stack when TemporaryRamMigration is returning to it's caller. (As
> opposed to after it returns, which I think is what is happening now.)
>
The stack is switched in both cases. The problem is the C code, for the gcc
code gen, does a leave so it moves %rbp into %rsp. The %rbp in the C code was
the temp stack frame on entry. So the leave instruction from the C code gen
reverts to the old stack.
>> The issue we are hitting is the gEfiTemporaryRamSupportPpiGuid
>> TemporaryRamMigration() function call does a stack switch, but it
>> returns. This causes an issue with the C calling conventions as RBP
>> is optionally a frame pointer. To quote the MSFT spec: "May be used
>> as a frame pointer; must be preserved by callee"
>> 1) It is used as a frame pointer. It looks like our existing code
>> fixes up the frame pointer to match the new location the stack got
>> moved to.
>> 2) Used as a general purpose register, and the value must be
>> preserved.
>
> This is true, and I think it makes writing TemporaryRamMigration in C
> unsafe. Nevertheless, we've been doing that in OVMF for a while now.
>
The OVMF form is probably more portable as it is at least following the coding
standards.
What I've observed is clang (at least the Xcode version) does not use the leave
instruction as it just does math to the %rsp directly and thus does not move
the %rbp into %rsp. VC++ and some flavors of gcc don't emit the frame pointer.
So there is dependency on code construction.
>>
>>> As I mentioned below, I think PIWG could consider an new
>>> TemporarayRemSupport interface that might work better, but that also
>>> may not be worth the effort.
>>
>> If the current API is not really portable I don;t think it is a bad
>> idea to update it.
>
> The trickier part is that the C ABI doesn't cover exactly how the
> stack may be used after the call to TemporaryRamMigration returns. For
> example, there's no reason that the compiler couldn't have saved the
> stack poin
Re: [edk2] [PATCH v2 0/3] Remove S3Lib and RecoveryLib class
Shenglei, I think it would be better to split the patch series in following order: 1. package dec/dsc/uni 2. changes of each module (one patch per module) 3. public header files Regards, Jian > -Original Message- > From: Zhang, Shenglei > Sent: Monday, November 19, 2018 3:30 PM > To: edk2-devel@lists.01.org > Cc: Sun, Zailiang ; Zeng, Star ; > Wang, Jian J ; Ni, Ruiyu ; Gao, > Liming > Subject: [PATCH v2 0/3] Remove S3Lib and RecoveryLib class > > S3Lib and RecoveryLib have been deprecated since 2009. > There is no code using AcpiS3ResumeOs() interface in > S3Lib and PeiRecoverFirmware() interface in RecoveryLib. > So they can be removed from edk2 repo. > https://bugzilla.tianocore.org/show_bug.cgi?id=1299 > > v2:Remove S3Lib.h and RecoveryLib.h. in MdeModulePkg. > > Cc: Zailiang Sun > Cc: Star Zeng > Cc: Jian J Wang > Cc: Ruiyu Ni > Cc: Liming Gao > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Shenglei Zhang > Shenglei Zhang (3): > IntelFrameworkModulePkg: Remove PeiS3Lib and PeiRecoveryLib > Vlv2TbltDevicePkg: Remove PeiS3Lib in DSC > MdeModulePkg: Remove PeiS3LibNull and PeiRecoveryLibNull > > .../IntelFrameworkModulePkg.dsc | 2 - > .../Library/PeiRecoveryLib/PeiRecoveryLib.c | 50 -- > .../Library/PeiRecoveryLib/PeiRecoveryLib.inf | 50 -- > .../Library/PeiRecoveryLib/PeiRecoveryLib.uni | 23 - > .../Library/PeiS3Lib/PeiS3Lib.c | 51 --- > .../Library/PeiS3Lib/PeiS3Lib.inf | 49 -- > .../Library/PeiS3Lib/PeiS3Lib.uni | 23 - > MdeModulePkg/Core/DxeIplPeim/DxeIpl.h | 2 - > MdeModulePkg/Include/Library/RecoveryLib.h| 35 - > MdeModulePkg/Include/Library/S3Lib.h | 34 - > .../PeiRecoveryLibNull/PeiRecoveryLibNull.c | 34 - > .../PeiRecoveryLibNull/PeiRecoveryLibNull.inf | 39 -- > .../PeiRecoveryLibNull/PeiRecoveryLibNull.uni | 24 - > .../Library/PeiS3LibNull/PeiS3LibNull.c | 35 - > .../Library/PeiS3LibNull/PeiS3LibNull.inf | 40 --- > .../Library/PeiS3LibNull/PeiS3LibNull.uni | 24 - > MdeModulePkg/MdeModulePkg.dec | 10 > MdeModulePkg/MdeModulePkg.dsc | 2 - > Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 3 -- > Vlv2TbltDevicePkg/PlatformPkgIA32.dsc | 3 -- > Vlv2TbltDevicePkg/PlatformPkgX64.dsc | 3 -- > 21 files changed, 536 deletions(-) > delete mode 100644 > IntelFrameworkModulePkg/Library/PeiRecoveryLib/PeiRecoveryLib.c > delete mode 100644 > IntelFrameworkModulePkg/Library/PeiRecoveryLib/PeiRecoveryLib.inf > delete mode 100644 > IntelFrameworkModulePkg/Library/PeiRecoveryLib/PeiRecoveryLib.uni > delete mode 100644 IntelFrameworkModulePkg/Library/PeiS3Lib/PeiS3Lib.c > delete mode 100644 IntelFrameworkModulePkg/Library/PeiS3Lib/PeiS3Lib.inf > delete mode 100644 IntelFrameworkModulePkg/Library/PeiS3Lib/PeiS3Lib.uni > delete mode 100644 MdeModulePkg/Include/Library/RecoveryLib.h > delete mode 100644 MdeModulePkg/Include/Library/S3Lib.h > delete mode 100644 > MdeModulePkg/Library/PeiRecoveryLibNull/PeiRecoveryLibNull.c > delete mode 100644 > MdeModulePkg/Library/PeiRecoveryLibNull/PeiRecoveryLibNull.inf > delete mode 100644 > MdeModulePkg/Library/PeiRecoveryLibNull/PeiRecoveryLibNull.uni > delete mode 100644 MdeModulePkg/Library/PeiS3LibNull/PeiS3LibNull.c > delete mode 100644 MdeModulePkg/Library/PeiS3LibNull/PeiS3LibNull.inf > delete mode 100644 MdeModulePkg/Library/PeiS3LibNull/PeiS3LibNull.uni > > -- > 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] SecurityPkg: TCG Add more Event type
Reviewed-by: jiewen@intel.com > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Zhang, Chao B > Sent: Saturday, November 17, 2018 11:43 PM > To: edk2-devel@lists.01.org > Subject: [edk2] [Patch] SecurityPkg: TCG Add more Event type > > Add more event log type defined in TCG PTP spec 00.51 > https://trustedcomputinggroup.org/wp-content/uploads/PC-ClientSpecific_ > Platform_Profile_for_TPM_2p0_Systems_v51.pdf > > Cc:Yao Jiewen > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Zhang, Chao B > --- > MdePkg/Include/IndustryStandard/UefiTcgPlatform.h | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/MdePkg/Include/IndustryStandard/UefiTcgPlatform.h > b/MdePkg/Include/IndustryStandard/UefiTcgPlatform.h > index 5ecb4ac86e..2d223f4ea7 100644 > --- a/MdePkg/Include/IndustryStandard/UefiTcgPlatform.h > +++ b/MdePkg/Include/IndustryStandard/UefiTcgPlatform.h > @@ -20,17 +20,25 @@ > #include > > // > // Standard event types > // > +#define EV_PREBOOT_CERT ((TCG_EVENTTYPE) > 0x) > #define EV_POST_CODE((TCG_EVENTTYPE) > 0x0001) > #define EV_NO_ACTION((TCG_EVENTTYPE) > 0x0003) > #define EV_SEPARATOR((TCG_EVENTTYPE) 0x0004) > +#define EV_ACTION ((TCG_EVENTTYPE) > 0x0005) > #define EV_S_CRTM_CONTENTS ((TCG_EVENTTYPE) > 0x0007) > #define EV_S_CRTM_VERSION ((TCG_EVENTTYPE) > 0x0008) > #define EV_CPU_MICROCODE((TCG_EVENTTYPE) > 0x0009) > +#define EV_PLATFORM_CONFIG_FLAGS((TCG_EVENTTYPE) > 0x000A) > #define EV_TABLE_OF_DEVICES ((TCG_EVENTTYPE) 0x000B) > +#define EV_COMPACT_HASH ((TCG_EVENTTYPE) > 0x000C) > +#define EV_NONHOST_CODE ((TCG_EVENTTYPE) > 0x000F) > +#define EV_NONHOST_CONFIG ((TCG_EVENTTYPE) > 0x0010) > +#define EV_NONHOST_INFO ((TCG_EVENTTYPE) > 0x0011) > +#define EV_OMIT_BOOT_DEVICE_EVENTS ((TCG_EVENTTYPE) > 0x0012) > > // > // EFI specific event types > // > #define EV_EFI_EVENT_BASE ((TCG_EVENTTYPE) > 0x8000) > @@ -41,10 +49,11 @@ > #define EV_EFI_RUNTIME_SERVICES_DRIVER (EV_EFI_EVENT_BASE > + 5) > #define EV_EFI_GPT_EVENT(EV_EFI_EVENT_BASE > + 6) > #define EV_EFI_ACTION (EV_EFI_EVENT_BASE > + 7) > #define EV_EFI_PLATFORM_FIRMWARE_BLOB > (EV_EFI_EVENT_BASE + 8) > #define EV_EFI_HANDOFF_TABLES (EV_EFI_EVENT_BASE > + 9) > +#define EV_EFI_HCRTM_EVENT (EV_EFI_EVENT_BASE > + 0x10) > #define EV_EFI_VARIABLE_AUTHORITY (EV_EFI_EVENT_BASE > + 0xE0) > > #define EFI_CALLING_EFI_APPLICATION \ >"Calling EFI Application from Boot Option" > #define EFI_RETURNING_FROM_EFI_APPLICATOIN \ > -- > 2.16.2.windows.1 > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-non-osi v2 0/4] Upload D06 binary modules for SBSA test
On 11/20/2018 2:46 AM, Leif Lindholm wrote: > On Fri, Nov 16, 2018 at 04:13:02PM +0800, Ming Huang wrote: >> Main Change since v1: >> 1 Modify comments; >> >> Code can also be found in github: >> https://github.com/hisilicon/OpenPlatformPkg.git >> branch: d06-acs-non-osi-v2 > > From the black-box standpoint, this series look fine. > Are there any implications of the TB->TA boot that means I need to > synchronise pushing these with pushing that change for edk2-platforms? This four binary patches is irrelevant about TB->TA boot. D06 has been TA boot from last series (August). Thanks. > > If not, for the series: > Reviewed-by: Leif Lindholm > and I'll push when I have confirmation. > >> Ming Huang (4): >> Hisilicon/D06: Add cpu on/off feature in TrustedFirmware >> Hisilicon/D06: Fix SBSA test case 42 failed issues >> Hisilicon/D06: Fix set usb reg failed issue >> Hisilicon/D06: Fix SBSA PE-15 failed issue >> >> Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi | Bin 229216 -> >> 232832 bytes >> Platform/Hisilicon/D06/bl1.bin | Bin 12432 -> 12432 >> bytes >> Platform/Hisilicon/D06/fip.bin | Bin 113578 -> >> 113450 bytes >> 3 files changed, 0 insertions(+), 0 deletions(-) >> >> -- >> 2.9.5 >> ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch] SecurityPkg: Update TCG PTP spec revision.
UEFI TCG has aligned with TCG PTP 1.03 v51 along with Errata Version 1.0. Update spec version accordingly. Spec Link: https://trustedcomputinggroup.org/wp-content/uploads/PC-ClientSpecific_Platform_Profile_for_TPM_2p0_Systems_v51.pdf https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-Firmware-Profile-for-TPM-2-0-v1p03_r51-errata-v1p0_170426.pdf Cc: Yao Jiewen Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Zhang, Chao B --- SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.inf | 4 +++- SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf | 4 ++-- SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf | 4 ++-- SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf | 4 +++- 4 files changed, 10 insertions(+), 6 deletions(-) diff --git a/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.inf b/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.inf index 22eaced5fa..5610bc4da5 100644 --- a/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.inf +++ b/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.inf @@ -1,10 +1,12 @@ ## @file # Provides security service for TPM 2.0 measured boot # # Spec Compliance Info: -#"TCG PC Client Platform Firmware Profile Specification for TPM Family 2.0 Level 00 Revision 00.21" +#"TCG PC Client Platform Firmware Profile Specification for TPM Family 2.0 Level 00 Revision 1.03 v51" +# along with +#"Errata for PC Client Specific Platform Firmware Profile Specification Version 1.0 Revision 1.03" # # This library instance hooks LoadImage() API to measure every image that # is not measured in PEI phase. And, it will also measure GPT partition. # # Caution: This module requires additional review when modified. diff --git a/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf b/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf index 2b89869ef1..12b7448ade 100644 --- a/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf +++ b/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf @@ -1,12 +1,12 @@ ## @file # Produces Tcg2 protocol and measure boot environment # # Spec Compliance Info: -#"TCG PC Client Platform Firmware Profile Specification for TPM Family 2.0 Level 00 Revision 00.21" +#"TCG PC Client Platform Firmware Profile Specification for TPM Family 2.0 Level 00 Revision 1.03 v51" # along with -#"Errata for PC Client Specific Platform Firmware Profile Specification Version 1.0 Revision 0.21" +#"Errata for PC Client Specific Platform Firmware Profile Specification Version 1.0 Revision 1.03" #"TCG EFI Protocol Specification" "Family 2.0" "Level 00 Revision 00.13" # # This module will produce Tcg2 protocol and measure boot environment. # # Caution: This module requires additional review when modified. diff --git a/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf b/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf index 9608f9ae7e..ea9dc759ab 100644 --- a/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf +++ b/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf @@ -1,12 +1,12 @@ ## @file # Initializes TPM 2.0 device and measure FVs in PEI phase # # Spec Compliance Info: -#"TCG PC Client Platform Firmware Profile Specification for TPM Family 2.0 Level 00 Revision 00.21" +#"TCG PC Client Platform Firmware Profile Specification for TPM Family 2.0 Level 00 Revision 1.03 v51" # along with -#"Errata for PC Client Specific Platform Firmware Profile Specification Version 1.0 Revision 0.21" +#"Errata for PC Client Specific Platform Firmware Profile Specification Version 1.0 Revision 1.03" # # This module will initialize TPM device, measure reported FVs and BIOS version. # # Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved. # Copyright (c) 2017, Microsoft Corporation. All rights reserved. diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf index 142941e269..0a08885786 100644 --- a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf +++ b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf @@ -4,11 +4,13 @@ # Spec Compliance Info: # "TCG ACPI Specification Level 00 Revision 00.37" # "Physical Presence Interface Specification Version 1.30 Revision 00.52" # "Platform Reset Attack Mitigation Specification Version 1.00" #TPM2.0 ACPI device object -# "TCG PC Client Platform Firmware Profile Specification for TPM Family 2.0 Level 00 Revision 00.21" +# "TCG PC Client Platform Firmware Profile Specification for TPM Family 2.0 Level 00 Revision 1.03 v51" +# along with +# "Errata for PC Client Specific Platform Firmware Profile Specification Version 1.0 Revision 1.03" # # This driver implements TPM 2.0 definition block in ACPI table and # registers SMI callback functions for Tcg2 physical presence and # MemoryClear to handle the requests from ACPI method. # -- 2.16.2.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org h
[edk2] [PATCH v2] SecurityPkg: Update TCG PFP spec revision.
UEFI TCG has aligned with TCG PFP 1.03 v51 along with Errata Version 1.0. Update spec version accordingly. Spec Link: https://trustedcomputinggroup.org/wp-content/uploads/PC-ClientSpecific_Platform_Profile_for_TPM_2p0_Systems_v51.pdf https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-Firmware-Profile-for-TPM-2-0-v1p03_r51-errata-v1p0_170426.pdf Cc: Yao Jiewen Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Zhang, Chao B --- SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.inf | 4 +++- SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf | 4 ++-- SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf | 4 ++-- SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf | 4 +++- 4 files changed, 10 insertions(+), 6 deletions(-) diff --git a/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.inf b/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.inf index 22eaced5fa..5610bc4da5 100644 --- a/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.inf +++ b/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.inf @@ -1,10 +1,12 @@ ## @file # Provides security service for TPM 2.0 measured boot # # Spec Compliance Info: -#"TCG PC Client Platform Firmware Profile Specification for TPM Family 2.0 Level 00 Revision 00.21" +#"TCG PC Client Platform Firmware Profile Specification for TPM Family 2.0 Level 00 Revision 1.03 v51" +# along with +#"Errata for PC Client Specific Platform Firmware Profile Specification Version 1.0 Revision 1.03" # # This library instance hooks LoadImage() API to measure every image that # is not measured in PEI phase. And, it will also measure GPT partition. # # Caution: This module requires additional review when modified. diff --git a/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf b/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf index 2b89869ef1..12b7448ade 100644 --- a/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf +++ b/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf @@ -1,12 +1,12 @@ ## @file # Produces Tcg2 protocol and measure boot environment # # Spec Compliance Info: -#"TCG PC Client Platform Firmware Profile Specification for TPM Family 2.0 Level 00 Revision 00.21" +#"TCG PC Client Platform Firmware Profile Specification for TPM Family 2.0 Level 00 Revision 1.03 v51" # along with -#"Errata for PC Client Specific Platform Firmware Profile Specification Version 1.0 Revision 0.21" +#"Errata for PC Client Specific Platform Firmware Profile Specification Version 1.0 Revision 1.03" #"TCG EFI Protocol Specification" "Family 2.0" "Level 00 Revision 00.13" # # This module will produce Tcg2 protocol and measure boot environment. # # Caution: This module requires additional review when modified. diff --git a/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf b/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf index 9608f9ae7e..ea9dc759ab 100644 --- a/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf +++ b/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf @@ -1,12 +1,12 @@ ## @file # Initializes TPM 2.0 device and measure FVs in PEI phase # # Spec Compliance Info: -#"TCG PC Client Platform Firmware Profile Specification for TPM Family 2.0 Level 00 Revision 00.21" +#"TCG PC Client Platform Firmware Profile Specification for TPM Family 2.0 Level 00 Revision 1.03 v51" # along with -#"Errata for PC Client Specific Platform Firmware Profile Specification Version 1.0 Revision 0.21" +#"Errata for PC Client Specific Platform Firmware Profile Specification Version 1.0 Revision 1.03" # # This module will initialize TPM device, measure reported FVs and BIOS version. # # Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved. # Copyright (c) 2017, Microsoft Corporation. All rights reserved. diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf index 142941e269..0a08885786 100644 --- a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf +++ b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf @@ -4,11 +4,13 @@ # Spec Compliance Info: # "TCG ACPI Specification Level 00 Revision 00.37" # "Physical Presence Interface Specification Version 1.30 Revision 00.52" # "Platform Reset Attack Mitigation Specification Version 1.00" #TPM2.0 ACPI device object -# "TCG PC Client Platform Firmware Profile Specification for TPM Family 2.0 Level 00 Revision 00.21" +# "TCG PC Client Platform Firmware Profile Specification for TPM Family 2.0 Level 00 Revision 1.03 v51" +# along with +# "Errata for PC Client Specific Platform Firmware Profile Specification Version 1.0 Revision 1.03" # # This driver implements TPM 2.0 definition block in ACPI table and # registers SMI callback functions for Tcg2 physical presence and # MemoryClear to handle the requests from ACPI method. # -- 2.16.2.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org h
Re: [edk2] [patch] MdePkg: check Length para before use in DevPathToTextUsbWWID
Reviewed-by: Liming Gao
> -Original Message-
> From: Bi, Dandan
> Sent: Monday, November 19, 2018 10:09 AM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Gao, Liming
>
> Subject: [patch] MdePkg: check Length para before use in DevPathToTextUsbWWID
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1336
>
> In function DevPathToTextUsbWWID, the Length parameter is used
> without check. This patch is to add check before using it.
>
> Cc: Michael D Kinney
> Cc: Liming Gao
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi
> ---
> MdePkg/Library/UefiDevicePathLib/DevicePathToText.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MdePkg/Library/UefiDevicePathLib/DevicePathToText.c
> b/MdePkg/Library/UefiDevicePathLib/DevicePathToText.c
> index 97d279eeb2..678f3d0a92 100644
> --- a/MdePkg/Library/UefiDevicePathLib/DevicePathToText.c
> +++ b/MdePkg/Library/UefiDevicePathLib/DevicePathToText.c
> @@ -970,11 +970,11 @@ DevPathToTextUsbWWID (
>
>UsbWWId = DevPath;
>
>SerialNumberStr = (CHAR16 *) ((UINT8 *) UsbWWId + sizeof
> (USB_WWID_DEVICE_PATH));
>Length = (UINT16) ((DevicePathNodeLength ((EFI_DEVICE_PATH_PROTOCOL *)
> UsbWWId) - sizeof (USB_WWID_DEVICE_PATH)) /
> sizeof (CHAR16));
> - if (SerialNumberStr [Length - 1] != 0) {
> + if (Length >= 1 && SerialNumberStr [Length - 1] != 0) {
> //
> // In case no NULL terminator in SerialNumber, create a new one with
> NULL terminator
> //
> NewStr = AllocateCopyPool ((Length + 1) * sizeof (CHAR16),
> SerialNumberStr);
> ASSERT (NewStr != NULL);
> --
> 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] MdePkg: Check input Ptrs in GetSectionFromAnyFvByFileType
Reviewed-by: Liming Gao > -Original Message- > From: Bi, Dandan > Sent: Monday, November 19, 2018 10:09 AM > To: edk2-devel@lists.01.org > Cc: Kinney, Michael D ; Gao, Liming > > Subject: [patch] MdePkg: Check input Ptrs in GetSectionFromAnyFvByFileType > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1337 > > In function GetSectionFromAnyFvByFileType, the input parameter "Buffer" > and "size" should not be NULL, so add ASSERT here to avoid any checker > report that the NULL pointer may be used. > > Cc: Michael D Kinney > Cc: Liming Gao > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Dandan Bi > --- > MdePkg/Library/DxeServicesLib/DxeServicesLib.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/MdePkg/Library/DxeServicesLib/DxeServicesLib.c > b/MdePkg/Library/DxeServicesLib/DxeServicesLib.c > index d4f366425f..e78d51cb92 100644 > --- a/MdePkg/Library/DxeServicesLib/DxeServicesLib.c > +++ b/MdePkg/Library/DxeServicesLib/DxeServicesLib.c > @@ -251,10 +251,13 @@ GetSectionFromAnyFvByFileType ( >UINTN Key; >EFI_GUID NameGuid; >EFI_FV_FILE_ATTRIBUTESAttributes; >EFI_FIRMWARE_VOLUME2_PROTOCOL *Fv; > > + ASSERT (Buffer != NULL); > + ASSERT (Size != NULL); > + >// >// Locate all available FVs. >// >HandleBuffer = NULL; >Status = gBS->LocateHandleBuffer ( > -- > 2.18.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH] IntelFsp2WrapperPkg: Revert 90c5bc08
Commit message issue and reverted commit
90c5bc081d15d077606131a61114ddfdefe62e61.
Will re-submit with correct formats.
Cc: Jiewen Yao
Cc: Star Zeng
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chasel Chiu
---
IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c | 20
IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c | 14 ++
IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf | 3 +--
IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf | 3 +--
IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dec | 13 ++---
5 files changed, 10 insertions(+), 43 deletions(-)
diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
index fa0441ce6c..7b7c5f5d86 100644
--- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
+++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
@@ -3,7 +3,7 @@
register TemporaryRamDonePpi to call TempRamExit API, and register
MemoryDiscoveredPpi
notify to call FspSiliconInit API.
- Copyright (c) 2014 - 2018, Intel Corporation. All rights reserved.
+ Copyright (c) 2014 - 2017, 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
@@ -65,7 +65,7 @@ PeiFspMemoryInit (
FspHobListPtr = NULL;
FspmUpdDataPtr = NULL;
- FspmHeaderPtr = (FSP_INFO_HEADER *) FspFindFspHeader (PcdGet32
(PcdFspmBaseAddress));
+ FspmHeaderPtr = (FSP_INFO_HEADER *)FspFindFspHeader (PcdGet32
(PcdFspmBaseAddress));
DEBUG ((DEBUG_INFO, "FspmHeaderPtr - 0x%x\n", FspmHeaderPtr));
if (FspmHeaderPtr == NULL) {
return EFI_DEVICE_ERROR;
@@ -155,20 +155,8 @@ FspmWrapperInit (
{
EFI_STATUS Status;
- Status = EFI_SUCCESS;
-
- if (FixedPcdGet8 (PcdFspModeSelection) == 1) {
-Status = PeiFspMemoryInit ();
-ASSERT_EFI_ERROR (Status);
- } else {
-PeiServicesInstallFvInfoPpi (
- NULL,
- (VOID *)(UINTN) PcdGet32 (PcdFspmBaseAddress),
- (UINT32)((EFI_FIRMWARE_VOLUME_HEADER *) (UINTN) PcdGet32
(PcdFspmBaseAddress))->FvLength,
- NULL,
- NULL
- );
- }
+ Status = PeiFspMemoryInit ();
+ ASSERT_EFI_ERROR (Status);
return Status;
}
diff --git a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
index 87dd61e5c5..70dac7a414 100644
--- a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
+++ b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
@@ -3,7 +3,7 @@
register TemporaryRamDonePpi to call TempRamExit API, and register
MemoryDiscoveredPpi
notify to call FspSiliconInit API.
- Copyright (c) 2014 - 2018, Intel Corporation. All rights reserved.
+ Copyright (c) 2014 - 2017, 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
@@ -349,17 +349,7 @@ FspsWrapperPeimEntryPoint (
{
DEBUG ((DEBUG_INFO, "FspsWrapperPeimEntryPoint\n"));
- if (FixedPcdGet8 (PcdFspModeSelection) == 1) {
-FspsWrapperInit ();
- } else {
-PeiServicesInstallFvInfoPpi (
- NULL,
- (VOID *)(UINTN) PcdGet32 (PcdFspsBaseAddress),
- (UINT32)((EFI_FIRMWARE_VOLUME_HEADER *) (UINTN) PcdGet32
(PcdFspsBaseAddress))->FvLength,
- NULL,
- NULL
- );
- }
+ FspsWrapperInit ();
return EFI_SUCCESS;
}
diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
index b3776a80f3..542356b582 100644
--- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
+++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
@@ -6,7 +6,7 @@
# register TemporaryRamDonePpi to call TempRamExit API, and register
MemoryDiscoveredPpi
# notify to call FspSiliconInit API.
#
-# Copyright (c) 2014 - 2018, Intel Corporation. All rights reserved.
+# Copyright (c) 2014 - 2017, 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
@@ -61,7 +61,6 @@
[Pcd]
gIntelFsp2WrapperTokenSpaceGuid.PcdFspmBaseAddress ## CONSUMES
gIntelFsp2WrapperTokenSpaceGuid.PcdFspmUpdDataAddress ## CONSUMES
- gIntelFsp2WrapperTokenSpaceGuid.PcdFspModeSelection## CONSUMES
[Sources]
FspmWrapperPeim.c
diff --git a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf
b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf
index 910286982b..cd87a99c40 100644
--- a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf
+++ b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf
@@ -6,7 +6,7 @@
# register TemporaryRamDonePp
Re: [edk2] [PATCH] IntelFsp2WrapperPkg: Revert 90c5bc08
Reviewed-by: Star Zeng
-Original Message-
From: Chiu, Chasel
Sent: Tuesday, November 20, 2018 11:53 AM
To: edk2-devel@lists.01.org
Cc: Yao, Jiewen ; Zeng, Star ; Chiu,
Chasel
Subject: [PATCH] IntelFsp2WrapperPkg: Revert 90c5bc08
Commit message issue and reverted commit
90c5bc081d15d077606131a61114ddfdefe62e61.
Will re-submit with correct formats.
Cc: Jiewen Yao
Cc: Star Zeng
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chasel Chiu
---
IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c | 20
IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c | 14 ++
IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf | 3 +--
IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf | 3 +--
IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dec | 13 ++---
5 files changed, 10 insertions(+), 43 deletions(-)
diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
index fa0441ce6c..7b7c5f5d86 100644
--- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
+++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
@@ -3,7 +3,7 @@
register TemporaryRamDonePpi to call TempRamExit API, and register
MemoryDiscoveredPpi
notify to call FspSiliconInit API.
- Copyright (c) 2014 - 2018, Intel Corporation. All rights reserved.
+ Copyright (c) 2014 - 2017, 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
@@ -65,7 +65,7 @@ PeiFspMemoryInit (
FspHobListPtr = NULL;
FspmUpdDataPtr = NULL;
- FspmHeaderPtr = (FSP_INFO_HEADER *) FspFindFspHeader (PcdGet32
(PcdFspmBaseAddress));
+ FspmHeaderPtr = (FSP_INFO_HEADER *)FspFindFspHeader (PcdGet32
(PcdFspmBaseAddress));
DEBUG ((DEBUG_INFO, "FspmHeaderPtr - 0x%x\n", FspmHeaderPtr));
if (FspmHeaderPtr == NULL) {
return EFI_DEVICE_ERROR;
@@ -155,20 +155,8 @@ FspmWrapperInit (
{
EFI_STATUS Status;
- Status = EFI_SUCCESS;
-
- if (FixedPcdGet8 (PcdFspModeSelection) == 1) {
-Status = PeiFspMemoryInit ();
-ASSERT_EFI_ERROR (Status);
- } else {
-PeiServicesInstallFvInfoPpi (
- NULL,
- (VOID *)(UINTN) PcdGet32 (PcdFspmBaseAddress),
- (UINT32)((EFI_FIRMWARE_VOLUME_HEADER *) (UINTN) PcdGet32
(PcdFspmBaseAddress))->FvLength,
- NULL,
- NULL
- );
- }
+ Status = PeiFspMemoryInit ();
+ ASSERT_EFI_ERROR (Status);
return Status;
}
diff --git a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
index 87dd61e5c5..70dac7a414 100644
--- a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
+++ b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
@@ -3,7 +3,7 @@
register TemporaryRamDonePpi to call TempRamExit API, and register
MemoryDiscoveredPpi
notify to call FspSiliconInit API.
- Copyright (c) 2014 - 2018, Intel Corporation. All rights reserved.
+ Copyright (c) 2014 - 2017, 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
@@ -349,17 +349,7 @@ FspsWrapperPeimEntryPoint (
{
DEBUG ((DEBUG_INFO, "FspsWrapperPeimEntryPoint\n"));
- if (FixedPcdGet8 (PcdFspModeSelection) == 1) {
-FspsWrapperInit ();
- } else {
-PeiServicesInstallFvInfoPpi (
- NULL,
- (VOID *)(UINTN) PcdGet32 (PcdFspsBaseAddress),
- (UINT32)((EFI_FIRMWARE_VOLUME_HEADER *) (UINTN) PcdGet32
(PcdFspsBaseAddress))->FvLength,
- NULL,
- NULL
- );
- }
+ FspsWrapperInit ();
return EFI_SUCCESS;
}
diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
index b3776a80f3..542356b582 100644
--- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
+++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
@@ -6,7 +6,7 @@
# register TemporaryRamDonePpi to call TempRamExit API, and register
MemoryDiscoveredPpi
# notify to call FspSiliconInit API.
#
-# Copyright (c) 2014 - 2018, Intel Corporation. All rights reserved.
+# Copyright (c) 2014 - 2017, 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
@@ -61,7 +61,6 @@
[Pcd]
gIntelFsp2WrapperTokenSpaceGuid.PcdFspmBaseAddress ## CONSUMES
gIntelFsp2WrapperTokenSpaceGuid.PcdFspmUpdDataAddress ## CONSUMES
- gIntelFsp2WrapperTokenSpaceGuid.PcdFspModeSelection## CONSUMES
[Sources]
FspmWrapperPeim.c
diff --git a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf
b/IntelFsp2WrapperPkg
[edk2] [RFC] Proposal to remove DuetPkg
All, DuetPkg depends on Legacy BIOS to provide a UEFI environment. It was invented in the era when UEFI environment is hard to find. Since now UEFI is very popular in PC area, we could stop the official support of this package and remove it from the master. Anyone who wants to use it still can just grab it from git history. This is the same as what we did for IPF contents. If there is no concern by end of November, we will send out a formal patch to remove DuetPkg. (Since DuetPkg is big, we will not generate the huge patch using git command, instead we will just send out the patch mail with correct title/commit message but empty content.) Thanks, Ray ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v4 0/4] SdMmcOverride extension
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Wu, Hao A
> Sent: Tuesday, November 13, 2018 4:29 PM
> To: Marcin Wojtas
> Cc: Tomasz Michalec; Grzegorz Jaszczyk; edk2-devel-01; Gao, Liming;
> nad...@marvell.com; Kinney, Michael D
> Subject: Re: [edk2] [PATCH v4 0/4] SdMmcOverride extension
>
> > -Original Message-
> > From: Marcin Wojtas [mailto:m...@semihalf.com]
> > Sent: Tuesday, November 13, 2018 4:25 PM
> > To: Wu, Hao A
> > Cc: edk2-devel-01; Leif Lindholm; Kinney, Michael D; Gao, Liming; Ard
> > Biesheuvel; nad...@marvell.com; j...@semihalf.com; Tomasz Michalec;
> > Grzegorz Jaszczyk
> > Subject: Re: [PATCH v4 0/4] SdMmcOverride extension
> >
> > Hi Hao,
> >
> > wt., 13 lis 2018 o 08:38 Wu, Hao A napisał(a):
> > >
> > > Hi Marcin,
> > >
> > > The code changes look good to me.
> > >
> > > Could you please grant me some time for some additional tests for these
> > > patches?
> >
> > Sure.
> >
> > > I will inform you with the results sometime next week. Thanks in advance.
> > >
> >
> > Ard gave his RB to 2/4 and 3/4. Moreover he pointed a typo in 3/4
> > commit message - should I repost, or could those be included when
> > applying the patches (unless you don't request any code change, of
> > course)?
>
> If no other issues, I will help to address the typo issue in patch 3/4.
>
> A little concern on the commit author information if I modify the commit, but
> I will let you know if a repost from you is needed.
>
> Best Regards,
> Hao Wu
For the series:
Reviewed-by: Hao Wu
Pushed at 49c9953425..7f3b0bad4b
Best Regards,
Hao Wu
>
> >
> > Best regards,
> > Marcin
> >
> > > Best Regards,
> > > Hao Wu
> > >
> > >
> > > > -Original Message-
> > > > From: Marcin Wojtas [mailto:m...@semihalf.com]
> > > > Sent: Saturday, November 10, 2018 7:01 AM
> > > > To: edk2-devel@lists.01.org
> > > > Cc: leif.lindh...@linaro.org; Wu, Hao A; Kinney, Michael D; Gao, Liming;
> > > > ard.biesheu...@linaro.org; nad...@marvell.com; m...@semihalf.com;
> > > > j...@semihalf.com; t...@semihalf.com; j...@semihalf.com
> > > > Subject: [PATCH v4 0/4] SdMmcOverride extension
> > > >
> > > > Hi,
> > > >
> > > > Although I could've waited for Hao's remarks, I think it may
> > > > be better if he takes a look at much cleaner code, which
> > > > addresses v3 review comments.
> > > > The newest version of the patchset cleans-up significantly
> > > > patches 2&3 by removing code duplication and other minor
> > > > improvements.
> > > >
> > > > Patches are available in the github:
> > > > https://github.com/MarvellEmbeddedProcessors/edk2-open-
> > > > platform/commits/sdmmc-override-upstream-r20181109
> > > >
> > > > Please note that extending SdMmcOverride protocol was impacting
> > > > so far the only user of it (Synquacer controller). In paralel
> > > > edk2-platforms patchset, a patch can be found:
> > > > ("Silicon/SynQuacer/PlatformDxe: adjust to updated SdMmcOverride")
> > > > which adjust to the new API.
> > > > https://github.com/MarvellEmbeddedProcessors/edk2-open-
> > > > platform/commits/xenon-upstream-r20181109
> > > >
> > > > I'm looking forward to the comments and remarks.
> > > >
> > > > Best regards,
> > > > Marcin
> > > >
> > > > Changelog:
> > > > v3->v4
> > > > * 2/4:
> > > > - avoid duplication by calling SdMmcOverride callback in
> > > > SdMmcHcUhsSignaling
> > > >
> > > > * 3/4:
> > > > - avoid duplication by calling SdMmcOverride callback in
> > > > EmmcSwitchClockFreq
> > > >
> > > > * 4/4:
> > > > - add Ard's RB
> > > >
> > > > v2->v3
> > > > * 1/4:
> > > > - rename new parameter to PhaseData
> > > > - add Ard's RB
> > > >
> > > > * 2/4:
> > > > - s/Controler/Controller/
> > > > - remove all references to MMC_SDR_50 mode
> > > > - rename and reorder MMC bus modes
> > > > - rename enum: s/SD_MMC_UHS_TIMING/SD_MMC_BUS_MODE/
> > > > and move it to protocol header in order to drop including private
> > > > one
> > > > - fix if condition in EmmcSwitchToHighSpeed
> > > > - call SdMmcHcUhsSignaling unconditionally before SdMmcOverride
> > > > callback, so that protocol producer can optionally modify only
> > > > quirky
> > > > timing mode values.
> > > >
> > > > *4/4
> > > > - bump protocol version to 2
> > > > - remove redundant assert from SdMmcPciHcDriverBindingStart
> > > > (BaseClkFreq is already checked in SdMmcHcInitClockFreq)
> > > > - update comment in SdMmcHcInitClockFreq
> > > > - restore original DumpCapabilityReg and append
> > > >
> > > > v1 -> v2
> > > > * Rebase onto newest master
> > > > * 1/4 [new patch] - preparation for extending NotifyPhase
> > > > * 2/4 - UhsSignaling as a part of NotifyPhase
> > > > * 3/4 - SwitchClockFreqPost as a part of NotifyPhase
> > > > * 4/4 - Allow updating BaseClkFreq via Capability instead of the
> > > > independent callback.
> > > >
> > > >
> > > > Marcin Wojtas (2):
> > > > MdeModulePkg/SdMmcPciHcDxe: Add an optional parameter in
> >
Re: [edk2] [PATCH edk2-platforms v2 06/15] Hisilicon/D06: Move some functions to OemMiscLib
On 11/20/2018 2:30 AM, Leif Lindholm wrote: > On Fri, Nov 16, 2018 at 02:56:53PM +0800, Ming Huang wrote: >> As M41T83RealTimeClockLib is common library, so move two cpld >> relative functions to OemMiscLib and rename this two functions. >> >> Contributed-under: TianoCore Contribution Agreement 1.1 >> Signed-off-by: Ming Huang > > I did not see any of my review comments addressed, or any response > saying it was not being changed. > > My feedback was: > --- > This would be more clear as "platform specific" than "cpld relative". > > I did not realise this wasn't a Hisilicon component when reviewing the > original set. > > I approve of this change, but can you tell me why it is included in > this set? If the goal is to make the M41T83 support platform > independent, should the library also move to Silicon/ST/? > --- > > So could you please update the commit message, and add a subsequent > patch moving Library/M41T83RealTimeClockLib to > Silicon/STMicroelectronics (and updating D06.dsc to match)? > I do not care if it is not perfectly abstracted yet - we can deal with > that when we have other users of the component in the tree. Sorry for missing update the commit message this patch. I will update it in v3. I try to move the library to Silicon/STMicroelectronics, but M41T83RealTimeClockLib depend on I2CLib in Hisilicon, so can't move the library to STMicroelectronics. Main gist of this patch is making this library as a common module in Hisilicon. > > / > Leif > >> --- >> Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClockLib.inf >> | 1 - >> Silicon/Hisilicon/Include/Library/OemMiscLib.h >> | 9 ++ >> Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClock.h >> | 4 - >> Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c >> | 82 ++ >> Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClockLib.c >> | 90 ++-- >> 5 files changed, 98 insertions(+), 88 deletions(-) >> >> diff --git >> a/Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClockLib.inf >> >> b/Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClockLib.inf >> index e0bf6b3f24db..4e963fd4531a 100644 >> --- >> a/Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClockLib.inf >> +++ >> b/Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClockLib.inf >> @@ -27,7 +27,6 @@ [Sources.common] >> [Packages] >>EmbeddedPkg/EmbeddedPkg.dec >>MdePkg/MdePkg.dec >> - Platform/Hisilicon/D06/D06.dec >>Silicon/Hisilicon/HisiPkg.dec >> >> [LibraryClasses] >> diff --git a/Silicon/Hisilicon/Include/Library/OemMiscLib.h >> b/Silicon/Hisilicon/Include/Library/OemMiscLib.h >> index 86ea6a1b3deb..0d7bf71b17d2 100644 >> --- a/Silicon/Hisilicon/Include/Library/OemMiscLib.h >> +++ b/Silicon/Hisilicon/Include/Library/OemMiscLib.h >> @@ -53,4 +53,13 @@ BOOLEAN OemIsNeedDisableExpanderBuffer(VOID); >> >> extern EFI_STRING_ID gDimmToDevLocator[MAX_SOCKET][MAX_CHANNEL][MAX_DIMM]; >> EFI_HII_HANDLE EFIAPI OemGetPackages (); >> + >> +VOID >> +OemReleaseOwnershipOfRtc ( >> + VOID >> + ); >> +EFI_STATUS >> +OemSwitchRtcI2cChannelAndLock ( >> + VOID >> + ); >> #endif >> diff --git >> a/Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClock.h >> b/Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClock.h >> index d985055d9bb6..f32910885856 100644 >> --- a/Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClock.h >> +++ b/Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClock.h >> @@ -17,11 +17,7 @@ >> #define __M41T83_REAL_TIME_CLOCK_H__ >> >> // The delay is need for cpld and I2C. This is a empirical value. >> MemoryFence is no need. >> -#define RTC_DELAY_30_MS3 >> -// The delay is need for cpld and I2C. This is a empirical value. >> MemoryFence is no need. >> #define RTC_DELAY_1000_MACROSECOND 1000 >> -// The delay is need for cpld and I2C. This is a empirical value. >> MemoryFence is no need. >> -#define RTC_DELAY_2_MACROSECOND2 >> >> #define M41T83_REGADDR_DOTSECONDS 0x00 >> #define M41T83_REGADDR_SECONDS 0x01 >> diff --git a/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c >> b/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c >> index 2a9db46d1ff9..64d167d18ae6 100644 >> --- a/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c >> +++ b/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c >> @@ -17,6 +17,7 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> #include >> @@ -27,6 +28,12 @@ >> #include >> #include >> #include >> +#include >> + >> +// The delay is need for cpld and I2C. This is a empirical value. >> MemoryFence is no need. >> +#define RTC_DELAY_30_MS3 >> +// The delay is need for cpld and I2C. This is a empirical value. >> Me
Re: [edk2] [PATCH edk2-platforms v2 07/15] Hisilicon/D0x: Fix secure boot bug in FlashFvbDxe
On 11/20/2018 2:13 AM, Leif Lindholm wrote: > On Fri, Nov 16, 2018 at 02:56:54PM +0800, Ming Huang wrote: >> When SECURE_BOOT_ENABLE is TRUE, FlashFvbDxe should use >> gEfiAuthenticatedVariableGuid, When SECURE_BOOT_ENABLE >> is FALSE, gEfiVariableGuid should be used. >> > > Other platforms seem to resolve this by doing something like: > > !if $(SECURE_BOOT_ENABLE) > ... > AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf > !else > > AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf > !endif > > Can the same mechanism be used here instead? I see Ard provide a patch which is similar to this patch, so modify this patch like that patch. Thanks. > > I _really_ don't like the idea of adding vendor-specific Pcds to > determine whether Secure Boot is enabled. > > / > Leif > >> Contributed-under: TianoCore Contribution Agreement 1.1 >> Signed-off-by: Ming Huang >> --- >> Silicon/Hisilicon/HisiPkg.dec | 1 + >> Platform/Hisilicon/D03/D03.dsc| 5 + >> Platform/Hisilicon/D05/D05.dsc| 5 + >> Platform/Hisilicon/D06/D06.dsc| 5 + >> Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.inf | 2 ++ >> Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.c | 14 -- >> 6 files changed, 30 insertions(+), 2 deletions(-) >> >> diff --git a/Silicon/Hisilicon/HisiPkg.dec b/Silicon/Hisilicon/HisiPkg.dec >> index 404a3ae4af9d..af9359e4d0e0 100644 >> --- a/Silicon/Hisilicon/HisiPkg.dec >> +++ b/Silicon/Hisilicon/HisiPkg.dec >> @@ -278,6 +278,7 @@ [PcdsFixedAtBuild] >> >>gHisiTokenSpaceGuid.Pcdsoctype|0|UINT32|0x0061 >>gHisiTokenSpaceGuid.PcdSerDesFlowCtrlFlag|0|UINT32|0x4056 >> + gHisiTokenSpaceGuid.PcdIsSecureBoot|FALSE|BOOLEAN|0x4058 >> >> [PcdsFeatureFlag] >>gHisiTokenSpaceGuid.PcdIsItsSupported|FALSE|BOOLEAN|0x0065 >> diff --git a/Platform/Hisilicon/D03/D03.dsc b/Platform/Hisilicon/D03/D03.dsc >> index aa1da5d61f83..ba3096672db0 100644 >> --- a/Platform/Hisilicon/D03/D03.dsc >> +++ b/Platform/Hisilicon/D03/D03.dsc >> @@ -281,6 +281,11 @@ [PcdsFixedAtBuild.common] >>gHisiTokenSpaceGuid.PcdHb0Rb2IoSize|0x #64K >> >>gHisiTokenSpaceGuid.Pcdsoctype|0x1610 >> + !if $(SECURE_BOOT_ENABLE) == TRUE >> +gHisiTokenSpaceGuid.PcdIsSecureBoot|TRUE >> + !else >> +gHisiTokenSpaceGuid.PcdIsSecureBoot|FALSE >> + !endif >> >> >> >> # >> diff --git a/Platform/Hisilicon/D05/D05.dsc b/Platform/Hisilicon/D05/D05.dsc >> index 1040466633ef..b8500cef8742 100644 >> --- a/Platform/Hisilicon/D05/D05.dsc >> +++ b/Platform/Hisilicon/D05/D05.dsc >> @@ -422,6 +422,11 @@ [PcdsFixedAtBuild.common] >>gHisiTokenSpaceGuid.PcdHb1Rb7IoSize|0x1 #64K >> >>gHisiTokenSpaceGuid.Pcdsoctype|0x1610 >> + !if $(SECURE_BOOT_ENABLE) == TRUE >> +gHisiTokenSpaceGuid.PcdIsSecureBoot|TRUE >> + !else >> +gHisiTokenSpaceGuid.PcdIsSecureBoot|FALSE >> + !endif >> >> >> >> # >> diff --git a/Platform/Hisilicon/D06/D06.dsc b/Platform/Hisilicon/D06/D06.dsc >> index 1a479c160e80..b6ef9fedf0a7 100644 >> --- a/Platform/Hisilicon/D06/D06.dsc >> +++ b/Platform/Hisilicon/D06/D06.dsc >> @@ -243,6 +243,11 @@ [PcdsFixedAtBuild.common] >> >>gEfiMdeModulePkgTokenSpaceGuid.PcdSrIovSupport|FALSE >>gArmTokenSpaceGuid.PcdPciIoTranslation|0x0 >> + !if $(SECURE_BOOT_ENABLE) == TRUE >> +gHisiTokenSpaceGuid.PcdIsSecureBoot|TRUE >> + !else >> +gHisiTokenSpaceGuid.PcdIsSecureBoot|FALSE >> + !endif >> >> >> >> # >> diff --git a/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.inf >> b/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.inf >> index f8be4741ef7c..47965a707032 100644 >> --- a/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.inf >> +++ b/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.inf >> @@ -44,6 +44,7 @@ [LibraryClasses] >>UefiRuntimeLib >> >> [Guids] >> + gEfiAuthenticatedVariableGuid >>gEfiSystemNvDataFvGuid >>gEfiVariableGuid >> >> @@ -62,6 +63,7 @@ [Pcd.common] >>gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize >> >>gArmPlatformTokenSpaceGuid.PcdNorFlashCheckBlockLocked >> + gHisiTokenSpaceGuid.PcdIsSecureBoot >>gHisiTokenSpaceGuid.PcdSFCMEM0BaseAddress >> >> [Depex] >> diff --git a/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.c >> b/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.c >> index e18cc9e06ec2..309941d6fe4d 100644 >> --- a/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.c >> +++ b/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.c >> @@ -189,7 +189,11 @@ InitializeFvAndVariableStoreHeaders ( >> // VARIABLE_STORE_HEADER >> // >> VariableStoreHeader = (VA
Re: [edk2] [PATCH edk2-platforms v2 07/15] Hisilicon/D0x: Fix secure boot bug in FlashFvbDxe
On 11/20/2018 2:19 AM, Ard Biesheuvel wrote:
> On Thu, 15 Nov 2018 at 22:57, Ming Huang wrote:
>>
>> When SECURE_BOOT_ENABLE is TRUE, FlashFvbDxe should use
>> gEfiAuthenticatedVariableGuid, When SECURE_BOOT_ENABLE
>> is FALSE, gEfiVariableGuid should be used.
>>
>
> Can we fix the driver instead so we don't need to make this distinction?
Yes, modify it as below patch.
Thank you.
>
> Please refer to commit 8753858f84768fa6fa17191b86c97538457723ce in the
> EDK2 for some background.
>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ming Huang
>> ---
>> Silicon/Hisilicon/HisiPkg.dec | 1 +
>> Platform/Hisilicon/D03/D03.dsc| 5 +
>> Platform/Hisilicon/D05/D05.dsc| 5 +
>> Platform/Hisilicon/D06/D06.dsc| 5 +
>> Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.inf | 2 ++
>> Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.c | 14 --
>> 6 files changed, 30 insertions(+), 2 deletions(-)
>>
>> diff --git a/Silicon/Hisilicon/HisiPkg.dec b/Silicon/Hisilicon/HisiPkg.dec
>> index 404a3ae4af9d..af9359e4d0e0 100644
>> --- a/Silicon/Hisilicon/HisiPkg.dec
>> +++ b/Silicon/Hisilicon/HisiPkg.dec
>> @@ -278,6 +278,7 @@ [PcdsFixedAtBuild]
>>
>>gHisiTokenSpaceGuid.Pcdsoctype|0|UINT32|0x0061
>>gHisiTokenSpaceGuid.PcdSerDesFlowCtrlFlag|0|UINT32|0x4056
>> + gHisiTokenSpaceGuid.PcdIsSecureBoot|FALSE|BOOLEAN|0x4058
>>
>> [PcdsFeatureFlag]
>>gHisiTokenSpaceGuid.PcdIsItsSupported|FALSE|BOOLEAN|0x0065
>> diff --git a/Platform/Hisilicon/D03/D03.dsc b/Platform/Hisilicon/D03/D03.dsc
>> index aa1da5d61f83..ba3096672db0 100644
>> --- a/Platform/Hisilicon/D03/D03.dsc
>> +++ b/Platform/Hisilicon/D03/D03.dsc
>> @@ -281,6 +281,11 @@ [PcdsFixedAtBuild.common]
>>gHisiTokenSpaceGuid.PcdHb0Rb2IoSize|0x #64K
>>
>>gHisiTokenSpaceGuid.Pcdsoctype|0x1610
>> + !if $(SECURE_BOOT_ENABLE) == TRUE
>> +gHisiTokenSpaceGuid.PcdIsSecureBoot|TRUE
>> + !else
>> +gHisiTokenSpaceGuid.PcdIsSecureBoot|FALSE
>> + !endif
>>
>>
>>
>> #
>> diff --git a/Platform/Hisilicon/D05/D05.dsc b/Platform/Hisilicon/D05/D05.dsc
>> index 1040466633ef..b8500cef8742 100644
>> --- a/Platform/Hisilicon/D05/D05.dsc
>> +++ b/Platform/Hisilicon/D05/D05.dsc
>> @@ -422,6 +422,11 @@ [PcdsFixedAtBuild.common]
>>gHisiTokenSpaceGuid.PcdHb1Rb7IoSize|0x1 #64K
>>
>>gHisiTokenSpaceGuid.Pcdsoctype|0x1610
>> + !if $(SECURE_BOOT_ENABLE) == TRUE
>> +gHisiTokenSpaceGuid.PcdIsSecureBoot|TRUE
>> + !else
>> +gHisiTokenSpaceGuid.PcdIsSecureBoot|FALSE
>> + !endif
>>
>>
>>
>> #
>> diff --git a/Platform/Hisilicon/D06/D06.dsc b/Platform/Hisilicon/D06/D06.dsc
>> index 1a479c160e80..b6ef9fedf0a7 100644
>> --- a/Platform/Hisilicon/D06/D06.dsc
>> +++ b/Platform/Hisilicon/D06/D06.dsc
>> @@ -243,6 +243,11 @@ [PcdsFixedAtBuild.common]
>>
>>gEfiMdeModulePkgTokenSpaceGuid.PcdSrIovSupport|FALSE
>>gArmTokenSpaceGuid.PcdPciIoTranslation|0x0
>> + !if $(SECURE_BOOT_ENABLE) == TRUE
>> +gHisiTokenSpaceGuid.PcdIsSecureBoot|TRUE
>> + !else
>> +gHisiTokenSpaceGuid.PcdIsSecureBoot|FALSE
>> + !endif
>>
>>
>>
>> #
>> diff --git a/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.inf
>> b/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.inf
>> index f8be4741ef7c..47965a707032 100644
>> --- a/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.inf
>> +++ b/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.inf
>> @@ -44,6 +44,7 @@ [LibraryClasses]
>>UefiRuntimeLib
>>
>> [Guids]
>> + gEfiAuthenticatedVariableGuid
>>gEfiSystemNvDataFvGuid
>>gEfiVariableGuid
>>
>> @@ -62,6 +63,7 @@ [Pcd.common]
>>gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
>>
>>gArmPlatformTokenSpaceGuid.PcdNorFlashCheckBlockLocked
>> + gHisiTokenSpaceGuid.PcdIsSecureBoot
>>gHisiTokenSpaceGuid.PcdSFCMEM0BaseAddress
>>
>> [Depex]
>> diff --git a/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.c
>> b/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.c
>> index e18cc9e06ec2..309941d6fe4d 100644
>> --- a/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.c
>> +++ b/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.c
>> @@ -189,7 +189,11 @@ InitializeFvAndVariableStoreHeaders (
>> // VARIABLE_STORE_HEADER
>> //
>> VariableStoreHeader = (VARIABLE_STORE_HEADER*)((UINTN)Headers +
>> (UINTN)FirmwareVolumeHeader->HeaderLength);
>> -CopyGuid (&VariableStoreHeader->Signature, &gEfiVariableGuid);
>> +if (PcdGetBool (PcdIsSecureBoot)) {
>> + CopyGuid (&VariableStoreHeader->Signature,
>> &gEfiAuthenticatedVariableGuid);
>> +} else {
>> + CopyGuid (&VariableStoreHeader->Signature, &gEfiVariableGuid)
[edk2] [edk2-test][PATCH] Framework/Include: allow usage with EFI version 2.7
EDK2 supports EFI version 2.7 and so allow UEFI-SCT to be usable with this version of EFI. Signed-off-by: Lokesh B V --- uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/Include/SctDef.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/Include/SctDef.h b/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/Include/SctDef.h index d24c201..c861437 100644 --- a/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/Include/SctDef.h +++ b/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/Include/SctDef.h @@ -46,6 +46,8 @@ Abstract: #define EFI_SCT_NAMEL"UEFI2.5 Self Certification Test(SCT2)" #elif (EFI_SPECIFICATION_VERSION == EFI_2_60_SYSTEM_TABLE_REVISION) #define EFI_SCT_NAMEL"UEFI2.6 Self Certification Test(SCT2)" +#elif (EFI_SPECIFICATION_VERSION == EFI_2_70_SYSTEM_TABLE_REVISION) +#define EFI_SCT_NAMEL"UEFI2.7 Self Certification Test(SCT2)" #else #error Unknown EFI_SPECIFICATION_VERSION #endif -- 2.7.4 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [edk2-test][PATCH] SctPkg/UEFI: Fix invalid GUID value format error
Fix all GUID values that are defined with a invalid GUID
value format.
Signed-off-by: Lokesh B V
---
uefi-sct/SctPkg/UEFI/UEFI.dec | 202 +-
1 file changed, 101 insertions(+), 101 deletions(-)
diff --git a/uefi-sct/SctPkg/UEFI/UEFI.dec b/uefi-sct/SctPkg/UEFI/UEFI.dec
index 14cc5b0..7e4d248 100644
--- a/uefi-sct/SctPkg/UEFI/UEFI.dec
+++ b/uefi-sct/SctPkg/UEFI/UEFI.dec
@@ -44,25 +44,25 @@
[Guids.common]
- gBlackBoxEfiFileInfoGuid = { 0x9576e92, 0x6d3f, 0x11d2, 0x8e, 0x39, 0x0,
0xa0, 0xc9, 0x69, 0x72, 0x3b }
- gBlackBoxEfiFileInfoIdGuid = { 0x9576e93, 0x6d3f, 0x11d2, 0x8e, 0x39, 0x0,
0xa0, 0xc9, 0x69, 0x72, 0x3b }
+ gBlackBoxEfiFileInfoGuid = { 0x9576e92, 0x6d3f, 0x11d2, { 0x8e, 0x39, 0x0,
0xa0, 0xc9, 0x69, 0x72, 0x3b }}
+ gBlackBoxEfiFileInfoIdGuid = { 0x9576e93, 0x6d3f, 0x11d2, { 0x8e, 0x39, 0x0,
0xa0, 0xc9, 0x69, 0x72, 0x3b }}
gBlackBoxEfiFileSystemInfoGuid = { 0x09576E93, 0x6D3F, 0x11D2, { 0x8E, 0x39,
0x00, 0xA0, 0xC9, 0x69, 0x72, 0x3B }}
- gBlackBoxEfiFileSystemVolumeLabelInfoIdGuid = { 0xDB47D7D3,0xFE81, 0x11d3,
0x9A, 0x35, 0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D }
- gBlackBoxEfiTcp4RegistryDataGuid = { 0x755B4303, 0xCAA5, 0x4481, 0xB1, 0x3D,
0x07, 0xBE, 0x14, 0xD5, 0x4D, 0x3F}
- gBlackBoxEfiTcp6RegistryDataGuid = { 0x80623540, 0x7B41, 0x4306, 0x99, 0x87,
0x1B, 0xF6, 0xE5, 0xAD, 0x15, 0x3E }
+ gBlackBoxEfiFileSystemVolumeLabelInfoIdGuid = { 0xDB47D7D3, 0xFE81, 0x11d3,
{ 0x9A, 0x35, 0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D }}
+ gBlackBoxEfiTcp4RegistryDataGuid = { 0x755B4303, 0xCAA5, 0x4481, { 0xB1,
0x3D, 0x07, 0xBE, 0x14, 0xD5, 0x4D, 0x3F }}
+ gBlackBoxEfiTcp6RegistryDataGuid = { 0x80623540, 0x7B41, 0x4306, { 0x99,
0x87, 0x1B, 0xF6, 0xE5, 0xAD, 0x15, 0x3E }}
gBlackBoxEfiPcAnsiGuid = { 0xE0C14753, 0xF9BE, 0x11D2, { 0x9A, 0x0C, 0x00,
0x90, 0x27, 0x3F, 0xC1, 0x4D }}
gBlackBoxEfiVT100Guid = { 0xDFA66065, 0xB419, 0x11D3, { 0x9A, 0x2D, 0x00,
0x90, 0x27, 0x3F, 0xC1, 0x4D }}
gBlackBoxEfiVT100PlusGuid = { 0x7BAEC70B, 0x57E0, 0x4C76, { 0x8E, 0x87,
0x2F, 0x9E, 0x28, 0x08, 0x83, 0x43 }}
gBlackBoxEfiVTUTF8Guid = { 0xAD15A0D6, 0x8BEC, 0x4ACF, { 0xA0, 0x73, 0xD0,
0x1D, 0xE7, 0x7E, 0x2D, 0x88 }}
- gBlackBoxEfiHash2AlgorithmSha1Guid = { 0x2ae9d80f, 0x3fb2, 0x4095, 0xb7,
0xb1, 0xe9, 0x31, 0x57, 0xb9, 0x46, 0xb6 }
- gBlackBoxEfiHash2AlgorithmSha224Guid = { 0x8df01a06, 0x9bd5, 0x4bf7, 0xb0,
0x21, 0xdb, 0x4f, 0xd9, 0xcc, 0xf4, 0x5b }
- gBlackBoxEfiHash2AlgorithmSha256Guid = { 0x51aa59de, 0xfdf2, 0x4ea3, 0xbc,
0x63, 0x87, 0x5f, 0xb7, 0x84, 0x2e, 0xe9 }
- gBlackBoxEfiHash2AlgorithmSha384Guid = { 0xefa96432, 0xde33, 0x4dd2, 0xae,
0xe6, 0x32, 0x8c, 0x33, 0xdf, 0x77, 0x7a }
- gBlackBoxEfiHash2AlgorithmSha512Guid = { 0xcaa4381e, 0x750c, 0x4770, 0xb8,
0x70, 0x7a, 0x23, 0xb4, 0xe4, 0x21, 0x30 }
- gBlackBoxEfiHash2AlgorithmMD5Guid = { 0xaf7c79c, 0x65b5, 0x4319, 0xb0, 0xae,
0x44, 0xec, 0x48, 0x4e, 0x4a, 0xd7 }
- gBlackBoxEfiHash2AlgorithmSha1NoPadGuid = { 0x24c5dc2f, 0x53e2, 0x40ca,
0x9e, 0xd6, 0xa5, 0xd9, 0xa4, 0x9f, 0x46, 0x3b }
- gBlackBoxEfiHash2AlgorithmSha256NoPadGuid = { 0x8628752a, 0x6cb7, 0x4814,
0x96, 0xfc, 0x24, 0xa8, 0x15, 0xac, 0x22, 0x26 }
+ gBlackBoxEfiHash2AlgorithmSha1Guid = { 0x2ae9d80f, 0x3fb2, 0x4095, { 0xb7,
0xb1, 0xe9, 0x31, 0x57, 0xb9, 0x46, 0xb6 }}
+ gBlackBoxEfiHash2AlgorithmSha224Guid = { 0x8df01a06, 0x9bd5, 0x4bf7, { 0xb0,
0x21, 0xdb, 0x4f, 0xd9, 0xcc, 0xf4, 0x5b }}
+ gBlackBoxEfiHash2AlgorithmSha256Guid = { 0x51aa59de, 0xfdf2, 0x4ea3, { 0xbc,
0x63, 0x87, 0x5f, 0xb7, 0x84, 0x2e, 0xe9 }}
+ gBlackBoxEfiHash2AlgorithmSha384Guid = { 0xefa96432, 0xde33, 0x4dd2, { 0xae,
0xe6, 0x32, 0x8c, 0x33, 0xdf, 0x77, 0x7a }}
+ gBlackBoxEfiHash2AlgorithmSha512Guid = { 0xcaa4381e, 0x750c, 0x4770, { 0xb8,
0x70, 0x7a, 0x23, 0xb4, 0xe4, 0x21, 0x30 }}
+ gBlackBoxEfiHash2AlgorithmMD5Guid = { 0xaf7c79c, 0x65b5, 0x4319, { 0xb0,
0xae, 0x44, 0xec, 0x48, 0x4e, 0x4a, 0xd7 }}
+ gBlackBoxEfiHash2AlgorithmSha1NoPadGuid = { 0x24c5dc2f, 0x53e2, 0x40ca, {
0x9e, 0xd6, 0xa5, 0xd9, 0xa4, 0x9f, 0x46, 0x3b }}
+ gBlackBoxEfiHash2AlgorithmSha256NoPadGuid = { 0x8628752a, 0x6cb7, 0x4814, {
0x96, 0xfc, 0x24, 0xa8, 0x15, 0xac, 0x22, 0x26 }}
gBlackBoxEfiCertSha256Guid = { 0xc1c41626, 0x504c, 0x4092,
{0xac, 0xa9, 0x41, 0xf9, 0x36, 0x93, 0x43, 0x28 }}
@@ -79,109 +79,109 @@
gBlackBoxEfiPersistentVirtualCdGuid = { 0x08018188, 0x42CD, 0xBB48, {0x10,
0x0F, 0x53, 0x87, 0xD5, 0x3D, 0xED, 0x3D }}
[Protocols.common]
- gBlackBoxEfiAbsolutePointerProtocolGuid = { 0x8D59D32B, 0xC655, 0x4AE9, {
0x9B, 0x15, 0xF2, 0x59, 0x04, 0x99, 0x2A, 0x43 } }
- gBlackBoxEfiAcpiTableProtocolGuid = { 0xffe06bdd, 0x6107, 0x46a6, 0x7b,
0xb2, 0x5a, 0x9c, 0x7e, 0xc5, 0x27, 0x5c }
- gBlackBoxEfiArpProtocolGuid = { 0xf4b427bb, 0xba21, 0x4f16, 0xbc, 0x4e,
0x43, 0xe4, 0x16, 0xab, 0x61, 0x9c }
- gBlackBoxEfiArpServiceBindingProtocolGuid = { 0xf44c00ee, 0x1f2c, 0x4a00,
0xaa, 0x09, 0x1c, 0x9f, 0x3e, 0x08, 0x00, 0xa3 }
- gBlackBoxEfiAtaPassThruPr
[edk2] [edk2-test][PATCH] SctPkg/Tools: Fix incorrect line ending detection by GenBin tool
Some windows editors uses "\r\n" for line feed. While processing uefi testcase
info file, the GenBin tool logic to skip line feed doesn't consider the presence
of carraige return(\r) in line feed. So this results in incorrect format error.
Signed-off-by: Lokesh B V
---
uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
b/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
index 61bb35b..ce271a1 100644
--- a/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
+++ b/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
@@ -176,6 +176,7 @@ Trim (
for (Index1 = 0; Index1 < Length; Index1++) {
if ((String[Index1] != ' ' ) &&
(String[Index1] != '\t') &&
+(String[Index1] != '\r') &&
(String[Index1] != '\n')) {
break;
}
@@ -193,6 +194,7 @@ Trim (
for (Index1 = 0; Index1 < Length; Index1++) {
if ((String[Length - 1 - Index1] != ' ' ) &&
(String[Length - 1 - Index1] != '\t') &&
+(String[Length - 1 - Index1] != '\r') &&
(String[Length - 1 - Index1] != '\n')) {
break;
}
--
2.7.4
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [edk2-test][PATCH] SctPkg/build: Add support for GenBin tool build
As the GenBin tool is necessary for SCT build, it is appropriate to support it's build in the SCT build procedure. Signed-off-by: Lokesh B V --- uefi-sct/SctPkg/build.sh | 29 + 1 file changed, 17 insertions(+), 12 deletions(-) diff --git a/uefi-sct/SctPkg/build.sh b/uefi-sct/SctPkg/build.sh index 73581c9..e070ad5 100755 --- a/uefi-sct/SctPkg/build.sh +++ b/uefi-sct/SctPkg/build.sh @@ -228,21 +228,26 @@ else echo using prebuilt tools fi -# Copy GenBin file to Base tools directory +if [[ ! -e $EDK_TOOLS_PATH/Source/C/bin/GenBin ]] +then + # build the GenBin if it doesn't yet exist + echo Building GenBin + make -C $EDK_TOOLS_PATH/../SctPkg/Tools/Source/GenBin + status=$? + if test $status -ne 0 + then + echo Error while building GenBin +exit -1 + fi +else + echo using prebuilt GenBin +fi + +# Copy GenBin file to Base tools bin directory DEST_DIR=`GetEdkToolsPathBinDirectory` # Ensure the directory exist mkdir -p $DEST_DIR -case `uname -m` in - x86_64) - cp SctPkg/Tools/Bin/GenBin_lin_64 $DEST_DIR/GenBin - ;; - x86_32) - cp SctPkg/Tools/Bin/GenBin_lin_32 $DEST_DIR/GenBin - ;; - *) - cp SctPkg/Tools/Bin/GenBin_lin_32 $DEST_DIR/GenBin - ;; -esac +cp $EDK_TOOLS_PATH/Source/C/bin/GenBin $DEST_DIR/GenBin # # Build the SCT package -- 2.7.4 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v2 00/15] Fix D06 SBSA/SBBR issue and improve
On 11/20/2018 2:42 AM, Leif Lindholm wrote: > On Fri, Nov 16, 2018 at 02:56:47PM +0800, Ming Huang wrote: >> Main Change since v1: >> 1. Add IORT patch; >> 2. Add HIDs/UIDs bug for PciHostBridgeLib; >> 3. Drop Pv660; >> 4. Drop two patchs: >>Modify for SBBR fwts SetTime_Func test case; >>Fix SBBR-SCT AuthVar issue >> >> Code can also be found in github: >> https://github.com/hisilicon/OpenPlatformPkg.git >> branch: d06-acs-platforms-v2 >> >> >> Ming Huang (15): >> Hisilicon/D0x: Modify IORT >> Silicon/Hisilicon/D06: Add watchdog to GTDT >> Silicon/Hisilicon/D06: Drop _CID for fwts issue >> Silicon/Hisilicon/D06: Fix fwts issue in Dbg2 >> Silicon/Hisilicon/D06: Fix fwts issue in FADT >> Hisilicon/D06: Move some functions to OemMiscLib >> Hisilicon/D0x: Fix secure boot bug in FlashFvbDxe >> Silicon/Hisilicon/D06: Reserve ECAM resource in DSDT >> Silicon/Hisilicon/D06: Modify GTDT timer flag >> Hisilicon/D06: Modify Gic base >> Silicon/Hisilicon/D06: Set TA as Node 0 for TA boot >> Silicon/Hisilicon/D03: Drop _CID for fwts issue >> Silicon/Hisilicon/D05: Drop _CID for fwts issue >> Hisilicon: Drop Pv660 source code >> Hisilicon/D06: Correct HIDs/UIDs of PCI host bridges > > The following patches (in this order): >Hisilicon: Drop Pv660 source code >Hisilicon/D0x: Modify IORT >Silicon/Hisilicon/D03: Drop _CID for fwts issue >Silicon/Hisilicon/D05: Drop _CID for fwts issue >Silicon/Hisilicon/D06: Drop _CID for fwts issue >Silicon/Hisilicon/D06: Add watchdog to GTDT >Silicon/Hisilicon/D06: Fix fwts issue in Dbg2 >Silicon/Hisilicon/D06: Fix fwts issue in FADT >Silicon/Hisilicon/D06: Reserve ECAM resource in DSDT >Silicon/Hisilicon/D06: Modify GTDT timer flag >Hisilicon/D06: Correct HIDs/UIDs of PCI host bridges > > Reviewed-by: Leif Lindholm > > Pushed as 46d3a977b9..ce4f7528ed. > > Please rebase on new master and address comments for v3. > If you can merge > Silicon/Hisilicon/D06: Set TA as Node 0 for TA boot > and > Hisilicon/D06: Modify Gic base > as requested and get those sent out before I start work tomorrow, > we are in pretty good shape for me to roll out an -rc1 tomorrow. > (Which would be good, because I hope to have Wednesday-Friday as > holiday :) > > If you can also address "Fix secure boot bug in FlashFvbDxe", that > should be all remaining functional changes. I have address all comment include "Fix secure boot bug in FlashFvbDxe". > > FYI: I am now working against edk2 tag edk2-stable201811. I update edk2 to edk2-stable201811, but can't build in my build server, maybe my build environment has some problems, it can build with edk2 commit (52437cb7633b Star Zeng 2018-08-01 10:15:45). Build error log: --- huangming@EstBuildSvr1:~/source/new$ ./uefi-tools/edk2-build.sh d06 Loading previous configuration from /home/huangming/source/new/edk2/Conf/BuildEnv.sh WORKSPACE: /home/huangming/source/new EDK_TOOLS_PATH: /home/huangming/source/new/edk2/BaseTools CONF_PATH: /home/huangming/source/new/edk2/Conf Copying $EDK_TOOLS_PATH/Conf/build_rule.template to /home/huangming/source/new/edk2/Conf/build_rule.txt Copying $EDK_TOOLS_PATH/Conf/tools_def.template to /home/huangming/source/new/edk2/Conf/tools_def.txt Copying $EDK_TOOLS_PATH/Conf/target.template to /home/huangming/source/new/edk2/Conf/target.txt make: Entering directory '/home/huangming/source/new/edk2/BaseTools' make -C Source/C make[1]: Entering directory '/home/huangming/source/new/edk2/BaseTools/Source/C' Attempting to detect HOST_ARCH from 'uname -m': x86_64 Detected HOST_ARCH of X64 using uname. mkdir -p . make -C Common make[2]: Entering directory '/home/huangming/source/new/edk2/BaseTools/Source/C/Common' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/home/huangming/source/new/edk2/BaseTools/Source/C/Common' make -C BrotliCompress make[2]: Entering directory '/home/huangming/source/new/edk2/BaseTools/Source/C/BrotliCompress' make[2]: *** No rule to make target 'common/././types.h', needed by 'common/dictionary.o'. Stop. make[2]: Leaving directory '/home/huangming/source/new/edk2/BaseTools/Source/C/BrotliCompress' GNUmakefile:85: recipe for target 'BrotliCompress' failed make[1]: *** [BrotliCompress] Error 2 make[1]: Leaving directory '/home/huangming/source/new/edk2/BaseTools/Source/C' GNUmakefile:25: recipe for target 'Source/C' failed make: *** [Source/C] Error 2 make: Leaving directory '/home/huangming/source/new/edk2/BaseTools' /home/huangming/source/new !!! BaseTools failed to build !!! --- > > / > Leif > >> Silicon/Hisilicon/HisiPkg.dec >> |1 + >> Platform/Hisilicon/D03/D03.dsc >> |5 + >> Platform/Hisilicon/D05/D05.dsc >> |5 + >> Platform/Hisilicon/D06/D06.dsc
Re: [edk2] [PATCH edk2-platforms v2 10/15] Hisilicon/D06: Modify Gic base
On 11/20/2018 2:20 AM, Leif Lindholm wrote:
> You said in reply to my comment on v1:
>
> ---
> The PcdGicInterruptInterfaceBase(0xFE00) is wrong, it just copy
> from D05/D03,
> maybe somewhere will need the right value of Pcd.
> ---
>
> Please split that out as a separate change, with the above mentioned
> in the commit message.
OK
>
> But if I understand correctly, the remainder of the patch will be
> incorrect until the other changes to book from TA have been applied
> (in the subsequent patch).
> So please move the MADT change to the other patch.
D06 had been boot from TA from last series (Upload for D06 platform).
Silicon/Hisilicon/D06: Set TA as Node 0 for TA boot
and
Hisilicon/D06: Modify Gic base
are tow important patches missed by last series.
>
> /
> Leif
>
> On Fri, Nov 16, 2018 at 02:56:57PM +0800, Ming Huang wrote:
>> The values of PcdGicInterruptInterfaceBase and GICD are wrong, so modify it.
>> Fix SBSA test case 21:
>> 21 : Check GIC version
>> GIC version is 0
>> Failed on PE -0 for Level= 3 : Result: --FAIL-- 2
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ming Huang
>> ---
>> Platform/Hisilicon/D06/D06.dsc| 2 +-
>> Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/MadtHi1620.aslc | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/Platform/Hisilicon/D06/D06.dsc b/Platform/Hisilicon/D06/D06.dsc
>> index b6ef9fedf0a7..ac35564f4ac6 100644
>> --- a/Platform/Hisilicon/D06/D06.dsc
>> +++ b/Platform/Hisilicon/D06/D06.dsc
>> @@ -183,7 +183,7 @@ [PcdsFixedAtBuild.common]
>>gHisiTokenSpaceGuid.PcdArmPrimaryCoreTemp|0x8001
>>gArmTokenSpaceGuid.PcdGicDistributorBase|0xAE00
>>gArmTokenSpaceGuid.PcdGicRedistributorsBase|0xAE10
>> - gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase|0xFE00
>> + gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase|0x9B00
>>
>>
>>
>> diff --git a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/MadtHi1620.aslc
>> b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/MadtHi1620.aslc
>> index 43b43142aff4..d3de69a3ef6c 100644
>> --- a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/MadtHi1620.aslc
>> +++ b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/MadtHi1620.aslc
>> @@ -361,7 +361,7 @@ EFI_ACPI_MULTIPLE_APIC_DESCRIPTION_TABLE Madt = {
>> 0x0, 0x0, 25, 0x4000AA00 + 0x6C /* GicRBase */, 0),
>>},
>>
>> - EFI_ACPI_6_1_GIC_DISTRIBUTOR_INIT(0, 0xAA00, 0, 0x4),
>> + EFI_ACPI_6_1_GIC_DISTRIBUTOR_INIT(0, 0xAE00, 0, 0x4),
>>{
>> EFI_ACPI_6_1_GIC_ITS_INIT(0,0x20210), //peri a
>> //EFI_ACPI_6_1_GIC_ITS_INIT(1,0x40020210), //peri a
>> --
>> 2.9.5
>>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 1/1] MdePkg ACPI: fix the typos in Acpi61.h and Acpi62.h
The GUID for VIRTUAL_CD_REGION_PERSISTENT was using the closing
square bracket mistakenly.
Cc: Michael D Kinney
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Gary Lin
---
MdePkg/Include/IndustryStandard/Acpi61.h | 2 +-
MdePkg/Include/IndustryStandard/Acpi62.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/MdePkg/Include/IndustryStandard/Acpi61.h
b/MdePkg/Include/IndustryStandard/Acpi61.h
index b2276b7d64d5..c66566e58647 100644
--- a/MdePkg/Include/IndustryStandard/Acpi61.h
+++ b/MdePkg/Include/IndustryStandard/Acpi61.h
@@ -1400,7 +1400,7 @@ typedef struct {
#define
EFI_ACPI_6_1_NFIT_GUID_RAM_DISK_SUPPORTING_VIRTUAL_DISK_REGION_VOLATILE {
0x77AB535A, 0x45FC, 0x624B, { 0x55, 0x60, 0xF7, 0xB2, 0x81, 0xD1, 0xF9, 0x6E }}
#define EFI_ACPI_6_1_NFIT_GUID_RAM_DISK_SUPPORTING_VIRTUAL_CD_REGION_VOLATILE
{ 0x3D5ABD30, 0x4175, 0x87CE, { 0x6D, 0x64, 0xD2, 0xAD, 0xE5, 0x23, 0xC4,
0xBB }}
#define
EFI_ACPI_6_1_NFIT_GUID_RAM_DISK_SUPPORTING_VIRTUAL_DISK_REGION_PERSISTENT {
0x5CEA02C9, 0x4D07, 0x69D3, { 0x26, 0x9F ,0x44, 0x96, 0xFB, 0xE0, 0x96, 0xF9 }}
-#define
EFI_ACPI_6_1_NFIT_GUID_RAM_DISK_SUPPORTING_VIRTUAL_CD_REGION_PERSISTENT {
0x08018188, 0x42CD, 0xBB48, { 0x10, 0x0F, 0x53, 0x87, 0xD5, 0x3D, 0xED, 0x3D ]}
+#define
EFI_ACPI_6_1_NFIT_GUID_RAM_DISK_SUPPORTING_VIRTUAL_CD_REGION_PERSISTENT {
0x08018188, 0x42CD, 0xBB48, { 0x10, 0x0F, 0x53, 0x87, 0xD5, 0x3D, 0xED, 0x3D }}
typedef struct {
UINT16 Type;
UINT16 Length;
diff --git a/MdePkg/Include/IndustryStandard/Acpi62.h
b/MdePkg/Include/IndustryStandard/Acpi62.h
index 730365b521d1..11ce1c16fb91 100644
--- a/MdePkg/Include/IndustryStandard/Acpi62.h
+++ b/MdePkg/Include/IndustryStandard/Acpi62.h
@@ -1512,7 +1512,7 @@ typedef struct {
#define
EFI_ACPI_6_2_NFIT_GUID_RAM_DISK_SUPPORTING_VIRTUAL_DISK_REGION_VOLATILE {
0x77AB535A, 0x45FC, 0x624B, { 0x55, 0x60, 0xF7, 0xB2, 0x81, 0xD1, 0xF9, 0x6E }}
#define EFI_ACPI_6_2_NFIT_GUID_RAM_DISK_SUPPORTING_VIRTUAL_CD_REGION_VOLATILE
{ 0x3D5ABD30, 0x4175, 0x87CE, { 0x6D, 0x64, 0xD2, 0xAD, 0xE5, 0x23, 0xC4,
0xBB }}
#define
EFI_ACPI_6_2_NFIT_GUID_RAM_DISK_SUPPORTING_VIRTUAL_DISK_REGION_PERSISTENT {
0x5CEA02C9, 0x4D07, 0x69D3, { 0x26, 0x9F ,0x44, 0x96, 0xFB, 0xE0, 0x96, 0xF9 }}
-#define
EFI_ACPI_6_2_NFIT_GUID_RAM_DISK_SUPPORTING_VIRTUAL_CD_REGION_PERSISTENT {
0x08018188, 0x42CD, 0xBB48, { 0x10, 0x0F, 0x53, 0x87, 0xD5, 0x3D, 0xED, 0x3D ]}
+#define
EFI_ACPI_6_2_NFIT_GUID_RAM_DISK_SUPPORTING_VIRTUAL_CD_REGION_PERSISTENT {
0x08018188, 0x42CD, 0xBB48, { 0x10, 0x0F, 0x53, 0x87, 0xD5, 0x3D, 0xED, 0x3D }}
typedef struct {
UINT16 Type;
UINT16 Length;
--
2.19.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v4 0/4] SdMmcOverride extension
wt., 20 lis 2018 o 06:59 Wu, Hao A napisał(a):
>
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Wu, Hao A
> > Sent: Tuesday, November 13, 2018 4:29 PM
> > To: Marcin Wojtas
> > Cc: Tomasz Michalec; Grzegorz Jaszczyk; edk2-devel-01; Gao, Liming;
> > nad...@marvell.com; Kinney, Michael D
> > Subject: Re: [edk2] [PATCH v4 0/4] SdMmcOverride extension
> >
> > > -Original Message-
> > > From: Marcin Wojtas [mailto:m...@semihalf.com]
> > > Sent: Tuesday, November 13, 2018 4:25 PM
> > > To: Wu, Hao A
> > > Cc: edk2-devel-01; Leif Lindholm; Kinney, Michael D; Gao, Liming; Ard
> > > Biesheuvel; nad...@marvell.com; j...@semihalf.com; Tomasz Michalec;
> > > Grzegorz Jaszczyk
> > > Subject: Re: [PATCH v4 0/4] SdMmcOverride extension
> > >
> > > Hi Hao,
> > >
> > > wt., 13 lis 2018 o 08:38 Wu, Hao A napisał(a):
> > > >
> > > > Hi Marcin,
> > > >
> > > > The code changes look good to me.
> > > >
> > > > Could you please grant me some time for some additional tests for these
> > > > patches?
> > >
> > > Sure.
> > >
> > > > I will inform you with the results sometime next week. Thanks in
> > > > advance.
> > > >
> > >
> > > Ard gave his RB to 2/4 and 3/4. Moreover he pointed a typo in 3/4
> > > commit message - should I repost, or could those be included when
> > > applying the patches (unless you don't request any code change, of
> > > course)?
> >
> > If no other issues, I will help to address the typo issue in patch 3/4.
> >
> > A little concern on the commit author information if I modify the commit,
> > but
> > I will let you know if a repost from you is needed.
> >
> > Best Regards,
> > Hao Wu
>
> For the series:
> Reviewed-by: Hao Wu
>
> Pushed at 49c9953425..7f3b0bad4b
>
Thanks a lot!
Marcin
>
> Best Regards,
> Hao Wu
>
> >
> > >
> > > Best regards,
> > > Marcin
> > >
> > > > Best Regards,
> > > > Hao Wu
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Marcin Wojtas [mailto:m...@semihalf.com]
> > > > > Sent: Saturday, November 10, 2018 7:01 AM
> > > > > To: edk2-devel@lists.01.org
> > > > > Cc: leif.lindh...@linaro.org; Wu, Hao A; Kinney, Michael D; Gao,
> > > > > Liming;
> > > > > ard.biesheu...@linaro.org; nad...@marvell.com; m...@semihalf.com;
> > > > > j...@semihalf.com; t...@semihalf.com; j...@semihalf.com
> > > > > Subject: [PATCH v4 0/4] SdMmcOverride extension
> > > > >
> > > > > Hi,
> > > > >
> > > > > Although I could've waited for Hao's remarks, I think it may
> > > > > be better if he takes a look at much cleaner code, which
> > > > > addresses v3 review comments.
> > > > > The newest version of the patchset cleans-up significantly
> > > > > patches 2&3 by removing code duplication and other minor
> > > > > improvements.
> > > > >
> > > > > Patches are available in the github:
> > > > > https://github.com/MarvellEmbeddedProcessors/edk2-open-
> > > > > platform/commits/sdmmc-override-upstream-r20181109
> > > > >
> > > > > Please note that extending SdMmcOverride protocol was impacting
> > > > > so far the only user of it (Synquacer controller). In paralel
> > > > > edk2-platforms patchset, a patch can be found:
> > > > > ("Silicon/SynQuacer/PlatformDxe: adjust to updated SdMmcOverride")
> > > > > which adjust to the new API.
> > > > > https://github.com/MarvellEmbeddedProcessors/edk2-open-
> > > > > platform/commits/xenon-upstream-r20181109
> > > > >
> > > > > I'm looking forward to the comments and remarks.
> > > > >
> > > > > Best regards,
> > > > > Marcin
> > > > >
> > > > > Changelog:
> > > > > v3->v4
> > > > > * 2/4:
> > > > > - avoid duplication by calling SdMmcOverride callback in
> > > > > SdMmcHcUhsSignaling
> > > > >
> > > > > * 3/4:
> > > > > - avoid duplication by calling SdMmcOverride callback in
> > > > > EmmcSwitchClockFreq
> > > > >
> > > > > * 4/4:
> > > > > - add Ard's RB
> > > > >
> > > > > v2->v3
> > > > > * 1/4:
> > > > > - rename new parameter to PhaseData
> > > > > - add Ard's RB
> > > > >
> > > > > * 2/4:
> > > > > - s/Controler/Controller/
> > > > > - remove all references to MMC_SDR_50 mode
> > > > > - rename and reorder MMC bus modes
> > > > > - rename enum: s/SD_MMC_UHS_TIMING/SD_MMC_BUS_MODE/
> > > > > and move it to protocol header in order to drop including private
> > > > > one
> > > > > - fix if condition in EmmcSwitchToHighSpeed
> > > > > - call SdMmcHcUhsSignaling unconditionally before SdMmcOverride
> > > > > callback, so that protocol producer can optionally modify only
> > > > > quirky
> > > > > timing mode values.
> > > > >
> > > > > *4/4
> > > > > - bump protocol version to 2
> > > > > - remove redundant assert from SdMmcPciHcDriverBindingStart
> > > > > (BaseClkFreq is already checked in SdMmcHcInitClockFreq)
> > > > > - update comment in SdMmcHcInitClockFreq
> > > > > - restore original DumpCapabilityReg and append
> > > > >
> > > > > v1 -> v2
> > > > > * Rebase onto newest master
> > > > > * 1/4 [new patch] - prepar
Re: [edk2] [edk2-test][RFC PATCH 11/12] uefi-sct/SctPkg: sbbr: Bugfix for MemoryMap Check Test.
Add the maintainer Supreeth.
Hello Sakar,
Thank for the patches in this series.
The common comments is:
The keyword 'SBBR' exists on the FilePath or in the FileName. But 'SBBR' string
or related description is not mentioned in UEFI spec at all.
Could you please add more detail for the checkpoint requirement in the UEFI
spec? Please remove the 'SBBR' in the new patch.
If the checkpoint is not related to UEFI spec, uefi-sct/sctpkg may not be the
proper space for these patch landing. Thanks.
Best Regards
Eric
-Original Message-
From: edk2-devel On Behalf Of Sakar Arora
Sent: Tuesday, November 6, 2018 4:48 PM
To: edk2-devel@lists.01.org
Cc: prasanth.pu...@arm.com
Subject: [edk2] [edk2-test][RFC PATCH 11/12] uefi-sct/SctPkg: sbbr: Bugfix for
MemoryMap Check Test.
As per SBBR specification, "A UEFI runtime environment compliant with SBBR must
not be written with any assumption of an identity mapping between virtual and
physical memory maps."
Test case implementation was failing the test, if it is not identity mapped,
which is incorrect.
Corrected test case to warn the user that UEFI runtime environment is identity
mapped, instead of failure.
Signed-off-by: Sakar Arora
Reported-by: Felix Poludov
---
.../SbbrBootServices/BlackBoxTest/SbbrBootServicesBBTestFunction.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/SbbrBootServices/BlackBoxTest/SbbrBootServicesBBTestFunction.c
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/SbbrBootServices/BlackBoxTest/SbbrBootServicesBBTestFunction.c
index fb50702..c88d60b 100644
---
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/SbbrBootServices/BlackBoxTest/SbbrBootServicesBBTestFunction.c
+++ b/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/SbbrBootServices/Bl
+++ ackBoxTest/SbbrBootServicesBBTestFunction.c
@@ -201,13 +201,13 @@ BBTestMemoryMapTest (
//
// Checking for identity mapping
//
-if (MemoryMapDescriptor->PhysicalStart !=
MemoryMapDescriptor->VirtualStart) {
+if (MemoryMapDescriptor->PhysicalStart ==
+ MemoryMapDescriptor->VirtualStart) {
StandardLib->RecordAssertion (
StandardLib,
- EFI_TEST_ASSERTION_FAILED,
+ EFI_TEST_ASSERTION_WARNING,
gSbbrBootServicesAssertion001Guid,
L"MemoryMap",
- L"%a:%d - MemoryMap 0x%X Not Identity Mapped",
+ L"%a:%d - MemoryMap 0x%X is Identity Mapped. UEFI
+ runtime environment must not be written with any assumption of an
+ identity mapping between virtual and physical memory maps.",
__FILE__,
__LINE__,
MemoryMapDescriptor
--
2.7.4
___
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
