Re: [edk2] How to build Open UEFI for Intel Xeon Server v3

[Dhanasekar J]

Hi Brain,

My server is based on* Intel Xeon E5-2600 v4 / v3 *family.
Will FSP available for this CPU?.  Is Intel enabled FSP support for this
CPU?

Please provide me the info.

Thanks,
Dhanasekar

On Sat, May 6, 2017 at 9:25 AM, Dhanasekar J 
wrote:

> Hi Brain,
>
> Thanks for the info.
>  In *https://github.com/IntelFsp/FSP *,
> I am seeing FSP "*Intel® Xeon® Processor D Product Family*"for , so we
> can boot Intel Server with FSP and we can get PlatformPkg from Intel.
> Am i right ?
>
>
> Thanks,
> Dhanasekar
>
> On Fri, May 5, 2017 at 11:16 PM, Richardson, Brian <
> brian.richard...@intel.com> wrote:
>
>> Intel does not currently have any firmware projects for Intel Xeon
>> platforms in EDK II. If this changes you will be able to find information
>> on https://firmware.intel.com or the EDK II platform repository in
>> github.
>>
>> Intel FSP binaries are available for download from http://intel.com or
>> https://github.com/IntelFsp/FSP. Note not every Intel processor is
>> supported by Intel FSP.
>>
>> Thanks ... br
>> ---
>> Brian Richardson, Senior Technical Marketing Engineer, Intel Software
>> brian.richard...@intel.com -- @intel_brian (Twitter & WeChat)
>> https://software.intel.com/en-us/meet-the-developers/evangel
>> ists/team/brian-richardson
>>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Dhanasekar J
>> Sent: Friday, May 5, 2017 12:20 AM
>> To: edk2-devel@lists.01.org
>> Subject: [edk2] How to build Open UEFI for Intel Xeon Server v3
>>
>> Hi All,
>>
>> I am trying to build BIOS for Inte Xeon Server v3. But I am not seeing
>> PlatformPkg for v3 in https://github.com/tianocore/edk2.
>> 
>>
>> Where can I get PlatformPkg for v3?
>>
>> Is it possible to boot Intel Server by open UEFI source without BIOS
>> vendor help?.
>>
>> Is Intel providing FSP  support Xeon server v3?.
>>
>> Can I able to boot xeon sever v3 with FSP?
>>
>>
>> Thanks,
>> Dhanasekar
>> ___
>> 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] How to build Open UEFI for Intel Xeon Server v3

[Dhanasekar J]

Hi Brain,

Thanks for the info.
 In *https://github.com/IntelFsp/FSP *, I
am seeing FSP "*Intel® Xeon® Processor D Product Family*"for , so we can
boot Intel Server with FSP and we can get PlatformPkg from Intel.
Am i right ?


Thanks,
Dhanasekar

On Fri, May 5, 2017 at 11:16 PM, Richardson, Brian <
brian.richard...@intel.com> wrote:

> Intel does not currently have any firmware projects for Intel Xeon
> platforms in EDK II. If this changes you will be able to find information
> on https://firmware.intel.com or the EDK II platform repository in github.
>
> Intel FSP binaries are available for download from http://intel.com or
> https://github.com/IntelFsp/FSP. Note not every Intel processor is
> supported by Intel FSP.
>
> Thanks ... br
> ---
> Brian Richardson, Senior Technical Marketing Engineer, Intel Software
> brian.richard...@intel.com -- @intel_brian (Twitter & WeChat)
> https://software.intel.com/en-us/meet-the-developers/
> evangelists/team/brian-richardson
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Dhanasekar J
> Sent: Friday, May 5, 2017 12:20 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] How to build Open UEFI for Intel Xeon Server v3
>
> Hi All,
>
> I am trying to build BIOS for Inte Xeon Server v3. But I am not seeing
> PlatformPkg for v3 in https://github.com/tianocore/edk2.
> 
>
> Where can I get PlatformPkg for v3?
>
> Is it possible to boot Intel Server by open UEFI source without BIOS
> vendor help?.
>
> Is Intel providing FSP  support Xeon server v3?.
>
> Can I able to boot xeon sever v3 with FSP?
>
>
> Thanks,
> Dhanasekar
> ___
> 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 2/7] OvmfPkg: remove gUefiOvmfPkgTokenSpaceGuid.PcdSecureBootEnable

[Laszlo Ersek]

This PCD is no longer used.

Cc: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkg.dec| 1 -
 OvmfPkg/OvmfPkgIa32.dsc| 3 ---
 OvmfPkg/OvmfPkgIa32X64.dsc | 3 ---
 OvmfPkg/OvmfPkgX64.dsc | 3 ---
 4 files changed, 10 deletions(-)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 3490f7ca7c07..5627be0bab0a 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -136,7 +136,6 @@ [PcdsDynamic, PcdsDynamicEx]
   gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size|0x0|UINT64|0x27
 
 [PcdsFeatureFlag]
-  gUefiOvmfPkgTokenSpaceGuid.PcdSecureBootEnable|FALSE|BOOLEAN|3
   gUefiOvmfPkgTokenSpaceGuid.PcdQemuBootOrderPciTranslation|TRUE|BOOLEAN|0x1c
   gUefiOvmfPkgTokenSpaceGuid.PcdQemuBootOrderMmioTranslation|FALSE|BOOLEAN|0x1d
 
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index e0779ddaa426..8f8d3472102a 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -400,9 +400,6 @@ [PcdsFeatureFlag]
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE
   gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
-!if $(SECURE_BOOT_ENABLE) == TRUE
-  gUefiOvmfPkgTokenSpaceGuid.PcdSecureBootEnable|TRUE
-!endif
 !if $(SMM_REQUIRE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmEnableBspElection|FALSE
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index bbe26e2cf452..fd554f8f375c 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -405,9 +405,6 @@ [PcdsFeatureFlag]
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE
   gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
-!if $(SECURE_BOOT_ENABLE) == TRUE
-  gUefiOvmfPkgTokenSpaceGuid.PcdSecureBootEnable|TRUE
-!endif
 !if $(SMM_REQUIRE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmEnableBspElection|FALSE
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index ff795815f65f..3bcd488fc7a8 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -405,9 +405,6 @@ [PcdsFeatureFlag]
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE
   gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
-!if $(SECURE_BOOT_ENABLE) == TRUE
-  gUefiOvmfPkgTokenSpaceGuid.PcdSecureBootEnable|TRUE
-!endif
 !if $(SMM_REQUIRE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmEnableBspElection|FALSE
-- 
2.9.3


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

[edk2] [PATCH 5/7] OvmfPkg/PlatformPei: don't allocate reserved mem varstore if SMM_REQUIRE

[Laszlo Ersek]

For the emulated variable store, PlatformPei allocates reserved memory (as
early as possible, so that the address remains the same during reboot),
and PcdEmuVariableNvStoreReserved carries the address to
EmuVariableFvbRuntimeDxe.

However, EmuVariableFvbRuntimeDxe is excluded from the SMM_REQUIRE build,
and then noone consumes PcdEmuVariableNvStoreReserved. Don't waste
reserved memory whenever that's the case.

(Even a dynamic default for PcdEmuVariableNvStoreReserved would be
unnecessary; but that way the PcdSet64S() call in the
ReserveEmuVariableNvStore() function doesn't compile.)

Cc: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkgIa32.dsc| 3 +++
 OvmfPkg/OvmfPkgIa32X64.dsc | 3 +++
 OvmfPkg/OvmfPkgX64.dsc | 3 +++
 OvmfPkg/PlatformPei/Platform.c | 4 +++-
 4 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 64427716c53c..b46eef6cabc3 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -495,7 +495,10 @@ [PcdsFixedAtBuild]
 

 
 [PcdsDynamicDefault]
+  # only set when
+  #   ($(SMM_REQUIRE) == FALSE)
   gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0
+
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 887964cd27c2..08f471fbc542 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -501,7 +501,10 @@ [PcdsFixedAtBuild.X64]
 

 
 [PcdsDynamicDefault]
+  # only set when
+  #   ($(SMM_REQUIRE) == FALSE)
   gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0
+
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index dc5fea3577d4..24053e5ff82d 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -500,7 +500,10 @@ [PcdsFixedAtBuild]
 

 
 [PcdsDynamicDefault]
+  # only set when
+  #   ($(SMM_REQUIRE) == FALSE)
   gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0
+
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0
diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/PlatformPei/Platform.c
index 5e983a8dcea9..1b4dc00b0180 100644
--- a/OvmfPkg/PlatformPei/Platform.c
+++ b/OvmfPkg/PlatformPei/Platform.c
@@ -672,7 +672,9 @@ InitializePlatform (
   mHostBridgeDevId = PciRead16 (OVMF_HOSTBRIDGE_DID);
 
   if (mBootMode != BOOT_ON_S3_RESUME) {
-ReserveEmuVariableNvStore ();
+if (!FeaturePcdGet (PcdSmmSmramRequire)) {
+  ReserveEmuVariableNvStore ();
+}
 PeiFvInitialization ();
 MemMapInitialization ();
 NoexecDxeInitialization ();
-- 
2.9.3


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

[edk2] [PATCH 6/7] OvmfPkg: resolve PcdLib for all PEIMs individually

[Laszlo Ersek]

Currently the default (module type independent) PcdLib resolution is to
BasePcdLibNull.inf, which is inherited by all PEIMs. In the next patch,
we'll flip the PEIM default resolution to PeiPcdLib.inf, but in order to
keep that patch both correct and simple to review, we should spell out the
Null resolution for those two PEIMs (ReportStatusCodeRouterPei and
StatusCodeHandlerPei) that are now the only ones that don't specify an
explicit resolution.

Cc: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkgIa32.dsc| 10 --
 OvmfPkg/OvmfPkgIa32X64.dsc | 10 --
 OvmfPkg/OvmfPkgX64.dsc | 10 --
 3 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index b46eef6cabc3..4fc26c0c66a0 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -559,8 +559,14 @@ [Components]
 
   PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
   }
-  
MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf
-  MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf
+  
MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf 
{
+
+  PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
+  }
+  MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf {
+
+  PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
+  }
   MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf {
 
   PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 08f471fbc542..b82c30656a83 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -567,8 +567,14 @@ [Components.IA32]
 
   PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
   }
-  
MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf
-  MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf
+  
MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf 
{
+
+  PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
+  }
+  MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf {
+
+  PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
+  }
   MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf {
 
   PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 24053e5ff82d..f553a0a1674a 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -566,8 +566,14 @@ [Components]
 
   PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
   }
-  
MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf
-  MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf
+  
MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf 
{
+
+  PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
+  }
+  MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf {
+
+  PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
+  }
   MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf {
 
   PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
-- 
2.9.3


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

[edk2] [PATCH 1/7] OvmfPkg/EmuVariableFvbRuntimeDxe: always format an auth varstore header

[Laszlo Ersek]

In this patch, we extend commit d92eaabefbe0 ("OvmfPkg: simplify
VARIABLE_STORE_HEADER generation", 2016-02-05) to
EmuVariableFvbRuntimeDxe.

This is the difference between FvAndVarTemplate and
FvAndAuthenticatedVarTemplate:

> --- non-auth2017-05-05 22:32:06.001512283 +0200
> +++ auth2017-05-05 22:32:18.841364882 +0200
> @@ -1,7 +1,7 @@
>//
> -  // Templates for standard (non-authenticated) variable FV header
> +  // Templates for authenticated variable FV header
>//
> -  STATIC FVB_FV_HDR_AND_VARS_TEMPLATE FvAndVarTemplate = {
> +  STATIC FVB_FV_HDR_AND_VARS_TEMPLATE FvAndAuthenticatedVarTemplate = {
>  { // EFI_FIRMWARE_VOLUME_HEADER FvHdr;
>// UINT8 ZeroVector[16];
>{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
> @@ -34,7 +34,7 @@
>EFI_FVH_REVISION,
>
>// EFI_FV_BLOCK_MAP_ENTRYBlockMap[1];
> -  {
> +  {
>  {
>2, // UINT32 NumBlocks;
>EMU_FVB_BLOCK_SIZE  // UINT32 Length;
> @@ -44,8 +44,8 @@
>  // EFI_FV_BLOCK_MAP_ENTRY EndBlockMap;
>  { 0, 0 }, // End of block map
>  { // VARIABLE_STORE_HEADER  VarHdr;
> -  // EFI_GUID  Signature;
> -  EFI_VARIABLE_GUID,
> +// EFI_GUID  Signature; // need authenticated variables for 
> secure boot
> +EFI_AUTHENTICATED_VARIABLE_GUID,
>
>// UINT32  Size;
>(

After this change, using "-bios", the variable driver logs:

- with the SB feature enabled:
> Variable driver will work with auth variable format!
> Variable driver will work with auth variable support!

- with the SB feature disabled:
> Variable driver will work with auth variable format!
> Variable driver will continue to work without auth variable support!

Cc: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf |  3 -
 OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c   | 79 ++--
 2 files changed, 5 insertions(+), 77 deletions(-)

diff --git a/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf 
b/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf
index 4d4827decb52..69b3c9972a76 100644
--- a/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf
+++ b/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf
@@ -68,9 +68,6 @@ [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase
   gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved
 
-[FeaturePcd]
-  gUefiOvmfPkgTokenSpaceGuid.PcdSecureBootEnable
-
 [Depex]
   TRUE
 
diff --git a/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c 
b/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c
index dec6d4af50df..7a6d3153ec8c 100644
--- a/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c
+++ b/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c
@@ -626,75 +626,6 @@ InitializeFvAndVariableStoreHeaders (
   )
 {
   //
-  // Templates for standard (non-authenticated) variable FV header
-  //
-  STATIC FVB_FV_HDR_AND_VARS_TEMPLATE FvAndVarTemplate = {
-{ // EFI_FIRMWARE_VOLUME_HEADER FvHdr;
-  // UINT8 ZeroVector[16];
-  { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
-
-  // EFI_GUID  FileSystemGuid;
-  EFI_SYSTEM_NV_DATA_FV_GUID,
-
-  // UINT64FvLength;
-  EMU_FVB_SIZE,
-
-  // UINT32Signature;
-  EFI_FVH_SIGNATURE,
-
-  // EFI_FVB_ATTRIBUTES_2  Attributes;
-  0x4feff,
-
-  // UINT16HeaderLength;
-  EMU_FV_HEADER_LENGTH,
-
-  // UINT16Checksum;
-  0,
-
-  // UINT16ExtHeaderOffset;
-  0,
-
-  // UINT8 Reserved[1];
-  {0},
-
-  // UINT8 Revision;
-  EFI_FVH_REVISION,
-
-  // EFI_FV_BLOCK_MAP_ENTRYBlockMap[1];
-  { 
-{
-  2, // UINT32 NumBlocks;
-  EMU_FVB_BLOCK_SIZE  // UINT32 Length;
-}
-  }
-},
-// EFI_FV_BLOCK_MAP_ENTRY EndBlockMap;
-{ 0, 0 }, // End of block map
-{ // VARIABLE_STORE_HEADER  VarHdr;
-  // EFI_GUID  Signature;
-  EFI_VARIABLE_GUID,
-
-  // UINT32  Size;
-  (
-FixedPcdGet32 (PcdVariableStoreSize) -
-OFFSET_OF (FVB_FV_HDR_AND_VARS_TEMPLATE, VarHdr)
-  ),
-
-  // UINT8   Format;
-  VARIABLE_STORE_FORMATTED,
-
-  // UINT8   State;
-  VARIABLE_STORE_HEALTHY,
-
-  // UINT16  Reserved;
-  0,
-
-  // UINT32  Reserved1;
-  0
-}
-  };
-
-  //
   // Templates for authenticated variable FV header
   //
   STATIC FVB_FV_HDR_AND_VARS_TEMPLATE FvAndAuthenticatedVarTemplate = {
@@ -768,11 +699,11 @@ InitializeFvAndVariableStoreHeaders (
   //
   // Copy the template structure into the location
   //
-  if (FeaturePcdGet (PcdSecureBootEnable) == FALSE) {
-CopyMem (Ptr, (VOID*)&FvAndVarTemplate, sizeof (FvAndVarTemplate));
-  } else {
-CopyMem (Ptr, (VOID*)&FvAndAuthenticatedVarTemplate, sizeof 
(FvAndAuthenticatedVarTemplate));
-  }
+  CopyMem (
+P

[edk2] [PATCH 3/7] OvmfPkg/PlatformPei: remove unused PcdVariableStoreSize dependency

[Laszlo Ersek]

Cc: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/PlatformPei/PlatformPei.inf | 1 -
 1 file changed, 1 deletion(-)

diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
b/OvmfPkg/PlatformPei/PlatformPei.inf
index 53c6dd445a0e..a1e12c1fc7e2 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
@@ -84,7 +84,6 @@ [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd
   gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes
   gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress
-  gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
   gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved
-- 
2.9.3


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

[edk2] [PATCH 4/7] OvmfPkg: sync PcdVariableStoreSize with PcdFlashNvStorageVariableSize

[Laszlo Ersek]

"MdeModulePkg/MdeModulePkg.dec" declares PcdVariableStoreSize like this:

> The size of volatile buffer. This buffer is used to store VOLATILE
> attribute variables.

There is no inherent reason why the size of the volatile variable store
should match the same of the non-volatile variable store. Indeed flash
variables in the 4MB build work fine without this equality.

However, OvmfPkg/EmuVariableFvbRuntimeDxe uses PcdVariableStoreSize to
initialize the non-volatile VARIABLE_STORE_HEADER too. (Presumably based
on the fact that ultimately that storage will not be permanent.) When
using EmuVariableFvbRuntimeDxe in the 4MB build, the mismatch between the
two mentioned PCDs (which is apparent through EmuVariableFvbRuntimeDxe's
VARIABLE_STORE_HEADER) triggers an assertion in the variable driver:

> ASSERT MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c(3772):
> mNvVariableCache->Size == VariableStoreLength

Bringing PcdVariableStoreSize in sync with PcdFlashNvStorageVariableSize
fixes this. It also happens to ensure a volatile store size in the 4MB
build that equals the non-volatile store size, which likely doesn't hurt
for symmetry.

Cc: Jordan Justen 
Fixes: b24fca05751f8222acf264853709012e0ab7bf49
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkgIa32.dsc| 3 ++-
 OvmfPkg/OvmfPkgIa32X64.dsc | 3 ++-
 OvmfPkg/OvmfPkgX64.dsc | 3 ++-
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 8f8d3472102a..64427716c53c 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -414,12 +414,13 @@ [PcdsFixedAtBuild]
 !if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x2000
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x2800
+  gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0xe000
 !endif
 !if $(FD_SIZE_IN_KB) == 4096
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x8400
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x8400
+  gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0x4
 !endif
-  gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0xe000
 
   gEfiMdeModulePkgTokenSpaceGuid.PcdVpdBaseAddress|0x0
 
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index fd554f8f375c..887964cd27c2 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -419,12 +419,13 @@ [PcdsFixedAtBuild]
 !if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x2000
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x2800
+  gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0xe000
 !endif
 !if $(FD_SIZE_IN_KB) == 4096
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x8400
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x8400
+  gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0x4
 !endif
-  gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0xe000
 
   gEfiMdeModulePkgTokenSpaceGuid.PcdVpdBaseAddress|0x0
 
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 3bcd488fc7a8..dc5fea3577d4 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -419,12 +419,13 @@ [PcdsFixedAtBuild]
 !if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x2000
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x2800
+  gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0xe000
 !endif
 !if $(FD_SIZE_IN_KB) == 4096
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x8400
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x8400
+  gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0x4
 !endif
-  gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0xe000
 
   gEfiMdeModulePkgTokenSpaceGuid.PcdVpdBaseAddress|0x0
 
-- 
2.9.3


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

[edk2] [PATCH 7/7] OvmfPkg: resolve PcdLib for PEIMs to PeiPcdLib by default

[Laszlo Ersek]

In the previous patch we had to add two explicit Null resolutions, but
here we can remove five PeiPcdLib ones, after setting the default to it.

Cc: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkgIa32.dsc| 22 +---
 OvmfPkg/OvmfPkgIa32X64.dsc | 22 +---
 OvmfPkg/OvmfPkgX64.dsc | 22 +---
 3 files changed, 15 insertions(+), 51 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 4fc26c0c66a0..bd115c9ced93 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -256,6 +256,7 @@ [LibraryClasses.common.PEIM]
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
   MpInitLib|UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/PeiQemuFwCfgS3LibFwCfg.inf
+  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
 
 [LibraryClasses.common.DXE_CORE]
   HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
@@ -567,32 +568,19 @@ [Components]
 
   PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
   }
-  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf {
-
-  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
-  }
+  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
 
-  OvmfPkg/PlatformPei/PlatformPei.inf {
-
-  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
-  }
+  OvmfPkg/PlatformPei/PlatformPei.inf
   UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf {
 
-  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
 !if $(SMM_REQUIRE) == TRUE
   LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf
 !endif
   }
 !if $(SMM_REQUIRE) == TRUE
-  OvmfPkg/SmmAccess/SmmAccessPei.inf {
-
-  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
-  }
+  OvmfPkg/SmmAccess/SmmAccessPei.inf
 !endif
-  UefiCpuPkg/CpuMpPei/CpuMpPei.inf {
-
-  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
-  }
+  UefiCpuPkg/CpuMpPei/CpuMpPei.inf
 
   #
   # DXE Phase modules
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index b82c30656a83..9727db842922 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -261,6 +261,7 @@ [LibraryClasses.common.PEIM]
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
   MpInitLib|UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/PeiQemuFwCfgS3LibFwCfg.inf
+  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
 
 [LibraryClasses.common.DXE_CORE]
   HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
@@ -575,32 +576,19 @@ [Components.IA32]
 
   PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
   }
-  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf {
-
-  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
-  }
+  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
 
-  OvmfPkg/PlatformPei/PlatformPei.inf {
-
-  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
-  }
+  OvmfPkg/PlatformPei/PlatformPei.inf
   UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf {
 
-  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
 !if $(SMM_REQUIRE) == TRUE
   LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf
 !endif
   }
 !if $(SMM_REQUIRE) == TRUE
-  OvmfPkg/SmmAccess/SmmAccessPei.inf {
-
-  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
-  }
+  OvmfPkg/SmmAccess/SmmAccessPei.inf
 !endif
-  UefiCpuPkg/CpuMpPei/CpuMpPei.inf {
-
-  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
-  }
+  UefiCpuPkg/CpuMpPei/CpuMpPei.inf
 
 [Components.X64]
   #
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index f553a0a1674a..61aaed761657 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -261,6 +261,7 @@ [LibraryClasses.common.PEIM]
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
   MpInitLib|UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/PeiQemuFwCfgS3LibFwCfg.inf
+  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
 
 [LibraryClasses.common.DXE_CORE]
   HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
@@ -574,32 +575,19 @@ [Components]
 
   PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
   }
-  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf {
-
-  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
-  }
+  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
 
-  OvmfPkg/PlatformPei/PlatformPei.inf {
-
-  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
-  }
+  OvmfPkg/PlatformPei/PlatformPei.inf
   UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf {
 
-  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
 !if $(SMM_REQUIRE) == TRUE
   LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf
 !endif
   }
 !if $(SMM_REQUIRE) == TRUE
-  OvmfPkg/SmmAccess/SmmAccessPei.inf {
-
-  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
-  }
+  OvmfPk

[edk2] [PATCH 0/7] OvmfPkg: small cleanups and tweaks

[Laszlo Ersek]

(I'm posting this on my free time. As if there is such a thing.)

Most of these patches have been lying around in my personal tree for
quite some time. They should be uncontroversial easy-to-verify small
improvements (famous last words I guess), so I'll try to flush them now.

They are loosely related to:
- https://bugzilla.tianocore.org/show_bug.cgi?id=386
- https://bugzilla.tianocore.org/show_bug.cgi?id=527

Yes, I tested this with "-bios".

Repo:   https://github.com/lersek/edk2.git
Branch: small_tweaks

Cc: Jordan Justen 

Thanks
Laszlo

Laszlo Ersek (7):
  OvmfPkg/EmuVariableFvbRuntimeDxe: always format an auth varstore
header
  OvmfPkg: remove gUefiOvmfPkgTokenSpaceGuid.PcdSecureBootEnable
  OvmfPkg/PlatformPei: remove unused PcdVariableStoreSize dependency
  OvmfPkg: sync PcdVariableStoreSize with PcdFlashNvStorageVariableSize
  OvmfPkg/PlatformPei: don't allocate reserved mem varstore if
SMM_REQUIRE
  OvmfPkg: resolve PcdLib for all PEIMs individually
  OvmfPkg: resolve PcdLib for PEIMs to PeiPcdLib by default

 OvmfPkg/OvmfPkg.dec  |  1 -
 OvmfPkg/OvmfPkgIa32.dsc  | 37 -
 OvmfPkg/OvmfPkgIa32X64.dsc   | 37 -
 OvmfPkg/OvmfPkgX64.dsc   | 37 -
 OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf |  3 -
 OvmfPkg/PlatformPei/PlatformPei.inf  |  1 -
 OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c   | 79 ++--
 OvmfPkg/PlatformPei/Platform.c   |  4 +-
 8 files changed, 56 insertions(+), 143 deletions(-)

-- 
2.9.3

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

Re: [edk2] "Package" multi-select gone from Bugzilla?

[Laszlo Ersek]

On 05/05/17 20:41, Kinney, Michael D wrote:
> Hi Laszlo,
> 
> Thanks for the feedback.  Please try again.  I have
> adjusted the configuration.

Thank you, everything works fine now. I see the N/A value in the Package
list as well, which I presume is for Docs reports (and other reports
that aren't directly tied to the edk2 codebase).

Thanks!
Laszlo

>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Friday, May 5, 2017 10:04 AM
>> To: Kinney, Michael D 
>> Cc: edk2-devel-01 
>> Subject: "Package" multi-select gone from Bugzilla?
>>
>> Hello Mike,
>>
>> I believe the recent change to remove the Package selection field from
>> Bugzilla, for Documentation-related reports, may have removed the field
>> completely. I just filed another TianoCore Feature Request for OvmfPkg
>> (BZ#527), and I couldn't set the Package field; either on the "new bug
>> report" page, or afterwards, on the normal bug view page.
>>
>> Thanks,
>> Laszlo

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

Re: [edk2] "Package" multi-select gone from Bugzilla?

[Kinney, Michael D]

Hi Laszlo,

Thanks for the feedback.  Please try again.  I have
adjusted the configuration.

Mike

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Friday, May 5, 2017 10:04 AM
> To: Kinney, Michael D 
> Cc: edk2-devel-01 
> Subject: "Package" multi-select gone from Bugzilla?
> 
> Hello Mike,
> 
> I believe the recent change to remove the Package selection field from
> Bugzilla, for Documentation-related reports, may have removed the field
> completely. I just filed another TianoCore Feature Request for OvmfPkg
> (BZ#527), and I couldn't set the Package field; either on the "new bug
> report" page, or afterwards, on the normal bug view page.
> 
> Thanks,
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] How to build Open UEFI for Intel Xeon Server v3

[Richardson, Brian]

Intel does not currently have any firmware projects for Intel Xeon platforms in 
EDK II. If this changes you will be able to find information on 
https://firmware.intel.com or the EDK II platform repository in github.

Intel FSP binaries are available for download from http://intel.com or 
https://github.com/IntelFsp/FSP. Note not every Intel processor is supported by 
Intel FSP.

Thanks ... br
---
Brian Richardson, Senior Technical Marketing Engineer, Intel Software
brian.richard...@intel.com -- @intel_brian (Twitter & WeChat)
https://software.intel.com/en-us/meet-the-developers/evangelists/team/brian-richardson
 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
Dhanasekar J
Sent: Friday, May 5, 2017 12:20 AM
To: edk2-devel@lists.01.org
Subject: [edk2] How to build Open UEFI for Intel Xeon Server v3

Hi All,

I am trying to build BIOS for Inte Xeon Server v3. But I am not seeing 
PlatformPkg for v3 in https://github.com/tianocore/edk2.


Where can I get PlatformPkg for v3?

Is it possible to boot Intel Server by open UEFI source without BIOS vendor 
help?.

Is Intel providing FSP  support Xeon server v3?.

Can I able to boot xeon sever v3 with FSP?


Thanks,
Dhanasekar
___
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] "Package" multi-select gone from Bugzilla?

[Laszlo Ersek]

Hello Mike,

I believe the recent change to remove the Package selection field from
Bugzilla, for Documentation-related reports, may have removed the field
completely. I just filed another TianoCore Feature Request for OvmfPkg
(BZ#527), and I couldn't set the Package field; either on the "new bug
report" page, or afterwards, on the normal bug view page.

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

Re: [edk2] [PATCH v2 3/5] OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK

[Laszlo Ersek]

On 05/05/17 17:43, Jordan Justen wrote:
> On 2017-05-05 05:07:25, Laszlo Ersek wrote:
>>
>> Which one do you prefer:
>> (1) I can take your patch, stick in the UINTN cast, and expand the
>> commit message a bit (similarly to what's on my patch),
>> (2) we can go with my patch as well.
> 
> I prefer your patch.
> 
> Re: "0001-OvmfPkg-PlatformPei-handle-non-power-of-two-spare-si.patch"
> 
>> +Alignment = GetPowerOfTwo32 (Alignment) << 1;
> 
> Do you think this might end up needing a UINT32 cast with 64-bit PEI?

No, the prototype is

UINT32
EFIAPI
GetPowerOfTwo32 (
  IN  UINT32Operand
  )

and we can safely shift the returned UINT32 in both 32-bit PEI and
64-bit PEI with the << operator. The result of the shift will also have
type UINT32, which we can safely re-assign to the UINT32 Alignment variable.

Shifting the result of GetPowerOfTwo64() with << would be problematic in
32-bit PEI.

> 
> Reviewed-by: Jordan Justen 

Thanks!

I verified this in the (now again default 2MB build) with the -bios
command line like this:

(1) boot to the UEFI shell normally. The log says:

> Reserved variable store memory: 0x7F5; size: 128kb,
> alignment: 0x1
> ...
> EMU Variable FVB Started
> EMU Variable FVB: Using pre-reserved block at 7F5
> EMU Variable FVB: Basic FV headers were invalid
> Installing FVB for EMU Variable support
> ...
> Ftw: FtwWorkSpaceLba - 0x0, WorkBlockSize  - 0x1,
> FtwWorkSpaceBase - 0xE000
> Ftw: FtwSpareLba - 0x1, SpareBlockSize - 0x1
> Ftw: NumberOfWorkBlock - 0x1, FtwWorkBlockLba - 0x0
> Ftw: WorkSpaceLbaInSpare - 0x0, WorkSpaceBaseInSpare - 0xE000
> Ftw: Remaining work space size - FE0
> Ftw: Work block header check mismatch
> Ftw: Work block header check mismatch
> Ftw: Both working and spare blocks are invalid, init workspace
> Ftw: start to reclaim work space
> Ftw: reclaim work space successfully

(2) run the following shell commands:

Shell>  setvar TestVar -guid ebe29c42-f3d1-4f96-a7c2-5585ce88f056
-bs -nv
="0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef"

Shell> reset

(3) after reboot, the log says:

> Reserved variable store memory: 0x7F5; size: 128kb,
> alignment: 0x1
> ...
> EMU Variable FVB Started
> EMU Variable FVB: Using pre-reserved block at 7F5
> EMU Variable FVB: Found valid pre-existing FV
> ...
> Ftw: FtwWorkSpaceLba - 0x0, WorkBlockSize  - 0x1,
> FtwWorkSpaceBase - 0xE000
> Ftw: FtwSpareLba - 0x1, SpareBlockSize - 0x1
> Ftw: NumberOfWorkBlock - 0x1, FtwWorkBlockLba - 0x0
> Ftw: WorkSpaceLbaInSpare - 0x0, WorkSpaceBaseInSpare - 0xE000
> Ftw: Remaining work space size - FE0

(4) run the following shell command:

Shell> setvar TestVar -guid ebe29c42-f3d1-4f96-a7c2-5585ce88f056
EBE29C42-F3D1-4F96-A7C2-5585CE88F056 - TestVar - 0040 Bytes
01 23 45 67 89 AB CD EF 01 23 45 67 89 AB CD EF 01 23 45 67 89 AB CD EF
01 23 45 67 89 AB CD EF 01 23 45 67 89 AB CD EF 01 23 45 67 89 AB CD EF
01 23 45 67 89 AB CD EF 01 23 45 67 89 AB CD EF


Also tested this with the 4MB build, using pflash. The log says

> Reserved variable store memory: 0xBFE8; size: 528kb,
> alignment: 0x8

The alignment is 512KB, which is the next power of two after 264KB.

> 
>> Regarding the non-flash path, I have the attached work-in-progress patches:
>>
>> - "OvmfPkg: sync PcdVariableStoreSize with PcdFlashNvStorageVariableSize",
>> - and "wip".
> 
> I looked over the non-wip patch, and it seems good, but maybe we
> should just revert the default size for now.

Works for me.

> For a revert of bba8dfbec3bbc4fba7fa6398ba3cf76593e0725e:
> 
> Reviewed-by: Jordan Justen 
> 

Thanks!

Commits:

  1  6e49d01cfb43 Revert "OvmfPkg: make the 4MB flash size the default"
  2  0c79471d6a98 OvmfPkg/PlatformPei: handle non-power-of-two spare
  size for emu variables

I've also filed the following TianoCore Feature Request:

https://bugzilla.tianocore.org/show_bug.cgi?id=527

If you or Gary feel inclined to work on this, that would be awesome. I
have no idea when I'll get to it; my TODO list hasn't been this long in
ages. Of course I cannot really *request* that you guys please pick up
my slack, just sayin' that you please feel free to... :)

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

Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

[Kinney, Michael D]

Star,

I think Tim's feedback is a request for an additional feature 
on top of this RFC.  I do not see any requests for changes to
the proposed syntax extensions.  I agree that implementing these
new feature in an edk2-staging branch makes a lot of sense.
 
Since Tim's request is about access to the SKU relationships from
FW modules when the FW module executes, let's discuss this from
an API perspective instead of detailed autogen.  We can figure
out what autogen is required to support the API.

When a platform boots with multiple SKUs enabled in the FW image,
typically a platform PEIM detects what SKU is present can calls
the PcdLib function LibPcdSetSku() to set the active SKU.

Then, that same module or other modules may want to know how the
current SKU is related to other SKUs.  Those other modules can
start with LibPcdGetSku() to get the active SKU.

This RFC introduces the concept that one SKU may be a derivative
of another SKU, and may be used to reduce the total number PCD
statements in a DSC file.  This derivative concept can be thought
of as parent to child link between the 2 SKUs.  We can draw this 
visually as a tree with parent child relationships between all the
SKUs.

Now from a module that calls LibPcdGetSku(), the module may want
to know who the parent SKU is.  The information we have about the
parent SKU is the SKU ID value.

A new API that may be useful here is something like:

UINTN
GetParentSku (
  IN UINTN  SkuId
  );

The algorithm that Tim provided below uses autogen and a loop
to retrieve the parent SKU.

So the request here is to extend the autogen to support a lookup
of the parent SKU given any valid SKU ID value.

Thanks,

Mike
 
> -Original Message-
> From: Zeng, Star
> Sent: Friday, May 5, 2017 3:08 AM
> To: Tim Lewis ; Kinney, Michael D 
> ;
> edk2-devel@lists.01.org
> Cc: Gao, Liming ; Zeng, Star 
> Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance
> 
> Tim,
> 
> In your code base, there are other tools beyond BaseTools to parse the 
> [SkuIds]
> section and SKUID_IDENTIFIER in DSC, right?
> 
> The boot time usage (use the value in DEFAULT SKU instead if the value in 
> specified
> SKU is not configured) for other resources in your code base is similar to 
> PCD, right?
> This RFC has no change to this boot time behavior that "use the value in 
> DEFAULT SKU
> instead if the value in specified SKU is not configured".
> So I am still not so clear about the benefit of the macro like #define
> SKUID_IDENTIFIER_DEFAULT 2,1,0,1,0,0.
> 
> 
> The DSC syntax extension in this RFC is OPTIONAL, the backward compatibility 
> is
> expected to be kept, no current tools and code should be impacted.
> As I know, there will be a staging branch proposed for the development of PCD 
> related
> RFCs (include Structure PCD, etc). Mike and Liming can help confirm it.
> How about we have the development of this RFC to the staging branch first, 
> then you
> can help evaluate the syntax and provide feedback further? :)
> 
> 
> Thanks,
> Star
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tim 
> Lewis
> Sent: Friday, May 5, 2017 12:36 AM
> To: Zeng, Star ; Kinney, Michael D 
> ;
> edk2-devel@lists.01.org
> Cc: Gao, Liming 
> Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance
> 
> Star --
> 
> I understand your use case. We use the same behavior for other resources 
> besides PCD.
> 
> All we are asking is that this data that is used by the build tools is also 
> available
> in some form at runtime.
> 
> Thanks,
> 
> Tim
> 
> 
> 
> -Original Message-
> From: Zeng, Star [mailto:star.z...@intel.com]
> Sent: Thursday, May 04, 2017 6:42 AM
> To: Tim Lewis ; Kinney, Michael D 
> ;
> edk2-devel@lists.01.org
> Cc: Gao, Liming ; Zeng, Star 
> Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance
> 
> Tim,
> 
> To avoid misunderstanding, I think I need to clarify more about this RFC. :)
> 
> This RFC is NOT to propose building real relationship (like parent-child) 
> between non-
> DEFAULT SKUs, it seems easy to bring confusion from the proposed syntax "
> SkuValue|SkuName[|ParentSkuName]", especially the word 'Parent', sorry for any
> confusion.
> The syntax extension proposed by this RFC is just to simplify the PCDs 
> configuring for
> multiple SKUs in DSC, I want to emphasize it is in DSC, it is to cover the 
> case that
> some non-DEFAULT SKU has much PCD values equal with another non-DEFAULT SKU, 
> but less
> PCD values equal with DEFAULT SKU.
> This RFC has no any change to boot time behavior and does not break the rule 
> that
> DEFAULT SKU PCD value will be returned if the specified SKU PCD value is not
> configured in DSC, the code logic is below.
> 
> PcdPeim Service.c:
>   //
>   // Find the current system's SKU ID entry in SKU ID table.
>   //
>   FoundSku = FALSE;
>   for (Index = 0; Index < SkuIdTable[0]; Index++) {
> if (PeiPcdDb->SystemSkuId == SkuIdTable[Index + 1]) {
>   Foun

Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

[Tim Lewis]

Star,

We would like to track the exact same defaulting as is used by PCDs. Otherwise 
it is confusing to users. If we were to say, "Use the this defaulting scheme 
for PCDs, but ignore it for all of the other runtime resource selection." That 
would be confusing to users. Of course, we can decide not to use this, but we 
actually like it.

Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zeng, 
Star
Sent: Friday, May 05, 2017 3:08 AM
To: Tim Lewis ; Kinney, Michael D 
; edk2-devel@lists.01.org
Cc: Zeng, Star ; Gao, Liming 
Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

Tim,

In your code base, there are other tools beyond BaseTools to parse the [SkuIds] 
section and SKUID_IDENTIFIER in DSC, right?

The boot time usage (use the value in DEFAULT SKU instead if the value in 
specified SKU is not configured) for other resources in your code base is 
similar to PCD, right?
This RFC has no change to this boot time behavior that "use the value in 
DEFAULT SKU instead if the value in specified SKU is not configured".
So I am still not so clear about the benefit of the macro like #define 
SKUID_IDENTIFIER_DEFAULT 2,1,0,1,0,0.


The DSC syntax extension in this RFC is OPTIONAL, the backward compatibility is 
expected to be kept, no current tools and code should be impacted.
As I know, there will be a staging branch proposed for the development of PCD 
related RFCs (include Structure PCD, etc). Mike and Liming can help confirm it.
How about we have the development of this RFC to the staging branch first, then 
you can help evaluate the syntax and provide feedback further? :)


Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tim Lewis
Sent: Friday, May 5, 2017 12:36 AM
To: Zeng, Star ; Kinney, Michael D 
; edk2-devel@lists.01.org
Cc: Gao, Liming 
Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

Star --

I understand your use case. We use the same behavior for other resources 
besides PCD. 

All we are asking is that this data that is used by the build tools is also 
available in some form at runtime. 

Thanks,

Tim
 


-Original Message-
From: Zeng, Star [mailto:star.z...@intel.com]
Sent: Thursday, May 04, 2017 6:42 AM
To: Tim Lewis ; Kinney, Michael D 
; edk2-devel@lists.01.org
Cc: Gao, Liming ; Zeng, Star 
Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance

Tim,

To avoid misunderstanding, I think I need to clarify more about this RFC. :)

This RFC is NOT to propose building real relationship (like parent-child) 
between non-DEFAULT SKUs, it seems easy to bring confusion from the proposed 
syntax " SkuValue|SkuName[|ParentSkuName]", especially the word 'Parent', sorry 
for any confusion.
The syntax extension proposed by this RFC is just to simplify the PCDs 
configuring for multiple SKUs in DSC, I want to emphasize it is in DSC, it is 
to cover the case that some non-DEFAULT SKU has much PCD values equal with 
another non-DEFAULT SKU, but less PCD values equal with DEFAULT SKU.
This RFC has no any change to boot time behavior and does not break the rule 
that DEFAULT SKU PCD value will be returned if the specified SKU PCD value is 
not configured in DSC, the code logic is below.

PcdPeim Service.c:
  //
  // Find the current system's SKU ID entry in SKU ID table.
  //
  FoundSku = FALSE;
  for (Index = 0; Index < SkuIdTable[0]; Index++) {
if (PeiPcdDb->SystemSkuId == SkuIdTable[Index + 1]) {
  FoundSku = TRUE;
  break;
}
  }

  //
  // Find the default SKU ID entry in SKU ID table.
  //
  if(!FoundSku) {
for (Index = 0; Index < SkuIdTable[0]; Index++) {
  if (0 == SkuIdTable[Index + 1]) {
break;
  }
}
  }


The usage case you provided for other resources beyond PCD could be like below?

CurrentSkuId = PcdGetSkuId();

Resource = NULL;
if (!GetResourceForSkuId(CurrentSkuId, &Resource) {
  // try DEFAULT SKU
  GetResourceForSkuId(0, &Resource);
}
If (Resource == NULL) {
  // error, no resource found for any of the SKU IDs }



Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tim Lewis
Sent: Thursday, May 4, 2017 2:55 AM
To: Zeng, Star ; Kinney, Michael D 
; edk2-devel@lists.01.org
Cc: Gao, Liming 
Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

We use SKU IDs for working with 15 different key resources in our product. Some 
are related to code execution, but most are related to selection of resources. 
I mentioned logo components and HII strings already.

I am asking that the information about SKU relationships be output in some form 
so that it can be used at runtime, by whatever component. Today, there is an 
implied relationship between a SKU X and the SKU DEFAULT for PCDs. We use this 
rule in many places, because it expresses a useful relationship.

So, in the Project's .dsc file (forgive my syntax, which may not match

Re: [edk2] [PATCH 0/3] ShellPkg/HandleParsingLib: Show LoadedImageProtocol info

[Carsey, Jaben]

I agree with Ray's commentary.  Good positive changes to UEFI Shell! 

For the series.

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: Jeff Westfahl [mailto:jeff.westf...@ni.com]
> Sent: Friday, May 05, 2017 5:25 AM
> To: Ni, Ruiyu 
> Cc: Jeff Westfahl ; edk2-devel@lists.01.org; Carsey,
> Jaben 
> Subject: RE: [PATCH 0/3] ShellPkg/HandleParsingLib: Show
> LoadedImageProtocol info
> Importance: High
> 
> Hi Ray,
> 
> Thank you for pointing out the ECC tool. These changes look good to me.
> 
> Reviewed-by: Jeff Westfahl 
> 
> On Fri, 5 May 2017, Ni, Ruiyu wrote:
> 
> > Jeff,
> > Firstly great thanks for filling the gap between EDK shell and UEFI shell.
> > There are many behavior differences between the two,  and EDK Shell
> does carry much more information that
> > are very helpful for developer debugging.
> >
> > Before I check in your patch, could you please kindly review whether the
> additional change is ok to you.
> > One change is to fix the ECC failure: "python
> BaseTools\Source\Python\Ecc\Ecc.py -t
> ShellPkg\Library\UefiHandleParsingLib -s"
> >
> > ShellPkg\Library\UefiHandleParsingLib\UefiHandleParsingLib.c(272):
> [3002]Non-Boolean comparisons should use a compare operator (==, !=, >, <
> >=, <=) Predicate Expression: FileName
> > ShellPkg\Library\UefiHandleParsingLib\UefiHandleParsingLib.c(272):
> [3003]A comparison of any pointer to zero must be done via the NULL type
> Predicate Expression: FileName
> >
> > patch content===
> > .../UefiHandleParsingLib/UefiHandleParsingLib.c| 39 
> --
> > 1 file changed, 14 insertions(+), 25 deletions(-)
> >
> > diff --git a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> > index 74934f8617..d3ee068eba 100644
> > --- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> > +++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> > @@ -16,14 +16,14 @@
> >
> > #include "UefiHandleParsingLib.h"
> > #include "IndustryStandard/Acpi10.h"
> > -#include "Pi/PiFirmwareFile.h"
> > -#include "Pi/PiFirmwareVolume.h"
> > -#include "Protocol/FirmwareVolume2.h"
> > +#include 
> > +#include 
> >
> > EFI_HANDLEmHandleParsingHiiHandle = NULL;
> > HANDLE_INDEX_LIST mHandleList = {{{NULL,NULL},0,0},0};
> > GUID_INFO_BLOCK   *mGuidList;
> > UINTN mGuidListCount;
> > +
> > /**
> >   Function to find the file name associated with a LoadedImageProtocol.
> >
> > @@ -44,37 +44,26 @@ FindLoadedImageFileName (
> >   UINTN  BufferSize;
> >   UINT32 AuthenticationStatus;
> >
> > -  //
> > -  // Only subtype MEDIA_PIWG_FW_FILE_DP of type
> MEDIA_DEVICE_PATH is supported.
> > -  //
> > -  if (   (LoadedImage == NULL)
> > -  || (LoadedImage->FilePath == NULL)
> > -  || (LoadedImage->FilePath->Type != MEDIA_DEVICE_PATH)
> > -  || (LoadedImage->FilePath->SubType != MEDIA_PIWG_FW_FILE_DP)
> > -   ) {
> > -return (NULL);
> > +  if ((LoadedImage == NULL) || (LoadedImage->FilePath == NULL)) {
> > +return NULL;
> >   }
> >
> >   NameGuid =
> EfiGetNameGuidFromFwVolDevicePathNode((MEDIA_FW_VOL_FILEPATH_
> DEVICE_PATH *)LoadedImage->FilePath);
> >
> >   if (NameGuid == NULL) {
> > -return (NULL);
> > +return NULL;
> >   }
> >
> >   //
> > -  // Get the FirmwareVolume2Protocol of the device handle that this
> image was
> > -  // loaded from.
> > +  // Get the FirmwareVolume2Protocol of the device handle that this
> image was loaded from.
> >   //
> > -  Status = gBS->HandleProtocol(
> > -LoadedImage->DeviceHandle,
> > -&gEfiFirmwareVolume2ProtocolGuid,
> > -(VOID**)&Fv);
> > +  Status = gBS->HandleProtocol (LoadedImage->DeviceHandle,
> &gEfiFirmwareVolume2ProtocolGuid, (VOID**) &Fv);
> >
> >   //
> >   // FirmwareVolume2Protocol is PI, and is not required to be available.
> >   //
> > -  if (EFI_ERROR(Status)) {
> > -return (NULL);
> > +  if (EFI_ERROR (Status)) {
> > +return NULL;
> >   }
> >
> >   //
> > @@ -83,15 +72,15 @@ FindLoadedImageFileName (
> >   Buffer = NULL;
> >   Status = Fv->ReadSection(Fv, NameGuid, EFI_SECTION_USER_INTERFACE,
> 0, &Buffer, &BufferSize, &AuthenticationStatus);
> >
> > -  if (EFI_ERROR(Status)) {
> > -return (NULL);
> > +  if (EFI_ERROR (Status)) {
> > +return NULL;
> >   }
> >
> >   //
> >   // ReadSection returns just the section data, without any section header.
> For
> >   // a user interface section, the only data is the file name.
> >   //
> > -  return (Buffer);
> > +  return Buffer;
> > }
> >
> > /**
> > @@ -269,7 +258,7 @@ LoadedImageProtocolDumpInformation(
> >   FileName = FindLoadedImageFileName(LoadedImage);
> >
> >   RetVal = NULL;
> > -  if (FileName) {
> > +  if (FileName != NULL) {
> > Temp = HiiGetString(mHandleParsingHiiHandle,
> STRING_TOKEN(STR_LI_DUMP_NAME), NULL);
> >
> > if (Temp != NULL) {
> >
> > Thanks/Ray
> >
> >> -Original Message-
> >> From: Jeff Westfahl [

Re: [edk2] [PATCH v2 3/5] OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK

[Jordan Justen]

On 2017-05-05 05:07:25, Laszlo Ersek wrote:
> 
> Which one do you prefer:
> (1) I can take your patch, stick in the UINTN cast, and expand the
> commit message a bit (similarly to what's on my patch),
> (2) we can go with my patch as well.

I prefer your patch.

Re: "0001-OvmfPkg-PlatformPei-handle-non-power-of-two-spare-si.patch"

> +Alignment = GetPowerOfTwo32 (Alignment) << 1;

Do you think this might end up needing a UINT32 cast with 64-bit PEI?

Reviewed-by: Jordan Justen 

> Regarding the non-flash path, I have the attached work-in-progress patches:
> 
> - "OvmfPkg: sync PcdVariableStoreSize with PcdFlashNvStorageVariableSize",
> - and "wip".

I looked over the non-wip patch, and it seems good, but maybe we
should just revert the default size for now.

For a revert of bba8dfbec3bbc4fba7fa6398ba3cf76593e0725e:

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

Re: [edk2] [RFC] migration of OpenPlatformPkg to tianocore

[Yao, Jiewen]

Some comments for the build failure.

I think we might have different understanding on PACKAGES_PATH.

We are using below structure:
=
Platform\
Intel\
PlatformAPkg
PlatformBPkg
Silicon\
Intel\
SiliconAPkg
SiliconBPkg

We set PACKAGES_PATH to "Platform\Intel:Silicon\Intel".
As such Build.DSC can include PlatformAPkg/DriverA/DriverA.inf.
=


My suggestion for your case is below: We can use
=
Platform\
Arm\
JunoPkg
VExpressPkg

We set PACKAGES_PATH to "Platform\Arm".
ArmJunoPkg.dsc can just use "VExpressPkg\ArmVExpress.dsc.inc" and 
"JunoPkg\Library\JunoPciHostBridgeLib\ JunoPciHostBridgeLib.dsc"
=

The benefit of adding "Pkg" is that people can have a clear picture on where 
the path starts from. :)

Thank you
Yao Jiewen



From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yao, 
Jiewen
Sent: Friday, May 5, 2017 9:46 PM
To: Leif Lindholm ; edk2-devel@lists.01.org
Cc: Richardson, Brian ; Ard Biesheuvel 
; Chenhui Sun ; Andrew Fish 
; Alan Ott ; Ryan Harkin 
; Duran, Leo ; 
haojian.zhu...@linaro.org; Linaro UEFI ; Kinney, 
Michael D ; Heyi Guo 
Subject: Re: [edk2] [RFC] migration of OpenPlatformPkg to tianocore

HI Leif
It is great that you are adding more platform to edk2-platforms.

We (Intel) also have plan to add more boards there. In general, we are very 
close on having silicon and platform folder.

I have a quick look. One minor suggestions here:
Take Arm folder as example. (I assume Juno is one package, and VExpress is the 
other package.)
Can we name Juno to be JunoPkg, and VExpress to be VExpressPkg ?
We do not add "Pkg" to a folder. And we usually add "Pkg" suffix to a package.

In general, I think it is a very good start.
I may review the content in more detail and provide more feedback.


Thank you
Yao Jiewen


From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leif 
Lindholm
Sent: Thursday, May 4, 2017 6:56 AM
To: edk2-devel@lists.01.org
Cc: Ryan Harkin mailto:ryan.har...@linaro.org>>; Ard 
Biesheuvel mailto:ard.biesheu...@linaro.org>>; 
Chenhui Sun mailto:chenhui@linaro.org>>; Andrew 
Fish mailto:af...@apple.com>>; Alan Ott 
mailto:a...@softiron.co.uk>>; Richardson, Brian 
mailto:brian.richard...@intel.com>>; Duran, Leo 
mailto:leo.du...@amd.com>>; 
haojian.zhu...@linaro.org; Linaro UEFI 
mailto:linaro-u...@lists.linaro.org>>; Kinney, 
Michael D mailto:michael.d.kin...@intel.com>>; Heyi 
Guo mailto:heyi@linaro.org>>
Subject: [edk2] [RFC] migration of OpenPlatformPkg to tianocore

Hi all,

As some of you may be aware, I have been working around the lack of
a clear upstreaming strategy for platform support by keeping such code
in a dedicated repository I set up at Linaro for that purpose:
https://git.linaro.org/uefi/OpenPlatformPkg.git

During discussions at the last Seattle plugfest we finally agreed on
the (theoretical) details of how to use the edk2-platforms repository.
After that I promised to migrate OpenPlatformPkg across to the
edk2-platforms and edk2-non-osi structure, with the explicit end goal
from my side that this should become the master branch for each.

And now, before the release of HURD 1.0, I have.

Current limitations (that I can remember):
- A few references to OpenPlatformPkg remain, in ways that do not
  appear to break any of the platform builds. Most likely this affects
  dead code, but in case it's been accidentally orphaned, I thought it
  best to
- I have simply nuked all references to Ebl (used in _addition_ to the
  UEFI shell, which was never the intent) and the efi-toolkit
  ramdisk driver.
- The Marvell Yukon driver that I sent out for review last week has
  not migrated anywhere, and so has been temporarily disabled
  Mike suggested I should
- USB support on the LeMaker Cello board depends on the patch
  "OptionRomPkg: add firmware loader driver for Renesas PD72020x"
  sent out by Ard on 18th of April.
- I have dropped some of the binary-only modules from OpenPlatformPkg,
  and contacted the platform owners with requests for modifications.
- The git history is quite messy and will be cleaned up, but I wanted
  to keep the transition quite visible in the RFC.
- I haven't filled anything into the Maintainers.txt files - I am in
  favour of moving to a fully machine-readable format with wildcards
  as Laszlo has proposed in the past, and think this would be an
  excellent point to have that discussion (which can be had separately
  for edk2-platforms and edk2-non-osi from edk2).
- Few of the platforms complete the FV generation stage, and I've
  inserted a couple of silly hacks to get them to get as far as they
  do. I think that either I am missing some points of how
  PACKAGES_PATH is intended to work, or I'm simply hitting corner
  cases n

Re: [edk2] [RFC] migration of OpenPlatformPkg to tianocore

[Yao, Jiewen]

HI Leif
It is great that you are adding more platform to edk2-platforms.

We (Intel) also have plan to add more boards there. In general, we are very 
close on having silicon and platform folder.

I have a quick look. One minor suggestions here:
Take Arm folder as example. (I assume Juno is one package, and VExpress is the 
other package.)
Can we name Juno to be JunoPkg, and VExpress to be VExpressPkg ?
We do not add "Pkg" to a folder. And we usually add "Pkg" suffix to a package.

In general, I think it is a very good start.
I may review the content in more detail and provide more feedback.


Thank you
Yao Jiewen


From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leif 
Lindholm
Sent: Thursday, May 4, 2017 6:56 AM
To: edk2-devel@lists.01.org
Cc: Ryan Harkin ; Ard Biesheuvel 
; Chenhui Sun ; Andrew Fish 
; Alan Ott ; Richardson, Brian 
; Duran, Leo ; 
haojian.zhu...@linaro.org; Linaro UEFI ; Kinney, 
Michael D ; Heyi Guo 
Subject: [edk2] [RFC] migration of OpenPlatformPkg to tianocore

Hi all,

As some of you may be aware, I have been working around the lack of
a clear upstreaming strategy for platform support by keeping such code
in a dedicated repository I set up at Linaro for that purpose:
https://git.linaro.org/uefi/OpenPlatformPkg.git

During discussions at the last Seattle plugfest we finally agreed on
the (theoretical) details of how to use the edk2-platforms repository.
After that I promised to migrate OpenPlatformPkg across to the
edk2-platforms and edk2-non-osi structure, with the explicit end goal
from my side that this should become the master branch for each.

And now, before the release of HURD 1.0, I have.

Current limitations (that I can remember):
- A few references to OpenPlatformPkg remain, in ways that do not
  appear to break any of the platform builds. Most likely this affects
  dead code, but in case it's been accidentally orphaned, I thought it
  best to
- I have simply nuked all references to Ebl (used in _addition_ to the
  UEFI shell, which was never the intent) and the efi-toolkit
  ramdisk driver.
- The Marvell Yukon driver that I sent out for review last week has
  not migrated anywhere, and so has been temporarily disabled
  Mike suggested I should
- USB support on the LeMaker Cello board depends on the patch
  "OptionRomPkg: add firmware loader driver for Renesas PD72020x"
  sent out by Ard on 18th of April.
- I have dropped some of the binary-only modules from OpenPlatformPkg,
  and contacted the platform owners with requests for modifications.
- The git history is quite messy and will be cleaned up, but I wanted
  to keep the transition quite visible in the RFC.
- I haven't filled anything into the Maintainers.txt files - I am in
  favour of moving to a fully machine-readable format with wildcards
  as Laszlo has proposed in the past, and think this would be an
  excellent point to have that discussion (which can be had separately
  for edk2-platforms and edk2-non-osi from edk2).
- Few of the platforms complete the FV generation stage, and I've
  inserted a couple of silly hacks to get them to get as far as they
  do. I think that either I am missing some points of how
  PACKAGES_PATH is intended to work, or I'm simply hitting corner
  cases no one has come across before. I could really use some help
  debugging these issues. (examples below).

The below depends on the 3-part series I sent out today for importing
DwEmmcDxe and EfiTimeBaseLib from OpenPlatformPkg. But apart from
that, I have uploaded branches called devel-OpenPlatformPkg to:

https://github.com/tianocore/edk2-platforms/tree/devel-OpenPlatformPkg
https://github.com/tianocore/edk2-non-osi/tree/devel-OpenPlatformPkg

These branches _will_ be rebased occasionally until they get to a
point where they can move out of devel- stage (and hopefully onto
master).


Build issue description
===
So, one of the hopefully easier ones is what I'm seeing when trying to
build the Juno platform:

$ PACKAGES_PATH="/work/maint/edk2-platforms:/work/maint/edk2-non-osi" 
GCC5_AARCH64_PREFIX=aarch64-linux-gnu- build -a AARCH64 -t GCC5 -p 
Platform/ARM/Juno/ArmJuno.dsc -b RELEASE -n 9

results in:

<<<
GenFds.py...
 : error F003: Output file for RAW section could not be found for
 Platform/ARM/Juno/AcpiTables/AcpiTables.inf

###


build.py...
 : error 7000: Failed to execute command
 GenFds -f /work/maint/edk2-platforms/Platform/ARM/Juno/ArmJuno.fdf 
--conf=/work/maint/edk2/Conf -o /work/maint/edk2/Build/ArmJuno/RELEASE_GCC5 -t 
GCC5 -b RELEASE -p /work/maint/edk2-platforms/Platform/ARM/Juno/ArmJuno.dsc -a 
AARCH64 -D "EFI_SOURCE=/work/maint/edk2/EdkCompatibilityPkg" -D 
"EDK_SOURCE=/work/maint/edk2/EdkCompatibilityPkg" -D "TOOL_CHAIN_TAG=GCC5" -D 
"TOOLCHAIN=GCC5" -D "TARGET=RELEASE" -D "FAMILY=GCC" -D 
"WORKSPACE=/work/maint/edk2" -D "EDK_TOOLS_PATH=/work/maint/edk2/BaseTools" -D 
"ARCH=AARCH64" -D "ECP_SOURCE=/work/maint/edk2/EdkCompatibilityPkg"
 [/work/maint/edk2]

- Failed -
>>>

Re: [edk2] Accessing AVX/AVX2 instruction in UEFI.

[Amit kumar]

Mike, Andrew


Thanks for your suggestions, it looks like MMIO is the bottleneck in my 
application.

I have one more query. Does each core have independent YMM registers or is it 
shared among the cores ?


Thanks And Regards

Amit Kumar


From: Kinney, Michael D 
Sent: Thursday, May 4, 2017 10:56:44 PM
To: Andrew Fish; Amit kumar; Kinney, Michael D
Cc: edk2-devel@lists.01.org
Subject: RE: [edk2] Accessing AVX/AVX2 instruction in UEFI.

Amit,

I agree with Andrew that establishing a good measurement method is very
important and that raising TPL to HIGH_LEVEL(disabling interrupts) during
measurement may improve the consistency of the measurement results.

You also likely want to test both large buffer operations as well as a
loop on small buffer operations to see if there are differences based
on the size of the requested operation.

In order to verify that your measurement method is working, you may want
to test some of the existing BaseMemoryLib implementations before testing
your new one.

* BaseMemoryLibC code implementation
* BaseMemoryLibMmx Uses MMX registers/instructions
* BaseMemoryLibSse2Uses SSE2 registers/instructions
* BaseMemoryLibRepStr  Uses REP STR instructions

* BaseMemoryLibOptDxe  Blend of above libs with good perf in DXE/UEFI phase
* BaseMemoryLibOptPei  Blend of above libs with good perf in PEI phase


I recommend you try measuring the first 4 to see if your measurements show
differences.

Base on my own evaluation in the past, I have found that DXE/UEFI code works
well with BaseMemoryLibRepStr.  It tends to go as fast as the largest
register width access the CPU supports.

One additional element that may be impacting your results is the type of
memory that is being testing and that memory ranges cache settings.  If
you are accessing MMIO, FLASH, or some other type of device memory, you
may be seeing bandwidth limitations from that device.

Best regards,

Mike



> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew 
> Fish
> Sent: Thursday, May 4, 2017 8:21 AM
> To: Amit kumar 
> Cc: Kinney, Michael D ; edk2-devel@lists.01.org
> Subject: Re: [edk2] Accessing AVX/AVX2 instruction in UEFI.
>
> Amit,
>
> In regards to AVX/AVX2 performance how are you doing the measuring?
>
> In EFI it is hard to measure wall clock time for things that take a long time.
> Basically there is no scheduler in EFI and no threads, but there are events. 
> The
> events can preempt your App while it is running and the time spent in events 
> would
> look to you like time spent in your App.
>
> Generally the time spent in events should be constant (hot plugging USB or 
> other
> changes like that may have a noticeable impact). If the goal of the 
> performance
> measurement is to make the system boot faster you care more about the delta, 
> than the
> absolute time (so the event overhead does not matter).
>
> If you are just doing a computation that does not do any IO then you may be 
> able to
> raise the TPL to prevent events from being part of your measurement.
>
> Thanks,
>
> Andrew Fish
>
> PS I assume your are measuring the RELEASE code since you are turning off 
> optimization
> on the DEBUG code.
>
> > On May 4, 2017, at 5:22 AM, Amit kumar  wrote:
> >
> > Here are the compiler flags
> > [BuildOptions]
> >  MSFT:DEBUG_*_*_CC_FLAGS = /Od /FAsc /GL-
> >  MSFT:RELEASE_*_*_CC_FLAGS = /FAsc /D MDEPKG_NDEBUG
> >  MSFT:RELEASE_*_*_DLINK_FLAGS = /BASE:0x1  /ALIGN:4096 /FILEALIGN:4096
> >
> >
> > 
> > From: Amit kumar 
> > Sent: Thursday, May 4, 2017 5:48:11 PM
> > To: Andrew Fish
> > Cc: Mike Kinney; edk2-devel@lists.01.org
> > Subject: Re: [edk2] Accessing AVX/AVX2 instruction in UEFI.
> >
> >
> > Yes am aligning the data at 32 byte boundary while allocating memory in both
> environments.
> >
> > in windows using  _alligned_malloc(size,32);
> >
> > in UEFI
> >
> > Offset = (UINTN)src & 0xFF;
> >
> > src = (CHAR8 *)((UINTN) src - Offset + 0x20);
> >
> >
> > Thanks
> >
> > Amit
> >
> > 
> > From: af...@apple.com  on behalf of Andrew Fish 
> > 
> > Sent: Thursday, May 4, 2017 5:02:55 PM
> > To: Amit kumar
> > Cc: Mike Kinney; edk2-devel@lists.01.org
> > Subject: Re: [edk2] Accessing AVX/AVX2 instruction in UEFI.
> >
> >
> >> On May 4, 2017, at 4:13 AM, Amit kumar  wrote:
> >>
> >> Hi,
> >>
> >>
> >> Even after using AVX2 instruction my code shown no performance improvement 
> >> in UEFI
> although there is substantial improvement when i run the similar code in 
> windows .
> >>
> >> Am i missing something ?
> >>
> >
> > Is the data aligned the same in both environments?
> >
> > Thanks,
> >
> > Andrew Fish
> >
> >> Using MSVC compiler and the codes written in ASM.
> >>
> >> Thanks And Regards
> >>
> >> Amit
> >>
> >> 
> >> From: edk2-devel  on behalf of Amit kumar
> 
> >> Sent: Wednesday, May 3, 2017 11:18:39 AM
> 

Re: [edk2] [PATCH 0/3] ShellPkg/HandleParsingLib: Show LoadedImageProtocol info

[Jeff Westfahl]

Hi Ray,

Thank you for pointing out the ECC tool. These changes look good to me.

Reviewed-by: Jeff Westfahl 

On Fri, 5 May 2017, Ni, Ruiyu wrote:


Jeff,
Firstly great thanks for filling the gap between EDK shell and UEFI shell.
There are many behavior differences between the two,  and EDK Shell does carry 
much more information that
are very helpful for developer debugging.

Before I check in your patch, could you please kindly review whether the 
additional change is ok to you.
One change is to fix the ECC failure: "python BaseTools\Source\Python\Ecc\Ecc.py -t 
ShellPkg\Library\UefiHandleParsingLib -s"

ShellPkg\Library\UefiHandleParsingLib\UefiHandleParsingLib.c(272): [3002]Non-Boolean 
comparisons should use a compare operator (==, !=, >, < >=, <=) Predicate 
Expression: FileName
ShellPkg\Library\UefiHandleParsingLib\UefiHandleParsingLib.c(272): [3003]A 
comparison of any pointer to zero must be done via the NULL type Predicate 
Expression: FileName

patch content===
.../UefiHandleParsingLib/UefiHandleParsingLib.c| 39 --
1 file changed, 14 insertions(+), 25 deletions(-)

diff --git a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c 
b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
index 74934f8617..d3ee068eba 100644
--- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
+++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
@@ -16,14 +16,14 @@

#include "UefiHandleParsingLib.h"
#include "IndustryStandard/Acpi10.h"
-#include "Pi/PiFirmwareFile.h"
-#include "Pi/PiFirmwareVolume.h"
-#include "Protocol/FirmwareVolume2.h"
+#include 
+#include 

EFI_HANDLEmHandleParsingHiiHandle = NULL;
HANDLE_INDEX_LIST mHandleList = {{{NULL,NULL},0,0},0};
GUID_INFO_BLOCK   *mGuidList;
UINTN mGuidListCount;
+
/**
  Function to find the file name associated with a LoadedImageProtocol.

@@ -44,37 +44,26 @@ FindLoadedImageFileName (
  UINTN  BufferSize;
  UINT32 AuthenticationStatus;

-  //
-  // Only subtype MEDIA_PIWG_FW_FILE_DP of type MEDIA_DEVICE_PATH is supported.
-  //
-  if (   (LoadedImage == NULL)
-  || (LoadedImage->FilePath == NULL)
-  || (LoadedImage->FilePath->Type != MEDIA_DEVICE_PATH)
-  || (LoadedImage->FilePath->SubType != MEDIA_PIWG_FW_FILE_DP)
-   ) {
-return (NULL);
+  if ((LoadedImage == NULL) || (LoadedImage->FilePath == NULL)) {
+return NULL;
  }

  NameGuid = 
EfiGetNameGuidFromFwVolDevicePathNode((MEDIA_FW_VOL_FILEPATH_DEVICE_PATH 
*)LoadedImage->FilePath);

  if (NameGuid == NULL) {
-return (NULL);
+return NULL;
  }

  //
-  // Get the FirmwareVolume2Protocol of the device handle that this image was
-  // loaded from.
+  // Get the FirmwareVolume2Protocol of the device handle that this image was 
loaded from.
  //
-  Status = gBS->HandleProtocol(
-LoadedImage->DeviceHandle,
-&gEfiFirmwareVolume2ProtocolGuid,
-(VOID**)&Fv);
+  Status = gBS->HandleProtocol (LoadedImage->DeviceHandle, 
&gEfiFirmwareVolume2ProtocolGuid, (VOID**) &Fv);

  //
  // FirmwareVolume2Protocol is PI, and is not required to be available.
  //
-  if (EFI_ERROR(Status)) {
-return (NULL);
+  if (EFI_ERROR (Status)) {
+return NULL;
  }

  //
@@ -83,15 +72,15 @@ FindLoadedImageFileName (
  Buffer = NULL;
  Status = Fv->ReadSection(Fv, NameGuid, EFI_SECTION_USER_INTERFACE, 0, &Buffer, 
&BufferSize, &AuthenticationStatus);

-  if (EFI_ERROR(Status)) {
-return (NULL);
+  if (EFI_ERROR (Status)) {
+return NULL;
  }

  //
  // ReadSection returns just the section data, without any section header. For
  // a user interface section, the only data is the file name.
  //
-  return (Buffer);
+  return Buffer;
}

/**
@@ -269,7 +258,7 @@ LoadedImageProtocolDumpInformation(
  FileName = FindLoadedImageFileName(LoadedImage);

  RetVal = NULL;
-  if (FileName) {
+  if (FileName != NULL) {
Temp = HiiGetString(mHandleParsingHiiHandle, 
STRING_TOKEN(STR_LI_DUMP_NAME), NULL);

if (Temp != NULL) {

Thanks/Ray


-Original Message-
From: Jeff Westfahl [mailto:jeff.westf...@ni.com]
Sent: Friday, May 5, 2017 5:53 AM
To: edk2-devel@lists.01.org
Cc: Jeff Westfahl ; Ni, Ruiyu ;
Carsey, Jaben 
Subject: [PATCH 0/3] ShellPkg/HandleParsingLib: Show LoadedImageProtocol
info

In the old shell, 'dh -v' showed some useful information about the file path
associated with a LoadedImageProtocol that is no longer shown in the modern
shell.

For example, with the old shell:

Handle D3 (3A552218)
Image (3A54C918)   File:MicrocodeUpdate
ParentHandle..: 3A666398
SystemTable...: 3D2A8F18
DeviceHandle..: 3B1C8098
FilePath..: FvFile(F3331DE6-4A55-44E4-B767-7453F7A1A021)
ImageBase.: 3D65 - 3D655540
ImageSize.: 5540
CodeType..: RT_code
DataType..: RT_data

compared to the new shell:

D3: 3A552218
LoadedImage
Revision..: 0x1000
ParentHandle.

Re: [edk2] [PATCH v2 3/5] OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK

[Laszlo Ersek]

On 05/05/17 10:57, Jordan Justen wrote:
> On 2017-05-04 21:07:24, Laszlo Ersek wrote:
>> On 05/03/17 23:39, Laszlo Ersek wrote:
>>> - Raise VARS_LIVE_SIZE by 8KB to 256KB, VARS_SPARE_SIZE by 8KB to 264KB,
>> Unfortunately, we have a terrible regression here. :(
>>
> 
> 
>> Adapting EmuVariableFvbRuntimeDxe to a non-power-of-two NV spare area
>> size is hopeless. (Definitely hopeless for the time frame & resources
>> I'm looking at.)
>>
>> Worse, even -pflash is broken in the 4MB build, actually. The
>> non-power-of-two NV spare area size, when used as Alignment for
>> AllocateAlignedRuntimePages() in ReserveEmuVariableNvStore(), triggers
>> an assertion. And this path is taken for the -pflash boot as well.
> For a short term fix, would something like this work?

Absolutely. I didn't dare ask for it.

> 1. Force emu fvb buffer alignment to next power-of-two
> 
>Something like the attachment, but I'm guessing you already wrote
>something similar.

Yes, I have almost exactly that; please see the attached
"OvmfPkg/PlatformPei: handle non-power-of-two spare size for emu variables".

The difference is that your patch uses HighBitSet32() directly, which
mine uses through GetPowerOfTwo32(). Also yours starts with the full
size, and then subtracts one for the shift in the alignment; mine starts
with half the size (i.e., the spare area size) and uses that in the
alignment.

One other comment on the patch:

> 0001-PlatformPei-Force-EmuVariableNvStore-alignment-size-.patch
> 
> 
> From 58ba393adf60caf806b26dec9aa56d936743f595 Mon Sep 17 00:00:00 2001
> From: Jordan Justen 
> Date: Fri, 5 May 2017 01:43:31 -0700
> Subject: [PATCH] PlatformPei: Force EmuVariableNvStore alignment size to power
>  of two
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jordan Justen 
> ---
>  OvmfPkg/PlatformPei/Platform.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/PlatformPei/Platform.c
> index 77a8a16c15..97dce8de92 100644
> --- a/OvmfPkg/PlatformPei/Platform.c
> +++ b/OvmfPkg/PlatformPei/Platform.c
> @@ -504,6 +504,14 @@ ReserveEmuVariableNvStore (
>  {
>EFI_PHYSICAL_ADDRESS VariableStore;
>RETURN_STATUSPcdStatus;
> +  UINT32   EmuFvbSize;
> +  INTN SizeHighBit;
> +
> +  EmuFvbSize = 2 * PcdGet32 (PcdFlashNvStorageFtwSpareSize);
> +  SizeHighBit = HighBitSet32 (EmuFvbSize);
> +  if ((EmuFvbSize & (EmuFvbSize - 1)) != 0) {
> +SizeHighBit++;
> +  }
>  
>//
>// Allocate storage for NV variables early on so it will be
> @@ -514,13 +522,13 @@ ReserveEmuVariableNvStore (
>VariableStore =
>  (EFI_PHYSICAL_ADDRESS)(UINTN)
>AllocateAlignedRuntimePages (
> -EFI_SIZE_TO_PAGES (2 * PcdGet32 (PcdFlashNvStorageFtwSpareSize)),
> -PcdGet32 (PcdFlashNvStorageFtwSpareSize)
> +EFI_SIZE_TO_PAGES (EmuFvbSize),

I think we should cast EmuFvbSize to UINTN first; EFI_SIZE_TO_PAGES()
likes the "Size" parameter to be UINTN.

> +1 << (SizeHighBit - 1)
>  );
>DEBUG ((EFI_D_INFO,
>"Reserved variable store memory: 0x%lX; size: %dkb\n",
>VariableStore,
> -  (2 * PcdGet32 (PcdFlashNvStorageFtwSpareSize)) / 1024
> +  EmuFvbSize / 1024
>  ));
>PcdStatus = PcdSet64S (PcdEmuVariableNvStoreReserved, VariableStore);
>ASSERT_RETURN_ERROR (PcdStatus);
> -- 2.11.0
> 

Which one do you prefer:
(1) I can take your patch, stick in the UINTN cast, and expand the
commit message a bit (similarly to what's on my patch),
(2) we can go with my patch as well.

I'm tempted to do (1) and commit it with my R-b immediately, but I
realize that "rushing it" is the root of all evil. So I won't rush it.

On 05/05/17 10:57, Jordan Justen wrote:
> 2. Revert 4MB by default patch
>
> This should allow you to start using the 4MB layout for your builds,
> and we can fix the non-flash path before re-enabling 4MB as the
> default.

This works for me, yes. Thank you.

Regarding the non-flash path, I have the attached work-in-progress patches:

- "OvmfPkg: sync PcdVariableStoreSize with PcdFlashNvStorageVariableSize",
- and "wip".

I think that the "wip" patch does all the "simple" fixes in
EmuVariableFvbRuntimeDxe, and what remains is to add code so that the
FVB protocol members actually do their job. Also, the "wip" patch
eliminates any special alignment in the AllocateRuntimePages() call of
PlatformPei, since after the "block size = page size" change, no such
alignment will be necessary. What do you think of this?

So here's the plan:
- based on what you prefer for (1) vs. (2), I'll post that patch as
first patch,
- I'll post the revert of the 4MB default as second patch,
- I think I'll immediately post the patch that syncs
PcdVariableStoreSize as well, as third patch, because it is a small
improvement for the pflash case too.

Does this work for you?

Thank you,
Laszlo
From 7bd8738556abb86bdbfdd11dd30ad7

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3] Use GP_CAMERASB10 as Board_ID3.

[zwei4]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: zwei4 
CC: Mang Guo 
CC: Shifei Lu 
---
 .../Board/LeafHill/BoardInitPreMem/PlatformId.c| 24 ++
 .../MinnowBoard3/BoardInitPreMem/PlatformId.c  | 24 ++
 2 files changed, 30 insertions(+), 18 deletions(-)

diff --git 
a/Platform/BroxtonPlatformPkg/Board/LeafHill/BoardInitPreMem/PlatformId.c 
b/Platform/BroxtonPlatformPkg/Board/LeafHill/BoardInitPreMem/PlatformId.c
index d550fd400..40554b95e 100644
--- a/Platform/BroxtonPlatformPkg/Board/LeafHill/BoardInitPreMem/PlatformId.c
+++ b/Platform/BroxtonPlatformPkg/Board/LeafHill/BoardInitPreMem/PlatformId.c
@@ -64,24 +64,30 @@ GetEmbeddedBoardIdFabId(
   padConfg0.r.PMode = 0;
   padConfg0.r.GPIORxTxDis = 0x1;
   GpioPadWrite (CommAndOffset + BXT_GPIO_PAD_CONF0_OFFSET, padConfg0.padCnf0);
+
   //
-  // Board_ID3: PMIC_PWRGOOD
+  // Board_ID3: GP_CAMERASB10
   //
-  CommAndOffset = GetCommOffset (NORTHWEST, 0x00C0);
+  
+  CommAndOffset = GetCommOffset (NORTH, 0x01E0);
   padConfg0.padCnf0 = GpioPadRead (CommAndOffset + BXT_GPIO_PAD_CONF0_OFFSET);
-  padConfg0.r.PMode = 0;
-  padConfg0.r.GPIORxTxDis = 0x1;
+  padConfg1.padCnf1 = GpioPadRead (CommAndOffset + BXT_GPIO_PAD_CONF1_OFFSET);
+
+  padConfg0.r.PMode = M0; // Set to GPIO mode
+  padConfg0.r.GPIORxTxDis = GPI;  // Set to GPI
   GpioPadWrite (CommAndOffset + BXT_GPIO_PAD_CONF0_OFFSET, padConfg0.padCnf0);
+
+  padConfg1.r.IOSTerm  = EnPu;// Enable pull-up
+  padConfg1.r.Term = P_20K_H; // Set to 20K pull-up
+  GpioPadWrite (CommAndOffset + BXT_GPIO_PAD_CONF1_OFFSET, padConfg1.padCnf1);
+
   //
-  // Set to Pull Up 20K
+  // Read out Board_ID 
   //
-  padConfg1.r.Term = 0xC;
-  GpioPadWrite (CommAndOffset + BXT_GPIO_PAD_CONF1_OFFSET, padConfg1.padCnf1);
-  
   *BoardId = (UINT8) (((GpioPadRead (GetCommOffset (NORTHWEST, 0x00F0) + 
BXT_GPIO_PAD_CONF0_OFFSET) & BIT1) >> 1) | \
  (((GpioPadRead (GetCommOffset (NORTHWEST, 0x00D0) + 
BXT_GPIO_PAD_CONF0_OFFSET) & BIT1) >> 1) << 1) | \
  (((GpioPadRead (GetCommOffset (NORTHWEST, 0x00C8) + 
BXT_GPIO_PAD_CONF0_OFFSET) & BIT1) >> 1) << 2) | \
- (((GpioPadRead (GetCommOffset (NORTHWEST, 0x00C0) + 
BXT_GPIO_PAD_CONF0_OFFSET) & BIT1) >> 1) << 3));
+ (((GpioPadRead (GetCommOffset (NORTH, 0x01E0) + 
BXT_GPIO_PAD_CONF0_OFFSET) & BIT1) >> 1) << 3));
 
   DEBUG ((DEBUG_INFO,  "BoardId from PMIC strap: %02X\n", *BoardId));
 
diff --git 
a/Platform/BroxtonPlatformPkg/Board/MinnowBoard3/BoardInitPreMem/PlatformId.c 
b/Platform/BroxtonPlatformPkg/Board/MinnowBoard3/BoardInitPreMem/PlatformId.c
index d550fd400..bacdab1f2 100644
--- 
a/Platform/BroxtonPlatformPkg/Board/MinnowBoard3/BoardInitPreMem/PlatformId.c
+++ 
b/Platform/BroxtonPlatformPkg/Board/MinnowBoard3/BoardInitPreMem/PlatformId.c
@@ -64,24 +64,30 @@ GetEmbeddedBoardIdFabId(
   padConfg0.r.PMode = 0;
   padConfg0.r.GPIORxTxDis = 0x1;
   GpioPadWrite (CommAndOffset + BXT_GPIO_PAD_CONF0_OFFSET, padConfg0.padCnf0);
+
   //
-  // Board_ID3: PMIC_PWRGOOD
+  // Board_ID3: GP_CAMERASB10
   //
-  CommAndOffset = GetCommOffset (NORTHWEST, 0x00C0);
+
+  CommAndOffset = GetCommOffset (NORTH, 0x01E0);
   padConfg0.padCnf0 = GpioPadRead (CommAndOffset + BXT_GPIO_PAD_CONF0_OFFSET);
-  padConfg0.r.PMode = 0;
-  padConfg0.r.GPIORxTxDis = 0x1;
+  padConfg1.padCnf1 = GpioPadRead (CommAndOffset + BXT_GPIO_PAD_CONF1_OFFSET);
+
+  padConfg0.r.PMode = M0; // Set to GPIO mode
+  padConfg0.r.GPIORxTxDis = GPI;  // Set to GPI
   GpioPadWrite (CommAndOffset + BXT_GPIO_PAD_CONF0_OFFSET, padConfg0.padCnf0);
+
+  padConfg1.r.IOSTerm  = EnPu;// Enable pull-up
+  padConfg1.r.Term = P_20K_H; // Set to 20K pull-up
+  GpioPadWrite (CommAndOffset + BXT_GPIO_PAD_CONF1_OFFSET, padConfg1.padCnf1);
+
   //
-  // Set to Pull Up 20K
+  // Read out Board_ID 
   //
-  padConfg1.r.Term = 0xC;
-  GpioPadWrite (CommAndOffset + BXT_GPIO_PAD_CONF1_OFFSET, padConfg1.padCnf1);
-  
   *BoardId = (UINT8) (((GpioPadRead (GetCommOffset (NORTHWEST, 0x00F0) + 
BXT_GPIO_PAD_CONF0_OFFSET) & BIT1) >> 1) | \
  (((GpioPadRead (GetCommOffset (NORTHWEST, 0x00D0) + 
BXT_GPIO_PAD_CONF0_OFFSET) & BIT1) >> 1) << 1) | \
  (((GpioPadRead (GetCommOffset (NORTHWEST, 0x00C8) + 
BXT_GPIO_PAD_CONF0_OFFSET) & BIT1) >> 1) << 2) | \
- (((GpioPadRead (GetCommOffset (NORTHWEST, 0x00C0) + 
BXT_GPIO_PAD_CONF0_OFFSET) & BIT1) >> 1) << 3));
+ (((GpioPadRead (GetCommOffset (NORTH, 0x01E0) + 
BXT_GPIO_PAD_CONF0_OFFSET) & BIT1) >> 1) << 3));
 
   DEBUG ((DEBUG_INFO,  "BoardId from PMIC strap: %02X\n", *BoardId));
 
-- 
2.11.0.windows.1

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

Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

[Zeng, Star]

Tim,

In your code base, there are other tools beyond BaseTools to parse the [SkuIds] 
section and SKUID_IDENTIFIER in DSC, right?

The boot time usage (use the value in DEFAULT SKU instead if the value in 
specified SKU is not configured) for other resources in your code base is 
similar to PCD, right?
This RFC has no change to this boot time behavior that "use the value in 
DEFAULT SKU instead if the value in specified SKU is not configured".
So I am still not so clear about the benefit of the macro like #define 
SKUID_IDENTIFIER_DEFAULT 2,1,0,1,0,0.


The DSC syntax extension in this RFC is OPTIONAL, the backward compatibility is 
expected to be kept, no current tools and code should be impacted.
As I know, there will be a staging branch proposed for the development of PCD 
related RFCs (include Structure PCD, etc). Mike and Liming can help confirm it.
How about we have the development of this RFC to the staging branch first, then 
you can help evaluate the syntax and provide feedback further? :)


Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tim Lewis
Sent: Friday, May 5, 2017 12:36 AM
To: Zeng, Star ; Kinney, Michael D 
; edk2-devel@lists.01.org
Cc: Gao, Liming 
Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

Star --

I understand your use case. We use the same behavior for other resources 
besides PCD. 

All we are asking is that this data that is used by the build tools is also 
available in some form at runtime. 

Thanks,

Tim
 


-Original Message-
From: Zeng, Star [mailto:star.z...@intel.com]
Sent: Thursday, May 04, 2017 6:42 AM
To: Tim Lewis ; Kinney, Michael D 
; edk2-devel@lists.01.org
Cc: Gao, Liming ; Zeng, Star 
Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance

Tim,

To avoid misunderstanding, I think I need to clarify more about this RFC. :)

This RFC is NOT to propose building real relationship (like parent-child) 
between non-DEFAULT SKUs, it seems easy to bring confusion from the proposed 
syntax " SkuValue|SkuName[|ParentSkuName]", especially the word 'Parent', sorry 
for any confusion.
The syntax extension proposed by this RFC is just to simplify the PCDs 
configuring for multiple SKUs in DSC, I want to emphasize it is in DSC, it is 
to cover the case that some non-DEFAULT SKU has much PCD values equal with 
another non-DEFAULT SKU, but less PCD values equal with DEFAULT SKU.
This RFC has no any change to boot time behavior and does not break the rule 
that DEFAULT SKU PCD value will be returned if the specified SKU PCD value is 
not configured in DSC, the code logic is below.

PcdPeim Service.c:
  //
  // Find the current system's SKU ID entry in SKU ID table.
  //
  FoundSku = FALSE;
  for (Index = 0; Index < SkuIdTable[0]; Index++) {
if (PeiPcdDb->SystemSkuId == SkuIdTable[Index + 1]) {
  FoundSku = TRUE;
  break;
}
  }

  //
  // Find the default SKU ID entry in SKU ID table.
  //
  if(!FoundSku) {
for (Index = 0; Index < SkuIdTable[0]; Index++) {
  if (0 == SkuIdTable[Index + 1]) {
break;
  }
}
  }


The usage case you provided for other resources beyond PCD could be like below?

CurrentSkuId = PcdGetSkuId();

Resource = NULL;
if (!GetResourceForSkuId(CurrentSkuId, &Resource) {
  // try DEFAULT SKU
  GetResourceForSkuId(0, &Resource);
}
If (Resource == NULL) {
  // error, no resource found for any of the SKU IDs }



Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tim Lewis
Sent: Thursday, May 4, 2017 2:55 AM
To: Zeng, Star ; Kinney, Michael D 
; edk2-devel@lists.01.org
Cc: Gao, Liming 
Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

We use SKU IDs for working with 15 different key resources in our product. Some 
are related to code execution, but most are related to selection of resources. 
I mentioned logo components and HII strings already.

I am asking that the information about SKU relationships be output in some form 
so that it can be used at runtime, by whatever component. Today, there is an 
implied relationship between a SKU X and the SKU DEFAULT for PCDs. We use this 
rule in many places, because it expresses a useful relationship.

So, in the Project's .dsc file (forgive my syntax, which may not match yours 
exactly)

// Select which SKUs
SKUID_IDENTIFIER = Sku2 Sku1 DEFAULT

[SkuIds]
  0|DEFAULT
  1|Sku1
  2|Sku2 Sku1
  3|Sku3

In (proposed) AutoGen.h. This gives enough data for runtime usage. For other 
build tools to use, maybe something else is required.

// Output as an array initializer. DEFAULT is always last.
// Only output for SKUs listed in SKUID_IDENTIFIER // 2->1->0 // 1->0 // 0 
#define SKUID_IDENTIFIER_DEFAULT 2,1,0,1,0,0

// In actual code:

UINT32 SkuIdDefaults[] = {SKUID_IDENTIFIER_DEFAULT};
UINT32 *SkuId;
UINT32 CurrentSkuId;
BOOLEAN Found;
VOID *Resource;

CurrentSkuId = PcdGetSkuId();

SkuId = SkuIdDefaults;
Found = (Curr

Re: [edk2] [Patch] BaseTools: PCD can only use single access method by source build

[Gao, Liming]

Reviewed-by: Liming Gao 

>-Original Message-
>From: Zhu, Yonghong
>Sent: Wednesday, May 03, 2017 5:21 PM
>To: edk2-devel@lists.01.org
>Cc: Gao, Liming 
>Subject: [Patch] BaseTools: PCD can only use single access method by source
>build
>
>Add the error check that A PCD can only use one type for all source
>modules.
>
>Cc: Liming Gao 
>Contributed-under: TianoCore Contribution Agreement 1.0
>Signed-off-by: Yonghong Zhu 
>---
> BaseTools/Source/Python/AutoGen/AutoGen.py | 16 
> 1 file changed, 16 insertions(+)
>
>diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py
>b/BaseTools/Source/Python/AutoGen/AutoGen.py
>index 8075afc..205a75d 100644
>--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
>+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
>@@ -502,10 +502,26 @@ class WorkspaceAutoGen(AutoGen):
> elif 'FixedAtBuild' in BuildData.Pcds[key].Type:
> if (BuildData.Pcds[key].TokenCName,
>BuildData.Pcds[key].TokenSpaceGuidCName) not in
>SourcePcdDict['FixedAtBuild']:
>
>SourcePcdDict['FixedAtBuild'].append((BuildData.Pcds[key].TokenCName,
>BuildData.Pcds[key].TokenSpaceGuidCName))
> else:
> pass
>+#
>+# A PCD can only use one type for all source modules
>+#
>+for i in SourcePcdDict_Keys:
>+for j in SourcePcdDict_Keys:
>+if i != j:
>+IntersectionList =
>list(set(SourcePcdDict[i]).intersection(set(SourcePcdDict[j])))
>+if len(IntersectionList) > 0:
>+EdkLogger.error(
>+'build',
>+FORMAT_INVALID,
>+"Building modules from source INFs, following PCD 
>use %s
>and %s access method. It must be corrected to use only one access method." %
>(i, j),
>+ExtraData="%s" % '\n\t'.join([str(P[1]+'.'+P[0]) 
>for P in
>IntersectionList])
>+)
>+else:
>+pass
>
> #
> # intersection the BinaryPCD for Mixed PCD
> #
> for i in BinaryPcdDict_Keys:
>--
>2.6.1.windows.1

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

Re: [edk2] [Patch] BaseTools: remove the hardcoded /bin/bash for PreBuild/PostBuild

[Gao, Liming]

Reviewed-by: Liming Gao 

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Yonghong Zhu
>Sent: Wednesday, May 03, 2017 5:21 PM
>To: edk2-devel@lists.01.org
>Cc: Gao, Liming 
>Subject: [edk2] [Patch] BaseTools: remove the hardcoded /bin/bash for
>PreBuild/PostBuild
>
>This patch remove the hardcoded /bin/bash for PreBuild/PostBuild
>scripts.
>
>Cc: Liming Gao 
>Contributed-under: TianoCore Contribution Agreement 1.0
>Signed-off-by: Yonghong Zhu 
>---
> BaseTools/Source/Python/build/build.py | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/BaseTools/Source/Python/build/build.py
>b/BaseTools/Source/Python/build/build.py
>index 45ccac1..bd14e27 100644
>--- a/BaseTools/Source/Python/build/build.py
>+++ b/BaseTools/Source/Python/build/build.py
>@@ -1037,11 +1037,11 @@ class Build():
> if sys.platform == "win32":
> args = ' && '.join((self.Prebuild, 'set > ' + 
> PrebuildEnvFile))
> Process = Popen(args, stdout=PIPE, stderr=PIPE)
> else:
> args = ' && '.join((self.Prebuild, 'env > ' + 
> PrebuildEnvFile))
>-Process = Popen(args, stdout=PIPE, stderr=PIPE, shell=True,
>executable="/bin/bash")
>+Process = Popen(args, stdout=PIPE, stderr=PIPE, shell=True)
>
> # launch two threads to read the STDOUT and STDERR
> EndOfProcedure = Event()
> EndOfProcedure.clear()
> if Process.stdout:
>@@ -1079,11 +1079,11 @@ class Build():
> if self.Postbuild:
> EdkLogger.info("\n- Postbuild Start -\n")
> if sys.platform == "win32":
> Process = Popen(self.Postbuild, stdout=PIPE, stderr=PIPE)
> else:
>-Process = Popen(self.Postbuild, stdout=PIPE, stderr=PIPE, 
>shell=True,
>executable="/bin/bash")
>+Process = Popen(self.Postbuild, stdout=PIPE, stderr=PIPE,
>shell=True)
> # launch two threads to read the STDOUT and STDERR
> EndOfProcedure = Event()
> EndOfProcedure.clear()
> if Process.stdout:
> StdOutThread = Thread(target=ReadMessage, 
> args=(Process.stdout,
>EdkLogger.info, EndOfProcedure))
>--
>2.6.1.windows.1
>
>___
>edk2-devel mailing list
>edk2-devel@lists.01.org
>https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdePkg DxeServicesLib: Handle potential NULL FvHandle

[Gao, Liming]

Reviewed-by: Liming Gao 

>-Original Message-
>From: Zeng, Star
>Sent: Friday, May 05, 2017 4:21 PM
>To: edk2-devel@lists.01.org
>Cc: Zeng, Star ; Gao, Liming ;
>Kinney, Michael D ; Michael Turner
>
>Subject: [PATCH] MdePkg DxeServicesLib: Handle potential NULL FvHandle
>
>REF: https://bugzilla.tianocore.org/show_bug.cgi?id=514
>
>The FvHandle input to InternalGetSectionFromFv() may be NULL,
>then ASSERT will appear. It is because the LoadedImage->DeviceHandle
>returned from InternalImageHandleToFvHandle() may be NULL.
>For example for DxeCore, there is LoadedImage protocol installed
>for it, but the LoadedImage->DeviceHandle could not be initialized
>before the FV2 (contain DxeCore) protocol is installed.
>
>This patch is to update InternalGetSectionFromFv() to return
>EFI_NOT_FOUND directly for NULL FvHandle.
>
>Cc: Liming Gao 
>Cc: Michael Kinney 
>Cc: Michael Turner 
>Contributed-under: TianoCore Contribution Agreement 1.0
>Signed-off-by: Star Zeng 
>---
> MdePkg/Library/DxeServicesLib/DxeServicesLib.c | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
>diff --git a/MdePkg/Library/DxeServicesLib/DxeServicesLib.c
>b/MdePkg/Library/DxeServicesLib/DxeServicesLib.c
>index 2adf76fd8d22..1827c9216fbc 100644
>--- a/MdePkg/Library/DxeServicesLib/DxeServicesLib.c
>+++ b/MdePkg/Library/DxeServicesLib/DxeServicesLib.c
>@@ -2,7 +2,7 @@
>   MDE DXE Services Library provides functions that simplify the development
>of DXE Drivers.
>   These functions help access data from sections of FFS files or from file 
> path.
>
>-  Copyright (c) 2007 - 2015, Intel Corporation. All rights reserved.
>+  Copyright (c) 2007 - 2017, Intel Corporation. All rights reserved.
>   (C) Copyright 2015 Hewlett Packard Enterprise Development LP
>   This program and the accompanying materials
>   are licensed and made available under the terms and conditions of the BSD
>License
>@@ -62,6 +62,12 @@ InternalImageHandleToFvHandle (
>
>   ASSERT_EFI_ERROR (Status);
>
>+  //
>+  // The LoadedImage->DeviceHandle may be NULL.
>+  // For example for DxeCore, there is LoadedImage protocol installed for it,
>but the
>+  // LoadedImage->DeviceHandle could not be initialized before the FV2
>(contain DxeCore)
>+  // protocol is installed.
>+  //
>   return LoadedImage->DeviceHandle;
>
> }
>@@ -84,7 +90,6 @@ InternalImageHandleToFvHandle (
>   The data and size is returned by Buffer and Size. The caller is responsible 
> to
>free the Buffer allocated
>   by this function. This function can be only called at TPL_NOTIFY and below.
>
>-  If FvHandle is NULL, then ASSERT ();
>   If NameGuid is NULL, then ASSERT();
>   If Buffer is NULL, then ASSERT();
>   If Size is NULL, then ASSERT().
>@@ -128,7 +133,12 @@ InternalGetSectionFromFv (
>   ASSERT (Buffer != NULL);
>   ASSERT (Size != NULL);
>
>-  ASSERT (FvHandle != NULL);
>+  if (FvHandle == NULL) {
>+//
>+// Return EFI_NOT_FOUND directly for NULL FvHandle.
>+//
>+return EFI_NOT_FOUND;
>+  }
>
>   Status = gBS->HandleProtocol (
>   FvHandle,
>--
>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 v2 3/5] OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK

[Jordan Justen]

On 2017-05-04 21:07:24, Laszlo Ersek wrote:
> On 05/03/17 23:39, Laszlo Ersek wrote:
> > - Raise VARS_LIVE_SIZE by 8KB to 256KB, VARS_SPARE_SIZE by 8KB to 264KB,
> 
> Unfortunately, we have a terrible regression here. :(
>



> Adapting EmuVariableFvbRuntimeDxe to a non-power-of-two NV spare area
> size is hopeless. (Definitely hopeless for the time frame & resources
> I'm looking at.)
> 
> Worse, even -pflash is broken in the 4MB build, actually. The
> non-power-of-two NV spare area size, when used as Alignment for
> AllocateAlignedRuntimePages() in ReserveEmuVariableNvStore(), triggers
> an assertion. And this path is taken for the -pflash boot as well.

For a short term fix, would something like this work?

1. Force emu fvb buffer alignment to next power-of-two

   Something like the attachment, but I'm guessing you already wrote
   something similar.

2. Revert 4MB by default patch

This should allow you to start using the 4MB layout for your builds,
and we can fix the non-flash path before re-enabling 4MB as the
default.

-Jordan
From 58ba393adf60caf806b26dec9aa56d936743f595 Mon Sep 17 00:00:00 2001
From: Jordan Justen 
Date: Fri, 5 May 2017 01:43:31 -0700
Subject: [PATCH] PlatformPei: Force EmuVariableNvStore alignment size to power
 of two

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen 
---
 OvmfPkg/PlatformPei/Platform.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/PlatformPei/Platform.c
index 77a8a16c15..97dce8de92 100644
--- a/OvmfPkg/PlatformPei/Platform.c
+++ b/OvmfPkg/PlatformPei/Platform.c
@@ -504,6 +504,14 @@ ReserveEmuVariableNvStore (
 {
   EFI_PHYSICAL_ADDRESS VariableStore;
   RETURN_STATUSPcdStatus;
+  UINT32   EmuFvbSize;
+  INTN SizeHighBit;
+
+  EmuFvbSize = 2 * PcdGet32 (PcdFlashNvStorageFtwSpareSize);
+  SizeHighBit = HighBitSet32 (EmuFvbSize);
+  if ((EmuFvbSize & (EmuFvbSize - 1)) != 0) {
+SizeHighBit++;
+  }
 
   //
   // Allocate storage for NV variables early on so it will be
@@ -514,13 +522,13 @@ ReserveEmuVariableNvStore (
   VariableStore =
 (EFI_PHYSICAL_ADDRESS)(UINTN)
   AllocateAlignedRuntimePages (
-EFI_SIZE_TO_PAGES (2 * PcdGet32 (PcdFlashNvStorageFtwSpareSize)),
-PcdGet32 (PcdFlashNvStorageFtwSpareSize)
+EFI_SIZE_TO_PAGES (EmuFvbSize),
+1 << (SizeHighBit - 1)
 );
   DEBUG ((EFI_D_INFO,
   "Reserved variable store memory: 0x%lX; size: %dkb\n",
   VariableStore,
-  (2 * PcdGet32 (PcdFlashNvStorageFtwSpareSize)) / 1024
+  EmuFvbSize / 1024
 ));
   PcdStatus = PcdSet64S (PcdEmuVariableNvStoreReserved, VariableStore);
   ASSERT_RETURN_ERROR (PcdStatus);
-- 
2.11.0

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

[edk2] [PATCH] MdePkg DxeServicesLib: Handle potential NULL FvHandle

[Star Zeng]

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=514

The FvHandle input to InternalGetSectionFromFv() may be NULL,
then ASSERT will appear. It is because the LoadedImage->DeviceHandle
returned from InternalImageHandleToFvHandle() may be NULL.
For example for DxeCore, there is LoadedImage protocol installed
for it, but the LoadedImage->DeviceHandle could not be initialized
before the FV2 (contain DxeCore) protocol is installed.

This patch is to update InternalGetSectionFromFv() to return
EFI_NOT_FOUND directly for NULL FvHandle.

Cc: Liming Gao 
Cc: Michael Kinney 
Cc: Michael Turner 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 MdePkg/Library/DxeServicesLib/DxeServicesLib.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/MdePkg/Library/DxeServicesLib/DxeServicesLib.c 
b/MdePkg/Library/DxeServicesLib/DxeServicesLib.c
index 2adf76fd8d22..1827c9216fbc 100644
--- a/MdePkg/Library/DxeServicesLib/DxeServicesLib.c
+++ b/MdePkg/Library/DxeServicesLib/DxeServicesLib.c
@@ -2,7 +2,7 @@
   MDE DXE Services Library provides functions that simplify the development of 
DXE Drivers.  
   These functions help access data from sections of FFS files or from file 
path.
 
-  Copyright (c) 2007 - 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2007 - 2017, Intel Corporation. All rights reserved.
   (C) Copyright 2015 Hewlett Packard Enterprise Development LP
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -62,6 +62,12 @@ InternalImageHandleToFvHandle (
 
   ASSERT_EFI_ERROR (Status);
 
+  //
+  // The LoadedImage->DeviceHandle may be NULL.
+  // For example for DxeCore, there is LoadedImage protocol installed for it, 
but the
+  // LoadedImage->DeviceHandle could not be initialized before the FV2 
(contain DxeCore)
+  // protocol is installed.
+  //
   return LoadedImage->DeviceHandle;
 
 }
@@ -84,7 +90,6 @@ InternalImageHandleToFvHandle (
   The data and size is returned by Buffer and Size. The caller is responsible 
to free the Buffer allocated 
   by this function. This function can be only called at TPL_NOTIFY and below.
   
-  If FvHandle is NULL, then ASSERT ();
   If NameGuid is NULL, then ASSERT();
   If Buffer is NULL, then ASSERT();
   If Size is NULL, then ASSERT().
@@ -128,7 +133,12 @@ InternalGetSectionFromFv (
   ASSERT (Buffer != NULL);
   ASSERT (Size != NULL);
   
-  ASSERT (FvHandle != NULL);
+  if (FvHandle == NULL) {
+//
+// Return EFI_NOT_FOUND directly for NULL FvHandle.
+//
+return EFI_NOT_FOUND;
+  }
 
   Status = gBS->HandleProtocol (
   FvHandle,
-- 
2.7.0.windows.1

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