[edk2-devel] [edk2-platform][PATCH v1 1/1] Platforms/RaspberryPi: Add SMBIOS Type 11

[Samer El-Haj-Mahmoud]

SMBIOS Type 11 (OEM Strings) is recommended in SBBR 1.2.
Add a simlpe implementation to the RPi.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Andrei Warkentin 
Cc: Pete Batard 
Signed-off-by: Samer El-Haj-Mahmoud 
---
 Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c | 27 

 1 file changed, 27 insertions(+)

diff --git a/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c 
b/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
index 7b86e76a1248..f336084520a9 100644
--- a/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
+++ b/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
@@ -389,6 +389,20 @@ CHAR8 *mSysSlotInfoType9Strings[] = {
   NULL
 };
 
+
+/***
+SMBIOS data definition  TYPE 11  OEM Strings
+/
+
+SMBIOS_TABLE_TYPE11 mOemStringsType11 = {
+  { EFI_SMBIOS_TYPE_OEM_STRINGS, sizeof (SMBIOS_TABLE_TYPE11), 
SMBIOS_HANDLE_PI_RESERVED },
+  1 // StringCount
+};
+CHAR8 *mOemStringsType11Strings[] = {
+  "https://github/tianocore/edk2-platforms/Platform/RaspberryPi/;,
+  NULL
+};
+
 /***
 SMBIOS data definition  TYPE16  Physical Memory ArrayInformation
 /
@@ -854,6 +868,17 @@ SysSlotInfoUpdateSmbiosType9 (
   LogSmbiosData ((EFI_SMBIOS_TABLE_HEADER*), 
mSysSlotInfoType9Strings, NULL);
 }
 
+/***
+SMBIOS data update  TYPE11  OEM Strings
+/
+VOID
+OemStringsUpdateSmbiosType11 (
+  VOID
+  )
+{
+  LogSmbiosData ((EFI_SMBIOS_TABLE_HEADER*), 
mOemStringsType11Strings, NULL);
+}
+
 /***
 SMBIOS data update  TYPE16  Physical Memory Array Information
 /
@@ -961,6 +986,8 @@ PlatformSmbiosDriverEntryPoint (
 
   SysSlotInfoUpdateSmbiosType9 ();
 
+  OemStringsUpdateSmbiosType11 ();
+
   PhyMemArrayInfoUpdateSmbiosType16 ();
 
   MemDevInfoUpdateSmbiosType17 ();
-- 
2.17.1


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

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

[edk2-devel] [edk2-platform][PATCH v1 1/1] Platforms/RaspberryPi: Fix SMBIOS Type 9

[Samer El-Haj-Mahmoud]

FWTS reports an error with SMBIOS Type 9 Segment-Bus-DevFunc fields.
The SMBIOS specification requires that for non-PCIe slot devices to have
these fields reported as 0xF-0xFF-xFF. Instead, they were being
reported as 0x-0x00-0x00.

This fixes the FWTS SMBIOS Type 9 failure reported here:
https://github.com/pftf/RPi4/issues/75

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Andrei Warkentin 
Cc: Pete Batard 
Signed-off-by: Samer El-Haj-Mahmoud 
---
 Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c 
b/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
index 7b86e76a1248..78bdda18eb2d 100644
--- a/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
+++ b/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
@@ -380,9 +380,9 @@ SMBIOS_TABLE_TYPE9  mSysSlotInfoType9 = {
 0,  // SmbusSignalSupported:1;
 0,  // Reserved:5;  ///< Set to 0.
   },
-  0,// SegmentGroupNum;
-  0,// BusNum;
-  0,// DevFuncNum;
+  0x, // SegmentGroupNum;
+  0xFF,   // BusNum;
+  0xFF,   // DevFuncNum;
 };
 CHAR8 *mSysSlotInfoType9Strings[] = {
   "SD Card",
-- 
2.17.1


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

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

[edk2-devel] [patch] MdeModulePkg/DisplayEngine: Add Debug message to show mismatch menu info

[Dandan Bi]

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

Currently when meet mismatch case for one-of and ordered-list
menu, just show a popup window to indicate mismatch, no more
info for debugging. This patch is to add more debug message
about mismatch menu info which is helpful to debug.

Cc: Liming Gao 
Cc: Eric Dong 
Signed-off-by: Dandan Bi 
---
 .../DisplayEngineDxe/ProcessOptions.c | 78 +++
 1 file changed, 78 insertions(+)

diff --git a/MdeModulePkg/Universal/DisplayEngineDxe/ProcessOptions.c 
b/MdeModulePkg/Universal/DisplayEngineDxe/ProcessOptions.c
index e7306f6d04..4331b2903c 100644
--- a/MdeModulePkg/Universal/DisplayEngineDxe/ProcessOptions.c
+++ b/MdeModulePkg/Universal/DisplayEngineDxe/ProcessOptions.c
@@ -911,10 +911,73 @@ PasswordProcess (
   FreePool (StringPtr);
 
   return Status;
 }
 
+/**
+  Print some debug message about mismatched menu info.
+
+  @param  MenuOption The MenuOption for this Question.
+
+**/
+VOID
+PrintMismatchMenuInfo (
+  IN  UI_MENU_OPTION  *MenuOption
+)
+{
+  CHAR16  *FormTitleStr;
+  CHAR16  *OneOfOptionStr;
+  CHAR16  *QuestionName;
+  LIST_ENTRY  *Link;
+  FORM_DISPLAY_ENGINE_STATEMENT   *Question;
+  EFI_IFR_ORDERED_LIST*OrderList;
+  UINTN   Index;
+  EFI_HII_VALUE   HiiValue;
+  EFI_HII_VALUE   *QuestionValue;
+  DISPLAY_QUESTION_OPTION *Option;
+  UINT8   *ValueArray;
+  UINT8   ValueType;
+
+  Question = MenuOption->ThisTag;
+  FormTitleStr = GetToken (gFormData->FormTitle, gFormData->HiiHandle);
+
+  DEBUG ((DEBUG_ERROR, "\n[DisplayEngine]: Mismatch Formset: Formset Guid 
= %g.\n", >FormSetGuid));
+  DEBUG ((DEBUG_ERROR, "[DisplayEngine]: Mismatch Form   : FormId = %d,  
Form title = %s.\n", gFormData->FormId, FormTitleStr));
+
+  if (Question->OpCode->OpCode == EFI_IFR_ORDERED_LIST_OP) {
+QuestionName = GetToken 
(((EFI_IFR_ORDERED_LIST*)MenuOption->ThisTag->OpCode)->Question.Header.Prompt, 
gFormData->HiiHandle);
+Link = GetFirstNode (>OptionListHead);
+Option = DISPLAY_QUESTION_OPTION_FROM_LINK (Link);
+ValueType = Option->OptionOpCode->Type;
+
+DEBUG ((DEBUG_ERROR, "[DisplayEngine]: Mismatch OrderedList: Name = 
%s.\n", QuestionName));
+DEBUG ((DEBUG_ERROR, "[DisplayEngine]: Mismatch OrderedList: Value 
Arrary:\n"));
+
+OrderList = (EFI_IFR_ORDERED_LIST *) Question->OpCode;
+for (Index = 0; Index < OrderList->MaxContainers; Index++) {
+  ValueArray = Question->CurrentValue.Buffer;
+  HiiValue.Value.u64 = GetArrayData (ValueArray, ValueType, Index);
+  DEBUG ((DEBUG_ERROR, "   Value[%d] 
=%d.\n",Index, HiiValue.Value.u64));
+}
+  } else if (Question->OpCode->OpCode == EFI_IFR_ONE_OF_OP) {
+QuestionName = GetToken 
(((EFI_IFR_ONE_OF*)MenuOption->ThisTag->OpCode)->Question.Header.Prompt, 
gFormData->HiiHandle);
+QuestionValue = >CurrentValue;;
+DEBUG ((DEBUG_ERROR, "[DisplayEngine]: Mismatch OneOf  : Named = 
%s.\n", QuestionName));
+DEBUG ((DEBUG_ERROR, "[DisplayEngine]: Mismatch OneOf  : Current value 
= %d.\n",QuestionValue->Value.u8));
+  }
+
+  Index = 0;
+  Link = GetFirstNode (>OptionListHead);
+  while (!IsNull (>OptionListHead, Link)) {
+Option = DISPLAY_QUESTION_OPTION_FROM_LINK (Link);
+OneOfOptionStr = GetToken (Option->OptionOpCode->Option, 
gFormData->HiiHandle);
+DEBUG ((DEBUG_ERROR, "[DisplayEngine]: Option %d: Option Name 
= %s. Option Value = 
%d.\n",Index,OneOfOptionStr,Option->OptionOpCode->Value.u8));
+Link = GetNextNode (>OptionListHead, Link);
+Index++;
+  }
+}
+
 /**
   Process a Question's Option (whether selected or un-selected).
 
   @param  MenuOption The MenuOption for this Question.
   @param  Selected   TRUE: if Question is selected.
@@ -1010,10 +1073,15 @@ ProcessOptions (
   break;
 }
 
 OneOfOption = ValueToOption (Question, );
 if (OneOfOption == NULL) {
+  //
+  // Print debug msg for the mistach menu.
+  //
+  PrintMismatchMenuInfo (MenuOption);
+
   if (SkipErrorValue) {
 //
 // Just try to get the option string, skip the value which not has 
option.
 //
 continue;
@@ -1102,10 +1170,15 @@ ProcessOptions (
   continue;
 }
 
 if (!ValueInvalid) {
   ValueInvalid = TRUE;
+  //
+  // Print debug msg for the mistach menu.
+  //
+  PrintMismatchMenuInfo (MenuOption);
+
   //
   // Show error message
   //
   do {
 CreateDialog (, gEmptyString, gOptionMismatch, gPressEnter, 
gEmptyString, NULL);
@@ -1152,10 +1225,15 @@ ProcessOptions (
   *OptionString = 

Re: [edk2-devel] [PATCH v5 1/1] MdeModulePkg.dec: Change PCDs for status code.

[Wang, Jian J]

Ming,

Sorry for previous comment. Although build supports it, the spec doesn't allow 
such
usage. Please revert to v4. Please keep R-B for v4.

Regards,
Jian

> -Original Message-
> From: Kinney, Michael D 
> Sent: Thursday, June 18, 2020 9:47 AM
> To: Wang, Jian J ; devel@edk2.groups.io; Tan, Ming
> ; Kinney, Michael D 
> Cc: Wu, Hao A 
> Subject: RE: [edk2-devel] [PATCH v5 1/1] MdeModulePkg.dec: Change PCDs for
> status code.
> 
> Jian,
> 
> There are few rules listed in the EDK II DEC File Format
> Specification that apply here:
> 
> https://edk2-docs.gitbook.io/edk-ii-dec-
> specification/3_edk_ii_dec_file_format/310_pcd_sections
> 
> * PCD entries may be put into any or all PCD section types
>   except PcdsFeatureFlag sections.
> 
> * PCDs listed in PcdsFeatureFlag sections must only be listed
>   in PcdsFeatureFlag sections.
> 
> * The PcdsFeatureFlag PcdType may not be mixed with any
>   other PcdType elements in the section header. The following
>   example is NOT VALID:
> 
> [PcdsFeatureFlag.IA32, PcdsFixedAtBuild.IA32]
> 
> Best regards,
> 
> Mike
> 
> > -Original Message-
> > From: Wang, Jian J 
> > Sent: Wednesday, June 17, 2020 5:58 PM
> > To: Kinney, Michael D ;
> > devel@edk2.groups.io; Tan, Ming 
> > Cc: Wu, Hao A 
> > Subject: RE: [edk2-devel] [PATCH v5 1/1]
> > MdeModulePkg.dec: Change PCDs for status code.
> >
> > Mike,
> >
> > I tried to build it. There's no warnings. And it's free
> > to change type to any of them.
> > Why's there such limitation? FeatureFlag looks the same
> > as FixedAtBuild to me.
> >
> > Regards,
> > Jian
> >
> > > -Original Message-
> > > From: Kinney, Michael D 
> > > Sent: Thursday, June 18, 2020 12:47 AM
> > > To: devel@edk2.groups.io; Wang, Jian J
> > ; Tan, Ming
> > > ; Kinney, Michael D
> > 
> > > Cc: Wu, Hao A 
> > > Subject: RE: [edk2-devel] [PATCH v5 1/1]
> > MdeModulePkg.dec: Change PCDs for
> > > status code.
> > >
> > > Ming,
> > >
> > > With this change, are the same PCDs listed as both
> > > a Feature Flag PCD and a non-Feature Flag PCD?
> > >
> > > That should not be allowed, and if that passes the
> > > build, then the build tools should flag that as an
> > > error condition.
> > >
> > > Mike
> > >
> > > > -Original Message-
> > > > From: devel@edk2.groups.io  On
> > > > Behalf Of Wang, Jian J
> > > > Sent: Wednesday, June 17, 2020 7:43 AM
> > > > To: Tan, Ming ;
> > devel@edk2.groups.io
> > > > Cc: Wu, Hao A 
> > > > Subject: Re: [edk2-devel] [PATCH v5 1/1]
> > > > MdeModulePkg.dec: Change PCDs for status code.
> > > >
> > > > Reviewed-by: Jian J Wang 
> > > >
> > > > Regards,
> > > > Jian
> > > >
> > > > > -Original Message-
> > > > > From: Tan, Ming 
> > > > > Sent: Wednesday, June 17, 2020 3:36 PM
> > > > > To: devel@edk2.groups.io
> > > > > Cc: Wang, Jian J ; Wu, Hao
> > A
> > > > 
> > > > > Subject: [PATCH v5 1/1] MdeModulePkg.dec: Change
> > PCDs
> > > > for status code.
> > > > >
> > > > > REF:
> > > > https://bugzilla.tianocore.org/show_bug.cgi?id=2786
> > > > >
> > > > > In order to support enable/disable report status
> > code
> > > > through memory
> > > > > or serial dynamic, change the following PCDs from
> > > > [PcdsFeatureFlag] to
> > > > > [PcdsFixedAtBuild, PcdsPatchableInModule,
> > PcdsDynamic,
> > > > PcdsDynamicEx]:
> > > > >   PcdStatusCodeUseSerial
> > > > >   PcdStatusCodeUseMemory
> > > > > The original plaforms can use PcdsFixedAtBuild in
> > .dsc
> > > > files to save size.
> > > > > Currently do not remove the old pcd type to keep
> > > > compatible.
> > > > >
> > > > > Cc: Jian J Wang 
> > > > > Cc: Hao A Wu 
> > > > > Signed-off-by: Ming Tan 
> > > > > ---
> > > > > V5: Do not remove th old pcd type to keep
> > compatible,
> > > > and change to
> > > > > standalone patch.
> > > > > V4: No change for this 1/4 patch, just modify the
> > 2-
> > > > 4/4 patchs.
> > > > > V3: Split one patch to several patchs, each Pkg
> > has
> > > > one patch.
> > > > > V2: Change the new type from [PcdsDynamic] to
> > > > [PcdsFixedAtBuild,
> > > > > PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
> > > > > And set to PcdsFixedAtBuild in the original
> > > > platform .dsc files.
> > > > >
> > > > >  MdeModulePkg/MdeModulePkg.dec
> > | 13
> > > > +
> > > > >  .../StatusCodeHandler/Pei/StatusCodeHandlerPei.c
> > |  6
> > > > +++---
> > > > >  .../Pei/StatusCodeHandlerPei.inf
> > |  6
> > > > ++
> > > > >  .../RuntimeDxe/StatusCodeHandlerRuntimeDxe.c
> > | 16
> > > > 
> > > > >  .../RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf
> > |  6
> > > > ++
> > > > >  .../StatusCodeHandler/Smm/StatusCodeHandlerSmm.c
> > | 10
> > > > +-
> > > > >  .../Smm/StatusCodeHandlerSmm.inf
> > |  6
> > > > ++
> > > > >  7 files changed, 35 insertions(+), 28 deletions(-
> > )
> > > > >
> > > > > diff --git a/MdeModulePkg/MdeModulePkg.dec
> > > > > b/MdeModulePkg/MdeModulePkg.dec
> > > > > index 4f44af694862..bd369d1f230e 100644
> > > > > --- 

Re: [edk2-devel] [PATCH v5 1/1] MdeModulePkg.dec: Change PCDs for status code.

[Michael D Kinney]

Jian,

There are few rules listed in the EDK II DEC File Format
Specification that apply here:

https://edk2-docs.gitbook.io/edk-ii-dec-specification/3_edk_ii_dec_file_format/310_pcd_sections

* PCD entries may be put into any or all PCD section types
  except PcdsFeatureFlag sections.

* PCDs listed in PcdsFeatureFlag sections must only be listed
  in PcdsFeatureFlag sections.

* The PcdsFeatureFlag PcdType may not be mixed with any
  other PcdType elements in the section header. The following
  example is NOT VALID:

[PcdsFeatureFlag.IA32, PcdsFixedAtBuild.IA32]

Best regards,

Mike

> -Original Message-
> From: Wang, Jian J 
> Sent: Wednesday, June 17, 2020 5:58 PM
> To: Kinney, Michael D ;
> devel@edk2.groups.io; Tan, Ming 
> Cc: Wu, Hao A 
> Subject: RE: [edk2-devel] [PATCH v5 1/1]
> MdeModulePkg.dec: Change PCDs for status code.
> 
> Mike,
> 
> I tried to build it. There's no warnings. And it's free
> to change type to any of them.
> Why's there such limitation? FeatureFlag looks the same
> as FixedAtBuild to me.
> 
> Regards,
> Jian
> 
> > -Original Message-
> > From: Kinney, Michael D 
> > Sent: Thursday, June 18, 2020 12:47 AM
> > To: devel@edk2.groups.io; Wang, Jian J
> ; Tan, Ming
> > ; Kinney, Michael D
> 
> > Cc: Wu, Hao A 
> > Subject: RE: [edk2-devel] [PATCH v5 1/1]
> MdeModulePkg.dec: Change PCDs for
> > status code.
> >
> > Ming,
> >
> > With this change, are the same PCDs listed as both
> > a Feature Flag PCD and a non-Feature Flag PCD?
> >
> > That should not be allowed, and if that passes the
> > build, then the build tools should flag that as an
> > error condition.
> >
> > Mike
> >
> > > -Original Message-
> > > From: devel@edk2.groups.io  On
> > > Behalf Of Wang, Jian J
> > > Sent: Wednesday, June 17, 2020 7:43 AM
> > > To: Tan, Ming ;
> devel@edk2.groups.io
> > > Cc: Wu, Hao A 
> > > Subject: Re: [edk2-devel] [PATCH v5 1/1]
> > > MdeModulePkg.dec: Change PCDs for status code.
> > >
> > > Reviewed-by: Jian J Wang 
> > >
> > > Regards,
> > > Jian
> > >
> > > > -Original Message-
> > > > From: Tan, Ming 
> > > > Sent: Wednesday, June 17, 2020 3:36 PM
> > > > To: devel@edk2.groups.io
> > > > Cc: Wang, Jian J ; Wu, Hao
> A
> > > 
> > > > Subject: [PATCH v5 1/1] MdeModulePkg.dec: Change
> PCDs
> > > for status code.
> > > >
> > > > REF:
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=2786
> > > >
> > > > In order to support enable/disable report status
> code
> > > through memory
> > > > or serial dynamic, change the following PCDs from
> > > [PcdsFeatureFlag] to
> > > > [PcdsFixedAtBuild, PcdsPatchableInModule,
> PcdsDynamic,
> > > PcdsDynamicEx]:
> > > >   PcdStatusCodeUseSerial
> > > >   PcdStatusCodeUseMemory
> > > > The original plaforms can use PcdsFixedAtBuild in
> .dsc
> > > files to save size.
> > > > Currently do not remove the old pcd type to keep
> > > compatible.
> > > >
> > > > Cc: Jian J Wang 
> > > > Cc: Hao A Wu 
> > > > Signed-off-by: Ming Tan 
> > > > ---
> > > > V5: Do not remove th old pcd type to keep
> compatible,
> > > and change to
> > > > standalone patch.
> > > > V4: No change for this 1/4 patch, just modify the
> 2-
> > > 4/4 patchs.
> > > > V3: Split one patch to several patchs, each Pkg
> has
> > > one patch.
> > > > V2: Change the new type from [PcdsDynamic] to
> > > [PcdsFixedAtBuild,
> > > > PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
> > > > And set to PcdsFixedAtBuild in the original
> > > platform .dsc files.
> > > >
> > > >  MdeModulePkg/MdeModulePkg.dec
> | 13
> > > +
> > > >  .../StatusCodeHandler/Pei/StatusCodeHandlerPei.c
> |  6
> > > +++---
> > > >  .../Pei/StatusCodeHandlerPei.inf
> |  6
> > > ++
> > > >  .../RuntimeDxe/StatusCodeHandlerRuntimeDxe.c
> | 16
> > > 
> > > >  .../RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf
> |  6
> > > ++
> > > >  .../StatusCodeHandler/Smm/StatusCodeHandlerSmm.c
> | 10
> > > +-
> > > >  .../Smm/StatusCodeHandlerSmm.inf
> |  6
> > > ++
> > > >  7 files changed, 35 insertions(+), 28 deletions(-
> )
> > > >
> > > > diff --git a/MdeModulePkg/MdeModulePkg.dec
> > > > b/MdeModulePkg/MdeModulePkg.dec
> > > > index 4f44af694862..bd369d1f230e 100644
> > > > --- a/MdeModulePkg/MdeModulePkg.dec
> > > > +++ b/MdeModulePkg/MdeModulePkg.dec
> > > > @@ -2001,6 +2001,19 @@ [PcdsFixedAtBuild,
> > > PcdsPatchableInModule,
> > > > PcdsDynamic, PcdsDynamicEx]
> > > ># @Prompt TCG Platform Firmware Profile
> revision.
> > > >
> > > >
> > >
> gEfiMdeModulePkgTokenSpaceGuid.PcdTcgPfpMeasurementRevis
> > > ion|0|UINT3
> > > > 2|0x00010077
> > > >
> > > > +  ## Indicates if StatusCode is reported via
> Serial
> > > port.
> > > > +  #   TRUE  - Reports StatusCode via Serial
> port.
> > > > +  #   FALSE - Does not report StatusCode via
> Serial
> > > port.
> > > > +  # @Prompt Enable StatusCode via Serial port.
> > > > +
> > > >
> > >
> gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|TR
> > > UE|BOOLEAN|
> > > > 0x00010022
> > > > +
> 

Re: [edk2-devel] [BaseTools PATCH v1] BaseTools: Add OpenSBI external definitions for RISC-V assembly build

[Abner Chang]

Sure YuWei,  v2 patch is sent.

Thanks
Abner

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Yuwei Chen
> Sent: Wednesday, June 17, 2020 4:51 PM
> To: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist)
> 
> Cc: Feng, Bob C ; Gao, Liming
> ; Schaefer, Daniel (DualStudy)
> ; Leif Lindholm 
> Subject: Re: [edk2-devel] [BaseTools PATCH v1] BaseTools: Add OpenSBI
> external definitions for RISC-V assembly build
> 
> Hi, abner
> 
> I have a little suggestion for the patch format, it would be better if the 
> length
> of each commit line is less than 70 characters.
> You can follow the Commit Message Format in the wiki of tianocore.
> 
> Thanks,
> Yuwei
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Abner
> > Chang
> > Sent: Friday, June 12, 2020 9:57 AM
> > To: devel@edk2.groups.io
> > Cc: abner.ch...@hpe.com; Feng, Bob C ; Gao,
> > Liming ; Daniel Schaefer
> > ; Leif Lindholm 
> > Subject: [edk2-devel] [BaseTools PATCH v1] BaseTools: Add OpenSBI
> > external definitions for RISC-V assembly build
> >
> > Add opensbi external definitions to RISC-V build for assembly code.
> > Use GCC5_RISCV_OPENSBI_TYPES to refer to edk2 data type for assembly
> > files instead of using opensbi data type.
> >
> > Signed-off-by: Abner Chang 
> >
> > Cc: Bob Feng 
> > Cc: Liming Gao 
> > Cc: Daniel Schaefer 
> > Cc: Leif Lindholm 
> > ---
> >  BaseTools/Conf/tools_def.template | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/BaseTools/Conf/tools_def.template
> > b/BaseTools/Conf/tools_def.template
> > index 923517b5c2..8aeb8a2a64 100755
> > --- a/BaseTools/Conf/tools_def.template
> > +++ b/BaseTools/Conf/tools_def.template
> > @@ -2037,6 +2037,7 @@ DEFINE GCC5_RISCV64_CC_FLAGS   =
> > DEF(GCC5_RISCV_ALL_CC_FLAGS) DEF(GC
> >  DEFINE GCC5_RISCV64_DLINK_FLAGS=
> > DEF(GCC5_RISCV_ALL_DLINK_FLAGS) -Wl,-melf64lriscv,--oformat=elf64-
> > littleriscv,--no-relax DEFINE GCC5_RISCV64_DLINK2_FLAGS   =
> > DEF(GCC5_RISCV_ALL_DLINK2_FLAGS) DEFINE
> GCC5_RISCV64_ASM_FLAGS =
> > DEF(GCC5_RISCV_ALL_ASM_FLAGS) -march=DEF(GCC5_RISCV64_ARCH) -
> > mcmodel=medany -mabi=lp64+DEFINE GCC_PP_FLAGS= -E -x
> > assembler-with-cpp -include AutoGen.h DEF(GCC5_RISCV_OPENSBI_TYPES)
> >
> ##
> > ## #--
> > 2.25.0
> >
> >
> > -=-=-=-=-=-=
> > Groups.io Links: You receive all messages sent to this group.
> >
> > View/Reply Online (#61183):
> > INVALID URI REMOVED
> 3A__edk2.groups.io_g_
> >
> devel_message_61183=DwIFAg=C5b8zRQO1miGmBeVZ2LFWg=_SN
> 6FZBN4Vgi4U
> >
> lkskz6qU3NYRO03nHp9P7Z5q59A3E=HQziIqz4xGRFswhRjSdNcWvHjUyN5
> ERpayXlIA
> > wzXVQ=zErLdJ3LY3S3GTWvOAUkqNPWIFoCzpYBs1z5cDrsVCY=
> > Mute This Topic:
> > INVALID URI REMOVED
> 3A__groups.io_mt_7483
> >
> 2499_4546272=DwIFAg=C5b8zRQO1miGmBeVZ2LFWg=_SN6FZBN4V
> gi4Ulkskz6q
> >
> U3NYRO03nHp9P7Z5q59A3E=HQziIqz4xGRFswhRjSdNcWvHjUyN5ERpayXl
> IAwzXVQ
> > =UG89s-i8w3cuIc12SggVYjjyUFkm-qVV0jHf1QBpgJc=
> > Group Owner: devel+ow...@edk2.groups.io
> > Unsubscribe:
> > INVALID URI REMOVED
> 3A__edk2.groups.io_g_
> >
> devel_unsub=DwIFAg=C5b8zRQO1miGmBeVZ2LFWg=_SN6FZBN4Vgi
> 4Ulkskz6qU
> >
> 3NYRO03nHp9P7Z5q59A3E=HQziIqz4xGRFswhRjSdNcWvHjUyN5ERpayXlI
> AwzXVQ=
> > fL7a3sHzOxEGfYK7Nw8RAwRqQhjuOfNdhjyiGAlamyc=
> > [yuwei.c...@intel.com] -=-=-=-=-=-=
> 
> 
> 


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

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

[edk2-devel] [BaseTools PATCH v2] BaseTools: Add external definitions for RISC-V assembly build

[Abner Chang]

Add opensbi external definitions to RISC-V build for assembly
code. Use GCC5_RISCV_OPENSBI_TYPES to refer to edk2 data type
for assembly files instead of using opensbi data type.

Signed-off-by: Abner Chang 

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Daniel Schaefer 
Cc: Leif Lindholm 
---
 BaseTools/Conf/tools_def.template | 1 +
 1 file changed, 1 insertion(+)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 923517b5c2..8aeb8a2a64 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -2037,6 +2037,7 @@ DEFINE GCC5_RISCV64_CC_FLAGS   = 
DEF(GCC5_RISCV_ALL_CC_FLAGS) DEF(GC
 DEFINE GCC5_RISCV64_DLINK_FLAGS= DEF(GCC5_RISCV_ALL_DLINK_FLAGS) 
-Wl,-melf64lriscv,--oformat=elf64-littleriscv,--no-relax
 DEFINE GCC5_RISCV64_DLINK2_FLAGS   = DEF(GCC5_RISCV_ALL_DLINK2_FLAGS)
 DEFINE GCC5_RISCV64_ASM_FLAGS  = DEF(GCC5_RISCV_ALL_ASM_FLAGS) 
-march=DEF(GCC5_RISCV64_ARCH) -mcmodel=medany -mabi=lp64
+DEFINE GCC_PP_FLAGS= -E -x assembler-with-cpp -include 
AutoGen.h DEF(GCC5_RISCV_OPENSBI_TYPES)
 
 

 #
-- 
2.25.0


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

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

Re: [edk2-devel] [PATCH v5 1/1] MdeModulePkg.dec: Change PCDs for status code.

[Wang, Jian J]

Mike,

I tried to build it. There's no warnings. And it's free to change type to any 
of them.
Why's there such limitation? FeatureFlag looks the same as FixedAtBuild to me.

Regards,
Jian

> -Original Message-
> From: Kinney, Michael D 
> Sent: Thursday, June 18, 2020 12:47 AM
> To: devel@edk2.groups.io; Wang, Jian J ; Tan, Ming
> ; Kinney, Michael D 
> Cc: Wu, Hao A 
> Subject: RE: [edk2-devel] [PATCH v5 1/1] MdeModulePkg.dec: Change PCDs for
> status code.
> 
> Ming,
> 
> With this change, are the same PCDs listed as both
> a Feature Flag PCD and a non-Feature Flag PCD?
> 
> That should not be allowed, and if that passes the
> build, then the build tools should flag that as an
> error condition.
> 
> Mike
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On
> > Behalf Of Wang, Jian J
> > Sent: Wednesday, June 17, 2020 7:43 AM
> > To: Tan, Ming ; devel@edk2.groups.io
> > Cc: Wu, Hao A 
> > Subject: Re: [edk2-devel] [PATCH v5 1/1]
> > MdeModulePkg.dec: Change PCDs for status code.
> >
> > Reviewed-by: Jian J Wang 
> >
> > Regards,
> > Jian
> >
> > > -Original Message-
> > > From: Tan, Ming 
> > > Sent: Wednesday, June 17, 2020 3:36 PM
> > > To: devel@edk2.groups.io
> > > Cc: Wang, Jian J ; Wu, Hao A
> > 
> > > Subject: [PATCH v5 1/1] MdeModulePkg.dec: Change PCDs
> > for status code.
> > >
> > > REF:
> > https://bugzilla.tianocore.org/show_bug.cgi?id=2786
> > >
> > > In order to support enable/disable report status code
> > through memory
> > > or serial dynamic, change the following PCDs from
> > [PcdsFeatureFlag] to
> > > [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic,
> > PcdsDynamicEx]:
> > >   PcdStatusCodeUseSerial
> > >   PcdStatusCodeUseMemory
> > > The original plaforms can use PcdsFixedAtBuild in .dsc
> > files to save size.
> > > Currently do not remove the old pcd type to keep
> > compatible.
> > >
> > > Cc: Jian J Wang 
> > > Cc: Hao A Wu 
> > > Signed-off-by: Ming Tan 
> > > ---
> > > V5: Do not remove th old pcd type to keep compatible,
> > and change to
> > > standalone patch.
> > > V4: No change for this 1/4 patch, just modify the 2-
> > 4/4 patchs.
> > > V3: Split one patch to several patchs, each Pkg has
> > one patch.
> > > V2: Change the new type from [PcdsDynamic] to
> > [PcdsFixedAtBuild,
> > > PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
> > > And set to PcdsFixedAtBuild in the original
> > platform .dsc files.
> > >
> > >  MdeModulePkg/MdeModulePkg.dec| 13
> > +
> > >  .../StatusCodeHandler/Pei/StatusCodeHandlerPei.c |  6
> > +++---
> > >  .../Pei/StatusCodeHandlerPei.inf |  6
> > ++
> > >  .../RuntimeDxe/StatusCodeHandlerRuntimeDxe.c | 16
> > 
> > >  .../RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf   |  6
> > ++
> > >  .../StatusCodeHandler/Smm/StatusCodeHandlerSmm.c | 10
> > +-
> > >  .../Smm/StatusCodeHandlerSmm.inf |  6
> > ++
> > >  7 files changed, 35 insertions(+), 28 deletions(-)
> > >
> > > diff --git a/MdeModulePkg/MdeModulePkg.dec
> > > b/MdeModulePkg/MdeModulePkg.dec
> > > index 4f44af694862..bd369d1f230e 100644
> > > --- a/MdeModulePkg/MdeModulePkg.dec
> > > +++ b/MdeModulePkg/MdeModulePkg.dec
> > > @@ -2001,6 +2001,19 @@ [PcdsFixedAtBuild,
> > PcdsPatchableInModule,
> > > PcdsDynamic, PcdsDynamicEx]
> > ># @Prompt TCG Platform Firmware Profile revision.
> > >
> > >
> > gEfiMdeModulePkgTokenSpaceGuid.PcdTcgPfpMeasurementRevis
> > ion|0|UINT3
> > > 2|0x00010077
> > >
> > > +  ## Indicates if StatusCode is reported via Serial
> > port.
> > > +  #   TRUE  - Reports StatusCode via Serial port.
> > > +  #   FALSE - Does not report StatusCode via Serial
> > port.
> > > +  # @Prompt Enable StatusCode via Serial port.
> > > +
> > >
> > gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|TR
> > UE|BOOLEAN|
> > > 0x00010022
> > > +
> > > +  ## Indicates if StatusCode is stored in memory.
> > > +  #  The memory is boot time memory in PEI Phase and
> > is runtime memory in
> > > DXE Phase.
> > > +  #   TRUE  - Stores StatusCode in memory.
> > > +  #   FALSE - Does not store StatusCode in
> > memory.
> > > +  # @Prompt Enable StatusCode via memory.
> > > +
> > >
> > gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseMemory|FA
> > LSE|BOOLEA
> > > N|0x00010023
> > > +
> > >  [PcdsPatchableInModule]
> > >## Specify memory size with page number for PEI
> > code when
> > >#  Loading Module at Fixed Address feature is
> > enabled.
> > > diff --git
> > >
> > a/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCod
> > eHandlerPei.c
> > >
> > b/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCod
> > eHandlerPei.c
> > > index 1b07f92f3ce8..9b2ea4ee84d9 100644
> > > ---
> > a/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCod
> > eHandlerPei.c
> > > +++
> > >
> > b/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCod
> > eHandlerPei.c
> > > @@ -2,7 +2,7 @@
> > >Report Status Code Handler PEIM which produces
> > 

Re: [edk2-devel] [PATCH v7 2/2] Features/Intel/PostCodeDebugFeaturePkg: add it.

[Dandan Bi]

Reviewed-by: Dandan Bi 


Thanks,
Dandan
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Tan,
> Ming
> Sent: Tuesday, June 16, 2020 7:26 PM
> To: devel@edk2.groups.io
> Cc: Dong, Eric ; Gao, Liming 
> Subject: [edk2-devel] [PATCH v7 2/2]
> Features/Intel/PostCodeDebugFeaturePkg: add it.
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2478
> 
> The PostCodeDebugFeaturePkg include some useful post code debug
> libraries, such as get post code from status code and show it.
> 
> It provide a library PostCodeStatusCodeHandlerLib used by edk2
> StatusCodeHandler.efi, used to show the post code.
> It also provide a library of PostCodeMap lib, it map the status code
> to post code.
> 
> Cc: Eric Dong 
> Cc: Liming Gao 
> Signed-off-by: Ming Tan 
> ---
> V7: Add the dec files in AdvancedFeaturesPcd.dsc. Combine Beep and
> PostCode to 2/2 patchs.
> And change to same V7 of Beep.
> V4: In dec files, change the PcdStatusCodeUsePostCode default to FALSE.
> V3: Modify according Eric's comments.
> Modify some bugs about dsc file when it is included.
> Update Readme.md.
> V2: Delete the last empty line in
> PostCodeDebugFeaturePkg/Library/PostCodeMapLib/PostCodeMapLib.inf
>  .../Include/AdvancedFeaturesPcd.dsc   |   1 +
>  .../Include/Library/PostCodeMapLib.h  |  32 +++
>  .../Include/PostCodeDebugFeature.dsc  | 200 +
>  .../PlatformStatusCodesInternal.h | 270 ++
>  .../Library/PostCodeMapLib/PostCodeMapLib.c   | 207 ++
>  .../Library/PostCodeMapLib/PostCodeMapLib.inf |  27 ++
>  .../PeiPostCodeStatusCodeHandlerLib.c | 102 +++
>  .../PeiPostCodeStatusCodeHandlerLib.inf   |  49 
>  .../RuntimeDxePostCodeStatusCodeHandlerLib.c  | 188 
>  ...RuntimeDxePostCodeStatusCodeHandlerLib.inf |  51 
>  .../SmmPostCodeStatusCodeHandlerLib.c | 141 +
>  .../SmmPostCodeStatusCodeHandlerLib.inf   |  50 
>  .../PostCodeDebugFeaturePkg.dec   |  32 +++
>  .../PostCodeDebugFeaturePkg.dsc   |  30 ++
>  .../PostCodeDebugFeaturePkg/Readme.md | 117 
>  15 files changed, 1497 insertions(+)
>  create mode 100644
> Features/Intel/Debugging/PostCodeDebugFeaturePkg/Include/Library/Post
> CodeMapLib.h
>  create mode 100644
> Features/Intel/Debugging/PostCodeDebugFeaturePkg/Include/PostCodeDe
> bugFeature.dsc
>  create mode 100644
> Features/Intel/Debugging/PostCodeDebugFeaturePkg/Library/PostCodeMa
> pLib/PlatformStatusCodesInternal.h
>  create mode 100644
> Features/Intel/Debugging/PostCodeDebugFeaturePkg/Library/PostCodeMa
> pLib/PostCodeMapLib.c
>  create mode 100644
> Features/Intel/Debugging/PostCodeDebugFeaturePkg/Library/PostCodeMa
> pLib/PostCodeMapLib.inf
>  create mode 100644
> Features/Intel/Debugging/PostCodeDebugFeaturePkg/Library/PostCodeStat
> usCodeHandlerLib/PeiPostCodeStatusCodeHandlerLib.c
>  create mode 100644
> Features/Intel/Debugging/PostCodeDebugFeaturePkg/Library/PostCodeStat
> usCodeHandlerLib/PeiPostCodeStatusCodeHandlerLib.inf
>  create mode 100644
> Features/Intel/Debugging/PostCodeDebugFeaturePkg/Library/PostCodeStat
> usCodeHandlerLib/RuntimeDxePostCodeStatusCodeHandlerLib.c
>  create mode 100644
> Features/Intel/Debugging/PostCodeDebugFeaturePkg/Library/PostCodeStat
> usCodeHandlerLib/RuntimeDxePostCodeStatusCodeHandlerLib.inf
>  create mode 100644
> Features/Intel/Debugging/PostCodeDebugFeaturePkg/Library/PostCodeStat
> usCodeHandlerLib/SmmPostCodeStatusCodeHandlerLib.c
>  create mode 100644
> Features/Intel/Debugging/PostCodeDebugFeaturePkg/Library/PostCodeStat
> usCodeHandlerLib/SmmPostCodeStatusCodeHandlerLib.inf
>  create mode 100644
> Features/Intel/Debugging/PostCodeDebugFeaturePkg/PostCodeDebugFeat
> urePkg.dec
>  create mode 100644
> Features/Intel/Debugging/PostCodeDebugFeaturePkg/PostCodeDebugFeat
> urePkg.dsc
>  create mode 100644
> Features/Intel/Debugging/PostCodeDebugFeaturePkg/Readme.md
> 
> diff --git
> a/Features/Intel/AdvancedFeaturePkg/Include/AdvancedFeaturesPcd.dsc
> b/Features/Intel/AdvancedFeaturePkg/Include/AdvancedFeaturesPcd.dsc
> index 366b551bd3..ad248de800 100644
> ---
> a/Features/Intel/AdvancedFeaturePkg/Include/AdvancedFeaturesPcd.dsc
> +++
> b/Features/Intel/AdvancedFeaturePkg/Include/AdvancedFeaturesPcd.dsc
> @@ -25,6 +25,7 @@
>UserAuthFeaturePkg/UserAuthFeaturePkg.dec
> 
>LogoFeaturePkg/LogoFeaturePkg.dec
> 
>BeepDebugFeaturePkg/BeepDebugFeaturePkg.dec
> 
> +  PostCodeDebugFeaturePkg/PostCodeDebugFeaturePkg.dec
> 
> 
> 
>  #
> 
>  # The section below sets all PCDs to FALSE in this DSC file so the feature is
> not enabled by default.
> 
> diff --git
> a/Features/Intel/Debugging/PostCodeDebugFeaturePkg/Include/Library/Po
> stCodeMapLib.h
> b/Features/Intel/Debugging/PostCodeDebugFeaturePkg/Include/Library/Po
> stCodeMapLib.h
> new file mode 100644
> index 00..834be623a1
> --- /dev/null
> +++
> 

Re: [edk2-devel] [PATCH v7 1/2] Features/Intel/BeepDebugFeaturePkg: add it.

[Dandan Bi]

Please ignore my previous comments.
Reviewed-by: Dandan Bi 


Thanks,
Dandan
> -Original Message-
> From: Bi, Dandan
> Sent: Wednesday, June 17, 2020 4:25 PM
> To: devel@edk2.groups.io; Tan, Ming 
> Cc: Dong, Eric ; Gao, Liming 
> Subject: RE: [edk2-devel] [PATCH v7 1/2]
> Features/Intel/BeepDebugFeaturePkg: add it.
> 
> Hi Min,
> 
> I have one minor comment about the function name of
> RegisterBeepBootTimeHandlers.
> Since this is the notification function of installation of status code handler
> protocol, could you help update it to make it more readable?
> Same comment for the function RegisterPostCodeBootTimeHandlers in
> patch 2.
> 
> Thanks,
> Dandan
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Tan,
> > Ming
> > Sent: Tuesday, June 16, 2020 7:26 PM
> > To: devel@edk2.groups.io
> > Cc: Dong, Eric ; Gao, Liming 
> > Subject: [edk2-devel] [PATCH v7 1/2]
> Features/Intel/BeepDebugFeaturePkg:
> > add it.
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2792
> >
> > The BeepDebugFeaturePkg include some useful beep debug
> > libraries, such as get beep value from status code and beep.
> >
> > It provide a library BeepStatusCodeHandlerLib used by edk2
> > StatusCodeHandler.efi, used to do beep if needed.
> > It also provide a library of BeepMap lib, it map the status code
> > to beep value.
> > A library of Beep lib is needed by platform, and this pkg has a
> > Null implementation.
> >
> > Cc: Eric Dong 
> > Cc: Liming Gao 
> > Signed-off-by: Ming Tan 
> > ---
> > V7: Add the dec files in AdvancedFeaturesPcd.dsc. Combine Beep and
> > PostCode to 2/2 patchs.
> > V6: Modify some bug when include the platform dsc file. And modify
> > Readme.md.
> > V5: In .inf files, remove some useless library.
> > In RuntimeDxeBeepStatusCodeHandlerLib.c, add a variable to indicate
> > whether need unregister.
> > V4: Change Include/BeepDebugFeature.dsc, make it can be included in
> > platform dsc file.
> > V3: Modify according the Eric's review comments.
> > V2: Delete the last empty line in
> > BeepDebugFeaturePkg/Library/BeepMapLib/BeepMapLib.inf
> >  .../Include/AdvancedFeaturesPcd.dsc   |  83 +++---
> >  .../BeepDebugFeaturePkg.dec   |  36 +++
> >  .../BeepDebugFeaturePkg.dsc   |  30 ++
> >  .../Include/BeepDebugFeature.dsc  | 201 +
> >  .../Include/Library/BeepLib.h |  33 +++
> >  .../Include/Library/BeepMapLib.h  |  32 +++
> >  .../Library/BeepLib/BeepLibNull.c |  37 +++
> >  .../Library/BeepLib/BeepLibNull.inf   |  26 ++
> >  .../Library/BeepMapLib/BeepMapLib.c   | 116 
> >  .../Library/BeepMapLib/BeepMapLib.inf |  27 ++
> >  .../BeepMapLib/PlatformStatusCodesInternal.h  | 270
> > ++
> >  .../PeiBeepStatusCodeHandlerLib.c | 101 +++
> >  .../PeiBeepStatusCodeHandlerLib.inf   |  49 
> >  .../RuntimeDxeBeepStatusCodeHandlerLib.c  | 184 
> >  .../RuntimeDxeBeepStatusCodeHandlerLib.inf|  51 
> >  .../SmmBeepStatusCodeHandlerLib.c | 138 +
> >  .../SmmBeepStatusCodeHandlerLib.inf   |  50 
> >  .../Debugging/BeepDebugFeaturePkg/Readme.md   | 125 
> >  18 files changed, 1548 insertions(+), 41 deletions(-)
> >  create mode 100644
> >
> Features/Intel/Debugging/BeepDebugFeaturePkg/BeepDebugFeaturePkg.d
> > ec
> >  create mode 100644
> >
> Features/Intel/Debugging/BeepDebugFeaturePkg/BeepDebugFeaturePkg.d
> > sc
> >  create mode 100644
> >
> Features/Intel/Debugging/BeepDebugFeaturePkg/Include/BeepDebugFeat
> > ure.dsc
> >  create mode 100644
> >
> Features/Intel/Debugging/BeepDebugFeaturePkg/Include/Library/BeepLib.
> > h
> >  create mode 100644
> >
> Features/Intel/Debugging/BeepDebugFeaturePkg/Include/Library/BeepMa
> > pLib.h
> >  create mode 100644
> >
> Features/Intel/Debugging/BeepDebugFeaturePkg/Library/BeepLib/BeepLib
> > Null.c
> >  create mode 100644
> >
> Features/Intel/Debugging/BeepDebugFeaturePkg/Library/BeepLib/BeepLib
> > Null.inf
> >  create mode 100644
> >
> Features/Intel/Debugging/BeepDebugFeaturePkg/Library/BeepMapLib/Bee
> > pMapLib.c
> >  create mode 100644
> >
> Features/Intel/Debugging/BeepDebugFeaturePkg/Library/BeepMapLib/Bee
> > pMapLib.inf
> >  create mode 100644
> >
> Features/Intel/Debugging/BeepDebugFeaturePkg/Library/BeepMapLib/Plat
> > formStatusCodesInternal.h
> >  create mode 100644
> >
> Features/Intel/Debugging/BeepDebugFeaturePkg/Library/BeepStatusCode
> > HandlerLib/PeiBeepStatusCodeHandlerLib.c
> >  create mode 100644
> >
> Features/Intel/Debugging/BeepDebugFeaturePkg/Library/BeepStatusCode
> > HandlerLib/PeiBeepStatusCodeHandlerLib.inf
> >  create mode 100644
> >
> Features/Intel/Debugging/BeepDebugFeaturePkg/Library/BeepStatusCode
> > HandlerLib/RuntimeDxeBeepStatusCodeHandlerLib.c
> >  create mode 100644
> >
> Features/Intel/Debugging/BeepDebugFeaturePkg/Library/BeepStatusCode
> > 

[edk2-devel] [PATCH V2 2/2] CryptoPkg/BaseCryptLib: Add MARCO to disable the deprecated SHA1

[Gao, Zhichao]

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

SHA1 is deprecated but it is required for compatible issue.
So add a MARCO for the platform to disable the usage of SHA1 for
security.

Cc: Jian J Wang 
Cc: Xiaoyu Lu 
Cc: Jiewen Yao 
Cc: Siyuan Fu 
Cc: Michael D Kinney 
Signed-off-by: Zhichao Gao 
---
 CryptoPkg/Driver/Crypto.c | 161 ++
 CryptoPkg/Include/Library/BaseCryptLib.h  |   2 +
 .../Library/BaseCryptLib/Hash/CryptSha1.c |   3 +-
 .../BaseCryptLibOnProtocolPpi/CryptLib.c  |   2 +
 4 files changed, 167 insertions(+), 1 deletion(-)

diff --git a/CryptoPkg/Driver/Crypto.c b/CryptoPkg/Driver/Crypto.c
index 7e7e31a35e..d9096ea603 100644
--- a/CryptoPkg/Driver/Crypto.c
+++ b/CryptoPkg/Driver/Crypto.c
@@ -550,6 +550,156 @@ CryptoServiceMd5HashAll (
 }
 #endif
 
+#ifdef DISABLE_SHA1_DEPRECATED_INTERFACES
+/**
+  Retrieves the size, in bytes, of the context buffer required for SHA-1 hash 
operations.
+
+  If this interface is not supported, then return zero.
+
+  @retval  0   This interface is not supported.
+
+**/
+UINTN
+EFIAPI
+DeprecatedCryptoServiceSha1GetContextSize (
+  VOID
+  )
+{
+  return BaseCryptLibServiceDeprecated ("Sha1GetContextSize"), 0;
+}
+
+/**
+  Initializes user-supplied memory pointed by Sha1Context as SHA-1 hash 
context for
+  subsequent use.
+
+  If Sha1Context is NULL, then return FALSE.
+  If this interface is not supported, then return FALSE.
+
+  @param[out]  Sha1Context  Pointer to SHA-1 context being initialized.
+
+  @retval TRUE   SHA-1 context initialization succeeded.
+  @retval FALSE  SHA-1 context initialization failed.
+  @retval FALSE  This interface is not supported.
+
+**/
+BOOLEAN
+EFIAPI
+DeprecatedCryptoServiceSha1Init (
+  OUT  VOID  *Sha1Context
+  )
+{
+  return BaseCryptLibServiceDeprecated ("Sha1Init"), FALSE;
+}
+
+/**
+  Makes a copy of an existing SHA-1 context.
+
+  If Sha1Context is NULL, then return FALSE.
+  If NewSha1Context is NULL, then return FALSE.
+  If this interface is not supported, then return FALSE.
+
+  @param[in]  Sha1Context Pointer to SHA-1 context being copied.
+  @param[out] NewSha1Context  Pointer to new SHA-1 context.
+
+  @retval FALSE  This interface is not supported.
+
+**/
+BOOLEAN
+EFIAPI
+DeprecatedCryptoServiceSha1Duplicate (
+  IN   CONST VOID  *Sha1Context,
+  OUT  VOID*NewSha1Context
+  )
+{
+  return BaseCryptLibServiceDeprecated ("Sha1Duplicate"), FALSE;
+}
+
+/**
+  Digests the input data and updates SHA-1 context.
+
+  This function performs SHA-1 digest on a data buffer of the specified size.
+  It can be called multiple times to compute the digest of long or 
discontinuous data streams.
+  SHA-1 context should be already correctly initialized by Sha1Init(), and 
should not be finalized
+  by Sha1Final(). Behavior with invalid context is undefined.
+
+  If Sha1Context is NULL, then return FALSE.
+  If this interface is not supported, then return FALSE.
+
+  @param[in, out]  Sha1Context  Pointer to the SHA-1 context.
+  @param[in]   Data Pointer to the buffer containing the data to 
be hashed.
+  @param[in]   DataSize Size of Data buffer in bytes.
+
+  @retval FALSE  This interface is not supported.
+
+**/
+BOOLEAN
+EFIAPI
+DeprecatedCryptoServiceSha1Update (
+  IN OUT  VOID*Sha1Context,
+  IN  CONST VOID  *Data,
+  IN  UINTN   DataSize
+  )
+{
+  return BaseCryptLibServiceDeprecated ("Sha1Update"), FALSE;
+}
+
+/**
+  Completes computation of the SHA-1 digest value.
+
+  This function completes SHA-1 hash computation and retrieves the digest 
value into
+  the specified memory. After this function has been called, the SHA-1 context 
cannot
+  be used again.
+  SHA-1 context should be already correctly initialized by Sha1Init(), and 
should not be
+  finalized by Sha1Final(). Behavior with invalid SHA-1 context is undefined.
+
+  If Sha1Context is NULL, then return FALSE.
+  If HashValue is NULL, then return FALSE.
+  If this interface is not supported, then return FALSE.
+
+  @param[in, out]  Sha1Context  Pointer to the SHA-1 context.
+  @param[out]  HashValuePointer to a buffer that receives the SHA-1 
digest
+value (20 bytes).
+
+  @retval FALSE  This interface is not supported.
+
+**/
+BOOLEAN
+EFIAPI
+DeprecatedCryptoServiceSha1Final (
+  IN OUT  VOID   *Sha1Context,
+  OUT UINT8  *HashValue
+  )
+{
+  return BaseCryptLibServiceDeprecated ("Sha1Final"), FALSE;
+}
+
+/**
+  Computes the SHA-1 message digest of a input data buffer.
+
+  This function performs the SHA-1 message digest of a given data buffer, and 
places
+  the digest value into the specified memory.
+
+  If this interface is not supported, then return FALSE.
+
+  @param[in]   DataPointer to the buffer containing the data to be 
hashed.
+  @param[in]   DataSizeSize of Data buffer in bytes.
+  @param[out]  HashValue   Pointer to a buffer that receives the SHA-1 digest
+ 

[edk2-devel] [PATCH V2 0/2] CryptoPkg: Add MARCO to disable MD5 & SHA1

[Gao, Zhichao]

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

V1:
Add new PCD to disable MD5 & SHA1.
Using the PCD to remove the decalration and definition of the MD5
& SHA1 functions.

V2:
Using the MARCO as DISABLE_NEW_DEPRECATED_INTERFACES to disable the
MD5 & SHA1. This MARCO would make the platform able to disable MD5 &
SHA1 by setting the MARCO at their platform dsc file.
In the future, if MD5 and SHA1 related functions are removed totally,
we can remove all the content of MD5 & SHA1.

Cc: Jian J Wang 
Cc: Xiaoyu Lu 
Cc: Jiewen Yao 
Cc: Siyuan Fu 
Cc: Michael D Kinney 
Signed-off-by: Zhichao Gao 

Zhichao Gao (2):
  CryptoPkg/BaseCryptLib: Add MARCO to disable the deprecated MD5
  CryptoPkg/BaseCryptLib: Add MARCO to disable the deprecated SHA1

 CryptoPkg/Driver/Crypto.c | 320 ++
 CryptoPkg/Include/Library/BaseCryptLib.h  |   4 +
 .../Library/BaseCryptLib/Hash/CryptMd5.c  |   3 +-
 .../Library/BaseCryptLib/Hash/CryptSha1.c |   3 +-
 .../BaseCryptLibOnProtocolPpi/CryptLib.c  |   4 +
 5 files changed, 332 insertions(+), 2 deletions(-)

-- 
2.21.0.windows.1


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

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

[edk2-devel] [PATCH V2 1/2] CryptoPkg/BaseCryptLib: Add MARCO to disable the deprecated MD5

[Gao, Zhichao]

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

MD5 is deprecated but it is required for compatible issue.
So add a MARCO for the platform to disable the usage of MD5 for
security.

Cc: Jian J Wang 
Cc: Xiaoyu Lu 
Cc: Jiewen Yao 
Cc: Siyuan Fu 
Cc: Michael D Kinney 
Signed-off-by: Zhichao Gao 
---
 CryptoPkg/Driver/Crypto.c | 159 ++
 CryptoPkg/Include/Library/BaseCryptLib.h  |   2 +
 .../Library/BaseCryptLib/Hash/CryptMd5.c  |   3 +-
 .../BaseCryptLibOnProtocolPpi/CryptLib.c  |   2 +
 4 files changed, 165 insertions(+), 1 deletion(-)

diff --git a/CryptoPkg/Driver/Crypto.c b/CryptoPkg/Driver/Crypto.c
index 73ae566755..7e7e31a35e 100644
--- a/CryptoPkg/Driver/Crypto.c
+++ b/CryptoPkg/Driver/Crypto.c
@@ -243,6 +243,154 @@ DeprecatedCryptoServiceMd4HashAll (
   return BaseCryptLibServiceDeprecated ("Md4HashAll"), FALSE;
 }
 
+#ifdef DISABLE_MD5_DEPRECATED_INTERFACES
+/**
+  Retrieves the size, in bytes, of the context buffer required for MD5 hash 
operations.
+
+  If this interface is not supported, then return zero.
+
+  @retval  0   This interface is not supported.
+
+**/
+UINTN
+EFIAPI
+DeprecatedCryptoServiceMd5GetContextSize (
+  VOID
+  )
+{
+  return BaseCryptLibServiceDeprecated ("Md5GetContextSize"), 0;
+}
+
+/**
+  Initializes user-supplied memory pointed by Md5Context as MD5 hash context 
for
+  subsequent use.
+
+  If Md5Context is NULL, then return FALSE.
+  If this interface is not supported, then return FALSE.
+
+  @param[out]  Md5Context  Pointer to MD5 context being initialized.
+
+  @retval FALSE  This interface is not supported.
+
+**/
+BOOLEAN
+EFIAPI
+DeprecatedCryptoServiceMd5Init (
+  OUT  VOID  *Md5Context
+  )
+{
+  return BaseCryptLibServiceDeprecated ("Md5Init"), FALSE;
+}
+
+/**
+  Makes a copy of an existing MD5 context.
+
+  If Md5Context is NULL, then return FALSE.
+  If NewMd5Context is NULL, then return FALSE.
+  If this interface is not supported, then return FALSE.
+
+  @param[in]  Md5Context Pointer to MD5 context being copied.
+  @param[out] NewMd5Context  Pointer to new MD5 context.
+
+  @retval FALSE  This interface is not supported.
+
+**/
+BOOLEAN
+EFIAPI
+DeprecatedCryptoServiceMd5Duplicate (
+  IN   CONST VOID  *Md5Context,
+  OUT  VOID*NewMd5Context
+  )
+{
+  return BaseCryptLibServiceDeprecated ("Md5Init"), FALSE;
+}
+
+/**
+  Digests the input data and updates MD5 context.
+
+  This function performs MD5 digest on a data buffer of the specified size.
+  It can be called multiple times to compute the digest of long or 
discontinuous data streams.
+  MD5 context should be already correctly initialized by Md5Init(), and should 
not be finalized
+  by Md5Final(). Behavior with invalid context is undefined.
+
+  If Md5Context is NULL, then return FALSE.
+  If this interface is not supported, then return FALSE.
+
+  @param[in, out]  Md5Context  Pointer to the MD5 context.
+  @param[in]   DataPointer to the buffer containing the data to be 
hashed.
+  @param[in]   DataSizeSize of Data buffer in bytes.
+
+  @retval FALSE  This interface is not supported.
+
+**/
+BOOLEAN
+EFIAPI
+DeprecatedCryptoServiceMd5Update (
+  IN OUT  VOID*Md5Context,
+  IN  CONST VOID  *Data,
+  IN  UINTN   DataSize
+  )
+{
+  return BaseCryptLibServiceDeprecated ("Md5Init"), FALSE;
+}
+
+/**
+  Completes computation of the MD5 digest value.
+
+  This function completes MD5 hash computation and retrieves the digest value 
into
+  the specified memory. After this function has been called, the MD5 context 
cannot
+  be used again.
+  MD5 context should be already correctly initialized by Md5Init(), and should 
not be
+  finalized by Md5Final(). Behavior with invalid MD5 context is undefined.
+
+  If Md5Context is NULL, then return FALSE.
+  If HashValue is NULL, then return FALSE.
+  If this interface is not supported, then return FALSE.
+
+  @param[in, out]  Md5Context  Pointer to the MD5 context.
+  @param[out]  HashValue   Pointer to a buffer that receives the MD5 digest
+   value (16 bytes).
+
+  @retval FALSE  This interface is not supported.
+
+**/
+BOOLEAN
+EFIAPI
+DeprecatedCryptoServiceMd5Final (
+  IN OUT  VOID   *Md5Context,
+  OUT UINT8  *HashValue
+  )
+{
+  return BaseCryptLibServiceDeprecated ("Md5Final"), FALSE;
+}
+
+/**
+  Computes the MD5 message digest of a input data buffer.
+
+  This function performs the MD5 message digest of a given data buffer, and 
places
+  the digest value into the specified memory.
+
+  If this interface is not supported, then return FALSE.
+
+  @param[in]   DataPointer to the buffer containing the data to be 
hashed.
+  @param[in]   DataSizeSize of Data buffer in bytes.
+  @param[out]  HashValue   Pointer to a buffer that receives the MD5 digest
+   value (16 bytes).
+
+  @retval FALSE  This interface is not supported.
+
+**/
+BOOLEAN
+EFIAPI

Re: [edk2-devel] [PATCH v5 1/1] MdeModulePkg.dec: Change PCDs for status code.

[Tan, Ming]

Michael:
  I verify it can pass the local build.
  Use this solution, can keep compatible, need not remove the setting in 
platforms at first.
  I will remove the Feature Flag PCD at last, after the platforms change the 
PCD type.

  BR/Tan Ming.

-Original Message-
From: Kinney, Michael D  
Sent: Thursday, June 18, 2020 12:47 AM
To: devel@edk2.groups.io; Wang, Jian J ; Tan, Ming 
; Kinney, Michael D 
Cc: Wu, Hao A 
Subject: RE: [edk2-devel] [PATCH v5 1/1] MdeModulePkg.dec: Change PCDs for 
status code.

Ming,

With this change, are the same PCDs listed as both a Feature Flag PCD and a 
non-Feature Flag PCD?

That should not be allowed, and if that passes the build, then the build tools 
should flag that as an error condition.

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Wang, 
> Jian J
> Sent: Wednesday, June 17, 2020 7:43 AM
> To: Tan, Ming ; devel@edk2.groups.io
> Cc: Wu, Hao A 
> Subject: Re: [edk2-devel] [PATCH v5 1/1]
> MdeModulePkg.dec: Change PCDs for status code.
> 
> Reviewed-by: Jian J Wang 
> 
> Regards,
> Jian
> 
> > -Original Message-
> > From: Tan, Ming 
> > Sent: Wednesday, June 17, 2020 3:36 PM
> > To: devel@edk2.groups.io
> > Cc: Wang, Jian J ; Wu, Hao A
> 
> > Subject: [PATCH v5 1/1] MdeModulePkg.dec: Change PCDs
> for status code.
> >
> > REF:
> https://bugzilla.tianocore.org/show_bug.cgi?id=2786
> >
> > In order to support enable/disable report status code
> through memory
> > or serial dynamic, change the following PCDs from
> [PcdsFeatureFlag] to
> > [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic,
> PcdsDynamicEx]:
> >   PcdStatusCodeUseSerial
> >   PcdStatusCodeUseMemory
> > The original plaforms can use PcdsFixedAtBuild in .dsc
> files to save size.
> > Currently do not remove the old pcd type to keep
> compatible.
> >
> > Cc: Jian J Wang 
> > Cc: Hao A Wu 
> > Signed-off-by: Ming Tan 
> > ---
> > V5: Do not remove th old pcd type to keep compatible,
> and change to
> > standalone patch.
> > V4: No change for this 1/4 patch, just modify the 2-
> 4/4 patchs.
> > V3: Split one patch to several patchs, each Pkg has
> one patch.
> > V2: Change the new type from [PcdsDynamic] to
> [PcdsFixedAtBuild,
> > PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
> > And set to PcdsFixedAtBuild in the original
> platform .dsc files.
> >
> >  MdeModulePkg/MdeModulePkg.dec| 13
> +
> >  .../StatusCodeHandler/Pei/StatusCodeHandlerPei.c |  6
> +++---
> >  .../Pei/StatusCodeHandlerPei.inf |  6
> ++
> >  .../RuntimeDxe/StatusCodeHandlerRuntimeDxe.c | 16
> 
> >  .../RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf   |  6
> ++
> >  .../StatusCodeHandler/Smm/StatusCodeHandlerSmm.c | 10
> +-
> >  .../Smm/StatusCodeHandlerSmm.inf |  6
> ++
> >  7 files changed, 35 insertions(+), 28 deletions(-)
> >
> > diff --git a/MdeModulePkg/MdeModulePkg.dec 
> > b/MdeModulePkg/MdeModulePkg.dec index 4f44af694862..bd369d1f230e 
> > 100644
> > --- a/MdeModulePkg/MdeModulePkg.dec
> > +++ b/MdeModulePkg/MdeModulePkg.dec
> > @@ -2001,6 +2001,19 @@ [PcdsFixedAtBuild,
> PcdsPatchableInModule,
> > PcdsDynamic, PcdsDynamicEx]
> ># @Prompt TCG Platform Firmware Profile revision.
> >
> >
> gEfiMdeModulePkgTokenSpaceGuid.PcdTcgPfpMeasurementRevis
> ion|0|UINT3
> > 2|0x00010077
> >
> > +  ## Indicates if StatusCode is reported via Serial
> port.
> > +  #   TRUE  - Reports StatusCode via Serial port.
> > +  #   FALSE - Does not report StatusCode via Serial
> port.
> > +  # @Prompt Enable StatusCode via Serial port.
> > +
> >
> gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|TR
> UE|BOOLEAN|
> > 0x00010022
> > +
> > +  ## Indicates if StatusCode is stored in memory.
> > +  #  The memory is boot time memory in PEI Phase and
> is runtime memory in
> > DXE Phase.
> > +  #   TRUE  - Stores StatusCode in memory.
> > +  #   FALSE - Does not store StatusCode in
> memory.
> > +  # @Prompt Enable StatusCode via memory.
> > +
> >
> gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseMemory|FA
> LSE|BOOLEA
> > N|0x00010023
> > +
> >  [PcdsPatchableInModule]
> >## Specify memory size with page number for PEI
> code when
> >#  Loading Module at Fixed Address feature is
> enabled.
> > diff --git
> >
> a/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCod
> eHandlerPei.c
> >
> b/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCod
> eHandlerPei.c
> > index 1b07f92f3ce8..9b2ea4ee84d9 100644
> > ---
> a/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCod
> eHandlerPei.c
> > +++
> >
> b/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCod
> eHandlerPei.c
> > @@ -2,7 +2,7 @@
> >Report Status Code Handler PEIM which produces
> general handlers and hook
> > them
> >onto the PEI status code router.
> >
> > -  Copyright (c) 2009 - 2018, Intel Corporation. All
> rights reserved.
> > +  Copyright (c) 2009 - 2020, Intel Corporation. All
> rights reserved.
> >

Re: [edk2-devel] [PATCH] Features/Intel/Readme.md: clarify feature package dependency rule

[Dong, Eric]

Reviewed-by: Eric Dong 

> -Original Message-
> From: Ni, Ray 
> Sent: Wednesday, June 17, 2020 5:03 PM
> To: devel@edk2.groups.io
> Cc: Ray Ni ; Dong, Eric
> ; Chan, Amy ; Chaganty,
> Rangasai V ; Oram, Isaac W
> 
> Subject: [PATCH] Features/Intel/Readme.md: clarify feature package
> dependency rule
> 
> From: Ray Ni 
> 
> Original statement only says depending on another feature package
> is not allowed. It gives developers impression that board level
> packages are allowed to depend on.
> 
> This patch clarifies the package dependency rule.
> 
> Signed-off-by: Ray Ni 
> Cc: Eric Dong 
> Cc: Amy Chan 
> Cc: Rangasai V Chaganty 
> Cc: Isaac W Oram 
> ---
>  Features/Intel/Readme.md | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/Features/Intel/Readme.md b/Features/Intel/Readme.md
> index 9729f90a41..1a03a4c0d2 100644
> --- a/Features/Intel/Readme.md
> +++ b/Features/Intel/Readme.md
> @@ -17,8 +17,10 @@ document as needed.
>  ### Advanced Feature Attributes
> 
>  Advanced features should be:
> 
>  * _Cohesive_, the feature should not contain any functionality unrelated to
> the feature.
> 
> -* _Complete_, the feature must have a complete design that minimizes
> dependencies. A feature package cannot directly
> 
> -  depend on another feature package.
> 
> +* _Complete_, the feature must have a complete design that minimizes
> dependencies. A feature package can only depend
> 
> +  on following packages:
> 
> +  * edk2 repo: `MdePkg`, `MdeModulePkg`, `UefiCpuPkg`, `FmpDevicePkg`,
> `SecurityPkg`, `NetworkPkg`, `ShellPkg`.
> 
> +  * edk2-platforms repo: `MinPlatformPkg`, `IntelSiliconPkg`.
> 
>  * _Easy to Integrate_, the feature should expose well-defined software
> interfaces to use and configure the feature.
> 
>* It should also present a set of simple and well-documented standard EDK
> II configuration options such as PCDs to
> 
>configure the feature.
> 
> --
> 2.25.1


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

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

Re: [edk2-devel] [edk2-platform][PATCH v1 1/1] Platforms/RaspberryPi: Hide RamMoreThan3GB setting

[Andrei Warkentin]

Reviewed-by: Andrei Warkentin 

Hiding is a good idea.

A



From: Samer El-Haj-Mahmoud 
Sent: Wednesday, June 17, 2020 1:32 PM
To: devel@edk2.groups.io 
Cc: Leif Lindholm ; Pete Batard ; Andrei 
Warkentin ; Ard Biesheuvel 
Subject: [edk2-platform][PATCH v1 1/1] Platforms/RaspberryPi: Hide 
RamMoreThan3GB setting

Hide the RamMoreThan3GB HII seting when the feature is not support
(i.e. on RPi with less than 4GB RAM) instead of graying it out.

Cc: Leif Lindholm 
Cc: Pete Batard 
Cc: Andrei Warkentin 
Cc: Ard Biesheuvel 
Signed-off-by: Samer El-Haj-Mahmoud 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
index d5615d7af0c5..e122b5b9ff5c 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
@@ -155,7 +155,7 @@ formset
 title  = STRING_TOKEN(STR_ADVANCED_FORM_TITLE);
 subtitle text = STRING_TOKEN(STR_NULL_STRING);

-grayoutif ideqval RamMoreThan3GB.Supported == 0;
+suppressif ideqval RamMoreThan3GB.Supported == 0;
   oneof varid = RamLimitTo3GB.Enabled,
   prompt  = STRING_TOKEN(STR_ADVANCED_3GB_PROMPT),
   help= STRING_TOKEN(STR_ADVANCED_3GB_HELP),
--
2.17.1


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

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

Re: [edk2-devel] [edk2-platform][PATCH v3 0/6] Update ASIX USB Networking driversSamer El-Haj-Mahmoud

[Samer El-Haj-Mahmoud]

Leif, Ard,

Any word on this series? I only got a RB on v3 from Ray.

Thanks,
--Samer


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Samer
> El-Haj-Mahmoud via groups.io
> Sent: Monday, June 8, 2020 9:38 AM
> To: devel@edk2.groups.io
> Cc: Ray Ni ; Leif Lindholm ; Ard
> Biesheuvel ; Michael D Kinney
> ; Pete Batard ; Andrei
> Warkentin 
> Subject: [edk2-devel] [edk2-platform][PATCH v3 0/6] Update ASIX USB
> Networking drivers
>
> This series updates the ASIX USB networking drivers:
>
>  - Create new Drivers/ASIX/ package
>  - Add new ASIX drivers Ax88179 and Ax88772c to the new ASIX package
>  - Delete old Ax88772 and Ax88772b drivers from OptionRomPkg
>
> Code pushed to https://github.com/samerhaj/edk2-
> platforms/tree/asix_usb_nic_drivers_ver3
>
> version 1: https://edk2.groups.io/g/devel/message/58771
> version 2: https://edk2.groups.io/g/devel/message/58986
> version 3 changes:
>  - Rename AsixPkg to ASIX [Ray]
>  - Changed SNP Mode->IfType from EfiNetworkInterfaceUndi to
>NET_IFTYPE_ETHERNET [Ard]
>  - Dropped runtime module types and associated depex, libraries,
>and memory allocation [Ard]
>  - Dropped "SCT_PASS" and kept the enable logic [Leif]
>  - Dropped dead / commented out code and macros
>(including "ARM" and "AMI") [Ard, Leif]
>  - Dropped unused debug macros [Leif, Ard]
>  - Dropped "Freddy" Comments and unused macros [Leif, Ard]
>  - Dropped inorrect VALID_ARCHITECTURES from INF files [Ard]
>  - Dropped all Hungarian notation variables [Ard, Leif]
>  - Dropped 'Yoda-style' compariosns [Ard, Leif]
>  - Dropped redundant casts [Ard]
>  - Fixed spacing, indentation, and curly braces [Ard, Leif]
>  - Used CamelCase definitions per coding style [Ard]
>  - Dropped 'success handling' [Ard]
>  - Sorted LibraryClasses and include files [Ard]
>  - Aligned variables and function parameters declarations [Ard]
>  - Cleaned up include headers [Leif]
>  - Added public link to orignal ASIX provided code [Leif]
>
> Cc: Ray Ni 
> Cc: Leif Lindholm 
> Cc: Ard Biesheuvel 
> Cc: Michael D Kinney 
> Cc: Pete Batard 
> Cc: Andrei Warkentin 
>
> Signed-off-by: Samer El-Haj-Mahmoud 
>
> Samer El-Haj-Mahmoud (6):
>   Drivers/ASIX: Create ASIX drivers package
>   Drivers/ASIX: Add ASIX Ax88179 driver
>   Drivers/ASIX: Add ASIX Ax88772c driver
>   Platform/RaspberryPi: Switch RPi3 USB NIC driver to Ax88772c
>   Platform/HiSilicon: Switch HiKey USB NIC driver to Ax88772c
>   Drivers/OptionRomPkg: Remove old ASIX NIC drivers
>
>  Drivers/ASIX/Asix.dec |   30 +
>  Drivers/ASIX/Asix.dsc |   68 +
>  Drivers/OptionRomPkg/OptionRomPkg.dsc |3 +-
>  Platform/Hisilicon/HiKey/HiKey.dsc|2 +-
>  Platform/RaspberryPi/RPi3/RPi3.dsc|2 +-
>  Platform/Hisilicon/HiKey/HiKey.fdf|2 +-
>  Platform/RaspberryPi/RPi3/RPi3.fdf|2 +-
>  .../Bus/Usb/UsbNetworking/Ax88179/Ax88179.inf |   45 +
>  .../Usb/UsbNetworking/Ax88772c/Ax88772c.inf}  |   28 +-
>  .../Usb/UsbNetworking/Ax88772b/Ax88772b.inf   |   61 -
>  .../Bus/Usb/UsbNetworking/Ax88179/Ax88179.h}  |  792 
> .../Bus/Usb/UsbNetworking/Ax88772c}/Ax88772.h |  489 ++---
>  .../Bus/Usb/UsbNetworking/Ax88179/Ax88179.c   | 1042 +++
>  .../UsbNetworking/Ax88179}/ComponentName.c|  107 +-
>  .../Usb/UsbNetworking/Ax88179/DriverBinding.c |  639 +++
> .../Usb/UsbNetworking/Ax88179/SimpleNetwork.c | 1548
> +++  .../Bus/Usb/UsbNetworking/Ax88772c/Ax88772.c  |
> 1300 +
>  .../UsbNetworking/Ax88772c}/ComponentName.c   |   97 +-
>  .../UsbNetworking/Ax88772c/DriverBinding.c|  652 +++
>  .../UsbNetworking/Ax88772c/SimpleNetwork.c| 1581 
>  .../Bus/Usb/UsbNetworking/Ax88772/Ax88772.c   | 1318 -
>  .../Usb/UsbNetworking/Ax88772/DriverBinding.c |  507 -
> .../Usb/UsbNetworking/Ax88772/SimpleNetwork.c | 1503 ---
> .../Bus/Usb/UsbNetworking/Ax88772b/Ax88772.c  |  875 -
>  .../UsbNetworking/Ax88772b/DriverBinding.c|  696 ---
>  .../UsbNetworking/Ax88772b/SimpleNetwork.c| 1657 -
>  26 files changed, 7754 insertions(+), 7292 deletions(-)  create mode 100644
> Drivers/ASIX/Asix.dec  create mode 100644 Drivers/ASIX/Asix.dsc  create
> mode 100644 Drivers/ASIX/Bus/Usb/UsbNetworking/Ax88179/Ax88179.inf
>  rename
> Drivers/{OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772/Ax88772.inf =>
> ASIX/Bus/Usb/UsbNetworking/Ax88772c/Ax88772c.inf} (58%)  delete mode
> 100644
> Drivers/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772b.inf
>  rename
> Drivers/{OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772/Ax88772.h =>
> ASIX/Bus/Usb/UsbNetworking/Ax88179/Ax88179.h} (52%)  rename
> Drivers/{OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b =>
> ASIX/Bus/Usb/UsbNetworking/Ax88772c}/Ax88772.h (69%)  create mode
> 100644 Drivers/ASIX/Bus/Usb/UsbNetworking/Ax88179/Ax88179.c
>  rename Drivers/{OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772 =>
> 

[edk2-devel] [edk2-platform][PATCH v1 1/1] Platforms/RaspberryPi: Regenerate boot options on boot failure

[Samer El-Haj-Mahmoud]

Port tianocore/edk2@2d233af64b8f73d1b1e138b302e6344f7c2e0f4e

This enables network boot by default on RPi first boot, when all other
boot options fail. This is required for unattended/headless boot cases.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Andrei Warkentin 
Cc: Pete Batard 
Signed-off-by: Samer El-Haj-Mahmoud 
---
 Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c | 36 
+++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c 
b/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c
index cb74d65b7f91..fa46be791732 100644
--- a/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c
+++ b/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c
@@ -4,7 +4,7 @@
  *  Copyright (c) 2017-2018, Andrei Warkentin 
  *  Copyright (c) 2016, Linaro Ltd. All rights reserved.
  *  Copyright (c) 2015-2016, Red Hat, Inc.
- *  Copyright (c) 2014, ARM Ltd. All rights reserved.
+ *  Copyright (c) 2014-2020, ARM Ltd. All rights reserved.
  *  Copyright (c) 2004-2016, Intel Corporation. All rights reserved.
  *
  *  SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -700,6 +700,40 @@ PlatformBootManagerUnableToBoot (
   EFI_INPUT_KEYKey;
   EFI_BOOT_MANAGER_LOAD_OPTION BootManagerMenu;
   UINTNIndex;
+  EFI_BOOT_MANAGER_LOAD_OPTION *BootOptions;
+  UINTNOldBootOptionCount;
+  UINTNNewBootOptionCount;
+
+  //
+  // Record the total number of boot configured boot options
+  //
+  BootOptions = EfiBootManagerGetLoadOptions (,
+  LoadOptionTypeBoot);
+  EfiBootManagerFreeLoadOptions (BootOptions, OldBootOptionCount);
+
+  //
+  // Connect all devices, and regenerate all boot options
+  //
+  EfiBootManagerConnectAll ();
+  EfiBootManagerRefreshAllBootOption ();
+
+  //
+  // Record the updated number of boot configured boot options
+  //
+  BootOptions = EfiBootManagerGetLoadOptions (,
+  LoadOptionTypeBoot);
+  EfiBootManagerFreeLoadOptions (BootOptions, NewBootOptionCount);
+
+  //
+  // If the number of configured boot options has changed, reboot
+  // the system so the new boot options will be taken into account
+  // while executing the ordinary BDS bootflow sequence.
+  //
+  if (NewBootOptionCount != OldBootOptionCount) {
+DEBUG ((DEBUG_WARN, "%a: rebooting after refreshing all boot options\n",
+  __FUNCTION__));
+gRT->ResetSystem (EfiResetCold, EFI_SUCCESS, 0, NULL);
+  }
 
   //
   // BootManagerMenu doesn't contain the correct information when return status
-- 
2.17.1


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

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

Re: [edk2-devel] [PATCH V3 2/2] UefiPayloadPkg/Pci: Use the PCIE Base Addr stored in AcpiBoardInfo HOB

[Ma, Maurice]

Patch V3 addressed all my previous comments.   It looks good to me.
Reviewed-by: Maurice Ma 

Regards,
Maurice
> -Original Message-
> From: Ni, Ray 
> Sent: Wednesday, June 17, 2020 1:41
> To: devel@edk2.groups.io
> Cc: Ma, Maurice ; Dong, Guo ;
> You, Benjamin 
> Subject: [PATCH V3 2/2] UefiPayloadPkg/Pci: Use the PCIE Base Addr stored in
> AcpiBoardInfo HOB
> 
> Today's UefiPayloadPkg always uses 0xE000 as the PCIE base address and
> ignores the value set in AcpiBoardInfo HOB created by the boot loader. This
> makes the payload binary cannot work in environment where the PCIE base
> address set by boot loader doesn't equal to 0xE000.
> 
> The patch enhances UefiPayloadPkg so that the PCIE base address set by boot
> loader in the AcpiBoardInfo HOB is used.
> 
> Signed-off-by: Ray Ni 
> Cc: Maurice Ma 
> Cc: Guo Dong 
> Cc: Benjamin You 
> ---
>  UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c| 13 +++-
>  UefiPayloadPkg/BlSupportDxe/BlSupportDxe.inf  |  3 +-
>  .../PciSegmentInfoLibAcpiBoardInfo.c  | 59 +++
>  .../PciSegmentInfoLibAcpiBoardInfo.inf| 36 +++
>  UefiPayloadPkg/UefiPayloadPkgIa32.dsc | 10 ++--
>  UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc  | 11 ++--
>  6 files changed, 121 insertions(+), 11 deletions(-)  create mode 100644
> UefiPayloadPkg/Library/PciSegmentInfoLibAcpiBoardInfo/PciSegmentInfoLibAc
> piBoardInfo.c
>  create mode 100644
> UefiPayloadPkg/Library/PciSegmentInfoLibAcpiBoardInfo/PciSegmentInfoLibAc
> piBoardInfo.inf
> 
> diff --git a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
> b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
> index 28dfc8fc55..a3974dcc02 100644
> --- a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
> +++ b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
> @@ -2,7 +2,7 @@
>This driver will report some MMIO/IO resources to dxe core, extract smbios
> and acpi   tables from bootloader. -  Copyright (c) 2014 - 2019, Intel 
> Corporation.
> All rights reserved.+  Copyright (c) 2014 - 2020, Intel Corporation. All 
> rights
> reserved.   SPDX-License-Identifier: BSD-2-Clause-Patent  **/@@ -101,6
> +101,7 @@ BlDxeEntryPoint (
>EFI_HOB_GUID_TYPE  *GuidHob;   SYSTEM_TABLE_INFO
> *SystemTableInfo;   EFI_PEI_GRAPHICS_INFO_HOB  *GfxInfo;+
> ACPI_BOARD_INFO*AcpiBoardInfo;Status = EFI_SUCCESS;   //@@ -
> 153,6 +154,16 @@ BlDxeEntryPoint (
>  ASSERT_EFI_ERROR (Status);   } +  //+  // Set PcdPciExpressBaseAddress by
> HOB info+  //+  GuidHob = GetFirstGuidHob ();+  if
> (GuidHob != NULL) {+AcpiBoardInfo = (ACPI_BOARD_INFO
> *)GET_GUID_HOB_DATA (GuidHob);+Status = PcdSet64S
> (PcdPciExpressBaseAddress, AcpiBoardInfo->PcieBaseAddress);+
> ASSERT_EFI_ERROR (Status);+  }+   return EFI_SUCCESS; } diff --git
> a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.inf
> b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.inf
> index 4c2b4670af..1371d5eb79 100644
> --- a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.inf
> +++ b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.inf
> @@ -3,7 +3,7 @@
>  # # Report some MMIO/IO resources to dxe core, extract smbios and acpi tables
> #-#  Copyright (c) 2014 - 2019, Intel Corporation. All rights reserved.+#
> Copyright (c) 2014 - 2020, Intel Corporation. All rights reserved. # #  
> SPDX-
> License-Identifier: BSD-2-Clause-Patent #@@ -53,6 +53,7 @@ [Pcd]
>gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution
> gEfiMdeModulePkgTokenSpaceGuid.PcdSetupVideoHorizontalResolution
> gEfiMdeModulePkgTokenSpaceGuid.PcdSetupVideoVerticalResolution+
> gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress  [Depex]   TRUEdiff --git
> a/UefiPayloadPkg/Library/PciSegmentInfoLibAcpiBoardInfo/PciSegmentInfoLib
> AcpiBoardInfo.c
> b/UefiPayloadPkg/Library/PciSegmentInfoLibAcpiBoardInfo/PciSegmentInfoLib
> AcpiBoardInfo.c
> new file mode 100644
> index 00..d37c91cc9f
> --- /dev/null
> +++ b/UefiPayloadPkg/Library/PciSegmentInfoLibAcpiBoardInfo/PciSegmentIn
> +++ foLibAcpiBoardInfo.c
> @@ -0,0 +1,59 @@
> +/** @file+  PCI Segment Information Library that returns one segment whose+
> segment base address is retrieved from AcpiBoardInfo HOB.++  Copyright (c)
> 2020, Intel Corporation. All rights reserved.+  SPDX-License-Identifier:
> BSD-2-Clause-Patent++**/++#include +#include
> ++#include +#include
> +#include ++STATIC
> PCI_SEGMENT_INFO mPciSegment0 = {+  0,  // Segment number+  0,  // To be
> fixed later+  0,  // Start bus number+  255 // End bus number+};++/**+  Return
> an array of PCI_SEGMENT_INFO holding the segment information.++  Note: The
> returned array/buffer is owned by callee.++  @param  Count  Return the count
> of segments.++  @retval A callee owned array holding the segment
> information.+**/+PCI_SEGMENT_INFO *+EFIAPI+GetPciSegmentInfo (+  UINTN
> *Count+  )+{+  EFI_HOB_GUID_TYPE  *GuidHob;+  ACPI_BOARD_INFO
> *AcpiBoardInfo;++  ASSERT (Count != NULL);+  if (Count == NULL) {+return
> NULL;+  }++  if (mPciSegment0.BaseAddress == 0) {+//+// Find the acpi
> board 

Re: [edk2-devel] [PATCH V3 2/2] UefiPayloadPkg/Pci: Use the PCIE Base Addr stored in AcpiBoardInfo HOB

[Guo Dong]

Thanks Ray for the update. It looks good to me.

Reviewed-by: Dong, Guo 

Thanks,
Guo

> -Original Message-
> From: Ni, Ray 
> Sent: Wednesday, June 17, 2020 1:41 AM
> To: devel@edk2.groups.io
> Cc: Ma, Maurice ; Dong, Guo
> ; You, Benjamin 
> Subject: [PATCH V3 2/2] UefiPayloadPkg/Pci: Use the PCIE Base Addr stored
> in AcpiBoardInfo HOB
> 
> Today's UefiPayloadPkg always uses 0xE000 as the PCIE base address
> and ignores the value set in AcpiBoardInfo HOB created by the boot
> loader. This makes the payload binary cannot work in environment
> where the PCIE base address set by boot loader doesn't equal to
> 0xE000.
> 
> The patch enhances UefiPayloadPkg so that the PCIE base address
> set by boot loader in the AcpiBoardInfo HOB is used.
> 
> Signed-off-by: Ray Ni 
> Cc: Maurice Ma 
> Cc: Guo Dong 
> Cc: Benjamin You 
> ---
>  UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c| 13 +++-
>  UefiPayloadPkg/BlSupportDxe/BlSupportDxe.inf  |  3 +-
>  .../PciSegmentInfoLibAcpiBoardInfo.c  | 59 +++
>  .../PciSegmentInfoLibAcpiBoardInfo.inf| 36 +++
>  UefiPayloadPkg/UefiPayloadPkgIa32.dsc | 10 ++--
>  UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc  | 11 ++--
>  6 files changed, 121 insertions(+), 11 deletions(-)
>  create mode 100644
> UefiPayloadPkg/Library/PciSegmentInfoLibAcpiBoardInfo/PciSegmentInfoLib
> AcpiBoardInfo.c
>  create mode 100644
> UefiPayloadPkg/Library/PciSegmentInfoLibAcpiBoardInfo/PciSegmentInfoLib
> AcpiBoardInfo.inf
> 
> diff --git a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
> b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
> index 28dfc8fc55..a3974dcc02 100644
> --- a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
> +++ b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
> @@ -2,7 +2,7 @@
>This driver will report some MMIO/IO resources to dxe core, extract smbios
> and acpi
> 
>tables from bootloader.
> 
> 
> 
> -  Copyright (c) 2014 - 2019, Intel Corporation. All rights reserved.
> 
> +  Copyright (c) 2014 - 2020, Intel Corporation. All rights reserved.
> 
>SPDX-License-Identifier: BSD-2-Clause-Patent
> 
> 
> 
>  **/
> 
> @@ -101,6 +101,7 @@ BlDxeEntryPoint (
>EFI_HOB_GUID_TYPE  *GuidHob;
> 
>SYSTEM_TABLE_INFO  *SystemTableInfo;
> 
>EFI_PEI_GRAPHICS_INFO_HOB  *GfxInfo;
> 
> +  ACPI_BOARD_INFO*AcpiBoardInfo;
> 
> 
> 
>Status = EFI_SUCCESS;
> 
>//
> 
> @@ -153,6 +154,16 @@ BlDxeEntryPoint (
>  ASSERT_EFI_ERROR (Status);
> 
>}
> 
> 
> 
> +  //
> 
> +  // Set PcdPciExpressBaseAddress by HOB info
> 
> +  //
> 
> +  GuidHob = GetFirstGuidHob ();
> 
> +  if (GuidHob != NULL) {
> 
> +AcpiBoardInfo = (ACPI_BOARD_INFO *)GET_GUID_HOB_DATA
> (GuidHob);
> 
> +Status = PcdSet64S (PcdPciExpressBaseAddress, AcpiBoardInfo-
> >PcieBaseAddress);
> 
> +ASSERT_EFI_ERROR (Status);
> 
> +  }
> 
> +
> 
>return EFI_SUCCESS;
> 
>  }
> 
> 
> 
> diff --git a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.inf
> b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.inf
> index 4c2b4670af..1371d5eb79 100644
> --- a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.inf
> +++ b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.inf
> @@ -3,7 +3,7 @@
>  #
> 
>  # Report some MMIO/IO resources to dxe core, extract smbios and acpi
> tables
> 
>  #
> 
> -#  Copyright (c) 2014 - 2019, Intel Corporation. All rights reserved.
> 
> +#  Copyright (c) 2014 - 2020, Intel Corporation. All rights reserved.
> 
>  #
> 
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  #
> 
> @@ -53,6 +53,7 @@ [Pcd]
>gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution
> 
>gEfiMdeModulePkgTokenSpaceGuid.PcdSetupVideoHorizontalResolution
> 
>gEfiMdeModulePkgTokenSpaceGuid.PcdSetupVideoVerticalResolution
> 
> +  gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
> 
> 
> 
>  [Depex]
> 
>TRUE
> 
> diff --git
> a/UefiPayloadPkg/Library/PciSegmentInfoLibAcpiBoardInfo/PciSegmentInfo
> LibAcpiBoardInfo.c
> b/UefiPayloadPkg/Library/PciSegmentInfoLibAcpiBoardInfo/PciSegmentInfo
> LibAcpiBoardInfo.c
> new file mode 100644
> index 00..d37c91cc9f
> --- /dev/null
> +++
> b/UefiPayloadPkg/Library/PciSegmentInfoLibAcpiBoardInfo/PciSegmentInfo
> LibAcpiBoardInfo.c
> @@ -0,0 +1,59 @@
> +/** @file
> 
> +  PCI Segment Information Library that returns one segment whose
> 
> +  segment base address is retrieved from AcpiBoardInfo HOB.
> 
> +
> 
> +  Copyright (c) 2020, Intel Corporation. All rights reserved.
> 
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
> +
> 
> +**/
> 
> +
> 
> +#include 
> 
> +#include 
> 
> +
> 
> +#include 
> 
> +#include 
> 
> +#include 
> 
> +
> 
> +STATIC PCI_SEGMENT_INFO mPciSegment0 = {
> 
> +  0,  // Segment number
> 
> +  0,  // To be fixed later
> 
> +  0,  // Start bus number
> 
> +  255 // End bus number
> 
> +};
> 
> +
> 
> +/**
> 
> +  Return an array of PCI_SEGMENT_INFO holding the segment information.
> 
> +
> 
> +  Note: The returned array/buffer is owned by callee.
> 
> +
> 
> +  @param  Count  Return 

Re: [edk2-devel] Components sub-section ordering

[Michael D Kinney]

Tim,

This is an excellent point.  I do not see any reason why the order should 
matter.  If there are any assumptions in BaseTools about the order, we should 
identify those and enter Bugzillas to remove those assumptions and update the 
specs to remove this requirement.

For some sections , the order of statements with a section is significant.

Thanks,

Mike

From: devel@edk2.groups.io  On Behalf Of Tim Lewis
Sent: Wednesday, June 17, 2020 9:56 AM
To: devel@edk2.groups.io
Subject: [edk2-devel] Components sub-section ordering

EDK2 build tool gurus:

Question: The current EDK2 .DSC specification, section 3.10 says that the 
sub-elements in a Component must follow a specific ordering (LibraryClasses, 
Pcds*, BuildOptions). But it is not clear why this is required. As a side note, 
we have a number of .dsc files where this is not followed today, but our tools 
developers wanted to know if this should be enforced.

Here is the text from the spec:

Within the context of an EDK II module sub-element, the  
entries must appear before  entries; the  entries 
terminate with the start of either the  or  sub-section 
header or the end of the scope defined by the right curly "}" brace. The 
 sub-element must be the last sub-entry of an EDK II module's 
scoped section. Entries for ,  and  are 
used to replace the platform or global definition entries listed elsewhere. 
LibraryClass and PCDs are globally defined in the DSC file's [LibraryClasses] 
and [Pcds*] sections, while global BuildOptions may be specified in either the 
DSC file's [BuildOptions] section or in the $(WORKSPACE)/Conf/tools_def.txt 
file.

I would also note that the  is not listed here.

Can we just elide this?

Thanks,

Tim Lewis
CTO, Insyde Software
www.insyde.com



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

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

Re: [edk2-devel] [edk2-platform][PATCH v1 0/2] Platforms/RaspberryPi: Add RPi settings to Readme

[Ard Biesheuvel]

On 6/13/20 3:41 PM, Samer El-Haj-Mahmoud wrote:

Add a section to the the RPi3/4 Readme for 'Configuration Settings', with
instructions on scripting from the UEFI Shell.

Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
Cc: Pete Batard 
Cc: Andrei Warkentin 
Signed-off-by: Samer El-Haj-Mahmoud 

Samer El-Haj-Mahmoud (2):
   Platforms/RaspberryPi: Add RPi4 settings to Readme
   Platforms/RaspberryPi: Add RPi3 settings to Readme

  Platform/RaspberryPi/RPi3/Readme.md | 61 
  Platform/RaspberryPi/RPi4/Readme.md | 74 +++-
  2 files changed, 134 insertions(+), 1 deletion(-)



Reviewed-by: Ard Biesheuvel 

Series pushed as 04c870e67d11..0f21db1139de

Thanks,

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

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

[edk2-devel] [edk2-platform][PATCH v1 1/1] Platforms/RaspberryPi: Hide RamMoreThan3GB setting

[Samer El-Haj-Mahmoud]

Hide the RamMoreThan3GB HII seting when the feature is not support
(i.e. on RPi with less than 4GB RAM) instead of graying it out.

Cc: Leif Lindholm 
Cc: Pete Batard 
Cc: Andrei Warkentin 
Cc: Ard Biesheuvel 
Signed-off-by: Samer El-Haj-Mahmoud 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
index d5615d7af0c5..e122b5b9ff5c 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
@@ -155,7 +155,7 @@ formset
 title  = STRING_TOKEN(STR_ADVANCED_FORM_TITLE);
 subtitle text = STRING_TOKEN(STR_NULL_STRING);
 
-grayoutif ideqval RamMoreThan3GB.Supported == 0;
+suppressif ideqval RamMoreThan3GB.Supported == 0;
   oneof varid = RamLimitTo3GB.Enabled,
   prompt  = STRING_TOKEN(STR_ADVANCED_3GB_PROMPT),
   help= STRING_TOKEN(STR_ADVANCED_3GB_HELP),
-- 
2.17.1


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

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

Re: [edk2-devel] [PATCH] EmbeddedPkg/NonCoherentDmaLib: avoid dereferencing bogus buffer address

[Ard Biesheuvel]

On 6/17/20 6:14 PM, Leif Lindholm wrote:

On Wed, Jun 17, 2020 at 17:38:24 +0200, Ard Biesheuvel wrote:

The bounce buffering code in NonCoherentDmaLib copies data into the
bounce buffer using CopyMem(), but passes Map->HostAddress as the
source of the copy before it has been assigned its correct value.


Whoops.


Signed-off-by: Ard Biesheuvel 


Reviewed-by: Leif Lindholm 



Thanks

Merged as 8f22a331b955bd3f8077c7fa83bafeec566d6718



---
  EmbeddedPkg/Library/NonCoherentDmaLib/NonCoherentDmaLib.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/EmbeddedPkg/Library/NonCoherentDmaLib/NonCoherentDmaLib.c 
b/EmbeddedPkg/Library/NonCoherentDmaLib/NonCoherentDmaLib.c
index 115345765435..9c8ef5bfb533 100644
--- a/EmbeddedPkg/Library/NonCoherentDmaLib/NonCoherentDmaLib.c
+++ b/EmbeddedPkg/Library/NonCoherentDmaLib/NonCoherentDmaLib.c
@@ -225,8 +225,7 @@ DmaMap (
  }
  
  if (Map->Operation == MapOperationBusMasterRead) {

-  CopyMem (Map->BufferAddress, (VOID *)(UINTN)Map->HostAddress,
-*NumberOfBytes);
+  CopyMem (Map->BufferAddress, (VOID *)(UINTN)HostAddress, *NumberOfBytes);
  }
  mCpu->FlushDataCache (mCpu, (UINTN)Map->BufferAddress, AllocSize,
  EfiCpuFlushTypeWriteBack);
--
2.27.0




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

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

Re: [edk2-devel] [PATCH] ArmPkg/PlatformBootManagerLib: regenerate boot options on boot failure

[Ard Biesheuvel]

On 6/17/20 4:35 PM, Leif Lindholm wrote:

On Wed, Jun 17, 2020 at 14:59:45 +0200, Ard Biesheuvel wrote:

Something like:
"On entry, the UiApp instantiates the autogenerated boot options that
we used to rely on - but it does not consume them. This breaks the
unattended..."


OK


I assume the UiApp only ever *adds* entries, which is why checking
number of entries is sufficient?



It only manages entries that it instantiated itself, but it may also remove
entries if the underlying hardware has disappeared.


Hmm, that's a bit trickier then. I mean, it's unlikely, but I'm sure
there's situations that could happen.
Would we run the risk of getting bug reports like "system fails to
boot from Ethernet when inifiniband switch powered off"? Or if some
virtual devices presented by a BMC appear/disappear?



If the boot entries are not refreshed, you will retain the old ones. So the
only way this could lead to a boot failure is when you rely on automatically
generated boot entries to device that disappear and reappear in a different
place, e.g., move a Ethernet PCIe card to a different slot. Note that USB
devices plugged into a different port will still work fine, though, as they
rely on the removable boot path in this case, which will be attempted anyway
before doing the UnableToBoot().

Note that the failure mode here is being dropped into the menu, where before
you were always dropped into the Shell. The case we are trying to address
here is zero intervention network boot after putting the device into
circulation, and that should work correctly with this change: if the network
boot path did not exist before, it will be added, in which case the number
of boot options will increase.


OK. I'm not convinced we're not going to see a report of this
somewhere down the line, but I think you've managed to convince me
it's an unlikely enough situation, and a fallback, that we can bump it
to then (and it *is* a behavioural improvement in all other cases).

Reviewed-by: Leif Lindholm 
(with the commit message update)



Merged as 2d233af64b8f73d1b1e138b302e6344f7c2e0f4e

Thanks all,

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

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

Re: [edk2-devel] [PATCH edk2-platforms v2] Silicon/Broadcom/BcmGenetDxe: implement media state adapter info protocol

[Samer El-Haj-Mahmoud]

Tested on RPi4 w/ 4GB

Reviewed-by: Samer El-Haj-Mahmoud 

> -Original Message-
> From: Ard Biesheuvel 
> Sent: Wednesday, June 17, 2020 2:15 PM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Pete Batard
> ; Andrei Warkentin (awarken...@vmware.com)
> ; Samer El-Haj-Mahmoud  mahm...@arm.com>
> Subject: [PATCH edk2-platforms v2] Silicon/Broadcom/BcmGenetDxe:
> implement media state adapter info protocol
>
> NetLibDetectMedia () in DxeNetLib is used as a fallback on implementations
> of the SNP protocol that do not also carry an implementation of the adapter
> info protocol to provide media state information, and it does all kinds of
> terrible things to the network interface (stopping and restarting multiple
> times, reprogramming the multicast filters etc etc) to workaround some
> alleged UNDI shortcoming.
>
> Although our GENET code should be bullet proof and therefore able to take
> this kind of abuse, it is better to avoid it, and provide an implementation
> of the adapter info protocol that returns the media state directly, without
> the need to mistreat the SNP layer.
>
>
> Cc: Pete Batard 
>
> Cc: Andrei Warkentin (awarken...@vmware.com)
> 
>
> Cc: Samer El-Haj-Mahmoud 
>
> Signed-off-by: Ard Biesheuvel 
> ---
>
> v2:
>
> - use the correct accessor to retrieve the GENET_PRIVATE_DATA pointer
>
> - call into the PHY routines to get the state, to ensure it is not stale
>
>
>  Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.inf |   3 +
>  Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.h   |   5 +
>  Silicon/Broadcom/Drivers/Net/BcmGenetDxe/AdapterInfo.c   | 106
> 
>  Silicon/Broadcom/Drivers/Net/BcmGenetDxe/DriverBinding.c |  12 ++-
>  4 files changed, 121 insertions(+), 5 deletions(-)
>
> diff --git a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.inf
> b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.inf
> index 28f3e66ebaf0..89dee9f10c83 100644
> --- a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.inf
> +++ b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.inf
> @@ -19,6 +19,7 @@ [Defines]
>UNLOAD_IMAGE   = GenetUnload
>
>
>
>  [Sources]
>
> +  AdapterInfo.c
>
>BcmGenetDxe.h
>
>ComponentName.c
>
>DriverBinding.c
>
> @@ -49,10 +50,12 @@ [LibraryClasses]
>
>
>  [Protocols]
>
>gBcmGenetPlatformDeviceProtocolGuid ## TO_START
>
> +  gEfiAdapterInformationProtocolGuid  ## BY_START
>
>gEfiDevicePathProtocolGuid  ## BY_START
>
>gEfiSimpleNetworkProtocolGuid   ## BY_START
>
>
>
>  [Guids]
>
> +  gEfiAdapterInfoMediaStateGuid
>
>gEfiEventExitBootServicesGuid
>
>
>
>  [FixedPcd]
>
> diff --git a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.h
> b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.h
> index 0af9d5209cf2..1a117b25f87f 100644
> --- a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.h
> +++ b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.h
> @@ -14,6 +14,7 @@
>  #include 
>
>  #include 
>
>  #include 
>
> +#include 
>
>  #include 
>
>  #include 
>
>  #include 
>
> @@ -209,6 +210,8 @@ typedef struct {
>EFI_SIMPLE_NETWORK_PROTOCOL Snp;
>
>EFI_SIMPLE_NETWORK_MODE SnpMode;
>
>
>
> +  EFI_ADAPTER_INFORMATION_PROTOCOLAip;
>
> +
>
>BCM_GENET_PLATFORM_DEVICE_PROTOCOL  *Dev;
>
>
>
>GENERIC_PHY_PRIVATE_DATAPhy;
>
> @@ -234,9 +237,11 @@ extern EFI_COMPONENT_NAME_PROTOCOL
> gGenetComponentName;
>  extern EFI_COMPONENT_NAME2_PROTOCOL
> gGenetComponentName2;
>
>
>
>  extern CONST EFI_SIMPLE_NETWORK_PROTOCOL
> gGenetSimpleNetworkTemplate;
>
> +extern CONST EFI_ADAPTER_INFORMATION_PROTOCOL
> gGenetAdapterInfoTemplate;
>
>
>
>  #define GENET_DRIVER_SIGNATURESIGNATURE_32('G', 'N', 'E', 
> 'T')
>
>  #define GENET_PRIVATE_DATA_FROM_SNP_THIS(a)   CR(a,
> GENET_PRIVATE_DATA, Snp, GENET_DRIVER_SIGNATURE)
>
> +#define GENET_PRIVATE_DATA_FROM_AIP_THIS(a)   CR(a,
> GENET_PRIVATE_DATA, Aip, GENET_DRIVER_SIGNATURE)
>
>
>
>  #define GENET_RX_BUFFER(g, idx)   ((UINT8 *)(UINTN)(g)->RxBuffer 
> +
> GENET_MAX_PACKET_SIZE * (idx))
>
>
>
> diff --git a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/AdapterInfo.c
> b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/AdapterInfo.c
> new file mode 100644
> index ..4b42b2bba67a
> --- /dev/null
> +++ b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/AdapterInfo.c
> @@ -0,0 +1,106 @@
> +/** @file
>
> +
>
> +  Copyright (c) 2020 Arm, Limited. All rights reserved.
>
> +
>
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
>
> +
>
> +**/
>
> +
>
> +#include 
>
> +#include 
>
> +#include 
>
> +#include 
>
> +
>
> +#include "BcmGenetDxe.h"
>
> +
>
> +STATIC
>
> +EFI_STATUS
>
> +EFIAPI
>
> +GenetAipGetInformation (
>
> +  IN  EFI_ADAPTER_INFORMATION_PROTOCOL  *This,
>
> +  IN  EFI_GUID  *InformationType,
>
> +  OUT VOID  **InformationBlock,
>
> +  OUT UINTN 

Re: [edk2-devel] [PATCH] ArmPkg/PlatformBootManagerLib: regenerate boot options on boot failure

[Ard Biesheuvel]

On 6/17/20 6:21 PM, Andrei Warkentin wrote:

Thanks for working on this.

Reviewed-by: Andrei Warkentin 



Thanks.

A non-blocking question: is a reboot necessary? Would it be possible to 
just retry the boot sequence?




Not sure how we'd do that.


A

*From:* Ard Biesheuvel 
*Sent:* Tuesday, June 16, 2020 12:48 PM
*To:* devel@edk2.groups.io 
*Cc:* l...@nuviainc.com ; Ard Biesheuvel 
; Pete Batard ; Andrei Warkentin 
; Samer El-Haj-Mahmoud 
*Subject:* [PATCH] ArmPkg/PlatformBootManagerLib: regenerate boot 
options on boot failure

One of the side effects of the recent changes to PlatformBootManagerLib
changes to avoid connecting all devices on every boot is that we no
longer default to network boot on a virgin boot, but end up in the
UiApp menu. At this point, the autogenerated boot options that we used
to rely on will be instantiated too, but it does break the unattended
boot case where devices are expected to attempt a network boot on the
very first power on.

Let's work around this by refreshing all boot options explicitly in
the UnableToBoot() handler, and rebooting the system if doing so
resulted in a change to the total number of configured boot options.
This way, we ultimately end up in the UiApp as before if no boot
options could be started, but only after all the autogenerated ones
have been attempted as well.


Cc: Pete Batard 

Cc: Andrei Warkentin (awarken...@vmware.com) 

Cc: Samer El-Haj-Mahmoud 

Signed-off-by: Ard Biesheuvel 
---
  ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c | 34 


  1 file changed, 34 insertions(+)

diff --git a/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c 
b/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c

index 15c5cac1bea0..9905cad22908 100644
--- a/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
+++ b/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
@@ -820,6 +820,40 @@ PlatformBootManagerUnableToBoot (
  {

    EFI_STATUS   Status;

    EFI_BOOT_MANAGER_LOAD_OPTION BootManagerMenu;

+  EFI_BOOT_MANAGER_LOAD_OPTION *BootOptions;

+  UINTN    OldBootOptionCount;

+  UINTN    NewBootOptionCount;

+

+  //

+  // Record the total number of boot configured boot options

+  //

+  BootOptions = EfiBootManagerGetLoadOptions (,

+  LoadOptionTypeBoot);

+  EfiBootManagerFreeLoadOptions (BootOptions, OldBootOptionCount);

+

+  //

+  // Connect all devices, and regenerate all boot options

+  //

+  EfiBootManagerConnectAll ();

+  EfiBootManagerRefreshAllBootOption ();

+

+  //

+  // Record the updated number of boot configured boot options

+  //

+  BootOptions = EfiBootManagerGetLoadOptions (,

+  LoadOptionTypeBoot);

+  EfiBootManagerFreeLoadOptions (BootOptions, NewBootOptionCount);

+

+  //

+  // If the number of configured boot options has changed, reboot

+  // the system so the new boot options will be taken into account

+  // while executing the ordinary BDS bootflow sequence.

+  //

+  if (NewBootOptionCount != OldBootOptionCount) {

+    DEBUG ((DEBUG_WARN, "%a: rebooting after refreshing all boot 
options\n",


+  __FUNCTION__));

+    gRT->ResetSystem (EfiResetCold, EFI_SUCCESS, 0, NULL);

+  }



    Status = EfiBootManagerGetBootManagerMenu ();

    if (EFI_ERROR (Status)) {

--
2.27.0




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

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

[edk2-devel] [PATCH edk2-platforms v2] Silicon/Broadcom/BcmGenetDxe: implement media state adapter info protocol

[Ard Biesheuvel]

NetLibDetectMedia () in DxeNetLib is used as a fallback on implementations
of the SNP protocol that do not also carry an implementation of the adapter
info protocol to provide media state information, and it does all kinds of
terrible things to the network interface (stopping and restarting multiple
times, reprogramming the multicast filters etc etc) to workaround some
alleged UNDI shortcoming.

Although our GENET code should be bullet proof and therefore able to take
this kind of abuse, it is better to avoid it, and provide an implementation
of the adapter info protocol that returns the media state directly, without
the need to mistreat the SNP layer.

Cc: Pete Batard 
Cc: Andrei Warkentin (awarken...@vmware.com) 
Cc: Samer El-Haj-Mahmoud 
Signed-off-by: Ard Biesheuvel 
---
v2:
- use the correct accessor to retrieve the GENET_PRIVATE_DATA pointer
- call into the PHY routines to get the state, to ensure it is not stale

 Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.inf |   3 +
 Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.h   |   5 +
 Silicon/Broadcom/Drivers/Net/BcmGenetDxe/AdapterInfo.c   | 106 

 Silicon/Broadcom/Drivers/Net/BcmGenetDxe/DriverBinding.c |  12 ++-
 4 files changed, 121 insertions(+), 5 deletions(-)

diff --git a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.inf 
b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.inf
index 28f3e66ebaf0..89dee9f10c83 100644
--- a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.inf
+++ b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.inf
@@ -19,6 +19,7 @@ [Defines]
   UNLOAD_IMAGE   = GenetUnload
 
 [Sources]
+  AdapterInfo.c
   BcmGenetDxe.h
   ComponentName.c
   DriverBinding.c
@@ -49,10 +50,12 @@ [LibraryClasses]
 
 [Protocols]
   gBcmGenetPlatformDeviceProtocolGuid ## TO_START
+  gEfiAdapterInformationProtocolGuid  ## BY_START
   gEfiDevicePathProtocolGuid  ## BY_START
   gEfiSimpleNetworkProtocolGuid   ## BY_START
 
 [Guids]
+  gEfiAdapterInfoMediaStateGuid
   gEfiEventExitBootServicesGuid
 
 [FixedPcd]
diff --git a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.h 
b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.h
index 0af9d5209cf2..1a117b25f87f 100644
--- a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.h
+++ b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.h
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -209,6 +210,8 @@ typedef struct {
   EFI_SIMPLE_NETWORK_PROTOCOL Snp;
   EFI_SIMPLE_NETWORK_MODE SnpMode;
 
+  EFI_ADAPTER_INFORMATION_PROTOCOLAip;
+
   BCM_GENET_PLATFORM_DEVICE_PROTOCOL  *Dev;
 
   GENERIC_PHY_PRIVATE_DATAPhy;
@@ -234,9 +237,11 @@ extern EFI_COMPONENT_NAME_PROTOCOL
gGenetComponentName;
 extern EFI_COMPONENT_NAME2_PROTOCOL   gGenetComponentName2;
 
 extern CONST EFI_SIMPLE_NETWORK_PROTOCOL  gGenetSimpleNetworkTemplate;
+extern CONST EFI_ADAPTER_INFORMATION_PROTOCOL gGenetAdapterInfoTemplate;
 
 #define GENET_DRIVER_SIGNATURESIGNATURE_32('G', 'N', 'E', 'T')
 #define GENET_PRIVATE_DATA_FROM_SNP_THIS(a)   CR(a, GENET_PRIVATE_DATA, Snp, 
GENET_DRIVER_SIGNATURE)
+#define GENET_PRIVATE_DATA_FROM_AIP_THIS(a)   CR(a, GENET_PRIVATE_DATA, Aip, 
GENET_DRIVER_SIGNATURE)
 
 #define GENET_RX_BUFFER(g, idx)   ((UINT8 *)(UINTN)(g)->RxBuffer + 
GENET_MAX_PACKET_SIZE * (idx))
 
diff --git a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/AdapterInfo.c 
b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/AdapterInfo.c
new file mode 100644
index ..4b42b2bba67a
--- /dev/null
+++ b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/AdapterInfo.c
@@ -0,0 +1,106 @@
+/** @file
+
+  Copyright (c) 2020 Arm, Limited. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+
+#include "BcmGenetDxe.h"
+
+STATIC
+EFI_STATUS
+EFIAPI
+GenetAipGetInformation (
+  IN  EFI_ADAPTER_INFORMATION_PROTOCOL  *This,
+  IN  EFI_GUID  *InformationType,
+  OUT VOID  **InformationBlock,
+  OUT UINTN *InformationBlockSize
+  )
+{
+  EFI_ADAPTER_INFO_MEDIA_STATE  *AdapterInfo;
+  GENET_PRIVATE_DATA*Genet;
+
+  if (This == NULL || InformationBlock == NULL ||
+  InformationBlockSize == NULL) {
+return EFI_INVALID_PARAMETER;
+  }
+
+  if (!CompareGuid (InformationType, )) {
+return EFI_UNSUPPORTED;
+  }
+
+  AdapterInfo = AllocateZeroPool (sizeof (EFI_ADAPTER_INFO_MEDIA_STATE));
+  if (AdapterInfo == NULL) {
+return EFI_OUT_OF_RESOURCES;
+  }
+
+  *InformationBlock = AdapterInfo;
+  *InformationBlockSize = sizeof (EFI_ADAPTER_INFO_MEDIA_STATE);
+
+  Genet = GENET_PRIVATE_DATA_FROM_AIP_THIS (This);
+  AdapterInfo->MediaState = GenericPhyUpdateConfig (>Phy);
+
+  return EFI_SUCCESS;
+}
+
+STATIC
+EFI_STATUS
+EFIAPI
+GenetAipSetInformation (
+  IN  

Re: [edk2-devel] [PATCH] OvmfPkg: End timer interrupt later to avoid stack overflow under load

[Igor Druzhinin]

On 17/06/2020 17:59, Paolo Bonzini wrote:
> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments 
> unless you have verified the sender and know the content is safe.
> 
> On 17/06/20 17:46, Laszlo Ersek wrote:
>>> That said, Igor's patch seems correct to me.  In fact, I'd even move
>>> DisableInterrupts before gBS->RestoreTPL unless there's a good reason
>>> not to do so.
>> OK, thank you!
>>
>> Igor, please confirm if you'd like to submit v2 with the update
>> suggested by Paolo, or if you prefer the current version. We're at the
>> beginning of the current development cycle, so I guess we can apply the
>> patch and see how it works in practice. If it ends up wreaking havoc on
>> some platforms, we can always revert the patch in time for the next
>> stable tag (edk2-stable202008).
> 
> For what it's worth "correct" means that I don't see anything that could
> break and in fact I find it good policy hygienic not to allow recursive
> interrupts.
> 
> v1 is okay for me too, so:
> 
> Reviewed-by: Paolo Bonzini 

Thanks, unfortunately it's not possible to move DisableInterrupts inside
TPL block as RestoreTPL would immediately enable them according to current
logic.

IMO RaiseTPL could technically save interrupt state inside it (in that
case it was disabled) and then honor it in RestoreTPL but that might have
more surprise consequences than the proposed change I reckon.

I will create a BZ ticket as requested.

Igor

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

View/Reply Online (#61434): https://edk2.groups.io/g/devel/message/61434
Mute This Topic: https://groups.io/mt/74913405/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 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Samer El-Haj-Mahmoud]

I worked with Pete offline on this..

This code seems to be violating the UEFI Spec:

https://github.com/tianocore/edk2/blob/a56af23f066e2816c67b7c6e64de7ddefcd70780/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c#L1763

  //
  // 3. Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load and 
execute
  //the boot option.
  //
  if (BmIsBootManagerMenuFilePath (BootOption->FilePath)) {
DEBUG ((EFI_D_INFO, "[Bds] Booting Boot Manager Menu.\n"));
BmStopHotkeyService (NULL, NULL);
  } else {
EfiSignalEventReadyToBoot();
//
// Report Status Code to indicate ReadyToBoot was signalled
//
REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER | 
EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
//
// 4. Repair system through DriverHealth protocol
//
BmRepairAllControllers (0);
  }

The UEFI Spec section 3.1.7 clearly states that Boot Options (and their 
FilePathList) *shall not* be evaluated prior to the completion of 
EFI_EVENT_GROUP_READY_TO_BOOT event group processing:

"After all SysPrep variables have been launched and exited, the platform 
shall notify EFI_EVENT_GROUP_READY_TO_BOOT event group and begin to evaluate 
Boot variables with Attributes set to LOAD_OPTION_CATEGORY_BOOT according 
to the order defined by BootOrder. The FilePathList of variables marked 
LOAD_OPTION_CATEGORY_BOOT shall not be evaluated prior to the completion of 
EFI_EVENT_GROUP_READY_TO_BOOT event group processing."

This is a prescriptive language that is stronger than the language in section 
7.1 which defines the ReadyToBoot event group in a general way:

"EFI_EVENT_GROUP_RESET_SYSTEM
This event group is notified by the system when ResetSystem() is invoked and 
the system is about to be reset. The event group is only notified prior to 
ExitBootServices() invocation."

The EDK2 code in the else block above (to call EfiSignalEventReadyToBoot() ) 
need to move before the code that is processing BootOption->FilePath. In fact, 
why is this signaling even a BootManager task? It should be a higher level BDS 
task (after processing SysPrp and before processing Boot options, per the 
spec). This would be somewhere around 
https://github.com/tianocore/edk2/blob/b15646484eaffcf7cc464fdea0214498f26addc2/MdeModulePkg/Universal/BdsDxe/BdsEntry.c#L1007
 where SysPrep is processed.

This should also take care of the issue Pete reported in this thread, without 
the need for explicitly signaling ReadyToBoot from PlatformRecovery (or 
changing the UEFI spec).

Thanks,
--Samer



From: devel@edk2.groups.io  On Behalf Of Samer 
El-Haj-Mahmoud via groups.io
Sent: Wednesday, June 17, 2020 12:42 PM
To: devel@edk2.groups.io; Andrei Warkentin (awarken...@vmware.com) 
; Wang, Sunny (HPS SW) ; p...@akeo.ie
Cc: zhichao@intel.com; ray...@intel.com; Ard Biesheuvel 
; l...@nuviainc.com; Samer El-Haj-Mahmoud 

Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: 
Signal ReadyToBoot on platform recovery

The UEFI spec (3.1.7) says:

"After all SysPrep variables have been launched and exited, the platform 
shall notify EFI_EVENT_GROUP_READY_TO_BOOT event group and begin to evaluate 
Boot variables with Attributes set to LOAD_OPTION_CATEGORY_BOOT according 
to the order defined by BootOrder. The FilePathList of variables marked 
LOAD_OPTION_CATEGORY_BOOT shall not be evaluated prior to the completion of 
EFI_EVENT_GROUP_READY_TO_BOOT event group processing."

The way I read this, I expect ReadyToBoot to be signaled after SysPrep (if 
any) are processed, but before Boot are processed. Is my understanding 
correct that this language implies ReadyToBoot need to be signaled even if 
BootOrder does not contain any Boot options marked as 
LOAD_OPTION_CATEGORY_BOOT? And if so, is EDK2 not doing this, which leads us to 
this patch (signaling it in PlatformRecovery?)



From: mailto:devel@edk2.groups.io  On Behalf Of 
Andrei Warkentin via groups.io
Sent: Wednesday, June 17, 2020 12:37 PM
To: Wang, Sunny (HPS SW) ; 
mailto:devel@edk2.groups.io; mailto:p...@akeo.ie
Cc: mailto:zhichao@intel.com; mailto:ray...@intel.com; Ard Biesheuvel 
; mailto:l...@nuviainc.com
Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: 
Signal ReadyToBoot on platform recovery

Thanks Pete.

I think the question I have, that I hope Tiano veterans can chime in, is 
whether we are doing the right thing, or if we should be overriding the boot 
mode? I.e. is it normal that we boot up in recovery until options are saved?


A



From: mailto:devel@edk2.groups.io  on behalf of 
Pete Batard via groups.io 
Sent: Wednesday, June 17, 2020 11:34 AM
To: Wang, Sunny (HPS SW) ; 
mailto:devel@edk2.groups.io 
Cc: 

Re: [edk2-devel] [PATCH] OvmfPkg: End timer interrupt later to avoid stack overflow under load

[Paolo Bonzini]

On 17/06/20 17:46, Laszlo Ersek wrote:
>> That said, Igor's patch seems correct to me.  In fact, I'd even move
>> DisableInterrupts before gBS->RestoreTPL unless there's a good reason
>> not to do so.
> OK, thank you!
> 
> Igor, please confirm if you'd like to submit v2 with the update
> suggested by Paolo, or if you prefer the current version. We're at the
> beginning of the current development cycle, so I guess we can apply the
> patch and see how it works in practice. If it ends up wreaking havoc on
> some platforms, we can always revert the patch in time for the next
> stable tag (edk2-stable202008).

For what it's worth "correct" means that I don't see anything that could
break and in fact I find it good policy hygienic not to allow recursive
interrupts.

v1 is okay for me too, so:

Reviewed-by: Paolo Bonzini 

Paolo


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

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

[edk2-devel] Components sub-section ordering

[Tim Lewis]

EDK2 build tool gurus:

 

Question: The current EDK2 .DSC specification, section 3.10 says that the
sub-elements in a Component must follow a specific ordering (LibraryClasses,
Pcds*, BuildOptions). But it is not clear why this is required. As a side
note, we have a number of .dsc files where this is not followed today, but
our tools developers wanted to know if this should be enforced.

 

Here is the text from the spec:

 

Within the context of an EDK II module sub-element, the 
entries must appear before  entries; the  entries
terminate with the start of either the  or  sub-section
header or the end of the scope defined by the right curly "}" brace. The
 sub-element must be the last sub-entry of an EDK II module's
scoped section. Entries for ,  and  are
used to replace the platform or global definition entries listed elsewhere.
LibraryClass and PCDs are globally defined in the DSC file's
[LibraryClasses] and [Pcds*] sections, while global BuildOptions may be
specified in either the DSC file's [BuildOptions] section or in the
$(WORKSPACE)/Conf/tools_def.txt file.

 

I would also note that the  is not listed here. 

 

Can we just elide this?

 

Thanks,

 

Tim Lewis

CTO, Insyde Software

www.insyde.com  

 


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

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

Re: [edk2-devel] [PATCH v5 1/1] MdeModulePkg.dec: Change PCDs for status code.

[Michael D Kinney]

Ming,

With this change, are the same PCDs listed as both
a Feature Flag PCD and a non-Feature Flag PCD?

That should not be allowed, and if that passes the
build, then the build tools should flag that as an
error condition.

Mike

> -Original Message-
> From: devel@edk2.groups.io  On
> Behalf Of Wang, Jian J
> Sent: Wednesday, June 17, 2020 7:43 AM
> To: Tan, Ming ; devel@edk2.groups.io
> Cc: Wu, Hao A 
> Subject: Re: [edk2-devel] [PATCH v5 1/1]
> MdeModulePkg.dec: Change PCDs for status code.
> 
> Reviewed-by: Jian J Wang 
> 
> Regards,
> Jian
> 
> > -Original Message-
> > From: Tan, Ming 
> > Sent: Wednesday, June 17, 2020 3:36 PM
> > To: devel@edk2.groups.io
> > Cc: Wang, Jian J ; Wu, Hao A
> 
> > Subject: [PATCH v5 1/1] MdeModulePkg.dec: Change PCDs
> for status code.
> >
> > REF:
> https://bugzilla.tianocore.org/show_bug.cgi?id=2786
> >
> > In order to support enable/disable report status code
> through memory
> > or serial dynamic, change the following PCDs from
> [PcdsFeatureFlag] to
> > [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic,
> PcdsDynamicEx]:
> >   PcdStatusCodeUseSerial
> >   PcdStatusCodeUseMemory
> > The original plaforms can use PcdsFixedAtBuild in .dsc
> files to save size.
> > Currently do not remove the old pcd type to keep
> compatible.
> >
> > Cc: Jian J Wang 
> > Cc: Hao A Wu 
> > Signed-off-by: Ming Tan 
> > ---
> > V5: Do not remove th old pcd type to keep compatible,
> and change to
> > standalone patch.
> > V4: No change for this 1/4 patch, just modify the 2-
> 4/4 patchs.
> > V3: Split one patch to several patchs, each Pkg has
> one patch.
> > V2: Change the new type from [PcdsDynamic] to
> [PcdsFixedAtBuild,
> > PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
> > And set to PcdsFixedAtBuild in the original
> platform .dsc files.
> >
> >  MdeModulePkg/MdeModulePkg.dec| 13
> +
> >  .../StatusCodeHandler/Pei/StatusCodeHandlerPei.c |  6
> +++---
> >  .../Pei/StatusCodeHandlerPei.inf |  6
> ++
> >  .../RuntimeDxe/StatusCodeHandlerRuntimeDxe.c | 16
> 
> >  .../RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf   |  6
> ++
> >  .../StatusCodeHandler/Smm/StatusCodeHandlerSmm.c | 10
> +-
> >  .../Smm/StatusCodeHandlerSmm.inf |  6
> ++
> >  7 files changed, 35 insertions(+), 28 deletions(-)
> >
> > diff --git a/MdeModulePkg/MdeModulePkg.dec
> > b/MdeModulePkg/MdeModulePkg.dec
> > index 4f44af694862..bd369d1f230e 100644
> > --- a/MdeModulePkg/MdeModulePkg.dec
> > +++ b/MdeModulePkg/MdeModulePkg.dec
> > @@ -2001,6 +2001,19 @@ [PcdsFixedAtBuild,
> PcdsPatchableInModule,
> > PcdsDynamic, PcdsDynamicEx]
> ># @Prompt TCG Platform Firmware Profile revision.
> >
> >
> gEfiMdeModulePkgTokenSpaceGuid.PcdTcgPfpMeasurementRevis
> ion|0|UINT3
> > 2|0x00010077
> >
> > +  ## Indicates if StatusCode is reported via Serial
> port.
> > +  #   TRUE  - Reports StatusCode via Serial port.
> > +  #   FALSE - Does not report StatusCode via Serial
> port.
> > +  # @Prompt Enable StatusCode via Serial port.
> > +
> >
> gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|TR
> UE|BOOLEAN|
> > 0x00010022
> > +
> > +  ## Indicates if StatusCode is stored in memory.
> > +  #  The memory is boot time memory in PEI Phase and
> is runtime memory in
> > DXE Phase.
> > +  #   TRUE  - Stores StatusCode in memory.
> > +  #   FALSE - Does not store StatusCode in
> memory.
> > +  # @Prompt Enable StatusCode via memory.
> > +
> >
> gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseMemory|FA
> LSE|BOOLEA
> > N|0x00010023
> > +
> >  [PcdsPatchableInModule]
> >## Specify memory size with page number for PEI
> code when
> >#  Loading Module at Fixed Address feature is
> enabled.
> > diff --git
> >
> a/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCod
> eHandlerPei.c
> >
> b/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCod
> eHandlerPei.c
> > index 1b07f92f3ce8..9b2ea4ee84d9 100644
> > ---
> a/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCod
> eHandlerPei.c
> > +++
> >
> b/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCod
> eHandlerPei.c
> > @@ -2,7 +2,7 @@
> >Report Status Code Handler PEIM which produces
> general handlers and hook
> > them
> >onto the PEI status code router.
> >
> > -  Copyright (c) 2009 - 2018, Intel Corporation. All
> rights reserved.
> > +  Copyright (c) 2009 - 2020, Intel Corporation. All
> rights reserved.
> >SPDX-License-Identifier: BSD-2-Clause-Patent
> >
> >  **/
> > @@ -45,13 +45,13 @@ StatusCodeHandlerPeiEntry (
> >// If enable UseSerial, then initialize serial
> port.
> >// if enable UseMemory, then initialize memory
> status code worker.
> >//
> > -  if (FeaturePcdGet (PcdStatusCodeUseSerial)) {
> > +  if (PcdGetBool (PcdStatusCodeUseSerial)) {
> >  Status = SerialPortInitialize();
> >  ASSERT_EFI_ERROR (Status);
> >  Status = RscHandlerPpi->Register
> (SerialStatusCodeReportWorker);
> >  

Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Pete Batard]

On 2020.06.17 17:36, Andrei Warkentin wrote:

Thanks Pete.

I think the question I have, that I hope Tiano veterans can chime in, is 
whether we are doing the right thing, or if we should be overriding the 
boot mode? I.e. is it normal that we boot up in recovery until options 
are saved?


Yes, that's the other part of the problem, that I didn't want to bring 
in because it's Pi-platform specific and I still see OnReadyToBoot as an 
event we logically want to signal during Platform Recovery.


Still, that doesn't mean I wouldn't want to have feedback on this too.

Regards,

/Pete




A



*From:* devel@edk2.groups.io  on behalf of Pete 
Batard via groups.io 

*Sent:* Wednesday, June 17, 2020 11:34 AM
*To:* Wang, Sunny (HPS SW) ; devel@edk2.groups.io 

*Cc:* zhichao@intel.com ; ray...@intel.com 
; ard.biesheu...@arm.com ; 
l...@nuviainc.com 
*Subject:* Re: [edk2-devel] [edk2][PATCH 1/1] 
MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

On 2020.06.17 14:04, Wang, Sunny (HPS SW) wrote:

Thanks for checking my comments, Pete.


Or is the "one more" the issue, meaning that it would get signaled more than 
once?

[Sunny] Yeah, it would get signaled more than once if the PlatformRecovery 
option (a UEFI application) calls EfiBootManagerBoot() to launch the recovered 
boot option inside of the application.


Okay.

One element that I'm going to point out is that, with the current EDK2
code (i.e. without this proposal applied), and after a user goes into
the setup to save their boot options in order for regular boot options
to get executed instead of PlaformRecovery, the OnReadyToBoot event is
actually called twice.

So my understanding is that, while we of course want to avoid this and
any patch proposal should actively try to prevent it, it seems we
already have behaviour in EDK2 that can lead to OnReadyToBoot being
signalled more than once.

At least the current Pi 4 platform does demonstrate this behaviour. For
instance, if you run DEBUG, you will see two instances of:

    RemoveDtStdoutPath: could not retrieve DT blob - Not Found

which is a one-instance message generated from the ConsolePrefDxe's
OnReadyToBoot() call. I've also confirmed more specifically that
OnReadyToBoot() is indeed called twice.

I don't recall us doing much of any special with regards to boot options
for the Pi platform, so my guess is that it's probably not the only
platform where OnReadyToBoot might be signalled more than once, and that
this might be tied to a default EDK2 behaviour. Therefore I don't see
having a repeated event as a major deal breaker (though, again, if we
can avoid that, we of course will want to).


I don't mind trying an alternative approach, but I don't understand how what 
you describe would help. Can you please be more specific about what you have in 
mind?

[Sunny] Sure. I added more information below. If it is still not clear enough, 
feel free to let me know.
   1. Create a UEFI application with the code to signal ReadyToBoot and 
pick /efi/boot/bootaa64.efi from either SD or USB and run it.


So that would basically be adding code that duplicates, in part, what
Platform Recovery already does.

I have to be honest: Even outside of the extra work this would require,
I don't really like the idea of having to write our own application, as
it will introduce new possible points of failures and require extra
maintenance (especially as we will want to be able to handle network
boot and other options, and before long, I fear that we're going to have
to write our own Pi specific boot manager). Doing so simply because the
current Platform Recovery, which does suit our needs otherwise, is not
designed to call ReadyToBoot does not seem like the best course of
action in my book.

Instead, I still logically believe that any option that calls a boot
loader should signal ReadyToBoot, regardless of whether it was launched
from Boot Manager or Platform Recovery, and that it shouldn't be left to
each platform to work around that.

Of course, I understand that this would require a specs change, and that
it also may have ramifications for existing platforms that interpret the
current specs pedantically. But to me, regardless of what the specs
appear to be limiting it to right now, the logic of a "ReadyToBoot"
event is that it should be signalled whenever a bootloader is about to
be executed, rather than only when a bootloader happened to be launched
through a formal Boot Manager option.

I would therefore appreciate if other people could weigh in on this
matter, to see if I'm the only one who believes that we could ultimately
have more to gain from signalling ReadyToBoot with PlatformRecovery
options than leaving things as they stand right now...


   2. Then, call EfiBootManagerInitializeLoadOption like the following in a DXE 
driver or other places before "Default PlatformRecovery" registration:
    Status = 

Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Samer El-Haj-Mahmoud]

The UEFI spec (3.1.7) says:


"After all SysPrep variables have been launched and exited, the platform 
shall notify EFI_EVENT_GROUP_READY_TO_BOOT event group and begin to evaluate 
Boot variables with Attributes set to LOAD_OPTION_CATEGORY_BOOT according 
to the order defined by BootOrder. The FilePathList of variables marked 
LOAD_OPTION_CATEGORY_BOOT shall not be evaluated prior to the completion of 
EFI_EVENT_GROUP_READY_TO_BOOT event group processing."

The way I read this, I expect ReadyToBoot to be signaled after SysPrep (if 
any) are processed, but before Boot are processed. Is my understanding 
correct that this language implies ReadyToBoot need to be signaled even if 
BootOrder does not contain any Boot options marked as 
LOAD_OPTION_CATEGORY_BOOT? And if so, is EDK2 not doing this, which leads us to 
this patch (signaling it in PlatformRecovery?)



From: devel@edk2.groups.io  On Behalf Of Andrei Warkentin 
via groups.io
Sent: Wednesday, June 17, 2020 12:37 PM
To: Wang, Sunny (HPS SW) ; devel@edk2.groups.io; p...@akeo.ie
Cc: zhichao@intel.com; ray...@intel.com; Ard Biesheuvel 
; l...@nuviainc.com
Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: 
Signal ReadyToBoot on platform recovery

Thanks Pete.

I think the question I have, that I hope Tiano veterans can chime in, is 
whether we are doing the right thing, or if we should be overriding the boot 
mode? I.e. is it normal that we boot up in recovery until options are saved?


A



From: devel@edk2.groups.io 
mailto:devel@edk2.groups.io>> on behalf of Pete Batard 
via groups.io mailto:pete=akeo...@groups.io>>
Sent: Wednesday, June 17, 2020 11:34 AM
To: Wang, Sunny (HPS SW) mailto:sunnyw...@hpe.com>>; 
devel@edk2.groups.io 
mailto:devel@edk2.groups.io>>
Cc: zhichao@intel.com 
mailto:zhichao@intel.com>>; 
ray...@intel.com 
mailto:ray...@intel.com>>; 
ard.biesheu...@arm.com 
mailto:ard.biesheu...@arm.com>>; 
l...@nuviainc.com 
mailto:l...@nuviainc.com>>
Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: 
Signal ReadyToBoot on platform recovery

On 2020.06.17 14:04, Wang, Sunny (HPS SW) wrote:
> Thanks for checking my comments, Pete.
>
>> Or is the "one more" the issue, meaning that it would get signaled more than 
>> once?
> [Sunny] Yeah, it would get signaled more than once if the PlatformRecovery 
> option (a UEFI application) calls EfiBootManagerBoot() to launch the 
> recovered boot option inside of the application.

Okay.

One element that I'm going to point out is that, with the current EDK2
code (i.e. without this proposal applied), and after a user goes into
the setup to save their boot options in order for regular boot options
to get executed instead of PlaformRecovery, the OnReadyToBoot event is
actually called twice.

So my understanding is that, while we of course want to avoid this and
any patch proposal should actively try to prevent it, it seems we
already have behaviour in EDK2 that can lead to OnReadyToBoot being
signalled more than once.

At least the current Pi 4 platform does demonstrate this behaviour. For
instance, if you run DEBUG, you will see two instances of:

   RemoveDtStdoutPath: could not retrieve DT blob - Not Found

which is a one-instance message generated from the ConsolePrefDxe's
OnReadyToBoot() call. I've also confirmed more specifically that
OnReadyToBoot() is indeed called twice.

I don't recall us doing much of any special with regards to boot options
for the Pi platform, so my guess is that it's probably not the only
platform where OnReadyToBoot might be signalled more than once, and that
this might be tied to a default EDK2 behaviour. Therefore I don't see
having a repeated event as a major deal breaker (though, again, if we
can avoid that, we of course will want to).

>> I don't mind trying an alternative approach, but I don't understand how what 
>> you describe would help. Can you please be more specific about what you have 
>> in mind?
> [Sunny] Sure. I added more information below. If it is still not clear 
> enough, feel free to let me know.
>   1. Create a UEFI application with the code to signal ReadyToBoot and 
> pick /efi/boot/bootaa64.efi from either SD or USB and run it.

So that would basically be adding code that duplicates, in part, what
Platform Recovery already does.

I have to be honest: Even outside of the extra work this would require,
I don't really like the idea of having to write our own application, as
it will introduce new possible points of failures and require extra
maintenance (especially as we will want to be able to handle network
boot and other options, and before long, I fear that we're going to have
to write our own Pi specific boot manager). Doing so simply because the
current Platform 

Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Andrei Warkentin]

Thanks Pete.

I think the question I have, that I hope Tiano veterans can chime in, is 
whether we are doing the right thing, or if we should be overriding the boot 
mode? I.e. is it normal that we boot up in recovery until options are saved?


A



From: devel@edk2.groups.io  on behalf of Pete Batard via 
groups.io 
Sent: Wednesday, June 17, 2020 11:34 AM
To: Wang, Sunny (HPS SW) ; devel@edk2.groups.io 

Cc: zhichao@intel.com ; ray...@intel.com 
; ard.biesheu...@arm.com ; 
l...@nuviainc.com 
Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: 
Signal ReadyToBoot on platform recovery

On 2020.06.17 14:04, Wang, Sunny (HPS SW) wrote:
> Thanks for checking my comments, Pete.
>
>> Or is the "one more" the issue, meaning that it would get signaled more than 
>> once?
> [Sunny] Yeah, it would get signaled more than once if the PlatformRecovery 
> option (a UEFI application) calls EfiBootManagerBoot() to launch the 
> recovered boot option inside of the application.

Okay.

One element that I'm going to point out is that, with the current EDK2
code (i.e. without this proposal applied), and after a user goes into
the setup to save their boot options in order for regular boot options
to get executed instead of PlaformRecovery, the OnReadyToBoot event is
actually called twice.

So my understanding is that, while we of course want to avoid this and
any patch proposal should actively try to prevent it, it seems we
already have behaviour in EDK2 that can lead to OnReadyToBoot being
signalled more than once.

At least the current Pi 4 platform does demonstrate this behaviour. For
instance, if you run DEBUG, you will see two instances of:

   RemoveDtStdoutPath: could not retrieve DT blob - Not Found

which is a one-instance message generated from the ConsolePrefDxe's
OnReadyToBoot() call. I've also confirmed more specifically that
OnReadyToBoot() is indeed called twice.

I don't recall us doing much of any special with regards to boot options
for the Pi platform, so my guess is that it's probably not the only
platform where OnReadyToBoot might be signalled more than once, and that
this might be tied to a default EDK2 behaviour. Therefore I don't see
having a repeated event as a major deal breaker (though, again, if we
can avoid that, we of course will want to).

>> I don't mind trying an alternative approach, but I don't understand how what 
>> you describe would help. Can you please be more specific about what you have 
>> in mind?
> [Sunny] Sure. I added more information below. If it is still not clear 
> enough, feel free to let me know.
>   1. Create a UEFI application with the code to signal ReadyToBoot and 
> pick /efi/boot/bootaa64.efi from either SD or USB and run it.

So that would basically be adding code that duplicates, in part, what
Platform Recovery already does.

I have to be honest: Even outside of the extra work this would require,
I don't really like the idea of having to write our own application, as
it will introduce new possible points of failures and require extra
maintenance (especially as we will want to be able to handle network
boot and other options, and before long, I fear that we're going to have
to write our own Pi specific boot manager). Doing so simply because the
current Platform Recovery, which does suit our needs otherwise, is not
designed to call ReadyToBoot does not seem like the best course of
action in my book.

Instead, I still logically believe that any option that calls a boot
loader should signal ReadyToBoot, regardless of whether it was launched
from Boot Manager or Platform Recovery, and that it shouldn't be left to
each platform to work around that.

Of course, I understand that this would require a specs change, and that
it also may have ramifications for existing platforms that interpret the
current specs pedantically. But to me, regardless of what the specs
appear to be limiting it to right now, the logic of a "ReadyToBoot"
event is that it should be signalled whenever a bootloader is about to
be executed, rather than only when a bootloader happened to be launched
through a formal Boot Manager option.

I would therefore appreciate if other people could weigh in on this
matter, to see if I'm the only one who believes that we could ultimately
have more to gain from signalling ReadyToBoot with PlatformRecovery
options than leaving things as they stand right now...

>   2. Then, call EfiBootManagerInitializeLoadOption like the following in 
> a DXE driver or other places before "Default PlatformRecovery" registration:
>Status = EfiBootManagerInitializeLoadOption (
>   ,
>   0,  
>-> 0 is the OptionNumber to let application be load before " 
> Default PlatformRecovery" option
>   LoadOptionTypePlatformRecovery,
>   LOAD_OPTION_ACTIVE,
>   L"Application for recovering 

Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Pete Batard]

On 2020.06.17 14:04, Wang, Sunny (HPS SW) wrote:

Thanks for checking my comments, Pete.


Or is the "one more" the issue, meaning that it would get signaled more than 
once?

[Sunny] Yeah, it would get signaled more than once if the PlatformRecovery 
option (a UEFI application) calls EfiBootManagerBoot() to launch the recovered 
boot option inside of the application.


Okay.

One element that I'm going to point out is that, with the current EDK2 
code (i.e. without this proposal applied), and after a user goes into 
the setup to save their boot options in order for regular boot options 
to get executed instead of PlaformRecovery, the OnReadyToBoot event is 
actually called twice.


So my understanding is that, while we of course want to avoid this and 
any patch proposal should actively try to prevent it, it seems we 
already have behaviour in EDK2 that can lead to OnReadyToBoot being 
signalled more than once.


At least the current Pi 4 platform does demonstrate this behaviour. For 
instance, if you run DEBUG, you will see two instances of:


  RemoveDtStdoutPath: could not retrieve DT blob - Not Found

which is a one-instance message generated from the ConsolePrefDxe's 
OnReadyToBoot() call. I've also confirmed more specifically that 
OnReadyToBoot() is indeed called twice.


I don't recall us doing much of any special with regards to boot options 
for the Pi platform, so my guess is that it's probably not the only 
platform where OnReadyToBoot might be signalled more than once, and that 
this might be tied to a default EDK2 behaviour. Therefore I don't see 
having a repeated event as a major deal breaker (though, again, if we 
can avoid that, we of course will want to).



I don't mind trying an alternative approach, but I don't understand how what 
you describe would help. Can you please be more specific about what you have in 
mind?

[Sunny] Sure. I added more information below. If it is still not clear enough, 
feel free to let me know.
  1. Create a UEFI application with the code to signal ReadyToBoot and pick 
/efi/boot/bootaa64.efi from either SD or USB and run it.


So that would basically be adding code that duplicates, in part, what 
Platform Recovery already does.


I have to be honest: Even outside of the extra work this would require, 
I don't really like the idea of having to write our own application, as 
it will introduce new possible points of failures and require extra 
maintenance (especially as we will want to be able to handle network 
boot and other options, and before long, I fear that we're going to have 
to write our own Pi specific boot manager). Doing so simply because the 
current Platform Recovery, which does suit our needs otherwise, is not 
designed to call ReadyToBoot does not seem like the best course of 
action in my book.


Instead, I still logically believe that any option that calls a boot 
loader should signal ReadyToBoot, regardless of whether it was launched 
from Boot Manager or Platform Recovery, and that it shouldn't be left to 
each platform to work around that.


Of course, I understand that this would require a specs change, and that 
it also may have ramifications for existing platforms that interpret the 
current specs pedantically. But to me, regardless of what the specs 
appear to be limiting it to right now, the logic of a "ReadyToBoot" 
event is that it should be signalled whenever a bootloader is about to 
be executed, rather than only when a bootloader happened to be launched 
through a formal Boot Manager option.


I would therefore appreciate if other people could weigh in on this 
matter, to see if I'm the only one who believes that we could ultimately 
have more to gain from signalling ReadyToBoot with PlatformRecovery 
options than leaving things as they stand right now...



  2. Then, call EfiBootManagerInitializeLoadOption like the following in a DXE driver 
or other places before "Default PlatformRecovery" registration:
   Status = EfiBootManagerInitializeLoadOption (
  ,
  0, 
-> 0 is the OptionNumber to let application be load before " Default 
PlatformRecovery" option
  LoadOptionTypePlatformRecovery,
  LOAD_OPTION_ACTIVE,
  L"Application for recovering boot options",
  FilePath,
-> FilePath is the Application's device path,
  NULL,
  0
  );



My reasoning is that, if PlatformRecovery can execute a regular bootloader 
like /efi/boot/boot.efi from installation media, then it should go through 
the same kind of initialization that happens for a regular boot option, and 
that should include signaling the ReadyToBoot event.

[Sunny] Thanks for clarifying this, and Sorry about that I missed your cover letter for 
this patch.  I was just thinking that we may not really need to make 

Re: [edk2-devel] [PATCH] ArmPkg/PlatformBootManagerLib: regenerate boot options on boot failure

[Andrei Warkentin]

Thanks for working on this.

Reviewed-by: Andrei Warkentin 

A non-blocking question: is a reboot necessary? Would it be possible to just 
retry the boot sequence?

A

From: Ard Biesheuvel 
Sent: Tuesday, June 16, 2020 12:48 PM
To: devel@edk2.groups.io 
Cc: l...@nuviainc.com ; Ard Biesheuvel 
; Pete Batard ; Andrei Warkentin 
; Samer El-Haj-Mahmoud 
Subject: [PATCH] ArmPkg/PlatformBootManagerLib: regenerate boot options on boot 
failure

One of the side effects of the recent changes to PlatformBootManagerLib
changes to avoid connecting all devices on every boot is that we no
longer default to network boot on a virgin boot, but end up in the
UiApp menu. At this point, the autogenerated boot options that we used
to rely on will be instantiated too, but it does break the unattended
boot case where devices are expected to attempt a network boot on the
very first power on.

Let's work around this by refreshing all boot options explicitly in
the UnableToBoot() handler, and rebooting the system if doing so
resulted in a change to the total number of configured boot options.
This way, we ultimately end up in the UiApp as before if no boot
options could be started, but only after all the autogenerated ones
have been attempted as well.


Cc: Pete Batard 

Cc: Andrei Warkentin (awarken...@vmware.com) 

Cc: Samer El-Haj-Mahmoud 

Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c | 34 
 1 file changed, 34 insertions(+)

diff --git a/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c 
b/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
index 15c5cac1bea0..9905cad22908 100644
--- a/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
+++ b/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
@@ -820,6 +820,40 @@ PlatformBootManagerUnableToBoot (
 {

   EFI_STATUS   Status;

   EFI_BOOT_MANAGER_LOAD_OPTION BootManagerMenu;

+  EFI_BOOT_MANAGER_LOAD_OPTION *BootOptions;

+  UINTNOldBootOptionCount;

+  UINTNNewBootOptionCount;

+

+  //

+  // Record the total number of boot configured boot options

+  //

+  BootOptions = EfiBootManagerGetLoadOptions (,

+  LoadOptionTypeBoot);

+  EfiBootManagerFreeLoadOptions (BootOptions, OldBootOptionCount);

+

+  //

+  // Connect all devices, and regenerate all boot options

+  //

+  EfiBootManagerConnectAll ();

+  EfiBootManagerRefreshAllBootOption ();

+

+  //

+  // Record the updated number of boot configured boot options

+  //

+  BootOptions = EfiBootManagerGetLoadOptions (,

+  LoadOptionTypeBoot);

+  EfiBootManagerFreeLoadOptions (BootOptions, NewBootOptionCount);

+

+  //

+  // If the number of configured boot options has changed, reboot

+  // the system so the new boot options will be taken into account

+  // while executing the ordinary BDS bootflow sequence.

+  //

+  if (NewBootOptionCount != OldBootOptionCount) {

+DEBUG ((DEBUG_WARN, "%a: rebooting after refreshing all boot options\n",

+  __FUNCTION__));

+gRT->ResetSystem (EfiResetCold, EFI_SUCCESS, 0, NULL);

+  }



   Status = EfiBootManagerGetBootManagerMenu ();

   if (EFI_ERROR (Status)) {

--
2.27.0


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

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

Re: [edk2-devel] [PATCH] EmbeddedPkg/NonCoherentDmaLib: avoid dereferencing bogus buffer address

[Andrei Warkentin]

Reviewed-by: Andrei Warkentin 

From: devel@edk2.groups.io  on behalf of Ard Biesheuvel 
via groups.io 
Sent: Wednesday, June 17, 2020 10:38 AM
To: devel@edk2.groups.io 
Cc: l...@nuviainc.com ; p...@akeo.ie ; Andrei 
Warkentin ; jeremy.lin...@arm.com 
; samer.el-haj-mahm...@arm.com 
; Ard Biesheuvel 
Subject: [edk2-devel] [PATCH] EmbeddedPkg/NonCoherentDmaLib: avoid 
dereferencing bogus buffer address

The bounce buffering code in NonCoherentDmaLib copies data into the
bounce buffer using CopyMem(), but passes Map->HostAddress as the
source of the copy before it has been assigned its correct value.

Signed-off-by: Ard Biesheuvel 
---
 EmbeddedPkg/Library/NonCoherentDmaLib/NonCoherentDmaLib.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/EmbeddedPkg/Library/NonCoherentDmaLib/NonCoherentDmaLib.c 
b/EmbeddedPkg/Library/NonCoherentDmaLib/NonCoherentDmaLib.c
index 115345765435..9c8ef5bfb533 100644
--- a/EmbeddedPkg/Library/NonCoherentDmaLib/NonCoherentDmaLib.c
+++ b/EmbeddedPkg/Library/NonCoherentDmaLib/NonCoherentDmaLib.c
@@ -225,8 +225,7 @@ DmaMap (
 }



 if (Map->Operation == MapOperationBusMasterRead) {

-  CopyMem (Map->BufferAddress, (VOID *)(UINTN)Map->HostAddress,

-*NumberOfBytes);

+  CopyMem (Map->BufferAddress, (VOID *)(UINTN)HostAddress, *NumberOfBytes);

 }

 mCpu->FlushDataCache (mCpu, (UINTN)Map->BufferAddress, AllocSize,

 EfiCpuFlushTypeWriteBack);

--
2.27.0


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

View/Reply Online (#61421): 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F61421data=02%7C01%7Cawarkentin%40vmware.com%7Ce0cab9a2b8a74880b69f08d812d48073%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637280051185406598sdata=NylhdsdCkUdiGZZB6ya0pCMs8vYFb8tpdjW29q1dJAQ%3Dreserved=0
Mute This Topic: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.io%2Fmt%2F74939973%2F4387333data=02%7C01%7Cawarkentin%40vmware.com%7Ce0cab9a2b8a74880b69f08d812d48073%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637280051185406598sdata=2Wv1bPYhk2Ac32ItKenF9bmig5t%2FKJuTFVWZacFZvY8%3Dreserved=0
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Funsubdata=02%7C01%7Cawarkentin%40vmware.com%7Ce0cab9a2b8a74880b69f08d812d48073%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637280051185406598sdata=4Yp5s5IOCF%2BY6OwqcDZmcmgn1crE9MxuL3TnHEGSMsM%3Dreserved=0
  [awarken...@vmware.com]
-=-=-=-=-=-=


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

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

Re: [edk2-devel] [PATCH] EmbeddedPkg/NonCoherentDmaLib: avoid dereferencing bogus buffer address

[Leif Lindholm]

On Wed, Jun 17, 2020 at 17:38:24 +0200, Ard Biesheuvel wrote:
> The bounce buffering code in NonCoherentDmaLib copies data into the
> bounce buffer using CopyMem(), but passes Map->HostAddress as the
> source of the copy before it has been assigned its correct value.

Whoops.

> Signed-off-by: Ard Biesheuvel 

Reviewed-by: Leif Lindholm 

> ---
>  EmbeddedPkg/Library/NonCoherentDmaLib/NonCoherentDmaLib.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/EmbeddedPkg/Library/NonCoherentDmaLib/NonCoherentDmaLib.c 
> b/EmbeddedPkg/Library/NonCoherentDmaLib/NonCoherentDmaLib.c
> index 115345765435..9c8ef5bfb533 100644
> --- a/EmbeddedPkg/Library/NonCoherentDmaLib/NonCoherentDmaLib.c
> +++ b/EmbeddedPkg/Library/NonCoherentDmaLib/NonCoherentDmaLib.c
> @@ -225,8 +225,7 @@ DmaMap (
>  }
>  
>  if (Map->Operation == MapOperationBusMasterRead) {
> -  CopyMem (Map->BufferAddress, (VOID *)(UINTN)Map->HostAddress,
> -*NumberOfBytes);
> +  CopyMem (Map->BufferAddress, (VOID *)(UINTN)HostAddress, 
> *NumberOfBytes);
>  }
>  mCpu->FlushDataCache (mCpu, (UINTN)Map->BufferAddress, AllocSize,
>  EfiCpuFlushTypeWriteBack);
> -- 
> 2.27.0
> 

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

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

Re: [edk2-devel] [PATCH] OvmfPkg: End timer interrupt later to avoid stack overflow under load

[Laszlo Ersek]

On 06/17/20 15:51, Paolo Bonzini wrote:
> On 16/06/20 20:42, Laszlo Ersek wrote:
>> (Hmmm... maybe the hypervisor *has* to queue the timer interrupts,
>> otherwise some of them would simply be lost, and the guest would lose
>> track of time.)
> 
> Yes, there are various kinds of coalescing of interrupts that
> hypervisors perform to help the guest keep track of time.  This is
> especially true of the PIT and RTC; newer OSes track time directly from
> the TSC, the HPET or the APIC timer so they tolerate lost ticks much better.
> 
> That said, Igor's patch seems correct to me.  In fact, I'd even move
> DisableInterrupts before gBS->RestoreTPL unless there's a good reason
> not to do so.

OK, thank you!

Igor, please confirm if you'd like to submit v2 with the update
suggested by Paolo, or if you prefer the current version. We're at the
beginning of the current development cycle, so I guess we can apply the
patch and see how it works in practice. If it ends up wreaking havoc on
some platforms, we can always revert the patch in time for the next
stable tag (edk2-stable202008).

Perhaps we should also file a TianoCore BZ for this issue, with a clear
problem statement, and the solution outline. The commit message is not
lacking, but I think a TianoCore BZ could be easier to find with a web
search, if users (not developers) want to comment after the patch is
merged. It's also easier to round up (possibly) important changes, for
stable tag content review, when there are BZs.

Thanks!
Laszlo


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

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

[edk2-devel] [PATCH] EmbeddedPkg/NonCoherentDmaLib: avoid dereferencing bogus buffer address

[Ard Biesheuvel]

The bounce buffering code in NonCoherentDmaLib copies data into the
bounce buffer using CopyMem(), but passes Map->HostAddress as the
source of the copy before it has been assigned its correct value.

Signed-off-by: Ard Biesheuvel 
---
 EmbeddedPkg/Library/NonCoherentDmaLib/NonCoherentDmaLib.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/EmbeddedPkg/Library/NonCoherentDmaLib/NonCoherentDmaLib.c 
b/EmbeddedPkg/Library/NonCoherentDmaLib/NonCoherentDmaLib.c
index 115345765435..9c8ef5bfb533 100644
--- a/EmbeddedPkg/Library/NonCoherentDmaLib/NonCoherentDmaLib.c
+++ b/EmbeddedPkg/Library/NonCoherentDmaLib/NonCoherentDmaLib.c
@@ -225,8 +225,7 @@ DmaMap (
 }
 
 if (Map->Operation == MapOperationBusMasterRead) {
-  CopyMem (Map->BufferAddress, (VOID *)(UINTN)Map->HostAddress,
-*NumberOfBytes);
+  CopyMem (Map->BufferAddress, (VOID *)(UINTN)HostAddress, *NumberOfBytes);
 }
 mCpu->FlushDataCache (mCpu, (UINTN)Map->BufferAddress, AllocSize,
 EfiCpuFlushTypeWriteBack);
-- 
2.27.0


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

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

Re: [edk2-devel] [PATCH V3 1/2] MdePkg/PciSegmentInfoLib: Add missing EFIAPI to GetPciSegmentInfo()

[Liming Gao]

Reviewed-by: Liming Gao 

> -Original Message-
> From: Ni, Ray 
> Sent: Wednesday, June 17, 2020 4:41 PM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming 
> ; Liu, Zhiguang 
> Subject: [PATCH V3 1/2] MdePkg/PciSegmentInfoLib: Add missing EFIAPI to 
> GetPciSegmentInfo()
> 
> All public APIs should have EFIAPI modifier. Somehow PciSegmentInfoLib
> missed the EFIAPI modifier.
> The patch updates the library header file and NULL instance in MdePkg
> to add the missing EFIAPI.
> 
> Signed-off-by: Ray Ni 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> ---
>  MdePkg/Include/Library/PciSegmentInfoLib.h   | 3 ++-
>  MdePkg/Library/BasePciSegmentInfoLibNull/PciSegmentInfoLib.c | 3 ++-
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/MdePkg/Include/Library/PciSegmentInfoLib.h 
> b/MdePkg/Include/Library/PciSegmentInfoLib.h
> index 320a223628..659ff85649 100644
> --- a/MdePkg/Include/Library/PciSegmentInfoLib.h
> +++ b/MdePkg/Include/Library/PciSegmentInfoLib.h
> @@ -3,7 +3,7 @@
> 
> 
>This library is consumed by PciSegmentLib to support multiple segment PCI 
> configuration access.
> 
> 
> 
> -  Copyright (c) 2017, Intel Corporation. All rights reserved.
> 
> +  Copyright (c) 2017 - 2020, Intel Corporation. All rights reserved.
> 
>SPDX-License-Identifier: BSD-2-Clause-Patent
> 
> 
> 
>  **/
> 
> @@ -28,6 +28,7 @@ typedef struct {
>@retval A callee owned array holding the segment information.
> 
>  **/
> 
>  PCI_SEGMENT_INFO *
> 
> +EFIAPI
> 
>  GetPciSegmentInfo (
> 
>UINTN  *Count
> 
>);
> 
> diff --git a/MdePkg/Library/BasePciSegmentInfoLibNull/PciSegmentInfoLib.c
> b/MdePkg/Library/BasePciSegmentInfoLibNull/PciSegmentInfoLib.c
> index f9019c4e64..3ec7784057 100644
> --- a/MdePkg/Library/BasePciSegmentInfoLibNull/PciSegmentInfoLib.c
> +++ b/MdePkg/Library/BasePciSegmentInfoLibNull/PciSegmentInfoLib.c
> @@ -2,7 +2,7 @@
>Default PCI Segment Information Library that returns one segment whose
> 
>segment base address equals to PcdPciExpressBaseAddress.
> 
> 
> 
> -  Copyright (c) 2017, Intel Corporation. All rights reserved.
> 
> +  Copyright (c) 2017 - 2020, Intel Corporation. All rights reserved.
> 
>SPDX-License-Identifier: BSD-2-Clause-Patent
> 
> 
> 
>  **/
> 
> @@ -21,6 +21,7 @@
>@retval A callee owned array holding the segment information.
> 
>  **/
> 
>  PCI_SEGMENT_INFO *
> 
> +EFIAPI
> 
>  GetPciSegmentInfo (
> 
>UINTN  *Count
> 
>)
> 
> --
> 2.26.2.windows.1


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

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

Re: [edk2-devel] [PATCH edk2-platforms 2/8] Silicon/NXP: Chassis2: define SVR macros

[Leif Lindholm]

On Wed, Jun 10, 2020 at 02:50:53 +0530, Wasim Khan wrote:
> From: Wasim Khan 
> 
> Define macros to retrieve System Version Register(SVR)
> related information
> 
> Signed-off-by: Wasim Khan 
> ---
>  Silicon/NXP/Chassis2/Include/Chassis.h | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Silicon/NXP/Chassis2/Include/Chassis.h 
> b/Silicon/NXP/Chassis2/Include/Chassis.h
> index e5edd80134a4..7e8bf224884b 100644
> --- a/Silicon/NXP/Chassis2/Include/Chassis.h
> +++ b/Silicon/NXP/Chassis2/Include/Chassis.h
> @@ -12,6 +12,10 @@
>  
>  #define  NXP_LAYERSCAPE_CHASSIS2_DCFG_ADDRESS  0x1EE
>  
> +#define SVR_SOC_VER(svr)(((svr) >> 8) & 0xFE)
> +#define SVR_MAJOR(svr)  (((svr) >> 4) & 0xf)
> +#define SVR_MINOR(svr)  (((svr) >> 0) & 0xf)
> +
>  /* SMMU Defintions */
>  #define SMMU_BASE_ADDR 0x0900
>  #define SMMU_REG_SCR0  (SMMU_BASE_ADDR + 0x0)

These macros are identical between Chassis2 and Chassis3V2, and they
also look like exactly the sort of thing you want identical across
different chassis. Is there a common header file they can use?

(The set is straightforward, I have no other comments on it.)

/
Leif

> -- 
> 2.7.4
> 

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

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

Re: [edk2-devel] [PATCH v5 1/1] MdeModulePkg.dec: Change PCDs for status code.

[Wang, Jian J]

Reviewed-by: Jian J Wang 

Regards,
Jian

> -Original Message-
> From: Tan, Ming 
> Sent: Wednesday, June 17, 2020 3:36 PM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J ; Wu, Hao A 
> Subject: [PATCH v5 1/1] MdeModulePkg.dec: Change PCDs for status code.
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2786
> 
> In order to support enable/disable report status code through memory
> or serial dynamic, change the following PCDs from [PcdsFeatureFlag] to
> [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]:
>   PcdStatusCodeUseSerial
>   PcdStatusCodeUseMemory
> The original plaforms can use PcdsFixedAtBuild in .dsc files to save size.
> Currently do not remove the old pcd type to keep compatible.
> 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Signed-off-by: Ming Tan 
> ---
> V5: Do not remove th old pcd type to keep compatible, and change to
> standalone patch.
> V4: No change for this 1/4 patch, just modify the 2-4/4 patchs.
> V3: Split one patch to several patchs, each Pkg has one patch.
> V2: Change the new type from [PcdsDynamic] to [PcdsFixedAtBuild,
> PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
> And set to PcdsFixedAtBuild in the original platform .dsc files.
> 
>  MdeModulePkg/MdeModulePkg.dec| 13 +
>  .../StatusCodeHandler/Pei/StatusCodeHandlerPei.c |  6 +++---
>  .../Pei/StatusCodeHandlerPei.inf |  6 ++
>  .../RuntimeDxe/StatusCodeHandlerRuntimeDxe.c | 16 
>  .../RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf   |  6 ++
>  .../StatusCodeHandler/Smm/StatusCodeHandlerSmm.c | 10 +-
>  .../Smm/StatusCodeHandlerSmm.inf |  6 ++
>  7 files changed, 35 insertions(+), 28 deletions(-)
> 
> diff --git a/MdeModulePkg/MdeModulePkg.dec
> b/MdeModulePkg/MdeModulePkg.dec
> index 4f44af694862..bd369d1f230e 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -2001,6 +2001,19 @@ [PcdsFixedAtBuild, PcdsPatchableInModule,
> PcdsDynamic, PcdsDynamicEx]
># @Prompt TCG Platform Firmware Profile revision.
> 
> gEfiMdeModulePkgTokenSpaceGuid.PcdTcgPfpMeasurementRevision|0|UINT3
> 2|0x00010077
> 
> +  ## Indicates if StatusCode is reported via Serial port.
> +  #   TRUE  - Reports StatusCode via Serial port.
> +  #   FALSE - Does not report StatusCode via Serial port.
> +  # @Prompt Enable StatusCode via Serial port.
> +
> gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|TRUE|BOOLEAN|
> 0x00010022
> +
> +  ## Indicates if StatusCode is stored in memory.
> +  #  The memory is boot time memory in PEI Phase and is runtime memory in
> DXE Phase.
> +  #   TRUE  - Stores StatusCode in memory.
> +  #   FALSE - Does not store StatusCode in memory.
> +  # @Prompt Enable StatusCode via memory.
> +
> gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseMemory|FALSE|BOOLEA
> N|0x00010023
> +
>  [PcdsPatchableInModule]
>## Specify memory size with page number for PEI code when
>#  Loading Module at Fixed Address feature is enabled.
> diff --git
> a/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.c
> b/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.c
> index 1b07f92f3ce8..9b2ea4ee84d9 100644
> --- a/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.c
> +++
> b/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.c
> @@ -2,7 +2,7 @@
>Report Status Code Handler PEIM which produces general handlers and hook
> them
>onto the PEI status code router.
> 
> -  Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
> +  Copyright (c) 2009 - 2020, Intel Corporation. All rights reserved.
>SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> @@ -45,13 +45,13 @@ StatusCodeHandlerPeiEntry (
>// If enable UseSerial, then initialize serial port.
>// if enable UseMemory, then initialize memory status code worker.
>//
> -  if (FeaturePcdGet (PcdStatusCodeUseSerial)) {
> +  if (PcdGetBool (PcdStatusCodeUseSerial)) {
>  Status = SerialPortInitialize();
>  ASSERT_EFI_ERROR (Status);
>  Status = RscHandlerPpi->Register (SerialStatusCodeReportWorker);
>  ASSERT_EFI_ERROR (Status);
>}
> -  if (FeaturePcdGet (PcdStatusCodeUseMemory)) {
> +  if (PcdGetBool (PcdStatusCodeUseMemory)) {
>  Status = MemoryStatusCodeInitializeWorker ();
>  ASSERT_EFI_ERROR (Status);
>  Status = RscHandlerPpi->Register (MemoryStatusCodeReportWorker);
> diff --git
> a/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf
> b/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf
> index 8aef9af34a05..64380ddfaccc 100644
> ---
> a/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf
> +++
> b/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf
> @@ -53,11 +53,9 @@ [Guids]
>  [Ppis]
>gEfiPeiRscHandlerPpiGuid  ## CONSUMES
> 
> -[FeaturePcd]
> -  

Re: [edk2-devel] [PATCH] ArmPkg/PlatformBootManagerLib: regenerate boot options on boot failure

[Leif Lindholm]

On Wed, Jun 17, 2020 at 14:59:45 +0200, Ard Biesheuvel wrote:
> > > > Something like:
> > > > "On entry, the UiApp instantiates the autogenerated boot options that
> > > > we used to rely on - but it does not consume them. This breaks the
> > > > unattended..."
> > > 
> > > OK
> > > 
> > > > I assume the UiApp only ever *adds* entries, which is why checking
> > > > number of entries is sufficient?
> > > > 
> > > 
> > > It only manages entries that it instantiated itself, but it may also 
> > > remove
> > > entries if the underlying hardware has disappeared.
> > 
> > Hmm, that's a bit trickier then. I mean, it's unlikely, but I'm sure
> > there's situations that could happen.
> > Would we run the risk of getting bug reports like "system fails to
> > boot from Ethernet when inifiniband switch powered off"? Or if some
> > virtual devices presented by a BMC appear/disappear?
> > 
> 
> If the boot entries are not refreshed, you will retain the old ones. So the
> only way this could lead to a boot failure is when you rely on automatically
> generated boot entries to device that disappear and reappear in a different
> place, e.g., move a Ethernet PCIe card to a different slot. Note that USB
> devices plugged into a different port will still work fine, though, as they
> rely on the removable boot path in this case, which will be attempted anyway
> before doing the UnableToBoot().
> 
> Note that the failure mode here is being dropped into the menu, where before
> you were always dropped into the Shell. The case we are trying to address
> here is zero intervention network boot after putting the device into
> circulation, and that should work correctly with this change: if the network
> boot path did not exist before, it will be added, in which case the number
> of boot options will increase.

OK. I'm not convinced we're not going to see a report of this
somewhere down the line, but I think you've managed to convince me
it's an unlikely enough situation, and a fallback, that we can bump it
to then (and it *is* a behavioural improvement in all other cases).

Reviewed-by: Leif Lindholm 
(with the commit message update)

/
Leif

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

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

Re: [edk2-devel] [PATCH] OvmfPkg: End timer interrupt later to avoid stack overflow under load

[Paolo Bonzini]

On 16/06/20 20:42, Laszlo Ersek wrote:
> (Hmmm... maybe the hypervisor *has* to queue the timer interrupts,
> otherwise some of them would simply be lost, and the guest would lose
> track of time.)

Yes, there are various kinds of coalescing of interrupts that
hypervisors perform to help the guest keep track of time.  This is
especially true of the PIT and RTC; newer OSes track time directly from
the TSC, the HPET or the APIC timer so they tolerate lost ticks much better.

That said, Igor's patch seems correct to me.  In fact, I'd even move
DisableInterrupts before gBS->RestoreTPL unless there's a good reason
not to do so.

Paolo


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

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

Re: [edk2-devel] [PATCH] ArmPkg/PlatformBootManagerLib: regenerate boot options on boot failure

[Laszlo Ersek]

On 06/16/20 19:48, Ard Biesheuvel wrote:
> One of the side effects of the recent changes to PlatformBootManagerLib
> changes to avoid connecting all devices on every boot is that we no
> longer default to network boot on a virgin boot, but end up in the
> UiApp menu. At this point, the autogenerated boot options that we used
> to rely on will be instantiated too, but it does break the unattended
> boot case where devices are expected to attempt a network boot on the
> very first power on.
> 
> Let's work around this by refreshing all boot options explicitly in
> the UnableToBoot() handler, and rebooting the system if doing so
> resulted in a change to the total number of configured boot options.
> This way, we ultimately end up in the UiApp as before if no boot
> options could be started, but only after all the autogenerated ones
> have been attempted as well.
> 
> Cc: Pete Batard 
> Cc: Andrei Warkentin (awarken...@vmware.com) 
> Cc: Samer El-Haj-Mahmoud 
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c | 34 
>  1 file changed, 34 insertions(+)
> 
> diff --git a/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c 
> b/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
> index 15c5cac1bea0..9905cad22908 100644
> --- a/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
> +++ b/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
> @@ -820,6 +820,40 @@ PlatformBootManagerUnableToBoot (
>  {
>EFI_STATUS   Status;
>EFI_BOOT_MANAGER_LOAD_OPTION BootManagerMenu;
> +  EFI_BOOT_MANAGER_LOAD_OPTION *BootOptions;
> +  UINTNOldBootOptionCount;
> +  UINTNNewBootOptionCount;
> +
> +  //
> +  // Record the total number of boot configured boot options
> +  //
> +  BootOptions = EfiBootManagerGetLoadOptions (,
> +  LoadOptionTypeBoot);
> +  EfiBootManagerFreeLoadOptions (BootOptions, OldBootOptionCount);
> +
> +  //
> +  // Connect all devices, and regenerate all boot options
> +  //
> +  EfiBootManagerConnectAll ();
> +  EfiBootManagerRefreshAllBootOption ();
> +
> +  //
> +  // Record the updated number of boot configured boot options
> +  //
> +  BootOptions = EfiBootManagerGetLoadOptions (,
> +  LoadOptionTypeBoot);
> +  EfiBootManagerFreeLoadOptions (BootOptions, NewBootOptionCount);
> +
> +  //
> +  // If the number of configured boot options has changed, reboot
> +  // the system so the new boot options will be taken into account
> +  // while executing the ordinary BDS bootflow sequence.
> +  //
> +  if (NewBootOptionCount != OldBootOptionCount) {
> +DEBUG ((DEBUG_WARN, "%a: rebooting after refreshing all boot options\n",
> +  __FUNCTION__));
> +gRT->ResetSystem (EfiResetCold, EFI_SUCCESS, 0, NULL);
> +  }
>  
>Status = EfiBootManagerGetBootManagerMenu ();
>if (EFI_ERROR (Status)) {
> 

This looks like a very nice trick, and a very good utilization of the
PlatformBootManagerUnableToBoot() hook, for physical machines.

FWIW:

Acked-by: Laszlo Ersek 


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

View/Reply Online (#61415): https://edk2.groups.io/g/devel/message/61415
Mute This Topic: https://groups.io/mt/74921613/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 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Wang, Sunny (HPS SW)]

Thanks for checking my comments, Pete. 

> Or is the "one more" the issue, meaning that it would get signaled more than 
> once?
[Sunny] Yeah, it would get signaled more than once if the PlatformRecovery 
option (a UEFI application) calls EfiBootManagerBoot() to launch the recovered 
boot option inside of the application.  

> I don't mind trying an alternative approach, but I don't understand how what 
> you describe would help. Can you please be more specific about what you have 
> in mind?
[Sunny] Sure. I added more information below. If it is still not clear enough, 
feel free to let me know.
 1. Create a UEFI application with the code to signal ReadyToBoot and pick 
/efi/boot/bootaa64.efi from either SD or USB and run it.
 2. Then, call EfiBootManagerInitializeLoadOption like the following in a 
DXE driver or other places before "Default PlatformRecovery" registration:  
  Status = EfiBootManagerInitializeLoadOption (
 ,
 0, 
-> 0 is the OptionNumber to let application be load before " 
Default PlatformRecovery" option
 LoadOptionTypePlatformRecovery,
 LOAD_OPTION_ACTIVE,
 L"Application for recovering boot options",
 FilePath,  
  -> FilePath is the Application's device path,
 NULL,
 0
 );


> My reasoning is that, if PlatformRecovery can execute a regular 
> bootloader like /efi/boot/boot.efi from installation media, then it 
> should go through the same kind of initialization that happens for a regular 
> boot option, and that should include signaling the ReadyToBoot event. 
[Sunny] Thanks for clarifying this, and Sorry about that I missed your cover 
letter for this patch.  I was just thinking that we may not really need to make 
this behavior change in both EDK II code and UEFI specification for solving the 
problem specific to the case that OS is loaded by "Default PlatformRecovery" 
option, and I'm also not sure if it is worth making this change to affect some 
of the system or BIOS vendors who have implemented their PlatformRecovery 
option. If the alternative approach I mentioned works for you, I think that 
would be an easier solution.

Regards,
Sunny Wang

-Original Message-
From: Pete Batard [mailto:p...@akeo.ie] 
Sent: Wednesday, June 17, 2020 6:59 PM
To: Wang, Sunny (HPS SW) ; devel@edk2.groups.io
Cc: zhichao@intel.com; ray...@intel.com; ard.biesheu...@arm.com; 
l...@nuviainc.com
Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: 
Signal ReadyToBoot on platform recovery

Hi Sunny, thanks for looking into this.

On 2020.06.17 09:16, Wang, Sunny (HPS SW) wrote:
> Hi Pete.
> 
> Since the EfiBootManagerProcessLoadOption is called by ProcessLoadOptions as 
> well, your change would also cause some unexpected behavior like:
> 1. Signal one more ReadyToBoot for the PlatformRecovery option which is an 
> application that calls EfiBootManagerBoot() to launch its recovered boot 
> option.

I'm not sure I understand how this part is unwanted.

The point of this patch is to ensure that ReadyToBoot is signalled for the 
PlatformRecovery option, so isn't what you describe above exactly what we want?

Or is the "one more" the issue, meaning that it would get signalled more than 
once?


> 2. Signal ReadyToBoot for SysPrep or Driver that is not really a 
> "boot" option.

Yes, I've been wondering about that, because BdsEntry.c's ProcessLoadOptions(), 
which calls EfiBootManagerProcessLoadOption(),
mentions that it will load will load and start every Driver, SysPrep or 
PlatformRecovery. But the comment about the while() loop in 
EfiBootManagerProcessLoadOption() only mentions PlatformRecovery.

If needed, I guess we could amend the patch to detect the type of option and 
only signal ReadyToBoot for PlatformRecovery.

> To solve your problem, creating a PlatformRecovery option with the smallest 
> option number and using it instead of default one (with short-form File Path 
> Media Device Path) looks like a simpler solution.

I don't mind trying an alternative approach, but I don't understand how what 
you describe would help. Can you please be more specific about what you have in 
mind?

Our main issue here is that we must have ReadyToBoot signalled so that the 
ReadyToBoot() function callback from EmbeddedPkg/Drivers/ConsolePrefDxe gets 
executed in order for the boot loader invoked from PlatformRecovery  to use 
a properly initialized graphical console. So I'm not sure I quite get how 
switching from one PlatformRecovery option to another would improve things.

If it helps, here is what we currently default to, in terms of boot options, on 
a Raspberry Pi 4 platform with a newly build firmware:

[Bds]=Begin Load Options Dumping ...=
   Driver 

Re: [edk2-devel] [PATCH] ArmPkg/PlatformBootManagerLib: regenerate boot options on boot failure

[Ard Biesheuvel]

On 6/17/20 2:40 PM, Leif Lindholm wrote:

On Wed, Jun 17, 2020 at 14:28:04 +0200, Ard Biesheuvel wrote:

On 6/17/20 2:16 PM, Leif Lindholm wrote:

On Wed, Jun 17, 2020 at 13:32:36 +0200, Ard Biesheuvel wrote:

On 6/17/20 1:12 PM, Leif Lindholm wrote:

On Tue, Jun 16, 2020 at 19:48:34 +0200, Ard Biesheuvel wrote:

One of the side effects of the recent changes to PlatformBootManagerLib
changes to avoid connecting all devices on every boot is that we no
longer default to network boot on a virgin boot, but end up in the
UiApp menu. At this point, the autogenerated boot options that we used
to rely on will be instantiated too,


The passive voice is confusing me a bit here - who does the updating,
and when specifically?



Originally, the ArmPkg PlatformBmLib would always refresh all boot options,
but now, only the UiApp does that upon entry, at which point your sitting in
the menu idly, and so automated network boot no longer works.


Sure. But the message should contain some description of agency.

Something like:
"On entry, the UiApp instantiates the autogenerated boot options that
we used to rely on - but it does not consume them. This breaks the
unattended..."


OK


I assume the UiApp only ever *adds* entries, which is why checking
number of entries is sufficient?



It only manages entries that it instantiated itself, but it may also remove
entries if the underlying hardware has disappeared.


Hmm, that's a bit trickier then. I mean, it's unlikely, but I'm sure
there's situations that could happen.
Would we run the risk of getting bug reports like "system fails to
boot from Ethernet when inifiniband switch powered off"? Or if some
virtual devices presented by a BMC appear/disappear?



If the boot entries are not refreshed, you will retain the old ones. So 
the only way this could lead to a boot failure is when you rely on 
automatically generated boot entries to device that disappear and 
reappear in a different place, e.g., move a Ethernet PCIe card to a 
different slot. Note that USB devices plugged into a different port will 
still work fine, though, as they rely on the removable boot path in this 
case, which will be attempted anyway before doing the UnableToBoot().


Note that the failure mode here is being dropped into the menu, where 
before you were always dropped into the Shell. The case we are trying to 
address here is zero intervention network boot after putting the device 
into circulation, and that should work correctly with this change: if 
the network boot path did not exist before, it will be added, in which 
case the number of boot options will increase.




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

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

Re: [edk2-devel] [PATCH 5/5] UefiCpuPkg: Uninstall EFI_SMM_CONFIGURATION_PROTOCOL at end of Dxe.

[Laszlo Ersek]

On 06/17/20 07:30, Liu, Zhiguang wrote:
> Hi Laszlo,
> Thanks for the comments, I will take the first one.
> But I can't find service to unregister protocol notify in 
> EFI_SMM_SYSTEM_TABLE2.
> Do you now how the unregister it in SMM driver?

It's a bit hidden, but it is explained by the PI spec, under
MmRegisterProtocolNotify():

If Function == NULL and Registration is an existing registration,
then the callback is unhooked. *Protocol must be validated it with
*Registration. If Registration is not found then EFI_NOT_FOUND is
returned.

So where you do

  gSmst->SmmRegisterProtocolNotify (
   ,
   SmmEndOfDxeNotify,
   
   );

in PiCpuSmmEntry(), you'd have to save the registration value into a
global variable (which would live in SMRAM):

VOID *mEndOfDxeRegistration;

  gSmst->SmmRegisterProtocolNotify (
   ,
   SmmEndOfDxeNotify,
// <- here
   );

Then in SmmEndOfDxeNotify(), you could call

  Status = gSmst->SmmRegisterProtocolNotify (
,
NULL,

);
  ASSERT_EFI_ERROR (Status);

You can see examples in:
- MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
- MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.c
- MdePkg/Library/SmmIoLib/SmmIoLib.c
- MdePkg/Library/SmmMemLib/SmmMemLib.c

Thanks
Laszlo


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

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

Re: [edk2-devel] [PATCH] OvmfPkg: End timer interrupt later to avoid stack overflow under load

[Laszlo Ersek]

On 06/17/20 05:16, Igor Druzhinin wrote:
> On 16/06/2020 19:42, Laszlo Ersek wrote
>> If I understand correctly, TimerInterruptHandler()
>> [OvmfPkg/8254TimerDxe/Timer.c] currently does the following:
>>
>> - RaiseTPL (TPL_HIGH_LEVEL) --> mask interrupts from being delivered
>>
>> - mLegacy8259->EndOfInterrupt() --> permit the PIC to generate further
>> interrupts (= make them pending)
>>
>> - RestoreTPL() --> unmask interrupts (allow delivery)
>>
>> RestoreTPL() is always expected to invoke handlers (on its own stack)
>> that have just been unmasked, so that behavior is not unexpected, in my
>> opinion.
> 
> Yes, this is where I'd like to have a confirmation - opening a window
> for uncontrollable number of nested interrupts with a small stack
> looks dangerous.

Sorry, I meant the above more generally. The sentence

  RestoreTPL() is always expected to invoke handlers (on its own stack)
  that have just been unmasked

doesn't only refer to actual timer hardware interrupts (in connection to
TPL_HGIH_LEVEL), but also to invoking event notification functions that
have been queued while running at the raised TPL.

Quoting "EFI_BOOT_SERVICES.CreateEvent()" from the spec:

Events exist in one of two states, “waiting” or “signaled.” When an
event is created, firmware puts it in the “waiting” state. When the
event is signaled, firmware changes its state to “signaled” and, if
EVT_NOTIFY_SIGNAL is specified, places a call to its notification
function in a FIFO queue. There is a queue for each of the “basic”
task priority levels defined in Section 7.1 (TPL_CALLBACK, and
TPL_NOTIFY). The functions in these queues are invoked in FIFO
order, starting with the highest priority level queue and proceeding
to the lowest priority queue that is unmasked by the current TPL. If
the current TPL is equal to or greater than the queued notification,
it will wait until the TPL is lowered via
EFI_BOOT_SERVICES.RestoreTPL().

In practice, when the event is signaled, and the current TPL is not
masking the TPL of the associated notify function, then the notify
function is called internally to signaling the event. Otherwise, if the
unmasking occurs via RestoreTPL(), then the queued notification
functions are invoked on the stack of RestoreTPL() -- in other words,
internally to the RestoreTPL() function call itself.

So all I meant was that notification functions running internally to
RestoreTPL() was by design.

What's unexpected is the "uncontrollable number" of nested interrupts.

> 
>> What seems unexpected is the queueing of a huge number of timer
>> interrupts. I would think a timer interrupt is either pending or not
>> pending (i.e. if it's already pending, then the next generated interrupt
>> is coalesced, not queued). While there would still be a window between
>> the EOI and the unmasking, I don't think it would normally allow for a
>> *huge* number of queued interrupts (and consequently a stack overflow).
> 
> It's not a window between EOI and unmasking but the very fact vCPU is 
> descheduled for a considerable amount of time that causes backlog of
> timer interrupts to build up. This is Xen default behavior and is
> configurable (there are several timer modes including coalescing
> you mention). That is done for compatibility with some guests basing
> time accounting on the number of periodic interrupts they receive.

OK, thanks for explaining.

> 
>> So I basically see the root of the problem in the interrupts being
>> queued rather than coalesced. I'm pretty unfamiliar with this x86 area
>> (= the 8259 PIC in general), but the following wiki article seems to
>> agree with my suspicion:
>>
>> https://wiki.osdev.org/8259_PIC#How_does_the_8259_PIC_chip_work.3F
>>
>> [...] and whether there's an interrupt already pending. If the
>> channel is unmasked and there's no interrupt pending, the PIC will
>> raise the interrupt line [...]
>>
>> Can we say that the interrupt queueing (as opposed to coalescing) is a
>> Xen issue?
> 
> I can admit that the whole issue might be Xen specific if that form
> of timer mode is not used in QEMU-KVM. What mode is typical there
> then?

That question is too difficult for me to answer :(

> We might consider switching Xen to a different mode if so, as I believe
> those guests are not in support for many years.

Can you perhaps test this hypothesis? If you select the coalescing timer
mode for the Xen guest in question, does the symptom go away?

> 
>> (Hmmm... maybe the hypervisor *has* to queue the timer interrupts,
>> otherwise some of them would simply be lost, and the guest would lose
>> track of time.)
>>
>> Either way, I'm not sure what the best approach is. This driver was
>> moved under OvmfPkg from PcAtChipsetPkg in commit 1a3ffdff82e6
>> ("OvmfPkg: Copy 8254TimerDxe driver from PcAtChipsetPkg", 2019-04-11).
>> HpetTimerDxe also lives under PcAtChipsetPkg.
>>
>> So I think I'll have to rely on the expertise of Ray here (CC'd).
> 

Re: [edk2-devel] [PATCH] ArmPkg/PlatformBootManagerLib: regenerate boot options on boot failure

[Leif Lindholm]

On Wed, Jun 17, 2020 at 14:28:04 +0200, Ard Biesheuvel wrote:
> On 6/17/20 2:16 PM, Leif Lindholm wrote:
> > On Wed, Jun 17, 2020 at 13:32:36 +0200, Ard Biesheuvel wrote:
> > > On 6/17/20 1:12 PM, Leif Lindholm wrote:
> > > > On Tue, Jun 16, 2020 at 19:48:34 +0200, Ard Biesheuvel wrote:
> > > > > One of the side effects of the recent changes to 
> > > > > PlatformBootManagerLib
> > > > > changes to avoid connecting all devices on every boot is that we no
> > > > > longer default to network boot on a virgin boot, but end up in the
> > > > > UiApp menu. At this point, the autogenerated boot options that we used
> > > > > to rely on will be instantiated too,
> > > > 
> > > > The passive voice is confusing me a bit here - who does the updating,
> > > > and when specifically?
> > > > 
> > > 
> > > Originally, the ArmPkg PlatformBmLib would always refresh all boot 
> > > options,
> > > but now, only the UiApp does that upon entry, at which point your sitting 
> > > in
> > > the menu idly, and so automated network boot no longer works.
> > 
> > Sure. But the message should contain some description of agency.
> > 
> > Something like:
> > "On entry, the UiApp instantiates the autogenerated boot options that
> > we used to rely on - but it does not consume them. This breaks the
> > unattended..."
> 
> OK
> 
> > I assume the UiApp only ever *adds* entries, which is why checking
> > number of entries is sufficient?
> > 
> 
> It only manages entries that it instantiated itself, but it may also remove
> entries if the underlying hardware has disappeared.

Hmm, that's a bit trickier then. I mean, it's unlikely, but I'm sure
there's situations that could happen.
Would we run the risk of getting bug reports like "system fails to
boot from Ethernet when inifiniband switch powered off"? Or if some
virtual devices presented by a BMC appear/disappear?

/
Leif


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

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

Re: [edk2-devel] [PATCH edk2-platforms v2 0/3] Silicon/NXP: LX2160A: Add SerDes Support

[Leif Lindholm]

On Wed, Jun 17, 2020 at 00:31:43 +0530, Wasim Khan wrote:
> From: Wasim Khan 
> 
> NXP SoCs supports different Serdes protocols using reset
> configuration word (RCW). 
> Based on Serdes protocol value in reset configuration word (RCW)
> different IP blocks gets enabled in HW.
> 
> This patch add Serdes support for LX2160A, which has 3 Serdes.
> 
> Changes in V2:
> - Incorporate review comments to change SerDesConfigTable to STATIC
> - Incorporate similar changes for LS1043
> - Update Debug log in SerdesHelperLib
> 
> V1 series can be accessed from:
> https://edk2.groups.io/g/devel/message/61056

Thanks.
For the series:
Reviewed-by: Leif Lindholm 
Series pushed as 73efee74df87..04c870e67d11.

> Wasim Khan (3):
>   Silicon/NXP: LX2160A: Add SerDes Support
>   Silicon/NXP: LS1043A: Change SerDes ConfigTable to STATIC
>   Silicon/NXP: SerDesHelperLib: Correct DEBUG log
> 
>  Silicon/NXP/LX2160A/LX2160A.dsc.inc   |   2 +
>  Silicon/NXP/LX2160A/Library/SocLib/SocLib.inf |   6 +
>  Silicon/NXP/LX2160A/Include/SocSerDes.h   |  74 +++
>  Silicon/NXP/LS1043A/Library/SocLib/SerDes.c   |   4 +-
>  Silicon/NXP/LX2160A/Library/SocLib/SerDes.c   | 211 
> 
>  Silicon/NXP/Library/SerDesHelperLib/SerDesHelperLib.c |   2 +-
>  6 files changed, 296 insertions(+), 3 deletions(-)
>  create mode 100644 Silicon/NXP/LX2160A/Include/SocSerDes.h
>  create mode 100644 Silicon/NXP/LX2160A/Library/SocLib/SerDes.c
> 
> -- 
> 2.7.4
> 

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

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

Re: [edk2-devel] [PATCH] ArmPkg/PlatformBootManagerLib: regenerate boot options on boot failure

[Ard Biesheuvel]

On 6/17/20 2:16 PM, Leif Lindholm wrote:

On Wed, Jun 17, 2020 at 13:32:36 +0200, Ard Biesheuvel wrote:

On 6/17/20 1:12 PM, Leif Lindholm wrote:

On Tue, Jun 16, 2020 at 19:48:34 +0200, Ard Biesheuvel wrote:

One of the side effects of the recent changes to PlatformBootManagerLib
changes to avoid connecting all devices on every boot is that we no
longer default to network boot on a virgin boot, but end up in the
UiApp menu. At this point, the autogenerated boot options that we used
to rely on will be instantiated too,


The passive voice is confusing me a bit here - who does the updating,
and when specifically?



Originally, the ArmPkg PlatformBmLib would always refresh all boot options,
but now, only the UiApp does that upon entry, at which point your sitting in
the menu idly, and so automated network boot no longer works.


Sure. But the message should contain some description of agency.

Something like:
"On entry, the UiApp instantiates the autogenerated boot options that
we used to rely on - but it does not consume them. This breaks the
unattended..."



OK


I assume the UiApp only ever *adds* entries, which is why checking
number of entries is sufficient?



It only manages entries that it instantiated itself, but it may also 
remove entries if the underlying hardware has disappeared.



With that/if so:
Reviewed-by: Leif Lindholm 

/
 Leif




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

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

Re: [edk2-devel] [PATCH] ArmPkg/PlatformBootManagerLib: regenerate boot options on boot failure

[Leif Lindholm]

On Wed, Jun 17, 2020 at 13:32:36 +0200, Ard Biesheuvel wrote:
> On 6/17/20 1:12 PM, Leif Lindholm wrote:
> > On Tue, Jun 16, 2020 at 19:48:34 +0200, Ard Biesheuvel wrote:
> > > One of the side effects of the recent changes to PlatformBootManagerLib
> > > changes to avoid connecting all devices on every boot is that we no
> > > longer default to network boot on a virgin boot, but end up in the
> > > UiApp menu. At this point, the autogenerated boot options that we used
> > > to rely on will be instantiated too,
> > 
> > The passive voice is confusing me a bit here - who does the updating,
> > and when specifically?
> > 
> 
> Originally, the ArmPkg PlatformBmLib would always refresh all boot options,
> but now, only the UiApp does that upon entry, at which point your sitting in
> the menu idly, and so automated network boot no longer works.

Sure. But the message should contain some description of agency.

Something like:
"On entry, the UiApp instantiates the autogenerated boot options that
we used to rely on - but it does not consume them. This breaks the
unattended..."

I assume the UiApp only ever *adds* entries, which is why checking
number of entries is sufficient?

With that/if so:
Reviewed-by: Leif Lindholm 

/
Leif

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

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

Re: [edk2-devel] [PATCH edk2-platforms v3 3/4] Silicon/Hisilicon/Acpi: Add update sas address feature

[Leif Lindholm]

On Wed, Jun 17, 2020 at 19:23:47 +0800, Ming Huang wrote:
>  +  Status = gBS->LocateProtocol (, NULL, 
>  (VOID **));
>  +  if (EFI_ERROR (Status)) {
>  +DEBUG ((DEBUG_ERROR, "Locate Sas Config Protocol failed %r\n", 
>  Status));
>  +SasAddrBuffer[0] = 0x50;
>  +SasAddrBuffer[1] = 0x01;
>  +SasAddrBuffer[2] = 0x88;
>  +SasAddrBuffer[3] = 0x20;
>  +SasAddrBuffer[4] = 0x16;
>  +SasAddrBuffer[5] = 0x00;
>  +SasAddrBuffer[6] = 0x00;
>  +SasAddrBuffer[7] = Index;
> >>>
> >>> This is still a sompletely random-looking value being stuffed into the
> >>> buffer. What is it?
> >>
> >> This is a random value. Maybe it is more appropriate to stuff zero into the
> >> buffer here.
> > 
> > I think so.
> > Would you be happy for me to fold that in before pushing?
> 
> Yes.
> Thanks.

Done.
For the remaining patches:
Reviewed-by: Leif Lindholm 
Series pushed as 5f13ce8a65f2..73efee74df87.

/
Leif

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

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

Re: [edk2-devel] [PATCH edk2-platforms V2 0/2] Add SATA driver support

[Leif Lindholm]

On Tue, Jun 09, 2020 at 20:01:03 +0530, Meenakshi Aggarwal wrote:
> This patchset implement SATA driver for NXP Platforms enable
> SATA for LX2160A Platform.
> 
> Changes in v2:
>   - Incorporated review comments
>   - Removed header file and define macro in .c file

For this set:
Reviewed-by: Leif Lindholm 

*However*, this set does not apply cleanly without the "Add USB driver
 support" set, and that set has an outstanding question from Ard in
https://edk2.groups.io/g/devel/message/61211.

I'll leave it up to you whether we get that set merged first, or
whether you can rebase this one.

/
Leif

> Meenakshi Aggarwal (2):
>   Silicon/NXP: Add SATA controller initialization driver
>   Platform/NXP:LX2160: Enable support of SATA controller
> 
>  Silicon/NXP/NxpQoriqLs.dec  |   6 +
>  Silicon/NXP/LX2160A/LX2160A.dsc.inc |   5 +
>  Silicon/NXP/NxpQoriqLs.dsc.inc  |  10 ++
>  Platform/NXP/LX2160aRdbPkg/LX2160aRdbPkg.dsc|   2 +
>  Platform/NXP/LX2160aRdbPkg/LX2160aRdbPkg.fdf|  18 ++-
>  Silicon/NXP/Drivers/SataInitDxe/SataInitDxe.inf |  45 +++
>  Silicon/NXP/Drivers/SataInitDxe/SataInit.c  | 124 
>  7 files changed, 207 insertions(+), 3 deletions(-)
>  create mode 100644 Silicon/NXP/Drivers/SataInitDxe/SataInitDxe.inf
>  create mode 100644 Silicon/NXP/Drivers/SataInitDxe/SataInit.c
> 
> -- 
> 1.9.1
> 

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

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

Re: [edk2-devel] [PATCH] ArmPkg/PlatformBootManagerLib: regenerate boot options on boot failure

[Ard Biesheuvel]

On 6/17/20 1:12 PM, Leif Lindholm wrote:

On Tue, Jun 16, 2020 at 19:48:34 +0200, Ard Biesheuvel wrote:

One of the side effects of the recent changes to PlatformBootManagerLib
changes to avoid connecting all devices on every boot is that we no
longer default to network boot on a virgin boot, but end up in the
UiApp menu. At this point, the autogenerated boot options that we used
to rely on will be instantiated too,


The passive voice is confusing me a bit here - who does the updating,
and when specifically?



Originally, the ArmPkg PlatformBmLib would always refresh all boot 
options, but now, only the UiApp does that upon entry, at which point 
your sitting in the menu idly, and so automated network boot no longer 
works.





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

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

Re: [edk2-devel] [PATCH edk2-platforms v3 3/4] Silicon/Hisilicon/Acpi: Add update sas address feature

[Ming Huang]

在 2020/6/17 19:07, Leif Lindholm 写道:
> On Wed, Jun 17, 2020 at 10:07:39 +0800, Ming Huang wrote:
>>
>>
>> 在 2020/6/16 22:20, Leif Lindholm 写道:
>>> One remaining question, then this set is ready to go in:
>>>
>>> On Tue, Jun 09, 2020 at 21:27:24 +0800, Ming Huang wrote:
 The updating sas address feature is similar with apdating mac address.
 Modify updating dsdt flow for add this feature.

 Signed-off-by: Ming Huang 
 ---
  Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatform.c  |   2 +-
  Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatformDxe.inf |   1 +
  Silicon/Hisilicon/Drivers/AcpiPlatformDxe/EthMac.c| 292 
 +++-
  Silicon/Hisilicon/Drivers/AcpiPlatformDxe/EthMac.h|   2 +-
  4 files changed, 227 insertions(+), 70 deletions(-)

 diff --git a/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatform.c 
 b/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatform.c
 index c45a0bb..9cdf710 100644
 --- a/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatform.c
 +++ b/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatform.c
 @@ -46,7 +46,7 @@ UpdateAcpiDsdt (
  return;
}

 -  Status = EthMacInit ();
 +  Status = UpdateAcpiDsdtTable ();
if (EFI_ERROR (Status)) {
  DEBUG ((DEBUG_ERROR, " UpdateAcpiDsdtTable Failed, Status = %r\n", 
 Status));
}
 diff --git a/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatformDxe.inf 
 b/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatformDxe.inf
 index 866ff75..856309a 100644
 --- a/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatformDxe.inf
 +++ b/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatformDxe.inf
 @@ -46,6 +46,7 @@
gEfiAcpiTableProtocolGuid # PROTOCOL ALWAYS_CONSUMED
gEfiAcpiSdtProtocolGuid   # PROTOCOL ALWAYS_CONSUMED
gHisiBoardNicProtocolGuid   # PROTOCOL 
 ALWAYS_CONSUMED
 +  gHisiSasConfigProtocolGuid

  [FeaturePcd]
gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol
 diff --git a/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/EthMac.c 
 b/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/EthMac.c
 index cd98506..841c94e 100644
 --- a/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/EthMac.c
 +++ b/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/EthMac.c
 @@ -1,7 +1,7 @@
  /** @file

Copyright (c) 2014, Applied Micro Curcuit Corporation. All rights 
 reserved.
 -  Copyright (c) 2015, Hisilicon Limited. All rights reserved.
 +  Copyright (c) 2015 - 2020, Hisilicon Limited. All rights reserved.
Copyright (c) 2015, Linaro Limited. All rights reserved.
SPDX-License-Identifier: BSD-2-Clause-Patent

 @@ -23,6 +23,7 @@
  #include 
  #include 
  #include 
 +#include 
  #include 
  #include 
  #include 
 @@ -32,6 +33,7 @@
  #include 

  #include 
 +#include 

  // Turn on debug message by enabling below define
  //#define ACPI_DEBUG
 @@ -45,17 +47,27 @@
  #define EFI_ACPI_MAX_NUM_TABLES 20
  #define DSDT_SIGNATURE  0x54445344

 -#define D03_ACPI_ETH_ID "HISI00C2"
 -
  #define ACPI_ETH_MAC_KEY"local-mac-address"
 +#define ACPI_ETH_SAS_KEY"sas-addr"

  #define PREFIX_VARIABLE_NAMEL"MAC"
  #define PREFIX_VARIABLE_NAME_COMPAT L"RGMII_MAC"
 -#define MAC_MAX_LEN 30
 +#define ADDRESS_MAX_LEN 30
 +
 +CHAR8 *mHisiAcpiDevId[] = {"HISI00C1","HISI00C2","HISI0162"};
 +
 +typedef enum {
 +  DsdtDeviceUnknown,
 +  DsdtDeviceLan,
 +  DsdtDeviceSas
 +} DSDT_DEVICE_TYPE;

 -EFI_STATUS GetEnvMac(
 -  IN  UINTNMacNextID,
 -  IN OUT  UINT8*MacBuffer)
 +STATIC
 +EFI_STATUS
 +GetEnvMac(
 +  IN UINTNMacNextID,
 +  IN OUT UINT8*MacBuffer
 +  )
  {
EFI_MAC_ADDRESS Mac;
EFI_STATUS Status;
 @@ -89,12 +101,121 @@ EFI_STATUS GetEnvMac(
return EFI_SUCCESS;
  }

 -EFI_STATUS _SearchReplacePackageMACAddress(
 +STATIC
 +EFI_STATUS
 +GetSasAddress (
 +  IN UINT8Index,
 +  IN OUT UINT8*SasAddrBuffer
 +  )
 +{
 +  EFI_STATUS Status;
 +  HISI_SAS_CONFIG_PROTOCOL *HisiSasConf;
 +
 +  if (SasAddrBuffer == NULL) {
 +return EFI_INVALID_PARAMETER;
 +  }
 +
 +  Status = gBS->LocateProtocol (, NULL, (VOID 
 **));
 +  if (EFI_ERROR (Status)) {
 +DEBUG ((DEBUG_ERROR, "Locate Sas Config Protocol failed %r\n", 
 Status));
 +SasAddrBuffer[0] = 0x50;
 +SasAddrBuffer[1] = 0x01;
 +SasAddrBuffer[2] = 0x88;
 +SasAddrBuffer[3] = 0x20;
 +

Re: [edk2-devel] [PATCH] ArmPkg/PlatformBootManagerLib: regenerate boot options on boot failure

[Leif Lindholm]

On Tue, Jun 16, 2020 at 19:48:34 +0200, Ard Biesheuvel wrote:
> One of the side effects of the recent changes to PlatformBootManagerLib
> changes to avoid connecting all devices on every boot is that we no
> longer default to network boot on a virgin boot, but end up in the
> UiApp menu. At this point, the autogenerated boot options that we used
> to rely on will be instantiated too,

The passive voice is confusing me a bit here - who does the updating,
and when specifically?

/
Leif

> but it does break the unattended
> boot case where devices are expected to attempt a network boot on the
> very first power on.
> 
> Let's work around this by refreshing all boot options explicitly in
> the UnableToBoot() handler, and rebooting the system if doing so
> resulted in a change to the total number of configured boot options.
> This way, we ultimately end up in the UiApp as before if no boot
> options could be started, but only after all the autogenerated ones
> have been attempted as well.
> 
> Cc: Pete Batard 
> Cc: Andrei Warkentin (awarken...@vmware.com) 
> Cc: Samer El-Haj-Mahmoud 
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c | 34 
>  1 file changed, 34 insertions(+)
> 
> diff --git a/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c 
> b/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
> index 15c5cac1bea0..9905cad22908 100644
> --- a/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
> +++ b/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
> @@ -820,6 +820,40 @@ PlatformBootManagerUnableToBoot (
>  {
>EFI_STATUS   Status;
>EFI_BOOT_MANAGER_LOAD_OPTION BootManagerMenu;
> +  EFI_BOOT_MANAGER_LOAD_OPTION *BootOptions;
> +  UINTNOldBootOptionCount;
> +  UINTNNewBootOptionCount;
> +
> +  //
> +  // Record the total number of boot configured boot options
> +  //
> +  BootOptions = EfiBootManagerGetLoadOptions (,
> +  LoadOptionTypeBoot);
> +  EfiBootManagerFreeLoadOptions (BootOptions, OldBootOptionCount);
> +
> +  //
> +  // Connect all devices, and regenerate all boot options
> +  //
> +  EfiBootManagerConnectAll ();
> +  EfiBootManagerRefreshAllBootOption ();
> +
> +  //
> +  // Record the updated number of boot configured boot options
> +  //
> +  BootOptions = EfiBootManagerGetLoadOptions (,
> +  LoadOptionTypeBoot);
> +  EfiBootManagerFreeLoadOptions (BootOptions, NewBootOptionCount);
> +
> +  //
> +  // If the number of configured boot options has changed, reboot
> +  // the system so the new boot options will be taken into account
> +  // while executing the ordinary BDS bootflow sequence.
> +  //
> +  if (NewBootOptionCount != OldBootOptionCount) {
> +DEBUG ((DEBUG_WARN, "%a: rebooting after refreshing all boot options\n",
> +  __FUNCTION__));
> +gRT->ResetSystem (EfiResetCold, EFI_SUCCESS, 0, NULL);
> +  }
>  
>Status = EfiBootManagerGetBootManagerMenu ();
>if (EFI_ERROR (Status)) {
> -- 
> 2.27.0
> 

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

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

Re: [edk2-devel] [PATCH edk2-platforms v3 3/4] Silicon/Hisilicon/Acpi: Add update sas address feature

[Leif Lindholm]

On Wed, Jun 17, 2020 at 10:07:39 +0800, Ming Huang wrote:
> 
> 
> 在 2020/6/16 22:20, Leif Lindholm 写道:
> > One remaining question, then this set is ready to go in:
> > 
> > On Tue, Jun 09, 2020 at 21:27:24 +0800, Ming Huang wrote:
> >> The updating sas address feature is similar with apdating mac address.
> >> Modify updating dsdt flow for add this feature.
> >>
> >> Signed-off-by: Ming Huang 
> >> ---
> >>  Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatform.c  |   2 +-
> >>  Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatformDxe.inf |   1 +
> >>  Silicon/Hisilicon/Drivers/AcpiPlatformDxe/EthMac.c| 292 
> >> +++-
> >>  Silicon/Hisilicon/Drivers/AcpiPlatformDxe/EthMac.h|   2 +-
> >>  4 files changed, 227 insertions(+), 70 deletions(-)
> >>
> >> diff --git a/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatform.c 
> >> b/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatform.c
> >> index c45a0bb..9cdf710 100644
> >> --- a/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatform.c
> >> +++ b/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatform.c
> >> @@ -46,7 +46,7 @@ UpdateAcpiDsdt (
> >>  return;
> >>}
> >>  
> >> -  Status = EthMacInit ();
> >> +  Status = UpdateAcpiDsdtTable ();
> >>if (EFI_ERROR (Status)) {
> >>  DEBUG ((DEBUG_ERROR, " UpdateAcpiDsdtTable Failed, Status = %r\n", 
> >> Status));
> >>}
> >> diff --git a/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatformDxe.inf 
> >> b/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatformDxe.inf
> >> index 866ff75..856309a 100644
> >> --- a/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatformDxe.inf
> >> +++ b/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatformDxe.inf
> >> @@ -46,6 +46,7 @@
> >>gEfiAcpiTableProtocolGuid # PROTOCOL ALWAYS_CONSUMED
> >>gEfiAcpiSdtProtocolGuid   # PROTOCOL ALWAYS_CONSUMED
> >>gHisiBoardNicProtocolGuid   # PROTOCOL 
> >> ALWAYS_CONSUMED
> >> +  gHisiSasConfigProtocolGuid
> >>  
> >>  [FeaturePcd]
> >>gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol
> >> diff --git a/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/EthMac.c 
> >> b/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/EthMac.c
> >> index cd98506..841c94e 100644
> >> --- a/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/EthMac.c
> >> +++ b/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/EthMac.c
> >> @@ -1,7 +1,7 @@
> >>  /** @file
> >>  
> >>Copyright (c) 2014, Applied Micro Curcuit Corporation. All rights 
> >> reserved.
> >> -  Copyright (c) 2015, Hisilicon Limited. All rights reserved.
> >> +  Copyright (c) 2015 - 2020, Hisilicon Limited. All rights reserved.
> >>Copyright (c) 2015, Linaro Limited. All rights reserved.
> >>SPDX-License-Identifier: BSD-2-Clause-Patent
> >>  
> >> @@ -23,6 +23,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >> @@ -32,6 +33,7 @@
> >>  #include 
> >>  
> >>  #include 
> >> +#include 
> >>  
> >>  // Turn on debug message by enabling below define
> >>  //#define ACPI_DEBUG
> >> @@ -45,17 +47,27 @@
> >>  #define EFI_ACPI_MAX_NUM_TABLES 20
> >>  #define DSDT_SIGNATURE  0x54445344
> >>  
> >> -#define D03_ACPI_ETH_ID "HISI00C2"
> >> -
> >>  #define ACPI_ETH_MAC_KEY"local-mac-address"
> >> +#define ACPI_ETH_SAS_KEY"sas-addr"
> >>  
> >>  #define PREFIX_VARIABLE_NAMEL"MAC"
> >>  #define PREFIX_VARIABLE_NAME_COMPAT L"RGMII_MAC"
> >> -#define MAC_MAX_LEN 30
> >> +#define ADDRESS_MAX_LEN 30
> >> +
> >> +CHAR8 *mHisiAcpiDevId[] = {"HISI00C1","HISI00C2","HISI0162"};
> >> +
> >> +typedef enum {
> >> +  DsdtDeviceUnknown,
> >> +  DsdtDeviceLan,
> >> +  DsdtDeviceSas
> >> +} DSDT_DEVICE_TYPE;
> >>  
> >> -EFI_STATUS GetEnvMac(
> >> -  IN  UINTNMacNextID,
> >> -  IN OUT  UINT8*MacBuffer)
> >> +STATIC
> >> +EFI_STATUS
> >> +GetEnvMac(
> >> +  IN UINTNMacNextID,
> >> +  IN OUT UINT8*MacBuffer
> >> +  )
> >>  {
> >>EFI_MAC_ADDRESS Mac;
> >>EFI_STATUS Status;
> >> @@ -89,12 +101,121 @@ EFI_STATUS GetEnvMac(
> >>return EFI_SUCCESS;
> >>  }
> >>  
> >> -EFI_STATUS _SearchReplacePackageMACAddress(
> >> +STATIC
> >> +EFI_STATUS
> >> +GetSasAddress (
> >> +  IN UINT8Index,
> >> +  IN OUT UINT8*SasAddrBuffer
> >> +  )
> >> +{
> >> +  EFI_STATUS Status;
> >> +  HISI_SAS_CONFIG_PROTOCOL *HisiSasConf;
> >> +
> >> +  if (SasAddrBuffer == NULL) {
> >> +return EFI_INVALID_PARAMETER;
> >> +  }
> >> +
> >> +  Status = gBS->LocateProtocol (, NULL, (VOID 
> >> **));
> >> +  if (EFI_ERROR (Status)) {
> >> +DEBUG ((DEBUG_ERROR, "Locate Sas Config Protocol failed %r\n", 
> >> Status));
> >> +SasAddrBuffer[0] = 0x50;
> >> +SasAddrBuffer[1] = 0x01;
> >> +SasAddrBuffer[2] = 0x88;
> >> +SasAddrBuffer[3] = 0x20;
> >> +SasAddrBuffer[4] = 0x16;
> 

Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Pete Batard]

Hi Sunny, thanks for looking into this.

On 2020.06.17 09:16, Wang, Sunny (HPS SW) wrote:

Hi Pete.

Since the EfiBootManagerProcessLoadOption is called by ProcessLoadOptions as 
well, your change would also cause some unexpected behavior like:
1. Signal one more ReadyToBoot for the PlatformRecovery option which is an 
application that calls EfiBootManagerBoot() to launch its recovered boot option.


I'm not sure I understand how this part is unwanted.

The point of this patch is to ensure that ReadyToBoot is signalled for 
the PlatformRecovery option, so isn't what you describe above exactly 
what we want?


Or is the "one more" the issue, meaning that it would get signalled more 
than once?



2. Signal ReadyToBoot for SysPrep or Driver that is not really a "boot" 
option.


Yes, I've been wondering about that, because BdsEntry.c's 
ProcessLoadOptions(), which calls EfiBootManagerProcessLoadOption(), 
mentions that it will load will load and start every Driver, 
SysPrep or PlatformRecovery. But the comment about the while() 
loop in EfiBootManagerProcessLoadOption() only mentions 
PlatformRecovery.


If needed, I guess we could amend the patch to detect the type of option 
and only signal ReadyToBoot for PlatformRecovery.



To solve your problem, creating a PlatformRecovery option with the smallest 
option number and using it instead of default one (with short-form File Path 
Media Device Path) looks like a simpler solution.


I don't mind trying an alternative approach, but I don't understand how 
what you describe would help. Can you please be more specific about what 
you have in mind?


Our main issue here is that we must have ReadyToBoot signalled so that 
the ReadyToBoot() function callback from 
EmbeddedPkg/Drivers/ConsolePrefDxe gets executed in order for the boot 
loader invoked from PlatformRecovery  to use a properly initialized 
graphical console. So I'm not sure I quite get how switching from one 
PlatformRecovery option to another would improve things.


If it helps, here is what we currently default to, in terms of boot 
options, on a Raspberry Pi 4 platform with a newly build firmware:


[Bds]=Begin Load Options Dumping ...=
  Driver Options:
  SysPrep Options:
  Boot Options:
Boot: UiApp  0x0109
Boot0001: UEFI Shell 0x
  PlatformRecovery Options:
PlatformRecovery: Default PlatformRecovery   0x0001
[Bds]=End Load Options Dumping=

With this, PlatformRecovery gets executed by default, which is what 
we want, since it will pick /efi/boot/bootaa64.efi from either SD or USB 
and run it, the only issue being that, because ReadyToBoot has not been 
executed, the graphical console is not operative so users can't interact 
with the OS installer.


So I'm really not sure how adding an extra PlatformRecovery would 
help. And I'm also not too familiar with how one would go around to add 
such an entry...



By the way, I also checked the UEFI specification. It looks making sense to 
only signal ReadyToBoot for boot option (Boot).


That's something I considered too, but I disagree with this conclusion.

My reasoning is that, if PlatformRecovery can execute a regular 
bootloader like /efi/boot/boot.efi from installation media, then it 
should go through the same kind of initialization that happens for a 
regular boot option, and that should include signalling the ReadyToBoot 
event.


If there was a special bootloader for PlatformRecovery (e.g. 
/efi/boot/recovery.efi) then I would agree with only signalling 
ReadyToBoot for a formal Boot option. But that isn't the case, so I 
think it is reasonable to want to have ReadyToBoot also occur when a 
/efi/boot/boot.efi bootloader is executed from 
PlatformRecovery., especially when we know it can be crucial to 
ensuring that the end user can actually use the graphical console.



Therefore, your change may also require specification change.


Yes, I mentioned that in the cover letter for this patch 
(https://edk2.groups.io/g/devel/message/61327), which also describes the 
issue we are trying to solve in greater details. This is what I wrote:



Note however that this may require a specs update, as the current UEFI
specs for EFI_BOOT_SERVICES.CreateEventEx() have:

>  EFI_EVENT_GROUP_READY_TO_BOOT
>This event group is notified by the system when the Boot Manager
>is about to load and execute a boot option.

and, once this patch has been applied, we may want to update this
section to mention that it applies to both Boot Manager and Platform
Recovery.



Again, I don't have an issue with trying to use an alternate approach to 
solve our problem (though I ultimately believe that, if 
PlatformRecovery can launch a 

Re: [edk2-devel] [RFC PATCH 1/1] OvmfPkg: Introduce LSI 53C895A SCSI Controller Driver

[Laszlo Ersek]

On 06/17/20 04:09, Gary Lin wrote:
> On Mon, Jun 15, 2020 at 01:27:22PM +0200, Laszlo Ersek wrote:
>> Hello Gary,
>>
> Hi Laszlo,
> 
>> On 06/12/20 12:04, Gary Lin wrote:
>>> This commit introduces the driver for LSI 53C895A SCSI Controller
>>> which, so that OVMF can access the devices attached to the emulated
>>> "lsi" SCSI controller.
>>>
>>> Cc: Jordan Justen 
>>> Cc: Laszlo Ersek 
>>> Cc: Ard Biesheuvel 
>>> Signed-off-by: Gary Lin 
>>> ---
>>> Although lsi is now considered obsolete in QEMU, I wrote this driver
>>> mainly for learning the UEFI SCSI driver and ... FUN! The majority of
>>> the code is actually borrowed from VirtioScsci and MptScsi, and I
>>> mainly focus on LsiScsiPassThru().
>>>
>>> If it's fine to add this driver into OvmfPkg, I'll start to split this
>>> patch into smaller pieces to make it easier to review.
>>
>> (1) Do we have an official deprecation notice for this SCSI controller
>> in QEMU?
>>
>> If we do, then (AIUI) the controller will be removed in QEMU in one or
>> two releases, so this code would become effectively dead in the mid
>> term. I wouldn't like to review and/or carry code that's soon to be
>> dead.
>>
> I just vaguely remember that virtio-scsi is the new default over lsi and
> it's not recommended to use lsi except for the old OS without virtio-scsi
> driver.

So the question is then whether the old OS that supports LSI but not
virtio-scsi is capable of booting on UEFI in the first place.

> 
>> (2) If there is no official deprecation notice in QEMU, then I agree it
>> makes sense to include this driver. In that case, I have another
>> question:
>>
>> Do you intend this driver for production purposes? I.e., do you expect
>> users or "layered products" (libvirt, proxmox, openstack, ...) to use
>> this SCSI controller for some well-defined purpose? (The MPT SCSI and PV
>> SCSI drivers had a clear product-oriented modivation:
>>
>>   https://edk2.groups.io/g/devel/message/55620
>>   http://mid.mail-archive.com/a96b6b74-c35d-e291-2122-9d77f1d5f89c@oracle.com
>> )
>>
>> (2a) If this driver is not meant for a production environment, then
>> LSI_SCSI_ENABLE should be FALSE by default (and I'll do a lighter
>> review).
>>
>> (2b) If the driver is meant for production, then LSI_SCSI_ENABLE should
>> indeed be TRUE, and I'll have to be more diligent in reviewing this.
>>
> I kind of wonder if the any serious use for lsi+ovmf. If the OS is so
> old and only supports lsi, seabios probably serves it better.

Right, my point exactly!

> Anyway,
> I'll try to gather more information from my colleagues to see if they
> got any feedback about lsi from our customers. If not, I'll set
> LSI_SCSI_ENABLE to FALSE by default.

Sounds like a good approach!

> 
>> For either (2a) or (2b), please do split up the driver into smaller
>> patches, and please also add yourself to Maintainers.txt as the
>> designated reviewer of the new driver.
>>
> Sure. Will do that.

Thanks!
Laszlo


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

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

Re: [edk2-devel] [PATCH] UefiCpuPkg: Add New Memory Attributes

[Laszlo Ersek]

On 06/16/20 20:59, Oleksiy Yakovlev wrote:
> Hi Laszlo.
> 
> There was separate patch for MdeModulePkg submitted with this one as well. I 
> did not include you into cc, because you are not in the maintainers list for 
> MdeModulePkg. Patch addresses EFI_MEMORY_(RO|RP|XP) macroses and all issues 
> you mentioned in your comment in same way as UefiCpuPkg patch (without 
> introducing single macros and using MEMORY_ATTRIBUTE_MASK instead of | ).

But MdeModulePkg and UefiCpuPkg still do not share a common macro or Fixed-PCD 
for the mask, correct?

I think they should. UefiCpuPkg is allowed to consume MdeModulePkg content. And 
both are allowed to consume MdePkg content.

--*--

*Even if* we're staying strictly within UefiCpuPkg, the following macros are 
duplicated:

- "UefiCpuPkg/CpuDxe/CpuDxe.h":

#define EFI_MEMORY_PAGETYPE_MASK  (EFI_MEMORY_RP  | \
   EFI_MEMORY_XP  | \
   EFI_MEMORY_RO\
   )

- "UefiCpuPkg/CpuDxe/CpuDxe.c":

#define MEMORY_ATTRIBUTE_MASK  (EFI_MEMORY_RP | EFI_MEMORY_XP | EFI_MEMORY_RO)


They should be united, and the existent UefiCpuPkg code should adopt the new 
common macro ("CpuPageTable.c", "SmmCpuMemoryManagement.c").

Afterwards, the now-common macro should be extended with the new bits, in a 
separate patch.

Thanks
Laszlo



> 
> Regards, Oleksiy.
> 
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com] 
> Sent: Tuesday, June 16, 2020 2:12 PM
> To: Oleksiy Yakovlev; devel@edk2.groups.io
> Cc: eric.d...@intel.com; ray...@intel.com; rahul1.ku...@intel.com; Felix 
> Polyudov; Liming Gao; Michael Kinney; Jian J Wang; Hao A Wu; Dandan Bi
> Subject: Re: [PATCH] UefiCpuPkg: Add New Memory Attributes
> 
> Hi Oleksiy,
> 
> On 06/15/20 23:45, Oleksiy Yakovlev wrote:
>> Add usage of EFI_MEMORY_SP and EFI_MEMORY_CPU_CRYPTO
>> attributes introduced in UEFI 2.8
>> (UEFI 2.8, mantis 1919 and 1872)
>>
>> Signed-off-by: Oleksiy Yakovlev 
>> ---
>>  UefiCpuPkg/CpuDxe/CpuDxe.c | 2 +-
>>  UefiCpuPkg/CpuDxe/CpuDxe.h | 4 +++-
>>  UefiCpuPkg/CpuDxe/CpuPageTable.c   | 2 +-
>>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c | 2 +-
>>  4 files changed, 6 insertions(+), 4 deletions(-)
> 
> I suggest / request turning this patch into 5 patches:
> 
> 
> (a) The first patch should please correct a mistake in commit
> c18708d2f002 ("MdePkg-UefiSpec.h: Add UEFI 2.8 new memory attributes",
> 2019-11-04).
> 
> Namely, in commit c18708d2f002, the EFI_MEMORY_CPU_CRYPTO macro's
> documentation includes the string "CPU?s", twice, in place of "CPU's".
> 
> I don't understand how this happened. In the mailing list archive, I can
> only find Liming's confirmation that he pushed the patch:
> 
>   https://edk2.groups.io/g/devel/message/49893
> 
> but not the original patch posting.
> 
> Note that, in the context quoted in that message (that is, the patch),
> the string was "CPU’s". That string did not use ASCII character 0x27,
> but U+2019 (RIGHT SINGLE QUOTATION MARK). So indeed the patch was
> incorrect. But the solution should not have been to replace U+2019 with
> "?", but to request a repost using ASCII 0x27.
> 
> Either way, even though it is obviously not your mistake, can you please
> include a patch for replacing both "CPU?s" instances with "CPU's"? In
> file "MdePkg/Include/Uefi/UefiSpec.h".
> 
> 
> For the rest of the patches, please consider:
> 
> $ git grep -E 'EFI_MEMORY_(RO|RP|XP) \| EFI_MEMORY_(RO|RP|XP) \| 
> EFI_MEMORY_(RO|RP|XP)'
> 
> MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c:#define MEMORY_ATTRIBUTE_MASK  
> (EFI_MEMORY_RP | EFI_MEMORY_XP | EFI_MEMORY_RO)
> MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c:#define MEMORY_PAGE_ATTRIBUTES  
> (EFI_MEMORY_XP | EFI_MEMORY_RP | EFI_MEMORY_RO)
> UefiCpuPkg/CpuDxe/CpuDxe.c:#define MEMORY_ATTRIBUTE_MASK  (EFI_MEMORY_RP | 
> EFI_MEMORY_XP | EFI_MEMORY_RO)
> UefiCpuPkg/CpuDxe/CpuPageTable.c:  if ((Attributes & ~(EFI_MEMORY_RP | 
> EFI_MEMORY_RO | EFI_MEMORY_XP)) != 0) {
> UefiCpuPkg/CpuDxe/CpuPageTable.c:Capabilities = EFI_MEMORY_RO | 
> EFI_MEMORY_RP | EFI_MEMORY_XP;
> UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c:  ASSERT ((Attributes & 
> ~(EFI_MEMORY_RP | EFI_MEMORY_RO | EFI_MEMORY_XP)) == 0);
> 
> This output tells us the following:
> 
> - the bitmask (RP|XP|RO) is *triplicated* between the macro
>   definitions in:
> 
>   - MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
>   - MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
>   - UefiCpuPkg/CpuDxe/CpuDxe.c
> 
> - "UefiCpuPkg/CpuDxe/CpuPageTable.c" open-codes the bitmask in two
>   separate spots (rather than using MEMORY_ATTRIBUTE_MASK)
> 
> - "UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c" open codes the
>   bitmask also (rather than using any macro).
> 
> (b) Therefore, the second patch should introduce a central macro for
> (RP|XP|RO) somewhere under MdePkg or MdeModulePkg. Perhaps it can even
> be a 

[edk2-devel] [PATCH] Features/Intel/Readme.md: clarify feature package dependency rule

[Ni, Ray]

From: Ray Ni 

Original statement only says depending on another feature package
is not allowed. It gives developers impression that board level
packages are allowed to depend on.

This patch clarifies the package dependency rule.

Signed-off-by: Ray Ni 
Cc: Eric Dong 
Cc: Amy Chan 
Cc: Rangasai V Chaganty 
Cc: Isaac W Oram 
---
 Features/Intel/Readme.md | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Features/Intel/Readme.md b/Features/Intel/Readme.md
index 9729f90a41..1a03a4c0d2 100644
--- a/Features/Intel/Readme.md
+++ b/Features/Intel/Readme.md
@@ -17,8 +17,10 @@ document as needed.
 ### Advanced Feature Attributes
 Advanced features should be:
 * _Cohesive_, the feature should not contain any functionality unrelated to 
the feature.
-* _Complete_, the feature must have a complete design that minimizes 
dependencies. A feature package cannot directly
-  depend on another feature package.
+* _Complete_, the feature must have a complete design that minimizes 
dependencies. A feature package can only depend
+  on following packages:
+  * edk2 repo: `MdePkg`, `MdeModulePkg`, `UefiCpuPkg`, `FmpDevicePkg`, 
`SecurityPkg`, `NetworkPkg`, `ShellPkg`.
+  * edk2-platforms repo: `MinPlatformPkg`, `IntelSiliconPkg`.
 * _Easy to Integrate_, the feature should expose well-defined software 
interfaces to use and configure the feature.
   * It should also present a set of simple and well-documented standard EDK II 
configuration options such as PCDs to
   configure the feature.
-- 
2.25.1


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

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

[edk2-devel] [PATCH] [edk2-staging]BaseTools/Fmmt: fix Some RAW encounter dead loop issue

[Feng, YunhuaX]

Some RAW ffs parse section for check UI section will encounter dead loop.
Actually when FFS is raw FFS, not include UI section.

Change-Id: I40e1cbb988bed30d8757008bad9074bc11eae135
Cc: Bob Feng 
Cc: Liming Gao 
Signed-off-by: Yunhua Feng 
---
 BaseTools/Source/C/FMMT/FirmwareModuleManagement.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/BaseTools/Source/C/FMMT/FirmwareModuleManagement.c 
b/BaseTools/Source/C/FMMT/FirmwareModuleManagement.c
index 89a7533deb..c8a53d3def 100644
--- a/BaseTools/Source/C/FMMT/FirmwareModuleManagement.c
+++ b/BaseTools/Source/C/FMMT/FirmwareModuleManagement.c
@@ -1,10 +1,10 @@
 /** @file

  FMMT main routine.

-Copyright (c) 2019, Intel Corporation. All rights reserved.
+Copyright (c) 2019 - 2020, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent

 **/

 #include "FirmwareModuleManagement.h"
@@ -750,10 +750,16 @@ ParseSection (
   UISectionFlag   = FALSE;
   Ptr = NULL;
   SectionLength   = 0;
   ParsedLength= GetFfsHeaderLength((EFI_FFS_FILE_HEADER *)InputFfs);
   FfsFileSize = GetFfsFileLength((EFI_FFS_FILE_HEADER *)InputFfs);
+  //
+  //if RAW ffs, return FALSE
+  //
+  if (((EFI_FFS_FILE_HEADER*)InputFfs)->Type == EFI_FV_FILETYPE_RAW) {
+return UISectionFlag;
+  }

   while (ParsedLength < FfsFileSize) {
 Ptr   = (UINT8 *)InputFfs + ParsedLength;
 SectionLength = GetLength (((EFI_COMMON_SECTION_HEADER *) Ptr)->Size);
 Type  = ((EFI_COMMON_SECTION_HEADER *) Ptr)->Type;
--
2.12.2.windows.2


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

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

Re: [edk2-devel] [BaseTools PATCH v1] BaseTools: Add OpenSBI external definitions for RISC-V assembly build

[Yuwei Chen]

Hi, abner

I have a little suggestion for the patch format, it would be better if the 
length of each commit line is less than 70 characters.
You can follow the Commit Message Format in the wiki of tianocore.

Thanks,
Yuwei

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Abner
> Chang
> Sent: Friday, June 12, 2020 9:57 AM
> To: devel@edk2.groups.io
> Cc: abner.ch...@hpe.com; Feng, Bob C ; Gao,
> Liming ; Daniel Schaefer
> ; Leif Lindholm 
> Subject: [edk2-devel] [BaseTools PATCH v1] BaseTools: Add OpenSBI
> external definitions for RISC-V assembly build
> 
> Add opensbi external definitions to RISC-V build for assembly code.
> Use GCC5_RISCV_OPENSBI_TYPES to refer to edk2 data type for assembly
> files instead of using opensbi data type.
> 
> Signed-off-by: Abner Chang 
> 
> Cc: Bob Feng 
> Cc: Liming Gao 
> Cc: Daniel Schaefer 
> Cc: Leif Lindholm 
> ---
>  BaseTools/Conf/tools_def.template | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/BaseTools/Conf/tools_def.template
> b/BaseTools/Conf/tools_def.template
> index 923517b5c2..8aeb8a2a64 100755
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -2037,6 +2037,7 @@ DEFINE GCC5_RISCV64_CC_FLAGS   =
> DEF(GCC5_RISCV_ALL_CC_FLAGS) DEF(GC
>  DEFINE GCC5_RISCV64_DLINK_FLAGS=
> DEF(GCC5_RISCV_ALL_DLINK_FLAGS) -Wl,-melf64lriscv,--oformat=elf64-
> littleriscv,--no-relax DEFINE GCC5_RISCV64_DLINK2_FLAGS   =
> DEF(GCC5_RISCV_ALL_DLINK2_FLAGS) DEFINE GCC5_RISCV64_ASM_FLAGS
> = DEF(GCC5_RISCV_ALL_ASM_FLAGS) -march=DEF(GCC5_RISCV64_ARCH) -
> mcmodel=medany -mabi=lp64+DEFINE GCC_PP_FLAGS= -E -x
> assembler-with-cpp -include AutoGen.h DEF(GCC5_RISCV_OPENSBI_TYPES)
> ##
> ## #--
> 2.25.0
> 
> 
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
> 
> View/Reply Online (#61183): https://edk2.groups.io/g/devel/message/61183
> Mute This Topic: https://groups.io/mt/74832499/4546272
> Group Owner: devel+ow...@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub
> [yuwei.c...@intel.com] -=-=-=-=-=-=


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

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

[edk2-devel] [PATCH 0/2] UefiPayloadPkg: Use PCIE base address set by boot loader

[Ni, Ray]

Ray Ni (2):
  MdePkg/PciSegmentInfoLib: Add missing EFIAPI to GetPciSegmentInfo()
  UefiPayloadPkg/Pci: Use the PCIE Base Addr stored in AcpiBoardInfo HOB

v2:
  update copyright year in patch 1/2
  add missing EFIAPI in patch 2/2
  remove PCIE_BASE macro in UefiPayloadPkgIa32X64.dsc in patch 2/2.

 MdePkg/Include/Library/PciSegmentInfoLib.h|  1 +
 .../PciSegmentInfoLib.c   |  1 +
 .../PciSegmentInfoLibAcpiBoardInfo.c  | 55 +++
 .../PciSegmentInfoLibAcpiBoardInfo.inf| 36 
 UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc  |  6 +-
 5 files changed, 97 insertions(+), 2 deletions(-)
 create mode 100644 
UefiPayloadPkg/Library/PciSegmentInfoLibAcpiBoardInfo/PciSegmentInfoLibAcpiBoardInfo.c
 create mode 100644 
UefiPayloadPkg/Library/PciSegmentInfoLibAcpiBoardInfo/PciSegmentInfoLibAcpiBoardInfo.inf

-- 
2.26.2.windows.1


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

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

[edk2-devel] [PATCH V3 1/2] MdePkg/PciSegmentInfoLib: Add missing EFIAPI to GetPciSegmentInfo()

[Ni, Ray]

All public APIs should have EFIAPI modifier. Somehow PciSegmentInfoLib
missed the EFIAPI modifier.
The patch updates the library header file and NULL instance in MdePkg
to add the missing EFIAPI.

Signed-off-by: Ray Ni 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
---
 MdePkg/Include/Library/PciSegmentInfoLib.h   | 3 ++-
 MdePkg/Library/BasePciSegmentInfoLibNull/PciSegmentInfoLib.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/MdePkg/Include/Library/PciSegmentInfoLib.h 
b/MdePkg/Include/Library/PciSegmentInfoLib.h
index 320a223628..659ff85649 100644
--- a/MdePkg/Include/Library/PciSegmentInfoLib.h
+++ b/MdePkg/Include/Library/PciSegmentInfoLib.h
@@ -3,7 +3,7 @@
 
   This library is consumed by PciSegmentLib to support multiple segment PCI 
configuration access.
 
-  Copyright (c) 2017, Intel Corporation. All rights reserved.
+  Copyright (c) 2017 - 2020, Intel Corporation. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -28,6 +28,7 @@ typedef struct {
   @retval A callee owned array holding the segment information.
 **/
 PCI_SEGMENT_INFO *
+EFIAPI
 GetPciSegmentInfo (
   UINTN  *Count
   );
diff --git a/MdePkg/Library/BasePciSegmentInfoLibNull/PciSegmentInfoLib.c 
b/MdePkg/Library/BasePciSegmentInfoLibNull/PciSegmentInfoLib.c
index f9019c4e64..3ec7784057 100644
--- a/MdePkg/Library/BasePciSegmentInfoLibNull/PciSegmentInfoLib.c
+++ b/MdePkg/Library/BasePciSegmentInfoLibNull/PciSegmentInfoLib.c
@@ -2,7 +2,7 @@
   Default PCI Segment Information Library that returns one segment whose
   segment base address equals to PcdPciExpressBaseAddress.
 
-  Copyright (c) 2017, Intel Corporation. All rights reserved.
+  Copyright (c) 2017 - 2020, Intel Corporation. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -21,6 +21,7 @@
   @retval A callee owned array holding the segment information.
 **/
 PCI_SEGMENT_INFO *
+EFIAPI
 GetPciSegmentInfo (
   UINTN  *Count
   )
-- 
2.26.2.windows.1


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

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

[edk2-devel] [PATCH V3 2/2] UefiPayloadPkg/Pci: Use the PCIE Base Addr stored in AcpiBoardInfo HOB

[Ni, Ray]

Today's UefiPayloadPkg always uses 0xE000 as the PCIE base address
and ignores the value set in AcpiBoardInfo HOB created by the boot
loader. This makes the payload binary cannot work in environment
where the PCIE base address set by boot loader doesn't equal to
0xE000.

The patch enhances UefiPayloadPkg so that the PCIE base address
set by boot loader in the AcpiBoardInfo HOB is used.

Signed-off-by: Ray Ni 
Cc: Maurice Ma 
Cc: Guo Dong 
Cc: Benjamin You 
---
 UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c| 13 +++-
 UefiPayloadPkg/BlSupportDxe/BlSupportDxe.inf  |  3 +-
 .../PciSegmentInfoLibAcpiBoardInfo.c  | 59 +++
 .../PciSegmentInfoLibAcpiBoardInfo.inf| 36 +++
 UefiPayloadPkg/UefiPayloadPkgIa32.dsc | 10 ++--
 UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc  | 11 ++--
 6 files changed, 121 insertions(+), 11 deletions(-)
 create mode 100644 
UefiPayloadPkg/Library/PciSegmentInfoLibAcpiBoardInfo/PciSegmentInfoLibAcpiBoardInfo.c
 create mode 100644 
UefiPayloadPkg/Library/PciSegmentInfoLibAcpiBoardInfo/PciSegmentInfoLibAcpiBoardInfo.inf

diff --git a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c 
b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
index 28dfc8fc55..a3974dcc02 100644
--- a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
+++ b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
@@ -2,7 +2,7 @@
   This driver will report some MMIO/IO resources to dxe core, extract smbios 
and acpi
   tables from bootloader.
 
-  Copyright (c) 2014 - 2019, Intel Corporation. All rights reserved.
+  Copyright (c) 2014 - 2020, Intel Corporation. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -101,6 +101,7 @@ BlDxeEntryPoint (
   EFI_HOB_GUID_TYPE  *GuidHob;
   SYSTEM_TABLE_INFO  *SystemTableInfo;
   EFI_PEI_GRAPHICS_INFO_HOB  *GfxInfo;
+  ACPI_BOARD_INFO*AcpiBoardInfo;
 
   Status = EFI_SUCCESS;
   //
@@ -153,6 +154,16 @@ BlDxeEntryPoint (
 ASSERT_EFI_ERROR (Status);
   }
 
+  //
+  // Set PcdPciExpressBaseAddress by HOB info
+  //
+  GuidHob = GetFirstGuidHob ();
+  if (GuidHob != NULL) {
+AcpiBoardInfo = (ACPI_BOARD_INFO *)GET_GUID_HOB_DATA (GuidHob);
+Status = PcdSet64S (PcdPciExpressBaseAddress, 
AcpiBoardInfo->PcieBaseAddress);
+ASSERT_EFI_ERROR (Status);
+  }
+
   return EFI_SUCCESS;
 }
 
diff --git a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.inf 
b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.inf
index 4c2b4670af..1371d5eb79 100644
--- a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.inf
+++ b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.inf
@@ -3,7 +3,7 @@
 #
 # Report some MMIO/IO resources to dxe core, extract smbios and acpi tables
 #
-#  Copyright (c) 2014 - 2019, Intel Corporation. All rights reserved.
+#  Copyright (c) 2014 - 2020, Intel Corporation. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -53,6 +53,7 @@ [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution
   gEfiMdeModulePkgTokenSpaceGuid.PcdSetupVideoHorizontalResolution
   gEfiMdeModulePkgTokenSpaceGuid.PcdSetupVideoVerticalResolution
+  gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
 
 [Depex]
   TRUE
diff --git 
a/UefiPayloadPkg/Library/PciSegmentInfoLibAcpiBoardInfo/PciSegmentInfoLibAcpiBoardInfo.c
 
b/UefiPayloadPkg/Library/PciSegmentInfoLibAcpiBoardInfo/PciSegmentInfoLibAcpiBoardInfo.c
new file mode 100644
index 00..d37c91cc9f
--- /dev/null
+++ 
b/UefiPayloadPkg/Library/PciSegmentInfoLibAcpiBoardInfo/PciSegmentInfoLibAcpiBoardInfo.c
@@ -0,0 +1,59 @@
+/** @file
+  PCI Segment Information Library that returns one segment whose
+  segment base address is retrieved from AcpiBoardInfo HOB.
+
+  Copyright (c) 2020, Intel Corporation. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+STATIC PCI_SEGMENT_INFO mPciSegment0 = {
+  0,  // Segment number
+  0,  // To be fixed later
+  0,  // Start bus number
+  255 // End bus number
+};
+
+/**
+  Return an array of PCI_SEGMENT_INFO holding the segment information.
+
+  Note: The returned array/buffer is owned by callee.
+
+  @param  Count  Return the count of segments.
+
+  @retval A callee owned array holding the segment information.
+**/
+PCI_SEGMENT_INFO *
+EFIAPI
+GetPciSegmentInfo (
+  UINTN  *Count
+  )
+{
+  EFI_HOB_GUID_TYPE  *GuidHob;
+  ACPI_BOARD_INFO*AcpiBoardInfo;
+
+  ASSERT (Count != NULL);
+  if (Count == NULL) {
+return NULL;
+  }
+
+  if (mPciSegment0.BaseAddress == 0) {
+//
+// Find the acpi board information guid hob
+//
+GuidHob = GetFirstGuidHob ();
+ASSERT (GuidHob != NULL);
+
+AcpiBoardInfo = (ACPI_BOARD_INFO *) GET_GUID_HOB_DATA (GuidHob);
+mPciSegment0.BaseAddress = AcpiBoardInfo->PcieBaseAddress;
+  }
+  *Count = 1;
+  return 
+}
diff --git 
a/UefiPayloadPkg/Library/PciSegmentInfoLibAcpiBoardInfo/PciSegmentInfoLibAcpiBoardInfo.inf
 

Re: [edk2-devel] Silicon/SbsaQemu: Fix NOR flash RegionBaseAddress

[Ard Biesheuvel]

On 6/17/20 9:39 AM, Graeme Gregory wrote:

On Wed, Jun 17, 2020 at 12:59:13AM +0530, Tanmay Jagdale wrote:

The EFI_FIMRWARE_VOLUME_HEADER is present at an offset in the
NOR flash of Sbsa QEMU model. Use the right RegionBaseAddress
so that the EFI firmware volume header can be found correctly.

Signed-off-by: Tanmay Jagdale 


This fixes the problem for me, I have tested setting variables from
efi shell and from debian guest OS and they persist correctly now.

Tested-by: Graeme Gregory 



Pushed as 8b2c8fcaa90b..5f13ce8a65f2

Thanks,

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

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

Re: [edk2-devel] [PATCH v7 1/2] Features/Intel/BeepDebugFeaturePkg: add it.

[Dandan Bi]

Hi Min,

I have one minor comment about the function name of 
RegisterBeepBootTimeHandlers.
Since this is the notification function of installation of status code handler 
protocol, could you help update it to make it more readable?
Same comment for the function RegisterPostCodeBootTimeHandlers in patch 2.

Thanks,
Dandan
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Tan,
> Ming
> Sent: Tuesday, June 16, 2020 7:26 PM
> To: devel@edk2.groups.io
> Cc: Dong, Eric ; Gao, Liming 
> Subject: [edk2-devel] [PATCH v7 1/2] Features/Intel/BeepDebugFeaturePkg:
> add it.
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2792
> 
> The BeepDebugFeaturePkg include some useful beep debug
> libraries, such as get beep value from status code and beep.
> 
> It provide a library BeepStatusCodeHandlerLib used by edk2
> StatusCodeHandler.efi, used to do beep if needed.
> It also provide a library of BeepMap lib, it map the status code
> to beep value.
> A library of Beep lib is needed by platform, and this pkg has a
> Null implementation.
> 
> Cc: Eric Dong 
> Cc: Liming Gao 
> Signed-off-by: Ming Tan 
> ---
> V7: Add the dec files in AdvancedFeaturesPcd.dsc. Combine Beep and
> PostCode to 2/2 patchs.
> V6: Modify some bug when include the platform dsc file. And modify
> Readme.md.
> V5: In .inf files, remove some useless library.
> In RuntimeDxeBeepStatusCodeHandlerLib.c, add a variable to indicate
> whether need unregister.
> V4: Change Include/BeepDebugFeature.dsc, make it can be included in
> platform dsc file.
> V3: Modify according the Eric's review comments.
> V2: Delete the last empty line in
> BeepDebugFeaturePkg/Library/BeepMapLib/BeepMapLib.inf
>  .../Include/AdvancedFeaturesPcd.dsc   |  83 +++---
>  .../BeepDebugFeaturePkg.dec   |  36 +++
>  .../BeepDebugFeaturePkg.dsc   |  30 ++
>  .../Include/BeepDebugFeature.dsc  | 201 +
>  .../Include/Library/BeepLib.h |  33 +++
>  .../Include/Library/BeepMapLib.h  |  32 +++
>  .../Library/BeepLib/BeepLibNull.c |  37 +++
>  .../Library/BeepLib/BeepLibNull.inf   |  26 ++
>  .../Library/BeepMapLib/BeepMapLib.c   | 116 
>  .../Library/BeepMapLib/BeepMapLib.inf |  27 ++
>  .../BeepMapLib/PlatformStatusCodesInternal.h  | 270
> ++
>  .../PeiBeepStatusCodeHandlerLib.c | 101 +++
>  .../PeiBeepStatusCodeHandlerLib.inf   |  49 
>  .../RuntimeDxeBeepStatusCodeHandlerLib.c  | 184 
>  .../RuntimeDxeBeepStatusCodeHandlerLib.inf|  51 
>  .../SmmBeepStatusCodeHandlerLib.c | 138 +
>  .../SmmBeepStatusCodeHandlerLib.inf   |  50 
>  .../Debugging/BeepDebugFeaturePkg/Readme.md   | 125 
>  18 files changed, 1548 insertions(+), 41 deletions(-)
>  create mode 100644
> Features/Intel/Debugging/BeepDebugFeaturePkg/BeepDebugFeaturePkg.d
> ec
>  create mode 100644
> Features/Intel/Debugging/BeepDebugFeaturePkg/BeepDebugFeaturePkg.d
> sc
>  create mode 100644
> Features/Intel/Debugging/BeepDebugFeaturePkg/Include/BeepDebugFeat
> ure.dsc
>  create mode 100644
> Features/Intel/Debugging/BeepDebugFeaturePkg/Include/Library/BeepLib.
> h
>  create mode 100644
> Features/Intel/Debugging/BeepDebugFeaturePkg/Include/Library/BeepMa
> pLib.h
>  create mode 100644
> Features/Intel/Debugging/BeepDebugFeaturePkg/Library/BeepLib/BeepLib
> Null.c
>  create mode 100644
> Features/Intel/Debugging/BeepDebugFeaturePkg/Library/BeepLib/BeepLib
> Null.inf
>  create mode 100644
> Features/Intel/Debugging/BeepDebugFeaturePkg/Library/BeepMapLib/Bee
> pMapLib.c
>  create mode 100644
> Features/Intel/Debugging/BeepDebugFeaturePkg/Library/BeepMapLib/Bee
> pMapLib.inf
>  create mode 100644
> Features/Intel/Debugging/BeepDebugFeaturePkg/Library/BeepMapLib/Plat
> formStatusCodesInternal.h
>  create mode 100644
> Features/Intel/Debugging/BeepDebugFeaturePkg/Library/BeepStatusCode
> HandlerLib/PeiBeepStatusCodeHandlerLib.c
>  create mode 100644
> Features/Intel/Debugging/BeepDebugFeaturePkg/Library/BeepStatusCode
> HandlerLib/PeiBeepStatusCodeHandlerLib.inf
>  create mode 100644
> Features/Intel/Debugging/BeepDebugFeaturePkg/Library/BeepStatusCode
> HandlerLib/RuntimeDxeBeepStatusCodeHandlerLib.c
>  create mode 100644
> Features/Intel/Debugging/BeepDebugFeaturePkg/Library/BeepStatusCode
> HandlerLib/RuntimeDxeBeepStatusCodeHandlerLib.inf
>  create mode 100644
> Features/Intel/Debugging/BeepDebugFeaturePkg/Library/BeepStatusCode
> HandlerLib/SmmBeepStatusCodeHandlerLib.c
>  create mode 100644
> Features/Intel/Debugging/BeepDebugFeaturePkg/Library/BeepStatusCode
> HandlerLib/SmmBeepStatusCodeHandlerLib.inf
>  create mode 100644
> Features/Intel/Debugging/BeepDebugFeaturePkg/Readme.md
> 
> diff --git
> a/Features/Intel/AdvancedFeaturePkg/Include/AdvancedFeaturesPcd.dsc
> b/Features/Intel/AdvancedFeaturePkg/Include/AdvancedFeaturesPcd.dsc
> index 

Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Wang, Sunny (HPS SW)]

Hi Pete. 

Since the EfiBootManagerProcessLoadOption is called by ProcessLoadOptions as 
well, your change would also cause some unexpected behavior like:
1. Signal one more ReadyToBoot for the PlatformRecovery option which is an 
application that calls EfiBootManagerBoot() to launch its recovered boot option.
2. Signal ReadyToBoot for SysPrep or Driver that is not really a "boot" 
option. 

To solve your problem, creating a PlatformRecovery option with the smallest 
option number and using it instead of default one (with short-form File Path 
Media Device Path) looks like a simpler solution.

By the way, I also checked the UEFI specification. It looks making sense to 
only signal ReadyToBoot for boot option (Boot). Therefore, your change may 
also require specification change.

Regards,
Sunny Wang

-Original Message-
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Pete 
Batard
Sent: Tuesday, June 16, 2020 5:56 PM
To: devel@edk2.groups.io
Cc: zhichao@intel.com; ray...@intel.com; ard.biesheu...@arm.com; 
l...@nuviainc.com
Subject: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal 
ReadyToBoot on platform recovery

Currently, the ReadyToBoot event is only signaled when a formal Boot Manager 
option is executed (in BmBoot.c -> EfiBootManagerBoot ()).

However, with the introduction of Platform Recovery in UEFI 2.5, which may lead 
to the execution of a boot loader that has similar requirements to a regular 
one, yet is not launched as a Boot Manager option, it also becomes necessary to 
signal ReadyToBoot when a Platform Recovery boot loader runs.

Especially, this can be critical to ensuring that the graphical console is 
actually usable during platform recovery, as some platforms do rely on the 
ConsolePrefDxe driver, which only performs console initialization after 
ReadyToBoot is triggered.

This patch fixes that behaviour by calling EfiSignalEventReadyToBoot () in 
EfiBootManagerProcessLoadOption (), which is the function that sets up the 
platform recovery boot process.

Signed-off-by: Pete Batard 
---
 MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
index 89372b3b97b8..117f1f5b124c 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
@@ -1376,6 +1376,15 @@ EfiBootManagerProcessLoadOption (
 return EFI_SUCCESS;
   }
 
+  //
+  // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load and 
execute the boot option.
+  //
+  EfiSignalEventReadyToBoot ();
+  //
+  // Report Status Code to indicate ReadyToBoot was signalled  //
+ REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER | 
+ EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
+
   //
   // Load and start the load option.
   //
--
2.21.0.windows.1





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

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

Re: [EXTERNAL] [edk2-devel] [PATCH v5 00/14] Add the VariablePolicy feature

[Guomin Jiang]

Hi Bret,

I plan to review it and give feedback before 7/31.

Thanks and Sorry for inconveniences.

Best Regards.
From: devel@edk2.groups.io  On Behalf Of Bret Barkelew 
via groups.io
Sent: Tuesday, June 9, 2020 1:52 PM
To: devel@edk2.groups.io; b...@corthon.com
Cc: Yao, Jiewen ; Zhang, Chao B ; 
Wang, Jian J ; Wu, Hao A ; Gao, 
Liming ; Justen, Jordan L ; 
Laszlo Ersek ; Ard Biesheuvel ; 
Andrew Fish ; Ni, Ray 
Subject: Re: [EXTERNAL] [edk2-devel] [PATCH v5 00/14] Add the VariablePolicy 
feature

Bump.
Now that the stable tag is behind us, I'd like to get this in to have maximum 
time before the next stable tag.

I think the only reviews I've seen so far are for the platform integrations 
(Arm, Ovmf, and Embedded). Need more eyeballs, please and thank you!

- Bret

From: Bret Barkelew via groups.io
Sent: Wednesday, June 3, 2020 2:52 AM
To: devel@edk2.groups.io
Cc: Yao, Jiewen; Chao 
Zhang; Jian J 
Wang; Hao A Wu; 
liming.gao; Jordan 
Justen; Laszlo 
Ersek; Ard Biesheuvel; 
Andrew Fish; Ni, Ray
Subject: [EXTERNAL] [edk2-devel] [PATCH v5 00/14] Add the VariablePolicy feature

REF:https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D2522data=02%7C01%7Cbret.barkelew%40microsoft.com%7C90bcb822fa054686203008d807a3e4ee%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637267747784879051sdata=k9X9qPTDTQlno5%2Ff4koMn6bE9s6nTOIlJ886PQRw%2Bzc%3Dreserved=0

The 14 patches in this series add the VariablePolicy feature to the core,
deprecate Edk2VarLock (while adding a compatibility layer to reduce code
churn), and integrate the VariablePolicy libraries and protocols into
Variable Services.

Since the integration requires multiple changes, including adding libraries,
a protocol, an SMI communication handler, and VariableServices integration,
the patches are broken up by individual library additions and then a final
integration. Security-sensitive changes like bypassing Authenticated
Variable enforcement are also broken out into individual patches so that
attention can be called directly to them.

Platform porting instructions are described in this wiki entry:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Ftianocore.github.io%2Fwiki%2FVariablePolicy-Protocol---Enhanced-Method-for-Managing-Variables%23platform-portingdata=02%7C01%7Cbret.barkelew%40microsoft.com%7C90bcb822fa054686203008d807a3e4ee%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637267747784879051sdata=eIQjfZJQGTECXzETa1iZ3T9vOdNiNEjIzVrjhDR%2B2CE%3Dreserved=0

Discussion of the feature can be found in multiple places throughout
the last year on the RFC channel, staging branches, and in devel.

Most recently, this subject was discussed in this thread:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F53712data=02%7C01%7Cbret.barkelew%40microsoft.com%7C90bcb822fa054686203008d807a3e4ee%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637267747784879051sdata=rhwUXzkU%2B71sFkomJvPzi4IN6hz2JKIbDBnNt0wCJS8%3Dreserved=0
(the code branches shared in that discussion are now out of date, but the
whitepapers and discussion are relevant).

Cc: Jiewen Yao mailto:jiewen@intel.com>>
Cc: Chao Zhang mailto:chao.b.zh...@intel.com>>
Cc: Jian J Wang mailto:jian.j.w...@intel.com>>
Cc: Hao A Wu mailto:hao.a...@intel.com>>
Cc: Liming Gao mailto:liming@intel.com>>
Cc: Jordan Justen mailto:jordan.l.jus...@intel.com>>
Cc: Laszlo Ersek mailto:ler...@redhat.com>>
Cc: Ard Biesheuvel mailto:ard.biesheu...@arm.com>>
Cc: Andrew Fish mailto:af...@apple.com>>
Cc: Ray Ni mailto:ray...@intel.com>>
Cc: Bret Barkelew mailto:brbar...@microsoft.com>>
Signed-off-by: Bret Barkelew 
mailto:brbar...@microsoft.com>>

v5 changes:
* Fix the CONST mismatch in VariablePolicy.h and VariablePolicySmmDxe.c
* Fix EFIAPI mismatches in the functional unittest
* Rebase on latest origin/master

v4 changes:
* Remove Optional PcdAllowVariablePolicyEnforcementDisable PCD from platforms
* Rebase on master
* Migrate to new MmCommunicate2 protocol
* Fix an oversight in the default return value for InitMmCommonCommBuffer
* Fix in VariablePolicyLib to allow ExtraInitRuntimeDxe to consume variables

V3 changes:
* Address all non-unittest issues with ECC
* Make additional style changes
* Include section name in hunk headers in "ini-style" files
* Remove requirement for the EdkiiPiSmmCommunicationsRegionTable driver
  (now allocates its own buffer)
* Change names from VARIABLE_POLICY_PROTOCOL and gVariablePolicyProtocolGuid
  to EDKII_VARIABLE_POLICY_PROTOCOL and gEdkiiVariablePolicyProtocolGuid
* Fix GCC warning about 

Re: [edk2-devel] Silicon/SbsaQemu: Fix NOR flash RegionBaseAddress

[Graeme Gregory]

On Wed, Jun 17, 2020 at 12:59:13AM +0530, Tanmay Jagdale wrote:
> The EFI_FIMRWARE_VOLUME_HEADER is present at an offset in the
> NOR flash of Sbsa QEMU model. Use the right RegionBaseAddress
> so that the EFI firmware volume header can be found correctly.
> 
> Signed-off-by: Tanmay Jagdale 

This fixes the problem for me, I have tested setting variables from
efi shell and from debian guest OS and they persist correctly now.

Tested-by: Graeme Gregory 

> ---
>  .../SbsaQemu/Library/SbsaQemuNorFlashLib/SbsaQemuNorFlashLib.c  | 2 +-
>  .../Library/SbsaQemuNorFlashLib/SbsaQemuNorFlashLib.inf | 2 ++
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git 
> a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuNorFlashLib/SbsaQemuNorFlashLib.c 
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuNorFlashLib/SbsaQemuNorFlashLib.c
> index e7bb626596..0946327cb5 100644
> --- a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuNorFlashLib/SbsaQemuNorFlashLib.c
> +++ b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuNorFlashLib/SbsaQemuNorFlashLib.c
> @@ -23,7 +23,7 @@ NorFlashPlatformInitialization (
>  NOR_FLASH_DESCRIPTION mNorFlashDevice =
>  {
>   FixedPcdGet64(PcdFdBaseAddress),
> - FixedPcdGet64(PcdFdBaseAddress),
> + FixedPcdGet64(PcdFlashNvStorageVariableBase),
>   FixedPcdGet32(PcdFdSize),
>   QEMU_NOR_BLOCK_SIZE
>  };
> diff --git 
> a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuNorFlashLib/SbsaQemuNorFlashLib.inf 
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuNorFlashLib/SbsaQemuNorFlashLib.inf
> index 82712c8901..f2ba41e1df 100644
> --- 
> a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuNorFlashLib/SbsaQemuNorFlashLib.inf
> +++ 
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuNorFlashLib/SbsaQemuNorFlashLib.inf
> @@ -23,7 +23,9 @@
>ArmPlatformPkg/ArmPlatformPkg.dec
>ArmPkg/ArmPkg.dec
>MdePkg/MdePkg.dec
> +  MdeModulePkg/MdeModulePkg.dec
>  
>  [FixedPcd]
>gArmTokenSpaceGuid.PcdFdBaseAddress
>gArmTokenSpaceGuid.PcdFdSize
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase
> -- 
> 2.27.0
> 

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

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

[edk2-devel] [PATCH v5 1/1] MdeModulePkg.dec: Change PCDs for status code.

[Tan, Ming]

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

In order to support enable/disable report status code through memory
or serial dynamic, change the following PCDs from [PcdsFeatureFlag] to
[PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]:
  PcdStatusCodeUseSerial
  PcdStatusCodeUseMemory
The original plaforms can use PcdsFixedAtBuild in .dsc files to save size.
Currently do not remove the old pcd type to keep compatible.

Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Ming Tan 
---
V5: Do not remove th old pcd type to keep compatible, and change to standalone 
patch.
V4: No change for this 1/4 patch, just modify the 2-4/4 patchs.
V3: Split one patch to several patchs, each Pkg has one patch.
V2: Change the new type from [PcdsDynamic] to [PcdsFixedAtBuild, 
PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
And set to PcdsFixedAtBuild in the original platform .dsc files.

 MdeModulePkg/MdeModulePkg.dec| 13 +
 .../StatusCodeHandler/Pei/StatusCodeHandlerPei.c |  6 +++---
 .../Pei/StatusCodeHandlerPei.inf |  6 ++
 .../RuntimeDxe/StatusCodeHandlerRuntimeDxe.c | 16 
 .../RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf   |  6 ++
 .../StatusCodeHandler/Smm/StatusCodeHandlerSmm.c | 10 +-
 .../Smm/StatusCodeHandlerSmm.inf |  6 ++
 7 files changed, 35 insertions(+), 28 deletions(-)

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 4f44af694862..bd369d1f230e 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -2001,6 +2001,19 @@ [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, 
PcdsDynamicEx]
   # @Prompt TCG Platform Firmware Profile revision.
   
gEfiMdeModulePkgTokenSpaceGuid.PcdTcgPfpMeasurementRevision|0|UINT32|0x00010077
 
+  ## Indicates if StatusCode is reported via Serial port.
+  #   TRUE  - Reports StatusCode via Serial port.
+  #   FALSE - Does not report StatusCode via Serial port.
+  # @Prompt Enable StatusCode via Serial port.
+  gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|TRUE|BOOLEAN|0x00010022
+
+  ## Indicates if StatusCode is stored in memory.
+  #  The memory is boot time memory in PEI Phase and is runtime memory in DXE 
Phase.
+  #   TRUE  - Stores StatusCode in memory.
+  #   FALSE - Does not store StatusCode in memory.
+  # @Prompt Enable StatusCode via memory.
+  
gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseMemory|FALSE|BOOLEAN|0x00010023
+
 [PcdsPatchableInModule]
   ## Specify memory size with page number for PEI code when
   #  Loading Module at Fixed Address feature is enabled.
diff --git 
a/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.c 
b/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.c
index 1b07f92f3ce8..9b2ea4ee84d9 100644
--- a/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.c
+++ b/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.c
@@ -2,7 +2,7 @@
   Report Status Code Handler PEIM which produces general handlers and hook them
   onto the PEI status code router.
 
-  Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2009 - 2020, Intel Corporation. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -45,13 +45,13 @@ StatusCodeHandlerPeiEntry (
   // If enable UseSerial, then initialize serial port.
   // if enable UseMemory, then initialize memory status code worker.
   //
-  if (FeaturePcdGet (PcdStatusCodeUseSerial)) {
+  if (PcdGetBool (PcdStatusCodeUseSerial)) {
 Status = SerialPortInitialize();
 ASSERT_EFI_ERROR (Status);
 Status = RscHandlerPpi->Register (SerialStatusCodeReportWorker);
 ASSERT_EFI_ERROR (Status);
   }
-  if (FeaturePcdGet (PcdStatusCodeUseMemory)) {
+  if (PcdGetBool (PcdStatusCodeUseMemory)) {
 Status = MemoryStatusCodeInitializeWorker ();
 ASSERT_EFI_ERROR (Status);
 Status = RscHandlerPpi->Register (MemoryStatusCodeReportWorker);
diff --git 
a/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf 
b/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf
index 8aef9af34a05..64380ddfaccc 100644
--- a/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf
+++ b/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf
@@ -53,11 +53,9 @@ [Guids]
 [Ppis]
   gEfiPeiRscHandlerPpiGuid  ## CONSUMES
 
-[FeaturePcd]
-  gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseMemory ## CONSUMES
-  gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial ## CONSUMES
-
 [Pcd]
+  gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial ## CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseMemory ## CONSUMES
   
gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1|gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseMemory
## SOMETIMES_CONSUMES
 
 [Depex]
diff --git 

Re: [EXTERNAL] [edk2-devel] [PATCH v5 12/14] MdeModulePkg: Change TCG MOR variables to use VariablePolicy

[Bret Barkelew via groups.io]

Bump. This specific patch needs Reviews.


- Bret


From: devel@edk2.groups.io  on behalf of Bret Barkelew 
via groups.io 
Sent: Tuesday, June 2, 2020 11:58 PM
To: devel@edk2.groups.io 
Cc: Jian J Wang ; Hao A Wu ; 
liming.gao 
Subject: [EXTERNAL] [edk2-devel] [PATCH v5 12/14] MdeModulePkg: Change TCG MOR 
variables to use VariablePolicy

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D2522data=02%7C01%7Cbret.barkelew%40microsoft.com%7Cc4837d136ec548d67adc08d807a3e192%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637267747730722710sdata=NAVaoXnmIgu2F0YobNn7oC5XNGudCoalxrB3nPZDl98%3Dreserved=0

These were previously using VarLock, which is
being deprecated.

Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Liming Gao 
Cc: Bret Barkelew 
Signed-off-by: Bret Barkelew 
---
 MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c  | 52 
++--
 MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c  | 52 
+++-
 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf   |  2 +
 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf |  1 +
 4 files changed, 82 insertions(+), 25 deletions(-)

diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c
index e7accf4ed806..b85f08c48c11 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c
@@ -5,6 +5,7 @@
   MOR lock control unsupported.



 Copyright (c) 2016, Intel Corporation. All rights reserved.

+Copyright (c) Microsoft Corporation.

 SPDX-License-Identifier: BSD-2-Clause-Patent



 **/

@@ -17,7 +18,8 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #include 

 #include "Variable.h"



-extern EDKII_VARIABLE_LOCK_PROTOCOL mVariableLock;

+#include 

+#include 



 /**

   This service is an MOR/MorLock checker handler for the SetVariable().

@@ -77,11 +79,6 @@ MorLockInit (
 NULL// Data

 );



-  //

-  // Need set this variable to be read-only to prevent other module set it.

-  //

-  VariableLockRequestToLock (, 
MEMORY_OVERWRITE_REQUEST_CONTROL_LOCK_NAME, 
);

-

   //

   // The MOR variable can effectively improve platform security only when the

   // MorLock variable protects the MOR variable. In turn MorLock cannot be made

@@ -99,11 +96,6 @@ MorLockInit (
 0,  // DataSize

 NULL// Data

 );

-  VariableLockRequestToLock (

-,

-MEMORY_OVERWRITE_REQUEST_VARIABLE_NAME,

-

-);



   return EFI_SUCCESS;

 }

@@ -118,7 +110,39 @@ MorLockInitAtEndOfDxe (
   VOID

   )

 {

-  //

-  // Do nothing.

-  //

+  EFI_STATUSStatus;

+  EDKII_VARIABLE_POLICY_PROTOCOL*VariablePolicy;

+

+  // First, we obviously need to locate the VariablePolicy protocol.

+  Status = gBS->LocateProtocol( , NULL, 
(VOID**) );

+  if (EFI_ERROR( Status )) {

+DEBUG(( DEBUG_ERROR, "%a - Could not locate VariablePolicy protocol! 
%r\n", __FUNCTION__, Status ));

+return;

+  }

+

+  // If we're successful, go ahead and set the policies to protect the target 
variables.

+  Status = RegisterBasicVariablePolicy( VariablePolicy,

+
,

+
MEMORY_OVERWRITE_REQUEST_CONTROL_LOCK_NAME,

+VARIABLE_POLICY_NO_MIN_SIZE,

+VARIABLE_POLICY_NO_MAX_SIZE,

+VARIABLE_POLICY_NO_MUST_ATTR,

+VARIABLE_POLICY_NO_CANT_ATTR,

+VARIABLE_POLICY_TYPE_LOCK_NOW );

+  if (EFI_ERROR( Status )) {

+DEBUG(( DEBUG_ERROR, "%a - Could not lock variable %s! %r\n", 
__FUNCTION__, MEMORY_OVERWRITE_REQUEST_CONTROL_LOCK_NAME, Status ));

+  }

+  Status = RegisterBasicVariablePolicy( VariablePolicy,

+,

+MEMORY_OVERWRITE_REQUEST_VARIABLE_NAME,

+VARIABLE_POLICY_NO_MIN_SIZE,

+VARIABLE_POLICY_NO_MAX_SIZE,

+VARIABLE_POLICY_NO_MUST_ATTR,

+VARIABLE_POLICY_NO_CANT_ATTR,

+VARIABLE_POLICY_TYPE_LOCK_NOW );

+  if (EFI_ERROR( Status )) {

+DEBUG(( DEBUG_ERROR, "%a - Could not lock variable %s! %r\n", 
__FUNCTION__, MEMORY_OVERWRITE_REQUEST_VARIABLE_NAME, Status ));

+  }

+

+  return;

 }

diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
index 085f82035f4b..ee37942a6b0c 100644
--- 

Re: [EXTERNAL] [edk2-devel] [PATCH v5 11/14] SecurityPkg: Allow VariablePolicy state to delete authenticated variables

[Bret Barkelew via groups.io]

Bump. This specific patch needs Reviews.


- Bret


From: devel@edk2.groups.io  on behalf of Bret Barkelew 
via groups.io 
Sent: Tuesday, June 2, 2020 11:58 PM
To: devel@edk2.groups.io 
Cc: Yao, Jiewen ; Jian J Wang ; 
Chao Zhang 
Subject: [EXTERNAL] [edk2-devel] [PATCH v5 11/14] SecurityPkg: Allow 
VariablePolicy state to delete authenticated variables

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D2522data=02%7C01%7CBret.Barkelew%40microsoft.com%7C2d4a699617424da6381f08d807a3d094%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637267747454210698sdata=10egANvpHPv6bNbdaNyL4%2F3tOk9eG03HUKCADhQix68%3Dreserved=0

Causes AuthService to check
IsVariablePolicyEnabled() before enforcing
write protections to allow variable deletion
when policy engine is disabled.

Only allows deletion, not modification.

Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Chao Zhang 
Cc: Bret Barkelew 
Signed-off-by: Bret Barkelew 
---
 SecurityPkg/Library/AuthVariableLib/AuthService.c   | 22 

 SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf |  2 ++
 2 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/SecurityPkg/Library/AuthVariableLib/AuthService.c 
b/SecurityPkg/Library/AuthVariableLib/AuthService.c
index 2f60331f2c04..aca9a5620c28 100644
--- a/SecurityPkg/Library/AuthVariableLib/AuthService.c
+++ b/SecurityPkg/Library/AuthVariableLib/AuthService.c
@@ -19,12 +19,16 @@
   to verify the signature.



 Copyright (c) 2009 - 2019, Intel Corporation. All rights reserved.

+Copyright (c) Microsoft Corporation.

 SPDX-License-Identifier: BSD-2-Clause-Patent



 **/



 #include "AuthServiceInternal.h"



+#include 

+#include 

+

 //

 // Public Exponent of RSA Key.

 //

@@ -217,9 +221,12 @@ NeedPhysicallyPresent(
   IN EFI_GUID   *VendorGuid

   )

 {

-  if ((CompareGuid (VendorGuid, ) && (StrCmp 
(VariableName, EFI_SECURE_BOOT_ENABLE_NAME) == 0))

-|| (CompareGuid (VendorGuid, ) && (StrCmp 
(VariableName, EFI_CUSTOM_MODE_NAME) == 0))) {

-return TRUE;

+  // If the VariablePolicy engine is disabled, allow deletion of any 
authenticated variables.

+  if (IsVariablePolicyEnabled()) {

+if ((CompareGuid (VendorGuid, ) && (StrCmp 
(VariableName, EFI_SECURE_BOOT_ENABLE_NAME) == 0))

+  || (CompareGuid (VendorGuid, ) && (StrCmp 
(VariableName, EFI_CUSTOM_MODE_NAME) == 0))) {

+  return TRUE;

+}

   }



   return FALSE;

@@ -842,7 +849,8 @@ ProcessVariable (
  

  );



-  if ((!EFI_ERROR (Status)) && IsDeleteAuthVariable 
(OrgVariableInfo.Attributes, Data, DataSize, Attributes) && 
UserPhysicalPresent()) {

+  // If the VariablePolicy engine is disabled, allow deletion of any 
authenticated variables.

+  if ((!EFI_ERROR (Status)) && IsDeleteAuthVariable 
(OrgVariableInfo.Attributes, Data, DataSize, Attributes) && 
(UserPhysicalPresent() || !IsVariablePolicyEnabled())) {

 //

 // Allow the delete operation of common authenticated variable(AT or AW) 
at user physical presence.

 //

@@ -1960,6 +1968,12 @@ VerifyTimeBasedPayload (


   CopyMem (Buffer, PayloadPtr, PayloadSize);



+  // If the VariablePolicy engine is disabled, allow deletion of any 
authenticated variables.

+  if (PayloadSize == 0 && (Attributes & EFI_VARIABLE_APPEND_WRITE) == 0 && 
!IsVariablePolicyEnabled()) {

+VerifyStatus = TRUE;

+goto Exit;

+  }

+

   if (AuthVarType == AuthVarTypePk) {

 //

 // Verify that the signature has been made with the current Platform Key 
(no chaining for PK).

diff --git a/SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf 
b/SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
index 8d4ce14df494..8eadeebcebd7 100644
--- a/SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
+++ b/SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
@@ -3,6 +3,7 @@
 #

 #  Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.

 #  Copyright (c) 2018, ARM Limited. All rights reserved.

+#  Copyright (c) Microsoft Corporation.

 #

 #  SPDX-License-Identifier: BSD-2-Clause-Patent

 #

@@ -41,6 +42,7 @@ [LibraryClasses]
   MemoryAllocationLib

   BaseCryptLib

   PlatformSecureLib

+  VariablePolicyLib



 [Guids]

   ## CONSUMES## Variable:L"SetupMode"

--
2.26.2.windows.1.8.g01c50adf56.20200515075929


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

View/Reply Online (#60637): 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F60637data=02%7C01%7CBret.Barkelew%40microsoft.com%7C2d4a699617424da6381f08d807a3d094%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637267747454210698sdata=%2BAYYshrhsUe22N%2Bq29KTBwBSfPZ%2BKMI%2BHfXnlAC1UDA%3Dreserved=0
Mute This Topic: 

Re: [EXTERNAL] [edk2-devel] [PATCH v5 10/14] MdeModulePkg: Allow VariablePolicy state to delete protected variables

[Bret Barkelew via groups.io]

Bump. This specific patch needs Reviews.


- Bret


From: devel@edk2.groups.io  on behalf of Bret Barkelew 
via groups.io 
Sent: Tuesday, June 2, 2020 11:58 PM
To: devel@edk2.groups.io 
Cc: Jian J Wang ; Hao A Wu ; 
liming.gao 
Subject: [EXTERNAL] [edk2-devel] [PATCH v5 10/14] MdeModulePkg: Allow 
VariablePolicy state to delete protected variables

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D2522data=02%7C01%7CBret.Barkelew%40microsoft.com%7Cec7ecc21f4ff44dadb1908d807a3e04b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637267747709985448sdata=DFl0Cmoq4Tos0b%2FSLNZMV8OJ9Bj7Waz5VK%2B9jhVzKUY%3Dreserved=0

TcgMorLockSmm provides special protections for
the TCG MOR variables. This will check
IsVariablePolicyEnabled() before enforcing
them to allow variable deletion when policy
engine is disabled.

Only allows deletion, not modification.

Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Liming Gao 
Cc: Bret Barkelew 
Signed-off-by: Bret Barkelew 
---
 MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c  | 10 
++
 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf |  2 ++
 2 files changed, 12 insertions(+)

diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
index 6d80eb64341a..085f82035f4b 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
@@ -5,6 +5,7 @@
   This module adds Variable Hook and check MemoryOverwriteRequestControlLock.



 Copyright (c) 2016 - 2018, Intel Corporation. All rights reserved.

+Copyright (c) Microsoft Corporation.

 SPDX-License-Identifier: BSD-2-Clause-Patent



 **/

@@ -17,6 +18,10 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #include 

 #include "Variable.h"



+#include 

+

+#include 

+

 typedef struct {

   CHAR16 *VariableName;

   EFI_GUID   *VendorGuid;

@@ -341,6 +346,11 @@ SetVariableCheckHandlerMor (
 return EFI_SUCCESS;

   }



+  // Permit deletion when policy is disabled.

+  if (!IsVariablePolicyEnabled() && ((Attributes == 0) || (DataSize == 0))) {

+return EFI_SUCCESS;

+  }

+

   //

   // MorLock variable

   //

diff --git 
a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
index 6e17f6cdf588..d8f480be27cc 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
@@ -20,6 +20,7 @@
 #

 # Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved.

 # Copyright (c) 2018, Linaro, Ltd. All rights reserved.

+# Copyright (c) Microsoft Corporation.

 # SPDX-License-Identifier: BSD-2-Clause-Patent

 #

 ##

@@ -74,6 +75,7 @@ [LibraryClasses]
   StandaloneMmDriverEntryPoint

   SynchronizationLib

   VarCheckLib

+  VariablePolicyLib



 [Protocols]

   gEfiSmmFirmwareVolumeBlockProtocolGuid## CONSUMES

--
2.26.2.windows.1.8.g01c50adf56.20200515075929


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

View/Reply Online (#60648): 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F60648data=02%7C01%7CBret.Barkelew%40microsoft.com%7Cec7ecc21f4ff44dadb1908d807a3e04b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637267747709985448sdata=CUaI6lTvlhobvdDoqQgtMcKp5QRggGmaV1S3NEaeOtA%3Dreserved=0
Mute This Topic: 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.io%2Fmt%2F74646437%2F1822150data=02%7C01%7CBret.Barkelew%40microsoft.com%7Cec7ecc21f4ff44dadb1908d807a3e04b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637267747709985448sdata=YvePvU%2FkWoM30sGZOk4rLOEWJQQJVsQO49%2FlhUtpm2k%3Dreserved=0
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Funsubdata=02%7C01%7CBret.Barkelew%40microsoft.com%7Cec7ecc21f4ff44dadb1908d807a3e04b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637267747709995441sdata=OcjE6Lzcue9eaD05VCLcPVPPBI9zq9P1uY0ZKKG4rfE%3Dreserved=0
  [brbar...@microsoft.com]
-=-=-=-=-=-=


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

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

Re: [EXTERNAL] [edk2-devel] [PATCH v5 06/14] EmulatorPkg: Add VariablePolicy engine to EmulatorPkg platform

[Bret Barkelew via groups.io]

Bump. This specific patch needs Reviews.


- Bret


From: devel@edk2.groups.io  on behalf of Bret Barkelew 
via groups.io 
Sent: Tuesday, June 2, 2020 11:58 PM
To: devel@edk2.groups.io 
Cc: Jordan Justen ; Andrew Fish ; 
Ni, Ray 
Subject: [EXTERNAL] [edk2-devel] [PATCH v5 06/14] EmulatorPkg: Add 
VariablePolicy engine to EmulatorPkg platform

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D2522data=02%7C01%7Cbret.barkelew%40microsoft.com%7Ca56662a5f811496ad41708d807a3d4f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637267747518608851sdata=lgRAXwoZC4hja4c1cE39pbslVKl7BZuGzP7e8r995Tg%3Dreserved=0

Cc: Jordan Justen 
Cc: Andrew Fish 
Cc: Ray Ni 
Cc: Bret Barkelew 
Signed-off-by: Bret Barkelew 
---
 EmulatorPkg/EmulatorPkg.dsc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
index 1fc924ae5a16..e49deb54161a 100644
--- a/EmulatorPkg/EmulatorPkg.dsc
+++ b/EmulatorPkg/EmulatorPkg.dsc
@@ -6,6 +6,7 @@
 #

 # Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.

 # Portions copyright (c) 2010 - 2011, Apple Inc. All rights reserved.

+# Copyright (c) Microsoft Corporation.

 #

 # SPDX-License-Identifier: BSD-2-Clause-Patent

 #

@@ -108,6 +109,8 @@ [LibraryClasses]
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf

   
AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf

   VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf

+  
VariablePolicyLib|MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLibRuntimeDxe.inf

+  
VariablePolicyHelperLib|MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.inf

   SortLib|MdeModulePkg/Library/BaseSortLib/BaseSortLib.inf

   ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf

   FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf

--
2.26.2.windows.1.8.g01c50adf56.20200515075929


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

View/Reply Online (#60640): 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F60640data=02%7C01%7Cbret.barkelew%40microsoft.com%7Ca56662a5f811496ad41708d807a3d4f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637267747518608851sdata=q%2FHfjUo1eRUp%2FD50XZQlM1rmS9gY5ilXbo3%2B9zlgKqw%3Dreserved=0
Mute This Topic: 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.io%2Fmt%2F74646429%2F1852292data=02%7C01%7Cbret.barkelew%40microsoft.com%7Ca56662a5f811496ad41708d807a3d4f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637267747518608851sdata=lTdyncwJeC9AVqxfvI6sL7emqulUvfCQN%2BegdbSEHAU%3Dreserved=0
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Funsubdata=02%7C01%7Cbret.barkelew%40microsoft.com%7Ca56662a5f811496ad41708d807a3d4f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637267747518608851sdata=vI0nFn13RBlMo8KklgQEhLUOEbhDta5yOsSEwtk8zZg%3Dreserved=0
  [bret.barke...@microsoft.com]
-=-=-=-=-=-=


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

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

Re: [EXTERNAL] [edk2-devel] [PATCH v5 03/14] MdeModulePkg: Define the VariablePolicyHelperLib

[Bret Barkelew via groups.io]

Bump. This specific patch needs Reviews.


- Bret


From: devel@edk2.groups.io  on behalf of Bret Barkelew 
via groups.io 
Sent: Tuesday, June 2, 2020 11:57 PM
To: devel@edk2.groups.io 
Cc: Jian J Wang ; Hao A Wu ; 
liming.gao 
Subject: [EXTERNAL] [edk2-devel] [PATCH v5 03/14] MdeModulePkg: Define the 
VariablePolicyHelperLib

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D2522data=02%7C01%7CBret.Barkelew%40microsoft.com%7Cf4de67d242ec4517ab1c08d807a3dc74%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637267747648232766sdata=ErqHXizN7Q6ghP%2BPuivvQuQnhfYKMEMwWgitRbYMCmE%3Dreserved=0

VariablePolicy is an updated interface to
replace VarLock and VarCheckProtocol.

Add the VariablePolicyHelperLib library, containing
several functions to help with the repetitive process
of creating a correctly structured and packed
VariablePolicy entry.

Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Liming Gao 
Cc: Bret Barkelew 
Signed-off-by: Bret Barkelew 
---
 MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.c   | 396 

 MdeModulePkg/Include/Library/VariablePolicyHelperLib.h   | 164 

 MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.inf |  35 
++
 MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.uni |  12 
+
 MdeModulePkg/MdeModulePkg.dec|   5 
+
 MdeModulePkg/MdeModulePkg.dsc|   2 
+
 6 files changed, 614 insertions(+)

diff --git 
a/MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.c 
b/MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.c
new file mode 100644
index ..0c9299c8b0e1
--- /dev/null
+++ b/MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.c
@@ -0,0 +1,396 @@
+/** @file -- VariablePolicyHelperLib.c

+This library contains helper functions for marshalling and registering

+new policies with the VariablePolicy infrastructure.

+

+This library is currently written against VariablePolicy revision 0x0001.

+

+Copyright (c) Microsoft Corporation.

+SPDX-License-Identifier: BSD-2-Clause-Patent

+

+**/

+

+#include 

+

+#include 

+#include 

+#include 

+#include 

+

+#include 

+

+/**

+  This internal helper function populates the header structure,

+  all common fields, and takes care of fix-ups.

+

+  NOTE: Only use this internally. Assumes correctly-sized buffers.

+

+  @param[out] EntPtr  Pointer to the buffer to be populated.

+  @param[in]  Namespace   Pointer to an EFI_GUID for the target variable 
namespace that this policy will protect.

+  @param[in]  MinSize MinSize for the VariablePolicy.

+  @param[in]  MaxSize MaxSize for the VariablePolicy.

+  @param[in]  AttributesMustHaveAttributesMustHave for the VariablePolicy.

+  @param[in]  AttributesCantHaveAttributesCantHave for the VariablePolicy.

+  @param[in]  LockPolicyTypeLockPolicyType for the VariablePolicy.

+

+**/

+STATIC

+VOID

+PopulateCommonData (

+  OUT VARIABLE_POLICY_ENTRY   *EntPtr,

+  IN CONST  EFI_GUID  *Namespace,

+  INUINT32MinSize,

+  INUINT32MaxSize,

+  INUINT32AttributesMustHave,

+  INUINT32AttributesCantHave,

+  INUINT8 LockPolicyType

+  )

+{

+  EntPtr->Version = VARIABLE_POLICY_ENTRY_REVISION;

+  CopyGuid( >Namespace, Namespace );

+  EntPtr->MinSize = MinSize;

+  EntPtr->MaxSize = MaxSize;

+  EntPtr->AttributesMustHave  = AttributesMustHave;

+  EntPtr->AttributesCantHave  = AttributesCantHave;

+  EntPtr->LockPolicyType  = LockPolicyType;

+

+  // NOTE: As a heler, fix up MaxSize for compatibility with the old model.

+  if (EntPtr->MaxSize == 0) {

+EntPtr->MaxSize = VARIABLE_POLICY_NO_MAX_SIZE;

+  }

+

+  return;

+}

+

+

+/**

+  This helper function will allocate and populate a new VariablePolicy

+  structure for a policy that does not contain any sub-structures (such as

+  VARIABLE_LOCK_ON_VAR_STATE_POLICY).

+

+  NOTE: Caller will need to free structure once finished.

+

+  @param[in]  Namespace   Pointer to an EFI_GUID for the target variable 
namespace that this policy will protect.

+  @param[in]  Name[Optional] If provided, a pointer to the CHAR16 
array for the target variable name.

+  Otherwise, will create a policy that targets an 
entire namespace.

+  @param[in]  MinSize MinSize for the VariablePolicy.

+  @param[in]  MaxSize MaxSize for the VariablePolicy.

+  @param[in]  AttributesMustHaveAttributesMustHave for the VariablePolicy.

+  @param[in]  AttributesCantHaveAttributesCantHave for the VariablePolicy.

+  @param[in]  LockPolicyTypeLockPolicyType for the VariablePolicy.

+  @param[out] NewEntryIf 

Re: [EXTERNAL] [edk2-devel] [PATCH v5 01/14] MdeModulePkg: Define the VariablePolicy protocol interface

[Bret Barkelew via groups.io]

Bump. This specific patch needs Reviews.


- Bret


From: devel@edk2.groups.io  on behalf of Bret Barkelew 
via groups.io 
Sent: Tuesday, June 2, 2020 11:57 PM
To: devel@edk2.groups.io 
Cc: Jian J Wang ; Hao A Wu ; 
liming.gao 
Subject: [EXTERNAL] [edk2-devel] [PATCH v5 01/14] MdeModulePkg: Define the 
VariablePolicy protocol interface

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D2522data=02%7C01%7CBret.Barkelew%40microsoft.com%7Ccaae5a1fbb05498c984f08d807a3dae0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637267747624441639sdata=zb9OOX6YpaObdlezhQmsj5zCSd1JS6ay6DVhGkiJRdU%3Dreserved=0

VariablePolicy is an updated interface to
replace VarLock and VarCheckProtocol.

Add the VariablePolicy protocol interface
header and add to the MdeModulePkg.dec file.

Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Liming Gao 
Cc: Bret Barkelew 
Signed-off-by: Bret Barkelew 
---
 MdeModulePkg/Include/Protocol/VariablePolicy.h | 157 
 MdeModulePkg/MdeModulePkg.dec  |  14 +-
 MdeModulePkg/MdeModulePkg.uni  |   7 +
 3 files changed, 177 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Include/Protocol/VariablePolicy.h 
b/MdeModulePkg/Include/Protocol/VariablePolicy.h
new file mode 100644
index ..8226c187a77b
--- /dev/null
+++ b/MdeModulePkg/Include/Protocol/VariablePolicy.h
@@ -0,0 +1,157 @@
+/** @file -- VariablePolicy.h

+

+This protocol allows communication with Variable Policy Engine.

+

+Copyright (c) Microsoft Corporation.

+SPDX-License-Identifier: BSD-2-Clause-Patent

+**/

+

+#ifndef __EDKII_VARIABLE_POLICY_PROTOCOL__

+#define __EDKII_VARIABLE_POLICY_PROTOCOL__

+

+#define EDKII_VARIABLE_POLICY_PROTOCOL_REVISION   0x0001

+

+#define EDKII_VARIABLE_POLICY_PROTOCOL_GUID \

+  { \

+0x81D1675C, 0x86F6, 0x48DF, { 0xBD, 0x95, 0x9A, 0x6E, 0x4F, 0x09, 0x25, 
0xC3 } \

+  }

+

+#define VARIABLE_POLICY_ENTRY_REVISION  0x0001

+

+#pragma pack(push, 1)

+typedef struct {

+  UINT32   Version;

+  UINT16   Size;

+  UINT16   OffsetToName;

+  EFI_GUID Namespace;

+  UINT32   MinSize;

+  UINT32   MaxSize;

+  UINT32   AttributesMustHave;

+  UINT32   AttributesCantHave;

+  UINT8LockPolicyType;

+  UINT8Padding[3];

+  // UINT8LockPolicy[]; // Variable Length Field

+  // CHAR16   Name[]// Variable Length Field

+} VARIABLE_POLICY_ENTRY;

+

+#define VARIABLE_POLICY_NO_MIN_SIZE 0

+#define VARIABLE_POLICY_NO_MAX_SIZE MAX_UINT32

+#define VARIABLE_POLICY_NO_MUST_ATTR0

+#define VARIABLE_POLICY_NO_CANT_ATTR0

+

+#define VARIABLE_POLICY_TYPE_NO_LOCK0

+#define VARIABLE_POLICY_TYPE_LOCK_NOW   1

+#define VARIABLE_POLICY_TYPE_LOCK_ON_CREATE 2

+#define VARIABLE_POLICY_TYPE_LOCK_ON_VAR_STATE  3

+

+typedef struct {

+  EFI_GUID Namespace;

+  UINT8Value;

+  UINT8Padding;

+  // CHAR16   Name[];   // Variable Length Field

+} VARIABLE_LOCK_ON_VAR_STATE_POLICY;

+#pragma pack(pop)

+

+/**

+  This API function disables the variable policy enforcement. If it's

+  already been called once, will return EFI_ALREADY_STARTED.

+

+  @retval EFI_SUCCESS

+  @retval EFI_ALREADY_STARTED   Has already been called once this boot.

+  @retval EFI_WRITE_PROTECTED   Interface has been locked until reboot.

+  @retval EFI_WRITE_PROTECTED   Interface option is disabled by platform 
PCD.

+

+**/

+typedef

+EFI_STATUS

+(EFIAPI *DISABLE_VARIABLE_POLICY)(

+  VOID

+  );

+

+/**

+  This API function returns whether or not the policy engine is

+  currently being enforced.

+

+  @param[out]   State   Pointer to a return value for whether the policy 
enforcement

+is currently enabled.

+

+  @retval EFI_SUCCESS

+  @retval OthersAn error has prevented this command from 
completing.

+

+**/

+typedef

+EFI_STATUS

+(EFIAPI *IS_VARIABLE_POLICY_ENABLED)(

+  OUT BOOLEAN *State

+  );

+

+/**

+  This API function validates and registers a new policy with

+  the policy enforcement engine.

+

+  @param[in]  NewPolicy Pointer to the incoming policy structure.

+

+  @retval EFI_SUCCESS

+  @retval EFI_INVALID_PARAMETER   NewPolicy is NULL or is internally 
inconsistent.

+  @retval EFI_ALREADY_STARTED An identical matching policy already 
exists.

+  @retval EFI_WRITE_PROTECTED The interface has been locked until the 
next reboot.

+  @retval EFI_ABORTED A calculation error has prevented this 
function from completing.

+  @retval EFI_OUT_OF_RESOURCESCannot grow the table to hold any more 
policies.

+

+**/

+typedef

+EFI_STATUS

+(EFIAPI *REGISTER_VARIABLE_POLICY)(

+  IN CONST VARIABLE_POLICY_ENTRY  *PolicyEntry

+  );

+

+/**

+  This API function will dump the entire contents of the variable 

Re: [edk2-devel] [PATCH v4 1/4] MdeModulePkg.dec: Change PCDs for status code.

[Wang, Jian J]

Hi Ming,

I'd suggest to keep the type of FeatureFlag for these two PCDs.
So those platforms, which don't want to use dynamic type, have
no need to update it's dsc file.

Regards,
Jian

> -Original Message-
> From: Tan, Ming 
> Sent: Wednesday, June 10, 2020 10:57 AM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J ; Wu, Hao A 
> Subject: [PATCH v4 1/4] MdeModulePkg.dec: Change PCDs for status code.
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2786
> 
> In order to support enable/disable report status code through memory
> or serial dynamic, change the following PCDs from [PcdsFeatureFlag] to
> [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]:
>   PcdStatusCodeUseSerial
>   PcdStatusCodeUseMemory
> The original plaforms can use PcdsFixedAtBuild in .dsc files to save size.
> 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Signed-off-by: Ming Tan 
> ---
> V4: No change for this 1/4 patch, just modify the 2-4/4 patchs.
> V3: Split one patch to several patchs, each Pkg has one patch.
> V2: Change the new type from [PcdsDynamic] to [PcdsFixedAtBuild,
> PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
> And set to PcdsFixedAtBuild in the original platform .dsc files.
> 
>  MdeModulePkg/MdeModulePkg.dec | 26 +--
>  .../Pei/StatusCodeHandlerPei.c|  6 ++---
>  .../Pei/StatusCodeHandlerPei.inf  |  6 ++---
>  .../RuntimeDxe/StatusCodeHandlerRuntimeDxe.c  | 16 ++--
>  .../StatusCodeHandlerRuntimeDxe.inf   |  6 ++---
>  .../Smm/StatusCodeHandlerSmm.c| 10 +++
>  .../Smm/StatusCodeHandlerSmm.inf  |  6 ++---
>  7 files changed, 35 insertions(+), 41 deletions(-)
> 
> diff --git a/MdeModulePkg/MdeModulePkg.dec
> b/MdeModulePkg/MdeModulePkg.dec
> index 4f44af694862..843e963ad34b 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -760,19 +760,6 @@ [PcdsFeatureFlag]
># @Prompt Enable PCI bridge IO alignment probe.
> 
> gEfiMdeModulePkgTokenSpaceGuid.PcdPciBridgeIoAlignmentProbe|FALSE|BOO
> LEAN|0x0001004e
> 
> -  ## Indicates if StatusCode is reported via Serial port.
> -  #   TRUE  - Reports StatusCode via Serial port.
> -  #   FALSE - Does not report StatusCode via Serial port.
> -  # @Prompt Enable StatusCode via Serial port.
> -
> gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|TRUE|BOOLEAN|
> 0x00010022
> -
> -  ## Indicates if StatusCode is stored in memory.
> -  #  The memory is boot time memory in PEI Phase and is runtime memory in
> DXE Phase.
> -  #   TRUE  - Stores StatusCode in memory.
> -  #   FALSE - Does not store StatusCode in memory.
> -  # @Prompt Enable StatusCode via memory.
> -
> gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseMemory|FALSE|BOOLEA
> N|0x00010023
> -
>## Indicates if PEI phase StatusCode will be replayed in DXE phase.
>#   TRUE  - Replays PEI phase StatusCode in DXE phased.
>#   FALSE - Does not replay PEI phase StatusCode in DXE phase.
> @@ -2001,6 +1988,19 @@ [PcdsFixedAtBuild, PcdsPatchableInModule,
> PcdsDynamic, PcdsDynamicEx]
># @Prompt TCG Platform Firmware Profile revision.
> 
> gEfiMdeModulePkgTokenSpaceGuid.PcdTcgPfpMeasurementRevision|0|UINT3
> 2|0x00010077
> 
> +  ## Indicates if StatusCode is reported via Serial port.
> +  #   TRUE  - Reports StatusCode via Serial port.
> +  #   FALSE - Does not report StatusCode via Serial port.
> +  # @Prompt Enable StatusCode via Serial port.
> +
> gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|TRUE|BOOLEAN|
> 0x00010022
> +
> +  ## Indicates if StatusCode is stored in memory.
> +  #  The memory is boot time memory in PEI Phase and is runtime memory in
> DXE Phase.
> +  #   TRUE  - Stores StatusCode in memory.
> +  #   FALSE - Does not store StatusCode in memory.
> +  # @Prompt Enable StatusCode via memory.
> +
> gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseMemory|FALSE|BOOLEA
> N|0x00010023
> +
>  [PcdsPatchableInModule]
>## Specify memory size with page number for PEI code when
>#  Loading Module at Fixed Address feature is enabled.
> diff --git
> a/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.c
> b/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.c
> index 1b07f92f3ce8..9b2ea4ee84d9 100644
> --- a/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.c
> +++
> b/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.c
> @@ -2,7 +2,7 @@
>Report Status Code Handler PEIM which produces general handlers and hook
> them
>onto the PEI status code router.
> 
> -  Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
> +  Copyright (c) 2009 - 2020, Intel Corporation. All rights reserved.
>SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> @@ -45,13 +45,13 @@ StatusCodeHandlerPeiEntry (
>// If enable UseSerial, then initialize serial port.
>// if enable UseMemory, then initialize memory status code worker.
>//
> -  if 

Re: [edk2-devel] [PATCH] OvmfPkg: End timer interrupt later to avoid stack overflow under load

[Igor Druzhinin]

On 16/06/2020 19:42, Laszlo Ersek wrote
> If I understand correctly, TimerInterruptHandler()
> [OvmfPkg/8254TimerDxe/Timer.c] currently does the following:
> 
> - RaiseTPL (TPL_HIGH_LEVEL) --> mask interrupts from being delivered
> 
> - mLegacy8259->EndOfInterrupt() --> permit the PIC to generate further
> interrupts (= make them pending)
> 
> - RestoreTPL() --> unmask interrupts (allow delivery)
> 
> RestoreTPL() is always expected to invoke handlers (on its own stack)
> that have just been unmasked, so that behavior is not unexpected, in my
> opinion.

Yes, this is where I'd like to have a confirmation - opening a window
for uncontrollable number of nested interrupts with a small stack
looks dangerous.

> What seems unexpected is the queueing of a huge number of timer
> interrupts. I would think a timer interrupt is either pending or not
> pending (i.e. if it's already pending, then the next generated interrupt
> is coalesced, not queued). While there would still be a window between
> the EOI and the unmasking, I don't think it would normally allow for a
> *huge* number of queued interrupts (and consequently a stack overflow).

It's not a window between EOI and unmasking but the very fact vCPU is 
descheduled for a considerable amount of time that causes backlog of
timer interrupts to build up. This is Xen default behavior and is
configurable (there are several timer modes including coalescing
you mention). That is done for compatibility with some guests basing
time accounting on the number of periodic interrupts they receive.

> So I basically see the root of the problem in the interrupts being
> queued rather than coalesced. I'm pretty unfamiliar with this x86 area
> (= the 8259 PIC in general), but the following wiki article seems to
> agree with my suspicion:
> 
> https://wiki.osdev.org/8259_PIC#How_does_the_8259_PIC_chip_work.3F
> 
> [...] and whether there's an interrupt already pending. If the
> channel is unmasked and there's no interrupt pending, the PIC will
> raise the interrupt line [...]
> 
> Can we say that the interrupt queueing (as opposed to coalescing) is a
> Xen issue?

I can admit that the whole issue might be Xen specific if that form
of timer mode is not used in QEMU-KVM. What mode is typical there
then? We might consider switching Xen to a different mode if so, as I believe
those guests are not in support for many years.

> (Hmmm... maybe the hypervisor *has* to queue the timer interrupts,
> otherwise some of them would simply be lost, and the guest would lose
> track of time.)
> 
> Either way, I'm not sure what the best approach is. This driver was
> moved under OvmfPkg from PcAtChipsetPkg in commit 1a3ffdff82e6
> ("OvmfPkg: Copy 8254TimerDxe driver from PcAtChipsetPkg", 2019-04-11).
> HpetTimerDxe also lives under PcAtChipsetPkg.
> 
> So I think I'll have to rely on the expertise of Ray here (CC'd).

Also note that since the issue might be Xen specific we might want to
try to fix it in XenTimer only - I modified 8254Timer due to the
fact Xen is still present in general config (but that should soon
go away).

> Also, I recall a recent-ish QEMU commit that seems vaguely related
> (i.e., to timer interrupt coalescing -- see 7a3e29b12f5a, "mc146818rtc:
> fix timer interrupt reinjection again", 2019-11-19), so I'm CC'ing Paolo
> too.

Hmm that looks more like a RTC implementation specific issue.

> Some more comments / questions below:
> 
>>
>> diff --git a/OvmfPkg/8254TimerDxe/Timer.c b/OvmfPkg/8254TimerDxe/Timer.c
>> index 67e22f5..fd1691b 100644
>> --- a/OvmfPkg/8254TimerDxe/Timer.c
>> +++ b/OvmfPkg/8254TimerDxe/Timer.c
>> @@ -79,8 +79,6 @@ TimerInterruptHandler (
>>  
>>OriginalTPL = gBS->RaiseTPL (TPL_HIGH_LEVEL);
>>  
>> -  mLegacy8259->EndOfInterrupt (mLegacy8259, Efi8259Irq0);
>> -
>>if (mTimerNotifyFunction != NULL) {
>>  //
>>  // @bug : This does not handle missed timer interrupts
>> @@ -89,6 +87,9 @@ TimerInterruptHandler (
>>}
>>  
>>gBS->RestoreTPL (OriginalTPL);
>> +
>> +  DisableInterrupts ();
>> +  mLegacy8259->EndOfInterrupt (mLegacy8259, Efi8259Irq0);
>>  }
> 
> So this briefly (temporarily) unmasks interrupt delivery (between
> RestoreTPL() and DisableInterrupts()) while the PIC is still blocked
> from generating more, and then unblocks the PIC.
> 
> It looks plausible for preventing the unbounded recursion per se, but
> why is it safe to leave the function with interrupts disabled? Before
> the patch, that didn't use to be the case.

Quickly looking through the code it appears to me the first thing that
caller does after interrupt handler - it clears interrupt flag to make
sure those disabled. So I don't see any assumption that interrupts should
be enabled on exiting. But I might not know about all of the possible
combinations here.

Igor

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

View/Reply Online (#61376): https://edk2.groups.io/g/devel/message/61376
Mute This Topic: 

Re: [edk2-devel] [PATCH V2 2/2] UefiPayloadPkg/Pci: Use the PCIE Base Addr stored in AcpiBoardInfo HOB

[Ni, Ray]

Maurice,

> -Original Message-
> From: Ma, Maurice 
> Sent: Monday, June 8, 2020 11:05 PM
> To: Ni, Ray ; devel@edk2.groups.io
> Cc: Dong, Guo ; You, Benjamin 
> Subject: RE: [PATCH V2 2/2] UefiPayloadPkg/Pci: Use the PCIE Base Addr stored 
> in AcpiBoardInfo HOB
> 
> Hi, Ray,
> 
> I noticed in this V2 patch, you removed the following line from the DSC file.
> gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|$(PCIE_BASE)
> It will make the PcdPciExpressBaseAddress become PcdsFixedAtBuild type 
> instead of
> PcdsDynamicDefault.   Is this your intention ?

Yes. I want all modules in the payload access the PCI configure space in two 
ways:
1.  Through PciRootBridgeIo/PciIo, this calling stack depends on the 
AcpiBoardInfo HOB because PciSegmentLibSegmentInfo is used.
2. Through PciCf8Lib.

In both ways the PCIE base address are configurable.

But if the concern is about performance impact of using CF8/CFC, I can keep the 
PciExpressLib access path.

> 
> Also this V2 patch forced PcdLib class instance to be BasePciLibCf8.  It 
> means all PCI configuration space access will use I/O
> port access.  We prefer using BasePciSegmentLibPci.   I think we should keep 
> the original code for this so that it is
> configurable.
> 
> Also can we sync up DSC changes into UefiPayloadPkgIa32.dsc as well ?

Sure. I will apply the similar change to Ia32.dsc after I understand how to 
change the X64.dsc.

> 
> Thanks
> Maurice
> > -Original Message-
> > From: Ni, Ray 
> > Sent: Wednesday, June 3, 2020 20:27
> > To: devel@edk2.groups.io
> > Cc: Ma, Maurice ; Dong, Guo ;
> > You, Benjamin 
> > Subject: [PATCH V2 2/2] UefiPayloadPkg/Pci: Use the PCIE Base Addr stored in
> > AcpiBoardInfo HOB
> >
> > Today's UefiPayloadPkg always uses 0xE000 as the PCIE base address and
> > ignores the value set in AcpiBoardInfo HOB created by the boot loader. This
> > makes the payload binary cannot work in environment where the PCIE base
> > address set by boot loader doesn't equal to 0xE000.
> >
> > The patch enhances UefiPayloadPkg so that the PCIE base address set by boot
> > loader in the AcpiBoardInfo HOB is used.
> >
> > Signed-off-by: Ray Ni 
> > Cc: Maurice Ma 
> > Cc: Guo Dong 
> > Cc: Benjamin You 
> > ---
> >  .../PciSegmentInfoLibAcpiBoardInfo.c  | 59 +++
> >  .../PciSegmentInfoLibAcpiBoardInfo.inf| 36 +++
> >  UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc  | 16 +
> >  3 files changed, 98 insertions(+), 13 deletions(-)  create mode 100644
> > UefiPayloadPkg/Library/PciSegmentInfoLibAcpiBoardInfo/PciSegmentInfoLibAc
> > piBoardInfo.c
> >  create mode 100644
> > UefiPayloadPkg/Library/PciSegmentInfoLibAcpiBoardInfo/PciSegmentInfoLibAc
> > piBoardInfo.inf
> >
> > diff --git
> > a/UefiPayloadPkg/Library/PciSegmentInfoLibAcpiBoardInfo/PciSegmentInfoLib
> > AcpiBoardInfo.c
> > b/UefiPayloadPkg/Library/PciSegmentInfoLibAcpiBoardInfo/PciSegmentInfoLib
> > AcpiBoardInfo.c
> > new file mode 100644
> > index 00..d37c91cc9f
> > --- /dev/null
> > +++ b/UefiPayloadPkg/Library/PciSegmentInfoLibAcpiBoardInfo/PciSegmentIn
> > +++ foLibAcpiBoardInfo.c
> > @@ -0,0 +1,59 @@
> > +/** @file+  PCI Segment Information Library that returns one segment
> > whose+  segment base address is retrieved from AcpiBoardInfo HOB.++
> > Copyright (c) 2020, Intel Corporation. All rights reserved.+  
> > SPDX-License-
> > Identifier: BSD-2-Clause-Patent++**/++#include +#include
> > ++#include +#include
> > +#include ++STATIC
> > PCI_SEGMENT_INFO mPciSegment0 = {+  0,  // Segment number+  0,  // To be
> > fixed later+  0,  // Start bus number+  255 // End bus number+};++/**+  
> > Return
> > an array of PCI_SEGMENT_INFO holding the segment information.++  Note: The
> > returned array/buffer is owned by callee.++  @param  Count  Return the count
> > of segments.++  @retval A callee owned array holding the segment
> > information.+**/+PCI_SEGMENT_INFO *+EFIAPI+GetPciSegmentInfo (+  UINTN
> > *Count+  )+{+  EFI_HOB_GUID_TYPE  *GuidHob;+  ACPI_BOARD_INFO
> > *AcpiBoardInfo;++  ASSERT (Count != NULL);+  if (Count == NULL) {+return
> > NULL;+  }++  if (mPciSegment0.BaseAddress == 0) {+//+// Find the 
> > acpi
> > board information guid hob+//+GuidHob = GetFirstGuidHob
> > ();+ASSERT (GuidHob != NULL);++AcpiBoardInfo 
> > =
> > (ACPI_BOARD_INFO *) GET_GUID_HOB_DATA (GuidHob);+
> > mPciSegment0.BaseAddress = AcpiBoardInfo->PcieBaseAddress;+  }+  *Count =
> > 1;+  return +}diff --git
> > a/UefiPayloadPkg/Library/PciSegmentInfoLibAcpiBoardInfo/PciSegmentInfoLib
> > AcpiBoardInfo.inf
> > b/UefiPayloadPkg/Library/PciSegmentInfoLibAcpiBoardInfo/PciSegmentInfoLib
> > AcpiBoardInfo.inf
> > new file mode 100644
> > index 00..ec4dbaaa55
> > --- /dev/null
> > +++ b/UefiPayloadPkg/Library/PciSegmentInfoLibAcpiBoardInfo/PciSegmentIn
> > +++ foLibAcpiBoardInfo.inf
> > @@ -0,0 +1,36 @@
> > +## @file+#   PCI Segment Information Library that returns one segment
> > whose+#