Re: [edk2] [Patch] BaseTools: Add support for $(FAMILY) macro

2016-07-04 Thread Gao, Liming
Reviewed-by: Liming Gao 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Yonghong Zhu
> Sent: Monday, July 04, 2016 5:27 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming 
> Subject: [edk2] [Patch] BaseTools: Add support for $(FAMILY) macro
> 
> Build spec mentions $(FAMILY) macro be used in DSC/FDF to specify the tool
> chain family, like GCC, MSFT. This patch add the support for this macro.
> 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Yonghong Zhu 
> ---
>  BaseTools/Source/Python/build/build.py | 23 +++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/BaseTools/Source/Python/build/build.py
> b/BaseTools/Source/Python/build/build.py
> index 4f859bf..d9afdcc 100644
> --- a/BaseTools/Source/Python/build/build.py
> +++ b/BaseTools/Source/Python/build/build.py
> @@ -784,10 +784,11 @@ class Build():
>  self.Db = WorkspaceDatabase(":memory:")
>  else:
>  self.Db = WorkspaceDatabase(GlobalData.gDatabasePath,
> self.Reparse)
>  self.BuildDatabase = self.Db.BuildObject
>  self.Platform = None
> +self.ToolChainFamily = None
>  self.LoadFixAddress = 0
>  self.UniFlag= BuildOptions.Flag
>  self.BuildModules = []
>  self.Db_Flag = False
>  self.LaunchPrebuildFlag = False
> @@ -876,10 +877,21 @@ class Build():
>  EdkLogger.error("build", RESOURCE_NOT_AVAILABLE,
>  ExtraData="[%s] not defined. No toolchain 
> available for
> build!\n" % ", ".join(self.ToolChainList))
>  else:
>  self.ToolChainList = NewToolChainList
> 
> +ToolChainFamily = []
> +ToolDefinition = self.ToolDef.ToolsDefTxtDatabase
> +for Tool in self.ToolChainList:
> +if TAB_TOD_DEFINES_FAMILY not in ToolDefinition or Tool not in
> ToolDefinition[TAB_TOD_DEFINES_FAMILY] \
> +   or not ToolDefinition[TAB_TOD_DEFINES_FAMILY][Tool]:
> +EdkLogger.warn("No tool chain family found in configuration 
> for %s.
> Default to MSFT." % Tool)
> +ToolChainFamily.append("MSFT")
> +else:
> +
> ToolChainFamily.append(ToolDefinition[TAB_TOD_DEFINES_FAMILY][Tool])
> +self.ToolChainFamily = ToolChainFamily
> +
>  if self.ThreadNumber == None:
>  self.ThreadNumber =
> self.TargetTxt.TargetTxtDictionary[DataType.TAB_TAT_DEFINES_MAX_CONC
> URRENT_THREAD_NUMBER]
>  if self.ThreadNumber == '':
>  self.ThreadNumber = 0
>  else:
> @@ -934,10 +946,12 @@ class Build():
>  if self.ArchList:
>  GlobalData.gGlobalDefines['ARCH'] = self.ArchList[0]
>  if self.ToolChainList:
>  GlobalData.gGlobalDefines['TOOLCHAIN'] = self.ToolChainList[0]
>  GlobalData.gGlobalDefines['TOOL_CHAIN_TAG'] = 
> self.ToolChainList[0]
> +if self.ToolChainFamily:
> +GlobalData.gGlobalDefines['FAMILY'] = self.ToolChainFamily[0]
>  if 'PREBUILD' in GlobalData.gCommandLineDefines.keys():
>  self.Prebuild   = GlobalData.gCommandLineDefines.get('PREBUILD')
>  else:
>  self.Db.InitDatabase()
>  self.Db_Flag = True
> @@ -1597,13 +1611,16 @@ class Build():
>  #
>  def _BuildPlatform(self):
>  SaveFileOnChange(self.PlatformBuildPath, '# DO NOT EDIT \n# FILE
> auto-generated\n', False)
>  for BuildTarget in self.BuildTargetList:
>  GlobalData.gGlobalDefines['TARGET'] = BuildTarget
> +index = 0
>  for ToolChain in self.ToolChainList:
>  GlobalData.gGlobalDefines['TOOLCHAIN'] = ToolChain
>  GlobalData.gGlobalDefines['TOOL_CHAIN_TAG'] = ToolChain
> +GlobalData.gGlobalDefines['FAMILY'] = 
> self.ToolChainFamily[index]
> +index += 1
>  Wa = WorkspaceAutoGen(
>  self.WorkspaceDir,
>  self.PlatformFile,
>  BuildTarget,
>  ToolChain,
> @@ -1677,13 +1694,16 @@ class Build():
>  ## Build active module for different build targets, different tool 
> chains and
> different archs
>  #
>  def _BuildModule(self):
>  for BuildTarget in self.BuildTargetList:
>  GlobalData.gGlobalDefines['TARGET'] = BuildTarget
> +index = 0
>  for ToolChain in self.ToolChainList:
>  GlobalData.gGlobalDefines['TOOLCHAIN'] = ToolChain
>  GlobalData.gGlobalDefines['TOOL_CHAIN_TAG'] = ToolChain
> +GlobalData.gGlobalDefines['FAMILY'] = 
> self.ToolChainFamily[index]
> +index += 1
>  #
>  # module build needs platform build information, so get 
> platform
>  # AutoGen first
> 

Re: [edk2] [PATCH v2] MdeModulePkg UefiPxeBcDxe: Fix build error for lastest VS2015 compiler

2016-07-04 Thread Fu, Siyuan
Reviewed-by: Fu Siyuan 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Hao
> Wu
> Sent: Tuesday, July 5, 2016 12:59 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Ye, Ting ; Fu,
> Siyuan ; Wu, Jiaxin 
> Subject: [edk2] [PATCH v2] MdeModulePkg UefiPxeBcDxe: Fix build error for
> lastest VS2015 compiler
> 
> The UefiPxeBcDxe module encounters a build error for IA32 arch using the
> latest version of VS2015:
> 
> UefiPxe4BcDxe.lib(PxeBcDhcp.obj) : error LNK2001: unresolved external
> symbol __allmul
> 
> The cause is line 1659 in file
> MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c. The third
> parameter for gBS->SetTimer() function is of type UINT64, so the
> multiplication should use the MultU64x32() function.
> 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Cc: Wu Jiaxin 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Hao Wu 
> ---
>  MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
> b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
> index 3849613..eac955c 100644
> --- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
> +++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
> @@ -1656,7 +1656,7 @@ PxeBcSelectBootPrompt (
>Status = gBS->SetTimer (
>TimeoutEvent,
>TimerRelative,
> -  Timeout * TICKS_PER_SECOND
> +  MultU64x32 (Timeout, TICKS_PER_SECOND)
>);
> 
>if (EFI_ERROR (Status)) {
> --
> 1.9.5.msysgit.0
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v2] MdeModulePkg UefiPxeBcDxe: Fix build error for lastest VS2015 compiler

2016-07-04 Thread Gao, Liming
Reviewed-by: Liming Gao 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Hao Wu
> Sent: Tuesday, July 05, 2016 12:59 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Ye, Ting ; Fu,
> Siyuan ; Wu, Jiaxin 
> Subject: [edk2] [PATCH v2] MdeModulePkg UefiPxeBcDxe: Fix build error for
> lastest VS2015 compiler
> 
> The UefiPxeBcDxe module encounters a build error for IA32 arch using the
> latest version of VS2015:
> 
> UefiPxe4BcDxe.lib(PxeBcDhcp.obj) : error LNK2001: unresolved external
> symbol __allmul
> 
> The cause is line 1659 in file
> MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c. The third
> parameter for gBS->SetTimer() function is of type UINT64, so the
> multiplication should use the MultU64x32() function.
> 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Cc: Wu Jiaxin 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Hao Wu 
> ---
>  MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
> b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
> index 3849613..eac955c 100644
> --- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
> +++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
> @@ -1656,7 +1656,7 @@ PxeBcSelectBootPrompt (
>Status = gBS->SetTimer (
>TimeoutEvent,
>TimerRelative,
> -  Timeout * TICKS_PER_SECOND
> +  MultU64x32 (Timeout, TICKS_PER_SECOND)
>);
> 
>if (EFI_ERROR (Status)) {
> --
> 1.9.5.msysgit.0
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH] Vlv2TbltDevicePkg: Enabled spectrum control by default and hide it in setup screen.

2016-07-04 Thread Guo, Mang
Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Guo Mang 
---
 Vlv2TbltDevicePkg/PlatformSetupDxe/SouthClusterConfig.vfi | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/Vlv2TbltDevicePkg/PlatformSetupDxe/SouthClusterConfig.vfi 
b/Vlv2TbltDevicePkg/PlatformSetupDxe/SouthClusterConfig.vfi
index 258bd6f..7a10840 100644
--- a/Vlv2TbltDevicePkg/PlatformSetupDxe/SouthClusterConfig.vfi
+++ b/Vlv2TbltDevicePkg/PlatformSetupDxe/SouthClusterConfig.vfi
@@ -870,13 +870,14 @@ form formid = MISC_OPTIONS_FORM_ID,
  option text = STRING_TOKEN(STR_S5_AFTER_G3_STRING), value = 1, flags = 
MANUFACTURING | RESET_REQUIRED;
   endoneof;
 
+  suppressif TRUE;
   oneof varid  = Setup.EnableClockSpreadSpec,
  prompt   = STRING_TOKEN(STR_CLOCK_SPREAD_SPEC_ENABLE),
  help = STRING_TOKEN(STR_CLOCK_SPREAD_SPEC_ENABLE_HELP),
- option text = STRING_TOKEN(STR_DISABLE), value = 0, flags = DEFAULT | 
MANUFACTURING | RESET_REQUIRED;
- option text = STRING_TOKEN(STR_ENABLE), value = 1, flags = RESET_REQUIRED;
+ option text = STRING_TOKEN(STR_DISABLE), value = 0, flags = 
RESET_REQUIRED;
+ option text = STRING_TOKEN(STR_ENABLE), value = 1, flags =DEFAULT | 
MANUFACTURING | RESET_REQUIRED;
   endoneof;
-
+  endif;
 
   oneof varid  = Setup.UartInterface,
 prompt   = STRING_TOKEN(STR_PCH_UART_SELECT),
-- 
2.8.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH v2] MdeModulePkg UefiPxeBcDxe: Fix build error for lastest VS2015 compiler

2016-07-04 Thread Hao Wu
The UefiPxeBcDxe module encounters a build error for IA32 arch using the
latest version of VS2015:

UefiPxe4BcDxe.lib(PxeBcDhcp.obj) : error LNK2001: unresolved external
symbol __allmul

The cause is line 1659 in file
MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c. The third
parameter for gBS->SetTimer() function is of type UINT64, so the
multiplication should use the MultU64x32() function.

Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Wu Jiaxin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c 
b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
index 3849613..eac955c 100644
--- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
+++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
@@ -1656,7 +1656,7 @@ PxeBcSelectBootPrompt (
   Status = gBS->SetTimer (
   TimeoutEvent,
   TimerRelative,
-  Timeout * TICKS_PER_SECOND
+  MultU64x32 (Timeout, TICKS_PER_SECOND)
   );
 
   if (EFI_ERROR (Status)) {
-- 
1.9.5.msysgit.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [patch 2/2] MdeModulePkg/Ui: Add ASSERT before using the pointer "Buffer"

2016-07-04 Thread Dandan Bi
Pointer "Buffer" is returned by function HiiGetFormSetFromHiiHandle,
when the function HiiGetFormSetFromHiiHandle return success, the
"Buffer" can not be NULL, so we add the ASSET codes.

Cc: Eric Dong 
Cc: Hao Wu 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
---
 MdeModulePkg/Application/UiApp/FrontPageCustomizedUiSupport.c  | 1 +
 .../BootMaintenanceManagerCustomizedUiSupport.c| 1 +
 MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c| 3 ++-
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Application/UiApp/FrontPageCustomizedUiSupport.c 
b/MdeModulePkg/Application/UiApp/FrontPageCustomizedUiSupport.c
index 93f6e4e..5a2762f 100644
--- a/MdeModulePkg/Application/UiApp/FrontPageCustomizedUiSupport.c
+++ b/MdeModulePkg/Application/UiApp/FrontPageCustomizedUiSupport.c
@@ -519,10 +519,11 @@ RequiredDriver (
 
   Status = HiiGetFormSetFromHiiHandle(HiiHandle, &Buffer,&BufferSize);
   if (EFI_ERROR (Status)) {
 return FALSE;
   }
+  ASSERT (Buffer != NULL);
 
   RetVal = FALSE;
   TempSize = 0;
   Ptr = (UINT8 *) Buffer;
   while(TempSize < BufferSize)  {
diff --git 
a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerCustomizedUiSupport.c
 
b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerCustomizedUiSupport.c
index b25bc67..c8978af 100644
--- 
a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerCustomizedUiSupport.c
+++ 
b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerCustomizedUiSupport.c
@@ -316,10 +316,11 @@ IsRequiredDriver (
 
   Status = HiiGetFormSetFromHiiHandle(HiiHandle, &Buffer,&BufferSize);
   if (EFI_ERROR (Status)) {
 return FALSE;
   }
+  ASSERT (Buffer != NULL);
 
   RetVal = FALSE;
   TempSize = 0;
   Ptr = (UINT8 *) Buffer;
   while(TempSize < BufferSize)  {
diff --git a/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c 
b/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
index 0de4e3c..ee8b4fb 100644
--- a/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
+++ b/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
@@ -1,9 +1,9 @@
 /** @file
 The device manager reference implementation
 
-Copyright (c) 2004 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2004 - 2016, 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
 
@@ -574,10 +574,11 @@ CreateDeviceManagerForm(
   for (Index = 0; HiiHandles[Index] != NULL; Index++) {
 Status = HiiGetFormSetFromHiiHandle(HiiHandles[Index], 
&Buffer,&BufferSize);
 if (EFI_ERROR (Status)){
   continue;
 }
+ASSERT (Buffer != NULL);
 Ptr = (UINT8 *)Buffer;
 while(TempSize < BufferSize)  {
   TempSize += ((EFI_IFR_OP_HEADER *) Ptr)->Length;
   if (((EFI_IFR_OP_HEADER *) Ptr)->Length <= OFFSET_OF (EFI_IFR_FORM_SET, 
Flags)){
 Ptr += ((EFI_IFR_OP_HEADER *) Ptr)->Length;
-- 
1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [patch 0/2]MdeModulePkg: Add error handling codes in function HiiGetFormSetFromHiiHandle

2016-07-04 Thread Dandan Bi
Patch 1 is to enhance the error handling codes in function 
HiiGetFormSetFromHiiHandle 
Patch 2 is enhance the logic in the caller functions of 
HiiGetFormSetFromHiiHandle.

Cc: Eric Dong 
Cc: Hao Wu 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 

Dandan Bi (2):
  MdeModulePkg/UefiHiiLib: Add error handling codes when
AllocateCopyPool fail
  MdeModulePkg/Ui: Add ASSERT before using the pointer "Buffer"

 .../Application/UiApp/FrontPageCustomizedUiSupport.c   |  1 +
 .../BootMaintenanceManagerCustomizedUiSupport.c|  1 +
 MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c|  3 ++-
 MdeModulePkg/Library/UefiHiiLib/HiiLib.c   | 14 --
 4 files changed, 16 insertions(+), 3 deletions(-)

-- 
1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [patch 1/2] MdeModulePkg/UefiHiiLib: Add error handling codes when AllocatePool fail

2016-07-04 Thread Dandan Bi
Cc: Eric Dong 
Cc: Hao Wu 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
---
 MdeModulePkg/Library/UefiHiiLib/HiiLib.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Library/UefiHiiLib/HiiLib.c 
b/MdeModulePkg/Library/UefiHiiLib/HiiLib.c
index 74ccd02..afd9985 100644
--- a/MdeModulePkg/Library/UefiHiiLib/HiiLib.c
+++ b/MdeModulePkg/Library/UefiHiiLib/HiiLib.c
@@ -1,9 +1,9 @@
 /** @file
   HII Library implementation that uses DXE protocols and services.
 
-  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2006 - 2016, 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
 
@@ -463,14 +463,23 @@ HiiGetFormSetFromHiiHandle(
 continue;
   }
 
   if (FormSetBuffer != NULL){
 TempBuffer = AllocateCopyPool (TempSize + ((EFI_IFR_OP_HEADER *) 
OpCodeData)->Length, FormSetBuffer);
-CopyMem (TempBuffer + TempSize,  OpCodeData, ((EFI_IFR_OP_HEADER *) 
OpCodeData)->Length);
 FreePool(FormSetBuffer);
+FormSetBuffer = NULL;
+if (TempBuffer == NULL) {
+  Status = EFI_OUT_OF_RESOURCES;
+  goto Done;
+}
+CopyMem (TempBuffer + TempSize,  OpCodeData, ((EFI_IFR_OP_HEADER *) 
OpCodeData)->Length);
   } else {
 TempBuffer = AllocateCopyPool (TempSize + ((EFI_IFR_OP_HEADER *) 
OpCodeData)->Length, OpCodeData);
+if (TempBuffer == NULL) {
+  Status = EFI_OUT_OF_RESOURCES;
+  goto Done;
+}
   }
   TempSize += ((EFI_IFR_OP_HEADER *) OpCodeData)->Length;
   FormSetBuffer = TempBuffer;
 
   Status = EFI_SUCCESS;
@@ -478,10 +487,11 @@ HiiGetFormSetFromHiiHandle(
   //One form package has one formset, exit current form package to search 
other form package in the packagelist.
   //
   break;
 }
   }
+Done:
   FreePool (HiiPackageList);
 
   *BufferSize = TempSize;
   *Buffer = (EFI_IFR_FORM_SET *)FormSetBuffer;
 
-- 
1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [patch 2/2] IntelFrameworkModulePkg/LegacyUi: Get legacy options when open legacy form

2016-07-04 Thread Dandan Bi
The LegacyBootMaintUiLib depends on the LegacyBootManagerLib to realize its
functionality, the LegacyBootManagerLib may initialize after 
LegacyBootMaintUiLib, so the functionality of LegacyBootMaintUiLib may 
be incorrect. Now we fix this issue by executing the related codes when 
opening the legacy forminstead in its the constructor function. Because 
when opening the legacy form, the LegacyBootManagerLib must have been 
initialized.

Cc: Liming Gao 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Eric Dong 
---
 .../LegacyBootMaintUiLib/LegacyBootMaintUi.c   | 42 ++
 1 file changed, 36 insertions(+), 6 deletions(-)

diff --git 
a/IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUi.c 
b/IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUi.c
index 3a3eeed..5e1ad54 100644
--- a/IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUi.c
+++ b/IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUi.c
@@ -17,10 +17,11 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 LEGACY_BOOT_OPTION_CALLBACK_DATA  *mLegacyBootOptionPrivate;
 EFI_GUID  mLegacyBootOptionGuid = LEGACY_BOOT_OPTION_FORMSET_GUID;
 CHAR16mLegacyBootStorageName[]  = L"LegacyBootData";
 BBS_TYPE  mBbsType[] = {BBS_FLOPPY, BBS_HARDDISK, BBS_CDROM, 
BBS_EMBED_NETWORK, BBS_BEV_DEVICE, BBS_UNKNOWN};
+BOOLEAN   mFirstEnterLegacyForm = FALSE;
 
 
 ///
 /// Legacy FD Info from LegacyBios.GetBbsInfo()
 ///
@@ -93,10 +94,30 @@ HII_VENDOR_DEVICE_PATH  
mLegacyBootOptionHiiVendorDevicePath = {
   (UINT8) ((END_DEVICE_PATH_LENGTH) >> 8)
 }
   }
 };
 
+/**
+
+  Build the LegacyFDMenu LegacyHDMenu LegacyCDMenu according to 
LegacyBios.GetBbsInfo().
+
+**/
+VOID
+GetLegacyOptions (
+  VOID
+  );
+
+
+/**
+
+  Base on the L"LegacyDevOrder" variable to build the current order data.
+
+**/
+VOID
+GetLegacyOptionsOrder (
+  VOID
+  );
 
 /**
   Re-order the Boot Option according to the DevOrder.
 
   The routine re-orders the Boot Option in BootOption array according to
@@ -1092,21 +1113,34 @@ LegacyBootOptionCallback (
   IN  UINT8  Type,
   IN  EFI_IFR_TYPE_VALUE *Value,
   OUT EFI_BROWSER_ACTION_REQUEST *ActionRequest
   )
 {
-  if (Action != EFI_BROWSER_ACTION_CHANGED && Action != 
EFI_BROWSER_ACTION_CHANGING) {
+  if (Action != EFI_BROWSER_ACTION_CHANGED && Action != 
EFI_BROWSER_ACTION_CHANGING && Action != EFI_BROWSER_ACTION_FORM_OPEN) {
 //
-// Do nothing for other UEFI Action. Only do call back when data is 
changed.
+// Do nothing for other UEFI Action. Only do call back when data is 
changed or the form is open.
 //
 return EFI_UNSUPPORTED;
   }
 
   if ((Value == NULL) || (ActionRequest == NULL)) {
 return EFI_INVALID_PARAMETER;
   }
 
+  if (Action == EFI_BROWSER_ACTION_FORM_OPEN) {
+if (!mFirstEnterLegacyForm) {
+  //
+  // The leagcyBootMaintUiLib depends on the LegacyBootManagerLib to 
realize its functionality.
+  // We need to do the leagcy boot options related actions after the 
LegacyBootManagerLib has been initialized.
+  // Opening the legacy menus is the appropriate time that the 
LegacyBootManagerLib has already been initialized.
+  //
+  mFirstEnterLegacyForm = TRUE;
+  GetLegacyOptions ();
+  GetLegacyOptionsOrder ();
+}
+  }
+
   if (Action == EFI_BROWSER_ACTION_CHANGING) {
 switch (QuestionId) {
 case FORM_FLOPPY_BOOT_ID:
 case FORM_HARDDISK_BOOT_ID:
 case FORM_CDROM_BOOT_ID:
@@ -1424,14 +1458,10 @@ LegacyBootMaintUiLibConstructor (
   NULL
   );
 ASSERT (LegacyBootOptionData->HiiHandle != NULL);
 
 mLegacyBootOptionPrivate = LegacyBootOptionData;
-
-GetLegacyOptions ();
-
-GetLegacyOptionsOrder();
   }
 
   return EFI_SUCCESS;
 }
 
-- 
1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [patch 1/2] MdeModulePkg/BootMaintUiLib: Update menus when open BMM form

2016-07-04 Thread Dandan Bi
BootMaintenanceManagerUiLib depend on the LeagcyBootMaintUiLib to show the
legacy menus. So we need to do the actions related to LegacyUi in BMM
after the LeagcyBootMaintUiLib have been initialized. So now : 1). update
menus (including legacy menus), 2) re-scan boot options (including legacy 
boot option) when opening the BMM form. When opening BMM form, the
LeagcyBootMaintUiLib must have been initialized.

Cc: Liming Gao 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Eric Dong 
---
 .../BootMaintenanceManagerUiLib/BootMaintenance.c  | 37 ++
 .../BootMaintenanceManager.vfr | 12 ++-
 2 files changed, 41 insertions(+), 8 deletions(-)

diff --git a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenance.c 
b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenance.c
index b35e938..e26e9e0 100644
--- a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenance.c
+++ b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenance.c
@@ -82,10 +82,11 @@ BMM_CALLBACK_DATA  gBootMaintenancePrivate = {
   }
 };
 
 BMM_CALLBACK_DATA *mBmmCallbackInfo = &gBootMaintenancePrivate;
 BOOLEAN  mAllMenuInit   = FALSE;
+BOOLEAN  mFirstEnterBMMForm = FALSE;
 
 /**
   Init all memu.
 
   @param CallbackDataThe BMM context data.
@@ -104,10 +105,20 @@ VOID
 FreeAllMenu (
   VOID
   );
 
 /**
+
+  Update the menus in the BMM page.
+
+**/
+VOID
+CustomizeMenus (
+  VOID
+  );
+
+/**
   This function will change video resolution and text mode
   according to defined setup mode or defined boot mode  
 
   @param  IsSetupMode   Indicate mode is changed to setup mode or boot mode. 
 
@@ -869,18 +880,35 @@ BootMaintCallback (
   BM_MENU_ENTRY *NewMenuEntry;
   BMM_FAKE_NV_DATA  *CurrentFakeNVMap;
   UINTN Index;
   EFI_DEVICE_PATH_PROTOCOL * File;
 
-  if (Action != EFI_BROWSER_ACTION_CHANGING && Action != 
EFI_BROWSER_ACTION_CHANGED) {
+  if (Action != EFI_BROWSER_ACTION_CHANGING && Action != 
EFI_BROWSER_ACTION_CHANGED && Action != EFI_BROWSER_ACTION_FORM_OPEN) {
 //
-// Do nothing for other UEFI Action. Only do call back when data is 
changed.
+// Do nothing for other UEFI Action. Only do call back when data is 
changed or the form is open.
 //
 return EFI_UNSUPPORTED;
   }
 
   Private= BMM_CALLBACK_DATA_FROM_THIS (This);
+
+  if (Action == EFI_BROWSER_ACTION_FORM_OPEN) {
+if (!mFirstEnterBMMForm) {
+  //
+  // BMMUiLib depends on LegacyUi library to show legacy menus.
+  // If we want to show Legacy menus correctly in BMM page,
+  // we must do it after the LegacyUi library has already been initialized.
+  // Opening the BMM form is the appropriate time that the LegacyUi 
library has already been initialized.
+  // So we do the tasks which are related to legacy menus here.
+  // 1. Update the menus (including legacy munu) show in 
BootMiantenanceManager page.
+  // 2. Re-scan the BootOption menus (including the legacy boot option).
+  //
+  CustomizeMenus ();
+  BOpt_GetBootOptions (Private);
+  mFirstEnterBMMForm = TRUE;
+}
+  }
   //
   // Retrive uncommitted data from Form Browser
   //
   CurrentFakeNVMap = &Private->BmmFakeNvData;
   HiiGetBrowserData (&mBootMaintGuid, mBootMaintStorageName, sizeof 
(BMM_FAKE_NV_DATA), (UINT8 *) CurrentFakeNVMap);
@@ -1222,15 +1250,10 @@ InitializeBmmConfig (
   GetTerminalAttribute (CallbackData);
 
   CallbackData->BmmFakeNvData.ForceReconnect = TRUE;
 
   //
-  // Update the menus.
-  //
-  CustomizeMenus ();
-
-  //
   // Backup Initialize BMM configuartion data to BmmOldFakeNVData
   //
   CopyMem (&CallbackData->BmmOldFakeNVData, &CallbackData->BmmFakeNvData, 
sizeof (BMM_FAKE_NV_DATA));
 }
 
diff --git 
a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManager.vfr 
b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManager.vfr
index d46a3e9..6262c6c 100644
--- 
a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManager.vfr
+++ 
b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManager.vfr
@@ -1,9 +1,9 @@
 ///** @file
 //  Boot Maintenance Utility Formset
 //
-//  Copyright (c) 2004 - 2015, Intel Corporation. All rights reserved.
+//  Copyright (c) 2004 - 2016, 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
 //  
@@ -25,10 +25,20 @@ formset
 name = BmmData,
 guid = BOOT_MAINT_FORMSET_GUID;
 
   form formid = FORM_MAIN_ID,
title = STRING_TOKEN(STR_FORM_MAIN_TITLE);
+   //
+   // Add this invisable text in order to indicate enter Boot Maintenance 
Manager form.
+   //
+   suppr

[edk2] [patch 0/2] MdeModulePkg/Ui: Remove the implicit dependency for libraries

2016-07-04 Thread Dandan Bi
Patch 1 remove the implicit dependency between BootMaintenanceManagerUiLib 
and LeagcyBootMaintUiLib.
Patch 2 remove the implicit dependency between LegacyBootMaintUiLib 
and LegacyBootManagerLib.

Cc: Liming Gao 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 

Dandan Bi (2):
  MdeModulePkg/BootMaintUiLib: Update menus when open BMM form
  IntelFrameworkModulePkg/LegacyUi: Get legacy options when open legacy
form

 .../LegacyBootMaintUiLib/LegacyBootMaintUi.c   | 42 ++
 .../BootMaintenanceManagerUiLib/BootMaintenance.c  | 37 +++
 .../BootMaintenanceManager.vfr | 12 ++-
 3 files changed, 77 insertions(+), 14 deletions(-)

-- 
1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Centralize TlsCaCertificate name and guid

2016-07-04 Thread Samer El Haj Mahmoud
Reviewed-by: Samer El-Haj-Mahmoud 



-Original Message-
From: Wu, Jiaxin [jiaxin...@intel.com]
Received: Monday, 04 Jul 2016, 9:45PM
To: Palmer, Thomas [thomas.pal...@hpe.com]; Wu, Jiaxin [jiaxin...@intel.com]; 
edk2-devel@lists.01.org [edk2-devel@lists.01.org]
CC: Ye, Ting [ting...@intel.com]; Fu, Siyuan [siyuan...@intel.com]
Subject: Re: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Centralize 
TlsCaCertificate name and guid

It should be "[edk2-staging/HTTPS-TLS][PATCH]".

Sorry for incorrect subject-prefix.

Jiaxin

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jiaxin Wu
> Sent: Tuesday, July 5, 2016 9:41 AM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan 
> Subject: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Centralize
> TlsCaCertificate name and guid
>
> This patch is used to centralize TlsCaCertificate name and guid to
> TlsAuthentication.h
>
> Cc: Palmer Thomas 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiaxin Wu 
> ---
>  NetworkPkg/HttpDxe/HttpDriver.h  |  2 ++
>  NetworkPkg/HttpDxe/HttpDxe.inf   |  4 
>  NetworkPkg/HttpDxe/HttpsSupport.c|  7 ++
>  NetworkPkg/HttpDxe/HttpsSupport.h| 10 
>  NetworkPkg/Include/Guid/TlsAuthentication.h  | 29
> 
>  NetworkPkg/NetworkPkg.dec|  5 +++-
>  NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf |  1 +
> NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c  | 14 +---
> NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.h  | 12 ++
>  9 files changed, 50 insertions(+), 34 deletions(-)  create mode 100644
> NetworkPkg/Include/Guid/TlsAuthentication.h
>
> diff --git a/NetworkPkg/HttpDxe/HttpDriver.h
> b/NetworkPkg/HttpDxe/HttpDriver.h index 3c30c12..73c211a 100644
> --- a/NetworkPkg/HttpDxe/HttpDriver.h
> +++ b/NetworkPkg/HttpDxe/HttpDriver.h
> @@ -58,10 +58,12 @@
>  //
>  // Produced Protocols
>  //
>  #include 
>
> +#include 
> +
>  //
>  // Driver Version
>  //
>  #define HTTP_DRIVER_VERSION 0xa
>
> diff --git a/NetworkPkg/HttpDxe/HttpDxe.inf
> b/NetworkPkg/HttpDxe/HttpDxe.inf index a228c3d..1118181 100644
> --- a/NetworkPkg/HttpDxe/HttpDxe.inf
> +++ b/NetworkPkg/HttpDxe/HttpDxe.inf
> @@ -24,10 +24,11 @@
>MODULE_UNI_FILE   = HttpDxe.uni
>
>  [Packages]
>MdePkg/MdePkg.dec
>MdeModulePkg/MdeModulePkg.dec
> +  NetworkPkg/NetworkPkg.dec
>
>  [Sources]
>ComponentName.h
>ComponentName.c
>HttpDns.h
> @@ -69,7 +70,10 @@
>gEfiIp6ConfigProtocolGuid## SOMETIMES_CONSUMES
>gEfiTlsServiceBindingProtocolGuid## SOMETIMES_CONSUMES
>gEfiTlsProtocolGuid  ## SOMETIMES_CONSUMES
>gEfiTlsConfigurationProtocolGuid ## SOMETIMES_CONSUMES
>
> +[Guids]
> +  gEfiTlsCaCertificateGuid ## CONSUMES  ## GUID
> +
>  [UserExtensions.TianoCore."ExtraFiles"]
>HttpDxeExtra.uni
> \ No newline at end of file
> diff --git a/NetworkPkg/HttpDxe/HttpsSupport.c
> b/NetworkPkg/HttpDxe/HttpsSupport.c
> index 09aaa46..36f658c 100644
> --- a/NetworkPkg/HttpDxe/HttpsSupport.c
> +++ b/NetworkPkg/HttpDxe/HttpsSupport.c
> @@ -12,12 +12,10 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF
> ANY KIND, EITHER EXPRESS OR IMPLIED.
>
>  **/
>
>  #include "HttpDriver.h"
>
> -EFI_GUID mEfiTlsCaCertificateGuid = EFI_TLS_CA_CERTIFICATE_GUID;
> -
>  /**
>Returns the first occurrence of a Null-terminated ASCII sub-string in a 
> Null-
> terminated
>ASCII string and ignore case during the search process.
>
>This function scans the contents of the ASCII string specified by String 
> @@ -
> 395,11 +393,11 @@ TlsConfigCertificate (
>// Try to read the TlsCaCertificate variable.
>//
>CACertSize = 0;
>Status  = gRT->GetVariable (
> EFI_TLS_CA_CERTIFICATE_VARIABLE,
> -   &mEfiTlsCaCertificateGuid,
> +   &gEfiTlsCaCertificateGuid,
> NULL,
> &CACertSize,
> NULL
> );
>
> @@ -412,11 +410,11 @@ TlsConfigCertificate (
>return EFI_OUT_OF_RESOURCES;
>  }
>
>  Status = gRT->GetVariable (
>  EFI_TLS_CA_CERTIFICATE_VARIABLE,
> -&mEfiTlsCaCertificateGuid,
> +&gEfiTlsCaCertificateGuid,
>  NULL,
>  &CACertSize,
>  CACert
>  );
>  if (EFI_ERROR (Status)) {
> @@ -453,11 +451,10 @@ TlsConfigCertificate (
>}
>
>Cert = (EFI_SIGNATURE_DATA *) ((UINT8 *) Cert + CertList-
> >SignatureSize);
>  }
>
> -
>  ItemDataSize -= CertList->SignatureListSize;
>  CertList = (EFI_SIGNATURE_LIST *) ((UINT8 *) CertList + CertList-
> >SignatureListSize);
>}
>
>return Status;
> diff --git a/Netwo

[edk2] [PATCH] MdeModulePkg UefiPxeBcDxe: Fix build error for lastest VS2015 compiler

2016-07-04 Thread Hao Wu
The UefiPxeBcDxe module encounters a build error for IA32 arch using the
latest version of VS2015:

UefiPxe4BcDxe.lib(PxeBcDhcp.obj) : error LNK2001: unresolved external
symbol __allmul

The cause is line 1659 in file
MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c. The third
parameter for gBS->SetTimer() function is of type UINT64, so the
multiplication should use the MultU64x64() function.

Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Wu Jiaxin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c 
b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
index 3849613..cf7a402 100644
--- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
+++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
@@ -1656,7 +1656,7 @@ PxeBcSelectBootPrompt (
   Status = gBS->SetTimer (
   TimeoutEvent,
   TimerRelative,
-  Timeout * TICKS_PER_SECOND
+  MultU64x64 ((UINT64)Timeout, TICKS_PER_SECOND)
   );
 
   if (EFI_ERROR (Status)) {
-- 
1.9.5.msysgit.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH] Vlv2TbltDevicePkg: Change SEC to new version: 1.0.3.1164.

2016-07-04 Thread Wei, David
Reviewed-by: David Wei  


Thanks,
David  Wei 

 Intel SSG BIOS Team

-Original Message-
From: Guo, Mang 
Sent: Tuesday, July 05, 2016 10:20 AM
To: edk2-devel@lists.01.org
Cc: Wei, David ; Guo, Mang 
Subject: [PATCH] Vlv2TbltDevicePkg: Change SEC to new version: 1.0.3.1164.

Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Guo Mang 
---
 Vlv2TbltDevicePkg/Stitch/MNW2_Stitch_Config.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Vlv2TbltDevicePkg/Stitch/MNW2_Stitch_Config.txt 
b/Vlv2TbltDevicePkg/Stitch/MNW2_Stitch_Config.txt
index 5a0a2b4..68f530f 100644
--- a/Vlv2TbltDevicePkg/Stitch/MNW2_Stitch_Config.txt
+++ b/Vlv2TbltDevicePkg/Stitch/MNW2_Stitch_Config.txt
@@ -1,5 +1,5 @@
 #
-# Copyright (c)  1999  - 2014, Intel Corporation. All rights reserved
+# Copyright (c)  1999  - 2016, 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.
@@ -12,5 +12,5 @@
 #
 
 HEADER=IFWI_HEADER
-SEC_VERSION=1.0.2.1060v5
+SEC_VERSION=1.0.3.1164
 
-- 
2.8.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH] Vlv2TbltDevicePkg: Change SEC to new version: 1.0.3.1164.

2016-07-04 Thread Guo, Mang
Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Guo Mang 
---
 Vlv2TbltDevicePkg/Stitch/MNW2_Stitch_Config.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Vlv2TbltDevicePkg/Stitch/MNW2_Stitch_Config.txt 
b/Vlv2TbltDevicePkg/Stitch/MNW2_Stitch_Config.txt
index 5a0a2b4..68f530f 100644
--- a/Vlv2TbltDevicePkg/Stitch/MNW2_Stitch_Config.txt
+++ b/Vlv2TbltDevicePkg/Stitch/MNW2_Stitch_Config.txt
@@ -1,5 +1,5 @@
 #
-# Copyright (c)  1999  - 2014, Intel Corporation. All rights reserved
+# Copyright (c)  1999  - 2016, 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.
@@ -12,5 +12,5 @@
 #
 
 HEADER=IFWI_HEADER
-SEC_VERSION=1.0.2.1060v5
+SEC_VERSION=1.0.3.1164
 
-- 
2.8.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Centralize TlsCaCertificate name and guid

2016-07-04 Thread Wu, Jiaxin
It should be "[edk2-staging/HTTPS-TLS][PATCH]".

Sorry for incorrect subject-prefix.

Jiaxin

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jiaxin Wu
> Sent: Tuesday, July 5, 2016 9:41 AM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan 
> Subject: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Centralize
> TlsCaCertificate name and guid
> 
> This patch is used to centralize TlsCaCertificate name and guid to
> TlsAuthentication.h
> 
> Cc: Palmer Thomas 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiaxin Wu 
> ---
>  NetworkPkg/HttpDxe/HttpDriver.h  |  2 ++
>  NetworkPkg/HttpDxe/HttpDxe.inf   |  4 
>  NetworkPkg/HttpDxe/HttpsSupport.c|  7 ++
>  NetworkPkg/HttpDxe/HttpsSupport.h| 10 
>  NetworkPkg/Include/Guid/TlsAuthentication.h  | 29
> 
>  NetworkPkg/NetworkPkg.dec|  5 +++-
>  NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf |  1 +
> NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c  | 14 +---
> NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.h  | 12 ++
>  9 files changed, 50 insertions(+), 34 deletions(-)  create mode 100644
> NetworkPkg/Include/Guid/TlsAuthentication.h
> 
> diff --git a/NetworkPkg/HttpDxe/HttpDriver.h
> b/NetworkPkg/HttpDxe/HttpDriver.h index 3c30c12..73c211a 100644
> --- a/NetworkPkg/HttpDxe/HttpDriver.h
> +++ b/NetworkPkg/HttpDxe/HttpDriver.h
> @@ -58,10 +58,12 @@
>  //
>  // Produced Protocols
>  //
>  #include 
> 
> +#include 
> +
>  //
>  // Driver Version
>  //
>  #define HTTP_DRIVER_VERSION 0xa
> 
> diff --git a/NetworkPkg/HttpDxe/HttpDxe.inf
> b/NetworkPkg/HttpDxe/HttpDxe.inf index a228c3d..1118181 100644
> --- a/NetworkPkg/HttpDxe/HttpDxe.inf
> +++ b/NetworkPkg/HttpDxe/HttpDxe.inf
> @@ -24,10 +24,11 @@
>MODULE_UNI_FILE   = HttpDxe.uni
> 
>  [Packages]
>MdePkg/MdePkg.dec
>MdeModulePkg/MdeModulePkg.dec
> +  NetworkPkg/NetworkPkg.dec
> 
>  [Sources]
>ComponentName.h
>ComponentName.c
>HttpDns.h
> @@ -69,7 +70,10 @@
>gEfiIp6ConfigProtocolGuid## SOMETIMES_CONSUMES
>gEfiTlsServiceBindingProtocolGuid## SOMETIMES_CONSUMES
>gEfiTlsProtocolGuid  ## SOMETIMES_CONSUMES
>gEfiTlsConfigurationProtocolGuid ## SOMETIMES_CONSUMES
> 
> +[Guids]
> +  gEfiTlsCaCertificateGuid ## CONSUMES  ## GUID
> +
>  [UserExtensions.TianoCore."ExtraFiles"]
>HttpDxeExtra.uni
> \ No newline at end of file
> diff --git a/NetworkPkg/HttpDxe/HttpsSupport.c
> b/NetworkPkg/HttpDxe/HttpsSupport.c
> index 09aaa46..36f658c 100644
> --- a/NetworkPkg/HttpDxe/HttpsSupport.c
> +++ b/NetworkPkg/HttpDxe/HttpsSupport.c
> @@ -12,12 +12,10 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF
> ANY KIND, EITHER EXPRESS OR IMPLIED.
> 
>  **/
> 
>  #include "HttpDriver.h"
> 
> -EFI_GUID mEfiTlsCaCertificateGuid = EFI_TLS_CA_CERTIFICATE_GUID;
> -
>  /**
>Returns the first occurrence of a Null-terminated ASCII sub-string in a 
> Null-
> terminated
>ASCII string and ignore case during the search process.
> 
>This function scans the contents of the ASCII string specified by String 
> @@ -
> 395,11 +393,11 @@ TlsConfigCertificate (
>// Try to read the TlsCaCertificate variable.
>//
>CACertSize = 0;
>Status  = gRT->GetVariable (
> EFI_TLS_CA_CERTIFICATE_VARIABLE,
> -   &mEfiTlsCaCertificateGuid,
> +   &gEfiTlsCaCertificateGuid,
> NULL,
> &CACertSize,
> NULL
> );
> 
> @@ -412,11 +410,11 @@ TlsConfigCertificate (
>return EFI_OUT_OF_RESOURCES;
>  }
> 
>  Status = gRT->GetVariable (
>  EFI_TLS_CA_CERTIFICATE_VARIABLE,
> -&mEfiTlsCaCertificateGuid,
> +&gEfiTlsCaCertificateGuid,
>  NULL,
>  &CACertSize,
>  CACert
>  );
>  if (EFI_ERROR (Status)) {
> @@ -453,11 +451,10 @@ TlsConfigCertificate (
>}
> 
>Cert = (EFI_SIGNATURE_DATA *) ((UINT8 *) Cert + CertList-
> >SignatureSize);
>  }
> 
> -
>  ItemDataSize -= CertList->SignatureListSize;
>  CertList = (EFI_SIGNATURE_LIST *) ((UINT8 *) CertList + CertList-
> >SignatureListSize);
>}
> 
>return Status;
> diff --git a/NetworkPkg/HttpDxe/HttpsSupport.h
> b/NetworkPkg/HttpDxe/HttpsSupport.h
> index 682a6b6..05b6e69 100644
> --- a/NetworkPkg/HttpDxe/HttpsSupport.h
> +++ b/NetworkPkg/HttpDxe/HttpsSupport.h
> @@ -20,20 +20,10 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF
> ANY KIND, EITHER EXPRESS OR IMPLIED.
>  #define HTTPS_DEFAULT_PORT   443
> 
>  #define HTTPS_FLAG   "https"
> 
>  //
> -// Private variable for CA Certificate c

[edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Centralize TlsCaCertificate name and guid

2016-07-04 Thread Jiaxin Wu
This patch is used to centralize TlsCaCertificate name and guid
to TlsAuthentication.h

Cc: Palmer Thomas 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
---
 NetworkPkg/HttpDxe/HttpDriver.h  |  2 ++
 NetworkPkg/HttpDxe/HttpDxe.inf   |  4 
 NetworkPkg/HttpDxe/HttpsSupport.c|  7 ++
 NetworkPkg/HttpDxe/HttpsSupport.h| 10 
 NetworkPkg/Include/Guid/TlsAuthentication.h  | 29 
 NetworkPkg/NetworkPkg.dec|  5 +++-
 NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf |  1 +
 NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c  | 14 +---
 NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.h  | 12 ++
 9 files changed, 50 insertions(+), 34 deletions(-)
 create mode 100644 NetworkPkg/Include/Guid/TlsAuthentication.h

diff --git a/NetworkPkg/HttpDxe/HttpDriver.h b/NetworkPkg/HttpDxe/HttpDriver.h
index 3c30c12..73c211a 100644
--- a/NetworkPkg/HttpDxe/HttpDriver.h
+++ b/NetworkPkg/HttpDxe/HttpDriver.h
@@ -58,10 +58,12 @@
 //
 // Produced Protocols
 //
 #include 
 
+#include 
+
 //
 // Driver Version
 //
 #define HTTP_DRIVER_VERSION 0xa
 
diff --git a/NetworkPkg/HttpDxe/HttpDxe.inf b/NetworkPkg/HttpDxe/HttpDxe.inf
index a228c3d..1118181 100644
--- a/NetworkPkg/HttpDxe/HttpDxe.inf
+++ b/NetworkPkg/HttpDxe/HttpDxe.inf
@@ -24,10 +24,11 @@
   MODULE_UNI_FILE   = HttpDxe.uni
 
 [Packages]
   MdePkg/MdePkg.dec
   MdeModulePkg/MdeModulePkg.dec
+  NetworkPkg/NetworkPkg.dec
 
 [Sources]
   ComponentName.h
   ComponentName.c
   HttpDns.h
@@ -69,7 +70,10 @@
   gEfiIp6ConfigProtocolGuid## SOMETIMES_CONSUMES
   gEfiTlsServiceBindingProtocolGuid## SOMETIMES_CONSUMES
   gEfiTlsProtocolGuid  ## SOMETIMES_CONSUMES
   gEfiTlsConfigurationProtocolGuid ## SOMETIMES_CONSUMES
 
+[Guids]
+  gEfiTlsCaCertificateGuid ## CONSUMES  ## GUID
+
 [UserExtensions.TianoCore."ExtraFiles"]
   HttpDxeExtra.uni
\ No newline at end of file
diff --git a/NetworkPkg/HttpDxe/HttpsSupport.c 
b/NetworkPkg/HttpDxe/HttpsSupport.c
index 09aaa46..36f658c 100644
--- a/NetworkPkg/HttpDxe/HttpsSupport.c
+++ b/NetworkPkg/HttpDxe/HttpsSupport.c
@@ -12,12 +12,10 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 **/
 
 #include "HttpDriver.h"
 
-EFI_GUID mEfiTlsCaCertificateGuid = EFI_TLS_CA_CERTIFICATE_GUID;
-
 /**
   Returns the first occurrence of a Null-terminated ASCII sub-string in a 
Null-terminated 
   ASCII string and ignore case during the search process.
 
   This function scans the contents of the ASCII string specified by String
@@ -395,11 +393,11 @@ TlsConfigCertificate (
   // Try to read the TlsCaCertificate variable.
   //
   CACertSize = 0;
   Status  = gRT->GetVariable (
EFI_TLS_CA_CERTIFICATE_VARIABLE,
-   &mEfiTlsCaCertificateGuid,
+   &gEfiTlsCaCertificateGuid,
NULL,
&CACertSize,
NULL
);
 
@@ -412,11 +410,11 @@ TlsConfigCertificate (
   return EFI_OUT_OF_RESOURCES;
 }
 
 Status = gRT->GetVariable (
 EFI_TLS_CA_CERTIFICATE_VARIABLE,
-&mEfiTlsCaCertificateGuid,
+&gEfiTlsCaCertificateGuid,
 NULL,
 &CACertSize,
 CACert
 );
 if (EFI_ERROR (Status)) {
@@ -453,11 +451,10 @@ TlsConfigCertificate (
   }
   
   Cert = (EFI_SIGNATURE_DATA *) ((UINT8 *) Cert + CertList->SignatureSize);
 }
 
-
 ItemDataSize -= CertList->SignatureListSize;
 CertList = (EFI_SIGNATURE_LIST *) ((UINT8 *) CertList + 
CertList->SignatureListSize);
   }
   
   return Status;
diff --git a/NetworkPkg/HttpDxe/HttpsSupport.h 
b/NetworkPkg/HttpDxe/HttpsSupport.h
index 682a6b6..05b6e69 100644
--- a/NetworkPkg/HttpDxe/HttpsSupport.h
+++ b/NetworkPkg/HttpDxe/HttpsSupport.h
@@ -20,20 +20,10 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #define HTTPS_DEFAULT_PORT   443
 
 #define HTTPS_FLAG   "https"
 
 //
-// Private variable for CA Certificate configuration
-//
-#define EFI_TLS_CA_CERTIFICATE_GUID \
-  { \
-0xfd2340D0, 0x3dab, 0x4349, { 0xa6, 0xc7, 0x3b, 0x4f, 0x12, 0xb4, 0x8e, 
0xae } \
-  }
-
-#define EFI_TLS_CA_CERTIFICATE_VARIABLE  L"TlsCaCertificate"
-
-//
 // TLS Version
 //
 #define TLS10_PROTOCOL_VERSION_MAJOR  0x03
 #define TLS10_PROTOCOL_VERSION_MINOR  0x01
 #define TLS11_PROTOCOL_VERSION_MAJOR  0x03
diff --git a/NetworkPkg/Include/Guid/TlsAuthentication.h 
b/NetworkPkg/Include/Guid/TlsAuthentication.h
new file mode 100644
index 000..2e800dc
--- /dev/null
+++ b/NetworkPkg/Include/Guid/TlsAuthentication.h
@@ -0,0 +1,29 @@
+/** @file
+  This file defines TlsCaCertificate var

Re: [edk2] Memory Profile question.

2016-07-04 Thread Yao, Jiewen
Comment inline:

From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew 
Fish
Sent: Thursday, June 30, 2016 10:17 PM
To: Yao, Jiewen 
Cc: edk2-devel 
Subject: Re: [edk2] Memory Profile question.


> On Jun 30, 2016, at 12:05 AM, Yao, Jiewen 
> mailto:jiewen@intel.com>> wrote:
>
> Yes, Andrew. You are right.
> We encounter similar problem, but it seems MSVC _ReturnAddress() does not 
> take parameter.
>  #define RETURN_ADDRESS(L) ((L == 0) ? _ReturnAddress() : (VOID *) 0)
>

For GCC family you can potentially get more info.

#define RETURN_ADDRESS(L) __builtin_return_address (L)

> So we enhanced MemoryAllocationLib to support add record from 
> MemoryAllocationLib.
>

Does that mean the logging gets moved to the library? Or does the library log 
just update the log in the DXE Core?
[Jiewen] DxeCore still logs gBS->AllocatePool.
The memory allocation library adds a profile record to DxeCore maintained 
profile database.


> The final log is like this:
>
>  CountSize   RVA  Action
> ==  == == 
> ()
> 0x006B  0x0001D31F <== 0xAE7C (gBS->AllocatePool) 
> (InternalAllocatePool() - 
> c:\home\edk-ii\mdemodulepkg\library\smmmemoryallocationlibprofile\memoryallocationlib.c:567)
> 0x0001  0x0020 <== 0xBCB8 (Lib:AllocatePool) 
> (SmmMemLibConstructor() - 
> c:\home\edk-ii\mdepkg\library\smmmemlib\smmmemlib.c:309)
> 0x0001  0x0070 <== 0x7F2D 
> (Lib:AllocateZeroRuntimePool) (VariableCommonInitialize() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:4055)
> 0x0001  0xC000 <== 0x715A 
> (Lib:AllocateZeroRuntimePool) (InitNonVolatileVariableStore() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:3692)
> 0x0001  0x00010400 <== 0x8121 
> (Lib:AllocateRuntimePool) (VariableCommonInitialize() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:4113)
> 0x0001  0x0404 <== 0x2957 (gBS->AllocatePool) 
> (VariableServiceInitialize() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variablesmm.c:956)
> 0x0007  0x01CE <== 0xC42E 
> (Lib:AllocateZeroRuntimePool) (VarCheckLibVariablePropertySet() - 
> c:\home\edk-ii\mdemodulepkg\library\varchecklib\varchecklib.c:521)
> 0x0001  0x0020 <== 0xC071 
> (Lib:ReallocateRuntimePool) (VarCheckAddTableEntry() - 
> c:\home\edk-ii\mdemodulepkg\library\varchecklib\varchecklib.c:228)
> 0x0001  0x0030 <== 0x2E08 (Lib:AllocateZeroPool) 
> (UpdateVariableInfo() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:196)
> 0x0001  0x0044 <== 0x2E68 (Lib:AllocateZeroPool) 
> (UpdateVariableInfo() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:200)
> 0x002C  0x0840 <== 0x2F98 (Lib:AllocateZeroPool) 
> (UpdateVariableInfo() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:232)
> 0x002C  0x037C <== 0x2FF6 (Lib:AllocateZeroPool) 
> (UpdateVariableInfo() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:236)
> 0x0001  0x000D <== 0x4DC9 
> (Lib:AllocateCopyRuntimePool) (AutoUpdateLangVariable() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:1960)
> 0x0001  0x0012 <== 0x4CC4 
> (Lib:AllocateCopyRuntimePool) (AutoUpdateLangVariable() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:1930)
> 0x0001  0x0012 <== 0x4D28 
> (Lib:AllocateRuntimePool) (AutoUpdateLangVariable() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:1940)
>
>

Are the address ranges allocated tracked? Is it possible to look up an address 
and figure out where it got allocated?
[Jiewen] I am not clear on the question. "Address" means the memory allocated? 
Or the RIP doing the allocation?
Also I do not understand what "ranges" means here.

Currently, DxeCore records all loaded image - so DxeCore knows the RIP of each 
allocation action.
So DxeCore records the RIP, as well as allocated buffer address.

The above log is summary. For detail, you may also see each allocation action 
in final log, like below:
=
MEMORY_PROFILE_ALLOC_INFO (0x52)
  Signature - 0x4941504D
  Length- 0x0030
  Revision  - 0x0001
  CallerAddress - 0x04B6A41B (Offset: 0x0001141B)
  SequenceId- 0x0033
  Action- 0x0003 (gBS->AllocatePool)
  MemoryType- 0x0004 (EfiBootServicesData)
  Buffer- 0x04F07BD0
  Size  - 0x0

Re: [edk2] [PATCH] BaseTools MemoryProfileSymbolGen.py: Handle 64bits rva from "nm -l xxx.dll"

2016-07-04 Thread Yao, Jiewen
Reviewed by: jiewen@intel.com

> -Original Message-
> From: Zeng, Star
> Sent: Monday, July 4, 2016 6:42 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Yao, Jiewen ;
> Gao, Liming ; Zhu, Yonghong
> 
> Subject: [PATCH] BaseTools MemoryProfileSymbolGen.py: Handle 64bits rva
> from "nm -l xxx.dll"
> 
> Current MemoryProfileSymbolGen.py assumes the rva is 32bits,
> the patch is to remove the restriction to match any lengths
> of rva.
> 
> Cc: Jiewen Yao 
> Cc: Liming Gao 
> Cc: Yonghong Zhu 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Star Zeng 
> ---
>  BaseTools/Scripts/MemoryProfileSymbolGen.py | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/BaseTools/Scripts/MemoryProfileSymbolGen.py
> b/BaseTools/Scripts/MemoryProfileSymbolGen.py
> index a9790d8883c8..5709ad4641cb 100644
> --- a/BaseTools/Scripts/MemoryProfileSymbolGen.py
> +++ b/BaseTools/Scripts/MemoryProfileSymbolGen.py
> @@ -19,7 +19,7 @@ import re
>  import sys
>  from optparse import OptionParser
> 
> -versionNumber = "1.0"
> +versionNumber = "1.1"
>  __copyright__ = "Copyright (c) 2016, Intel Corporation. All rights reserved."
> 
>  class Symbols:
> @@ -72,7 +72,7 @@ class Symbols:
>  linefile.close()
> 
>  # 000113ca T AllocatePool
>   c:\home\edk-ii\MdePkg\Library\UefiMemoryAllocationLib\MemoryAllo
> cationLib.c:399
> -patchLineFileMatchString =
> "([0-9a-fA-F]{8})\s+[T|D|t|d]\s+(\w+)\s*((?:[a-zA-Z]:)?[\w+\-./_a-zA-Z0-9\\\
> \]*):?([0-9]*)"
> +patchLineFileMatchString =
> "([0-9a-fA-F]*)\s+[T|D|t|d]\s+(\w+)\s*((?:[a-zA-Z]:)?[\w+\-./_a-zA-Z0-9]
> *):?([0-9]*)"
> 
>  for reportLine in reportLines:
>  #print "check - " + reportLine
> --
> 2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH] MdeModulePkg MemoryProfileInfo: Handle "/" character in the PDB path

2016-07-04 Thread Yao, Jiewen
Reviewed by: jiewen@intel.com

> -Original Message-
> From: Zeng, Star
> Sent: Monday, July 4, 2016 6:42 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Yao, Jiewen 
> Subject: [PATCH] MdeModulePkg MemoryProfileInfo: Handle "/" character in
> the PDB path
> 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Star Zeng 
> ---
>  MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c | 2
> +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git
> a/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
> b/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
> index 69c6cf166daa..68e7ed7326f0 100644
> --- a/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
> +++ b/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
> @@ -205,7 +205,7 @@ GetShortPdbFileName (
>  StartIndex = 0;
>  for (EndIndex = 0; PdbFileName[EndIndex] != 0; EndIndex++);
>  for (IndexPdb = 0; PdbFileName[IndexPdb] != 0; IndexPdb++) {
> -  if (PdbFileName[IndexPdb] == '\\') {
> +  if ((PdbFileName[IndexPdb] == '\\') || (PdbFileName[IndexPdb] ==
> '/')) {
>  StartIndex = IndexPdb + 1;
>}
> 
> --
> 2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] Memory Profile question.

2016-07-04 Thread Yao, Jiewen
Yes, FreePool is also handled.
The current algorithm is: We insert a record when AllocatePool happens. We 
search and delete the record when FreePool happens.

So the final memory profile record means: the memory allocated, but not freed.

Thank you
Yao Jiewen

From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ramesh R.
Sent: Monday, July 4, 2016 8:07 PM
To: Andrew Fish ; Yao, Jiewen 
Cc: edk2-devel 
Subject: Re: [edk2] Memory Profile question.

Is there any way we can track the FreePool also ? In the end is it possible to 
identify which are all the memory area allocated, but no freed by system BIOS ?

Thanks,
Ramesh

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew 
Fish
Sent: 30 June 2016 19:47
To: Yao, Jiewen
Cc: edk2-devel
Subject: Re: [edk2] Memory Profile question.


> On Jun 30, 2016, at 12:05 AM, Yao, Jiewen 
> mailto:jiewen@intel.com>> wrote:
>
> Yes, Andrew. You are right.
> We encounter similar problem, but it seems MSVC _ReturnAddress() does not 
> take parameter.
>  #define RETURN_ADDRESS(L) ((L == 0) ? _ReturnAddress() : (VOID *) 0)
>

For GCC family you can potentially get more info.

#define RETURN_ADDRESS(L) __builtin_return_address (L)

> So we enhanced MemoryAllocationLib to support add record from 
> MemoryAllocationLib.
>

Does that mean the logging gets moved to the library? Or does the library log 
just update the log in the DXE Core?

> The final log is like this:
>
>  CountSize   RVA  Action
> ==  == == 
> ()
> 0x006B  0x0001D31F <== 0xAE7C
> (gBS->AllocatePool) (InternalAllocatePool() -
> c:\home\edk-ii\mdemodulepkg\library\smmmemoryallocationlibprofile\memo
> ryallocationlib.c:567)
> 0x0001  0x0020 <== 0xBCB8
> (Lib:AllocatePool) (SmmMemLibConstructor() -
> c:\home\edk-ii\mdepkg\library\smmmemlib\smmmemlib.c:309)
> 0x0001  0x0070 <== 0x7F2D
> (Lib:AllocateZeroRuntimePool) (VariableCommonInitialize() -
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:4
> 055)
> 0x0001  0xC000 <== 0x715A
> (Lib:AllocateZeroRuntimePool) (InitNonVolatileVariableStore() -
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:3
> 692)
> 0x0001  0x00010400 <== 0x8121
> (Lib:AllocateRuntimePool) (VariableCommonInitialize() -
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:4
> 113)
> 0x0001  0x0404 <== 0x2957
> (gBS->AllocatePool) (VariableServiceInitialize() -
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variablesmm.
> c:956)
> 0x0007  0x01CE <== 0xC42E
> (Lib:AllocateZeroRuntimePool) (VarCheckLibVariablePropertySet() -
> c:\home\edk-ii\mdemodulepkg\library\varchecklib\varchecklib.c:521)
> 0x0001  0x0020 <== 0xC071
> (Lib:ReallocateRuntimePool) (VarCheckAddTableEntry() -
> c:\home\edk-ii\mdemodulepkg\library\varchecklib\varchecklib.c:228)
> 0x0001  0x0030 <== 0x2E08
> (Lib:AllocateZeroPool) (UpdateVariableInfo() -
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:1
> 96)
> 0x0001  0x0044 <== 0x2E68
> (Lib:AllocateZeroPool) (UpdateVariableInfo() -
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:2
> 00) 0x002C  0x0840 <== 0x2F98
> (Lib:AllocateZeroPool) (UpdateVariableInfo() -
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:2
> 32) 0x002C  0x037C <== 0x2FF6
> (Lib:AllocateZeroPool) (UpdateVariableInfo() -
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:2
> 36)
> 0x0001  0x000D <== 0x4DC9
> (Lib:AllocateCopyRuntimePool) (AutoUpdateLangVariable() -
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:1
> 960)
> 0x0001  0x0012 <== 0x4CC4
> (Lib:AllocateCopyRuntimePool) (AutoUpdateLangVariable() -
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:1
> 930)
> 0x0001  0x0012 <== 0x4D28
> (Lib:AllocateRuntimePool) (AutoUpdateLangVariable() -
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:1
> 940)
>
>

Are the address ranges allocated tracked? Is it possible to look up an address 
and figure out where it got allocated?

Any plans to add logging for stalls? You can dump events with a debugger 
script, so that is not as important.

Thanks,

Andrew Fish

>
>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
>> Of Andrew Fish
>> Sent: Thursday, June 30, 2016 2:38 PM
>> To: edk2-devel mailto:edk2-devel@lists.01.org>>
>> Subject: [edk2] Me

Re: [edk2] StdLib usage for drivers?

2016-07-04 Thread Daryl McDaniel
Marvin,

 

Personally, I would be happy for any contributions you could make for StdLib.

The only remaining Shell dependencies should be:

* File system support.

* One or two functions in PosixLib

 

The next big area is breaking up the MainData structure and moving its members 
into the sub-libraries that they are relevant to.

 

Once that is done, I had planned on trying to break as many of the library’s 
interdependencies as possible.

 

As long as StdLib continues to pass the ISO C95 compliance tests, and gets 
smaller instead of larger, just about anything is fair game.

I had pretty much decided to abandon using the FreeBSD / NetBSD code since it 
is not the best suited for the EDK II environment.

 

As Michael surmised, I’ve been traveling a lot and too busy lately to devote as 
much attention to StdLib as I wish I could.

 

Please remember for your contributions; compatibility with both GCC and 
Microsoft compilers and both IA32 and X64 is required.  If you can also retain 
or provide support for ARM then that would be great.

 

I can’t speak for Jaben, so I will have to wait for his response to determine 
his stance on the issue.

 

I’m willing to answer any questions about AppPkg or StdLib that I can.

 

Thank you for your offer.

Daryl McDaniel

 

 

From: Marvin Häuser [mailto:marvin.haeu...@outlook.com] 
Sent: Monday, July 04, 2016 11:18 AM
To: edk2-devel@lists.01.org
Cc: Michael Zimmermann ; edk2-li...@mc2research.org; 
Carsey, Jaben 
Subject: RE: [edk2] StdLib usage for drivers?

 

Daryl, Jaben,

 

As you are the package maintainers of StdLib, could you please comment on the 
situation?

If modifications to have StdLib working for drivers are welcome, I would offer 
my help in cleaning up the existing stuff and/or write my own patches, though 
of course there is little point if there is no reaction from the reviewers.

If it is of any interest, I want to write a shim library for Capstone and would 
prefer not to have three copies of Std functions in my tree (StdLib, CryptoPkg 
(SSL) and Capstone), but rather an improved StdLib that works for all.

 

Thanks to those who have offered alternative solutions, but I prefer to keep it 
‚clean‘ and have the libraries shipping with EDK2 work. :)

 

Regards,

Marvin.

 

From: Michael Zimmermann [mailto:sigmaepsilo...@gmail.com] 
Sent: Thursday, June 23, 2016 5:32 AM
To: Marvin Häuser mailto:marvin.haeu...@outlook.com> >
Cc: edk2-devel@lists.01.org  ; af...@apple.com 
 
Subject: Re: [edk2] StdLib usage for drivers?

 

well for the patch to go upstream it would have to get improved a lot.

I've tried to implement this in a way that doesn't need a different dsc but the 
problem is that ShellLib's constructor ASSERT's if it can't find the shell 
protocol and removing that would probably be against the spec's.

 

Also it appears that the StdLib maintainers are kinda busy because most of the 
StdLib patches I've sent to this mailing list didn't get reviewed.

 

Thanks

Michael

 

On Wed, Jun 22, 2016 at 10:37 PM, Marvin Häuser mailto:marvin.haeu...@outlook.com> > wrote:

Hey Michael,

Thank you for your input! This looks interesting.
Maybe it would be a good idea to provide the libraries that depend on Shell (in 
master) with functions that call ASSERT (FALSE); for drivers? I do not need 
file I/O, so I think your modifications might work out well for me. Would be 
very nice of course if such changes found their way upstream. :)

And thank you very much for your comment as well, Andrew! It makes sense that 
StdLib is primarily targeted at porting console applications to UEFI Shell.

Regards,
Marvin.

From: Michael Zimmermann [mailto:sigmaepsilo...@gmail.com 
 ]
Sent: Wednesday, June 22, 2016 10:28 PM
To: Marvin H?user mailto:marvin.haeu...@outlook.com> >
Cc: edk2-devel@lists.01.org  
Subject: Re: [edk2] StdLib usage for drivers?

In my fork of edk2 I've added support for using StdLib without the Shell.
It's quite hacky(setenv/getenv are stubs, no File IO and maybe other things 
hidden by linker GC and me not using all features).

But depending on which StdLib features you need this can work pretty good.

here's the commit that does the magic:
https://github.com/efidroid/edk2/commit/bf7a296718486bafaf774ea8bcf187c162c3c167

and this is how you convert a Shell project to a NonShell one:
https://github.com/efidroid/uefi_apps_EFIDroidUi/commit/23f0fa08108b8f852564fae733c6a7bce62e2070

as you can see it works by using StdLib with different libraries/cflags so you 
have to compile your driver separately if there are other modules which need 
the normal StdLib.

Thanks
Michael

On Wed, Jun 22, 2016 at 9:38 PM, Marvin H?user mailto:marvin.haeu...@outlook.com>  >> wrote:
Dear EDK2 developers,

For an experimental project, I'm currently attem

Re: [edk2] StdLib usage for drivers?

2016-07-04 Thread Marvin Häuser
Daryl, Jaben,

As you are the package maintainers of StdLib, could you please comment on the 
situation?
If modifications to have StdLib working for drivers are welcome, I would offer 
my help in cleaning up the existing stuff and/or write my own patches, though 
of course there is little point if there is no reaction from the reviewers.
If it is of any interest, I want to write a shim library for Capstone and would 
prefer not to have three copies of Std functions in my tree (StdLib, CryptoPkg 
(SSL) and Capstone), but rather an improved StdLib that works for all.

Thanks to those who have offered alternative solutions, but I prefer to keep it 
‚clean‘ and have the libraries shipping with EDK2 work. :)

Regards,
Marvin.

From: Michael Zimmermann [mailto:sigmaepsilo...@gmail.com]
Sent: Thursday, June 23, 2016 5:32 AM
To: Marvin Häuser 
Cc: edk2-devel@lists.01.org; af...@apple.com
Subject: Re: [edk2] StdLib usage for drivers?

well for the patch to go upstream it would have to get improved a lot.
I've tried to implement this in a way that doesn't need a different dsc but the 
problem is that ShellLib's constructor ASSERT's if it can't find the shell 
protocol and removing that would probably be against the spec's.

Also it appears that the StdLib maintainers are kinda busy because most of the 
StdLib patches I've sent to this mailing list didn't get reviewed.

Thanks
Michael

On Wed, Jun 22, 2016 at 10:37 PM, Marvin Häuser 
mailto:marvin.haeu...@outlook.com>> wrote:
Hey Michael,

Thank you for your input! This looks interesting.
Maybe it would be a good idea to provide the libraries that depend on Shell (in 
master) with functions that call ASSERT (FALSE); for drivers? I do not need 
file I/O, so I think your modifications might work out well for me. Would be 
very nice of course if such changes found their way upstream. :)

And thank you very much for your comment as well, Andrew! It makes sense that 
StdLib is primarily targeted at porting console applications to UEFI Shell.

Regards,
Marvin.

From: Michael Zimmermann 
[mailto:sigmaepsilo...@gmail.com]
Sent: Wednesday, June 22, 2016 10:28 PM
To: Marvin H?user 
mailto:marvin.haeu...@outlook.com>>
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] StdLib usage for drivers?

In my fork of edk2 I've added support for using StdLib without the Shell.
It's quite hacky(setenv/getenv are stubs, no File IO and maybe other things 
hidden by linker GC and me not using all features).

But depending on which StdLib features you need this can work pretty good.

here's the commit that does the magic:
https://github.com/efidroid/edk2/commit/bf7a296718486bafaf774ea8bcf187c162c3c167

and this is how you convert a Shell project to a NonShell one:
https://github.com/efidroid/uefi_apps_EFIDroidUi/commit/23f0fa08108b8f852564fae733c6a7bce62e2070

as you can see it works by using StdLib with different libraries/cflags so you 
have to compile your driver separately if there are other modules which need 
the normal StdLib.

Thanks
Michael

On Wed, Jun 22, 2016 at 9:38 PM, Marvin H?user 
mailto:marvin.haeu...@outlook.com>>>
 wrote:
Dear EDK2 developers,

For an experimental project, I'm currently attempting to write a library 
wrapper for the disassembler library 'Capstone' in a similar manner to 
CryptoPkg's OpensslLib. As most C libraries, it also depends on the standard 
headers, which are not provided by 'stock' EDK2. My first guess has been to use 
StdLib, though its description states:
'Due to the execution environment built by the StdLib component, execution as a 
UEFI driver can cause system stability issues.'

Inspecting OpensslLib I discovered that CryptoPkg deploys its own include files 
for StdLib. Though, from your experience, what are the issues with using 
StdLibPkg with DXE/UEFI drivers? It might be nice to reduce duplicate code, 
though I honestly don't know anything about StdLibPkg and its implementation 
and would be thankful for some insight on that manner.

Thank you in advance for your time!

Regards,
Marvin.
___
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 v2 0/4] ArmPkg: refactor MMU handling routines into separate ArmMmuLib

2016-07-04 Thread Leif Lindholm
On Fri, Jul 01, 2016 at 05:43:52PM +0200, Ard Biesheuvel wrote:
> The MMU routines are only used by a small subset of the users of ArmLib.
> In order to prevent all those users to have to run the library constructor
> to clean some MMU handling routines to the PoC, split off all MMU handling
> into a separate ArmMmuLib.
> 
> NOTE: this change will affect out-of-tree platforms, which will need to add 
> the
>   ArmMmuLib library class resolution to their .DSC descriptions.
> 
> Changes since v1:
> - updated ArmVirtQemuKernel as well as ArmVirtQemu and ArmVirtXen to switch to
>   the new ArmMmuLib (#3)
> - added tags from Laszlo and Star (#3)
> - dropped ArmLib reference from DxeIp l(#3) [*]
> - clarified comment (#4)

For the series:
Reviewed-by: Leif Lindholm 

> [*] I have taken the liberty to keep Star's R-b on patch #3 since the change 
> to
> MdeModulePkg is minimal and only affects ARM/AARCH64
> 
> Ard Biesheuvel (4):
>   ArmPkg: introduce ArmMmuLib library class
>   ArmPkg: introduce base ArmMmuLib implementation
>   ArmPkg ArmVirtPkg MdeModulePkg: switch to separate ArmMmuLib
>   ArmPkg/ArmMmuLib: add PEI specific version of ArmMmuLib
> 
>  ArmPkg/ArmPkg.dec
>  |  1 +
>  ArmPkg/Drivers/CpuDxe/CpuDxe.inf 
>  |  1 +
>  ArmPkg/Include/Library/ArmLib.h  
>  | 38 --
>  ArmPkg/Include/Library/ArmMmuLib.h   
>  | 65 +
>  ArmPkg/Library/ArmLib/AArch64/AArch64BaseLibConstructor.c
>  | 36 --
>  ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf 
>  |  3 -
>  ArmPkg/Library/ArmLib/AArch64/AArch64LibPrePi.inf
>  |  1 -
>  ArmPkg/Library/ArmLib/ArmV7/ArmLibSupportV7.S
>  |  6 --
>  ArmPkg/Library/ArmLib/ArmV7/ArmLibSupportV7.asm  
>  |  6 --
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.h   
>  | 12 
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.inf 
>  |  1 -
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7LibPrePi.inf
>  |  1 -
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S   
>  |  5 --
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.asm 
>  |  4 --
>  ArmPkg/Library/{ArmLib/AArch64/AArch64Mmu.c => 
> ArmMmuLib/AArch64/ArmMmuLibCore.c} | 25 +--
>  ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S 
>  | 76 
>  ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuPeiLibConstructor.c   
>  | 61 
>  ArmPkg/Library/{ArmLib/ArmV7/ArmV7Mmu.c => ArmMmuLib/Arm/ArmMmuLibCore.c}
>  | 38 +-
>  ArmPkg/Library/ArmMmuLib/Arm/ArmMmuLibV7Support.S
>  | 35 +
>  ArmPkg/Library/ArmMmuLib/Arm/ArmMmuLibV7Support.asm  
>  | 32 +
>  ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf   
>  | 43 +++
>  ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
>  | 36 ++
>  ArmVirtPkg/ArmVirtQemu.dsc   
>  |  2 +
>  ArmVirtPkg/ArmVirtQemuKernel.dsc 
>  |  2 +
>  ArmVirtPkg/ArmVirtXen.dsc
>  |  2 +
>  ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c 
>  |  1 +
>  ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.inf   
>  |  1 +
>  MdeModulePkg/Core/DxeIplPeim/Arm/DxeLoadFunc.c   
>  |  2 +-
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf  
>  |  2 +-
>  29 files changed, 417 insertions(+), 121 deletions(-)
>  create mode 100644 ArmPkg/Include/Library/ArmMmuLib.h
>  delete mode 100644 ArmPkg/Library/ArmLib/AArch64/AArch64BaseLibConstructor.c
>  rename ArmPkg/Library/{ArmLib/AArch64/AArch64Mmu.c => 
> ArmMmuLib/AArch64/ArmMmuLibCore.c} (94%)
>  create mode 100644 ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S
>  create mode 100644 ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuPeiLibConstructor.c
>  rename ArmPkg/Library/{ArmLib/ArmV7/ArmV7Mmu.c => 
> ArmMmuLib/Arm/ArmMmuLibCore.c} (93%)
>  create mode 100644 ArmPkg/Library/ArmMmuLib/Arm/ArmMmuLibV7Support.S
>  create mode 100644 ArmPkg/Library/ArmMmuLib/Arm/ArmMmuLibV7Support.asm
>  create mode 100644 ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
>  create mode 100644 ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
> 
> -- 
> 2.7.4
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https:/

Re: [edk2] [PATCH 1/7] BaseTools: Enable three new toolchains

2016-07-04 Thread Shi, Steven
OK. I will separate this patch to 3 commits and post a public branch for them.


Steven Shi
Intel\SSG\STO\UEFI Firmware

Tel: +86 021-61166522
iNet: 821-6522


> -Original Message-
> From: Justen, Jordan L
> Sent: Thursday, June 30, 2016 4:55 AM
> To: Shi, Steven ; edk2-devel@lists.01.org; Gao,
> Liming 
> Cc: Kinney, Michael D ; af...@apple.com
> Subject: Re: [edk2] [PATCH 1/7] BaseTools: Enable three new toolchains
> 
> This should be 3 separate commits. It should be obvious in the commit
> subject line what toolchain is being added.
> 
> Can you post a public branch with your commits? Maybe on a personal
> github fork of the edk2 repo.
> 
> On 2016-06-28 08:18:55, Shi, Steven wrote:
> > Enable three new toolchains: CLANG38, CLANGSCAN38 and GCC53.
> > (1)CLANG38 uses Clang3.8.0, enable LLVM Link Time Optimization (LTO)
> > and code size optimization flag (-Oz) by default for aggressive code
> > size improvement. CLANG38 X64 code is small code model + PIE.
> > (2)CLANGSCAN38 is based on CLANG38 to seamlessly integrate Clang
> > scan-build analyzer infrastructure into edk2 build infrastructure.
> 
> I'm not sure we should add a separate toolchain for this.
> 
> > (3)GCC53 use gcc 5.3, enable GCC Link Time Optimization (LTO) and
> > code size optimization (–Os) for aggressive code size improvement.
> > GCC53 X64 code is also small + PIE.
> 
> As of GCC 5.0, the minor releases have been bumped left. Essentially,
> GCC51, GCC52, etc don't make sense, and GCC5 or GCC6 should be used
> now.
> 
> https://gcc.gnu.org/releases.html
> 
> So, will this work with all versions of GCC 5.*? If not, I suggest we
> consider starting this support at GCC6.
> 
> -Jordan
> 
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Steven Shi 
> > ---
> >  BaseTools/Conf/build_rule.template |  17 ++-
> >  BaseTools/Conf/tools_def.template  | 267
> +
> >  2 files changed, 283 insertions(+), 1 deletion(-)
> >  mode change 100644 => 100755 BaseTools/Conf/build_rule.template
> >  mode change 100644 => 100755 BaseTools/Conf/tools_def.template
> >
> > diff --git a/BaseTools/Conf/build_rule.template
> b/BaseTools/Conf/build_rule.template
> > old mode 100644
> > new mode 100755
> > index 91bcc18..7f21813
> > --- a/BaseTools/Conf/build_rule.template
> > +++ b/BaseTools/Conf/build_rule.template
> > @@ -137,6 +137,9 @@
> >  
> >  "$(CC)" $(CC_FLAGS) -o ${dst} $(INC) ${src}
> >
> > +
> > +"$(SCAN)" $(SCAN_FLAGS) -o $(SCAN_DST) "$(CC)" $(CC_FLAGS) -o
> ${dst} $(INC) ${src}
> > +
> >  [C-Code-File.COMMON.IPF]
> >  
> >  ?.c
> > @@ -267,7 +270,10 @@
> >
> >  
> >  "$(SLINK)" -cr ${dst} $(SLINK_FLAGS) @$(OBJECT_FILES_LIST)
> > -
> > +
> > +
> > +"$(SLINK)" cr ${dst} $(SLINK_FLAGS) @$(OBJECT_FILES_LIST)
> > +
> >  
> >  "$(SLINK)" $(SLINK_FLAGS) ${dst} --via $(OBJECT_FILES_LIST)
> >
> > @@ -295,6 +301,10 @@
> >  "$(DLINK)" -o ${dst} $(DLINK_FLAGS) --start-group $(DLINK_SPATH)
> @$(STATIC_LIBRARY_FILES_LIST) --end-group $(DLINK2_FLAGS)
> >  "$(OBJCOPY)" $(OBJCOPY_FLAGS) ${dst}
> >
> > +
> > +"$(DLINK)" -o ${dst} $(DLINK_FLAGS) -Wl,--start-
> group,$(DLINK_SPATH),@$(STATIC_LIBRARY_FILES_LIST) -Wl,--end-group
> $(DLINK2_FLAGS)
> > +"$(OBJCOPY)" $(OBJCOPY_FLAGS) ${dst}
> > +
> >  
> >  "$(DLINK)" $(DLINK_FLAGS) -o ${dst} $(DLINK_SPATH) --via
> $(STATIC_LIBRARY_FILES_LIST) $(DLINK2_FLAGS)
> >
> > @@ -448,6 +458,11 @@
> >  "$(ASLDLINK)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll
> $(ASLDLINK_FLAGS) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
> >  "$(GENFW)" -o ${dst} -c $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll
> $(GENFW_FLAGS)
> >
> > +
> > +"$(ASLCC)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
> $(ASLCC_FLAGS) $(INC) ${src}
> > +"$(ASLDLINK)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll
> $(ASLDLINK_FLAGS) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
> > +"$(GENFW)" -o ${dst} -c $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll
> $(GENFW_FLAGS)
> > +
> >  
> >  "$(ASLCC)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
> $(ASLCC_FLAGS) $(INC) ${src}
> >  "$(ASLDLINK)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll
> $(ASLDLINK_FLAGS) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
> > diff --git a/BaseTools/Conf/tools_def.template
> b/BaseTools/Conf/tools_def.template
> > old mode 100644
> > new mode 100755
> > index 2065fa3..d401031
> > --- a/BaseTools/Conf/tools_def.template
> > +++ b/BaseTools/Conf/tools_def.template
> > @@ -366,12 +366,30 @@ DEFINE SOURCERY_CYGWIN_TOOLS =
> /cygdrive/c/Program Files/CodeSourcery/Sourcery G
> >  # Required to build platforms or ACPI tables:
> >  #   Intel(r) ACPI Compiler from
> >  #   https://acpica.org/downloads
> > +#   GCC53-Linux-  Requires:
> > +# GCC 5.3 targeting x86_64-

Re: [edk2] [PATCH 4/7] QuarkPlatformPkg-AcpiPlatform: Downgrade the optimization to O1

2016-07-04 Thread Shi, Steven
OK, I will try to root cause it. And I will separate the Quark build enabling 
work from this serial patches as a new one.


Steven Shi
Intel\SSG\STO\UEFI Firmware

Tel: +86 021-61166522
iNet: 821-6522


> -Original Message-
> From: Kinney, Michael D
> Sent: Thursday, June 30, 2016 4:56 AM
> To: af...@apple.com; Shi, Steven ; Kinney, Michael D
> 
> Cc: edk2-devel ; Gao, Liming
> ; Zimmer, Vincent ;
> Doran, Mark ; Mudusuru, Giri P
> 
> Subject: RE: [edk2] [PATCH 4/7] QuarkPlatformPkg-AcpiPlatform:
> Downgrade the optimization to O1
> 
> Andrew,
> 
> I agree that we need to root cause and fix this code issue.
> 
> I also like idea of doing RELEASE/DEBUG/NOOPT builds to make sure code
> changes do not introduce build failures.
> 
> Mike
> 
> > -Original Message-
> > From: af...@apple.com [mailto:af...@apple.com]
> > Sent: Wednesday, June 29, 2016 11:31 AM
> > To: Shi, Steven 
> > Cc: edk2-devel ; Gao, Liming
> ; Kinney,
> > Michael D ; Zimmer, Vincent
> ;
> > Doran, Mark ; Mudusuru, Giri P
> 
> > Subject: Re: [edk2] [PATCH 4/7] QuarkPlatformPkg-AcpiPlatform:
> Downgrade the
> > optimization to O1
> >
> >
> > > On Jun 28, 2016, at 8:18 AM, Shi, Steven  wrote:
> > >
> > > Quark AcpiPlatform module cannot link successfully by CLANG38
> > > with Oz optimization level. Add a work around to downgrade the
> > > optimization to O1.
> > >
> >
> > We should fix the code too. These bugs are usually structure assignments in
> the scope
> > of a function that should be global, static, or done via CopyMem.
> >
> > I really think they should get fixed as I see a lot of Si code that fails 
> > to link
> when
> > you compile with optimizations disabled, -O0, with Xcode clang as the
> compiler falls
> > back to memset/memcpy and we were just getting lucky the optimizer
> removed it.
> >
> > Actually it would be nice if packages also got built NOOPT to help catch
> these classes
> > of errors.
> >
> > Thanks,
> >
> > Andrew Fish
> >
> > > Contributed-under: TianoCore Contribution Agreement 1.0
> > > Signed-off-by: Steven Shi 
> > > ---
> > > QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.inf | 4 
> > > 1 file changed, 4 insertions(+)
> > > mode change 100644 => 100755
> QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.inf
> > >
> > > diff --git a/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.inf
> > b/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.inf
> > > old mode 100644
> > > new mode 100755
> > > index dcf2b4a..f1bcfa1
> > > --- a/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.inf
> > > +++ b/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.inf
> > > @@ -200,3 +200,7 @@
> > >
> > > [Depex]
> > >   gEfiMpServiceProtocolGuid AND gEfiAcpiTableProtocolGuid
> > > +
> > > +[BuildOptions]
> > > +  GCC:*_CLANG38_IA32_DLINK_FLAGS  = -O1
> > > +  GCC:*_CLANGSCAN38_IA32_DLINK_FLAGS  = -O1
> > > --
> > > 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


Re: [edk2] [PATCH 5/7] QuarkSocPkg-MemoryInitPei: Enable compiler builtin and disable CLANG LTO

2016-07-04 Thread Shi, Steven
I will separate the Quark platform code cleanup work from this serial patches. 
Thanks.


Steven Shi
Intel\SSG\STO\UEFI Firmware

Tel: +86 021-61166522
iNet: 821-6522


> -Original Message-
> From: Kinney, Michael D
> Sent: Thursday, June 30, 2016 2:10 AM
> To: af...@apple.com; Shi, Steven ; Kinney, Michael D
> 
> Cc: edk2-devel ; Gao, Liming
> ; Zimmer, Vincent ;
> Doran, Mark ; Mudusuru, Giri P
> 
> Subject: RE: [PATCH 5/7] QuarkSocPkg-MemoryInitPei: Enable compiler
> builtin and disable CLANG LTO
> 
> Andrew,
> 
> I agree.  I will work with Steven on this module to improve its compiler
> compatibility.
> 
> Mike
> 
> > -Original Message-
> > From: af...@apple.com [mailto:af...@apple.com]
> > Sent: Wednesday, June 29, 2016 10:57 AM
> > To: Shi, Steven 
> > Cc: edk2-devel ; Gao, Liming
> ; Kinney,
> > Michael D ; Zimmer, Vincent
> ;
> > Doran, Mark ; Mudusuru, Giri P
> 
> > Subject: Re: [PATCH 5/7] QuarkSocPkg-MemoryInitPei: Enable compiler
> builtin and disable
> > CLANG LTO
> >
> >
> > > On Jun 28, 2016, at 8:18 AM, Shi, Steven  wrote:
> > >
> > > The MRC use the memset() in the code and assume the compiler to offer
> > > such builtin fuctions. Add work around to permit compiler add builtin
> > > functions in this module. Also MRC mix some inline assembly,
> > > e.g. asm("rdtsc":"=a"(tscL),"=d"(tscH)),in the C code, and CLANG38
> > > could wrongly remove them if enable LTO with high optimization level.
> > > Add work around to simply disable the LTO in this module.
> > >
> >
> > Steven,
> >
> > If this code is in the edk2 it should follow the edk2 coding rules and we
> should clean
> > it up and not propagate the workarounds to new compilers. Not following
> the rules in
> > the 1st place is what made this code harder to port. Actually if you look at
> the code
> > it started off using VC++ compiler intrinsics and inline assembler syntax,
> and then it
> > had to add some hacky #ifdefs to compile with GCC. If the code just used
> BaseLib and
> > BaseMemoryLib it would not require compiler specific hacks.
> >
> > Why not fix the code to NOT depend on compiler intrinsics and use
> ZeroMem()?
> > /work/src/edk2/QuarkSocPkg/QuarkNorthCluster/MemoryInit(master)>git
> grep memcpy
> > Pei/meminit_utils.h:94:void *memcpy(void *d, const void *s, size_t n);
> >
> ~/work/src/edk2/QuarkSocPkg/QuarkNorthCluster/MemoryInit(master)>git
> grep memset
> > Pei/MemoryInitPei.inf:79:  # /Oi option to use the intrinsic memset
> function in source
> > code.
> > Pei/meminit.c::  memset((void *) (final_delay), 0x00, (size_t)
> > sizeof(final_delay));
> > Pei/meminit.c:1396:  memset((void *) (final_delay), 0x00, (size_t)
> > sizeof(final_delay));
> > Pei/meminit.c:1650:  memset((void *) (final_delay), 0x00, (size_t)
> > sizeof(final_delay));
> > Pei/meminit.c:1972:  memset((void *) (final_delay), 0x00, (size_t)
> > sizeof(final_delay));
> > Pei/meminit_utils.h:93:void *memset(void *d, int c, size_t n);
> >
> > All the inline assembly code is duplicating BaseLib functionality so why not
> fix it?
> >
> ~/work/src/edk2/QuarkSocPkg/QuarkNorthCluster/MemoryInit(master)>git
> grep -W  asm
> > Pei/meminit.c:2240:static void asm_wbinvd(void)
> > Pei/meminit.c-2241-{
> > Pei/meminit.c-2242-#if defined (SIM) || defined (GCC)
> > Pei/meminit.c:2243:  asm(
> > Pei/meminit.c-2244-"wbinvd;"
> > Pei/meminit.c-2245-  );
> > Pei/meminit.c-2246-#else
> > Pei/meminit.c:2247:  __asm wbinvd;
> > Pei/meminit.c-2248-#endif
> > Pei/meminit.c-2249-}
> > Pei/meminit.c-2250-
> > Pei/meminit.c-2251-// cache invalidate
> > Pei/meminit.c:2252:static void asm_invd(void)
> > Pei/meminit.c-2253-{
> > Pei/meminit.c-2254-#if defined (SIM) || defined (GCC)
> > Pei/meminit.c:2255:  asm(
> > Pei/meminit.c-2256-  "invd;"
> > Pei/meminit.c-2257-  );
> > Pei/meminit.c-2258-#else
> > Pei/meminit.c:2259:  __asm invd;
> > Pei/meminit.c-2260-#endif
> > Pei/meminit.c-2261-}
> > Pei/meminit.c-2262-
> > Pei/meminit.c-2263-
> > Pei/meminit.c=2264=static void cpu_read(void)
> > Pei/meminit.c-2265-{
> > Pei/meminit.c-2266-  uint32_t adr, dat, limit;
> > Pei/meminit.c-2267-
> > Pei/meminit.c:2268:  asm_invd();
> > Pei/meminit.c-2269-
> > Pei/meminit.c-2270-  limit = 8 * 1024;
> > Pei/meminit.c-2271-  for (adr = 0; adr < limit; adr += 4)
> > Pei/meminit.c-2272-  {
> > Pei/meminit.c-2273-dat = *(uint32_t*) adr;
> > Pei/meminit.c-2274-if ((adr & 0x0F) == 0)
> > Pei/meminit.c-2275-{
> > Pei/meminit.c-2276-  DPF(D_INFO, "\n%x : ", adr);
> > Pei/meminit.c-2277-}
> > Pei/meminit.c-2278-DPF(D_INFO, "%x ", dat);
> > Pei/meminit.c-2279-  }
> > Pei/meminit.c-2280-  DPF(D_INFO, "\n");
> > Pei/meminit.c-2281-
> > Pei/meminit.c-2282-  DPF(D_INFO, "CPU read done\n");
> > Pei/meminit.c-2283-}
> > Pei/meminit.c-2284-
> > Pei/meminit.c-2285-
> > Pei/meminit.c=2286=static void cpu_write(void)
> > Pei/meminit.c-2287-{
> > Pei/meminit.c-2288-  uint32_t adr, limit;
> > Pei/meminit.c-2289-
> > Pei/meminit.c-2290-  limit = 8 * 1024;
> > Pei/meminit.c

Re: [edk2] [PATCH 3/7] MdePkg: Enable new MS VA intrinsics for GNUC 64bits build

2016-07-04 Thread Shi, Steven
Yes. MS VA intrinsic (__builtin_ms_va_*) can work on GCC44, and in fact, GCC44 
should have to use them for Uefi 64bits build. The current GCC44 wrongly use 
UNIX  VA intrinsics (__builtin_va_*) as default which cause generate wrong VA 
code if enable -O2 or higher optimization (e.g. -Os). I could fix them on GCC44 
as well in a separate patch later.


Steven Shi
Intel\SSG\STO\UEFI Firmware

Tel: +86 021-61166522
iNet: 821-6522

> -Original Message-
> From: Justen, Jordan L
> Sent: Thursday, June 30, 2016 5:47 AM
> To: Andrew Fish 
> Cc: Shi, Steven ; edk2-devel@lists.01.org; Gao,
> Liming ; Kinney, Michael D
> 
> Subject: Re: [edk2] [PATCH 3/7] MdePkg: Enable new MS VA intrinsics for
> GNUC 64bits build
> 
> On 2016-06-29 14:31:49, Andrew Fish wrote:
> >
> > > On Jun 29, 2016, at 2:02 PM, Jordan Justen 
> wrote:
> > >
> > > On 2016-06-28 08:18:57, Shi, Steven wrote:
> > >> Both GCC and LLVM 3.8 64bits support new variable argument (VA)
> > >
> > > Which versions of GCC? Maybe we should define MS_VA_LIST on the
> > > command line for toolchains that can support this?
> > >
> >
> > Maybe I'm backwards but VA_LIST is by definition MS_VA_LIST. What
> > you lose access to is UNIX_VA_LIST?
> >
> > Thus for a compiler that uses the EFIAPI __builtin_va_arg is EFIABI.
> > For a compiler that produces Sys V ABI __builtin_va_arg is the Unix
> > ABI. I verified this assertion with the clang maintainers.
> >
> > VA_LIST always points to EFIAPI and that is why you have to decorate
> > var arg functions with EFIAPI to match VA_LIST.
> >
> > We could add a NATIVE_VA_LIST but for an compiler that natively does
> > EFIAPI it would be the same a VA_LIST. Thus it would be hard to
> > enforce, but it would let some one that knew what they are doing get
> > access to __builtin_va_arg. The problem is if you know what you are
> > doing you can decorate with EFIAPI so is adding NATIVE_VA_LIST
> > really solving any problem?
> >
> 
> My concern was more about if this patch would work on GCC44. I think
> Steven has been testing with GCC5+, so I thought it might be better to
> selectively enable usage of __builtin_ms_va_list for each toolchain.
> 
> -Jordan
> 
> > >
> > >> intrinsics for Microsoft ABI, enable these new VA intrinsics for
> > >> GNUC family 64bits code build. These VA intrinsics are only
> > >> permitted use in 64bits code, so not use them in 32bits code build.
> > >> The original 32bits GNU VA intrinsics has the same calling conversion
> > >> as MS, so we don’t need change them.
> > >>
> > >> Contributed-under: TianoCore Contribution Agreement 1.0
> > >> Signed-off-by: Steven Shi 
> > >> ---
> > >> MdePkg/Include/Base.h | 27 +--
> > >> 1 file changed, 25 insertions(+), 2 deletions(-)
> > >> mode change 100644 => 100755 MdePkg/Include/Base.h
> > >>
> > >> diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
> > >> old mode 100644
> > >> new mode 100755
> > >> index cbd9e55..05fccf3
> > >> --- a/MdePkg/Include/Base.h
> > >> +++ b/MdePkg/Include/Base.h
> > >> @@ -588,9 +588,32 @@ struct _LIST_ENTRY {
> > >>
> > >> #define VA_COPY(Dest, Start)  __va_copy (Dest, Start)
> > >>
> > >> -#elif defined(__GNUC__) && !defined(NO_BUILTIN_VA_FUNCS)
> > >> +
> > >> +#elif defined(__GNUC__) && !defined(NO_BUILTIN_VA_FUNCS)
> && !defined (EFI32)
> > >> +//
> > >> +// 64bits build only. Use GCC built-in macros for variable argument 
> > >> lists.
> > >> +//
> > >> +///
> > >> +/// Both GCC and LLVM 3.8 64bits support new variable argument
> intrinsics for Microsoft ABI
> > >> +///
> > >> +
> > >> +///
> > >> +/// Variable used to traverse the list of arguments. This type can vary
> by
> > >> +/// implementation and could be an array or structure.
> > >> +///
> > >> +typedef __builtin_ms_va_list VA_LIST;
> > >> +
> > >> +#define VA_START(Marker, Parameter)  __builtin_ms_va_start (Marker,
> Parameter)
> > >> +
> > >> +#define VA_ARG(Marker, TYPE) ((sizeof (TYPE) < sizeof (UINTN)) ?
> (TYPE)(__builtin_va_arg (Marker, UINTN)) : (TYPE)(__builtin_va_arg (Marker,
> TYPE)))
> > >> +
> > >> +#define VA_END(Marker)   __builtin_ms_va_end (Marker)
> > >> +
> > >> +#define VA_COPY(Dest, Start) __builtin_ms_va_copy (Dest, Start)
> > >> +
> > >> +#elif defined(__GNUC__) && !defined(NO_BUILTIN_VA_FUNCS) &&
> defined (EFI32)
> > >> //
> > >> -// Use GCC built-in macros for variable argument lists.
> > >> +// 32bits build only. Use GCC built-in macros for variable argument 
> > >> lists.
> > >> //
> > >>
> > >> ///
> > >> --
> > >> 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
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
h

Re: [edk2] Memory Profile question.

2016-07-04 Thread Ramesh R .
Is there any way we can track the FreePool also ? In the end is it possible to 
identify which are all the memory area allocated, but no freed by system BIOS ?

Thanks,
Ramesh

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew 
Fish
Sent: 30 June 2016 19:47
To: Yao, Jiewen
Cc: edk2-devel
Subject: Re: [edk2] Memory Profile question.


> On Jun 30, 2016, at 12:05 AM, Yao, Jiewen  wrote:
> 
> Yes, Andrew. You are right.
> We encounter similar problem, but it seems MSVC _ReturnAddress() does not 
> take parameter.
>  #define RETURN_ADDRESS(L) ((L == 0) ? _ReturnAddress() : (VOID *) 0)
> 

For GCC family you can potentially get more info. 

#define RETURN_ADDRESS(L) __builtin_return_address (L)

> So we enhanced MemoryAllocationLib to support add record from 
> MemoryAllocationLib.
> 

Does that mean the logging gets moved to the library? Or does the library log 
just update the log in the DXE Core?

> The final log is like this:
> 
>  CountSize   RVA  Action
> ==  == == 
> ()
> 0x006B  0x0001D31F <== 0xAE7C 
> (gBS->AllocatePool) (InternalAllocatePool() - 
> c:\home\edk-ii\mdemodulepkg\library\smmmemoryallocationlibprofile\memo
> ryallocationlib.c:567)
> 0x0001  0x0020 <== 0xBCB8 
> (Lib:AllocatePool) (SmmMemLibConstructor() - 
> c:\home\edk-ii\mdepkg\library\smmmemlib\smmmemlib.c:309)
> 0x0001  0x0070 <== 0x7F2D 
> (Lib:AllocateZeroRuntimePool) (VariableCommonInitialize() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:4
> 055)
> 0x0001  0xC000 <== 0x715A 
> (Lib:AllocateZeroRuntimePool) (InitNonVolatileVariableStore() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:3
> 692)
> 0x0001  0x00010400 <== 0x8121 
> (Lib:AllocateRuntimePool) (VariableCommonInitialize() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:4
> 113)
> 0x0001  0x0404 <== 0x2957 
> (gBS->AllocatePool) (VariableServiceInitialize() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variablesmm.
> c:956)
> 0x0007  0x01CE <== 0xC42E 
> (Lib:AllocateZeroRuntimePool) (VarCheckLibVariablePropertySet() - 
> c:\home\edk-ii\mdemodulepkg\library\varchecklib\varchecklib.c:521)
> 0x0001  0x0020 <== 0xC071 
> (Lib:ReallocateRuntimePool) (VarCheckAddTableEntry() - 
> c:\home\edk-ii\mdemodulepkg\library\varchecklib\varchecklib.c:228)
> 0x0001  0x0030 <== 0x2E08 
> (Lib:AllocateZeroPool) (UpdateVariableInfo() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:1
> 96)
> 0x0001  0x0044 <== 0x2E68 
> (Lib:AllocateZeroPool) (UpdateVariableInfo() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:2
> 00) 0x002C  0x0840 <== 0x2F98 
> (Lib:AllocateZeroPool) (UpdateVariableInfo() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:2
> 32) 0x002C  0x037C <== 0x2FF6 
> (Lib:AllocateZeroPool) (UpdateVariableInfo() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:2
> 36)
> 0x0001  0x000D <== 0x4DC9 
> (Lib:AllocateCopyRuntimePool) (AutoUpdateLangVariable() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:1
> 960)
> 0x0001  0x0012 <== 0x4CC4 
> (Lib:AllocateCopyRuntimePool) (AutoUpdateLangVariable() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:1
> 930)
> 0x0001  0x0012 <== 0x4D28 
> (Lib:AllocateRuntimePool) (AutoUpdateLangVariable() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:1
> 940)
> 
> 

Are the address ranges allocated tracked? Is it possible to look up an address 
and figure out where it got allocated? 

Any plans to add logging for stalls? You can dump events with a debugger 
script, so that is not as important. 

Thanks,

Andrew Fish

> 
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
>> Of Andrew Fish
>> Sent: Thursday, June 30, 2016 2:38 PM
>> To: edk2-devel 
>> Subject: [edk2] Memory Profile question.
>> 
>> I've done some experimentation on the memory logging and if possible 
>> it is very useful to have 4 stack frames (non-LTO)  as it is common 
>> for the MemoryAllocationLib to to call a sequence of Internal 
>> functions, so to find the calling spot in the driver you need 4 entries.
>> For example:
>> FunctionThatAllocatePool()
>> AllocateZeroPool()
>> InternalAllocateZeroPool()
>> InternalAllocatePool()
>> 
>> I see that only RETURN_ADDRESS (0) is logged.
>>

[edk2] [PATCH] BaseTools MemoryProfileSymbolGen.py: Handle 64bits rva from "nm -l xxx.dll"

2016-07-04 Thread Star Zeng
Current MemoryProfileSymbolGen.py assumes the rva is 32bits,
the patch is to remove the restriction to match any lengths
of rva.

Cc: Jiewen Yao 
Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 BaseTools/Scripts/MemoryProfileSymbolGen.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Scripts/MemoryProfileSymbolGen.py 
b/BaseTools/Scripts/MemoryProfileSymbolGen.py
index a9790d8883c8..5709ad4641cb 100644
--- a/BaseTools/Scripts/MemoryProfileSymbolGen.py
+++ b/BaseTools/Scripts/MemoryProfileSymbolGen.py
@@ -19,7 +19,7 @@ import re
 import sys
 from optparse import OptionParser
 
-versionNumber = "1.0"
+versionNumber = "1.1"
 __copyright__ = "Copyright (c) 2016, Intel Corporation. All rights reserved."
 
 class Symbols:
@@ -72,7 +72,7 @@ class Symbols:
 linefile.close()
 
 # 000113ca T AllocatePool  
c:\home\edk-ii\MdePkg\Library\UefiMemoryAllocationLib\MemoryAllocationLib.c:399
-patchLineFileMatchString = 
"([0-9a-fA-F]{8})\s+[T|D|t|d]\s+(\w+)\s*((?:[a-zA-Z]:)?[\w+\-./_a-zA-Z0-9]*):?([0-9]*)"
+patchLineFileMatchString = 
"([0-9a-fA-F]*)\s+[T|D|t|d]\s+(\w+)\s*((?:[a-zA-Z]:)?[\w+\-./_a-zA-Z0-9]*):?([0-9]*)"
 
 for reportLine in reportLines:
 #print "check - " + reportLine
-- 
2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH] MdeModulePkg MemoryProfileInfo: Handle "/" character in the PDB path

2016-07-04 Thread Star Zeng
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c 
b/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
index 69c6cf166daa..68e7ed7326f0 100644
--- a/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
+++ b/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
@@ -205,7 +205,7 @@ GetShortPdbFileName (
 StartIndex = 0;
 for (EndIndex = 0; PdbFileName[EndIndex] != 0; EndIndex++);
 for (IndexPdb = 0; PdbFileName[IndexPdb] != 0; IndexPdb++) {
-  if (PdbFileName[IndexPdb] == '\\') {
+  if ((PdbFileName[IndexPdb] == '\\') || (PdbFileName[IndexPdb] == '/')) {
 StartIndex = IndexPdb + 1;
   }
 
-- 
2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [Patch] BaseTools: Add support for $(FAMILY) macro

2016-07-04 Thread Yonghong Zhu
Build spec mentions $(FAMILY) macro be used in DSC/FDF to specify the tool
chain family, like GCC, MSFT. This patch add the support for this macro.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/build/build.py | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/BaseTools/Source/Python/build/build.py 
b/BaseTools/Source/Python/build/build.py
index 4f859bf..d9afdcc 100644
--- a/BaseTools/Source/Python/build/build.py
+++ b/BaseTools/Source/Python/build/build.py
@@ -784,10 +784,11 @@ class Build():
 self.Db = WorkspaceDatabase(":memory:")
 else:
 self.Db = WorkspaceDatabase(GlobalData.gDatabasePath, self.Reparse)
 self.BuildDatabase = self.Db.BuildObject
 self.Platform = None
+self.ToolChainFamily = None
 self.LoadFixAddress = 0
 self.UniFlag= BuildOptions.Flag
 self.BuildModules = []
 self.Db_Flag = False
 self.LaunchPrebuildFlag = False
@@ -876,10 +877,21 @@ class Build():
 EdkLogger.error("build", RESOURCE_NOT_AVAILABLE,
 ExtraData="[%s] not defined. No toolchain 
available for build!\n" % ", ".join(self.ToolChainList))
 else:
 self.ToolChainList = NewToolChainList
 
+ToolChainFamily = []
+ToolDefinition = self.ToolDef.ToolsDefTxtDatabase
+for Tool in self.ToolChainList:
+if TAB_TOD_DEFINES_FAMILY not in ToolDefinition or Tool not in 
ToolDefinition[TAB_TOD_DEFINES_FAMILY] \
+   or not ToolDefinition[TAB_TOD_DEFINES_FAMILY][Tool]:
+EdkLogger.warn("No tool chain family found in configuration 
for %s. Default to MSFT." % Tool)
+ToolChainFamily.append("MSFT")
+else:
+
ToolChainFamily.append(ToolDefinition[TAB_TOD_DEFINES_FAMILY][Tool])
+self.ToolChainFamily = ToolChainFamily
+
 if self.ThreadNumber == None:
 self.ThreadNumber = 
self.TargetTxt.TargetTxtDictionary[DataType.TAB_TAT_DEFINES_MAX_CONCURRENT_THREAD_NUMBER]
 if self.ThreadNumber == '':
 self.ThreadNumber = 0
 else:
@@ -934,10 +946,12 @@ class Build():
 if self.ArchList:
 GlobalData.gGlobalDefines['ARCH'] = self.ArchList[0]
 if self.ToolChainList:
 GlobalData.gGlobalDefines['TOOLCHAIN'] = self.ToolChainList[0]
 GlobalData.gGlobalDefines['TOOL_CHAIN_TAG'] = self.ToolChainList[0]
+if self.ToolChainFamily:
+GlobalData.gGlobalDefines['FAMILY'] = self.ToolChainFamily[0]
 if 'PREBUILD' in GlobalData.gCommandLineDefines.keys():
 self.Prebuild   = GlobalData.gCommandLineDefines.get('PREBUILD')
 else:
 self.Db.InitDatabase()
 self.Db_Flag = True
@@ -1597,13 +1611,16 @@ class Build():
 #
 def _BuildPlatform(self):
 SaveFileOnChange(self.PlatformBuildPath, '# DO NOT EDIT \n# FILE 
auto-generated\n', False)
 for BuildTarget in self.BuildTargetList:
 GlobalData.gGlobalDefines['TARGET'] = BuildTarget
+index = 0
 for ToolChain in self.ToolChainList:
 GlobalData.gGlobalDefines['TOOLCHAIN'] = ToolChain
 GlobalData.gGlobalDefines['TOOL_CHAIN_TAG'] = ToolChain
+GlobalData.gGlobalDefines['FAMILY'] = 
self.ToolChainFamily[index]
+index += 1
 Wa = WorkspaceAutoGen(
 self.WorkspaceDir,
 self.PlatformFile,
 BuildTarget,
 ToolChain,
@@ -1677,13 +1694,16 @@ class Build():
 ## Build active module for different build targets, different tool chains 
and different archs
 #
 def _BuildModule(self):
 for BuildTarget in self.BuildTargetList:
 GlobalData.gGlobalDefines['TARGET'] = BuildTarget
+index = 0
 for ToolChain in self.ToolChainList:
 GlobalData.gGlobalDefines['TOOLCHAIN'] = ToolChain
 GlobalData.gGlobalDefines['TOOL_CHAIN_TAG'] = ToolChain
+GlobalData.gGlobalDefines['FAMILY'] = 
self.ToolChainFamily[index]
+index += 1
 #
 # module build needs platform build information, so get 
platform
 # AutoGen first
 #
 Wa = WorkspaceAutoGen(
@@ -1771,13 +1791,16 @@ class Build():
 #
 def _MultiThreadBuildPlatform(self):
 SaveFileOnChange(self.PlatformBuildPath, '# DO NOT EDIT \n# FILE 
auto-generated\n', False)
 for BuildTarget in self.BuildTargetList:
 GlobalData.gGlobalDefines['TARGET'] = BuildTarget
+index = 0
 for ToolChain in self.ToolChainList:
 GlobalData.gGlobalDefines['TOOLCHAIN'] = ToolChain
   

Re: [edk2] [PATCH] MdeModulePkg/UsbBusDxe: Fixed potential NULL pointer dereference UsbSelectConfig

2016-07-04 Thread Evgeny Yakovlev
ping?

2016-06-29 14:54 GMT+03:00 Evgeny Yakovlev :

> Consider the following course of action When enumerating new USB device:
>
> 1. UsbParseConfigDesc is called during new device enumeration process.
> It allocates an array of USB_INTERFACE_DESC pointers in Config->Interfaces.
> Each of those structures have an array of pointers to USB_INTERFACE_SETTING
> which are currently set to NULL.
>
> 2. Then UsbParseConfigDesc calls UsbParseInterfaceDesc as long as there is
> data left in buffer. Each call parses an interface setting and sets
> appropriate pointer in Interface->Settings for related interface desc.
>
> 3. Later UsbSelectConfig traverses Config->Interfaces[NumIf]->Settings
> to pick appropriate interface configuration.
>
> However if during step 2 UsbParseInterfaceDesc returns NULL (i.e.
> because UsbCreateDesc returned NULL, see f89f1db) then config will be
> not fully initialized by the time it is returned to caller. Some pointers
> in
> Config->Interfaces->Settings are still set to NULL and will be possibly
> dereferenced in UsbSelectConfig.
>
> This patch treats this situation as an error and returns NULL
> instead if incompletely initialized config descriptor.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Evgeny Yakovlev 
> CC: Feng Tian 
> ---
>  MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c   | 4 ++--
>  MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c | 3 +++
>  2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c
> b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c
> index fba60da..20e6ca3 100644
> --- a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c
> +++ b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c
> @@ -368,8 +368,8 @@ UsbParseConfigDesc (
>  Setting = UsbParseInterfaceDesc (DescBuf, Len, &Consumed);
>
>  if (Setting == NULL) {
> -  DEBUG (( EFI_D_ERROR, "UsbParseConfigDesc: warning: failed to get
> interface setting, stop parsing now.\n"));
> -  break;
> +  DEBUG (( EFI_D_ERROR, "UsbParseConfigDesc: failed to get interface
> setting, stop parsing now.\n"));
> +  goto ON_ERROR;
>
>  } else if (Setting->Desc.InterfaceNumber >= NumIf) {
>DEBUG (( EFI_D_ERROR, "UsbParseConfigDesc: mal-formated interface
> descriptor\n"));
> diff --git a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
> b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
> index 79453fe..57199a0 100644
> --- a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
> +++ b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
> @@ -412,6 +412,9 @@ UsbSelectConfig (
>  // the endpoint toggles to zero for its endpoints.
>  //
>  IfDesc = ConfigDesc->Interfaces[Index];
> +ASSERT (IfDesc != NULL);
> +ASSERT (IfDesc->Settings[0] != NULL);
> +
>  UsbSelectSetting (IfDesc, IfDesc->Settings[0]->Desc.AlternateSetting);
>
>  //
> --
> 2.7.4 (Apple Git-66)
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH 1/4] MdePkg/IndustryStandard: introduce EFI_PCI_CAPABILITY_ID_SHPC

2016-07-04 Thread Ni, Ruiyu
Reviewed-by: Ruiyu Ni 

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Friday, July 1, 2016 9:11 AM
> To: edk2-devel-01 
> Cc: Johnson, Brian J. ; Alex Williamson
> ; Andrew Fish ; Tian, Feng
> ; Justen, Jordan L ; Gao,
> Liming ; Marcel Apfelbaum ;
> Kinney, Michael D ; Ni, Ruiyu
> ; Zeng, Star 
> Subject: [PATCH 1/4] MdePkg/IndustryStandard: introduce
> EFI_PCI_CAPABILITY_ID_SHPC
> 
> The "Pci22.h" header file defines the macro
> EFI_PCI_CAPABILITY_ID_HOTPLUG with value 0x06. According to all of:
> - later parts of the same header file,
> - Appendix H ("Capability IDs") of the PCI Local Bus Specification
>   Revision 2.3,
> - and Chapter 2 ("Capability IDs") of the PCI Code and ID Assignment
>   Specification Revision 0.9,
> 
> 0x06 means "CompactPCI Hot Swap". It does not mean "PCI Hot-Plug": that
> capability is described by ID 0x0C:
> 
>   0Ch  PCI Hot-Plug -- This Capability ID indicates that the associated
>device conforms to the Standard Hot-Plug Controller model.
> 
> Therefore EFI_PCI_CAPABILITY_ID_HOTPLUG is arguably a misnomer.
> PciBusDxe (mis-)uses EFI_PCI_CAPABILITY_ID_HOTPLUG in the IsSHPC()
> helper function to identify PCI Hot-Plug capability.
> 
> In order to preserve compatibility with existent code, leave
> EFI_PCI_CAPABILITY_ID_HOTPLUG alone, and introduce
> EFI_PCI_CAPABILITY_ID_SHPC with the right ID value.
> 
> Cc: "Johnson, Brian J." 
> Cc: Alex Williamson 
> Cc: Andrew Fish 
> Cc: Feng Tian 
> Cc: Jordan Justen 
> Cc: Liming Gao 
> Cc: Marcel Apfelbaum 
> Cc: Michael D Kinney 
> Cc: Ruiyu Ni 
> Cc: Star Zeng 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
>  MdePkg/Include/IndustryStandard/Pci22.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MdePkg/Include/IndustryStandard/Pci22.h
> b/MdePkg/Include/IndustryStandard/Pci22.h
> index db24a153e15e..4cf8389c699b 100644
> --- a/MdePkg/Include/IndustryStandard/Pci22.h
> +++ b/MdePkg/Include/IndustryStandard/Pci22.h
> @@ -635,6 +635,7 @@ typedef union {
>  #define EFI_PCI_CAPABILITY_ID_SLOTID  0x04
>  #define EFI_PCI_CAPABILITY_ID_MSI 0x05
>  #define EFI_PCI_CAPABILITY_ID_HOTPLUG 0x06
> +#define EFI_PCI_CAPABILITY_ID_SHPC0x0C
> 
>  ///
>  /// Capabilities List Header
> --
> 1.8.3.1
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] Error. The protocol 'gEfiIp4ConfigProtocolGuid' was required and not found

2016-07-04 Thread Ye, Ting
Hi Aravindh,

I see following difference between your working and non-working logs.

29 000A B N N   1   1 ASIX AX88772B Ethernet Driver 2.4.0 
Fv(A881D567-6CB0-4EEE-8435-2E72D33E45B5)/FvFile(25DC8C52-544B-43BF-A58D-995F96DEB726)
2B 000A ? N N   0   0 ASIX AX88772B Ethernet Driver 2.4.0 
Fv(A881D567-6CB0-4EEE-8435-2E72D33E45B5)/FvFile(25DC8C52-544B-43BF-A58D-995F96DEB726)

Is this the particular NIC driver for your network card? I see the NIC card is 
managed by this driver in your working environment.

Thanks,
Ting


-Original Message-
From: Aravindhlal G.S.S [mailto:aravindhlal...@embedur.com] 
Sent: Monday, July 04, 2016 1:06 PM
To: Ye, Ting ; edk2-devel@lists.01.org
Subject: RE: Error. The protocol 'gEfiIp4ConfigProtocolGuid' was required and 
not found

Hi Ting, 

I think it should be fine, because we have a similar setup and that is working 
fine. In the working setup, I could see many of the drivers whose type is not 
yet recognised.
But in case of the working setup, almost many of the drivers are classified and 
they are being used by devices (entries under #D & #C).

I have attached the output of drivers command of both working & non-working 
setups to differentiate it. Could you please take a look at these attached 
files ?

Both of them are running the same version of EFI firmware. Am I missing 
anything big ? 

Thanks
-Aravindh

-Original Message-
From: Ye, Ting [mailto:ting...@intel.com] 
Sent: Monday, July 04, 2016 10:20 AM
To: Aravindhlal G.S.S; edk2-devel@lists.01.org
Subject: RE: Error. The protocol 'gEfiIp4ConfigProtocolGuid' was required and 
not found

Hi Aravindh,

It looks the problem is irrelevant to upper layer drivers including SNP, MNP, 
and others, but your UNDI driver does not manage your NIC card:
F7 000A ? N N   0   0 UNDI32 Driver   
Fv(A881D567-6CB0-4EEE-8435-2E72D33E45B5)/FvFile(A1F436EA-A127-4EF8-957C-8048606FF670)

Is the UNDI driver the correct NIC device driver in UEFI?

Best Regards,
Ting

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
Aravindhlal G.S.S
Sent: Monday, July 04, 2016 12:39 PM
To: Aravindhlal G.S.S ; Ye, Ting 
; edk2-devel@lists.01.org
Subject: Re: [edk2] Error. The protocol 'gEfiIp4ConfigProtocolGuid' was 
required and not found

Sorry, Forgot to attach file in previous email. Attached in this email. 

Hi Ting,

The chipset being used is Puma 7 DOCSIS 3.1 chip. I could also see the UNDI 
driver installed. Please see below.

F7 000A ? N N   0   0 UNDI32 Driver   
Fv(A881D567-6CB0-4EEE-8435-2E72D33E45B5)/FvFile(A1F436EA-A127-4EF8-957C-8048606FF670)

Please see the attached text file the output of drivers command. I tried 
following, but none of them worked. 
*   I reset all the parameters/values to defaults
*   I tried reconnecting all the drivers 
*   I tried to unload and then again load the driver using the 
handle
*   I tried to bind all drivers to a specific devices and start the 
driver
*   I tried to force defaults on all devices using "drvcfg -f 0" 
command

Could you please take a look in the attached text file ? Still am I missing any 
drivers to be installed ? is there any way to reinstall the drivers (SNP, MNP & 
other network drivers) ? Appreciate your help !

Thanks
-Aravindh
-Original Message-
From: Ye, Ting [mailto:ting...@intel.com] 
Sent: Monday, July 04, 2016 7:12 AM
To: Aravindhlal G.S.S; edk2-devel@lists.01.org
Subject: RE: Error. The protocol 'gEfiIp4ConfigProtocolGuid' was required and 
not found

Hi Aravindh,

Which platform are you using for running the network stack? You probably need a 
particular UNDI driver for your Ethernet card if you are not using simulator 
like NT32 platform.

Best Regards,
Ting
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
Aravindhlal G.S.S
Sent: Friday, July 01, 2016 6:42 PM
To: edk2-devel@lists.01.org
Subject: [edk2] Error. The protocol 'gEfiIp4ConfigProtocolGuid' was required 
and not found

Hi Experts,

I am not able to config the Ethernet interface in UEFI shell. I am running

Shell> teractive Shell v2.1
EDK II
UEFI v2.40 (EDK II, 0x0001)

The drivers commands list the required driver, but #D is 0 and Type is "?". Am 
I missing any drivers to be installed ? If so could you please help in sharing 
the pointers ?

 T
 Y C  I
 P F  A
DRV VERSION  E G G #D  #C  DRIVER NAME IMAGE PATH
===  = = = === === === ==
97 000A ? N N   0   0 Simple Network Protocol Driver  
Fv(A881D567-6CB0-4EEE-8435-2E72D33E45B5)/FvFile(A2F436EA-A127-4EF8-957C-8048606FF670)
9C 000A ? N N   0   0 IP4 CONFIG Network Service Driver   
Fv(A881D567-6CB0-4EEE-8435-2E72D33E45B5)/FvFile(26841BDE-920A-4E7A-9FBE-637F477143A6)
9D 000

Re: [edk2] [PATCH 3/4] MdeModulePkg/PciBusDxe: recognize hotplug-capable PCIe ports

2016-07-04 Thread Ni, Ruiyu
Adding Kinney.

Laszlo,
Your patch assumes all PCIE slot are hot plug capable.
But why PCIE spec 3.0 chapter 7.8.9 Slot Capabilities Register (Offset 14h)
contains a BIT called Hot-Plug Capable?
Does your patch also need to check the Hot-Plug Capable bit as well?


BTW, though I am the owner of PciBus driver in EDKII, I am really a newbie to
this area.
Before your patch, I always thought PciHotPlugInit.GetRootHpcList() should
return all hot plug PCIE ports. But after seeing your patch, I went back to
re-read the PI spec and found some words like "root HPCs", "may not be
able to detect these HPCs", which let me agree with your understanding
that GetRootHpcList() only returns these HPCs that cannot be detected by
PciBus.

Thanks,
Ray

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Friday, July 1, 2016 9:11 AM
> To: edk2-devel-01 
> Cc: Ni, Ruiyu ; Tian, Feng ;
> Johnson, Brian J. ; Andrew Fish ;
> Justen, Jordan L ; Marcel Apfelbaum
> ; Zeng, Star 
> Subject: [edk2] [PATCH 3/4] MdeModulePkg/PciBusDxe: recognize hotplug-
> capable PCIe ports
> 
> Section 7.8.2 of the PCI Express specification (r4.0 v0.3), entitled "PCI 
> Express
> Capabilities Register (Offset 02h)", describes the conditions when a PCIe port
> should be considered "supporting hotplug":
> - it should be a root complex port or a switch downstream port, and
> - it should have the "Slot Implemented" bit set.
> 
> This logic is already implemented in at least two open source projects I could
> find:
> 
> - in SeaBIOS by Marcel Apfelbaum: "hw/pci: reserve IO and mem for pci
>   express downstream ports with no devices attached"
>   ,
> 
> - in edk2 itself, in the implementation of the "PCI" UEFI Shell command:
>   see the "PcieExplainTypeSlot" case label in function
>   PciExplainPciExpress(), file
>   "ShellPkg/Library/UefiShellDebug1CommandsLib/Pci.c".
> 
> PciBusDxe recognizes such PCIe ports as bridges, but it doesn't realize they
> support hotplug. In turn PciBusDxe omits getting any resource padding
> information from the platform's EFI_PCI_HOT_PLUG_INIT_PROTOCOL for
> these
> bridges:
> 
>   GatherPpbInfo()[PciEnumeratorSupport.c]
> GetResourcePaddingPpb()  [PciResourceSupport.c]
>   GetResourcePaddingForHpb() [PciHotPlugSupport.c]
> IsPciHotPlugBus()[PciHotPlugSupport.c]
>   //
>   // returns FALSE
>   //
> //
> // the following is not reached:
> //
> gPciHotPlugInit->GetResourcePadding()
> 
> Implement a function called SupportsPcieHotplug() for identifying such ports,
> and call it from IsPciHotPlugBus() (after the call to IsSHPC()).
> 
> Cc: "Johnson, Brian J." 
> Cc: Alex Williamson 
> Cc: Andrew Fish 
> Cc: Feng Tian 
> Cc: Jordan Justen 
> Cc: Marcel Apfelbaum 
> Cc: Ruiyu Ni 
> Cc: Star Zeng 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciHotPlugSupport.h | 19 ++
> MdeModulePkg/Bus/Pci/PciBusDxe/PciHotPlugSupport.c | 71
> 
>  2 files changed, 90 insertions(+)
> 
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciHotPlugSupport.h
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciHotPlugSupport.h
> index 1fb9ba972091..6e02b8b98bf0 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciHotPlugSupport.h
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciHotPlugSupport.h
> @@ -177,6 +177,25 @@ IsSHPC (
>);
> 
>  /**
> +  Check whether PciIoDevice supports PCIe hotplug.
> +
> +  This is equivalent to the following condition:
> +  - the device is either a PCIe switch downstream port or a root port,
> +  - and the device has the SlotImplemented bit set in its PCIe capability
> +register.
> +
> +  @param[in] PciIoDevice  The device being checked.
> +
> +  @retval TRUE   PciIoDevice is a PCIe port that accepts a hotplugged device.
> +  @retval FALSE  Otherwise.
> +
> +**/
> +BOOLEAN
> +SupportsPcieHotplug (
> +  IN PCI_IO_DEVICE  *PciIoDevice
> +  );
> +
> +/**
>Get resource padding if the specified PCI bridge is a hot plug bus.
> 
>@param PciIoDevicePCI bridge instance.
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciHotPlugSupport.c
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciHotPlugSupport.c
> index ca8766869ae7..19dd97a4528d 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciHotPlugSupport.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciHotPlugSupport.c
> @@ -317,6 +317,69 @@ IsSHPC (
>  }
> 
>  /**
> +  Check whether PciIoDevice supports PCIe hotplug.
> +
> +  This is equivalent to the following condition:
> +  - the device is either a PCIe switch downstream port or a root port,
> +  - and the device has the SlotImplemented bit set in its PCIe capability
> +register.
> +
> +  @param[in] PciIoDevice  The device being checked.
> +
> +  @retval TRUE   PciIoDevice is a PCIe port that accepts a