Re: [edk2-devel] Remove debug strings from OVMF.fd

[Liming Gao]

/Build/OvmfX64/RELEASE_GCC5/X64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.dll
 is generated by GenFw tool. When GenFw tool convert ELF image to EFI image, it 
inserts the debug entry with the below string.

Thanks
Liming
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Pedro 
Barbosa
Sent: Tuesday, April 16, 2019 11:46 PM
To: devel@edk2.groups.io
Subject: [edk2-devel] Remove debug strings from OVMF.fd

Hi EDK2 developers,

I'm trying to build OVMF without debug symbols but even building as RELEASE, I 
still can see some strings on the PE files, such as:
/Build/OvmfX64/RELEASE_GCC5/X64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.dll
and many others in the format */DEBUG/*.dll

Is there a way to build without these strings?

Thanks!

--
[]s

Pedro Yóssis Silva Barbosa
Security Engineer, Google
PhD in Computer Science, UFCG, Brazil
sites.google.com/site/pedroysb


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39236): https://edk2.groups.io/g/devel/message/39236
Mute This Topic: https://groups.io/mt/31202062/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2] MdeModulePkg/UefiBootManagerLib: fix crash on uninitialized ExitData

[Ard Biesheuvel]

As reported by Gary, the recent LoadImage/StartImage changes to
accommodate dispatching PE/COFF images built for foreign architectures
may result in a crash when loading an IA32 option ROM into a X64 VM
running OVMF:

  Loading driver at 0x0007E537000 EntryPoint=0x0007E53C06D 8086100e.efi
  InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 7F003B98
  ProtectUefiImageCommon - 0x7F002BC0
- 0x7E537000 - 0x0009F900
  Image type IA32 can't be started on X64 UEFI system.
  ASSERT MdeModulePkg/Core/Dxe/Mem/Pool.c(698): Head->Signature == ((('p') |
  ('h' << 8)) | ((('d') | ('0' << 8)) << 16)) || Head->Signature
  == ((('p') | ('h' << 8)) | ((('d') | ('1' << 8)) << 16))

This turns out to be caused by the deferred image loading code in BDS,
which doesn't check the result code of gBS->StartImage(), and ends up
trying to free an uninitialized pointer.

Given that ExitData is never actually used, let's just get rid of it
entirely. While we're at it, drop the pointless assignment of Status
as well.

Tested-by: Gary Lin 
Signed-off-by: Ard Biesheuvel 
---
v2: drop ExitData entirely instead of initializing it to NULL

 MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
index fc8775dfa419..6b8fb4d92461 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
@@ -439,8 +439,6 @@ EfiBootManagerDispatchDeferredImages (
   UINTN  ImageSize;
   BOOLEANBootOption;
   EFI_HANDLE ImageHandle;
-  UINTN  ExitDataSize;
-  CHAR16 *ExitData;
   UINTN  ImageCount;
   UINTN  LoadCount;
 
@@ -502,10 +500,7 @@ EfiBootManagerDispatchDeferredImages (
 // a 5 Minute period
 //
 gBS->SetWatchdogTimer (5 * 60, 0x, 0x00, NULL);
-Status = gBS->StartImage (ImageHandle, &ExitDataSize, &ExitData);
-if (ExitData != NULL) {
-  FreePool (ExitData);
-}
+gBS->StartImage (ImageHandle, NULL, NULL);
 
 //
 // Clear the Watchdog Timer after the image returns.
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39234): https://edk2.groups.io/g/devel/message/39234
Mute This Topic: https://groups.io/mt/31209297/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V2 25/25] MdeModulePkg/ResetUtilityLib: Add a new API ResetSystemWithSubtype

[Wu, Hao A]

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Gao,
> Zhichao
> Sent: Wednesday, April 17, 2019 2:27 PM
> To: devel@edk2.groups.io
> Cc: Bret Barkelew; Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Gao, Liming;
> Sean Brogan; Michael Turner
> Subject: [edk2-devel] [PATCH V2 25/25] MdeModulePkg/ResetUtilityLib: Add a
> new API ResetSystemWithSubtype
> 
> From: Bret Barkelew 
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1458
> 
> Implement the new API ResetSystemWithSubtype. Depend on Uefi Spec
> 2.8 chapter 8.5.1, the ResetData is valid while the ResetStatus
> is EFI_SUCCESS regardless of the ResetType. Also change the function
> ResetPlatofrmSpecificGuid to directly call ResetSystemWithSubtype
> to reduce the duplicated code.
> 
> Cc: Jian J Wang 
> Cc: Hao Wu 
> Cc: Ray Ni 
> Cc: Star Zeng 
> Cc: Liming Gao 
> Cc: Sean Brogan 
> Cc: Michael Turner 
> Cc: Bret Barkelew 
> Signed-off-by: Zhichao Gao 
> ---
>  .../Library/ResetUtilityLib/ResetUtility.c| 40 ---
>  1 file changed, 34 insertions(+), 6 deletions(-)
> 
> diff --git a/MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c
> b/MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c
> index 59f14edadc..2b5af4b95a 100644
> --- a/MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c
> +++ b/MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c
> @@ -1,7 +1,7 @@
>  /** @file
>This contains the business logic for the module-specific Reset Helper
> functions.
> 
> -  Copyright (c) 2017 - 2018 Intel Corporation. All rights reserved.
> +  Copyright (c) 2017 - 2019 Intel Corporation. All rights reserved.
>Copyright (c) 2016 Microsoft Corporation. All rights reserved.
> 
>SPDX-License-Identifier: BSD-2-Clause-Patent
> @@ -23,9 +23,9 @@ typedef struct {
>  VERIFY_SIZE_OF (RESET_UTILITY_GUID_SPECIFIC_RESET_DATA, 18);
> 
>  /**
> -  This is a shorthand helper function to reset with a subtype so that
> -  the caller doesn't have to bother with a function that has half a dozen
> -  parameters.
> +  This is a shorthand helper function to reset with reset type and a subtype
> +  so that the caller doesn't have to bother with a function that has half
> +  a dozen parameters.
> 
>This will generate a reset with status EFI_SUCCESS, a NULL string, and
>no custom data. The subtype will be formatted in such a way that it can be
> @@ -35,12 +35,14 @@ VERIFY_SIZE_OF
> (RESET_UTILITY_GUID_SPECIFIC_RESET_DATA, 18);
>  are not initialized. For DXE, you can add gEfiResetArchProtocolGuid
>  to your DEPEX.
> 
> +  @param[in]  ResetType The default EFI_RESET_TYPE of the reset.
>@param[in]  ResetSubtype  GUID pointer for the reset subtype to be used.
> 
>  **/
>  VOID
>  EFIAPI
> -ResetPlatformSpecificGuid (
> +ResetSystemWithSubtype (
> +  IN EFI_RESET_TYPE ResetType,
>IN CONST  GUID*ResetSubtype
>)
>  {
> @@ -51,7 +53,33 @@ ResetPlatformSpecificGuid (
>  (GUID *)((UINT8 *)&ResetData + OFFSET_OF
> (RESET_UTILITY_GUID_SPECIFIC_RESET_DATA, ResetSubtype)),
>  ResetSubtype
>  );
> -  ResetPlatformSpecific (sizeof (ResetData), &ResetData);
> +
> +  ResetSystem (ResetType, EFI_SUCCESS, sizeof (ResetData), &ResetData);
> +}
> +
> +/**
> +  This is a shorthand helper function to reset with the reset type
> +  'EfiResetPlatformSpecific' and a subtype so that the caller doesn't
> +  have to bother with a function that has half a dozen parameters.
> +
> +  This will generate a reset with status EFI_SUCCESS, a NULL string, and
> +  no custom data. The subtype will be formatted in such a way that it can be
> +  picked up by notification registrations and custom handlers.
> +
> +  NOTE: This call will fail if the architectural ResetSystem underpinnings
> +are not initialized. For DXE, you can add gEfiResetArchProtocolGuid
> +to your DEPEX.
> +
> +  @param[in]  ResetSubtype  GUID pointer for the reset subtype to be used.
> +
> +**/
> +VOID
> +EFIAPI
> +ResetPlatformSpecificGuid (
> +  IN CONST  GUID*ResetSubtype
> +  )
> +{
> +  ResetSystemWithSubtype (EfiResetPlatformSpecific, ResetSubtype);

Thanks for addressing the comments.
Reviewed-by: Hao Wu 

Best Regards,
Hao Wu

>  }
> 
>  /**
> --
> 2.21.0.windows.1
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39233): https://edk2.groups.io/g/devel/message/39233
Mute This Topic: https://groups.io/mt/31209245/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V2 24/25] MdeModulePkg/ResetUtilityLib: Add a new API ResetSystemWithSubtype

[Wu, Hao A]

> -Original Message-
> From: Gao, Zhichao
> Sent: Wednesday, April 17, 2019 2:27 PM
> To: devel@edk2.groups.io
> Cc: Bret Barkelew; Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Gao, Liming;
> Sean Brogan; Michael Turner
> Subject: [PATCH V2 24/25] MdeModulePkg/ResetUtilityLib: Add a new API
> ResetSystemWithSubtype
> 
> From: Bret Barkelew 
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1458
> 
> Add a new API ResetSystemWithSubtype's prototype declaration in
> header file. Also add the required data type header file.
> 
> Cc: Jian J Wang 
> Cc: Hao Wu 
> Cc: Ray Ni 
> Cc: Star Zeng 
> Cc: Liming Gao 
> Cc: Sean Brogan 
> Cc: Michael Turner 
> Cc: Bret Barkelew 
> Signed-off-by: Zhichao Gao 
> ---
>  .../Include/Library/ResetUtilityLib.h | 34 ---
>  1 file changed, 30 insertions(+), 4 deletions(-)
> 
> diff --git a/MdeModulePkg/Include/Library/ResetUtilityLib.h
> b/MdeModulePkg/Include/Library/ResetUtilityLib.h
> index ca310cdb01..656703e782 100644
> --- a/MdeModulePkg/Include/Library/ResetUtilityLib.h
> +++ b/MdeModulePkg/Include/Library/ResetUtilityLib.h
> @@ -1,7 +1,7 @@
>  /** @file
>This header describes various helper functions for resetting the system.
> 
> -  Copyright (c) 2017 Intel Corporation. All rights reserved.
> +  Copyright (c) 2017 - 2019 Intel Corporation. All rights reserved.
>Copyright (c) 2016 Microsoft Corporation. All rights reserved.
> 
>SPDX-License-Identifier: BSD-2-Clause-Patent
> @@ -10,10 +10,36 @@
>  #ifndef _RESET_UTILITY_LIB_H_
>  #define _RESET_UTILITY_LIB_H_
> 
> +#include 
> +
> +/**
> +  This is a shorthand helper function to reset with reset type and a subtype
> +  so that the caller doesn't have to bother with a function that has half
> +  a dozen parameters.
> +
> +  This will generate a reset with status EFI_SUCCESS, a NULL string, and
> +  no custom data. The subtype will be formatted in such a way that it can be
> +  picked up by notification registrations and custom handlers.
> +
> +  NOTE: This call will fail if the architectural ResetSystem underpinnings
> +are not initialized. For DXE, you can add gEfiResetArchProtocolGuid
> +to your DEPEX.
> +
> +  @param[in]  ResetType The default EFI_RESET_TYPE of the reset.
> +  @param[in]  ResetSubtype  GUID pointer for the reset subtype to be used.
> +
> +**/
> +VOID
> +EFIAPI
> +ResetSystemWithSubtype (
> +  IN EFI_RESET_TYPE ResetType,
> +  IN CONST  GUID*ResetSubtype
> +  );
> +
>  /**
> -  This is a shorthand helper function to reset with a subtype so that
> -  the caller doesn't have to bother with a function that has half a dozen
> -  parameters.
> +  This is a shorthand helper function to reset with the reset type
> +  'EfiResetPlatformSpecific' and a subtype so that the caller doesn't
> +  have to bother with a function that has half a dozen parameters.

Thanks for addressing the comments.
Reviewed-by: Hao Wu 

Best Regards,
Hao Wu

> 
>This will generate a reset with status EFI_SUCCESS, a NULL string, and
>no custom data. The subtype will be formatted in such a way that it can be
> --
> 2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39232): https://edk2.groups.io/g/devel/message/39232
Mute This Topic: https://groups.io/mt/31209252/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] MdeModulePkg/UefiBootManagerLib: fix crash on uninitialized ExitData

[Ni, Ray]

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Ard Biesheuvel
> Sent: Tuesday, April 16, 2019 11:23 PM
> To: Wu, Hao A 
> Cc: Ni, Ray ; devel@edk2.groups.io; Wang, Jian J
> ; g...@suse.com
> Subject: Re: [edk2-devel] [PATCH] MdeModulePkg/UefiBootManagerLib: fix
> crash on uninitialized ExitData
> 
> On Tue, 16 Apr 2019 at 23:07, Wu, Hao A  wrote:
> >
> > > -Original Message-
> > > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > > Sent: Wednesday, April 17, 2019 4:30 AM
> > > To: devel@edk2.groups.io
> > > Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; g...@suse.com; Ard Biesheuvel
> > > Subject: [PATCH] MdeModulePkg/UefiBootManagerLib: fix crash on
> > > uninitialized ExitData
> > >
> > > As reported by Gary, the recent LoadImage/StartImage changes to
> > > accommodate dispatching PE/COFF images built for foreign
> > > architectures may result in a crash when loading an IA32 option ROM
> > > into a X64 VM running OVMF:
> > >
> > >   Loading driver at 0x0007E537000 EntryPoint=0x0007E53C06D
> 8086100e.efi
> > >   InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF
> > > 7F003B98
> > >   ProtectUefiImageCommon - 0x7F002BC0
> > > - 0x7E537000 - 0x0009F900
> > >   Image type IA32 can't be started on X64 UEFI system.
> > >   ASSERT MdeModulePkg/Core/Dxe/Mem/Pool.c(698): Head->Signature
> ==
> > > ((('p') |
> > >   ('h' << 8)) | ((('d') | ('0' << 8)) << 16)) || 
> > > Head->Signature
> > >   == ((('p') | ('h' << 8)) | ((('d') | ('1' << 8)) <<
> > > 16))
> > >
> > > This turns out to be caused by the deferred image loading code in
> > > BDS, which doesn't check the result code of gBS->StartImage(), and
> > > ends up trying to free an uninitialized pointer. So ensure ExitData
> > > is initialized before the call.
> > >
> > > Signed-off-by: Ard Biesheuvel 
> > > ---
> > >  MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> > > b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> > > index fc8775dfa419..cf99de5b924a 100644
> > > --- a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> > > +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> > > @@ -502,6 +502,7 @@ EfiBootManagerDispatchDeferredImages (
> > >  // a 5 Minute period
> > >  //
> > >  gBS->SetWatchdogTimer (5 * 60, 0x, 0x00, NULL);
> > > +ExitData = NULL;
> > >  Status = gBS->StartImage (ImageHandle, &ExitDataSize, &ExitData);
> > >  if (ExitData != NULL) {
> > >FreePool (ExitData);
> >
> > Looks like the 'ExitData' is not being used at all here.
> >
> > Ray and Ard,
> >
> > Do you see any concern to just pass 'NULL' as the 3rd parameter
> > (eliminates 'ExitData') here?
> >
> 
> Yes, that would be even better, actually, I did not realize it was optional

I agree.
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39231): https://edk2.groups.io/g/devel/message/39231
Mute This Topic: https://groups.io/mt/31204960/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 24/25] MdeModulePkg/ResetUtilityLib: Add a new API ResetSystemWithSubtype

[Gao, Zhichao]

From: Bret Barkelew 

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

Add a new API ResetSystemWithSubtype's prototype declaration in
header file. Also add the required data type header file.

Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ray Ni 
Cc: Star Zeng 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 
Signed-off-by: Zhichao Gao 
---
 .../Include/Library/ResetUtilityLib.h | 34 ---
 1 file changed, 30 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Include/Library/ResetUtilityLib.h 
b/MdeModulePkg/Include/Library/ResetUtilityLib.h
index ca310cdb01..656703e782 100644
--- a/MdeModulePkg/Include/Library/ResetUtilityLib.h
+++ b/MdeModulePkg/Include/Library/ResetUtilityLib.h
@@ -1,7 +1,7 @@
 /** @file
   This header describes various helper functions for resetting the system.
 
-  Copyright (c) 2017 Intel Corporation. All rights reserved.
+  Copyright (c) 2017 - 2019 Intel Corporation. All rights reserved.
   Copyright (c) 2016 Microsoft Corporation. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -10,10 +10,36 @@
 #ifndef _RESET_UTILITY_LIB_H_
 #define _RESET_UTILITY_LIB_H_
 
+#include 
+
+/**
+  This is a shorthand helper function to reset with reset type and a subtype
+  so that the caller doesn't have to bother with a function that has half
+  a dozen parameters.
+
+  This will generate a reset with status EFI_SUCCESS, a NULL string, and
+  no custom data. The subtype will be formatted in such a way that it can be
+  picked up by notification registrations and custom handlers.
+
+  NOTE: This call will fail if the architectural ResetSystem underpinnings
+are not initialized. For DXE, you can add gEfiResetArchProtocolGuid
+to your DEPEX.
+
+  @param[in]  ResetType The default EFI_RESET_TYPE of the reset.
+  @param[in]  ResetSubtype  GUID pointer for the reset subtype to be used.
+
+**/
+VOID
+EFIAPI
+ResetSystemWithSubtype (
+  IN EFI_RESET_TYPE ResetType,
+  IN CONST  GUID*ResetSubtype
+  );
+
 /**
-  This is a shorthand helper function to reset with a subtype so that
-  the caller doesn't have to bother with a function that has half a dozen
-  parameters.
+  This is a shorthand helper function to reset with the reset type
+  'EfiResetPlatformSpecific' and a subtype so that the caller doesn't
+  have to bother with a function that has half a dozen parameters.
 
   This will generate a reset with status EFI_SUCCESS, a NULL string, and
   no custom data. The subtype will be formatted in such a way that it can be
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39230): https://edk2.groups.io/g/devel/message/39230
Mute This Topic: https://groups.io/mt/31209252/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 19/25] PcAtChipsetPkg/ResetSystemLib: Add new API ResetSystem

[Gao, Zhichao]

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

Add a new API ResetSystem to this ResetSystemLib instance.
It only adds the basic functions from ResetSystemRuntimeDxe.
Lacking of this interface may cause link error, if some drivers
use this new API and link to this library instance.
Notes:
This library API only provide a basic function of reset. Full
function should use the instance in the MdeModulePkg and make
sure the depex driver is dispatched.

Cc: Ray Ni 
Cc: Liming Gao 
Signed-off-by: Zhichao Gao 
---
 .../Library/ResetSystemLib/ResetSystemLib.c   | 48 ++-
 1 file changed, 47 insertions(+), 1 deletion(-)

diff --git a/PcAtChipsetPkg/Library/ResetSystemLib/ResetSystemLib.c 
b/PcAtChipsetPkg/Library/ResetSystemLib/ResetSystemLib.c
index eccef89ebe..7fe1663c97 100644
--- a/PcAtChipsetPkg/Library/ResetSystemLib/ResetSystemLib.c
+++ b/PcAtChipsetPkg/Library/ResetSystemLib/ResetSystemLib.c
@@ -1,13 +1,16 @@
 /** @file
   Reset System Library functions for PCAT platforms
 
-  Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
 
 #include 
 
+#include 
+#include 
+
 #include 
 #include 
 
@@ -99,3 +102,46 @@ ResetPlatformSpecific (
 {
   ResetCold ();
 }
+
+/**
+  The ResetSystem function resets the entire platform.
+
+  @param[in] ResetType  The type of reset to perform.
+  @param[in] ResetStatusThe status code for the reset.
+  @param[in] DataSize   The size, in bytes, of ResetData.
+  @param[in] ResetData  For a ResetType of EfiResetCold, EfiResetWarm, or 
EfiResetShutdown
+the data buffer starts with a Null-terminated 
string, optionally
+followed by additional binary data. The string is 
a description
+that the caller may use to further indicate the 
reason for the
+system reset.
+**/
+VOID
+EFIAPI
+ResetSystem (
+  IN EFI_RESET_TYPE   ResetType,
+  IN EFI_STATUS   ResetStatus,
+  IN UINTNDataSize,
+  IN VOID *ResetData OPTIONAL
+  )
+{
+  switch (ResetType) {
+  case EfiResetWarm:
+ResetWarm ();
+break;
+
+  case EfiResetCold:
+ResetCold ();
+break;
+
+  case EfiResetShutdown:
+ResetShutdown ();
+return;
+
+  case EfiResetPlatformSpecific:
+ResetPlatformSpecific (DataSize, ResetData);
+return;
+
+  default:
+return;
+  }
+}
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39224): https://edk2.groups.io/g/devel/message/39224
Mute This Topic: https://groups.io/mt/31209238/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 21/25] Vlv2TbltdevicePkg/ResetSystemLib: Add new API ResetSystem

[Gao, Zhichao]

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

Add a new API ResetSystem to this ResetSystemLib instance.
It only adds the basic functions from ResetSystemRuntimeDxe.
Lacking of this interface may cause link error, if some drivers
use this new API and link to this library instance.
Notes:
This library API only provide a basic function of reset. Full
function should use the instance in the MdeModulePkg and make
sure the depex driver is dispatched.

Cc: Zailiang Sun 
Cc: Yi Qian 
Cc: Liming Gao 
Signed-off-by: Zhichao Gao 
Reviewed-by: Zailiang Sun 
---
 .../Library/ResetSystemLib/ResetSystemLib.c   | 45 ++-
 1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/Vlv2TbltDevicePkg/Library/ResetSystemLib/ResetSystemLib.c 
b/Vlv2TbltDevicePkg/Library/ResetSystemLib/ResetSystemLib.c
index 1cd6f80891..fac998fefa 100644
--- a/Vlv2TbltDevicePkg/Library/ResetSystemLib/ResetSystemLib.c
+++ b/Vlv2TbltDevicePkg/Library/ResetSystemLib/ResetSystemLib.c
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2007 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 



@@ -190,3 +190,46 @@ ResetPlatformSpecific (
 {
   ResetCold ();
 }
+
+/**
+  The ResetSystem function resets the entire platform.
+
+  @param[in] ResetType  The type of reset to perform.
+  @param[in] ResetStatusThe status code for the reset.
+  @param[in] DataSize   The size, in bytes, of ResetData.
+  @param[in] ResetData  For a ResetType of EfiResetCold, EfiResetWarm, or 
EfiResetShutdown
+the data buffer starts with a Null-terminated 
string, optionally
+followed by additional binary data. The string is 
a description
+that the caller may use to further indicate the 
reason for the
+system reset.
+**/
+VOID
+EFIAPI
+ResetSystem (
+  IN EFI_RESET_TYPE   ResetType,
+  IN EFI_STATUS   ResetStatus,
+  IN UINTNDataSize,
+  IN VOID *ResetData OPTIONAL
+  )
+{
+  switch (ResetType) {
+  case EfiResetWarm:
+ResetWarm ();
+break;
+
+  case EfiResetCold:
+ResetCold ();
+break;
+
+  case EfiResetShutdown:
+ResetShutdown ();
+return;
+
+  case EfiResetPlatformSpecific:
+ResetPlatformSpecific (DataSize, ResetData);
+return;
+
+  default:
+return;
+  }
+}
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39226): https://edk2.groups.io/g/devel/message/39226
Mute This Topic: https://groups.io/mt/31209240/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 23/25] ArmVirtPkg/ArmVirtPsciResetSystemLib: Add a new API ResetSystem

[Gao, Zhichao]

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

Add a new API ResetSystem to this ResetSystemLib instance.
It only adds the basic functions from ResetSystemRuntimeDxe.
Lacking of this interface may cause link error, if some drivers
use this new API and link to this library instance.
Notes:
This library API only provide a basic function of reset. Full
function should use the instance in the MdeModulePkg and make
sure the depex driver is dispatched.

Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Liming Gao 
Signed-off-by: Zhichao Gao 
Reviewed-by: Laszlo Ersek 
---
 .../ArmVirtPsciResetSystemLib.c   | 44 +++
 1 file changed, 44 insertions(+)

diff --git 
a/ArmVirtPkg/Library/ArmVirtPsciResetSystemLib/ArmVirtPsciResetSystemLib.c 
b/ArmVirtPkg/Library/ArmVirtPsciResetSystemLib/ArmVirtPsciResetSystemLib.c
index 79a5456c49..fdf49e1d9c 100644
--- a/ArmVirtPkg/Library/ArmVirtPsciResetSystemLib/ArmVirtPsciResetSystemLib.c
+++ b/ArmVirtPkg/Library/ArmVirtPsciResetSystemLib/ArmVirtPsciResetSystemLib.c
@@ -8,6 +8,7 @@
   Copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
   Copyright (c) 2013, ARM Ltd. All rights reserved.
   Copyright (c) 2014, Linaro Ltd. All rights reserved.
+  Copyright (c) 2019, Intel Corporation. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -179,3 +180,46 @@ ResetPlatformSpecific (
   // Map the platform specific reset as reboot
   ResetCold ();
 }
+
+/**
+  The ResetSystem function resets the entire platform.
+
+  @param[in] ResetType  The type of reset to perform.
+  @param[in] ResetStatusThe status code for the reset.
+  @param[in] DataSize   The size, in bytes, of ResetData.
+  @param[in] ResetData  For a ResetType of EfiResetCold, EfiResetWarm, or 
EfiResetShutdown
+the data buffer starts with a Null-terminated 
string, optionally
+followed by additional binary data. The string is 
a description
+that the caller may use to further indicate the 
reason for the
+system reset.
+**/
+VOID
+EFIAPI
+ResetSystem (
+  IN EFI_RESET_TYPE   ResetType,
+  IN EFI_STATUS   ResetStatus,
+  IN UINTNDataSize,
+  IN VOID *ResetData OPTIONAL
+  )
+{
+  switch (ResetType) {
+  case EfiResetWarm:
+ResetWarm ();
+break;
+
+  case EfiResetCold:
+ResetCold ();
+break;
+
+  case EfiResetShutdown:
+ResetShutdown ();
+return;
+
+  case EfiResetPlatformSpecific:
+ResetPlatformSpecific (DataSize, ResetData);
+return;
+
+  default:
+return;
+  }
+}
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39228): https://edk2.groups.io/g/devel/message/39228
Mute This Topic: https://groups.io/mt/31209244/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 17/25] Nt32Pkg/ResetSystemLib: Add new API ResetSystem

[Gao, Zhichao]

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

Add a new API ResetSystem to this ResetSystemLib instance.
It only adds the basic functions from ResetSystemRuntimeDxe.
Lacking of this interface may cause link error, if some drivers
use this new API and link to this library instance.
Notes:
This library API only provide a basic function of reset. Full
function should use the instance in the MdeModulePkg and make
sure the depex driver is dispatched.

Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
Cc: Liming Gao 
Signed-off-by: Zhichao Gao 
Reviewed-by: Hao Wu 
---
 .../Library/ResetSystemLib/ResetSystemLib.c   | 45 ++-
 1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/Nt32Pkg/Library/ResetSystemLib/ResetSystemLib.c 
b/Nt32Pkg/Library/ResetSystemLib/ResetSystemLib.c
index ed4129d46b..f8f9aa409f 100644
--- a/Nt32Pkg/Library/ResetSystemLib/ResetSystemLib.c
+++ b/Nt32Pkg/Library/ResetSystemLib/ResetSystemLib.c
@@ -1,6 +1,6 @@
 /** @file
   
-  Copyright (c) 2017, Intel Corporation. All rights reserved.
+  Copyright (c) 2017 - 2019, Intel Corporation. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -90,3 +90,46 @@ ResetPlatformSpecific (
 {
   ResetCold ();
 }
+
+/**
+  The ResetSystem function resets the entire platform.
+
+  @param[in] ResetType  The type of reset to perform.
+  @param[in] ResetStatusThe status code for the reset.
+  @param[in] DataSize   The size, in bytes, of ResetData.
+  @param[in] ResetData  For a ResetType of EfiResetCold, EfiResetWarm, or 
EfiResetShutdown
+the data buffer starts with a Null-terminated 
string, optionally
+followed by additional binary data. The string is 
a description
+that the caller may use to further indicate the 
reason for the
+system reset.
+**/
+VOID
+EFIAPI
+ResetSystem (
+  IN EFI_RESET_TYPE   ResetType,
+  IN EFI_STATUS   ResetStatus,
+  IN UINTNDataSize,
+  IN VOID *ResetData OPTIONAL
+  )
+{
+  switch (ResetType) {
+  case EfiResetWarm:
+ResetWarm ();
+break;
+
+  case EfiResetCold:
+ResetCold ();
+break;
+
+  case EfiResetShutdown:
+ResetShutdown ();
+return;
+
+  case EfiResetPlatformSpecific:
+ResetPlatformSpecific (DataSize, ResetData);
+return;
+
+  default:
+return;
+  }
+}
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39222): https://edk2.groups.io/g/devel/message/39222
Mute This Topic: https://groups.io/mt/31209236/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 16/25] CorebootPayloadPkg/ResetSystemLib: Add new API ResetSystem

[Gao, Zhichao]

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

Add a new API ResetSystem to this ResetSystemLib instance.
It only adds the basic functions from ResetSystemRuntimeDxe.
Lacking of this interface may cause link error, if some drivers
use this new API and link to this library instance.
Notes:
This library API only provide a basic function of reset. Full
function should use the instance in the MdeModulePkg and make
sure the depex driver is dispatched.

Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
Cc: Liming Gao 
Signed-off-by: Zhichao Gao 
Reviewed-by: Leif Lindholm 
---
 .../Library/ResetSystemLib/ResetSystemLib.c   | 45 ++-
 1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/CorebootPayloadPkg/Library/ResetSystemLib/ResetSystemLib.c 
b/CorebootPayloadPkg/Library/ResetSystemLib/ResetSystemLib.c
index 1fb9142408..2a6abaf6ba 100644
--- a/CorebootPayloadPkg/Library/ResetSystemLib/ResetSystemLib.c
+++ b/CorebootPayloadPkg/Library/ResetSystemLib/ResetSystemLib.c
@@ -1,7 +1,7 @@
 /** @file
   Reset System Library functions for coreboot
 
-  Copyright (c) 2014 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2014 - 2019, Intel Corporation. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -176,3 +176,46 @@ ResetPlatformSpecific (
 {
   ResetCold ();
 }
+
+/**
+  The ResetSystem function resets the entire platform.
+
+  @param[in] ResetType  The type of reset to perform.
+  @param[in] ResetStatusThe status code for the reset.
+  @param[in] DataSize   The size, in bytes, of ResetData.
+  @param[in] ResetData  For a ResetType of EfiResetCold, EfiResetWarm, or 
EfiResetShutdown
+the data buffer starts with a Null-terminated 
string, optionally
+followed by additional binary data. The string is 
a description
+that the caller may use to further indicate the 
reason for the
+system reset.
+**/
+VOID
+EFIAPI
+ResetSystem (
+  IN EFI_RESET_TYPE   ResetType,
+  IN EFI_STATUS   ResetStatus,
+  IN UINTNDataSize,
+  IN VOID *ResetData OPTIONAL
+  )
+{
+  switch (ResetType) {
+  case EfiResetWarm:
+ResetWarm ();
+break;
+
+  case EfiResetCold:
+ResetCold ();
+break;
+
+  case EfiResetShutdown:
+ResetShutdown ();
+return;
+
+  case EfiResetPlatformSpecific:
+ResetPlatformSpecific (DataSize, ResetData);
+return;
+
+  default:
+return;
+  }
+}
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39221): https://edk2.groups.io/g/devel/message/39221
Mute This Topic: https://groups.io/mt/31209235/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 20/25] QuarkSocPkg/ResetSystemLib: Add new API ResetSystem

[Gao, Zhichao]

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

Add a new API ResetSystem to this ResetSystemLib instance.
It only adds the basic functions from ResetSystemRuntimeDxe.
Lacking of this interface may cause link error, if some drivers
use this new API and link to this library instance.
Notes:
This library API only provide a basic function of reset. Full
function should use the instance in the MdeModulePkg and make
sure the depex driver is dispatched.

Cc: Michael D Kinney 
Cc: Kelly Steele 
Cc: Liming Gao 
Signed-off-by: Zhichao Gao 
---
 .../Library/ResetSystemLib/ResetSystemLib.c   | 45 ++-
 1 file changed, 44 insertions(+), 1 deletion(-)

diff --git 
a/QuarkSocPkg/QuarkNorthCluster/Library/ResetSystemLib/ResetSystemLib.c 
b/QuarkSocPkg/QuarkNorthCluster/Library/ResetSystemLib/ResetSystemLib.c
index ea95f89059..d730f62ce0 100644
--- a/QuarkSocPkg/QuarkNorthCluster/Library/ResetSystemLib/ResetSystemLib.c
+++ b/QuarkSocPkg/QuarkNorthCluster/Library/ResetSystemLib/ResetSystemLib.c
@@ -2,7 +2,7 @@
 System reset Library Services.  This library class provides a set of
 methods to reset whole system with manipulate QNC.
 
-Copyright (c) 2013-2016 Intel Corporation.
+Copyright (c) 2013-2019 Intel Corporation.
 
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -334,3 +334,46 @@ ResetPlatformSpecific (
 {
   ResetCold ();
 }
+
+/**
+  The ResetSystem function resets the entire platform.
+
+  @param[in] ResetType  The type of reset to perform.
+  @param[in] ResetStatusThe status code for the reset.
+  @param[in] DataSize   The size, in bytes, of ResetData.
+  @param[in] ResetData  For a ResetType of EfiResetCold, EfiResetWarm, or 
EfiResetShutdown
+the data buffer starts with a Null-terminated 
string, optionally
+followed by additional binary data. The string is 
a description
+that the caller may use to further indicate the 
reason for the
+system reset.
+**/
+VOID
+EFIAPI
+ResetSystem (
+  IN EFI_RESET_TYPE   ResetType,
+  IN EFI_STATUS   ResetStatus,
+  IN UINTNDataSize,
+  IN VOID *ResetData OPTIONAL
+  )
+{
+  switch (ResetType) {
+  case EfiResetWarm:
+ResetWarm ();
+break;
+
+  case EfiResetCold:
+ResetCold ();
+break;
+
+  case EfiResetShutdown:
+ResetShutdown ();
+return;
+
+  case EfiResetPlatformSpecific:
+ResetPlatformSpecific (DataSize, ResetData);
+return;
+
+  default:
+return;
+  }
+}
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39225): https://edk2.groups.io/g/devel/message/39225
Mute This Topic: https://groups.io/mt/31209239/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 06/25] MdeModulePkg/ResetSystemLib.h: Change comments of ResetSystem

[Gao, Zhichao]

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

Refer to Uefi spec 2.8, the ResetData is valid while ResetStatus
is EFI_SUCCESS regardless of the ResetType is EfiResetPlatformSpecific
or not.

Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ray Ni 
Cc: Star Zeng 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 
Signed-off-by: Zhichao Gao 
Reviewed-by: Hao Wu 
---
 MdeModulePkg/Include/Library/ResetSystemLib.h | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/MdeModulePkg/Include/Library/ResetSystemLib.h 
b/MdeModulePkg/Include/Library/ResetSystemLib.h
index 8fd875f2e9..3b2a098a60 100644
--- a/MdeModulePkg/Include/Library/ResetSystemLib.h
+++ b/MdeModulePkg/Include/Library/ResetSystemLib.h
@@ -90,9 +90,7 @@ ResetPlatformSpecific (
 the data buffer starts with a Null-terminated 
string, optionally
 followed by additional binary data. The string is 
a description
 that the caller may use to further indicate the 
reason for the
-system reset. ResetData is only valid if 
ResetStatus is something
-other than EFI_SUCCESS unless the ResetType is 
EfiResetPlatformSpecific
-where a minimum amount of ResetData is always 
required.
+system reset.
 **/
 VOID
 EFIAPI
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39211): https://edk2.groups.io/g/devel/message/39211
Mute This Topic: https://groups.io/mt/31209225/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 25/25] MdeModulePkg/ResetUtilityLib: Add a new API ResetSystemWithSubtype

[Gao, Zhichao]

From: Bret Barkelew 

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

Implement the new API ResetSystemWithSubtype. Depend on Uefi Spec
2.8 chapter 8.5.1, the ResetData is valid while the ResetStatus
is EFI_SUCCESS regardless of the ResetType. Also change the function
ResetPlatofrmSpecificGuid to directly call ResetSystemWithSubtype
to reduce the duplicated code.

Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ray Ni 
Cc: Star Zeng 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 
Signed-off-by: Zhichao Gao 
---
 .../Library/ResetUtilityLib/ResetUtility.c| 40 ---
 1 file changed, 34 insertions(+), 6 deletions(-)

diff --git a/MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c 
b/MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c
index 59f14edadc..2b5af4b95a 100644
--- a/MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c
+++ b/MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c
@@ -1,7 +1,7 @@
 /** @file
   This contains the business logic for the module-specific Reset Helper 
functions.
 
-  Copyright (c) 2017 - 2018 Intel Corporation. All rights reserved.
+  Copyright (c) 2017 - 2019 Intel Corporation. All rights reserved.
   Copyright (c) 2016 Microsoft Corporation. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -23,9 +23,9 @@ typedef struct {
 VERIFY_SIZE_OF (RESET_UTILITY_GUID_SPECIFIC_RESET_DATA, 18);
 
 /**
-  This is a shorthand helper function to reset with a subtype so that
-  the caller doesn't have to bother with a function that has half a dozen
-  parameters.
+  This is a shorthand helper function to reset with reset type and a subtype
+  so that the caller doesn't have to bother with a function that has half
+  a dozen parameters.
 
   This will generate a reset with status EFI_SUCCESS, a NULL string, and
   no custom data. The subtype will be formatted in such a way that it can be
@@ -35,12 +35,14 @@ VERIFY_SIZE_OF (RESET_UTILITY_GUID_SPECIFIC_RESET_DATA, 18);
 are not initialized. For DXE, you can add gEfiResetArchProtocolGuid
 to your DEPEX.
 
+  @param[in]  ResetType The default EFI_RESET_TYPE of the reset.
   @param[in]  ResetSubtype  GUID pointer for the reset subtype to be used.
 
 **/
 VOID
 EFIAPI
-ResetPlatformSpecificGuid (
+ResetSystemWithSubtype (
+  IN EFI_RESET_TYPE ResetType,
   IN CONST  GUID*ResetSubtype
   )
 {
@@ -51,7 +53,33 @@ ResetPlatformSpecificGuid (
 (GUID *)((UINT8 *)&ResetData + OFFSET_OF 
(RESET_UTILITY_GUID_SPECIFIC_RESET_DATA, ResetSubtype)),
 ResetSubtype
 );
-  ResetPlatformSpecific (sizeof (ResetData), &ResetData);
+
+  ResetSystem (ResetType, EFI_SUCCESS, sizeof (ResetData), &ResetData);
+}
+
+/**
+  This is a shorthand helper function to reset with the reset type
+  'EfiResetPlatformSpecific' and a subtype so that the caller doesn't
+  have to bother with a function that has half a dozen parameters.
+
+  This will generate a reset with status EFI_SUCCESS, a NULL string, and
+  no custom data. The subtype will be formatted in such a way that it can be
+  picked up by notification registrations and custom handlers.
+
+  NOTE: This call will fail if the architectural ResetSystem underpinnings
+are not initialized. For DXE, you can add gEfiResetArchProtocolGuid
+to your DEPEX.
+
+  @param[in]  ResetSubtype  GUID pointer for the reset subtype to be used.
+
+**/
+VOID
+EFIAPI
+ResetPlatformSpecificGuid (
+  IN CONST  GUID*ResetSubtype
+  )
+{
+  ResetSystemWithSubtype (EfiResetPlatformSpecific, ResetSubtype);
 }
 
 /**
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39229): https://edk2.groups.io/g/devel/message/39229
Mute This Topic: https://groups.io/mt/31209245/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 10/25] MdeModulePkg/PeiResetSystemlib.c: Change comments of ResetSystem

[Gao, Zhichao]

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

Refer to Uefi spec 2.8, the ResetData is valid while ResetStatus
is EFI_SUCCESS regardless of the ResetType is EfiResetPlatformSpecific
or not.

Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ray Ni 
Cc: Star Zeng 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 
Signed-off-by: Zhichao Gao 
Reviewed-by: Hao Wu 
---
 MdeModulePkg/Library/PeiResetSystemLib/PeiResetSystemLib.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/MdeModulePkg/Library/PeiResetSystemLib/PeiResetSystemLib.c 
b/MdeModulePkg/Library/PeiResetSystemLib/PeiResetSystemLib.c
index be5dc08c7a..50297129b7 100644
--- a/MdeModulePkg/Library/PeiResetSystemLib/PeiResetSystemLib.c
+++ b/MdeModulePkg/Library/PeiResetSystemLib/PeiResetSystemLib.c
@@ -101,9 +101,7 @@ ResetPlatformSpecific (
 the data buffer starts with a Null-terminated 
string, optionally
 followed by additional binary data. The string is 
a description
 that the caller may use to further indicate the 
reason for the
-system reset. ResetData is only valid if 
ResetStatus is something
-other than EFI_SUCCESS unless the ResetType is 
EfiResetPlatformSpecific
-where a minimum amount of ResetData is always 
required.
+system reset.
 **/
 VOID
 EFIAPI
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39215): https://edk2.groups.io/g/devel/message/39215
Mute This Topic: https://groups.io/mt/31209229/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 22/25] ArmPkg/ArmSmcPsciResetSystemLib: Add a new API ResetSystem

[Gao, Zhichao]

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

Add a new API ResetSystem to this ResetSystemLib instance.
It only adds the basic functions from ResetSystemRuntimeDxe.
Lacking of this interface may cause link error, if some drivers
use this new API and link to this library instance.
Notes:
This library API only provide a basic function of reset. Full
function should use the instance in the MdeModulePkg and make
sure the depex driver is dispatched.

Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
Cc: Liming Gao 
Signed-off-by: Zhichao Gao 
Reviewed-by: Leif Lindholm 
---
 .../ArmSmcPsciResetSystemLib.c| 44 +++
 1 file changed, 44 insertions(+)

diff --git a/ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.c 
b/ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.c
index 87c1ea0ed0..b2dde9bfc1 100644
--- a/ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.c
+++ b/ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.c
@@ -2,6 +2,7 @@
   ResetSystemLib implementation using PSCI calls
 
   Copyright (c) 2017 - 2018, Linaro Ltd. All rights reserved.
+  Copyright (c) 2019, Intel Corporation. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -169,3 +170,46 @@ ResetPlatformSpecific (
   // Map the platform specific reset as reboot
   ResetCold ();
 }
+
+/**
+  The ResetSystem function resets the entire platform.
+
+  @param[in] ResetType  The type of reset to perform.
+  @param[in] ResetStatusThe status code for the reset.
+  @param[in] DataSize   The size, in bytes, of ResetData.
+  @param[in] ResetData  For a ResetType of EfiResetCold, EfiResetWarm, or 
EfiResetShutdown
+the data buffer starts with a Null-terminated 
string, optionally
+followed by additional binary data. The string is 
a description
+that the caller may use to further indicate the 
reason for the
+system reset.
+**/
+VOID
+EFIAPI
+ResetSystem (
+  IN EFI_RESET_TYPE   ResetType,
+  IN EFI_STATUS   ResetStatus,
+  IN UINTNDataSize,
+  IN VOID *ResetData OPTIONAL
+  )
+{
+  switch (ResetType) {
+  case EfiResetWarm:
+ResetWarm ();
+break;
+
+  case EfiResetCold:
+ResetCold ();
+break;
+
+  case EfiResetShutdown:
+ResetShutdown ();
+return;
+
+  case EfiResetPlatformSpecific:
+ResetPlatformSpecific (DataSize, ResetData);
+return;
+
+  default:
+return;
+  }
+}
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39227): https://edk2.groups.io/g/devel/message/39227
Mute This Topic: https://groups.io/mt/31209242/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 14/25] MdeModulePkg/NvmExpressHci.c: Change comments

[Gao, Zhichao]

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

Refer to Uefi spec 2.8, the ResetData is valid while ResetStatus
is EFI_SUCCESS regardless of the ResetType is EfiResetPlatformSpecific
or not. So change the comments of NvmeShutdownAllControllers.

Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ray Ni 
Cc: Star Zeng 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 
Signed-off-by: Zhichao Gao 
Reviewed-by: Hao Wu 
---
 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c 
b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
index d1b106ef61..95f8b18bc4 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
+++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
@@ -966,10 +966,7 @@ NvmeControllerInit (
 EfiResetShutdown the data buffer starts with a 
Null-terminated
 string, optionally followed by additional 
binary data.
 The string is a description that the caller 
may use to further
-indicate the reason for the system reset. 
ResetData is only
-valid if ResetStatus is something other than 
EFI_SUCCESS
-unless the ResetType is 
EfiResetPlatformSpecific
-where a minimum amount of ResetData is always 
required.
+indicate the reason for the system reset.
 For a ResetType of EfiResetPlatformSpecific 
the data buffer
 also starts with a Null-terminated string that 
is followed
 by an EFI_GUID that describes the specific 
type of reset to perform.
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39219): https://edk2.groups.io/g/devel/message/39219
Mute This Topic: https://groups.io/mt/31209233/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 02/25] MdePkg/PiPeiCis.h: Change comments of EFI_PEI_RESET2_SYSTEM

[Gao, Zhichao]

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

Refer to Uefi spec 2.8, the ResetData is valid while ResetStatus
is EFI_SUCCESS regardless of the ResetType is EfiResetPlatformSpecific
or not.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 
Signed-off-by: Zhichao Gao 
Reviewed-by: Liming Gao 
---
 MdePkg/Include/Pi/PiPeiCis.h | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/MdePkg/Include/Pi/PiPeiCis.h b/MdePkg/Include/Pi/PiPeiCis.h
index ea2455ab1f..d9d4ed7d41 100644
--- a/MdePkg/Include/Pi/PiPeiCis.h
+++ b/MdePkg/Include/Pi/PiPeiCis.h
@@ -1,7 +1,7 @@
 /** @file
   PI PEI master include file. This file should match the PI spec.
 
-Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
   @par Revision Reference:
@@ -614,9 +614,7 @@ EFI_STATUS
 the data buffer starts with a Null-terminated 
string, optionally
 followed by additional binary data. The string is 
a description
 that the caller may use to further indicate the 
reason for the
-system reset. ResetData is only valid if 
ResetStatus is something
-other than EFI_SUCCESS unless the ResetType is 
EfiResetPlatformSpecific
-where a minimum amount of ResetData is always 
required.
+system reset.
 
 **/
 typedef
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39207): https://edk2.groups.io/g/devel/message/39207
Mute This Topic: https://groups.io/mt/31209221/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 04/25] MdePkg/PeiServicesLib.c: Change comments of PeiServicesResetSystem2

[Gao, Zhichao]

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

Refer to Uefi spec 2.8, the ResetData is valid while ResetStatus
is EFI_SUCCESS regardless of the ResetType is EfiResetPlatformSpecific
or not.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 
Signed-off-by: Zhichao Gao 
Reviewed-by: Liming Gao 
---
 MdePkg/Library/PeiServicesLib/PeiServicesLib.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/MdePkg/Library/PeiServicesLib/PeiServicesLib.c 
b/MdePkg/Library/PeiServicesLib/PeiServicesLib.c
index 35d03fed62..e8eaed71c8 100644
--- a/MdePkg/Library/PeiServicesLib/PeiServicesLib.c
+++ b/MdePkg/Library/PeiServicesLib/PeiServicesLib.c
@@ -1,7 +1,7 @@
 /** @file
   Implementation for PEI Services Library.
 
-  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -793,9 +793,7 @@ PeiServicesInstallFvInfo2Ppi (
 the data buffer starts with a Null-terminated 
string, optionally
 followed by additional binary data. The string is 
a description
 that the caller may use to further indicate the 
reason for the
-system reset. ResetData is only valid if 
ResetStatus is something
-other than EFI_SUCCESS unless the ResetType is 
EfiResetPlatformSpecific
-where a minimum amount of ResetData is always 
required.
+system reset.
 
 **/
 VOID
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39209): https://edk2.groups.io/g/devel/message/39209
Mute This Topic: https://groups.io/mt/31209223/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 00/25] Add the new APIs ResetSystem and ResetSystemWithSubtype

[Gao, Zhichao]

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1460
Refer to Uefi spec 2.8, the ResetData is valid while ResetStatus
is EFI_SUCCESS regardless of the ResetType is EfiResetPlatformSpecific
or not.
Add a new API ResetSystem to ResetSystemLib instances. The new driver may
consume this new API and then it may cause a link error. For these library
instances, the new API only has a basic function. If the consumers want
the full function of this API, they should use the instance in the MdeModulePkg
and make sure the depex driver is dispatched.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1458
Add a new API ResetSystemWithSubtype to ResetUtilityLib

V2:
Update the copy right.
Fix build error of PcAtChipsetPkg/ResetSystemLib.
Fix the coding style issue.
Update the comment for the new API ResetSystemWithSubtype

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Chao Zhang 
Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ray Ni 
Cc: Star Zeng 
Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Michael D Kinney 
Cc: Kelly Steele 
Cc: Zailiang Sun 
Cc: Yi Qian 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 

Bret Barkelew (2):
  MdeModulePkg/ResetUtilityLib: Add a new API ResetSystemWithSubtype
  MdeModulePkg/ResetUtilityLib: Add a new API ResetSystemWithSubtype

Zhichao Gao (23):
  MdePkg/UefiSpec.h: Change comments of EFI_RESET_SYSTEM
  MdePkg/PiPeiCis.h: Change comments of EFI_PEI_RESET2_SYSTEM
  MdePkg/PeiServicesLib.h: Change comments of PeiServicesResetSystem2
  MdePkg/PeiServicesLib.c: Change comments of PeiServicesResetSystem2
  SecurityPkg/Tcg2Dxe: Change comments of ShutdownTpmOnReset
  MdeModulePkg/ResetSystemLib.h: Change comments of ResetSystem
  MdeModulePkg/DxeResetSystemLib.c: Change comments of ResetSystem
  MdeModulePkg/BaseResetSystemLibNull.c: Change comments of ResetSystem
  MdeModulePkg/RuntimeResetSystemLib.c: Change comments
  MdeModulePkg/PeiResetSystemlib.c: Change comments of ResetSystem
  MdeModulePkg/ResetSystemRuntimeDxe: Change comments
  MdeModulePkg/ResetSystemPei: Change comments of ResetSystem2
  MdeModulePkg/PeiMain: Change comments of PeiResetSystem2
  MdeModulePkg/NvmExpressHci.c: Change comments
  BeagleBoardPkg/ResetSystemLib: Add new API ResetSystem
  CorebootPayloadPkg/ResetSystemLib: Add new API ResetSystem
  Nt32Pkg/ResetSystemLib: Add new API ResetSystem
  OvmfPkg/ResetSystemLib: Add new API ResetSystem
  PcAtChipsetPkg/ResetSystemLib: Add new API ResetSystem
  QuarkSocPkg/ResetSystemLib: Add new API ResetSystem
  Vlv2TbltdevicePkg/ResetSystemLib: Add new API ResetSystem
  ArmPkg/ArmSmcPsciResetSystemLib: Add a new API ResetSystem
  ArmVirtPkg/ArmVirtPsciResetSystemLib: Add a new API ResetSystem

 .../ArmSmcPsciResetSystemLib.c| 44 +
 .../ArmVirtPsciResetSystemLib.c   | 44 +
 .../Library/ResetSystemLib/ResetSystemLib.c   | 44 +
 .../Library/ResetSystemLib/ResetSystemLib.c   | 45 -
 .../Bus/Pci/NvmExpressDxe/NvmExpressHci.c |  5 +-
 MdeModulePkg/Core/Pei/PeiMain.h   |  4 +-
 MdeModulePkg/Core/Pei/Reset/Reset.c   |  6 +--
 MdeModulePkg/Include/Library/ResetSystemLib.h |  4 +-
 .../Include/Library/ResetUtilityLib.h | 34 +++--
 .../BaseResetSystemLibNull.c  |  6 +--
 .../DxeResetSystemLib/DxeResetSystemLib.c |  4 +-
 .../PeiResetSystemLib/PeiResetSystemLib.c |  4 +-
 .../Library/ResetUtilityLib/ResetUtility.c| 40 +---
 .../RuntimeResetSystemLib.c   |  4 +-
 .../Universal/ResetSystemPei/ResetSystem.c|  7 +--
 .../Universal/ResetSystemPei/ResetSystem.h|  5 +-
 .../ResetSystemRuntimeDxe/ResetSystem.c   |  5 +-
 .../ResetSystemRuntimeDxe/ResetSystem.h   |  5 +-
 MdePkg/Include/Library/PeiServicesLib.h   |  6 +--
 MdePkg/Include/Pi/PiPeiCis.h  |  6 +--
 MdePkg/Include/Uefi/UefiSpec.h|  7 +--
 .../Library/PeiServicesLib/PeiServicesLib.c   |  6 +--
 .../Library/ResetSystemLib/ResetSystemLib.c   | 45 -
 .../Library/ResetSystemLib/ResetSystemLib.c   | 45 -
 .../Library/ResetSystemLib/ResetSystemLib.c   | 48 ++-
 .../Library/ResetSystemLib/ResetSystemLib.c   | 45 -
 SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c |  7 +--
 .../Library/ResetSystemLib/ResetSystemLib.c   | 45 -
 28 files changed, 488 insertions(+), 82 deletions(-)

-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39205): https://edk2.groups.io/g/devel/message/39205
Mute This Topic: https://groups.io/mt/31209219/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 18/25] OvmfPkg/ResetSystemLib: Add new API ResetSystem

[Gao, Zhichao]

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

Add a new API ResetSystem to this ResetSystemLib instance.
It only adds the basic functions from ResetSystemRuntimeDxe.
Lacking of this interface may cause link error, if some drivers
use this new API and link to this library instance.
Notes:
This library API only provide a basic function of reset. Full
function should use the instance in the MdeModulePkg and make
sure the depex driver is dispatched.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Liming Gao 
Signed-off-by: Zhichao Gao 
Reviewed-by: Laszlo Ersek 
---
 .../Library/ResetSystemLib/ResetSystemLib.c   | 45 ++-
 1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c 
b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c
index c2c7736aa8..27460cd100 100644
--- a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c
+++ b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c
@@ -1,7 +1,7 @@
 /** @file
   Reset System Library functions for OVMF
 
-  Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -140,3 +140,46 @@ ResetPlatformSpecific (
 {
   ResetCold ();
 }
+
+/**
+  The ResetSystem function resets the entire platform.
+
+  @param[in] ResetType  The type of reset to perform.
+  @param[in] ResetStatusThe status code for the reset.
+  @param[in] DataSize   The size, in bytes, of ResetData.
+  @param[in] ResetData  For a ResetType of EfiResetCold, EfiResetWarm, or 
EfiResetShutdown
+the data buffer starts with a Null-terminated 
string, optionally
+followed by additional binary data. The string is 
a description
+that the caller may use to further indicate the 
reason for the
+system reset.
+**/
+VOID
+EFIAPI
+ResetSystem (
+  IN EFI_RESET_TYPE   ResetType,
+  IN EFI_STATUS   ResetStatus,
+  IN UINTNDataSize,
+  IN VOID *ResetData OPTIONAL
+  )
+{
+  switch (ResetType) {
+  case EfiResetWarm:
+ResetWarm ();
+break;
+
+  case EfiResetCold:
+ResetCold ();
+break;
+
+  case EfiResetShutdown:
+ResetShutdown ();
+return;
+
+  case EfiResetPlatformSpecific:
+ResetPlatformSpecific (DataSize, ResetData);
+return;
+
+  default:
+return;
+  }
+}
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39223): https://edk2.groups.io/g/devel/message/39223
Mute This Topic: https://groups.io/mt/31209237/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 12/25] MdeModulePkg/ResetSystemPei: Change comments of ResetSystem2

[Gao, Zhichao]

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

Refer to Uefi spec 2.8, the ResetData is valid while ResetStatus
is EFI_SUCCESS regardless of the ResetType is EfiResetPlatformSpecific
or not.

Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ray Ni 
Cc: Star Zeng 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 
Signed-off-by: Zhichao Gao 
Reviewed-by: Hao Wu 
---
 MdeModulePkg/Universal/ResetSystemPei/ResetSystem.c | 7 ++-
 MdeModulePkg/Universal/ResetSystemPei/ResetSystem.h | 5 +
 2 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/MdeModulePkg/Universal/ResetSystemPei/ResetSystem.c 
b/MdeModulePkg/Universal/ResetSystemPei/ResetSystem.c
index 068e4e1130..ce90c86257 100644
--- a/MdeModulePkg/Universal/ResetSystemPei/ResetSystem.c
+++ b/MdeModulePkg/Universal/ResetSystemPei/ResetSystem.c
@@ -1,7 +1,7 @@
 /** @file
   Implementation of Reset2, ResetFilter and ResetHandler PPIs.
 
-  Copyright (c) 2017 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2017 - 2019, Intel Corporation. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -265,10 +265,7 @@ InitializeResetSystem (
 EfiResetShutdown the data buffer starts with a 
Null-terminated
 string, optionally followed by additional 
binary data.
 The string is a description that the caller 
may use to further
-indicate the reason for the system reset. 
ResetData is only
-valid if ResetStatus is something other than 
EFI_SUCCESS
-unless the ResetType is 
EfiResetPlatformSpecific
-where a minimum amount of ResetData is always 
required.
+indicate the reason for the system reset.
 For a ResetType of EfiResetPlatformSpecific 
the data buffer
 also starts with a Null-terminated string that 
is followed
 by an EFI_GUID that describes the specific 
type of reset to perform.
diff --git a/MdeModulePkg/Universal/ResetSystemPei/ResetSystem.h 
b/MdeModulePkg/Universal/ResetSystemPei/ResetSystem.h
index 6c96ddaa84..4d49a308af 100644
--- a/MdeModulePkg/Universal/ResetSystemPei/ResetSystem.h
+++ b/MdeModulePkg/Universal/ResetSystemPei/ResetSystem.h
@@ -58,10 +58,7 @@ typedef struct {
 EfiResetShutdown the data buffer starts with a 
Null-terminated
 string, optionally followed by additional 
binary data.
 The string is a description that the caller 
may use to further
-indicate the reason for the system reset. 
ResetData is only
-valid if ResetStatus is something other than 
EFI_SUCCESS
-unless the ResetType is 
EfiResetPlatformSpecific
-where a minimum amount of ResetData is always 
required.
+indicate the reason for the system reset.
 For a ResetType of EfiResetPlatformSpecific 
the data buffer
 also starts with a Null-terminated string that 
is followed
 by an EFI_GUID that describes the specific 
type of reset to perform.
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39217): https://edk2.groups.io/g/devel/message/39217
Mute This Topic: https://groups.io/mt/31209231/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 08/25] MdeModulePkg/BaseResetSystemLibNull.c: Change comments of ResetSystem

[Gao, Zhichao]

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

Refer to Uefi spec 2.8, the ResetData is valid while ResetStatus
is EFI_SUCCESS regardless of the ResetType is EfiResetPlatformSpecific
or not.

Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ray Ni 
Cc: Star Zeng 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 
Signed-off-by: Zhichao Gao 
Reviewed-by: Hao Wu 
---
 .../Library/BaseResetSystemLibNull/BaseResetSystemLibNull.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git 
a/MdeModulePkg/Library/BaseResetSystemLibNull/BaseResetSystemLibNull.c 
b/MdeModulePkg/Library/BaseResetSystemLibNull/BaseResetSystemLibNull.c
index 10c682afb8..8d4c1028e6 100644
--- a/MdeModulePkg/Library/BaseResetSystemLibNull/BaseResetSystemLibNull.c
+++ b/MdeModulePkg/Library/BaseResetSystemLibNull/BaseResetSystemLibNull.c
@@ -1,7 +1,7 @@
 /** @file
   Null Reset System Library instance that only generates ASSERT() conditions.
 
-  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -103,9 +103,7 @@ ResetPlatformSpecific (
 the data buffer starts with a Null-terminated 
string, optionally
 followed by additional binary data. The string is 
a description
 that the caller may use to further indicate the 
reason for the
-system reset. ResetData is only valid if 
ResetStatus is something
-other than EFI_SUCCESS unless the ResetType is 
EfiResetPlatformSpecific
-where a minimum amount of ResetData is always 
required.
+system reset.
 **/
 VOID
 EFIAPI
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39213): https://edk2.groups.io/g/devel/message/39213
Mute This Topic: https://groups.io/mt/31209227/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 11/25] MdeModulePkg/ResetSystemRuntimeDxe: Change comments

[Gao, Zhichao]

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

Refer to Uefi spec 2.8, the ResetData is valid while ResetStatus
is EFI_SUCCESS regardless of the ResetType is EfiResetPlatformSpecific
or not. So change the comments of RuntimeServiceResetSystem.

Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ray Ni 
Cc: Star Zeng 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 
Signed-off-by: Zhichao Gao 
Reviewed-by: Hao Wu 
---
 MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c | 5 +
 MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.h | 5 +
 2 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c 
b/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c
index 399104ca8e..77aedcba6e 100644
--- a/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c
+++ b/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c
@@ -210,10 +210,7 @@ InitializeResetSystem (
 EfiResetShutdown the data buffer starts with a 
Null-terminated
 string, optionally followed by additional 
binary data.
 The string is a description that the caller 
may use to further
-indicate the reason for the system reset. 
ResetData is only
-valid if ResetStatus is something other than 
EFI_SUCCESS
-unless the ResetType is 
EfiResetPlatformSpecific
-where a minimum amount of ResetData is always 
required.
+indicate the reason for the system reset.
 For a ResetType of EfiResetPlatformSpecific 
the data buffer
 also starts with a Null-terminated string that 
is followed
 by an EFI_GUID that describes the specific 
type of reset to perform.
diff --git a/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.h 
b/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.h
index 25ae5dac27..87d9c572aa 100644
--- a/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.h
+++ b/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.h
@@ -80,10 +80,7 @@ InitializeResetSystem (
 EfiResetShutdown the data buffer starts with a 
Null-terminated
 string, optionally followed by additional 
binary data.
 The string is a description that the caller 
may use to further
-indicate the reason for the system reset. 
ResetData is only
-valid if ResetStatus is something other than 
EFI_SUCCESS
-unless the ResetType is 
EfiResetPlatformSpecific
-where a minimum amount of ResetData is always 
required.
+indicate the reason for the system reset.
 For a ResetType of EfiResetPlatformSpecific 
the data buffer
 also starts with a Null-terminated string that 
is followed
 by an EFI_GUID that describes the specific 
type of reset to perform.
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39216): https://edk2.groups.io/g/devel/message/39216
Mute This Topic: https://groups.io/mt/31209230/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 09/25] MdeModulePkg/RuntimeResetSystemLib.c: Change comments

[Gao, Zhichao]

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

Refer to Uefi spec 2.8, the ResetData is valid while ResetStatus
is EFI_SUCCESS regardless of the ResetType is EfiResetPlatformSpecific
or not. So change the comments of ResetSystem.

Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ray Ni 
Cc: Star Zeng 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 
Signed-off-by: Zhichao Gao 
Reviewed-by: Hao Wu 
---
 .../Library/RuntimeResetSystemLib/RuntimeResetSystemLib.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.c 
b/MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.c
index 7074f595b7..29b3f7ebd8 100644
--- a/MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.c
+++ b/MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.c
@@ -106,9 +106,7 @@ ResetPlatformSpecific (
 the data buffer starts with a Null-terminated 
string, optionally
 followed by additional binary data. The string is 
a description
 that the caller may use to further indicate the 
reason for the
-system reset. ResetData is only valid if 
ResetStatus is something
-other than EFI_SUCCESS unless the ResetType is 
EfiResetPlatformSpecific
-where a minimum amount of ResetData is always 
required.
+system reset.
 **/
 VOID
 EFIAPI
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39214): https://edk2.groups.io/g/devel/message/39214
Mute This Topic: https://groups.io/mt/31209228/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 07/25] MdeModulePkg/DxeResetSystemLib.c: Change comments of ResetSystem

[Gao, Zhichao]

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

Refer to Uefi spec 2.8, the ResetData is valid while ResetStatus
is EFI_SUCCESS regardless of the ResetType is EfiResetPlatformSpecific
or not.

Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ray Ni 
Cc: Star Zeng 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 
Signed-off-by: Zhichao Gao 
Reviewed-by: Hao Wu 
---
 MdeModulePkg/Library/DxeResetSystemLib/DxeResetSystemLib.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/MdeModulePkg/Library/DxeResetSystemLib/DxeResetSystemLib.c 
b/MdeModulePkg/Library/DxeResetSystemLib/DxeResetSystemLib.c
index 5ca2fd4c11..a85b6cd9a6 100644
--- a/MdeModulePkg/Library/DxeResetSystemLib/DxeResetSystemLib.c
+++ b/MdeModulePkg/Library/DxeResetSystemLib/DxeResetSystemLib.c
@@ -101,9 +101,7 @@ ResetPlatformSpecific (
 the data buffer starts with a Null-terminated 
string, optionally
 followed by additional binary data. The string is 
a description
 that the caller may use to further indicate the 
reason for the
-system reset. ResetData is only valid if 
ResetStatus is something
-other than EFI_SUCCESS unless the ResetType is 
EfiResetPlatformSpecific
-where a minimum amount of ResetData is always 
required.
+system reset.
 **/
 VOID
 EFIAPI
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39212): https://edk2.groups.io/g/devel/message/39212
Mute This Topic: https://groups.io/mt/31209226/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 15/25] BeagleBoardPkg/ResetSystemLib: Add new API ResetSystem

[Gao, Zhichao]

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

Add a new API ResetSystem to this ResetSystemLib instance.
It only adds the basic functions from ResetSystemRuntimeDxe.
Lacking of this interface may cause link error, if some drivers
use this new API and link to this library instance.
Notes:
This library API only provide a basic function of reset. Full
function should use the instance in the MdeModulePkg and make
sure the depex driver is dispatched.

Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
Cc: Liming Gao 
Signed-off-by: Zhichao Gao 
Reviewed-by: Leif Lindholm 
---
 .../Library/ResetSystemLib/ResetSystemLib.c   | 44 +++
 1 file changed, 44 insertions(+)

diff --git a/BeagleBoardPkg/Library/ResetSystemLib/ResetSystemLib.c 
b/BeagleBoardPkg/Library/ResetSystemLib/ResetSystemLib.c
index 9fc572957f..f3e0201a6f 100644
--- a/BeagleBoardPkg/Library/ResetSystemLib/ResetSystemLib.c
+++ b/BeagleBoardPkg/Library/ResetSystemLib/ResetSystemLib.c
@@ -3,6 +3,7 @@
 
   Copyright (c) 2008 - 2010, Apple Inc. All rights reserved.
   Copyright (c) 2017, Linaro Ltd. All rights reserved.
+  Copyright (c) 2019, Intel Corporation. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -103,3 +104,46 @@ ResetPlatformSpecific (
 {
   ResetCold ();
 }
+
+/**
+  The ResetSystem function resets the entire platform.
+
+  @param[in] ResetType  The type of reset to perform.
+  @param[in] ResetStatusThe status code for the reset.
+  @param[in] DataSize   The size, in bytes, of ResetData.
+  @param[in] ResetData  For a ResetType of EfiResetCold, EfiResetWarm, or 
EfiResetShutdown
+the data buffer starts with a Null-terminated 
string, optionally
+followed by additional binary data. The string is 
a description
+that the caller may use to further indicate the 
reason for the
+system reset.
+**/
+VOID
+EFIAPI
+ResetSystem (
+  IN EFI_RESET_TYPE   ResetType,
+  IN EFI_STATUS   ResetStatus,
+  IN UINTNDataSize,
+  IN VOID *ResetData OPTIONAL
+  )
+{
+  switch (ResetType) {
+  case EfiResetWarm:
+ResetWarm ();
+break;
+
+  case EfiResetCold:
+ResetCold ();
+break;
+
+  case EfiResetShutdown:
+ResetShutdown ();
+return;
+
+  case EfiResetPlatformSpecific:
+ResetPlatformSpecific (DataSize, ResetData);
+return;
+
+  default:
+return;
+  }
+}
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39220): https://edk2.groups.io/g/devel/message/39220
Mute This Topic: https://groups.io/mt/31209234/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 13/25] MdeModulePkg/PeiMain: Change comments of PeiResetSystem2

[Gao, Zhichao]

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

Refer to Uefi spec 2.8, the ResetData is valid while ResetStatus
is EFI_SUCCESS regardless of the ResetType is EfiResetPlatformSpecific
or not.

Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ray Ni 
Cc: Star Zeng 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 
Signed-off-by: Zhichao Gao 
Reviewed-by: Hao Wu 
---
 MdeModulePkg/Core/Pei/PeiMain.h | 4 +---
 MdeModulePkg/Core/Pei/Reset/Reset.c | 6 ++
 2 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/MdeModulePkg/Core/Pei/PeiMain.h b/MdeModulePkg/Core/Pei/PeiMain.h
index 0aed4f4685..f2aa97c664 100644
--- a/MdeModulePkg/Core/Pei/PeiMain.h
+++ b/MdeModulePkg/Core/Pei/PeiMain.h
@@ -1097,9 +1097,7 @@ PeiResetSystem (
 the data buffer starts with a Null-terminated 
string, optionally
 followed by additional binary data. The string is 
a description
 that the caller may use to further indicate the 
reason for the
-system reset. ResetData is only valid if 
ResetStatus is something
-other than EFI_SUCCESS unless the ResetType is 
EfiResetPlatformSpecific
-where a minimum amount of ResetData is always 
required.
+system reset.
 
 **/
 VOID
diff --git a/MdeModulePkg/Core/Pei/Reset/Reset.c 
b/MdeModulePkg/Core/Pei/Reset/Reset.c
index 263eace239..0c3cfad035 100644
--- a/MdeModulePkg/Core/Pei/Reset/Reset.c
+++ b/MdeModulePkg/Core/Pei/Reset/Reset.c
@@ -1,7 +1,7 @@
 /** @file
   Pei Core Reset System Support
 
-Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -72,9 +72,7 @@ PeiResetSystem (
 the data buffer starts with a Null-terminated 
string, optionally
 followed by additional binary data. The string is 
a description
 that the caller may use to further indicate the 
reason for the
-system reset. ResetData is only valid if 
ResetStatus is something
-other than EFI_SUCCESS unless the ResetType is 
EfiResetPlatformSpecific
-where a minimum amount of ResetData is always 
required.
+system reset.
 
 **/
 VOID
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39218): https://edk2.groups.io/g/devel/message/39218
Mute This Topic: https://groups.io/mt/31209232/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 05/25] SecurityPkg/Tcg2Dxe: Change comments of ShutdownTpmOnReset

[Gao, Zhichao]

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

Refer to Uefi spec 2.8, the ResetData is valid while ResetStatus
is EFI_SUCCESS regardless of the ResetType is EfiResetPlatformSpecific
or not.

Cc: Chao Zhang 
Cc: Jiewen Yao 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 
Signed-off-by: Zhichao Gao 
---
 SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c 
b/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c
index b3e21f0947..a2729457b7 100644
--- a/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c
+++ b/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c
@@ -1,7 +1,7 @@
 /** @file
   This module implements Tcg2 Protocol.
 
-Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2019, Intel Corporation. All rights reserved.
 (C) Copyright 2016 Hewlett Packard Enterprise Development LP
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -2419,10 +2419,7 @@ OnExitBootServicesFailed (
 EfiResetShutdown the data buffer starts with a 
Null-terminated
 string, optionally followed by additional 
binary data.
 The string is a description that the caller 
may use to further
-indicate the reason for the system reset. 
ResetData is only
-valid if ResetStatus is something other than 
EFI_SUCCESS
-unless the ResetType is 
EfiResetPlatformSpecific
-where a minimum amount of ResetData is always 
required.
+indicate the reason for the system reset.
 For a ResetType of EfiResetPlatformSpecific 
the data buffer
 also starts with a Null-terminated string that 
is followed
 by an EFI_GUID that describes the specific 
type of reset to perform.
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39210): https://edk2.groups.io/g/devel/message/39210
Mute This Topic: https://groups.io/mt/31209224/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 01/25] MdePkg/UefiSpec.h: Change comments of EFI_RESET_SYSTEM

[Gao, Zhichao]

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

Refer to Uefi spec 2.8, the ResetData is valid while ResetStatus
is EFI_SUCCESS regardless of the ResetType is EfiResetPlatformSpecific
or not.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 
Signed-off-by: Zhichao Gao 
Reviewed-by: Liming Gao 
---
 MdePkg/Include/Uefi/UefiSpec.h | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/MdePkg/Include/Uefi/UefiSpec.h b/MdePkg/Include/Uefi/UefiSpec.h
index fca8df6751..44a0a6a7fa 100644
--- a/MdePkg/Include/Uefi/UefiSpec.h
+++ b/MdePkg/Include/Uefi/UefiSpec.h
@@ -5,7 +5,7 @@
   If a code construct is defined in the UEFI 2.7 specification it must be 
included
   by this include file.
 
-Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -1014,10 +1014,7 @@ EFI_STATUS
 EfiResetShutdown the data buffer starts with a 
Null-terminated
 string, optionally followed by additional 
binary data.
 The string is a description that the caller 
may use to further
-indicate the reason for the system reset. 
ResetData is only
-valid if ResetStatus is something other than 
EFI_SUCCESS
-unless the ResetType is 
EfiResetPlatformSpecific
-where a minimum amount of ResetData is always 
required.
+indicate the reason for the system reset.
 For a ResetType of EfiResetPlatformSpecific 
the data buffer
 also starts with a Null-terminated string that 
is followed
 by an EFI_GUID that describes the specific 
type of reset to perform.
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39206): https://edk2.groups.io/g/devel/message/39206
Mute This Topic: https://groups.io/mt/31209220/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 03/25] MdePkg/PeiServicesLib.h: Change comments of PeiServicesResetSystem2

[Gao, Zhichao]

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

Refer to Uefi spec 2.8, the ResetData is valid while ResetStatus
is EFI_SUCCESS regardless of the ResetType is EfiResetPlatformSpecific
or not.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 
Signed-off-by: Zhichao Gao 
Reviewed-by: Liming Gao 
---
 MdePkg/Include/Library/PeiServicesLib.h | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/MdePkg/Include/Library/PeiServicesLib.h 
b/MdePkg/Include/Library/PeiServicesLib.h
index d32347493b..5d57947101 100644
--- a/MdePkg/Include/Library/PeiServicesLib.h
+++ b/MdePkg/Include/Library/PeiServicesLib.h
@@ -1,7 +1,7 @@
 /** @file
   Provides library functions for all PEI Services.
 
-Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -544,9 +544,7 @@ PeiServicesInstallFvInfo2Ppi (
 the data buffer starts with a Null-terminated 
string, optionally
 followed by additional binary data. The string is 
a description
 that the caller may use to further indicate the 
reason for the
-system reset. ResetData is only valid if 
ResetStatus is something
-other than EFI_SUCCESS unless the ResetType is 
EfiResetPlatformSpecific
-where a minimum amount of ResetData is always 
required.
+system reset.
 
 **/
 VOID
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39208): https://edk2.groups.io/g/devel/message/39208
Mute This Topic: https://groups.io/mt/31209222/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] MdeModulePkg/UefiBootManagerLib: fix crash on uninitialized ExitData

[Ard Biesheuvel]

On Tue, 16 Apr 2019 at 23:07, Wu, Hao A  wrote:
>
> > -Original Message-
> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > Sent: Wednesday, April 17, 2019 4:30 AM
> > To: devel@edk2.groups.io
> > Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; g...@suse.com; Ard Biesheuvel
> > Subject: [PATCH] MdeModulePkg/UefiBootManagerLib: fix crash on
> > uninitialized ExitData
> >
> > As reported by Gary, the recent LoadImage/StartImage changes to
> > accommodate dispatching PE/COFF images built for foreign architectures
> > may result in a crash when loading an IA32 option ROM into a X64 VM
> > running OVMF:
> >
> >   Loading driver at 0x0007E537000 EntryPoint=0x0007E53C06D 8086100e.efi
> >   InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF
> > 7F003B98
> >   ProtectUefiImageCommon - 0x7F002BC0
> > - 0x7E537000 - 0x0009F900
> >   Image type IA32 can't be started on X64 UEFI system.
> >   ASSERT MdeModulePkg/Core/Dxe/Mem/Pool.c(698): Head->Signature ==
> > ((('p') |
> >   ('h' << 8)) | ((('d') | ('0' << 8)) << 16)) || Head->Signature
> >   == ((('p') | ('h' << 8)) | ((('d') | ('1' << 8)) << 16))
> >
> > This turns out to be caused by the deferred image loading code in BDS,
> > which doesn't check the result code of gBS->StartImage(), and ends up
> > trying to free an uninitialized pointer. So ensure ExitData is initialized
> > before the call.
> >
> > Signed-off-by: Ard Biesheuvel 
> > ---
> >  MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> > b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> > index fc8775dfa419..cf99de5b924a 100644
> > --- a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> > +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> > @@ -502,6 +502,7 @@ EfiBootManagerDispatchDeferredImages (
> >  // a 5 Minute period
> >  //
> >  gBS->SetWatchdogTimer (5 * 60, 0x, 0x00, NULL);
> > +ExitData = NULL;
> >  Status = gBS->StartImage (ImageHandle, &ExitDataSize, &ExitData);
> >  if (ExitData != NULL) {
> >FreePool (ExitData);
>
> Looks like the 'ExitData' is not being used at all here.
>
> Ray and Ard,
>
> Do you see any concern to just pass 'NULL' as the 3rd parameter
> (eliminates 'ExitData') here?
>

Yes, that would be even better, actually, I did not realize it was optional

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39204): https://edk2.groups.io/g/devel/message/39204
Mute This Topic: https://groups.io/mt/31204960/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2] [PATCH 0/6] Add new APIs for BaseCryptLib

[Wang, Jian J]

Zhichao,

Thanks for update.  Reviewed-by: Jian J Wang 

Jian

> -Original Message-
> From: Gao, Zhichao
> Sent: Wednesday, April 17, 2019 1:57 PM
> To: Gao, Zhichao ; Yao, Jiewen
> ; devel@edk2.groups.io
> Cc: Ye, Ting ; Michael Turner
> ; Bret Barkelew
> ; Gao, Liming ; Wang,
> Jian J 
> Subject: RE: [edk2] [PATCH 0/6] Add new APIs for BaseCryptLib
> 
> Resend to the groups.io.
> Testcase is update in my branch. And all unit test is passed.
> By the way, the new interface is not supported in Runtime phase.
> 
> Thanks,
> Zhichao
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Gao, Zhichao
> > Sent: Thursday, March 28, 2019 12:05 PM
> > To: Yao, Jiewen ; edk2-de...@lists.01.org
> > Cc: Ye, Ting ; Michael Turner
> > ; Bret Barkelew
> > ; Gang Wei ; Gao,
> > Liming 
> > Subject: Re: [edk2] [PATCH 0/6] Add new APIs for BaseCryptLib
> >
> > Sorry for late reply. I have write a very simple test case for these new 
> > APIs.
> > And the test result is as expected.
> > Refer to
> > https://github.com/ZhichaoGao/edk2/commit/31938b606c6a6a1fdb560e3d0
> > dd4e41a78e1d7e9
> > The section to test VerifyEKUsInPkcs7Signature is refer to
> > https://github.com/Microsoft/mu_tiano_plus/tree/release/201808/CryptoP
> > kg/UnitTests/VerifyPkcs7EkuUnitTestApp
> >
> > Thanks,
> > Zhichao
> >
> > > -Original Message-
> > > From: Yao, Jiewen
> > > Sent: Monday, March 25, 2019 4:22 PM
> > > To: Gao, Zhichao ; edk2-de...@lists.01.org
> > > Cc: Ye, Ting ; Michael Turner
> > > ; Bret Barkelew
> > > ; Gao, Liming ;
> > > Gang Wei 
> > > Subject: RE: [edk2] [PATCH 0/6] Add new APIs for BaseCryptLib
> > >
> > > Hi
> > > Would you please describe what unit test has been run for the new API ?
> > >
> > >
> > > > -Original Message-
> > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> > > > Of Zhichao Gao
> > > > Sent: Monday, March 25, 2019 12:01 PM
> > > > To: edk2-de...@lists.01.org
> > > > Cc: Ye, Ting ; Michael Turner
> > > > ; Bret Barkelew
> > > > ; Gao, Liming ;
> > > > Gang Wei 
> > > > Subject: [edk2] [PATCH 0/6] Add new APIs for BaseCryptLib
> > > >
> > > > Add new API to get organization name Add new API
> > > > VerifyEKUsInPkcs7Signature Add PKCS1v2 (RSAES-OAEP) support
> > > >
> > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > Signed-off-by: Zhichao Gao 
> > > > Cc: Ting Ye 
> > > > Cc: Gang Wei 
> > > > Cc: Wang Jian J 
> > > > Cc: Liming Gao 
> > > > Cc: Sean Brogan 
> > > > Cc: Michael Turner 
> > > > Cc: Bret Barkelew 
> > > >
> > > > Bret Barkelew (6):
> > > >   CryptoPkg/BaseCryptLib.h: Add new API to get organization name
> > > >   CryptoPkg/BaseCryptLib: Add new API to get organization name
> > > >   CryptoPkg/BaseCryptLib.h: Add new API VerifyEKUsInPkcs7Signature
> > > >   CryptoPkg/BaseCryptLib: Add new API VerifyEKUsInPkcs7Signature
> > > >   CryptoPkg/BaseCryptLib.h: Add PKCS1v2 (RSAES-OAEP) support.
> > > >   CryptoPkg/BaseCryptLib: Add PKCS1v2 (RSAES-OAEP) support.
> > > >
> > > >  CryptoPkg/Include/Library/BaseCryptLib.h   | 121 -
> > > >  CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf|   2 +
> > > >  CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf |   4 +-
> > > >  CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs1Oaep.c | 218 +
> > > >  .../Library/BaseCryptLib/Pk/CryptPkcs1OaepNull.c   |  61 +++
> > > >  .../Library/BaseCryptLib/Pk/CryptPkcs7VerifyEku.c  | 539
> > > > +
> > > >  .../BaseCryptLib/Pk/CryptPkcs7VerifyEkuRuntime.c   |  75 +++
> > > >  CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c  | 102 +++-
> > > >  CryptoPkg/Library/BaseCryptLib/Pk/CryptX509Null.c  |  32 ++
> > > >  CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf |   2 +
> > > >  CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf |   2 +
> > > >  11 files changed, 1144 insertions(+), 14 deletions(-)  create mode
> > > > 100644 CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs1Oaep.c
> > > >  create mode 100644
> > > > CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs1OaepNull.c
> > > >  create mode 100644
> > > > CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7VerifyEku.c
> > > >  create mode 100644
> > > > CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7VerifyEkuRuntime.c
> > > >
> > > > --
> > > > 2.16.2.windows.1
> > > >
> > > > ___
> > > > edk2-devel mailing list
> > > > edk2-de...@lists.01.org
> > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > ___
> > edk2-devel mailing list
> > edk2-de...@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39203): https://edk2.groups.io/g/devel/message/39203
Mute This Topic: https://groups.io/mt/31209096/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-

Re: [edk2-devel] [PATCH] MdeModulePkg/UefiBootManagerLib: fix crash on uninitialized ExitData

[Wu, Hao A]

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Wednesday, April 17, 2019 4:30 AM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; g...@suse.com; Ard Biesheuvel
> Subject: [PATCH] MdeModulePkg/UefiBootManagerLib: fix crash on
> uninitialized ExitData
> 
> As reported by Gary, the recent LoadImage/StartImage changes to
> accommodate dispatching PE/COFF images built for foreign architectures
> may result in a crash when loading an IA32 option ROM into a X64 VM
> running OVMF:
> 
>   Loading driver at 0x0007E537000 EntryPoint=0x0007E53C06D 8086100e.efi
>   InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF
> 7F003B98
>   ProtectUefiImageCommon - 0x7F002BC0
> - 0x7E537000 - 0x0009F900
>   Image type IA32 can't be started on X64 UEFI system.
>   ASSERT MdeModulePkg/Core/Dxe/Mem/Pool.c(698): Head->Signature ==
> ((('p') |
>   ('h' << 8)) | ((('d') | ('0' << 8)) << 16)) || Head->Signature
>   == ((('p') | ('h' << 8)) | ((('d') | ('1' << 8)) << 16))
> 
> This turns out to be caused by the deferred image loading code in BDS,
> which doesn't check the result code of gBS->StartImage(), and ends up
> trying to free an uninitialized pointer. So ensure ExitData is initialized
> before the call.
> 
> Signed-off-by: Ard Biesheuvel 
> ---
>  MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> index fc8775dfa419..cf99de5b924a 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> @@ -502,6 +502,7 @@ EfiBootManagerDispatchDeferredImages (
>  // a 5 Minute period
>  //
>  gBS->SetWatchdogTimer (5 * 60, 0x, 0x00, NULL);
> +ExitData = NULL;
>  Status = gBS->StartImage (ImageHandle, &ExitDataSize, &ExitData);
>  if (ExitData != NULL) {
>FreePool (ExitData);

Looks like the 'ExitData' is not being used at all here.

Ray and Ard,

Do you see any concern to just pass 'NULL' as the 3rd parameter
(eliminates 'ExitData') here?

Best Regards,
Hao Wu

> --
> 2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39202): https://edk2.groups.io/g/devel/message/39202
Mute This Topic: https://groups.io/mt/31204960/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2] [PATCH 0/6] Add new APIs for BaseCryptLib

[Gao, Zhichao]

Resend to the groups.io.
Testcase is update in my branch. And all unit test is passed. 
By the way, the new interface is not supported in Runtime phase.

Thanks,
Zhichao

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Gao, Zhichao
> Sent: Thursday, March 28, 2019 12:05 PM
> To: Yao, Jiewen ; edk2-de...@lists.01.org
> Cc: Ye, Ting ; Michael Turner
> ; Bret Barkelew
> ; Gang Wei ; Gao,
> Liming 
> Subject: Re: [edk2] [PATCH 0/6] Add new APIs for BaseCryptLib
> 
> Sorry for late reply. I have write a very simple test case for these new APIs.
> And the test result is as expected.
> Refer to
> https://github.com/ZhichaoGao/edk2/commit/31938b606c6a6a1fdb560e3d0
> dd4e41a78e1d7e9
> The section to test VerifyEKUsInPkcs7Signature is refer to
> https://github.com/Microsoft/mu_tiano_plus/tree/release/201808/CryptoP
> kg/UnitTests/VerifyPkcs7EkuUnitTestApp
> 
> Thanks,
> Zhichao
> 
> > -Original Message-
> > From: Yao, Jiewen
> > Sent: Monday, March 25, 2019 4:22 PM
> > To: Gao, Zhichao ; edk2-de...@lists.01.org
> > Cc: Ye, Ting ; Michael Turner
> > ; Bret Barkelew
> > ; Gao, Liming ;
> > Gang Wei 
> > Subject: RE: [edk2] [PATCH 0/6] Add new APIs for BaseCryptLib
> >
> > Hi
> > Would you please describe what unit test has been run for the new API ?
> >
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> > > Of Zhichao Gao
> > > Sent: Monday, March 25, 2019 12:01 PM
> > > To: edk2-de...@lists.01.org
> > > Cc: Ye, Ting ; Michael Turner
> > > ; Bret Barkelew
> > > ; Gao, Liming ;
> > > Gang Wei 
> > > Subject: [edk2] [PATCH 0/6] Add new APIs for BaseCryptLib
> > >
> > > Add new API to get organization name Add new API
> > > VerifyEKUsInPkcs7Signature Add PKCS1v2 (RSAES-OAEP) support
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Zhichao Gao 
> > > Cc: Ting Ye 
> > > Cc: Gang Wei 
> > > Cc: Wang Jian J 
> > > Cc: Liming Gao 
> > > Cc: Sean Brogan 
> > > Cc: Michael Turner 
> > > Cc: Bret Barkelew 
> > >
> > > Bret Barkelew (6):
> > >   CryptoPkg/BaseCryptLib.h: Add new API to get organization name
> > >   CryptoPkg/BaseCryptLib: Add new API to get organization name
> > >   CryptoPkg/BaseCryptLib.h: Add new API VerifyEKUsInPkcs7Signature
> > >   CryptoPkg/BaseCryptLib: Add new API VerifyEKUsInPkcs7Signature
> > >   CryptoPkg/BaseCryptLib.h: Add PKCS1v2 (RSAES-OAEP) support.
> > >   CryptoPkg/BaseCryptLib: Add PKCS1v2 (RSAES-OAEP) support.
> > >
> > >  CryptoPkg/Include/Library/BaseCryptLib.h   | 121 -
> > >  CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf|   2 +
> > >  CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf |   4 +-
> > >  CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs1Oaep.c | 218 +
> > >  .../Library/BaseCryptLib/Pk/CryptPkcs1OaepNull.c   |  61 +++
> > >  .../Library/BaseCryptLib/Pk/CryptPkcs7VerifyEku.c  | 539
> > > +
> > >  .../BaseCryptLib/Pk/CryptPkcs7VerifyEkuRuntime.c   |  75 +++
> > >  CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c  | 102 +++-
> > >  CryptoPkg/Library/BaseCryptLib/Pk/CryptX509Null.c  |  32 ++
> > >  CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf |   2 +
> > >  CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf |   2 +
> > >  11 files changed, 1144 insertions(+), 14 deletions(-)  create mode
> > > 100644 CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs1Oaep.c
> > >  create mode 100644
> > > CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs1OaepNull.c
> > >  create mode 100644
> > > CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7VerifyEku.c
> > >  create mode 100644
> > > CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7VerifyEkuRuntime.c
> > >
> > > --
> > > 2.16.2.windows.1
> > >
> > > ___
> > > edk2-devel mailing list
> > > edk2-de...@lists.01.org
> > > https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-de...@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39201): https://edk2.groups.io/g/devel/message/39201
Mute This Topic: https://groups.io/mt/31209096/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 25/25] MdeModulePkg/ResetUtilityLib: Add a new API ResetSystemWithSubtype

[Wu, Hao A]

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Gao,
> Zhichao
> Sent: Monday, April 15, 2019 11:06 AM
> To: devel@edk2.groups.io
> Cc: Bret Barkelew; Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Gao, Liming;
> Sean Brogan; Michael Turner
> Subject: [edk2-devel] [PATCH 25/25] MdeModulePkg/ResetUtilityLib: Add a new
> API ResetSystemWithSubtype
> 
> From: Bret Barkelew 
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1458
> 
> Implement the new API ResetSystemWithSubtype. Depend on Uefi Spec
> 2.8 chapter 8.5.1, the ResetData is valid while the ResetStatus
> is EFI_SUCCESS regardless of the ResetType. Also change the function
> ResetPlatofrmSpecificGuid to directly call ResetSystemWithSubtype
> to reduce the duplicated code.
> 
> Cc: Jian J Wang 
> Cc: Hao Wu 
> Cc: Ray Ni 
> Cc: Star Zeng 
> Cc: Liming Gao 
> Cc: Sean Brogan 
> Cc: Michael Turner 
> Cc: Bret Barkelew 
> Signed-off-by: Zhichao Gao 
> ---
>  .../Library/ResetUtilityLib/ResetUtility.c| 36 +++
>  1 file changed, 30 insertions(+), 6 deletions(-)
> 
> diff --git a/MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c
> b/MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c
> index 59f14edadc..45dbd2a952 100644
> --- a/MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c
> +++ b/MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c
> @@ -31,16 +31,14 @@ VERIFY_SIZE_OF
> (RESET_UTILITY_GUID_SPECIFIC_RESET_DATA, 18);
>no custom data. The subtype will be formatted in such a way that it can be
>picked up by notification registrations and custom handlers.
> 
> -  NOTE: This call will fail if the architectural ResetSystem underpinnings
> -are not initialized. For DXE, you can add gEfiResetArchProtocolGuid
> -to your DEPEX.
> -
> +  @param[in]  ResetType The default EFI_RESET_TYPE of the reset.
>@param[in]  ResetSubtype  GUID pointer for the reset subtype to be used.
> 
>  **/
>  VOID
>  EFIAPI
> -ResetPlatformSpecificGuid (
> +ResetSystemWithSubtype (
> +  IN EFI_RESET_TYPE ResetType,
>IN CONST  GUID*ResetSubtype
>)
>  {
> @@ -51,7 +49,33 @@ ResetPlatformSpecificGuid (
>  (GUID *)((UINT8 *)&ResetData + OFFSET_OF
> (RESET_UTILITY_GUID_SPECIFIC_RESET_DATA, ResetSubtype)),
>  ResetSubtype
>  );
> -  ResetPlatformSpecific (sizeof (ResetData), &ResetData);
> +
> +  ResetSystem (ResetType, EFI_SUCCESS, sizeof (ResetData), &ResetData);
> +}
> +
> +/**
> +  This is a shorthand helper function to reset with a subtype so that
> +  the caller doesn't have to bother with a function that has half a dozen
> +  parameters.
> +
> +  This will generate a reset with status EFI_SUCCESS, a NULL string, and
> +  no custom data. The subtype will be formatted in such a way that it can be
> +  picked up by notification registrations and custom handlers.
> +
> +  NOTE: This call will fail if the architectural ResetSystem underpinnings
> +are not initialized. For DXE, you can add gEfiResetArchProtocolGuid
> +to your DEPEX.
> +
> +  @param[in]  ResetSubtype  GUID pointer for the reset subtype to be used.
> +
> +**/
> +VOID
> +EFIAPI
> +ResetPlatformSpecificGuid (
> +  IN CONST  GUID*ResetSubtype
> +  )
> +{
> +  ResetSystemWithSubtype (EfiResetPlatformSpecific, ResetSubtype);
>  }

Apart from the API description comments mentioned in patch 24, the patch
seems good to me,
Reviewed-by: Hao Wu 

Best Regards,
Hao Wu

> 
>  /**
> --
> 2.21.0.windows.1
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39200): https://edk2.groups.io/g/devel/message/39200
Mute This Topic: https://groups.io/mt/31137361/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 24/25] MdeModulePkg/ResetUtilityLib: Add a new API ResetSystemWithSubtype

[Wu, Hao A]

> -Original Message-
> From: Gao, Zhichao
> Sent: Monday, April 15, 2019 11:06 AM
> To: devel@edk2.groups.io
> Cc: Bret Barkelew; Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Gao, Liming;
> Sean Brogan; Michael Turner
> Subject: [PATCH 24/25] MdeModulePkg/ResetUtilityLib: Add a new API
> ResetSystemWithSubtype
> 
> From: Bret Barkelew 
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1458
> 
> Add a new API ResetSystemWithSubtype's prototype declaration in
> header file. Also add the required data type header file.
> 
> Cc: Jian J Wang 
> Cc: Hao Wu 
> Cc: Ray Ni 
> Cc: Star Zeng 
> Cc: Liming Gao 
> Cc: Sean Brogan 
> Cc: Michael Turner 
> Cc: Bret Barkelew 
> Signed-off-by: Zhichao Gao 
> ---
>  .../Include/Library/ResetUtilityLib.h | 22 +++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/MdeModulePkg/Include/Library/ResetUtilityLib.h
> b/MdeModulePkg/Include/Library/ResetUtilityLib.h
> index ca310cdb01..9bb4adc1ad 100644
> --- a/MdeModulePkg/Include/Library/ResetUtilityLib.h
> +++ b/MdeModulePkg/Include/Library/ResetUtilityLib.h
> @@ -10,6 +10,28 @@
>  #ifndef _RESET_UTILITY_LIB_H_
>  #define _RESET_UTILITY_LIB_H_
> 
> +#include 
> +
> +/**
> +  This is a shorthand helper function to reset with a subtype so that
> +  the caller doesn't have to bother with a function that has half a dozen
> +  parameters.
> +
> +  This will generate a reset with status EFI_SUCCESS, a NULL string, and
> +  no custom data. The subtype will be formatted in such a way that it can be
> +  picked up by notification registrations and custom handlers.

I found that the function description is almost the same  with the
existing API 'ResetPlatformSpecificGuid' (except lacking the 3rd paragraph
starting with 'NOTE:', which I think should be applied to
'ResetSystemWithSubtype' as well).

Seems to me that 'ResetSystemWithSubtype' is more generic. Could you help
to refine one of their descriptions to reflect their difference?

Best Regards,
Hao Wu

> +
> +  @param[in]  ResetType The default EFI_RESET_TYPE of the reset.
> +  @param[in]  ResetSubtype  GUID pointer for the reset subtype to be used.
> +
> +**/
> +VOID
> +EFIAPI
> +ResetSystemWithSubtype (
> +  IN EFI_RESET_TYPE ResetType,
> +  IN CONST  GUID*ResetSubtype
> +  );
> +
>  /**
>This is a shorthand helper function to reset with a subtype so that
>the caller doesn't have to bother with a function that has half a dozen
> --
> 2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39199): https://edk2.groups.io/g/devel/message/39199
Mute This Topic: https://groups.io/mt/31137373/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 17/25] Nt32Pkg/ResetSystemLib: Add new API ResetSystem

[Wu, Hao A]

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Gao,
> Zhichao
> Sent: Monday, April 15, 2019 11:06 AM
> To: devel@edk2.groups.io
> Cc: Leif Lindholm; Ard Biesheuvel; Gao, Liming
> Subject: [edk2-devel] [PATCH 17/25] Nt32Pkg/ResetSystemLib: Add new API
> ResetSystem
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1460
> 
> Add a new API ResetSystem to this ResetSystemLib instance.
> It only adds the basic functions from ResetSystemRuntimeDxe.
> Lacking of this interface may cause link error, if some drivers
> use this new API and link to this library instance.
> Notes:
> This library API only provide a basic function of reset. Full
> function should use the instance in the MdeModulePkg and make
> sure the depex driver is dispatched.
> 
> Cc: Leif Lindholm 
> Cc: Ard Biesheuvel 
> Cc: Liming Gao 
> Signed-off-by: Zhichao Gao 
> ---
>  .../Library/ResetSystemLib/ResetSystemLib.c   | 43 +++
>  1 file changed, 43 insertions(+)
> 
> diff --git a/Nt32Pkg/Library/ResetSystemLib/ResetSystemLib.c
> b/Nt32Pkg/Library/ResetSystemLib/ResetSystemLib.c
> index ed4129d46b..02fa30169d 100644
> --- a/Nt32Pkg/Library/ResetSystemLib/ResetSystemLib.c
> +++ b/Nt32Pkg/Library/ResetSystemLib/ResetSystemLib.c
> @@ -90,3 +90,46 @@ ResetPlatformSpecific (
>  {
>ResetCold ();
>  }
> +
> +/**
> +  The ResetSystem function resets the entire platform.
> +
> +  @param[in] ResetType  The type of reset to perform.
> +  @param[in] ResetStatusThe status code for the reset.
> +  @param[in] DataSize   The size, in bytes, of ResetData.
> +  @param[in] ResetData  For a ResetType of EfiResetCold, EfiResetWarm,
> or EfiResetShutdown
> +the data buffer starts with a Null-terminated 
> string,
> optionally
> +followed by additional binary data. The string 
> is a description
> +that the caller may use to further indicate the 
> reason for the
> +system reset.
> +**/
> +VOID
> +EFIAPI
> +ResetSystem (
> +  IN EFI_RESET_TYPE   ResetType,
> +  IN EFI_STATUS   ResetStatus,
> +  IN UINTNDataSize,
> +  IN VOID *ResetData OPTIONAL
> +  )
> +{
> +  switch (ResetType) {
> +  case EfiResetWarm:
> +ResetWarm ();
> +break;
> +
> +  case EfiResetCold:
> +ResetCold ();
> +break;
> +
> +  case EfiResetShutdown:
> +ResetShutdown ();
> +return ;
> +
> +  case EfiResetPlatformSpecific:
> +ResetPlatformSpecific (DataSize, ResetData);
> +return;
> +
> +  default:
> +return ;

Please remove the extra space between 'return' & ';'.
With this addressed,
Reviewed-by: Hao Wu 

Best Regards,
Hao Wu

> +  }
> +}
> --
> 2.21.0.windows.1
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39198): https://edk2.groups.io/g/devel/message/39198
Mute This Topic: https://groups.io/mt/31137353/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 00/25] Add the new APIs ResetSystem and ResetSystemWithSubtype

[Wu, Hao A]

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Gao,
> Zhichao
> Sent: Monday, April 15, 2019 11:06 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D; Gao, Liming; Zhang, Chao B; Yao, Jiewen; Wang, Jian J;
> Wu, Hao A; Ni, Ray; Zeng, Star; Leif Lindholm; Ard Biesheuvel; Justen, Jordan 
> L;
> Laszlo Ersek; Steele, Kelly; Sun, Zailiang; Qian, Yi; Sean Brogan; Michael 
> Turner;
> Bret Barkelew
> Subject: [edk2-devel] [PATCH 00/25] Add the new APIs ResetSystem and
> ResetSystemWithSubtype
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1460
> Refer to Uefi spec 2.8, the ResetData is valid while ResetStatus
> is EFI_SUCCESS regardless of the ResetType is EfiResetPlatformSpecific
> or not.
> Add a new API ResetSystem to ResetSystemLib instances. The new driver may
> consume this new API and then it may cause a link error. For these library
> instances, the new API only has a basic function. If the consumers want
> the full function of this API, they should use the instance in the 
> MdeModulePkg
> and make sure the depex driver is dispatched.
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1458
> Add a new API ResetSystemWithSubtype to ResetUtilityLib
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Chao Zhang 
> Cc: Jiewen Yao 
> Cc: Jian J Wang 
> Cc: Hao Wu 
> Cc: Ray Ni 
> Cc: Star Zeng 
> Cc: Leif Lindholm 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Michael D Kinney 
> Cc: Kelly Steele 
> Cc: Zailiang Sun 
> Cc: Yi Qian 
> Cc: Sean Brogan 
> Cc: Michael Turner 
> Cc: Bret Barkelew 
> 
> Bret Barkelew (2):
>   MdeModulePkg/ResetUtilityLib: Add a new API ResetSystemWithSubtype
>   MdeModulePkg/ResetUtilityLib: Add a new API ResetSystemWithSubtype
> 
> Zhichao Gao (23):
>   MdePkg/UefiSpec.h: Change comments of EFI_RESET_SYSTEM
>   MdePkg/PiPeiCis.h: Change comments of EFI_PEI_RESET2_SYSTEM
>   MdePkg/PeiServicesLib.h: Change comments of PeiServicesResetSystem2
>   MdePkg/PeiServicesLib.c: Change comments of PeiServicesResetSystem2
>   SecurityPkg/Tcg2Dxe: Change comments of ShutdownTpmOnReset

>   MdeModulePkg/ResetSystemLib.h: Change comments of ResetSystem
>   MdeModulePkg/DxeResetSystemLib.c: Change comments of ResetSystem
>   MdeModulePkg/BaseResetSystemLibNull.c: Change comments of ResetSystem
>   MdeModulePkg/RuntimeResetSystemLib.c: Change comments
>   MdeModulePkg/PeiResetSystemlib.c: Change comments of ResetSystem
>   MdeModulePkg/ResetSystemRuntimeDxe: Change comments
>   MdeModulePkg/ResetSystemPei: Change comments of ResetSystem2
>   MdeModulePkg/PeiMain: Change comments of PeiResetSystem2
>   MdeModulePkg/NvmExpressHci.c: Change comments

For the above 9 comments update patches (patch 6~14),
Reviewed-by: Hao Wu 

Best Regards,
Hao Wu

>   BeagleBoardPkg/ResetSystemLib: Add new API ResetSystem
>   CorebootPayloadPkg/ResetSystemLib: Add new API ResetSystem
>   Nt32Pkg/ResetSystemLib: Add new API ResetSystem
>   OvmfPkg/ResetSystemLib: Add new API ResetSystem
>   PcAtChipsetPkg/ResetSystemLib: Add new API ResetSystem
>   QuarkSocPkg/ResetSystemLib: Add new API ResetSystem
>   Vlv2TbltdevicePkg/ResetSystemLib: Add new API ResetSystem
>   ArmPkg/ArmSmcPsciResetSystemLib: Add a new API ResetSystem
>   ArmVirtPkg/ArmVirtPsciResetSystemLib: Add a new API ResetSystem
> 
>  .../ArmSmcPsciResetSystemLib.c| 43 +++
>  .../ArmVirtPsciResetSystemLib.c   | 43 +++
>  .../Library/ResetSystemLib/ResetSystemLib.c   | 43 +++
>  .../Library/ResetSystemLib/ResetSystemLib.c   | 43 +++
>  .../Bus/Pci/NvmExpressDxe/NvmExpressHci.c |  5 +--
>  MdeModulePkg/Core/Pei/PeiMain.h   |  4 +-
>  MdeModulePkg/Core/Pei/Reset/Reset.c   |  4 +-
>  MdeModulePkg/Include/Library/ResetSystemLib.h |  4 +-
>  .../Include/Library/ResetUtilityLib.h | 22 ++
>  .../BaseResetSystemLibNull.c  |  4 +-
>  .../DxeResetSystemLib/DxeResetSystemLib.c |  4 +-
>  .../PeiResetSystemLib/PeiResetSystemLib.c |  4 +-
>  .../Library/ResetUtilityLib/ResetUtility.c| 36 +---
>  .../RuntimeResetSystemLib.c   |  4 +-
>  .../Universal/ResetSystemPei/ResetSystem.c|  5 +--
>  .../Universal/ResetSystemPei/ResetSystem.h|  5 +--
>  .../ResetSystemRuntimeDxe/ResetSystem.c   |  5 +--
>  .../ResetSystemRuntimeDxe/ResetSystem.h   |  5 +--
>  MdePkg/Include/Library/PeiServicesLib.h   |  4 +-
>  MdePkg/Include/Pi/PiPeiCis.h  |  4 +-
>  MdePkg/Include/Uefi/UefiSpec.h|  5 +--
>  .../Library/PeiServicesLib/PeiServicesLib.c   |  4 +-
>  .../Library/ResetSystemLib/ResetSystemLib.c   | 43 +++
>  .../Library/ResetSystemLib/ResetSystemLib.c   | 43 +++
>  .../Library/ResetSystemLib/ResetSystemLib.c   | 43 +++
>  .../Library/ResetSystemLib/ResetSystemLib.c   | 43 +++
>  SecurityPkg/Tcg

Re: [edk2-devel] [PATCH] MdeModulePkg/UefiBootManagerLib: fix crash on uninitialized ExitData

[Gary Lin]

On Tue, Apr 16, 2019 at 01:29:35PM -0700, Ard Biesheuvel wrote:
> As reported by Gary, the recent LoadImage/StartImage changes to
> accommodate dispatching PE/COFF images built for foreign architectures
> may result in a crash when loading an IA32 option ROM into a X64 VM
> running OVMF:
> 
>   Loading driver at 0x0007E537000 EntryPoint=0x0007E53C06D 8086100e.efi
>   InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 7F003B98
>   ProtectUefiImageCommon - 0x7F002BC0
> - 0x7E537000 - 0x0009F900
>   Image type IA32 can't be started on X64 UEFI system.
>   ASSERT MdeModulePkg/Core/Dxe/Mem/Pool.c(698): Head->Signature == ((('p') |
>   ('h' << 8)) | ((('d') | ('0' << 8)) << 16)) || Head->Signature
>   == ((('p') | ('h' << 8)) | ((('d') | ('1' << 8)) << 16))
> 
> This turns out to be caused by the deferred image loading code in BDS,
> which doesn't check the result code of gBS->StartImage(), and ends up
> trying to free an uninitialized pointer. So ensure ExitData is initialized
> before the call.
> 
The fix works for me.

Tested-by: Gary Lin 

> Signed-off-by: Ard Biesheuvel 
> ---
>  MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c 
> b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> index fc8775dfa419..cf99de5b924a 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> @@ -502,6 +502,7 @@ EfiBootManagerDispatchDeferredImages (
>  // a 5 Minute period
>  //
>  gBS->SetWatchdogTimer (5 * 60, 0x, 0x00, NULL);
> +ExitData = NULL;
>  Status = gBS->StartImage (ImageHandle, &ExitDataSize, &ExitData);
>  if (ExitData != NULL) {
>FreePool (ExitData);
> -- 
> 2.17.1
> 
> 
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39196): https://edk2.groups.io/g/devel/message/39196
Mute This Topic: https://groups.io/mt/31204960/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH] BaseTools:Makefiles cause data errors on some platforms

[Fan, ZhijuX]

As the Dict is unordered, an error occurs when using the Dict
while creating a new item.So for now, use OrdereDict instead
of Dict.

Cc: Bob Feng 
Cc: Liming Gao 
Signed-off-by: Zhiju.Fan 
---
 BaseTools/Source/Python/AutoGen/GenMake.py | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/GenMake.py 
b/BaseTools/Source/Python/AutoGen/GenMake.py
index 7562dc68b3..426e6ca51a 100644
--- a/BaseTools/Source/Python/AutoGen/GenMake.py
+++ b/BaseTools/Source/Python/AutoGen/GenMake.py
@@ -429,7 +429,7 @@ cleanlib:
 self.CommonFileDependency = []
 self.FileListMacros = {}
 self.ListFileMacros = {}
-self.ObjTargetDict = {}
+self.ObjTargetDict = OrderedDict()
 self.FileCache = {}
 self.LibraryBuildCommandList = []
 self.LibraryFileList = []
@@ -954,11 +954,9 @@ cleanlib:
 self.ListFileMacros[T.IncListFileMacro] = []
 if self._AutoGenObject.BuildRuleFamily == TAB_COMPILER_MSFT 
and Type == TAB_C_CODE_FILE:
 NewFile = self.PlaceMacro(str(T), self.Macros)
-if self.ObjTargetDict.get(T.Target.SubDir):
-self.ObjTargetDict[T.Target.SubDir].add(NewFile)
-else:
+if not self.ObjTargetDict.get(T.Target.SubDir):
 self.ObjTargetDict[T.Target.SubDir] = set()
-self.ObjTargetDict[T.Target.SubDir].add(NewFile)
+self.ObjTargetDict[T.Target.SubDir].add(NewFile)
 
 Deps = []
 CCodeDeps = []
-- 
2.14.1.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39195): https://edk2.groups.io/g/devel/message/39195
Mute This Topic: https://groups.io/mt/31207805/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

<>

Re: [edk2-devel] [PATCH V2 0/5] Make some DebugLib instance runtime safe

[Liming Gao]

Reviewed-by: Liming Gao 

>-Original Message-
>From: Gao, Zhichao
>Sent: Friday, April 12, 2019 8:42 AM
>To: devel@edk2.groups.io
>Cc: Yao, Jiewen ; Zhang, Chao B
>; Wang, Jian J ; Wu, Hao A
>; Ni, Ray ; Zeng, Star
>; Kinney, Michael D ;
>Gao, Liming ; Sean Brogan
>; Michael Turner
>; Bret Barkelew
>
>Subject: [PATCH V2 0/5] Make some DebugLib instance runtime safe
>
>REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1416
>
>Some pointer will be invalid after ExitBootServices, such as protocol pointer,
>gST, gBS and so on. Disable the functions which used that pointer.
>
>Remove SMM support of UefiDebugLibDebugPortProtocol,
>UefidebugLibConOut
>and UefiDebugLibStdErr.
>Before removing, should change the SMM instance in the dsc file which use
>them as SMM instance. And null version is safe.
>
>V2:
>Fix some typos.
>Change the comment of function to meet the Doxygen rule.
>
>Cc: Jiewen Yao 
>Cc: Chao Zhang 
>Cc: Jian J Wang 
>Cc: Hao Wu 
>Cc: Ray Ni 
>Cc: Star Zeng 
>Cc: Michael D Kinney 
>Cc: Liming Gao 
>Cc: Sean Brogan 
>Cc: Michael Turner 
>Cc: Bret Barkelew 
>
>Aaron Antone (3):
>  MdePkg/UefiDebugLibDebugPortProtocol: Make it runtime safe
>  MdePkg/UefidebugLibConOut: Make it runtime safe
>  MdePkg/UefiDebugLibStdErr: Make it runtime safe
>
>Zhichao Gao (2):
>  MdeModulePkg: Change the SMM debug lib instance
>  SignedCapsulePkg: Change the SMM debug lib instance
>
> MdeModulePkg/MdeModulePkg.dsc |   2 +-
> MdePkg/Library/UefiDebugLibConOut/DebugLib.c  | 116 +++---
> .../UefiDebugLibConOut/DebugLibConstructor.c  |  77 +
> .../UefiDebugLibConOut/UefiDebugLibConOut.inf |  12 +-
> .../UefiDebugLibDebugPortProtocol/DebugLib.c  | 146 +-
> .../DebugLibConstructor.c |  77 +
> .../UefiDebugLibDebugPortProtocol.inf |  12 +-
> MdePkg/Library/UefiDebugLibStdErr/DebugLib.c  | 113 +++---
> .../UefiDebugLibStdErr/DebugLibConstructor.c  |  77 +
> .../UefiDebugLibStdErr/UefiDebugLibStdErr.inf |  12 +-
> SignedCapsulePkg/SignedCapsulePkg.dsc |   4 +-
> 11 files changed, 458 insertions(+), 190 deletions(-)
> create mode 100644
>MdePkg/Library/UefiDebugLibConOut/DebugLibConstructor.c
> create mode 100644
>MdePkg/Library/UefiDebugLibDebugPortProtocol/DebugLibConstructor.c
> create mode 100644
>MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c
>
>--
>2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39194): https://edk2.groups.io/g/devel/message/39194
Mute This Topic: https://groups.io/mt/31037316/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 00/25] Add the new APIs ResetSystem and ResetSystemWithSubtype

[Liming Gao]

Zhichao:
  The change in MdePkg is good to me. Reviewed-by: Liming Gao 


>-Original Message-
>From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>Gao, Zhichao
>Sent: Monday, April 15, 2019 11:06 AM
>To: devel@edk2.groups.io
>Cc: Kinney, Michael D ; Gao, Liming
>; Zhang, Chao B ; Yao,
>Jiewen ; Wang, Jian J ; Wu,
>Hao A ; Ni, Ray ; Zeng, Star
>; Leif Lindholm ; Ard
>Biesheuvel ; Justen, Jordan L
>; Laszlo Ersek ; Steele,
>Kelly ; Sun, Zailiang ; Qian,
>Yi ; Sean Brogan ; Michael
>Turner ; Bret Barkelew
>
>Subject: [edk2-devel] [PATCH 00/25] Add the new APIs ResetSystem and
>ResetSystemWithSubtype
>
>REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1460
>Refer to Uefi spec 2.8, the ResetData is valid while ResetStatus
>is EFI_SUCCESS regardless of the ResetType is EfiResetPlatformSpecific
>or not.
>Add a new API ResetSystem to ResetSystemLib instances. The new driver may
>consume this new API and then it may cause a link error. For these library
>instances, the new API only has a basic function. If the consumers want
>the full function of this API, they should use the instance in the
>MdeModulePkg
>and make sure the depex driver is dispatched.
>
>REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1458
>Add a new API ResetSystemWithSubtype to ResetUtilityLib
>
>Cc: Michael D Kinney 
>Cc: Liming Gao 
>Cc: Chao Zhang 
>Cc: Jiewen Yao 
>Cc: Jian J Wang 
>Cc: Hao Wu 
>Cc: Ray Ni 
>Cc: Star Zeng 
>Cc: Leif Lindholm 
>Cc: Ard Biesheuvel 
>Cc: Jordan Justen 
>Cc: Laszlo Ersek 
>Cc: Michael D Kinney 
>Cc: Kelly Steele 
>Cc: Zailiang Sun 
>Cc: Yi Qian 
>Cc: Sean Brogan 
>Cc: Michael Turner 
>Cc: Bret Barkelew 
>
>Bret Barkelew (2):
>  MdeModulePkg/ResetUtilityLib: Add a new API ResetSystemWithSubtype
>  MdeModulePkg/ResetUtilityLib: Add a new API ResetSystemWithSubtype
>
>Zhichao Gao (23):
>  MdePkg/UefiSpec.h: Change comments of EFI_RESET_SYSTEM
>  MdePkg/PiPeiCis.h: Change comments of EFI_PEI_RESET2_SYSTEM
>  MdePkg/PeiServicesLib.h: Change comments of PeiServicesResetSystem2
>  MdePkg/PeiServicesLib.c: Change comments of PeiServicesResetSystem2
>  SecurityPkg/Tcg2Dxe: Change comments of ShutdownTpmOnReset
>  MdeModulePkg/ResetSystemLib.h: Change comments of ResetSystem
>  MdeModulePkg/DxeResetSystemLib.c: Change comments of ResetSystem
>  MdeModulePkg/BaseResetSystemLibNull.c: Change comments of
>ResetSystem
>  MdeModulePkg/RuntimeResetSystemLib.c: Change comments
>  MdeModulePkg/PeiResetSystemlib.c: Change comments of ResetSystem
>  MdeModulePkg/ResetSystemRuntimeDxe: Change comments
>  MdeModulePkg/ResetSystemPei: Change comments of ResetSystem2
>  MdeModulePkg/PeiMain: Change comments of PeiResetSystem2
>  MdeModulePkg/NvmExpressHci.c: Change comments
>  BeagleBoardPkg/ResetSystemLib: Add new API ResetSystem
>  CorebootPayloadPkg/ResetSystemLib: Add new API ResetSystem
>  Nt32Pkg/ResetSystemLib: Add new API ResetSystem
>  OvmfPkg/ResetSystemLib: Add new API ResetSystem
>  PcAtChipsetPkg/ResetSystemLib: Add new API ResetSystem
>  QuarkSocPkg/ResetSystemLib: Add new API ResetSystem
>  Vlv2TbltdevicePkg/ResetSystemLib: Add new API ResetSystem
>  ArmPkg/ArmSmcPsciResetSystemLib: Add a new API ResetSystem
>  ArmVirtPkg/ArmVirtPsciResetSystemLib: Add a new API ResetSystem
>
> .../ArmSmcPsciResetSystemLib.c| 43 +++
> .../ArmVirtPsciResetSystemLib.c   | 43 +++
> .../Library/ResetSystemLib/ResetSystemLib.c   | 43 +++
> .../Library/ResetSystemLib/ResetSystemLib.c   | 43 +++
> .../Bus/Pci/NvmExpressDxe/NvmExpressHci.c |  5 +--
> MdeModulePkg/Core/Pei/PeiMain.h   |  4 +-
> MdeModulePkg/Core/Pei/Reset/Reset.c   |  4 +-
> MdeModulePkg/Include/Library/ResetSystemLib.h |  4 +-
> .../Include/Library/ResetUtilityLib.h | 22 ++
> .../BaseResetSystemLibNull.c  |  4 +-
> .../DxeResetSystemLib/DxeResetSystemLib.c |  4 +-
> .../PeiResetSystemLib/PeiResetSystemLib.c |  4 +-
> .../Library/ResetUtilityLib/ResetUtility.c| 36 +---
> .../RuntimeResetSystemLib.c   |  4 +-
> .../Universal/ResetSystemPei/ResetSystem.c|  5 +--
> .../Universal/ResetSystemPei/ResetSystem.h|  5 +--
> .../ResetSystemRuntimeDxe/ResetSystem.c   |  5 +--
> .../ResetSystemRuntimeDxe/ResetSystem.h   |  5 +--
> MdePkg/Include/Library/PeiServicesLib.h   |  4 +-
> MdePkg/Include/Pi/PiPeiCis.h  |  4 +-
> MdePkg/Include/Uefi/UefiSpec.h|  5 +--
> .../Library/PeiServicesLib/PeiServicesLib.c   |  4 +-
> .../Library/ResetSystemLib/ResetSystemLib.c   | 43 +++
> .../Library/ResetSystemLib/ResetSystemLib.c   | 43 +++
> .../Library/ResetSystemLib/ResetSystemLib.c   | 43 +++
> .../Library/ResetSystemLib/ResetSystemLib.c   | 43 +++
> SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c |  5 +--
> .../Library/ResetSystemLib/ResetSystemLib.c   | 43 

Re: [edk2-devel] [edk2] [PATCH] MdeModulePkg/CapsulePei: Update the debug code to print 64bit data

[Gao, Zhichao]

Hi Phil,

Sorry I missed this email again.

When you reply to me, I get the email from the groups.io. It is not directly to 
me.
I make a folder contained all the email from groups.io. And it would receive so 
many emails and it is hard for me to view them all. So I may miss some 
important emails.
I just join the groups.io and install a Extractpatch tool to the email 
software. Did I miss something or some settings?

Thanks,
Zhichao

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Philippe Mathieu-Daudé
> Sent: Thursday, April 11, 2019 6:33 PM
> To: devel@edk2.groups.io; Gao, Zhichao ; Wu, Hao
> A 
> Cc: Bret Barkelew ; Michael Turner
> ; Gao, Liming ;
> Zeng, Star ; Wang, Jian J ;
> stephano 
> Subject: Re: [edk2-devel] [edk2] [PATCH] MdeModulePkg/CapsulePei:
> Update the debug code to print 64bit data
> 
> Hi Zhichao,
> 
> This is not a technical comment related to your patch.
> 
> I understand the migration from lists.01.org to edk2.groups.io was in part
> motivated to help developpers having a restricted email setup to easily use a
> mailing list. I see you top posting your replies so I wonder if groups.io is 
> really
> helpful to you.
> Are you missing other features that would make your list email workflow
> easier?
> 
> Thanks,
> 
> Phil.
> 
> On 4/11/19 11:33 AM, Gao, Zhichao wrote:
> > Thanks for you advices.
> >
> > I would better to keep the 'UINTN' with '%x' because PEIM is compiled as
> 32 bit object. And lots of PEIMs keep this combine.
> >
> > Thanks,
> > Zhichao
> >
> >> -Original Message-
> >> From: Wu, Hao A
> >> Sent: Thursday, April 11, 2019 4:12 PM
> >> To: Gao, Zhichao ; Philippe Mathieu-Daudé
> >> ; devel@edk2.groups.io
> >> Cc: Bret Barkelew ; Michael Turner
> >> ; Gao, Liming ;
> >> Zeng, Star ; Wang, Jian J
> >> 
> >> Subject: RE: [edk2] [PATCH] MdeModulePkg/CapsulePei: Update the
> debug
> >> code to print 64bit data
> >>
> >>> -Original Message-
> >>> From: Gao, Zhichao
> >>> Sent: Thursday, April 11, 2019 3:47 PM
> >>> To: Philippe Mathieu-Daudé; devel@edk2.groups.io
> >>> Cc: Bret Barkelew; Michael Turner; Gao, Liming; Zeng, Star; Wu, Hao
> >>> A; Wang, Jian J
> >>> Subject: RE: [edk2] [PATCH] MdeModulePkg/CapsulePei: Update the
> >> debug
> >>> code to print 64bit data
> >>>
> >>> Sorry for missing this email.
> >>>
> >>> While I change the code, it couldn't pass the Patchcher.py because
> >>> of the 'EFI_D_" version MACRO. So I change all the debug message in
> >>> this
> >> driver.
> >>> Maybe that is a redundant work.
> >>
> >> Hello Zhichao,
> >>
> >> For this case, you can work out a first patch to replace all the
> >> macros starting with 'EFI_D_' with 'DEBUG_'. And a second patch to
> address the real issue.
> >>
> >>>
> >>> Thanks,
> >>> Zhichao
> >>>
>  -Original Message-
>  From: Philippe Mathieu-Daudé [mailto:phi...@redhat.com]
>  Sent: Tuesday, April 2, 2019 11:36 PM
>  To: Gao, Zhichao ; edk2-de...@lists.01.org
>  Cc: Bret Barkelew ; Michael Turner
>  ; Gao, Liming
> ;
>  Zeng, Star 
>  Subject: Re: [edk2] [PATCH] MdeModulePkg/CapsulePei: Update the
> >>> debug
>  code to print 64bit data
> 
>  Hi Bret,
> 
>  On 4/2/19 7:50 AM, Zhichao Gao wrote:
> > From: Bret Barkelew 
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1677
> >
> > For some pointer and UINT64 data, the debug code print with '%x'.
> > Which would loss the upper 32bit data. So update '%x' to '%lx'
> > for these data.
> 
>  Some are UINTN. Per Laszlo answer on this thread:
>  https://lists.01.org/pipermail/edk2-devel/2016-
> September/002093.htm
>  l for those, casting and changing format is the accepted way.
> >>
> >> After a skim of the patch, I think there seems only 2 cases that are
> >> handled in this patch:
> >>
> >> 1. UINT64
> >> For this one, the change in this patch looks good to me.
> >>
> >> 2. Pointers
> >> I think we can directly use '%p' for pointers.
> >>
> >> If I happen to miss other cases, please do follow the above link to
> >> handle UINTN.
> >>
> >>
> >> Best Regards,
> >> Hao Wu
> >>
> 
>  However this is a change,
> 
> > Change the DEBUG PrintLevel from EFI_D_ version to DEBUG_ version.
> > DEBUG_ version is recommended to use.
> 
>  and this is another change.
> 
>  Splitting this patch in 2 would make it more digestable.
> [...]
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39192): https://edk2.groups.io/g/devel/message/39192
Mute This Topic: https://groups.io/mt/31028411/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 02/10] MdePkg/PiFirmwareFile: fix undefined behavior in SECTION_SIZE

[Andrew Fish via Groups.Io]

> On Apr 16, 2019, at 11:48 AM, Jordan Justen  wrote:
> 
> On 2019-04-16 03:59:48, Laszlo Ersek wrote:
>> On 04/16/19 11:04, Jordan Justen wrote:
>>> On 2019-04-15 09:15:31, Laszlo Ersek wrote:
 On 04/14/19 09:19, Jordan Justen wrote:
> On 2019-04-12 16:31:20, Laszlo Ersek wrote:
>> RH covscan justifiedly reports that accessing
>> "EFI_COMMON_SECTION_HEADER.Size", which is of type UINT8[3], through a
>> (UINT32*), is undefined behavior:
>> 
>>> Error: OVERRUN (CWE-119):
>>> edk2-89910a39dcfd/OvmfPkg/Sec/SecMain.c:178: overrun-local: Overrunning
>>> array of 3 bytes at byte offset 3 by dereferencing pointer
>>> "(UINT32 *)((EFI_COMMON_SECTION_HEADER *)(UINTN)Section)->Size".
>>> #  176|   Section = (EFI_COMMON_SECTION_HEADER*)(UINTN) 
>>> CurrentAddress;
>>> #  177|
>>> #  178|-> Size = SECTION_SIZE (Section);
>>> #  179|   if (Size < sizeof (*Section)) {
>>> #  180| return EFI_VOLUME_CORRUPTED;
>> 
>> Fix this by introducing EFI_COMMON_SECTION_HEADER_UNION, and expressing
>> SECTION_SIZE() in terms of "EFI_COMMON_SECTION_HEADER_UNION.Uint32".
>> 
>> Cc: Liming Gao 
>> Cc: Michael D Kinney 
>> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1710
>> Issue: scan-1007.txt
>> Signed-off-by: Laszlo Ersek 
>> ---
>> MdePkg/Include/Pi/PiFirmwareFile.h | 10 +-
>> 1 file changed, 9 insertions(+), 1 deletion(-)
>> 
>> diff --git a/MdePkg/Include/Pi/PiFirmwareFile.h 
>> b/MdePkg/Include/Pi/PiFirmwareFile.h
>> index a9f3bcc4eb8e..4fce8298d1c0 100644
>> --- a/MdePkg/Include/Pi/PiFirmwareFile.h
>> +++ b/MdePkg/Include/Pi/PiFirmwareFile.h
>> @@ -229,16 +229,24 @@ typedef struct {
>>   ///
>>   UINT8 Size[3];
>>   EFI_SECTION_TYPE  Type;
>>   ///
>>   /// Declares the section type.
>>   ///
>> } EFI_COMMON_SECTION_HEADER;
>> 
>> +///
>> +/// Union that permits accessing EFI_COMMON_SECTION_HEADER as a UINT32 
>> object.
>> +///
>> +typedef union {
>> +  EFI_COMMON_SECTION_HEADER Hdr;
>> +  UINT32Uint32;
>> +} EFI_COMMON_SECTION_HEADER_UNION;
>> +
>> typedef struct {
>>   ///
>>   /// A 24-bit unsigned integer that contains the total size of the 
>> section in bytes,
>>   /// including the EFI_COMMON_SECTION_HEADER.
>>   ///
>>   UINT8 Size[3];
>> 
>>   EFI_SECTION_TYPE  Type;
>> @@ -476,17 +484,17 @@ typedef struct {
>>   /// A UINT16 that represents a particular build. Subsequent builds 
>> have monotonically
>>   /// increasing build numbers relative to earlier builds.
>>   ///
>>   UINT16BuildNumber;
>>   CHAR16VersionString[1];
>> } EFI_VERSION_SECTION2;
>> 
>> #define SECTION_SIZE(SectionHeaderPtr) \
>> -((UINT32) (*((UINT32 *) ((EFI_COMMON_SECTION_HEADER *) (UINTN) 
>> SectionHeaderPtr)->Size) & 0x00ff))
>> +(((EFI_COMMON_SECTION_HEADER_UNION *) (UINTN) 
>> (SectionHeaderPtr))->Uint32 & 0x00ff)
> 
> Mike, all,
> 
> Can we add a typedef for EFI_COMMON_SECTION_HEADER_UNION if it's not
> in the PI spec?
> 
> If it's not allowed, I think something like this might work too:
> 
> #define SECTION_SIZE(SectionHeaderPtr) \
>(*((UINT32*)(UINTN)(SectionHeaderPtr)) & 0x00ff)
 
 (Less importantly:)
 
 It might shut up the static analyzer, but regarding the C standard, it's
 equally undefined behavior.
>>> 
>>> I think you are still accessing it through a UINT32*, since you are
>>> using a pointer to a union, and an field of type UINT32 within the
>>> union.
>> 
>> Using a union makes the behavior well-defined.
>> 
>>> 6.2.7 Compatible type and composite type
>>> 
>>> 1 Two types have compatible type if their types are the same.
>>>  Additional rules for determining whether two types are compatible
>>>  are described in [...]
>> 
>>> 6.5 Expressions
>>> 
>>> 6 The /effective type/ of an object for an access to its stored value
>>>  is the declared type of the object, if any. [...]
>>> 
>>> 7 An object shall have its stored value accessed only by an lvalue
>>>  expression that has one of the following types:
> 
> I think maybe this all applies to lvalues, not rvalues. The boon and
> bane of C is that any pointer can be easily cast to a pointer of any
> other type and then dereferenced.
> 
> If the pointer is dereferenced to a type that is larger, then I
> understand that there are cases where deferencing the pointer could
> have unintended side effects, but that is not the case here.
> 
> The dereference could also be undefined if big-endian was in the
> picture, but UEFI restricts that.
> 
> Of course none of this stops a tool from trying to delve further into
> the pointer usage to look for possible issues.
> 
> But, I don't 

[edk2-devel] [PATCH] MdeModulePkg/UefiBootManagerLib: fix crash on uninitialized ExitData

[Ard Biesheuvel]

As reported by Gary, the recent LoadImage/StartImage changes to
accommodate dispatching PE/COFF images built for foreign architectures
may result in a crash when loading an IA32 option ROM into a X64 VM
running OVMF:

  Loading driver at 0x0007E537000 EntryPoint=0x0007E53C06D 8086100e.efi
  InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 7F003B98
  ProtectUefiImageCommon - 0x7F002BC0
- 0x7E537000 - 0x0009F900
  Image type IA32 can't be started on X64 UEFI system.
  ASSERT MdeModulePkg/Core/Dxe/Mem/Pool.c(698): Head->Signature == ((('p') |
  ('h' << 8)) | ((('d') | ('0' << 8)) << 16)) || Head->Signature
  == ((('p') | ('h' << 8)) | ((('d') | ('1' << 8)) << 16))

This turns out to be caused by the deferred image loading code in BDS,
which doesn't check the result code of gBS->StartImage(), and ends up
trying to free an uninitialized pointer. So ensure ExitData is initialized
before the call.

Signed-off-by: Ard Biesheuvel 
---
 MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
index fc8775dfa419..cf99de5b924a 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
@@ -502,6 +502,7 @@ EfiBootManagerDispatchDeferredImages (
 // a 5 Minute period
 //
 gBS->SetWatchdogTimer (5 * 60, 0x, 0x00, NULL);
+ExitData = NULL;
 Status = gBS->StartImage (ImageHandle, &ExitDataSize, &ExitData);
 if (ExitData != NULL) {
   FreePool (ExitData);
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39190): https://edk2.groups.io/g/devel/message/39190
Mute This Topic: https://groups.io/mt/31204960/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH] BaseTools: Hash false success.. minor change in hash invalidation

[Christian Rodriguez]

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

Change part of the hash error handling to invalidate hashes in the
cache destination not the cache source.

Signed-off-by: Christian Rodriguez 
Cc: Bob Feng 
Cc: Liming Gao 
Cc: 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 71478b7268..7271570d29 100644
--- a/BaseTools/Source/Python/build/build.py
+++ b/BaseTools/Source/Python/build/build.py
@@ -1165,8 +1165,8 @@ class Build():
 os.remove(ModuleHashFile)
 
 # Remove .hash file from cache
-if GlobalData.gBinCacheSource:
-FileDir = path.join(GlobalData.gBinCacheSource, 
moduleAutoGenObj.Arch, moduleAutoGenObj.SourceDir, 
moduleAutoGenObj.MetaFile.BaseName)
+if GlobalData.gBinCacheDest:
+FileDir = path.join(GlobalData.gBinCacheDest, 
moduleAutoGenObj.Arch, moduleAutoGenObj.SourceDir, 
moduleAutoGenObj.MetaFile.BaseName)
 HashFile = path.join(FileDir, moduleAutoGenObj.Name + '.hash')
 if os.path.exists(HashFile):
 os.remove(HashFile)
-- 
2.19.1.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39189): https://edk2.groups.io/g/devel/message/39189
Mute This Topic: https://groups.io/mt/31204490/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms: PATCH v2 0/6] Armada7k8k misc improvements

[Ard Biesheuvel]

On Tue, 16 Apr 2019 at 02:23, Marcin Wojtas  wrote:
>
> Hi,
>
> A second version of the patchset brings one, though significant
> change. An idea of using custom DtLoaderLib for the PMU IRQ handling
> was dropped. Instead use existing PlatInitDxe. The EL3 service
> is still switched off in the ExitBootServicesEvent. However its
> execution depends on the gEdkiiPlatformHasAcpiGuid status check in the new
> gEfiEventReadyToBootGuid routine.
>
> The patches are available in the github:
> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/misc-upstream-r20190416
>
> I'm looking forward to your comments or remarks.
>
> Best regards,
> Marcin
>
> Changelog:
> v1 -> v2:
> * 3/6
>   - Use PlatInitDxe and gEfiEventReadyToBootGuid event
>
>
> Grzegorz Jaszczyk (1):
>   Marvell/Armada80x0Db: Configure the CP1, comphy-2 to work with SFI 10G
>
> Marcin Wojtas (4):
>   Marvell/Armada7k8k: AcpiTables: Enable edge trigger of PMU interrupt
>   Marvell/Armada7k8k: Switch to software-based watchdog
>   Marvell/Armada7k8k: ArmadaSoCDescLib: Add more I2C controllers
>
> Mark Kettenis (1):
>   Marvell/Armada7k8k: RealTimeClockLib: Update bus parameters
>

For the patches above

Reviewed-by: Ard Biesheuvel 

Pushed as a8cf8edf747b..df2ad607e1be

>   Marvell/Armada7k8k: Implement PMU interrupt handling

I have responded with some comments on this one



>  Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
>   |  2 +-
>  Platform/Marvell/Armada70x0Db/Armada70x0Db.dsc   
>   |  4 +-
>  Platform/Marvell/Armada80x0Db/Armada80x0Db.dsc   
>   |  4 +-
>  Silicon/Marvell/Armada7k8k/Armada7k8k.fdf
>   |  2 +-
>  Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.inf   
>   |  6 ++
>  
> Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.h
>  |  8 +-
>  Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.h   
>   |  7 +-
>  Silicon/Marvell/Include/IndustryStandard/MvSmc.h 
>   |  2 +
>  Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.c 
>   | 82 
>  
> Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.c
>  |  5 +-
>  Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.c   
>   |  5 ++
>  Silicon/Marvell/Armada7k8k/AcpiTables/Madt.aslc  
>   | 10 ++-
>  12 files changed, 123 insertions(+), 14 deletions(-)
>
> --
> 2.7.4
>

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39188): https://edk2.groups.io/g/devel/message/39188
Mute This Topic: https://groups.io/mt/31198632/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms: PATCH v2 3/6] Marvell/Armada7k8k: Implement PMU interrupt handling

[Ard Biesheuvel]

On Tue, 16 Apr 2019 at 02:23, Marcin Wojtas  wrote:
>
> Generic handling of the PMU interrupts in UEFI and Linux with
> ACPI require enabling a dedicated handler in the EL3.
> Extend the PlatInitDxe with enabler code.
>
> Because for DT world the EL3 service must remain disabled,
> switch it off in the ExitBootServicesEvent. Its execution
> depends on the gEdkiiPlatformHasAcpiGuid status check in the new
> gEfiEventReadyToBootGuid routine.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marcin Wojtas 
> ---
>  Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.inf |  6 ++
>  Silicon/Marvell/Include/IndustryStandard/MvSmc.h   |  2 +
>  Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.c   | 82 
> 
>  3 files changed, 90 insertions(+)
>
> diff --git a/Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.inf 
> b/Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.inf
> index e707fe9..df10526 100644
> --- a/Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.inf
> +++ b/Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.inf
> @@ -25,6 +25,7 @@
>PlatInitDxe.c
>
>  [Packages]
> +  ArmPkg/ArmPkg.dec
>EmbeddedPkg/EmbeddedPkg.dec
>MdeModulePkg/MdeModulePkg.dec
>MdePkg/MdePkg.dec
> @@ -32,6 +33,7 @@
>
>  [LibraryClasses]
>ArmadaIcuLib
> +  ArmSmcLib
>ComPhyLib
>DebugLib
>MppLib
> @@ -40,6 +42,10 @@
>UefiDriverEntryPoint
>UtmiPhyLib
>
> +[Guids]
> +  gEdkiiPlatformHasAcpiGuid
> +  gEfiEventReadyToBootGuid
> +
>  [Protocols]
>gMarvellPlatformInitCompleteProtocolGuid## PRODUCES
>
> diff --git a/Silicon/Marvell/Include/IndustryStandard/MvSmc.h 
> b/Silicon/Marvell/Include/IndustryStandard/MvSmc.h
> index 0c90f11..e5c89d9 100644
> --- a/Silicon/Marvell/Include/IndustryStandard/MvSmc.h
> +++ b/Silicon/Marvell/Include/IndustryStandard/MvSmc.h
> @@ -20,5 +20,7 @@
>  #define MV_SMC_ID_COMPHY_POWER_OFF0x8202
>  #define MV_SMC_ID_COMPHY_PLL_LOCK 0x8203
>  #define MV_SMC_ID_DRAM_SIZE   0x8210
> +#define MV_SMC_ID_PMU_IRQ_ENABLE  0x8212
> +#define MV_SMC_ID_PMU_IRQ_DISABLE 0x8213
>
>  #endif //__MV_SMC_H__
> diff --git a/Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.c 
> b/Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.c
> index 18b6783..4012fd7 100644
> --- a/Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.c
> +++ b/Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.c
> @@ -12,7 +12,12 @@
>
>  **/
>
> +#include 
> +
> +#include 
> +
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -21,6 +26,62 @@
>  #include 
>  #include 
>
> +STATIC EFI_EVENT mArmada7k8kExitBootServicesEvent;
> +
> +/**
> +  Disable extra EL3 handling of the PMU interrupts for DT world.
> +
> +  @param[in]   Event  Event structure
> +  @param[in]   ContextNotification context
> +
> +**/
> +STATIC
> +VOID

Please add EFIAPI here. I know it evaluates to nothing at the moment,
but since this is called via a function pointer by the DXE core, it
should have the correct prototype.

> +Armada7k8kExitBootServicesHandler (
> +  IN EFI_EVENT  Event,
> +  IN VOID  *Context
> +  )
> +{
> +  ARM_SMC_ARGS SmcRegs = {0};
> +
> +  SmcRegs.Arg0 = MV_SMC_ID_PMU_IRQ_DISABLE;
> +  ArmCallSmc (&SmcRegs);
> +
> +  return;
> +}
> +
> +/**
> +  Check if we boot with DT and trigger EBS event in such case.
> +
> +  @param[in]   Event  Event structure
> +  @param[in]   ContextNotification context
> +
> +**/
> +STATIC
> +VOID

Same here

> +Armada7k8kOnReadyToBootHandler (
> +  IN EFI_EVENT  Event,
> +  IN VOID  *Context
> +  )
> +{
> +  EFI_STATUSStatus;
> +  VOID *Interface;
> +
> +  Status = gBS->LocateProtocol (&gEdkiiPlatformHasAcpiGuid,
> +  NULL,
> +  (VOID **)&Interface);
> +  if (EFI_ERROR (Status)) {

Can we invert the logic (i.e. return early on success) with a comment
explaining why?

> +Status = gBS->CreateEvent (EVT_SIGNAL_EXIT_BOOT_SERVICES,
> +TPL_NOTIFY,
> +Armada7k8kExitBootServicesHandler,
> +NULL,
> +&mArmada7k8kExitBootServicesEvent);
> +if (EFI_ERROR (Status)) {
> +  DEBUG ((DEBUG_ERROR, "%a: Fail to register EBS event\n", 
> __FUNCTION__));
> +}

Just use ASSERT_EFI_ERROR() here - this never fails in practice.

> +  }

Please close the event - ReadyToBoot could fire multiple times and you
only want the notification once.

> +}
> +
>  EFI_STATUS
>  EFIAPI
>  ArmadaPlatInitDxeEntryPoint (
> @@ -28,7 +89,9 @@ ArmadaPlatInitDxeEntryPoint (
>IN EFI_SYSTEM_TABLE   *SystemTable
>)
>  {
> +  ARM_SMC_ARGS  SmcRegs = {0};
>EFI_STATUSStatus;
> +  EFI_EVENT Event;
>
>DEBUG ((DEBUG_ERROR, "\nArmada Platform Init\n\n"));
>
> @@ -43,5 +106,24 @@ ArmadaPlatInitDxeEntryPo

Re: [edk2-devel] [PATCH 02/10] MdePkg/PiFirmwareFile: fix undefined behavior in SECTION_SIZE

[Jordan Justen]

On 2019-04-16 03:59:48, Laszlo Ersek wrote:
> On 04/16/19 11:04, Jordan Justen wrote:
> > On 2019-04-15 09:15:31, Laszlo Ersek wrote:
> >> On 04/14/19 09:19, Jordan Justen wrote:
> >>> On 2019-04-12 16:31:20, Laszlo Ersek wrote:
>  RH covscan justifiedly reports that accessing
>  "EFI_COMMON_SECTION_HEADER.Size", which is of type UINT8[3], through a
>  (UINT32*), is undefined behavior:
> 
> > Error: OVERRUN (CWE-119):
> > edk2-89910a39dcfd/OvmfPkg/Sec/SecMain.c:178: overrun-local: Overrunning
> > array of 3 bytes at byte offset 3 by dereferencing pointer
> > "(UINT32 *)((EFI_COMMON_SECTION_HEADER *)(UINTN)Section)->Size".
> > #  176|   Section = (EFI_COMMON_SECTION_HEADER*)(UINTN) 
> > CurrentAddress;
> > #  177|
> > #  178|-> Size = SECTION_SIZE (Section);
> > #  179|   if (Size < sizeof (*Section)) {
> > #  180| return EFI_VOLUME_CORRUPTED;
> 
>  Fix this by introducing EFI_COMMON_SECTION_HEADER_UNION, and expressing
>  SECTION_SIZE() in terms of "EFI_COMMON_SECTION_HEADER_UNION.Uint32".
> 
>  Cc: Liming Gao 
>  Cc: Michael D Kinney 
>  Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1710
>  Issue: scan-1007.txt
>  Signed-off-by: Laszlo Ersek 
>  ---
>   MdePkg/Include/Pi/PiFirmwareFile.h | 10 +-
>   1 file changed, 9 insertions(+), 1 deletion(-)
> 
>  diff --git a/MdePkg/Include/Pi/PiFirmwareFile.h 
>  b/MdePkg/Include/Pi/PiFirmwareFile.h
>  index a9f3bcc4eb8e..4fce8298d1c0 100644
>  --- a/MdePkg/Include/Pi/PiFirmwareFile.h
>  +++ b/MdePkg/Include/Pi/PiFirmwareFile.h
>  @@ -229,16 +229,24 @@ typedef struct {
> ///
> UINT8 Size[3];
> EFI_SECTION_TYPE  Type;
> ///
> /// Declares the section type.
> ///
>   } EFI_COMMON_SECTION_HEADER;
> 
>  +///
>  +/// Union that permits accessing EFI_COMMON_SECTION_HEADER as a UINT32 
>  object.
>  +///
>  +typedef union {
>  +  EFI_COMMON_SECTION_HEADER Hdr;
>  +  UINT32Uint32;
>  +} EFI_COMMON_SECTION_HEADER_UNION;
>  +
>   typedef struct {
> ///
> /// A 24-bit unsigned integer that contains the total size of the 
>  section in bytes,
> /// including the EFI_COMMON_SECTION_HEADER.
> ///
> UINT8 Size[3];
> 
> EFI_SECTION_TYPE  Type;
>  @@ -476,17 +484,17 @@ typedef struct {
> /// A UINT16 that represents a particular build. Subsequent builds 
>  have monotonically
> /// increasing build numbers relative to earlier builds.
> ///
> UINT16BuildNumber;
> CHAR16VersionString[1];
>   } EFI_VERSION_SECTION2;
> 
>   #define SECTION_SIZE(SectionHeaderPtr) \
>  -((UINT32) (*((UINT32 *) ((EFI_COMMON_SECTION_HEADER *) (UINTN) 
>  SectionHeaderPtr)->Size) & 0x00ff))
>  +(((EFI_COMMON_SECTION_HEADER_UNION *) (UINTN) 
>  (SectionHeaderPtr))->Uint32 & 0x00ff)
> >>>
> >>> Mike, all,
> >>>
> >>> Can we add a typedef for EFI_COMMON_SECTION_HEADER_UNION if it's not
> >>> in the PI spec?
> >>>
> >>> If it's not allowed, I think something like this might work too:
> >>>
> >>> #define SECTION_SIZE(SectionHeaderPtr) \
> >>> (*((UINT32*)(UINTN)(SectionHeaderPtr)) & 0x00ff)
> >>
> >> (Less importantly:)
> >>
> >> It might shut up the static analyzer, but regarding the C standard, it's
> >> equally undefined behavior.
> > 
> > I think you are still accessing it through a UINT32*, since you are
> > using a pointer to a union, and an field of type UINT32 within the
> > union.
> 
> Using a union makes the behavior well-defined.
> 
> > 6.2.7 Compatible type and composite type
> >
> > 1 Two types have compatible type if their types are the same.
> >   Additional rules for determining whether two types are compatible
> >   are described in [...]
> 
> > 6.5 Expressions
> >
> > 6 The /effective type/ of an object for an access to its stored value
> >   is the declared type of the object, if any. [...]
> >
> > 7 An object shall have its stored value accessed only by an lvalue
> >   expression that has one of the following types:

I think maybe this all applies to lvalues, not rvalues. The boon and
bane of C is that any pointer can be easily cast to a pointer of any
other type and then dereferenced.

If the pointer is dereferenced to a type that is larger, then I
understand that there are cases where deferencing the pointer could
have unintended side effects, but that is not the case here.

The dereference could also be undefined if big-endian was in the
picture, but UEFI restricts that.

Of course none of this stops a tool from trying to delve further into
the pointer usage to look for possible issues.

But, I don't see how any of this changes the fact that with or without
the union, we are dereferenc

Re: [edk2-devel] Building current OVMF master with multiple workspaces on Windows/VS2017 fails due to missing includes?

[Laszlo Ersek]

On 04/16/19 16:56, Ryszard Knop wrote:
> I have a bit odd issues with building OVMF from the current master
> branch (commit 0eccea3...), with the following setup using multiple
> workspaces (this is important):
> 
> - Windows 10, 64-bit
> - Visual Studio 2017 build tools (conf'd with VS2017_PREFIX envvar)
> - NASM 2.14.02 (conf'd with NASM_PREFIX envvar)
> - Python 3.7.3 running the latest BaseTools
> - WORKSPACE envvar points at a dir with extra modules to be included
> with OVMF (C:\Env\OvmfBuild)
> - PACKAGES_PATH points at the EDK2 repo (C:\Env\Workspace\edk2)
> 
> All envvars are set before edksetup.

On Linux anyway, the above has worked for me, with two finer points:

- In $WORKSPACE, the Conf/ directory is created manually (as an empty
directory), just before sourcing edksetup.sh

- (not sure if this matters, but) the "--platform" option of "build"
refers to a standalone DSC file under $WORKSPACE, not to one of the OVMF
DSC files under $PACKAGES_PATH.

The use case for the above is different from yours though -- it's not
for building OVMF with extra modules included, but for building
standalone UEFI applications with various libraries from edk2.

... It's also possible, I guess, that the fix for
 simply forgot
about PACKAGES_PATH.

If you can provide a stripped-down reproducer (with basically "empty"
additional driver modules etc), I'd suggest packaging it all up in a zip
file, and reporting a new TianoCore BZ for BaseTools, with the zip file
attached. (The zip file is particularly helpful because it can preserve
the directory structure too, which individual BZ attachments couldn't.)

Thanks
Laszlo


> Trying to build -a X64 -p
> OvmfPkg/OvmfPkgX64.dsc -b RELEASE -t VS2017 fails with the following:
> 
> "C:\Env\BuildTools\MSVS2017_SDK_WDK_Windows10_16299\Program
> Files\Microsoft Visual
> Studio\2017\BuildTools\VC\Tools\MSVC\14.10.25017\bin\Hostx86\x64\cl.exe"
> /nologo /E /TC /FIAutoGen.h
> /IC:\Env\Workspace\edk2\MdePkg\Library\BaseLib\X64
> /IC:\Env\Workspace\edk2\MdePkg\Library\BaseLib
> /Ic:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\DEBUG
> /IC:\Env\Workspace\edk2\MdePkg /IC:\Env\Workspace\edk2\MdePkg\Include
> /IC:\Env\Workspace\edk2\MdePkg\Include\X64
> C:\Env\Workspace\edk2\MdePkg\Library\BaseLib\X64\LongJump.nasm >
> c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.i
> 
> LongJump.nasm
>     Trim --trim-long --source-code -o
> c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.iii
> c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.i
> 
>     "C:\Env\BuildTools\NASM\2.14.02\nasm"
> -IC:\Env\Workspace\edk2\MdePkg\Library\BaseLib\X64\ -Ox -f win64 -o
> c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.obj
> c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.iii
> 
> c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.iii:16:
> fatal: unable to open include file `Nasm.inc'
> NMAKE : fatal error U1077: 'C:\Env\BuildTools\NASM\2.14.02\nasm.EXE' :
> return code '0x1'
> 
> Missing Nasm.inc, which is present in MdePkg/Include/X64/Nasm.inc - but
> the weird thing is, adding extra NASM include paths was added recently
> (in BaseTools/Source/Python/AutoGen/GenMake.py there's a block that
> replaces NASM_INC with appropriate directories, build_rule.template
> should generate NASM calls with these, as of commit 7c3a1ef). After
> adding a few prints to the GenMake I can see it does find the proper
> include paths, but none of them land in the final NASM call in the
> Makefile, even though it knows about the Nasm.inc dependency - the
> NASM_INC macro seems to be completely missing from the generated Makefile:
> 
> $(OUTPUT_DIR)\X64\LongJump.obj : $(MAKE_FILE)
> $(OUTPUT_DIR)\X64\LongJump.obj :
> C:\Env\Workspace\edk2\MdePkg\Include\Base.h
> $(OUTPUT_DIR)\X64\LongJump.obj :
> C:\Env\Workspace\edk2\MdePkg\Include\X64\Nasm.inc
> $(OUTPUT_DIR)\X64\LongJump.obj : $(DEBUG_DIR)\AutoGen.h
> $(OUTPUT_DIR)\X64\LongJump.obj :
> C:\Env\Workspace\edk2\MdePkg\Include\X64\ProcessorBind.h
> $(OUTPUT_DIR)\X64\LongJump.obj :
> C:\Env\Workspace\edk2\MdePkg\Include\Library\PcdLib.h
> $(OUTPUT_DIR)\X64\LongJump.obj :
> C:\Env\Workspace\edk2\MdePkg\Library\BaseLib\X64\LongJump.nasm
>     "$(PP)" $(PP_FLAGS) $(INC)
> C:\Env\Workspace\edk2\MdePkg\Library\BaseLib\X64\LongJump.nasm >
> c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.i
> 
>     Trim --trim-long --source-code -o
> c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.iii
> c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.i

Re: [edk2-devel] [edk2-CCodingStandardsSpecification Patch] Change preferred license of EDK II to BSD+Patent

[Philippe Mathieu-Daudé]

On 4/15/19 10:57 PM, Michael D Kinney wrote:
> https://bugzilla.tianocore.org/show_bug.cgi?id=1656
> 
> Change the EDK II C Coding Standards Specification to state that
> the preferred license of the EDK II is the BSD+Patent License and
> that file headers should use SPDX license identifiers.
> 
> Cc: Andrew Fish 
> Cc: Laszlo Ersek 
> Cc: Leif Lindholm 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Michael Kinney 

Reviewed-by: Philippe Mathieu-Daude 

> ---
>  5_source_files/52_spacing.md | 23 +--
>  5_source_files/53_include_files.md   | 10 +-
>  5_source_files/54_code_file_structure.md | 10 +-
>  appendix_a_common_examples.md|  9 +
>  4 files changed, 8 insertions(+), 44 deletions(-)
> 
> diff --git a/5_source_files/52_spacing.md b/5_source_files/52_spacing.md
> index ddeabf7..012a192 100644
> --- a/5_source_files/52_spacing.md
> +++ b/5_source_files/52_spacing.md
> @@ -279,15 +279,7 @@ the preferred indentation, but two tabs (four spaces) is 
> also acceptable.
>information for a person viewing the file for the first time.
>  
>Copyright (C) --20XX, Acme Corporation. All rights reserved.
> -  This program and the accompanying materials
> -  are licensed and made available under the terms and conditions of
> -  the BSD License which accompanies this distribution. The full
> -  text of the license may be found at
> -  http://opensource.org/licenses/bsd-license.
> -
> -  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> -  BASIS, WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> -  EXPRESS OR IMPLIED.
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
>  
>@par Revision Reference:
>  - PI Version 1.0
> @@ -364,17 +356,12 @@ the location and content of the file. The correct 
> license will be determined by
>  the project leader at the time the file is created. In most cases, the 
> license
>  will be the same as for other files in the module or package.
>  
> -The majority of the files in EDK II contain the following "BSD" license.
> +The preferred license for EDK II is the "BSD+Patent" license.  The license 
> for
> +a file is provided in the file header using an SPDX identifier.  The 
> following
> +shows the SPDX identifier for the "BSD+Patent" license.
>  
>  ```
> -This program and the accompanying materials are licensed and made
> -available under the terms and conditions of the BSD License that
> -accompanies this distribution. The full text of the license may be
> -found at http://opensource.org/licenses/bsd-license.
> -
> -THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> -WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
> -IMPLIED.
> +SPDX-License-Identifier: BSD-2-Clause-Patent
>  ```
>  
>  The license will follow the copyright notice without an intervening blank 
> line.
> diff --git a/5_source_files/53_include_files.md 
> b/5_source_files/53_include_files.md
> index 890e1c7..a859b76 100644
> --- a/5_source_files/53_include_files.md
> +++ b/5_source_files/53_include_files.md
> @@ -151,15 +151,7 @@ Not all types of declarations are present in every file.
>you should probably also explain your rationale.
>  
>Copyright (c) 20XX, Acme Corporation. All rights reserved.
> -  This program and the accompanying materials
> -  are licensed and made available under the terms and conditions of
> -  the BSD License which accompanies this distribution. The full
> -  text of the license may be found at
> -  http://opensource.org/licenses/bsd-license.
> -
> -  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> -  BASIS, WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> -  EXPRESS OR IMPLIED.
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
>  
>@par Specification Reference:
>  - UEFI 2.3, Chapter 9, Device Path Protocol
> diff --git a/5_source_files/54_code_file_structure.md 
> b/5_source_files/54_code_file_structure.md
> index 8cc9f4f..caaeab9 100644
> --- a/5_source_files/54_code_file_structure.md
> +++ b/5_source_files/54_code_file_structure.md
> @@ -45,15 +45,7 @@ these are C files with an extension of "`.c`".
>you should probably also explain your rationale.
>  
>Copyright (c) 20XX, Acme Corporation. All rights reserved.
> -  This program and the accompanying materials
> -  are licensed and made available under the terms and conditions of
> -  the BSD License which accompanies this distribution. The full
> -  text of the license may be found at
> -  http://opensource.org/licenses/bsd-license.php
> -
> -  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> -  BASIS, WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> -  EXPRESS OR IMPLIED.
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
>  
>@par Specification Reference:
>  - UEFI 2.3, Chapter 9, Device Path Protocol
> diff --git a/appendix_a_common_examples.md b/appendix_a_common_examples.md
> 

Re: [edk2-devel] Remove debug strings from OVMF.fd

[Andrew Fish via Groups.Io]

Pedro,

There is an assumption that you have Link Time Optimization (LTO) turned on to 
dead strip. There are 3 PCD flags that let you control what ends up in the ROM. 
Assuming LTO you should be able to use PcdFixedDebugPrintErrorLevel to strip 
sets of strings out of the file. You can also turn all DEBUG prints off via 
PcdDebugPropertyMask.

https://github.com/tianocore/edk2/blob/master/MdePkg/MdePkg.dec


  ## This flag is used to control build time optimization based on debug print 
level.
  #  Its default value is 0x to expose all debug print level.
  #  BIT0  - Initialization message.
  #  BIT1  - Warning message.
  #  BIT2  - Load Event message.
  #  BIT3  - File System message.
  #  BIT4  - Allocate or Free Pool message.
  #  BIT5  - Allocate or Free Page message.
  #  BIT6  - Information message.
  #  BIT7  - Dispatcher message.
  #  BIT8  - Variable message.
  #  BIT10 - Boot Manager message.
  #  BIT12 - BlockIo Driver message.
  #  BIT14 - Network Driver message.
  #  BIT16 - UNDI Driver message.
  #  BIT17 - LoadFile message.
  #  BIT19 - Event message.
  #  BIT20 - Global Coherency Database changes message.
  #  BIT21 - Memory range cachability changes message.
  #  BIT22 - Detailed debug message.
  #  BIT31 - Error message.
  # @Prompt Fixed Debug Message Print Level.
  
gEfiMdePkgTokenSpaceGuid.PcdFixedDebugPrintErrorLevel|0x|UINT32|0x30001016

  ## The mask is used to control DebugLib behavior.
  #  BIT0 - Enable Debug Assert.
  #  BIT1 - Enable Debug Print.
  #  BIT2 - Enable Debug Code.
  #  BIT3 - Enable Clear Memory.
  #  BIT4 - Enable BreakPoint as ASSERT.
  #  BIT5 - Enable DeadLoop as ASSERT.
  # @Prompt Debug Property.
  # @Expression  0x8002 | (gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask & 
0xC0) == 0
  gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0|UINT8|0x0005

  ## This flag is used to control the print out Debug message.
  #  BIT0  - Initialization message.
  #  BIT1  - Warning message.
  #  BIT2  - Load Event message.
  #  BIT3  - File System message.
  #  BIT4  - Allocate or Free Pool message.
  #  BIT5  - Allocate or Free Page message.
  #  BIT6  - Information message.
  #  BIT7  - Dispatcher message.
  #  BIT8  - Variable message.
  #  BIT10 - Boot Manager message.
  #  BIT12 - BlockIo Driver message.
  #  BIT14 - Network Driver message.
  #  BIT16 - UNDI Driver message.
  #  BIT17 - LoadFile message.
  #  BIT19 - Event message.
  #  BIT20 - Global Coherency Database changes message.
  #  BIT21 - Memory range cachability changes message.
  #  BIT22 - Detailed debug message.
  #  BIT31 - Error message.
  # @Prompt Debug Message Print Level.
  # @Expression  0x8002 | (gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel 
& 0x7F84AA00) == 0
  gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x8000|UINT32|0x0006

Thanks,

Andrew Fish

> On Apr 16, 2019, at 8:46 AM, Pedro Barbosa  wrote:
> 
> Hi EDK2 developers,
> 
> I'm trying to build OVMF without debug symbols but even building as RELEASE, 
> I still can see some strings on the PE files, such as:
> /Build/OvmfX64/RELEASE_GCC5/X64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.dll
> and many others in the format */DEBUG/*.dll
> 
> Is there a way to build without these strings?
> 
> Thanks!
> 
> -- 
> []s
> 
> Pedro Yóssis Silva Barbosa
> Security Engineer, Google
> PhD in Computer Science, UFCG, Brazil
> sites.google.com/site/pedroysb 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39183): https://edk2.groups.io/g/devel/message/39183
Mute This Topic: https://groups.io/mt/31202062/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 02/10] MdePkg/PiFirmwareFile: fix undefined behavior in SECTION_SIZE

[Philippe Mathieu-Daudé]

Hi Laszlo,

On 4/16/19 12:59 PM, Laszlo Ersek wrote:
> On 04/16/19 11:04, Jordan Justen wrote:
>> On 2019-04-15 09:15:31, Laszlo Ersek wrote:
>>> On 04/14/19 09:19, Jordan Justen wrote:
 On 2019-04-12 16:31:20, Laszlo Ersek wrote:
> RH covscan justifiedly reports that accessing
> "EFI_COMMON_SECTION_HEADER.Size", which is of type UINT8[3], through a
> (UINT32*), is undefined behavior:
>
>> Error: OVERRUN (CWE-119):
>> edk2-89910a39dcfd/OvmfPkg/Sec/SecMain.c:178: overrun-local: Overrunning
>> array of 3 bytes at byte offset 3 by dereferencing pointer
>> "(UINT32 *)((EFI_COMMON_SECTION_HEADER *)(UINTN)Section)->Size".
>> #  176|   Section = (EFI_COMMON_SECTION_HEADER*)(UINTN) 
>> CurrentAddress;
>> #  177|
>> #  178|-> Size = SECTION_SIZE (Section);
>> #  179|   if (Size < sizeof (*Section)) {
>> #  180| return EFI_VOLUME_CORRUPTED;
>
> Fix this by introducing EFI_COMMON_SECTION_HEADER_UNION, and expressing
> SECTION_SIZE() in terms of "EFI_COMMON_SECTION_HEADER_UNION.Uint32".
>
> Cc: Liming Gao 
> Cc: Michael D Kinney 
> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1710
> Issue: scan-1007.txt
> Signed-off-by: Laszlo Ersek 
> ---
>  MdePkg/Include/Pi/PiFirmwareFile.h | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/MdePkg/Include/Pi/PiFirmwareFile.h 
> b/MdePkg/Include/Pi/PiFirmwareFile.h
> index a9f3bcc4eb8e..4fce8298d1c0 100644
> --- a/MdePkg/Include/Pi/PiFirmwareFile.h
> +++ b/MdePkg/Include/Pi/PiFirmwareFile.h
> @@ -229,16 +229,24 @@ typedef struct {
>///
>UINT8 Size[3];
>EFI_SECTION_TYPE  Type;
>///
>/// Declares the section type.
>///
>  } EFI_COMMON_SECTION_HEADER;
>  
> +///
> +/// Union that permits accessing EFI_COMMON_SECTION_HEADER as a UINT32 
> object.
> +///
> +typedef union {
> +  EFI_COMMON_SECTION_HEADER Hdr;
> +  UINT32Uint32;
> +} EFI_COMMON_SECTION_HEADER_UNION;
> +
>  typedef struct {
>///
>/// A 24-bit unsigned integer that contains the total size of the 
> section in bytes,
>/// including the EFI_COMMON_SECTION_HEADER.
>///
>UINT8 Size[3];
>  
>EFI_SECTION_TYPE  Type;
> @@ -476,17 +484,17 @@ typedef struct {
>/// A UINT16 that represents a particular build. Subsequent builds 
> have monotonically
>/// increasing build numbers relative to earlier builds.
>///
>UINT16BuildNumber;
>CHAR16VersionString[1];
>  } EFI_VERSION_SECTION2;
>  
>  #define SECTION_SIZE(SectionHeaderPtr) \
> -((UINT32) (*((UINT32 *) ((EFI_COMMON_SECTION_HEADER *) (UINTN) 
> SectionHeaderPtr)->Size) & 0x00ff))
> +(((EFI_COMMON_SECTION_HEADER_UNION *) (UINTN) 
> (SectionHeaderPtr))->Uint32 & 0x00ff)

 Mike, all,

 Can we add a typedef for EFI_COMMON_SECTION_HEADER_UNION if it's not
 in the PI spec?

 If it's not allowed, I think something like this might work too:

 #define SECTION_SIZE(SectionHeaderPtr) \
 (*((UINT32*)(UINTN)(SectionHeaderPtr)) & 0x00ff)
>>>
>>> (Less importantly:)
>>>
>>> It might shut up the static analyzer, but regarding the C standard, it's
>>> equally undefined behavior.
>>
>> I think you are still accessing it through a UINT32*, since you are
>> using a pointer to a union, and an field of type UINT32 within the
>> union.
> 
> Using a union makes the behavior well-defined.
> 
>> 6.2.7 Compatible type and composite type
>>
>> 1 Two types have compatible type if their types are the same.
>>   Additional rules for determining whether two types are compatible
>>   are described in [...]
> 
>> 6.5 Expressions
>>
>> 6 The /effective type/ of an object for an access to its stored value
>>   is the declared type of the object, if any. [...]
>>
>> 7 An object shall have its stored value accessed only by an lvalue
>>   expression that has one of the following types:
>>
>>   — a type compatible with the effective type of the object,
>>   — a qualified version of a type compatible with the effective type
>> of the object,
>>   — a type that is the signed or unsigned type corresponding to the
>> effective type of the object,
>>   — a type that is the signed or unsigned type corresponding to a
>> qualified version of the effective type of the object,
>>   — an aggregate or union type that includes one of the aforementioned
>> types among its members (including, recursively, a member of a
>> subaggregate or contained union), or
>>   — a character type.
> 
> - Regarding 6.5p6, the original object we intend to access has
> (declared) type EFI_COMMON_SECTION_HEADER. Therefore the effective type
> is EFI_COMMON_SECTION

Re: [edk2-devel] Remove debug strings from OVMF.fd

[Laszlo Ersek]

On 04/16/19 17:46, Pedro Barbosa wrote:
> Hi EDK2 developers,
> 
> I'm trying to build OVMF without debug symbols but even building as
> RELEASE, I still can see some strings on the PE files, such as:
> /Build/OvmfX64/RELEASE_GCC5/X64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.dll
> and many others in the format */DEBUG/*.dll
> 
> Is there a way to build without these strings?
> 
> Thanks!
> 

Do you see such strings in "UiApp.efi" too? (When built for RELEASE.)
"UiApp.dll" is an intermediate build product.

Thanks,
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39181): https://edk2.groups.io/g/devel/message/39181
Mute This Topic: https://groups.io/mt/31202062/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2] BaseTools: Remove the unnecessary copy action for module output files

[Ni, Ray]

Liming,
Is there a place or maybe a spec to summarize the build output file location?
Platform may have script to reference some of the output files.
Have a clear documentation from now on if there is not could be great to avoid
future build breakage due to missing some of output files.

Thanks,
Ray

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Liming Gao
> Sent: Tuesday, April 16, 2019 1:11 AM
> To: devel@edk2.groups.io
> Cc: Feng, Bob C 
> Subject: [edk2-devel] [PATCH v2] BaseTools: Remove the unnecessary copy
> action for module output files
> 
> BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1673
> 
> In v2, keep copy output image into $(BIN_DIR), the platform still uses
> the output file in $(BIN_DIR).
> 
> Signed-off-by: Liming Gao 
> Cc: Bob Feng 
> ---
>  BaseTools/Conf/build_rule.template | 17 ++---
>  1 file changed, 2 insertions(+), 15 deletions(-)
> 
> diff --git a/BaseTools/Conf/build_rule.template
> b/BaseTools/Conf/build_rule.template
> index 030e74c35a..dbb68c62fb 100755
> --- a/BaseTools/Conf/build_rule.template
> +++ b/BaseTools/Conf/build_rule.template
> @@ -357,34 +357,21 @@
> 
>  
>  "$(GENFW)" -e $(MODULE_TYPE) -o ${dst} ${src} $(GENFW_FLAGS)
> -$(CP) ${dst} $(DEBUG_DIR)
>  $(CP) ${dst} $(BIN_DIR)(+)$(MODULE_NAME_GUID).efi
> --$(CP) $(DEBUG_DIR)(+)*.map $(OUTPUT_DIR)
> --$(CP) $(DEBUG_DIR)(+)*.pdb $(OUTPUT_DIR)
> +
>  
>  $(CP) ${src} $(DEBUG_DIR)(+)$(MODULE_NAME).debug
>  $(OBJCOPY) --strip-unneeded -R .eh_frame ${src}
> -
> -#
> -#The below 2 lines are only needed for UNIXGCC tool chain, which
> generates PE image directly
> -#
> --$(OBJCOPY) $(OBJCOPY_ADDDEBUGFLAG) ${src}
> --$(CP) $(DEBUG_DIR)(+)$(MODULE_NAME).debug
> $(BIN_DIR)(+)$(MODULE_NAME_GUID).debug
> -
>  "$(GENFW)" -e $(MODULE_TYPE) -o ${dst} ${src} $(GENFW_FLAGS)
> -$(CP) ${dst} $(DEBUG_DIR)
>  $(CP) ${dst} $(BIN_DIR)(+)$(MODULE_NAME_GUID).efi
> --$(CP) $(DEBUG_DIR)(+)*.map $(OUTPUT_DIR)
> -
> +
>  
>  # tool to convert Mach-O to PE/COFF
>  "$(MTOC)" -subsystem $(MODULE_TYPE)  $(MTOC_FLAGS)  ${src}
> $(DEBUG_DIR)(+)$(MODULE_NAME).pecoff
>  # create symbol file for GDB debug
>  -$(DSYMUTIL) ${src}
>  "$(GENFW)" -e $(MODULE_TYPE) -o ${dst}
> $(DEBUG_DIR)(+)$(MODULE_NAME).pecoff $(GENFW_FLAGS)
> -$(CP) ${dst} $(DEBUG_DIR)
>  $(CP) ${dst} $(BIN_DIR)(+)$(MODULE_NAME_GUID).efi
> --$(CP) $(DEBUG_DIR)(+)*.map $(OUTPUT_DIR)
> 
>  [Dependency-Expression-File]
>  
> --
> 2.13.0.windows.1
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39180): https://edk2.groups.io/g/devel/message/39180
Mute This Topic: https://groups.io/mt/31198263/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v6 3/7] MdeModulePkg/PciBusDxe: dispatch option ROMs for foreign architectures

[Ard Biesheuvel]

On Mon, 15 Apr 2019 at 23:02, Gary Lin  wrote:
>
> On Sun, Apr 14, 2019 at 12:52:29PM -0700, Ard Biesheuvel wrote:
> > Delete the explicit machine type check for option ROM images, and instead,
> > rely on the LoadImage() boot service to decide whether an option ROM can
> > be dispatched or not. This permits platforms to ship with emulators to
> > execute option ROMs that are not native to the processor architecture.
> >
> After applying this patch, my OVMF VM failed to boot if e1000 or iPXE
> were enabled. It failed with the following message:
>
> Loading driver at 0x0007E537000 EntryPoint=0x0007E53C06D 8086100e.efi
> InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 7F003B98
> ProtectUefiImageCommon - 0x7F002BC0
>   - 0x7E537000 - 0x0009F900
> Image type IA32 can't be started on X64 UEFI system.
> ASSERT MdeModulePkg/Core/Dxe/Mem/Pool.c(698): Head->Signature == ((('p') | 
> ('h' << 8)) | ((('d') | ('0' << 8)) << 16)) || Head->Signature == ((('p') | 
> ('h' << 8)) | ((('d') | ('1' << 8)) << 16))
>
> It seems OVMF was trying to load the IA32 driver and failed.
>

Thanks Gary, I am looking into this.

It should fail gracefully after failing to start the image, but
perhaps we should not attempt to start cross-type images in the first
place (which is closer to the previous situation)

-- 
Ard.

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39179): https://edk2.groups.io/g/devel/message/39179
Mute This Topic: https://groups.io/mt/31133142/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Staging/Bug_1525_FmpDevicePkg_MultipleControllers][PATCH] MdeModulePkg/EsrtFmpDxe: Correct the LastAttemptVersion algorithm in ESRT entry

[Michael D Kinney]

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: Jin, Eric
> Sent: Monday, April 15, 2019 8:02 PM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D 
> Subject:
> [Staging/Bug_1525_FmpDevicePkg_MultipleControllers][PAT
> CH] MdeModulePkg/EsrtFmpDxe: Correct the
> LastAttemptVersion algorithm in ESRT entry
> 
> Fix the 1nd issue mentioned in
> https://bugzilla.tianocore.org/show_bug.cgi?id=1525
> 
> Update the ESRT entry with the last attempt status and
> last attempt
> version from the first FMP instance whose last attempt
> status is not
> SUCCESS. If all FMP instances are SUCCESS, then set
> last attempt version
> to the smallest value from all FMP instances
> 
> CC: Michael D Kinney 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Jin 
> ---
>  MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c | 14
> --
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git
> a/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c
> b/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c
> index bd92d1da40..848bd44e9d 100644
> --- a/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c
> +++ b/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c
> @@ -196,20 +196,22 @@ CreateEsrtEntry (
>// VERSION 3 supports last attempt values
>//
>if (FmpVersion >= 3) {
> -Entry->LastAttemptVersion =
> -  MIN (
> -FmpImageInfoBuf->LastAttemptVersion,
> -Entry->LastAttemptVersion
> -);
>  //
>  // Update the ESRT entry with the last attempt
> status and last attempt
>  // version from the first FMP instance whose
> last attempt status is not
> -// SUCCESS.
> +// SUCCESS.  If all FMP instances are SUCCESS,
> then set version to the
> +// smallest value from all FMP instances.
>  //
>  if (Entry->LastAttemptStatus ==
> LAST_ATTEMPT_STATUS_SUCCESS) {
>if (FmpImageInfoBuf->LastAttemptStatus !=
> LAST_ATTEMPT_STATUS_SUCCESS) {
>  Entry->LastAttemptStatus =
> FmpImageInfoBuf->LastAttemptStatus;
>  Entry->LastAttemptVersion =
> FmpImageInfoBuf->LastAttemptVersion;
> +  } else {
> +Entry->LastAttemptVersion =
> +  MIN (
> +FmpImageInfoBuf->LastAttemptVersion,
> +Entry->LastAttemptVersion
> +);
>}
>  }
>}
> --
> 2.20.1.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39178): https://edk2.groups.io/g/devel/message/39178
Mute This Topic: https://groups.io/mt/31196314/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] Remove debug strings from OVMF.fd

[Pedro Barbosa]

Hi EDK2 developers,

I'm trying to build OVMF without debug symbols but even building as
RELEASE, I still can see some strings on the PE files, such as:
/Build/OvmfX64/RELEASE_GCC5/X64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.dll
and many others in the format */DEBUG/*.dll

Is there a way to build without these strings?

Thanks!

-- 
[]s

Pedro Yóssis Silva Barbosa
Security Engineer, Google
PhD in Computer Science, UFCG, Brazil
sites.google.com/site/pedroysb

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39177): https://edk2.groups.io/g/devel/message/39177
Mute This Topic: https://groups.io/mt/31202062/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] Building current OVMF master with multiple workspaces on Windows/VS2017 fails due to missing includes?

[Ryszard Knop]

I have a bit odd issues with building OVMF from the current master 
branch (commit 0eccea3...), with the following setup using multiple 
workspaces (this is important):


- Windows 10, 64-bit
- Visual Studio 2017 build tools (conf'd with VS2017_PREFIX envvar)
- NASM 2.14.02 (conf'd with NASM_PREFIX envvar)
- Python 3.7.3 running the latest BaseTools
- WORKSPACE envvar points at a dir with extra modules to be included 
with OVMF (C:\Env\OvmfBuild)

- PACKAGES_PATH points at the EDK2 repo (C:\Env\Workspace\edk2)

All envvars are set before edksetup. Trying to build -a X64 -p 
OvmfPkg/OvmfPkgX64.dsc -b RELEASE -t VS2017 fails with the following:


"C:\Env\BuildTools\MSVS2017_SDK_WDK_Windows10_16299\Program 
Files\Microsoft Visual 
Studio\2017\BuildTools\VC\Tools\MSVC\14.10.25017\bin\Hostx86\x64\cl.exe" 
/nologo /E /TC /FIAutoGen.h 
/IC:\Env\Workspace\edk2\MdePkg\Library\BaseLib\X64 
/IC:\Env\Workspace\edk2\MdePkg\Library\BaseLib 
/Ic:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\DEBUG 
/IC:\Env\Workspace\edk2\MdePkg /IC:\Env\Workspace\edk2\MdePkg\Include 
/IC:\Env\Workspace\edk2\MdePkg\Include\X64 
C:\Env\Workspace\edk2\MdePkg\Library\BaseLib\X64\LongJump.nasm > 
c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.i

LongJump.nasm
    Trim --trim-long --source-code -o 
c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.iii 
c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.i
    "C:\Env\BuildTools\NASM\2.14.02\nasm" 
-IC:\Env\Workspace\edk2\MdePkg\Library\BaseLib\X64\ -Ox -f win64 -o 
c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.obj 
c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.iii
c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.iii:16: 
fatal: unable to open include file `Nasm.inc'
NMAKE : fatal error U1077: 'C:\Env\BuildTools\NASM\2.14.02\nasm.EXE' : 
return code '0x1'


Missing Nasm.inc, which is present in MdePkg/Include/X64/Nasm.inc - but 
the weird thing is, adding extra NASM include paths was added recently 
(in BaseTools/Source/Python/AutoGen/GenMake.py there's a block that 
replaces NASM_INC with appropriate directories, build_rule.template 
should generate NASM calls with these, as of commit 7c3a1ef). After 
adding a few prints to the GenMake I can see it does find the proper 
include paths, but none of them land in the final NASM call in the 
Makefile, even though it knows about the Nasm.inc dependency - the 
NASM_INC macro seems to be completely missing from the generated Makefile:


$(OUTPUT_DIR)\X64\LongJump.obj : $(MAKE_FILE)
$(OUTPUT_DIR)\X64\LongJump.obj : C:\Env\Workspace\edk2\MdePkg\Include\Base.h
$(OUTPUT_DIR)\X64\LongJump.obj : 
C:\Env\Workspace\edk2\MdePkg\Include\X64\Nasm.inc

$(OUTPUT_DIR)\X64\LongJump.obj : $(DEBUG_DIR)\AutoGen.h
$(OUTPUT_DIR)\X64\LongJump.obj : 
C:\Env\Workspace\edk2\MdePkg\Include\X64\ProcessorBind.h
$(OUTPUT_DIR)\X64\LongJump.obj : 
C:\Env\Workspace\edk2\MdePkg\Include\Library\PcdLib.h
$(OUTPUT_DIR)\X64\LongJump.obj : 
C:\Env\Workspace\edk2\MdePkg\Library\BaseLib\X64\LongJump.nasm
    "$(PP)" $(PP_FLAGS) $(INC) 
C:\Env\Workspace\edk2\MdePkg\Library\BaseLib\X64\LongJump.nasm > 
c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.i
    Trim --trim-long --source-code -o 
c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.iii 
c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.i
    "$(NASM)" -IC:\Env\Workspace\edk2\MdePkg\Library\BaseLib\X64\ 
$(NASM_FLAGS) -o 
c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.obj 
c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.iii


The nasty workaround is to copy Nasm.inc into MdePkg/Library/BaseLib/X64 
and everything builds just fine after that.


Another interesting thing is that if I don't use WORKSPACE and 
PACKAGES_PATH (both contain no spaces and are on local file systems) but 
rather build everything directly in the EDK2 directory, OVMF also builds 
fine (Makefile contains the NASM_INC definition which is included in 
NASM calls). Have anyone also hit this issue?


Thanks, Richard


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39176): https://edk2.groups.io/g/devel/message/39176
Mute This Topic: https://groups.io/mt/31201466/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-CCodingStandardsSpecification Patch] Change preferred license of EDK II to BSD+Patent

[Laszlo Ersek]

On 04/15/19 22:57, Michael D Kinney wrote:
> https://bugzilla.tianocore.org/show_bug.cgi?id=1656
> 
> Change the EDK II C Coding Standards Specification to state that
> the preferred license of the EDK II is the BSD+Patent License and
> that file headers should use SPDX license identifiers.
> 
> Cc: Andrew Fish 
> Cc: Laszlo Ersek 
> Cc: Leif Lindholm 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Michael Kinney 
> ---
>  5_source_files/52_spacing.md | 23 +--
>  5_source_files/53_include_files.md   | 10 +-
>  5_source_files/54_code_file_structure.md | 10 +-
>  appendix_a_common_examples.md|  9 +
>  4 files changed, 8 insertions(+), 44 deletions(-)
> 
> diff --git a/5_source_files/52_spacing.md b/5_source_files/52_spacing.md
> index ddeabf7..012a192 100644
> --- a/5_source_files/52_spacing.md
> +++ b/5_source_files/52_spacing.md
> @@ -279,15 +279,7 @@ the preferred indentation, but two tabs (four spaces) is 
> also acceptable.
>information for a person viewing the file for the first time.
>
>Copyright (C) --20XX, Acme Corporation. All rights reserved.
> -  This program and the accompanying materials
> -  are licensed and made available under the terms and conditions of
> -  the BSD License which accompanies this distribution. The full
> -  text of the license may be found at
> -  http://opensource.org/licenses/bsd-license.
> -
> -  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> -  BASIS, WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> -  EXPRESS OR IMPLIED.
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
>
>@par Revision Reference:
>  - PI Version 1.0
> @@ -364,17 +356,12 @@ the location and content of the file. The correct 
> license will be determined by
>  the project leader at the time the file is created. In most cases, the 
> license
>  will be the same as for other files in the module or package.
>
> -The majority of the files in EDK II contain the following "BSD" license.
> +The preferred license for EDK II is the "BSD+Patent" license.  The license 
> for
> +a file is provided in the file header using an SPDX identifier.  The 
> following
> +shows the SPDX identifier for the "BSD+Patent" license.
>
>  ```
> -This program and the accompanying materials are licensed and made
> -available under the terms and conditions of the BSD License that
> -accompanies this distribution. The full text of the license may be
> -found at http://opensource.org/licenses/bsd-license.
> -
> -THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> -WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
> -IMPLIED.
> +SPDX-License-Identifier: BSD-2-Clause-Patent
>  ```
>
>  The license will follow the copyright notice without an intervening blank 
> line.

All of the above looks good, but this context line ("The license will
follow the copyright notice without an intervening blank line.") catches
my eye. I don't think we conform to that requirement (nor that we did
before the conversion to SPDIX/BSD+Patent).

Should we drop this line? Perhaps in a separate patch?

Anyway, for this patch:

Reviewed-by: Laszlo Ersek 

Thanks
Laszlo

> diff --git a/5_source_files/53_include_files.md 
> b/5_source_files/53_include_files.md
> index 890e1c7..a859b76 100644
> --- a/5_source_files/53_include_files.md
> +++ b/5_source_files/53_include_files.md
> @@ -151,15 +151,7 @@ Not all types of declarations are present in every file.
>you should probably also explain your rationale.
>
>Copyright (c) 20XX, Acme Corporation. All rights reserved.
> -  This program and the accompanying materials
> -  are licensed and made available under the terms and conditions of
> -  the BSD License which accompanies this distribution. The full
> -  text of the license may be found at
> -  http://opensource.org/licenses/bsd-license.
> -
> -  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> -  BASIS, WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> -  EXPRESS OR IMPLIED.
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
>
>@par Specification Reference:
>  - UEFI 2.3, Chapter 9, Device Path Protocol
> diff --git a/5_source_files/54_code_file_structure.md 
> b/5_source_files/54_code_file_structure.md
> index 8cc9f4f..caaeab9 100644
> --- a/5_source_files/54_code_file_structure.md
> +++ b/5_source_files/54_code_file_structure.md
> @@ -45,15 +45,7 @@ these are C files with an extension of "`.c`".
>you should probably also explain your rationale.
>
>Copyright (c) 20XX, Acme Corporation. All rights reserved.
> -  This program and the accompanying materials
> -  are licensed and made available under the terms and conditions of
> -  the BSD License which accompanies this distribution. The full
> -  text of the license may be found at
> -  http://opensource.org/licenses/bsd-license.php
> -
> -  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON

Re: [edk2-devel] [WebSite Patch] Change preferred license of EDK II to BSD+Patent

[Laszlo Ersek]

Hi Mike,

On 04/15/19 22:38, Michael D Kinney wrote:
> https://bugzilla.tianocore.org/show_bug.cgi?id=1656
> 
> Change the web page documentation to state that the preferred license
> of the EDK II is the BSD+Patent License.
> 
> Cc: Andrew Fish 
> Cc: Laszlo Ersek 
> Cc: Leif Lindholm 
> Signed-off-by: Michael D Kinney 
> ---
>  edk2/index.md | 3 +--
>  legalese.md   | 3 ++-
>  ovmf/index.md | 2 +-
>  site/index.md | 2 +-
>  4 files changed, 5 insertions(+), 5 deletions(-)

can you please remind me where I can clone the website repo, and at what
*individual* URLs I can look at these four rendered pages? (Pre-patch
state is fine too.)

Thanks!
Laszlo

> diff --git a/edk2/index.md b/edk2/index.md
> index 2596fb3..6c6c6ea 100644
> --- a/edk2/index.md
> +++ b/edk2/index.md
> @@ -10,8 +10,7 @@ EDK II is a modern, feature-rich, cross-platform firmware 
> development
>  environment for the UEFI and PI specifications.
>  
>   License information:  
> -[BSD](http://www.opensource.org/licenses/bsd-license.php)
> -
> +[BSD+Patent]((https://opensource.org/licenses/BSDplusPatent)
>  
>   Source repositories:  
>  * edk2 main repository - 
> [https://github.com/tianocore/edk2](https://github.com/tianocore/edk2)
> diff --git a/legalese.md b/legalese.md
> index 9a2c8b2..03965b6 100644
> --- a/legalese.md
> +++ b/legalese.md
> @@ -6,7 +6,8 @@ title: Legal
>  
>  ## Licenses for TianoCore Contributions
>  
> -The preferred license for TianoCore is 
> [BSD-2-Clause]({{wiki}}/BSD-License){:target="_blank"}. The [TianoCore 
> contributors 
> agreement](https://raw.githubusercontent.com/tianocore/edk2/master/Contributions.txt){:target="_blank"}
>  describes acceptable licenses for community contributions.
> +The preferred license for TianoCore is 
> [BSD+Patent]({{wiki}}/BSD-Plus-Patent-License){:target="_blank"}. When that 
> is not possible, then contributions using
> +the following licenses can be accepted:
>  * BSD (2-clause): 
> [http://opensource.org/licenses/BSD-2-Clause](https://opensource.org/licenses/BSD-2-Clause){:target="_blank"}
>  * BSD (3-clause): 
> [http://opensource.org/licenses/BSD-3-Clause](http://opensource.org/licenses/BSD-3-Clause){:target="_blank"}
>  * MIT: 
> [http://opensource.org/licenses/MIT](http://opensource.org/licenses/MIT){:target="_blank"}
> diff --git a/ovmf/index.md b/ovmf/index.md
> index 843ad71..97c0cf3 100644
> --- a/ovmf/index.md
> +++ b/ovmf/index.md
> @@ -9,7 +9,7 @@ OVMF is an [EDK II] based project to enable UEFI support for 
> Virtual
>  Machines.  OVMF contains a sample UEFI firmware for [QEMU] and [KVM].
>  
>  License information:
> - [BSD](http://www.opensource.org/licenses/bsd-license.php)
> +  [BSD+Patent]((https://opensource.org/licenses/BSDplusPatent)
>  
>  More information:
>[OVMF FAQ]({{wiki}}/OVMF FAQ),
> diff --git a/site/index.md b/site/index.md
> index 9684422..dd3ffcc 100644
> --- a/site/index.md
> +++ b/site/index.md
> @@ -7,7 +7,7 @@ title: TianoCore web site
>  Our website is open source. Let us know if you have site content or
>  other website improvements!
>  
> -License information: 
> [BSD](http://www.opensource.org/licenses/bsd-license.php){:target="_blank"}
> +License information: 
> [BSD+Patent]((https://opensource.org/licenses/BSDplusPatent){:target="_blank"}
>  
>  Source repository: 
> {:target="_blank"}
>  
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39174): https://edk2.groups.io/g/devel/message/39174
Mute This Topic: https://groups.io/mt/31192884/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 08/10] OvmfPkg: suppress "Value stored to ... is never read" analyzer warnings

[Laszlo Ersek]

On 04/16/19 11:26, Jordan Justen wrote:
> On 2019-04-15 09:25:33, Laszlo Ersek wrote:
>> On 04/14/19 10:03, Jordan Justen wrote:
>>> On 2019-04-12 16:31:26, Laszlo Ersek wrote:
 RH covscan warns about assignments that it can determine are never
 "consumed" later ("dead stores"). The idea behind the warning is
 presumably that the programmer forgot to implement a dependent check
 somewhere.

 For each such warning that has been emitted for OvmfPkg,
 the case is one of the following however:

 - We assign a variable a value for (re-)initialization's sake, in
   preparation for further or future uses. This practice is safe (sometimes
   even recommended!), hence we should suppress these warnings.

 - We capture a result or a computation in a variable, following a general
   programming pattern, but then decide to ignore the value in that
   particular case. This is again safe, and we should suppress these
   warnings too.

 According to the Clang documentation at

   https://clang-analyzer.llvm.org/faq.html#dead_store

 we should use

   (void)x;

 See the logs below (produced originally for edk2-stable201903).

> Error: CLANG_WARNING:
> edk2-89910a39dcfd/OvmfPkg/AcpiPlatformDxe/Xen.c:156:3: warning: Value
> stored to 'NumberOfTableEntries' is never read
> #  NumberOfTableEntries = 0;
> #  ^  ~
> edk2-89910a39dcfd/OvmfPkg/AcpiPlatformDxe/Xen.c:156:3: note: Value
> stored to 'NumberOfTableEntries' is never read
> #  NumberOfTableEntries = 0;
> #  ^  ~
> #  154| DsdtTable   = NULL;
> #  155| TableHandle = 0;
> #  156|->   NumberOfTableEntries = 0;
> #  157|
> #  158| //
>
> Error: CLANG_WARNING:
> edk2-89910a39dcfd/OvmfPkg/Library/PlatformBootManagerLib/QemuKernel.c:43:3:
> warning: Value stored to 'SetupSize' is never read
> #  SetupSize = 0;
> #  ^   ~
> edk2-89910a39dcfd/OvmfPkg/Library/PlatformBootManagerLib/QemuKernel.c:43:3:
> note: Value stored to 'SetupSize' is never read
> #  SetupSize = 0;
> #  ^   ~
> #   41|
> #   42| SetupBuf = NULL;
> #   43|->   SetupSize = 0;
> #   44| KernelBuf = NULL;
> #   45| KernelInitialSize = 0;
>
> Error: CLANG_WARNING:
> edk2-89910a39dcfd/OvmfPkg/Library/SerializeVariablesLib/SerializeVariablesLib.c:609:9:
> warning: Value stored to 'VariableDataBufferSize' is never read
> #VariableDataBufferSize = 0;
> #^~
> edk2-89910a39dcfd/OvmfPkg/Library/SerializeVariablesLib/SerializeVariablesLib.c:609:9:
> note: Value stored to 'VariableDataBufferSize' is never read
> #VariableDataBufferSize = 0;
> #^~
> #  607|   FreePool (VariableData);
> #  608|   VariableData = NULL;
> #  609|-> VariableDataBufferSize = 0;
> #  610| }
> #  611| VariableData = AllocatePool (VariableDataSize);
>
> Error: CLANG_WARNING:
> edk2-89910a39dcfd/OvmfPkg/Library/VirtioLib/VirtioLib.c:125:3: warning:
> Value stored to 'RingPagesPtr' is never read
> #  RingPagesPtr += sizeof *Ring->Used.AvailEvent;
> #  ^   ~
> edk2-89910a39dcfd/OvmfPkg/Library/VirtioLib/VirtioLib.c:125:3: note:
> Value stored to 'RingPagesPtr' is never read
> #  RingPagesPtr += sizeof *Ring->Used.AvailEvent;
> #  ^   ~
> #  123|
> #  124| Ring->Used.AvailEvent = (volatile VOID *) RingPagesPtr;
> #  125|->   RingPagesPtr += sizeof *Ring->Used.AvailEvent;
> #  126|
> #  127| Ring->QueueSize = QueueSize;
>
> Error: CLANG_WARNING:
> edk2-89910a39dcfd/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c:1079:3:
> warning: Value stored to 'FwhInstance' is never read
> #  FwhInstance = (EFI_FW_VOL_INSTANCE *)
> #  ^ ~~~
> edk2-89910a39dcfd/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c:1079:3:
> note: Value stored to 'FwhInstance' is never read
> #  FwhInstance = (EFI_FW_VOL_INSTANCE *)
> #  ^ ~~~
> # 1077| ASSERT_RETURN_ERROR (PcdStatus);
> # 1078|
> # 1079|->   FwhInstance = (EFI_FW_VOL_INSTANCE *)
> # 1080|   (
> # 1081| (UINTN) ((UINT8 *) FwhInstance) + 
> FwVolHeader->HeaderLength +
>
> Error: CLANG_WARNING:
> edk2-89910a39dcfd/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c:173:3:
> warning: Value stored to 'Status' is never read
> #  Status = gDS->RemoveMemorySpace (
> #  ^
> edk2-89910a39dcfd/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c:173:3:
> note: Value stored to 'Status'

Re: [edk2-devel] [PATCH 10/10] OvmfPkg/BasePciCapLib: suppress invalid "nullptr deref" warning

[Laszlo Ersek]

On 04/15/19 19:31, Philippe Mathieu-Daudé wrote:
> On 4/13/19 1:31 AM, Laszlo Ersek wrote:
>> RH covscan reports the following "nullptr deref" warning:
>>
>>> Error: CLANG_WARNING:
>>> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:312:5:
>>> warning: Dereference of null pointer
>>> #InstanceZero->NumInstancesUnion.NumInstances++;
>>> #^
>>> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:509:7:
>>> note: Assuming 'OutCapList' is not equal to NULL
>>> #  if (OutCapList == NULL) {
>>> #  ^~
>>> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:509:3:
>>> note: Taking false branch
>>> #  if (OutCapList == NULL) {
>>> #  ^
>>> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:518:7:
>>> note: Assuming the condition is false
>>> #  if (OutCapList->Capabilities == NULL) {
>>> #  ^~~~
>>> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:518:3:
>>> note: Taking false branch
>>> #  if (OutCapList->Capabilities == NULL) {
>>> #  ^
>>> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:529:7:
>>> note: Assuming 'CapHdrOffsets' is not equal to NULL
>>> #  if (CapHdrOffsets == NULL) {
>>> #  ^
>>> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:529:3:
>>> note: Taking false branch
>>> #  if (CapHdrOffsets == NULL) {
>>> #  ^
>>> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:546:3:
>>> note: Taking false branch
>>> #  if (RETURN_ERROR (Status)) {
>>> #  ^
>>> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:549:7:
>>> note: Assuming the condition is true
>>> #  if ((PciStatusReg & EFI_PCI_STATUS_CAPABILITY) != 0) {
>>> #  ^~~
>>> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:549:3:
>>> note: Taking true branch
>>> #  if ((PciStatusReg & EFI_PCI_STATUS_CAPABILITY) != 0) {
>>> #  ^
>>> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:557:5:
>>> note: Taking false branch
>>> #if (RETURN_ERROR (Status)) {
>>> #^
>>> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:565:12:
>>> note: Assuming 'NormalCapHdrOffset' is > 0
>>> #while (NormalCapHdrOffset > 0) {
>>> #   ^~
>>> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:565:5:
>>> note: Loop condition is true.  Entering loop body
>>> #while (NormalCapHdrOffset > 0) {
>>> #^
>>> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:570:7:
>>> note: Taking false branch
>>> #  if (RETURN_ERROR (Status)) {
>>> #  ^
>>> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:574:16:
>>> note: Calling 'InsertPciCap'
>>> #  Status = InsertPciCap (OutCapList, CapHdrOffsets, PciCapNormal,
>>> #   ^~
>>> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:235:3:
>>> note: Null pointer value stored to 'InstanceZero'
>>> #  InstanceZero = NULL;
>>> #  ^~~
>>> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:243:7:
>>> note: Assuming 'PciCap' is not equal to NULL
>>> #  if (PciCap == NULL) {
>>> #  ^~
>>> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:243:3:
>>> note: Taking false branch
>>> #  if (PciCap == NULL) {
>>> #  ^
>>> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:259:3:
>>> note: Taking false branch
>>> #  if (RETURN_ERROR (Status)) {
>>> #  ^
>>> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:297:3:
>>> note: Taking false branch
>>> #  if (RETURN_ERROR (Status)) {
>>> #  ^
>>> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:311:7:
>>> note: Assuming the condition is true
>>> #  if (PciCap->Key.Instance > 0) {
>>> #  ^~~~
>>> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:311:3:
>>> note: Taking true branch
>>> #  if (PciCap->Key.Instance > 0) {
>>> #  ^
>>> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:312:5:
>>> note: Dereference of null pointer
>>> #InstanceZero->NumInstancesUnion.NumInstances++;
>>> #^~
>>> #  310| //
>>> #  311| if (PciCap->Key.Instance > 0) {
>>> #  312|-> InstanceZero->NumInstancesUnion.NumInstances++;
>>> #  313| }
>>> #  314| return RETURN_SUCCESS;
>>
>> The warning is invalid: the flagged dereferencing of "InstanceZero" is
>> gated by a condition that is only satisfied if we dereference
>> "InstanceZero" *first*.
>>
>> (Perhaps the analyzer assumes that the OrderedCollectionInsert() call,
>> just before line 259, can change the value of "PciCap->Key.Instance" via
>> the last argument:
>>
>>254//
>>255// Add PciCap to CapList.
>>256//
>>257Status = OrderedCollectionInsert (CapList->Capabilities, 
>> &

Re: [edk2-devel] [PATCH 02/10] MdePkg/PiFirmwareFile: fix undefined behavior in SECTION_SIZE

[Laszlo Ersek]

On 04/16/19 11:04, Jordan Justen wrote:
> On 2019-04-15 09:15:31, Laszlo Ersek wrote:
>> On 04/14/19 09:19, Jordan Justen wrote:
>>> On 2019-04-12 16:31:20, Laszlo Ersek wrote:
 RH covscan justifiedly reports that accessing
 "EFI_COMMON_SECTION_HEADER.Size", which is of type UINT8[3], through a
 (UINT32*), is undefined behavior:

> Error: OVERRUN (CWE-119):
> edk2-89910a39dcfd/OvmfPkg/Sec/SecMain.c:178: overrun-local: Overrunning
> array of 3 bytes at byte offset 3 by dereferencing pointer
> "(UINT32 *)((EFI_COMMON_SECTION_HEADER *)(UINTN)Section)->Size".
> #  176|   Section = (EFI_COMMON_SECTION_HEADER*)(UINTN) 
> CurrentAddress;
> #  177|
> #  178|-> Size = SECTION_SIZE (Section);
> #  179|   if (Size < sizeof (*Section)) {
> #  180| return EFI_VOLUME_CORRUPTED;

 Fix this by introducing EFI_COMMON_SECTION_HEADER_UNION, and expressing
 SECTION_SIZE() in terms of "EFI_COMMON_SECTION_HEADER_UNION.Uint32".

 Cc: Liming Gao 
 Cc: Michael D Kinney 
 Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1710
 Issue: scan-1007.txt
 Signed-off-by: Laszlo Ersek 
 ---
  MdePkg/Include/Pi/PiFirmwareFile.h | 10 +-
  1 file changed, 9 insertions(+), 1 deletion(-)

 diff --git a/MdePkg/Include/Pi/PiFirmwareFile.h 
 b/MdePkg/Include/Pi/PiFirmwareFile.h
 index a9f3bcc4eb8e..4fce8298d1c0 100644
 --- a/MdePkg/Include/Pi/PiFirmwareFile.h
 +++ b/MdePkg/Include/Pi/PiFirmwareFile.h
 @@ -229,16 +229,24 @@ typedef struct {
///
UINT8 Size[3];
EFI_SECTION_TYPE  Type;
///
/// Declares the section type.
///
  } EFI_COMMON_SECTION_HEADER;

 +///
 +/// Union that permits accessing EFI_COMMON_SECTION_HEADER as a UINT32 
 object.
 +///
 +typedef union {
 +  EFI_COMMON_SECTION_HEADER Hdr;
 +  UINT32Uint32;
 +} EFI_COMMON_SECTION_HEADER_UNION;
 +
  typedef struct {
///
/// A 24-bit unsigned integer that contains the total size of the 
 section in bytes,
/// including the EFI_COMMON_SECTION_HEADER.
///
UINT8 Size[3];

EFI_SECTION_TYPE  Type;
 @@ -476,17 +484,17 @@ typedef struct {
/// A UINT16 that represents a particular build. Subsequent builds have 
 monotonically
/// increasing build numbers relative to earlier builds.
///
UINT16BuildNumber;
CHAR16VersionString[1];
  } EFI_VERSION_SECTION2;

  #define SECTION_SIZE(SectionHeaderPtr) \
 -((UINT32) (*((UINT32 *) ((EFI_COMMON_SECTION_HEADER *) (UINTN) 
 SectionHeaderPtr)->Size) & 0x00ff))
 +(((EFI_COMMON_SECTION_HEADER_UNION *) (UINTN) 
 (SectionHeaderPtr))->Uint32 & 0x00ff)
>>>
>>> Mike, all,
>>>
>>> Can we add a typedef for EFI_COMMON_SECTION_HEADER_UNION if it's not
>>> in the PI spec?
>>>
>>> If it's not allowed, I think something like this might work too:
>>>
>>> #define SECTION_SIZE(SectionHeaderPtr) \
>>> (*((UINT32*)(UINTN)(SectionHeaderPtr)) & 0x00ff)
>>
>> (Less importantly:)
>>
>> It might shut up the static analyzer, but regarding the C standard, it's
>> equally undefined behavior.
> 
> I think you are still accessing it through a UINT32*, since you are
> using a pointer to a union, and an field of type UINT32 within the
> union.

Using a union makes the behavior well-defined.

> 6.2.7 Compatible type and composite type
>
> 1 Two types have compatible type if their types are the same.
>   Additional rules for determining whether two types are compatible
>   are described in [...]

> 6.5 Expressions
>
> 6 The /effective type/ of an object for an access to its stored value
>   is the declared type of the object, if any. [...]
>
> 7 An object shall have its stored value accessed only by an lvalue
>   expression that has one of the following types:
>
>   — a type compatible with the effective type of the object,
>   — a qualified version of a type compatible with the effective type
> of the object,
>   — a type that is the signed or unsigned type corresponding to the
> effective type of the object,
>   — a type that is the signed or unsigned type corresponding to a
> qualified version of the effective type of the object,
>   — an aggregate or union type that includes one of the aforementioned
> types among its members (including, recursively, a member of a
> subaggregate or contained union), or
>   — a character type.

- Regarding 6.5p6, the original object we intend to access has
(declared) type EFI_COMMON_SECTION_HEADER. Therefore the effective type
is EFI_COMMON_SECTION_HEADER.

- Based on 6.2.7p1, EFI_COMMON_SECTION_HEADER is compatible with
EFI_COMMON_SECTION_HEADER. (Because they are the same.)

- Based on 6.5p7 item #5, EFI_COMMON_SECTION_HEADER can be acce

Re: [edk2-devel] [PATCH edk2-platforms] Silicon/AMD: drop unused/orphaned Styx ResetSystemLib

[Leif Lindholm]

On Mon, Apr 15, 2019 at 12:00:38PM -0700, Ard Biesheuvel wrote:
> On Mon, 15 Apr 2019 at 03:15, Leif Lindholm  wrote:
> >
> > All Styx platforms in the tree (and the world) use
> > ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.inf
> > these days, but somehow this orphaned .inf was left around - drop it.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Leif Lindholm 
> 
> Reviewed-by: Ard Biesheuvel 

Thanks. Pushed as a8cf8edf74.

/
Leif

> > ---
> >  Silicon/AMD/Styx/Library/ResetSystemLib/ResetSystemLib.inf | 44 
> > 
> >  1 file changed, 44 deletions(-)
> >
> > diff --git a/Silicon/AMD/Styx/Library/ResetSystemLib/ResetSystemLib.inf 
> > b/Silicon/AMD/Styx/Library/ResetSystemLib/ResetSystemLib.inf
> > deleted file mode 100644
> > index d9faf3abb0..00
> > --- a/Silicon/AMD/Styx/Library/ResetSystemLib/ResetSystemLib.inf
> > +++ /dev/null
> > @@ -1,44 +0,0 @@
> > -#/** @file
> > -# Reset System lib using PSCI hypervisor or secure monitor calls
> > -#
> > -# Copyright (c) 2008, Apple Inc. All rights reserved.
> > -# Copyright (c) 2014, Linaro Ltd. All rights reserved.
> > -# Copyright (c) 2014, ARM Ltd. All rights reserved.
> > -# Copyright (c) 2014 - 2016, AMD Inc. All rights reserved.
> > -#
> > -#  This program and the accompanying materials
> > -#  are licensed and made available under the terms and conditions of the 
> > BSD License
> > -#  which accompanies this distribution. The full text of the license may 
> > be found at
> > -#  http://opensource.org/licenses/bsd-license.php
> > -#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> > -#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> > IMPLIED.
> > -#
> > -#**/
> > -#/**
> > -#  Derived from:
> > -#   ArmPkg/Library/ArmPsciResetSystemLib/ArmPsciResetSystemLib.inf
> > -#
> > -#**/
> > -
> > -[Defines]
> > -  INF_VERSION= 0x00010005
> > -  BASE_NAME  = AmdStyxResetSystemLib
> > -  FILE_GUID  = 624f6cc6-c38f-4897-b3b7-8a601701291b
> > -  MODULE_TYPE= BASE
> > -  VERSION_STRING = 1.0
> > -  LIBRARY_CLASS  = EfiResetSystemLib
> > -
> > -[Sources.common]
> > -  ResetSystemLib.c
> > -
> > -[Packages]
> > -  ArmPkg/ArmPkg.dec
> > -  MdePkg/MdePkg.dec
> > -  EmbeddedPkg/EmbeddedPkg.dec
> > -  Silicon/AMD/Styx/AmdModulePkg/AmdModulePkg.dec
> > -  Silicon/AMD/Styx/AmdStyx.dec
> > -
> > -[LibraryClasses]
> > -  PcdLib
> > -  BaseLib
> > -  ArmSmcLib
> > --
> > 2.11.0
> >

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39170): https://edk2.groups.io/g/devel/message/39170
Mute This Topic: https://groups.io/mt/31186492/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 08/10] OvmfPkg: suppress "Value stored to ... is never read" analyzer warnings

[Jordan Justen]

On 2019-04-15 09:25:33, Laszlo Ersek wrote:
> On 04/14/19 10:03, Jordan Justen wrote:
> > On 2019-04-12 16:31:26, Laszlo Ersek wrote:
> >> RH covscan warns about assignments that it can determine are never
> >> "consumed" later ("dead stores"). The idea behind the warning is
> >> presumably that the programmer forgot to implement a dependent check
> >> somewhere.
> >>
> >> For each such warning that has been emitted for OvmfPkg,
> >> the case is one of the following however:
> >>
> >> - We assign a variable a value for (re-)initialization's sake, in
> >>   preparation for further or future uses. This practice is safe (sometimes
> >>   even recommended!), hence we should suppress these warnings.
> >>
> >> - We capture a result or a computation in a variable, following a general
> >>   programming pattern, but then decide to ignore the value in that
> >>   particular case. This is again safe, and we should suppress these
> >>   warnings too.
> >>
> >> According to the Clang documentation at
> >>
> >>   https://clang-analyzer.llvm.org/faq.html#dead_store
> >>
> >> we should use
> >>
> >>   (void)x;
> >>
> >> See the logs below (produced originally for edk2-stable201903).
> >>
> >>> Error: CLANG_WARNING:
> >>> edk2-89910a39dcfd/OvmfPkg/AcpiPlatformDxe/Xen.c:156:3: warning: Value
> >>> stored to 'NumberOfTableEntries' is never read
> >>> #  NumberOfTableEntries = 0;
> >>> #  ^  ~
> >>> edk2-89910a39dcfd/OvmfPkg/AcpiPlatformDxe/Xen.c:156:3: note: Value
> >>> stored to 'NumberOfTableEntries' is never read
> >>> #  NumberOfTableEntries = 0;
> >>> #  ^  ~
> >>> #  154| DsdtTable   = NULL;
> >>> #  155| TableHandle = 0;
> >>> #  156|->   NumberOfTableEntries = 0;
> >>> #  157|
> >>> #  158| //
> >>>
> >>> Error: CLANG_WARNING:
> >>> edk2-89910a39dcfd/OvmfPkg/Library/PlatformBootManagerLib/QemuKernel.c:43:3:
> >>> warning: Value stored to 'SetupSize' is never read
> >>> #  SetupSize = 0;
> >>> #  ^   ~
> >>> edk2-89910a39dcfd/OvmfPkg/Library/PlatformBootManagerLib/QemuKernel.c:43:3:
> >>> note: Value stored to 'SetupSize' is never read
> >>> #  SetupSize = 0;
> >>> #  ^   ~
> >>> #   41|
> >>> #   42| SetupBuf = NULL;
> >>> #   43|->   SetupSize = 0;
> >>> #   44| KernelBuf = NULL;
> >>> #   45| KernelInitialSize = 0;
> >>>
> >>> Error: CLANG_WARNING:
> >>> edk2-89910a39dcfd/OvmfPkg/Library/SerializeVariablesLib/SerializeVariablesLib.c:609:9:
> >>> warning: Value stored to 'VariableDataBufferSize' is never read
> >>> #VariableDataBufferSize = 0;
> >>> #^~
> >>> edk2-89910a39dcfd/OvmfPkg/Library/SerializeVariablesLib/SerializeVariablesLib.c:609:9:
> >>> note: Value stored to 'VariableDataBufferSize' is never read
> >>> #VariableDataBufferSize = 0;
> >>> #^~
> >>> #  607|   FreePool (VariableData);
> >>> #  608|   VariableData = NULL;
> >>> #  609|-> VariableDataBufferSize = 0;
> >>> #  610| }
> >>> #  611| VariableData = AllocatePool (VariableDataSize);
> >>>
> >>> Error: CLANG_WARNING:
> >>> edk2-89910a39dcfd/OvmfPkg/Library/VirtioLib/VirtioLib.c:125:3: warning:
> >>> Value stored to 'RingPagesPtr' is never read
> >>> #  RingPagesPtr += sizeof *Ring->Used.AvailEvent;
> >>> #  ^   ~
> >>> edk2-89910a39dcfd/OvmfPkg/Library/VirtioLib/VirtioLib.c:125:3: note:
> >>> Value stored to 'RingPagesPtr' is never read
> >>> #  RingPagesPtr += sizeof *Ring->Used.AvailEvent;
> >>> #  ^   ~
> >>> #  123|
> >>> #  124| Ring->Used.AvailEvent = (volatile VOID *) RingPagesPtr;
> >>> #  125|->   RingPagesPtr += sizeof *Ring->Used.AvailEvent;
> >>> #  126|
> >>> #  127| Ring->QueueSize = QueueSize;
> >>>
> >>> Error: CLANG_WARNING:
> >>> edk2-89910a39dcfd/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c:1079:3:
> >>> warning: Value stored to 'FwhInstance' is never read
> >>> #  FwhInstance = (EFI_FW_VOL_INSTANCE *)
> >>> #  ^ ~~~
> >>> edk2-89910a39dcfd/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c:1079:3:
> >>> note: Value stored to 'FwhInstance' is never read
> >>> #  FwhInstance = (EFI_FW_VOL_INSTANCE *)
> >>> #  ^ ~~~
> >>> # 1077| ASSERT_RETURN_ERROR (PcdStatus);
> >>> # 1078|
> >>> # 1079|->   FwhInstance = (EFI_FW_VOL_INSTANCE *)
> >>> # 1080|   (
> >>> # 1081| (UINTN) ((UINT8 *) FwhInstance) + 
> >>> FwVolHeader->HeaderLength +
> >>>
> >>> Error: CLANG_WARNING:
> >>> edk2-89910a39dcfd/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c:173:3:
> >>> warning: Value stored to 'Status' is never read
> >>> #  Status = gDS->RemoveMemorySpace (
> >>> #  ^
> >>> edk2-89910a39dcfd/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c:173:3:
> >>> note: Value stored to 'Status' is never read
> >>> #  Status = gDS->Remov

[edk2-devel] [edk2-platforms: PATCH v2 3/6] Marvell/Armada7k8k: Implement PMU interrupt handling

[Marcin Wojtas]

Generic handling of the PMU interrupts in UEFI and Linux with
ACPI require enabling a dedicated handler in the EL3.
Extend the PlatInitDxe with enabler code.

Because for DT world the EL3 service must remain disabled,
switch it off in the ExitBootServicesEvent. Its execution
depends on the gEdkiiPlatformHasAcpiGuid status check in the new
gEfiEventReadyToBootGuid routine.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.inf |  6 ++
 Silicon/Marvell/Include/IndustryStandard/MvSmc.h   |  2 +
 Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.c   | 82 

 3 files changed, 90 insertions(+)

diff --git a/Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.inf 
b/Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.inf
index e707fe9..df10526 100644
--- a/Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.inf
+++ b/Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.inf
@@ -25,6 +25,7 @@
   PlatInitDxe.c
 
 [Packages]
+  ArmPkg/ArmPkg.dec
   EmbeddedPkg/EmbeddedPkg.dec
   MdeModulePkg/MdeModulePkg.dec
   MdePkg/MdePkg.dec
@@ -32,6 +33,7 @@
 
 [LibraryClasses]
   ArmadaIcuLib
+  ArmSmcLib
   ComPhyLib
   DebugLib
   MppLib
@@ -40,6 +42,10 @@
   UefiDriverEntryPoint
   UtmiPhyLib
 
+[Guids]
+  gEdkiiPlatformHasAcpiGuid
+  gEfiEventReadyToBootGuid
+
 [Protocols]
   gMarvellPlatformInitCompleteProtocolGuid## PRODUCES
 
diff --git a/Silicon/Marvell/Include/IndustryStandard/MvSmc.h 
b/Silicon/Marvell/Include/IndustryStandard/MvSmc.h
index 0c90f11..e5c89d9 100644
--- a/Silicon/Marvell/Include/IndustryStandard/MvSmc.h
+++ b/Silicon/Marvell/Include/IndustryStandard/MvSmc.h
@@ -20,5 +20,7 @@
 #define MV_SMC_ID_COMPHY_POWER_OFF0x8202
 #define MV_SMC_ID_COMPHY_PLL_LOCK 0x8203
 #define MV_SMC_ID_DRAM_SIZE   0x8210
+#define MV_SMC_ID_PMU_IRQ_ENABLE  0x8212
+#define MV_SMC_ID_PMU_IRQ_DISABLE 0x8213
 
 #endif //__MV_SMC_H__
diff --git a/Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.c 
b/Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.c
index 18b6783..4012fd7 100644
--- a/Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.c
+++ b/Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.c
@@ -12,7 +12,12 @@
 
 **/
 
+#include 
+
+#include 
+
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -21,6 +26,62 @@
 #include 
 #include 
 
+STATIC EFI_EVENT mArmada7k8kExitBootServicesEvent;
+
+/**
+  Disable extra EL3 handling of the PMU interrupts for DT world.
+
+  @param[in]   Event  Event structure
+  @param[in]   ContextNotification context
+
+**/
+STATIC
+VOID
+Armada7k8kExitBootServicesHandler (
+  IN EFI_EVENT  Event,
+  IN VOID  *Context
+  )
+{
+  ARM_SMC_ARGS SmcRegs = {0};
+
+  SmcRegs.Arg0 = MV_SMC_ID_PMU_IRQ_DISABLE;
+  ArmCallSmc (&SmcRegs);
+
+  return;
+}
+
+/**
+  Check if we boot with DT and trigger EBS event in such case.
+
+  @param[in]   Event  Event structure
+  @param[in]   ContextNotification context
+
+**/
+STATIC
+VOID
+Armada7k8kOnReadyToBootHandler (
+  IN EFI_EVENT  Event,
+  IN VOID  *Context
+  )
+{
+  EFI_STATUSStatus;
+  VOID *Interface;
+
+  Status = gBS->LocateProtocol (&gEdkiiPlatformHasAcpiGuid,
+  NULL,
+  (VOID **)&Interface);
+  if (EFI_ERROR (Status)) {
+Status = gBS->CreateEvent (EVT_SIGNAL_EXIT_BOOT_SERVICES,
+TPL_NOTIFY,
+Armada7k8kExitBootServicesHandler,
+NULL,
+&mArmada7k8kExitBootServicesEvent);
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR, "%a: Fail to register EBS event\n", __FUNCTION__));
+}
+  }
+}
+
 EFI_STATUS
 EFIAPI
 ArmadaPlatInitDxeEntryPoint (
@@ -28,7 +89,9 @@ ArmadaPlatInitDxeEntryPoint (
   IN EFI_SYSTEM_TABLE   *SystemTable
   )
 {
+  ARM_SMC_ARGS  SmcRegs = {0};
   EFI_STATUSStatus;
+  EFI_EVENT Event;
 
   DEBUG ((DEBUG_ERROR, "\nArmada Platform Init\n\n"));
 
@@ -43,5 +106,24 @@ ArmadaPlatInitDxeEntryPoint (
   MppInitialize ();
   ArmadaIcuInitialize ();
 
+  /*
+   * Enable EL3 PMU interrupt handler and
+   * register the ReadyToBoot event.
+   */
+  SmcRegs.Arg0 = MV_SMC_ID_PMU_IRQ_ENABLE;
+  ArmCallSmc (&SmcRegs);
+
+  Status = gBS->CreateEventEx (EVT_NOTIFY_SIGNAL,
+  TPL_CALLBACK,
+  Armada7k8kOnReadyToBootHandler,
+  NULL,
+  &gEfiEventReadyToBootGuid,
+  &Event);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR,
+  "%a: Fail to register OnReadyToBoot event\n",
+  __FUNCTION__));
+  }
+
   return EFI_SUCCESS;
 }
-- 
2.7.4


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39165): https://edk2.groups.io/g/devel/message/39165

[edk2-devel] [edk2-platforms: PATCH v2 1/6] Marvell/Armada7k8k: RealTimeClockLib: Update bus parameters

[Marcin Wojtas]

From: Mark Kettenis 

Adjust bus timing parameters to make reading and updating the RTC
reliable.

This patch aligns the bus configuration to the one used by Linux.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.h | 7 
++-
 Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.c | 5 
+
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git 
a/Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.h 
b/Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.h
index 922f959..ee0c303 100644
--- a/Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.h
+++ b/Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.h
@@ -41,10 +41,15 @@ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 #define RTC_IRQ_2_CONFIG_REG0x8
 #define RTC_IRQ_ALARM_EN0x1
 #define RTC_ALARM_2_REG 0x14
+#define RTC_BRIDGE_TIMING_CTRL0_REG_OFFS0x80
 #define RTC_BRIDGE_TIMING_CTRL1_REG_OFFS0x84
 #define RTC_IRQ_STATUS_REG  0x90
 #define RTC_IRQ_ALARM_MASK  0x1
+#define RTC_WRITE_PERIOD_DELAY_MASK 0x
+#define RTC_WRITE_PERIOD_DELAY_DEFAULT  0x3FF
+#define RTC_WRITE_SETUP_DELAY_MASK  (0x << 16)
+#define RTC_WRITE_SETUP_DELAY_DEFAULT   (0x29 << 16)
 #define RTC_READ_OUTPUT_DELAY_MASK  0x
-#define RTC_READ_OUTPUT_DELAY_DEFAULT   0x1F
+#define RTC_READ_OUTPUT_DELAY_DEFAULT   0x3F
 
 #endif /* __RTCLIB_H__ */
diff --git 
a/Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.c 
b/Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.c
index 087bd9a..7de5ed7 100644
--- a/Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.c
+++ b/Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.c
@@ -250,6 +250,11 @@ LibRtcInitialize (
 
   /* Update RTC-MBUS bridge timing parameters */
   MmioAndThenOr32 (
+  mArmadaRtcBase + RTC_BRIDGE_TIMING_CTRL0_REG_OFFS,
+  ~(RTC_WRITE_SETUP_DELAY_MASK | RTC_WRITE_PERIOD_DELAY_MASK),
+  (RTC_WRITE_SETUP_DELAY_DEFAULT | RTC_WRITE_PERIOD_DELAY_DEFAULT)
+  );
+  MmioAndThenOr32 (
   mArmadaRtcBase + RTC_BRIDGE_TIMING_CTRL1_REG_OFFS,
   ~RTC_READ_OUTPUT_DELAY_MASK,
   RTC_READ_OUTPUT_DELAY_DEFAULT
-- 
2.7.4


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39163): https://edk2.groups.io/g/devel/message/39163
Mute This Topic: https://groups.io/mt/31198633/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms: PATCH v2 5/6] Marvell/Armada7k8k: ArmadaSoCDescLib: Add more I2C controllers

[Marcin Wojtas]

Hitherto SoC library of Armada7k8k was missing AP and CP-MSS
I2C controllers. Fix that and update Armada70x0Db and
Armada80x0Db I2C description accordingly.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Armada70x0Db/Armada70x0Db.dsc 
| 4 ++--
 Platform/Marvell/Armada80x0Db/Armada80x0Db.dsc 
| 2 +-
 Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.h 
| 8 ++--
 Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.c 
| 5 -
 4 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/Platform/Marvell/Armada70x0Db/Armada70x0Db.dsc 
b/Platform/Marvell/Armada70x0Db/Armada70x0Db.dsc
index e8cd177..01532b4 100644
--- a/Platform/Marvell/Armada70x0Db/Armada70x0Db.dsc
+++ b/Platform/Marvell/Armada70x0Db/Armada70x0Db.dsc
@@ -94,9 +94,9 @@
   # I2C
   gMarvellTokenSpaceGuid.PcdI2cSlaveAddresses|{ 0x50, 0x57, 0x60, 0x21 }
   gMarvellTokenSpaceGuid.PcdI2cSlaveBuses|{ 0x0, 0x0, 0x0, 0x0 }
-  gMarvellTokenSpaceGuid.PcdI2cControllersEnabled|{ 0x1, 0x1 }
+  gMarvellTokenSpaceGuid.PcdI2cControllersEnabled|{ 0x0, 0x1, 0x1 }
   gMarvellTokenSpaceGuid.PcdEepromI2cAddresses|{ 0x50, 0x57 }
-  gMarvellTokenSpaceGuid.PcdEepromI2cBuses|{ 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdEepromI2cBuses|{ 0x1, 0x1 }
   gMarvellTokenSpaceGuid.PcdI2cClockFrequency|25000
   gMarvellTokenSpaceGuid.PcdI2cBaudRate|10
   gMarvellTokenSpaceGuid.PcdI2cBusCount|2
diff --git a/Platform/Marvell/Armada80x0Db/Armada80x0Db.dsc 
b/Platform/Marvell/Armada80x0Db/Armada80x0Db.dsc
index 8e8c2ba..a28e330 100644
--- a/Platform/Marvell/Armada80x0Db/Armada80x0Db.dsc
+++ b/Platform/Marvell/Armada80x0Db/Armada80x0Db.dsc
@@ -103,7 +103,7 @@
   # I2C
   gMarvellTokenSpaceGuid.PcdI2cSlaveAddresses|{ 0x50, 0x57, 0x50, 0x57, 0x21, 
0x25 }
   gMarvellTokenSpaceGuid.PcdI2cSlaveBuses|{ 0x0, 0x0, 0x1, 0x1, 0x0, 0x0 }
-  gMarvellTokenSpaceGuid.PcdI2cControllersEnabled|{ 0x1, 0x0, 0x1 }
+  gMarvellTokenSpaceGuid.PcdI2cControllersEnabled|{ 0x0, 0x1, 0x0, 0x0, 0x1 }
   gMarvellTokenSpaceGuid.PcdEepromI2cAddresses|{ 0x50, 0x57, 0x50, 0x57 }
   gMarvellTokenSpaceGuid.PcdEepromI2cBuses|{ 0x0, 0x0, 0x1, 0x1 }
   gMarvellTokenSpaceGuid.PcdI2cClockFrequency|25000
diff --git 
a/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.h
 
b/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.h
index c2d7933..8bbc5b0 100644
--- 
a/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.h
+++ 
b/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.h
@@ -56,8 +56,12 @@
 //
 // Platform description of I2C controllers
 //
-#define MV_SOC_I2C_PER_CP_COUNT  2
-#define MV_SOC_I2C_BASE(I2c) (0x701000 + ((I2c) * 0x100))
+#define MV_SOC_I2C_PER_AP_COUNT  1
+#define MV_SOC_I2C_AP_BASE   (MV_SOC_AP806_BASE + 0x511000)
+#define MV_SOC_I2C_PER_CP_COUNT  3
+#define MV_SOC_I2C_BASE(I2c) ((I2c < 2) ? \
+  (0x701000 + (I2c) * 0x100) : \
+  0x211000)
 
 //
 // Platform description of ICU (Interrupt Consolidation Unit) controllers
diff --git 
a/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.c
 
b/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.c
index 584f445..355be64 100644
--- 
a/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.c
+++ 
b/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.c
@@ -157,7 +157,7 @@ ArmadaSoCDescI2cGet (
 
   CpCount = FixedPcdGet8 (PcdMaxCpCount);
 
-  *DescCount = CpCount * MV_SOC_I2C_PER_CP_COUNT;
+  *DescCount = CpCount * MV_SOC_I2C_PER_CP_COUNT + MV_SOC_I2C_PER_AP_COUNT;
   Desc = AllocateZeroPool (*DescCount * sizeof (MV_SOC_I2C_DESC));
   if (Desc == NULL) {
 DEBUG ((DEBUG_ERROR, "%a: Cannot allocate memory\n", __FUNCTION__));
@@ -166,6 +166,9 @@ ArmadaSoCDescI2cGet (
 
   *I2cDesc = Desc;
 
+  Desc->I2cBaseAddress = MV_SOC_I2C_AP_BASE;
+  Desc++;
+
   for (CpIndex = 0; CpIndex < CpCount; CpIndex++) {
 for (Index = 0; Index < MV_SOC_I2C_PER_CP_COUNT; Index++) {
   Desc->I2cBaseAddress = MV_SOC_CP_BASE (CpIndex) + MV_SOC_I2C_BASE 
(Index);
-- 
2.7.4


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39167): https://edk2.groups.io/g/devel/message/39167
Mute This Topic: https://groups.io/mt/31198637/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms: PATCH v2 2/6] Marvell/Armada7k8k: AcpiTables: Enable edge trigger of PMU interrupt

[Marcin Wojtas]

Extend MADT GICC table flags with PERFORMANCE_INTERRUPT_MODEL,
which is responsible for configuring interrupt type in the OS.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Silicon/Marvell/Armada7k8k/AcpiTables/Madt.aslc | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/Silicon/Marvell/Armada7k8k/AcpiTables/Madt.aslc 
b/Silicon/Marvell/Armada7k8k/AcpiTables/Madt.aslc
index 3dae5d3..7ab927d 100644
--- a/Silicon/Marvell/Armada7k8k/AcpiTables/Madt.aslc
+++ b/Silicon/Marvell/Armada7k8k/AcpiTables/Madt.aslc
@@ -35,6 +35,8 @@
 #define PMU_INTERRUPT_CPU2132
 #define PMU_INTERRUPT_CPU3133
 
+#define PMU_INTERRUPT_FLAGEFI_ACPI_6_0_GIC_ENABLED | 
EFI_ACPI_6_0_PERFORMANCE_INTERRUPT_MODEL
+
 #pragma pack(push, 1)
 typedef struct {
   EFI_ACPI_6_0_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER Header;
@@ -57,7 +59,7 @@ ACPI_6_0_MADT_STRUCTURE Madt = {
 EFI_ACPI_6_0_GICC_STRUCTURE_INIT(0, // GicId
  0x000, // AcpiCpuUid
  0x000, // Mpidr
- EFI_ACPI_6_0_GIC_ENABLED,  // Flags
+ PMU_INTERRUPT_FLAG,// Flags
  PMU_INTERRUPT_CPU0,// PmuIrq
  GICC_BASE, // GicBase
  GICV_BASE, // GicVBase
@@ -69,7 +71,7 @@ ACPI_6_0_MADT_STRUCTURE Madt = {
 EFI_ACPI_6_0_GICC_STRUCTURE_INIT(1, // GicId
  0x001, // AcpiCpuUid
  0x001, // Mpidr
- EFI_ACPI_6_0_GIC_ENABLED,  // Flags
+ PMU_INTERRUPT_FLAG,// Flags
  PMU_INTERRUPT_CPU1,// PmuIrq
  GICC_BASE, // GicBase
  GICV_BASE, // GicVBase
@@ -81,7 +83,7 @@ ACPI_6_0_MADT_STRUCTURE Madt = {
 EFI_ACPI_6_0_GICC_STRUCTURE_INIT(2, // GicId
  0x100, // AcpiCpuUid
  0x100, // Mpidr
- EFI_ACPI_6_0_GIC_ENABLED,  // Flags
+ PMU_INTERRUPT_FLAG,// Flags
  PMU_INTERRUPT_CPU2,// PmuIrq
  GICC_BASE, // GicBase
  GICV_BASE, // GicVBase
@@ -93,7 +95,7 @@ ACPI_6_0_MADT_STRUCTURE Madt = {
 EFI_ACPI_6_0_GICC_STRUCTURE_INIT(3, // GicId
  0x101, // AcpiCpuUid
  0x101, // Mpidr
- EFI_ACPI_6_0_GIC_ENABLED,  // Flags
+ PMU_INTERRUPT_FLAG,// Flags
  PMU_INTERRUPT_CPU3,// PmuIrq
  GICC_BASE, // GicBase
  GICV_BASE, // GicVBase
-- 
2.7.4


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39164): https://edk2.groups.io/g/devel/message/39164
Mute This Topic: https://groups.io/mt/31198634/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms: PATCH v2 6/6] Marvell/Armada80x0Db: Configure the CP1, comphy-2 to work with SFI 10G

[Marcin Wojtas]

From: Grzegorz Jaszczyk 

By mistake port0 of the second PP2 controller was configured
to 5G speed, instead of 10G. Fix it.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Armada80x0Db/Armada80x0Db.dsc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Platform/Marvell/Armada80x0Db/Armada80x0Db.dsc 
b/Platform/Marvell/Armada80x0Db/Armada80x0Db.dsc
index a28e330..c6510bb 100644
--- a/Platform/Marvell/Armada80x0Db/Armada80x0Db.dsc
+++ b/Platform/Marvell/Armada80x0Db/Armada80x0Db.dsc
@@ -137,7 +137,7 @@
   # 4: PCIE1 5 Gbps
   # 5: PCIE2 5 Gbps
   gMarvellTokenSpaceGuid.PcdChip1ComPhyTypes|{ $(CP_PCIE0), $(CP_SATA2), 
$(CP_SFI), $(CP_SATA3), $(CP_PCIE1), $(CP_PCIE2) }
-  gMarvellTokenSpaceGuid.PcdChip1ComPhySpeeds|{ $(CP_5G), $(CP_5G), 
$(CP_5_15625G), $(CP_5G), $(CP_5G), $(CP_5G) }
+  gMarvellTokenSpaceGuid.PcdChip1ComPhySpeeds|{ $(CP_5G), $(CP_5G), 
$(CP_10_3125G), $(CP_5G), $(CP_5G), $(CP_5G) }
 
   #UtmiPhy
   gMarvellTokenSpaceGuid.PcdUtmiControllersEnabled|{ 0x1, 0x1, 0x1, 0x0 }
-- 
2.7.4


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39168): https://edk2.groups.io/g/devel/message/39168
Mute This Topic: https://groups.io/mt/31198638/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms: PATCH v2 0/6] Armada7k8k misc improvements

[Marcin Wojtas]

Hi,

A second version of the patchset brings one, though significant
change. An idea of using custom DtLoaderLib for the PMU IRQ handling
was dropped. Instead use existing PlatInitDxe. The EL3 service
is still switched off in the ExitBootServicesEvent. However its
execution depends on the gEdkiiPlatformHasAcpiGuid status check in the new
gEfiEventReadyToBootGuid routine.

The patches are available in the github:
https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/misc-upstream-r20190416

I'm looking forward to your comments or remarks.

Best regards,
Marcin

Changelog:
v1 -> v2:
* 3/6
  - Use PlatInitDxe and gEfiEventReadyToBootGuid event


Grzegorz Jaszczyk (1):
  Marvell/Armada80x0Db: Configure the CP1, comphy-2 to work with SFI 10G

Marcin Wojtas (4):
  Marvell/Armada7k8k: AcpiTables: Enable edge trigger of PMU interrupt
  Marvell/Armada7k8k: Implement PMU interrupt handling
  Marvell/Armada7k8k: Switch to software-based watchdog
  Marvell/Armada7k8k: ArmadaSoCDescLib: Add more I2C controllers

Mark Kettenis (1):
  Marvell/Armada7k8k: RealTimeClockLib: Update bus parameters

 Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc  
|  2 +-
 Platform/Marvell/Armada70x0Db/Armada70x0Db.dsc 
|  4 +-
 Platform/Marvell/Armada80x0Db/Armada80x0Db.dsc 
|  4 +-
 Silicon/Marvell/Armada7k8k/Armada7k8k.fdf  
|  2 +-
 Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.inf 
|  6 ++
 Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.h 
|  8 +-
 Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.h 
|  7 +-
 Silicon/Marvell/Include/IndustryStandard/MvSmc.h   
|  2 +
 Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.c   
| 82 
 Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.c 
|  5 +-
 Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.c 
|  5 ++
 Silicon/Marvell/Armada7k8k/AcpiTables/Madt.aslc
| 10 ++-
 12 files changed, 123 insertions(+), 14 deletions(-)

-- 
2.7.4


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39162): https://edk2.groups.io/g/devel/message/39162
Mute This Topic: https://groups.io/mt/31198632/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms: PATCH v2 4/6] Marvell/Armada7k8k: Switch to software-based watchdog

[Marcin Wojtas]

Due to the hardware issue, it is better to
use generic MdeModulePkg version of the watchdog
instead of the ArmPkg driver. It prevents unwanted
resetting of the platform when spending "too long"
inside the default boot manager.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc | 2 +-
 Silicon/Marvell/Armada7k8k/Armada7k8k.fdf | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc 
b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
index 8291582..0ced400 100644
--- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
+++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
@@ -454,7 +454,7 @@
   ArmPkg/Drivers/CpuDxe/CpuDxe.inf
   ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
   ArmPkg/Drivers/TimerDxe/TimerDxe.inf
-  ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf
+  MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
 
   # Platform Initialization
   Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe.inf
diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.fdf 
b/Silicon/Marvell/Armada7k8k/Armada7k8k.fdf
index e143517..d739020 100644
--- a/Silicon/Marvell/Armada7k8k/Armada7k8k.fdf
+++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.fdf
@@ -114,7 +114,7 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
   INF ArmPkg/Drivers/CpuDxe/CpuDxe.inf
   INF ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
   INF ArmPkg/Drivers/TimerDxe/TimerDxe.inf
-  INF ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf
+  INF MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
   INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
   INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
   INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
-- 
2.7.4


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39166): https://edk2.groups.io/g/devel/message/39166
Mute This Topic: https://groups.io/mt/31198636/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 02/10] MdePkg/PiFirmwareFile: fix undefined behavior in SECTION_SIZE

[Jordan Justen]

On 2019-04-15 09:15:31, Laszlo Ersek wrote:
> On 04/14/19 09:19, Jordan Justen wrote:
> > On 2019-04-12 16:31:20, Laszlo Ersek wrote:
> >> RH covscan justifiedly reports that accessing
> >> "EFI_COMMON_SECTION_HEADER.Size", which is of type UINT8[3], through a
> >> (UINT32*), is undefined behavior:
> >>
> >>> Error: OVERRUN (CWE-119):
> >>> edk2-89910a39dcfd/OvmfPkg/Sec/SecMain.c:178: overrun-local: Overrunning
> >>> array of 3 bytes at byte offset 3 by dereferencing pointer
> >>> "(UINT32 *)((EFI_COMMON_SECTION_HEADER *)(UINTN)Section)->Size".
> >>> #  176|   Section = (EFI_COMMON_SECTION_HEADER*)(UINTN) 
> >>> CurrentAddress;
> >>> #  177|
> >>> #  178|-> Size = SECTION_SIZE (Section);
> >>> #  179|   if (Size < sizeof (*Section)) {
> >>> #  180| return EFI_VOLUME_CORRUPTED;
> >>
> >> Fix this by introducing EFI_COMMON_SECTION_HEADER_UNION, and expressing
> >> SECTION_SIZE() in terms of "EFI_COMMON_SECTION_HEADER_UNION.Uint32".
> >>
> >> Cc: Liming Gao 
> >> Cc: Michael D Kinney 
> >> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1710
> >> Issue: scan-1007.txt
> >> Signed-off-by: Laszlo Ersek 
> >> ---
> >>  MdePkg/Include/Pi/PiFirmwareFile.h | 10 +-
> >>  1 file changed, 9 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/MdePkg/Include/Pi/PiFirmwareFile.h 
> >> b/MdePkg/Include/Pi/PiFirmwareFile.h
> >> index a9f3bcc4eb8e..4fce8298d1c0 100644
> >> --- a/MdePkg/Include/Pi/PiFirmwareFile.h
> >> +++ b/MdePkg/Include/Pi/PiFirmwareFile.h
> >> @@ -229,16 +229,24 @@ typedef struct {
> >>///
> >>UINT8 Size[3];
> >>EFI_SECTION_TYPE  Type;
> >>///
> >>/// Declares the section type.
> >>///
> >>  } EFI_COMMON_SECTION_HEADER;
> >>
> >> +///
> >> +/// Union that permits accessing EFI_COMMON_SECTION_HEADER as a UINT32 
> >> object.
> >> +///
> >> +typedef union {
> >> +  EFI_COMMON_SECTION_HEADER Hdr;
> >> +  UINT32Uint32;
> >> +} EFI_COMMON_SECTION_HEADER_UNION;
> >> +
> >>  typedef struct {
> >>///
> >>/// A 24-bit unsigned integer that contains the total size of the 
> >> section in bytes,
> >>/// including the EFI_COMMON_SECTION_HEADER.
> >>///
> >>UINT8 Size[3];
> >>
> >>EFI_SECTION_TYPE  Type;
> >> @@ -476,17 +484,17 @@ typedef struct {
> >>/// A UINT16 that represents a particular build. Subsequent builds have 
> >> monotonically
> >>/// increasing build numbers relative to earlier builds.
> >>///
> >>UINT16BuildNumber;
> >>CHAR16VersionString[1];
> >>  } EFI_VERSION_SECTION2;
> >>
> >>  #define SECTION_SIZE(SectionHeaderPtr) \
> >> -((UINT32) (*((UINT32 *) ((EFI_COMMON_SECTION_HEADER *) (UINTN) 
> >> SectionHeaderPtr)->Size) & 0x00ff))
> >> +(((EFI_COMMON_SECTION_HEADER_UNION *) (UINTN) 
> >> (SectionHeaderPtr))->Uint32 & 0x00ff)
> > 
> > Mike, all,
> > 
> > Can we add a typedef for EFI_COMMON_SECTION_HEADER_UNION if it's not
> > in the PI spec?
> > 
> > If it's not allowed, I think something like this might work too:
> > 
> > #define SECTION_SIZE(SectionHeaderPtr) \
> > (*((UINT32*)(UINTN)(SectionHeaderPtr)) & 0x00ff)
> 
> (Less importantly:)
> 
> It might shut up the static analyzer, but regarding the C standard, it's
> equally undefined behavior.

I think you are still accessing it through a UINT32*, since you are
using a pointer to a union, and an field of type UINT32 within the
union.

I guess it might more well defined to shift the bytes, like is
sometimes done with the FFS file sizes.

-Jordan

> Anyway I don't feel too strongly about this, given that we disable the
> strict aliasing / effective type rules in "tools_def.template"
> ("-fno-strict-aliasing").
> 
> > Then again, I see SECTION_SIZE is not in the spec, so maybe it's ok to
> > add the typedef.
> 
> (More importantly:)
> 
> Indeed the doubt you voice about ..._UNION crossed my mind, but then I
> too searched the PI spec for SECTION_SIZE, with no hits.
> 
> Beyond that, I searched both the PI and UEFI specs, for "_UNION" --
> again no hits, despite our definitions of:
> 
> - EFI_IMAGE_OPTIONAL_HEADER_UNION
> - EFI_GRAPHICS_OUTPUT_BLT_PIXEL_UNION
> 
> in
> 
> - "MdePkg/Include/IndustryStandard/PeImage.h"
> - "MdePkg/Include/Protocol/GraphicsOutput.h"
> 
> respectively.
> 
> Thanks,
> Laszlo
> 
> > 
> > -Jordan
> > 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39161): https://edk2.groups.io/g/devel/message/39161
Mute This Topic: https://groups.io/mt/31070302/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 02/10] MdePkg/PiFirmwareFile: fix undefined behavior in SECTION_SIZE

[Liming Gao]

Laszlo:
  I think it is OK to add UNION type. UNION is not new data structure. It is 
convenience for developer to consume the data structure. This change is good to 
me. Reviewed-by: Liming Gao 

Thanks
Liming
>-Original Message-
>From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>Laszlo Ersek
>Sent: Tuesday, April 16, 2019 12:16 AM
>To: Justen, Jordan L ; edk2-devel-groups-io
>; Kinney, Michael D 
>Cc: Gao, Liming 
>Subject: Re: [edk2-devel] [PATCH 02/10] MdePkg/PiFirmwareFile: fix
>undefined behavior in SECTION_SIZE
>
>On 04/14/19 09:19, Jordan Justen wrote:
>> On 2019-04-12 16:31:20, Laszlo Ersek wrote:
>>> RH covscan justifiedly reports that accessing
>>> "EFI_COMMON_SECTION_HEADER.Size", which is of type UINT8[3],
>through a
>>> (UINT32*), is undefined behavior:
>>>
 Error: OVERRUN (CWE-119):
 edk2-89910a39dcfd/OvmfPkg/Sec/SecMain.c:178: overrun-local:
>Overrunning
 array of 3 bytes at byte offset 3 by dereferencing pointer
 "(UINT32 *)((EFI_COMMON_SECTION_HEADER *)(UINTN)Section)-
>>Size".
 #  176|   Section = (EFI_COMMON_SECTION_HEADER*)(UINTN)
>CurrentAddress;
 #  177|
 #  178|-> Size = SECTION_SIZE (Section);
 #  179|   if (Size < sizeof (*Section)) {
 #  180| return EFI_VOLUME_CORRUPTED;
>>>
>>> Fix this by introducing EFI_COMMON_SECTION_HEADER_UNION, and
>expressing
>>> SECTION_SIZE() in terms of
>"EFI_COMMON_SECTION_HEADER_UNION.Uint32".
>>>
>>> Cc: Liming Gao 
>>> Cc: Michael D Kinney 
>>> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1710
>>> Issue: scan-1007.txt
>>> Signed-off-by: Laszlo Ersek 
>>> ---
>>>  MdePkg/Include/Pi/PiFirmwareFile.h | 10 +-
>>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/MdePkg/Include/Pi/PiFirmwareFile.h
>b/MdePkg/Include/Pi/PiFirmwareFile.h
>>> index a9f3bcc4eb8e..4fce8298d1c0 100644
>>> --- a/MdePkg/Include/Pi/PiFirmwareFile.h
>>> +++ b/MdePkg/Include/Pi/PiFirmwareFile.h
>>> @@ -229,16 +229,24 @@ typedef struct {
>>>///
>>>UINT8 Size[3];
>>>EFI_SECTION_TYPE  Type;
>>>///
>>>/// Declares the section type.
>>>///
>>>  } EFI_COMMON_SECTION_HEADER;
>>>
>>> +///
>>> +/// Union that permits accessing EFI_COMMON_SECTION_HEADER as a
>UINT32 object.
>>> +///
>>> +typedef union {
>>> +  EFI_COMMON_SECTION_HEADER Hdr;
>>> +  UINT32Uint32;
>>> +} EFI_COMMON_SECTION_HEADER_UNION;
>>> +
>>>  typedef struct {
>>>///
>>>/// A 24-bit unsigned integer that contains the total size of the 
>>> section in
>bytes,
>>>/// including the EFI_COMMON_SECTION_HEADER.
>>>///
>>>UINT8 Size[3];
>>>
>>>EFI_SECTION_TYPE  Type;
>>> @@ -476,17 +484,17 @@ typedef struct {
>>>/// A UINT16 that represents a particular build. Subsequent builds have
>monotonically
>>>/// increasing build numbers relative to earlier builds.
>>>///
>>>UINT16BuildNumber;
>>>CHAR16VersionString[1];
>>>  } EFI_VERSION_SECTION2;
>>>
>>>  #define SECTION_SIZE(SectionHeaderPtr) \
>>> -((UINT32) (*((UINT32 *) ((EFI_COMMON_SECTION_HEADER *) (UINTN)
>SectionHeaderPtr)->Size) & 0x00ff))
>>> +(((EFI_COMMON_SECTION_HEADER_UNION *) (UINTN)
>(SectionHeaderPtr))->Uint32 & 0x00ff)
>>
>> Mike, all,
>>
>> Can we add a typedef for EFI_COMMON_SECTION_HEADER_UNION if it's
>not
>> in the PI spec?
>>
>> If it's not allowed, I think something like this might work too:
>>
>> #define SECTION_SIZE(SectionHeaderPtr) \
>> (*((UINT32*)(UINTN)(SectionHeaderPtr)) & 0x00ff)
>
>(Less importantly:)
>
>It might shut up the static analyzer, but regarding the C standard, it's
>equally undefined behavior.
>
>Anyway I don't feel too strongly about this, given that we disable the
>strict aliasing / effective type rules in "tools_def.template"
>("-fno-strict-aliasing").
>
>> Then again, I see SECTION_SIZE is not in the spec, so maybe it's ok to
>> add the typedef.
>
>(More importantly:)
>
>Indeed the doubt you voice about ..._UNION crossed my mind, but then I
>too searched the PI spec for SECTION_SIZE, with no hits.
>
>Beyond that, I searched both the PI and UEFI specs, for "_UNION" --
>again no hits, despite our definitions of:
>
>- EFI_IMAGE_OPTIONAL_HEADER_UNION
>- EFI_GRAPHICS_OUTPUT_BLT_PIXEL_UNION
>
>in
>
>- "MdePkg/Include/IndustryStandard/PeImage.h"
>- "MdePkg/Include/Protocol/GraphicsOutput.h"
>
>respectively.
>
>Thanks,
>Laszlo
>
>>
>> -Jordan
>>
>
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39157): https://edk2.groups.io/g/devel/message/39157
Mute This Topic: https://groups.io/mt/31070302/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2] BaseTools: Remove the unnecessary copy action for module output files

[Liming Gao]

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

In v2, keep copy output image into $(BIN_DIR), the platform still uses
the output file in $(BIN_DIR).

Signed-off-by: Liming Gao 
Cc: Bob Feng 
---
 BaseTools/Conf/build_rule.template | 17 ++---
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/BaseTools/Conf/build_rule.template 
b/BaseTools/Conf/build_rule.template
index 030e74c35a..dbb68c62fb 100755
--- a/BaseTools/Conf/build_rule.template
+++ b/BaseTools/Conf/build_rule.template
@@ -357,34 +357,21 @@
 
 
 "$(GENFW)" -e $(MODULE_TYPE) -o ${dst} ${src} $(GENFW_FLAGS)
-$(CP) ${dst} $(DEBUG_DIR)
 $(CP) ${dst} $(BIN_DIR)(+)$(MODULE_NAME_GUID).efi
--$(CP) $(DEBUG_DIR)(+)*.map $(OUTPUT_DIR)
--$(CP) $(DEBUG_DIR)(+)*.pdb $(OUTPUT_DIR) 
+
 
 $(CP) ${src} $(DEBUG_DIR)(+)$(MODULE_NAME).debug
 $(OBJCOPY) --strip-unneeded -R .eh_frame ${src}
-
-#
-#The below 2 lines are only needed for UNIXGCC tool chain, which 
generates PE image directly
-#
--$(OBJCOPY) $(OBJCOPY_ADDDEBUGFLAG) ${src}
--$(CP) $(DEBUG_DIR)(+)$(MODULE_NAME).debug 
$(BIN_DIR)(+)$(MODULE_NAME_GUID).debug
-
 "$(GENFW)" -e $(MODULE_TYPE) -o ${dst} ${src} $(GENFW_FLAGS)
-$(CP) ${dst} $(DEBUG_DIR)
 $(CP) ${dst} $(BIN_DIR)(+)$(MODULE_NAME_GUID).efi
--$(CP) $(DEBUG_DIR)(+)*.map $(OUTPUT_DIR)
-
+
 
 # tool to convert Mach-O to PE/COFF
 "$(MTOC)" -subsystem $(MODULE_TYPE)  $(MTOC_FLAGS)  ${src}  
$(DEBUG_DIR)(+)$(MODULE_NAME).pecoff
 # create symbol file for GDB debug
 -$(DSYMUTIL) ${src}
 "$(GENFW)" -e $(MODULE_TYPE) -o ${dst} 
$(DEBUG_DIR)(+)$(MODULE_NAME).pecoff $(GENFW_FLAGS)
-$(CP) ${dst} $(DEBUG_DIR)
 $(CP) ${dst} $(BIN_DIR)(+)$(MODULE_NAME_GUID).efi
--$(CP) $(DEBUG_DIR)(+)*.map $(OUTPUT_DIR)
 
 [Dependency-Expression-File]
 
-- 
2.13.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39156): https://edk2.groups.io/g/devel/message/39156
Mute This Topic: https://groups.io/mt/31198263/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V2] BaseTools:update ConvertFceToStructurePcd.py with the char order PCD name.

[Liming Gao]

Reviewed-by: Liming Gao 

>-Original Message-
>From: Fan, ZhijuX
>Sent: Monday, April 15, 2019 4:55 PM
>To: devel@edk2.groups.io
>Cc: Gao, Liming ; Feng, Bob C 
>Subject: [PATCH V2] BaseTools:update ConvertFceToStructurePcd.py with the
>char order PCD name.
>
>BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1718
>
>BaseTools\Scripts\ConvertFceToStructurePcd.py
>This script is for sorting the PCD order them
>base on PcdName, then base on Pcd field name.
>
>Cc: Liming Gao 
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Zhiju.Fan 
>---
> BaseTools/Scripts/ConvertFceToStructurePcd.py | 5 +
> 1 file changed, 5 insertions(+)
>
>diff --git a/BaseTools/Scripts/ConvertFceToStructurePcd.py
>b/BaseTools/Scripts/ConvertFceToStructurePcd.py
>index c65cb555af..89e6a727a2 100644
>--- a/BaseTools/Scripts/ConvertFceToStructurePcd.py
>+++ b/BaseTools/Scripts/ConvertFceToStructurePcd.py
>@@ -506,6 +506,8 @@ class mainprocess(object):
> for i in range(len(info_list)-1,-1,-1):
>   if len(info_list[i]) == 0:
> info_list.remove(info_list[i])
>+for i in (inf_list, title_all, header_list):
>+  i.sort()
> return keys,title_all,info_list,header_list,inf_list
>
>   def remove_bracket(self,List):
>@@ -517,6 +519,9 @@ class mainprocess(object):
>   List[List.index(i)][i.index(j)] = "|".join(tmp)
> else:
>   List[List.index(i)][i.index(j)] = j
>+for i in List:
>+  if type(i) == type([0,0]):
>+i.sort()
> return List
>
>   def write_all(self):
>--
>2.14.1.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39155): https://edk2.groups.io/g/devel/message/39155
Mute This Topic: https://groups.io/mt/31186060/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-