date:20190423

After commit 57df17fe26, some static check reports suspicous NULL pointer
deference at line:

  Entry->MachineType = Entry->Emulator->MachineType;
   ^^^

within function PeCoffEmuProtocolNotify().

However, 'Entry->Emulator' is guaranteed to have a non-NULL value when
previous call to the CoreHandleProtocol() returns EFI_SUCCESS.

This commit will re-write the return status check for CoreHandleProtocol()
to add explicit NULL pointer check for protocol instance pointer.

Cc: Ard Biesheuvel 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Jian J Wang 
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Core/Dxe/Image/Image.c | 23 
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Image/Image.c 
b/MdeModulePkg/Core/Dxe/Image/Image.c
index 08306a73fd..de5b8bed27 100644
--- a/MdeModulePkg/Core/Dxe/Image/Image.c
+++ b/MdeModulePkg/Core/Dxe/Image/Image.c
@@ -134,12 +134,14 @@ PeCoffEmuProtocolNotify (
   IN  VOID*Context
   )
 {
-  EFI_STATUS  Status;
-  UINTN   BufferSize;
-  EFI_HANDLE  EmuHandle;
-  EMULATOR_ENTRY  *Entry;
+  EFI_STATUSStatus;
+  UINTN BufferSize;
+  EFI_HANDLEEmuHandle;
+  EDKII_PECOFF_IMAGE_EMULATOR_PROTOCOL  *Emulator;
+  EMULATOR_ENTRY*Entry;
 
   EmuHandle = NULL;
+  Emulator  = NULL;
 
   while (TRUE) {
 BufferSize = sizeof (EmuHandle);
@@ -157,16 +159,19 @@ PeCoffEmuProtocolNotify (
   return;
 }
 
-Entry = AllocateZeroPool (sizeof (*Entry));
-ASSERT (Entry != NULL);
-
 Status = CoreHandleProtocol (
EmuHandle,
,
-   (VOID **)>Emulator
+   (VOID **)
);
-ASSERT_EFI_ERROR (Status);
+if (EFI_ERROR (Status) || Emulator == NULL) {
+  continue;
+}
+
+Entry = AllocateZeroPool (sizeof (*Entry));
+ASSERT (Entry != NULL);
 
+Entry->Emulator= Emulator;
 Entry->MachineType = Entry->Emulator->MachineType;
 
 InsertTailList (, >Link);
-- 
2.12.0.windows.1


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

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

[edk2-devel] [PATCH V2 4/8] IntelFrameworkModulePkg: Decrease the name collisions

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

Add a 'static' descriptor to the global variables that only
used in a single file to minimize the name collisions.
This is only for the varable named 'mExitBootServicesEvent'.

Cc: Laszlo Ersek 
Cc: Liming Gao 
Cc: Dandan Bi 
Signed-off-by: Zhichao Gao 
---
 .../DatahubStatusCodeHandlerDxe/DatahubStatusCodeHandlerDxe.c   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/IntelFrameworkModulePkg/Universal/StatusCode/DatahubStatusCodeHandlerDxe/DatahubStatusCodeHandlerDxe.c
 
b/IntelFrameworkModulePkg/Universal/StatusCode/DatahubStatusCodeHandlerDxe/DatahubStatusCodeHandlerDxe.c
index 0f9185144d..5399bc7123 100644
--- 
a/IntelFrameworkModulePkg/Universal/StatusCode/DatahubStatusCodeHandlerDxe/DatahubStatusCodeHandlerDxe.c
+++ 
b/IntelFrameworkModulePkg/Universal/StatusCode/DatahubStatusCodeHandlerDxe/DatahubStatusCodeHandlerDxe.c
@@ -9,7 +9,7 @@
 
 #include "DatahubStatusCodeHandlerDxe.h"
 
-EFI_EVENT mExitBootServicesEvent = NULL;
+static EFI_EVENT  mExitBootServicesEvent = NULL;
 EFI_RSC_HANDLER_PROTOCOL  *mRscHandlerProtocol   = NULL;
 
 /**
-- 
2.21.0.windows.1


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

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

[edk2-devel] [PATCH V2 2/8] MdePkg/UefiDebugLibDebugPortProtocol: Decrease the name collisions

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

Add a 'static' descriptor to the global variables that only
used in a single file to minimize the name collisions.
This is only for the varable named 'mExitBootServicesEvent'.

Cc: Laszlo Ersek 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Dandan Bi 
Signed-off-by: Zhichao Gao 
---
 .../UefiDebugLibDebugPortProtocol/DebugLibConstructor.c   | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdePkg/Library/UefiDebugLibDebugPortProtocol/DebugLibConstructor.c 
b/MdePkg/Library/UefiDebugLibDebugPortProtocol/DebugLibConstructor.c
index ed2cb70c21..5d108288c9 100644
--- a/MdePkg/Library/UefiDebugLibDebugPortProtocol/DebugLibConstructor.c
+++ b/MdePkg/Library/UefiDebugLibDebugPortProtocol/DebugLibConstructor.c
@@ -15,9 +15,9 @@
 //
 // BOOLEAN value to indicate if it is at the post ExitBootServices pahse
 //
-BOOLEAN mPostEBS = FALSE;
+BOOLEAN   mPostEBS = FALSE;
 
-EFI_EVENT   mExitBootServicesEvent;
+static EFI_EVENT  mExitBootServicesEvent;
 
 //
 // Pointer to SystemTable
-- 
2.21.0.windows.1


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

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

[edk2-devel] [PATCH V2 8/8] MdeModulePkg/StatusCodeHandlerRuntimeDxe: Decrease the name collisions

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

Add a 'static' descriptor to the global variables that only
used in a single file to minimize the name collisions.
This is only for the varable named 'mExitBootServicesEvent'.

Cc: Laszlo Ersek 
Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ray Ni 
Cc: Star Zeng 
Cc: Liming Gao 
Cc: Dandan Bi 
Signed-off-by: Zhichao Gao 
---
 .../StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.c  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.c
 
b/MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.c
index 0d327d40e3..e22dae5736 100644
--- 
a/MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.c
+++ 
b/MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.c
@@ -10,7 +10,7 @@
 #include "StatusCodeHandlerRuntimeDxe.h"
 
 EFI_EVENT mVirtualAddressChangeEvent = NULL;
-EFI_EVENT mExitBootServicesEvent = NULL;
+static EFI_EVENT  mExitBootServicesEvent = NULL;
 EFI_RSC_HANDLER_PROTOCOL  *mRscHandlerProtocol   = NULL;
 
 /**
-- 
2.21.0.windows.1


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

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

[edk2-devel] [PATCH V2 6/8] IntelFsp2WrapperPkg/FspWrapperNotifyDxe: Decrease the name collisions

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

Add a 'static' descriptor to the global variables that only
used in a single file to minimize the name collisions.
This is only for the varable named 'mExitBootServicesEvent'.

Cc: Laszlo Ersek 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Star Zeng 
Cc: Liming Gao 
Cc: Dandan Bi 
Signed-off-by: Zhichao Gao 
---
 IntelFsp2WrapperPkg/FspWrapperNotifyDxe/FspWrapperNotifyDxe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/IntelFsp2WrapperPkg/FspWrapperNotifyDxe/FspWrapperNotifyDxe.c 
b/IntelFsp2WrapperPkg/FspWrapperNotifyDxe/FspWrapperNotifyDxe.c
index fe344a5327..459acc694b 100644
--- a/IntelFsp2WrapperPkg/FspWrapperNotifyDxe/FspWrapperNotifyDxe.c
+++ b/IntelFsp2WrapperPkg/FspWrapperNotifyDxe/FspWrapperNotifyDxe.c
@@ -39,7 +39,7 @@ extern EFI_GUID gAddPerfRecordProtocolGuid;
 extern EFI_GUID gFspHobGuid;
 extern EFI_GUID gFspApiPerformanceGuid;
 
-EFI_EVENT mExitBootServicesEvent = NULL;
+static EFI_EVENT mExitBootServicesEvent = NULL;
 
 /**
   Relocate this image under 4G memory.
-- 
2.21.0.windows.1


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

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

[edk2-devel] [PATCH V2 7/8] IntelFrameworkModulePkg: Decrease the name collisions

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

Add a 'static' descriptor to the global variables that only
used in a single file to minimize the name collisions.
This is only for the varable named 'mExitBootServicesEvent'.

Cc: Laszlo Ersek 
Cc: Liming Gao 
Cc: Dandan Bi 
Signed-off-by: Zhichao Gao 
---
 .../SmmRuntimeDxeSupport.c  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/IntelFrameworkModulePkg/Library/SmmRuntimeDxeReportStatusCodeLibFramework/SmmRuntimeDxeSupport.c
 
b/IntelFrameworkModulePkg/Library/SmmRuntimeDxeReportStatusCodeLibFramework/SmmRuntimeDxeSupport.c
index 4a6137a509..e5db127b8a 100644
--- 
a/IntelFrameworkModulePkg/Library/SmmRuntimeDxeReportStatusCodeLibFramework/SmmRuntimeDxeSupport.c
+++ 
b/IntelFrameworkModulePkg/Library/SmmRuntimeDxeReportStatusCodeLibFramework/SmmRuntimeDxeSupport.c
@@ -9,7 +9,7 @@
 #include "ReportStatusCodeLibInternal.h"
 
 EFI_EVENT mVirtualAddressChangeEvent;
-EFI_EVENT mExitBootServicesEvent;
+static EFI_EVENT  mExitBootServicesEvent;
 EFI_STATUS_CODE_DATA  *mStatusCodeData;
 BOOLEAN   mInSmm;
 EFI_SMM_BASE_PROTOCOL *mSmmBase;
-- 
2.21.0.windows.1


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

View/Reply Online (#39452): https://edk2.groups.io/g/devel/message/39452
Mute This Topic: https://groups.io/mt/31318892/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/8] MdePkg/UefiDebugLibConOut: Decrease the name collisions

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

Add a 'static' descriptor to the global variables that only
used in a single file to minimize the name collisions.
This is only for the varable named 'mExitBootServicesEvent'.

Cc: Laszlo Ersek 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Dandan Bi 
Signed-off-by: Zhichao Gao 
---
 MdePkg/Library/UefiDebugLibConOut/DebugLibConstructor.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdePkg/Library/UefiDebugLibConOut/DebugLibConstructor.c 
b/MdePkg/Library/UefiDebugLibConOut/DebugLibConstructor.c
index d4fdfbab55..bb7b144569 100644
--- a/MdePkg/Library/UefiDebugLibConOut/DebugLibConstructor.c
+++ b/MdePkg/Library/UefiDebugLibConOut/DebugLibConstructor.c
@@ -15,9 +15,9 @@
 //
 // BOOLEAN value to indicate if it is at the post ExitBootServices pahse
 //
-BOOLEAN mPostEBS = FALSE;
+BOOLEAN   mPostEBS = FALSE;
 
-EFI_EVENT   mExitBootServicesEvent;
+static EFI_EVENT  mExitBootServicesEvent;
 
 //
 // Pointer to SystemTable
-- 
2.21.0.windows.1


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

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

[edk2-devel] [PATCH V2 5/8] MdeModulePkg/FirmwarePerformanceDxe: Decrease the name collisions

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

Add a 'static' descriptor to the global variables that only
used in a single file to minimize the name collisions.
This is only for the varable named 'mExitBootServicesEvent'.

Cc: Laszlo Ersek 
Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ray Ni 
Cc: Star Zeng 
Cc: Liming Gao 
Cc: Dandan Bi 
Signed-off-by: Zhichao Gao 
---
 .../FirmwarePerformanceDataTableDxe/FirmwarePerformanceDxe.c| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/MdeModulePkg/Universal/Acpi/FirmwarePerformanceDataTableDxe/FirmwarePerformanceDxe.c
 
b/MdeModulePkg/Universal/Acpi/FirmwarePerformanceDataTableDxe/FirmwarePerformanceDxe.c
index 9713048f1f..85ca1e8d11 100644
--- 
a/MdeModulePkg/Universal/Acpi/FirmwarePerformanceDataTableDxe/FirmwarePerformanceDxe.c
+++ 
b/MdeModulePkg/Universal/Acpi/FirmwarePerformanceDataTableDxe/FirmwarePerformanceDxe.c
@@ -40,7 +40,7 @@ EFI_RSC_HANDLER_PROTOCOL*mRscHandlerProtocol = NULL;
 BOOLEAN mLockBoxReady = FALSE;
 EFI_EVENT   mReadyToBootEvent;
 EFI_EVENT   mLegacyBootEvent;
-EFI_EVENT   mExitBootServicesEvent;
+static EFI_EVENTmExitBootServicesEvent;
 UINTN   mFirmwarePerformanceTableTemplateKey  = 0;
 BOOLEAN mDxeCoreReportStatusCodeEnable = FALSE;
 
-- 
2.21.0.windows.1


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

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

Re: [edk2-devel] [PATCH 1/1] MdeModulePkg: BaseSerialPortLib16550: Add Mmio32 support

2019-04-23 Thread Michael D Kinney

One issue I see is using a FeatureFlag PCD.
These PCDs can only be TRUE or FALSE, so they can not be
extended later.  A FixedAtBuild PCD of type BOOL has the 
same issue.

It would be better to use a UINTx FixedAtBuild PCD, and 
define a bit or a value for 32-bit access.  That way, if
there is a device that requires 16-bit access, it can be
added in the same PCD.

Also, should the new PCD be limited to MMIO?  It could be
an access width PCD that could be applied to I/O or MMIO
Access.

Mike

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io]
> On Behalf Of Wu, Hao A
> Sent: Tuesday, April 23, 2019 8:20 PM
> To: Loh, Tien Hock ;
> devel@edk2.groups.io; thlo...@gmail.com
> Cc: Wang, Jian J 
> Subject: Re: [edk2-devel] [PATCH 1/1] MdeModulePkg:
> BaseSerialPortLib16550: Add Mmio32 support
> 
> > -Original Message-
> > From: Loh, Tien Hock
> > Sent: Wednesday, April 24, 2019 11:05 AM
> > To: devel@edk2.groups.io; thlo...@gmail.com
> > Cc: Loh, Tien Hock; Wang, Jian J; Wu, Hao A
> > Subject: [PATCH 1/1] MdeModulePkg:
> BaseSerialPortLib16550: Add Mmio32
> > support
> >
> > From: "Tien Hock, Loh" 
> >
> > Some busses doesn't allow 8 bit MMIO read/write, this
> adds support for
> > 32 bits read/write
> 
> Hello Tien Hock,
> 
> Your V2 patch seems to be based on your V1 patch.
> 
> Could you help to update the V2 patch to base on the tip
> of the edk2
> master branch? Thanks.
> 
> One easy way to do this is to squash the 2 commits into
> one.
> 
> 
> Some minor comments:
> A. Please help to update the copyright year for the
> files:
>BaseSerialPortLib16550.c
>BaseSerialPortLib16550.inf
> 
> B. For BaseSerialPortLib16550.inf, maybe:
> 
> gEfiMdeModulePkgTokenSpaceGuid.PcdSerialMmio32BitAccess
> ## SOMETIMES_CONSUMES
> 
> is more appropriate here.
> 
> Best Regards,
> Hao Wu
> 
> >
> > Signed-off-by: "Tien Hock, Loh"
> 
> > Cc: Jian J Wang 
> > Cc: Hao Wu 
> >
> > --
> > v2:
> > - Updates the Pcd name to PcdSerialMmio32BitAccess and
> access 32 bits
> > register if PcdSerialUseMmio and
> PcdSerialMmio32BitAccess is set
> > ---
> >  .../BaseSerialPortLib16550/BaseSerialPortLib16550.c
> | 16 
> >  .../BaseSerialPortLib16550/BaseSerialPortLib16550.inf
> |  2 +-
> >  MdeModulePkg/MdeModulePkg.dec
> | 12 +++-
> >  3 files changed, 16 insertions(+), 14 deletions(-)
> >
> > diff --git
> >
> a/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialP
> ortLib16550.c
> >
> b/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialP
> ortLib16550.c
> > index b242b23..f90fb55 100644
> > ---
> a/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialP
> ortLib16550.c
> > +++
> >
> b/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialP
> ortLib16550.c
> > @@ -76,10 +76,10 @@ SerialPortReadRegister (
> >UINTN  Offset
> >)
> >  {
> > -  if (PcdGetBool (PcdSerialUseMmio32)) {
> > -return (UINT8) MmioRead32 (Base + Offset *
> PcdGet32
> > (PcdSerialRegisterStride));
> > -  }
> > -  else if (PcdGetBool (PcdSerialUseMmio)) {
> > +  if (PcdGetBool (PcdSerialUseMmio)) {
> > +if (PcdGetBool (PcdSerialMmio32BitAccess)) {
> > +  return (UINT8) MmioRead32 (Base + Offset *
> PcdGet32
> > (PcdSerialRegisterStride));
> > +}
> >  return MmioRead8 (Base + Offset * PcdGet32
> (PcdSerialRegisterStride));
> >} else {
> >  return IoRead8 (Base + Offset * PcdGet32
> (PcdSerialRegisterStride));
> > @@ -106,10 +106,10 @@ SerialPortWriteRegister (
> >UINT8  Value
> >)
> >  {
> > -  if (PcdGetBool (PcdSerialUseMmio32)) {
> > -return MmioWrite32 (Base + Offset * PcdGet32
> (PcdSerialRegisterStride),
> > (UINT8)Value);
> > -  }
> > -  else if (PcdGetBool (PcdSerialUseMmio)) {
> > +  if (PcdGetBool (PcdSerialUseMmio)) {
> > +if (PcdGetBool (PcdSerialMmio32BitAccess)) {
> > +  return (UINT8) MmioWrite32 (Base + Offset *
> PcdGet32
> > (PcdSerialRegisterStride), (UINT8)Value);
> > +}
> >  return MmioWrite8 (Base + Offset * PcdGet32
> (PcdSerialRegisterStride),
> > Value);
> >} else {
> >  return IoWrite8 (Base + Offset * PcdGet32
> (PcdSerialRegisterStride), Value);
> > diff --git
> >
> a/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialP
> ortLib16550.inf
> >
> b/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialP
> ortLib16550.inf
> > index 575728a..c03d90d 100644
> > ---
> >
> a/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialP
> ortLib16550.inf
> > +++
> >
> b/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialP
> ortLib16550.inf
> > @@ -29,7 +29,7 @@
> >BaseSerialPortLib16550.c
> >
> >  [Pcd]
> > -  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialUseMmio32
> ##
> > CONSUMES
> > +
> gEfiMdeModulePkgTokenSpaceGuid.PcdSerialMmio32BitAccess
> ##
> > CONSUMES
> >gEfiMdeModulePkgTokenSpaceGuid.PcdSerialUseMmio
> ##
> > CONSUMES
> >
> gEfiMdeModulePkgTokenSpaceGuid.PcdSerialUseHardwareFlowCo
> ntrol  ##
> > CONSUMES
> >gEfiMdeModulePkgTokenSpaceGuid.PcdSerialDetectCable
> ##
> >

Re: [edk2-devel] [PATCH 1/1] MdeModulePkg: BaseSerialPortLib16550: Add Mmio32 support

> -Original Message-
> From: Loh, Tien Hock
> Sent: Wednesday, April 24, 2019 11:05 AM
> To: devel@edk2.groups.io; thlo...@gmail.com
> Cc: Loh, Tien Hock; Wang, Jian J; Wu, Hao A
> Subject: [PATCH 1/1] MdeModulePkg: BaseSerialPortLib16550: Add Mmio32
> support
> 
> From: "Tien Hock, Loh" 
> 
> Some busses doesn't allow 8 bit MMIO read/write, this adds support for
> 32 bits read/write

Hello Tien Hock,

Your V2 patch seems to be based on your V1 patch.

Could you help to update the V2 patch to base on the tip of the edk2
master branch? Thanks.

One easy way to do this is to squash the 2 commits into one.


Some minor comments:
A. Please help to update the copyright year for the files:
   BaseSerialPortLib16550.c
   BaseSerialPortLib16550.inf

B. For BaseSerialPortLib16550.inf, maybe:

gEfiMdeModulePkgTokenSpaceGuid.PcdSerialMmio32BitAccess ## 
SOMETIMES_CONSUMES

is more appropriate here.

Best Regards,
Hao Wu

> 
> Signed-off-by: "Tien Hock, Loh" 
> Cc: Jian J Wang 
> Cc: Hao Wu 
> 
> --
> v2:
> - Updates the Pcd name to PcdSerialMmio32BitAccess and access 32 bits
> register if PcdSerialUseMmio and PcdSerialMmio32BitAccess is set
> ---
>  .../BaseSerialPortLib16550/BaseSerialPortLib16550.c  | 16 
> 
>  .../BaseSerialPortLib16550/BaseSerialPortLib16550.inf|  2 +-
>  MdeModulePkg/MdeModulePkg.dec| 12 +++-
>  3 files changed, 16 insertions(+), 14 deletions(-)
> 
> diff --git
> a/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.c
> b/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.c
> index b242b23..f90fb55 100644
> --- a/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.c
> +++
> b/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.c
> @@ -76,10 +76,10 @@ SerialPortReadRegister (
>UINTN  Offset
>)
>  {
> -  if (PcdGetBool (PcdSerialUseMmio32)) {
> -return (UINT8) MmioRead32 (Base + Offset * PcdGet32
> (PcdSerialRegisterStride));
> -  }
> -  else if (PcdGetBool (PcdSerialUseMmio)) {
> +  if (PcdGetBool (PcdSerialUseMmio)) {
> +if (PcdGetBool (PcdSerialMmio32BitAccess)) {
> +  return (UINT8) MmioRead32 (Base + Offset * PcdGet32
> (PcdSerialRegisterStride));
> +}
>  return MmioRead8 (Base + Offset * PcdGet32 (PcdSerialRegisterStride));
>} else {
>  return IoRead8 (Base + Offset * PcdGet32 (PcdSerialRegisterStride));
> @@ -106,10 +106,10 @@ SerialPortWriteRegister (
>UINT8  Value
>)
>  {
> -  if (PcdGetBool (PcdSerialUseMmio32)) {
> -return MmioWrite32 (Base + Offset * PcdGet32 (PcdSerialRegisterStride),
> (UINT8)Value);
> -  }
> -  else if (PcdGetBool (PcdSerialUseMmio)) {
> +  if (PcdGetBool (PcdSerialUseMmio)) {
> +if (PcdGetBool (PcdSerialMmio32BitAccess)) {
> +  return (UINT8) MmioWrite32 (Base + Offset * PcdGet32
> (PcdSerialRegisterStride), (UINT8)Value);
> +}
>  return MmioWrite8 (Base + Offset * PcdGet32 (PcdSerialRegisterStride),
> Value);
>} else {
>  return IoWrite8 (Base + Offset * PcdGet32 (PcdSerialRegisterStride), 
> Value);
> diff --git
> a/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf
> b/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf
> index 575728a..c03d90d 100644
> ---
> a/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf
> +++
> b/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf
> @@ -29,7 +29,7 @@
>BaseSerialPortLib16550.c
> 
>  [Pcd]
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialUseMmio32   ##
> CONSUMES
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialMmio32BitAccess ##
> CONSUMES
>gEfiMdeModulePkgTokenSpaceGuid.PcdSerialUseMmio ##
> CONSUMES
>gEfiMdeModulePkgTokenSpaceGuid.PcdSerialUseHardwareFlowControl  ##
> CONSUMES
>gEfiMdeModulePkgTokenSpaceGuid.PcdSerialDetectCable ##
> SOMETIMES_CONSUMES
> diff --git a/MdeModulePkg/MdeModulePkg.dec
> b/MdeModulePkg/MdeModulePkg.dec
> index 4e53625..f868850 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -1170,11 +1170,13 @@
># @Prompt Serial port registers use MMIO.
> 
> gEfiMdeModulePkgTokenSpaceGuid.PcdSerialUseMmio|FALSE|BOOLEAN|0x00
> 02
> 
> -  ## Indicates the 16550 serial port registers are in MMIO 32 bit space, or 
> in
> I/O space. Default is I/O space.
> -  #   TRUE  - 16550 serial port registers are in MMIO 32 bit space.
> -  #   FALSE - 16550 serial port registers are in I/O space.
> -  # @Prompt Serial port registers use MMIO.
> -
> gEfiMdeModulePkgTokenSpaceGuid.PcdSerialUseMmio32|FALSE|BOOLEAN|0x
> 00020007
> +  ## Indicates the access mode for 16550 serial port registers when they are 
> in
> MMIO space.
> +  # The PCD is only valid if PcdSerialUseMmio is set to TRUE.
> +  # Default is 8-bit access mode.
> +  #   TRUE  - 16550 serial port MMIO registers are accessed in 32-bit
> width.
> +  #   FALSE - 16550 serial port

[edk2-devel] [PATCH 1/1] MdeModulePkg: BaseSerialPortLib16550: Add Mmio32 support

2019-04-23 Thread tien . hock . loh

From: "Tien Hock, Loh" 

Some busses doesn't allow 8 bit MMIO read/write, this adds support for
32 bits read/write

Signed-off-by: "Tien Hock, Loh" 
Cc: Jian J Wang 
Cc: Hao Wu 

--
v2:
- Updates the Pcd name to PcdSerialMmio32BitAccess and access 32 bits
register if PcdSerialUseMmio and PcdSerialMmio32BitAccess is set
---
 .../BaseSerialPortLib16550/BaseSerialPortLib16550.c  | 16 
 .../BaseSerialPortLib16550/BaseSerialPortLib16550.inf|  2 +-
 MdeModulePkg/MdeModulePkg.dec| 12 +++-
 3 files changed, 16 insertions(+), 14 deletions(-)

diff --git 
a/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.c 
b/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.c
index b242b23..f90fb55 100644
--- a/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.c
+++ b/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.c
@@ -76,10 +76,10 @@ SerialPortReadRegister (
   UINTN  Offset
   )
 {
-  if (PcdGetBool (PcdSerialUseMmio32)) {
-return (UINT8) MmioRead32 (Base + Offset * PcdGet32 
(PcdSerialRegisterStride));
-  }
-  else if (PcdGetBool (PcdSerialUseMmio)) {
+  if (PcdGetBool (PcdSerialUseMmio)) {
+if (PcdGetBool (PcdSerialMmio32BitAccess)) {
+  return (UINT8) MmioRead32 (Base + Offset * PcdGet32 
(PcdSerialRegisterStride));
+}
 return MmioRead8 (Base + Offset * PcdGet32 (PcdSerialRegisterStride));
   } else {
 return IoRead8 (Base + Offset * PcdGet32 (PcdSerialRegisterStride));
@@ -106,10 +106,10 @@ SerialPortWriteRegister (
   UINT8  Value
   )
 {
-  if (PcdGetBool (PcdSerialUseMmio32)) {
-return MmioWrite32 (Base + Offset * PcdGet32 (PcdSerialRegisterStride), 
(UINT8)Value);
-  }
-  else if (PcdGetBool (PcdSerialUseMmio)) {
+  if (PcdGetBool (PcdSerialUseMmio)) {
+if (PcdGetBool (PcdSerialMmio32BitAccess)) {
+  return (UINT8) MmioWrite32 (Base + Offset * PcdGet32 
(PcdSerialRegisterStride), (UINT8)Value);
+}
 return MmioWrite8 (Base + Offset * PcdGet32 (PcdSerialRegisterStride), 
Value);
   } else {
 return IoWrite8 (Base + Offset * PcdGet32 (PcdSerialRegisterStride), 
Value);
diff --git 
a/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf 
b/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf
index 575728a..c03d90d 100644
--- a/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf
+++ b/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf
@@ -29,7 +29,7 @@
   BaseSerialPortLib16550.c
 
 [Pcd]
-  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialUseMmio32   ## CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialMmio32BitAccess ## CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdSerialUseMmio ## CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdSerialUseHardwareFlowControl  ## CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdSerialDetectCable ## 
SOMETIMES_CONSUMES
diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 4e53625..f868850 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -1170,11 +1170,13 @@
   # @Prompt Serial port registers use MMIO.
   gEfiMdeModulePkgTokenSpaceGuid.PcdSerialUseMmio|FALSE|BOOLEAN|0x0002
 
-  ## Indicates the 16550 serial port registers are in MMIO 32 bit space, or in 
I/O space. Default is I/O space.
-  #   TRUE  - 16550 serial port registers are in MMIO 32 bit space.
-  #   FALSE - 16550 serial port registers are in I/O space.
-  # @Prompt Serial port registers use MMIO.
-  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialUseMmio32|FALSE|BOOLEAN|0x00020007
+  ## Indicates the access mode for 16550 serial port registers when they are 
in MMIO space.
+  # The PCD is only valid if PcdSerialUseMmio is set to TRUE.
+  # Default is 8-bit access mode.
+  #   TRUE  - 16550 serial port MMIO registers are accessed in 32-bit 
width.
+  #   FALSE - 16550 serial port MMIO registers are accessed in 8-bit width.
+  # @Prompt Serial port MMIO registers access mode.
+  
gEfiMdeModulePkgTokenSpaceGuid.PcdSerialMmio32BitAccess|FALSE|BOOLEAN|0x00020007
 
   ## Indicates if the 16550 serial port hardware flow control will be enabled. 
Default is FALSE.
   #   TRUE  - 16550 serial port hardware flow control will be enabled.
-- 
2.2.2


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

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

Re: [edk2-devel] [PATCH 0/3] MdePkg/DebugLib: Change the global variable name



> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, April 23, 2019 10:08 PM
> To: devel@edk2.groups.io; Gao, Zhichao 
> Cc: Kinney, Michael D ; Gao, Liming
> ; Bi, Dandan 
> Subject: Re: [edk2-devel] [PATCH 0/3] MdePkg/DebugLib: Change the global
> variable name
> 
> On 04/23/19 04:35, Gao, Zhichao wrote:
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1740
> >
> > The DebugLib instances of DebugPortProtocol, ConOut and StdErr use a
> > global variable "mExitBootServicesEvent" which is in conflict with the
> > same variable in StatusCodeHandlerRuntimeDxe.inf.
> > That would cause a build error through GCC5. So change the name to the
> > "mDebugLibExitBootServicesEvent".
> >
> > Cc: Michael D Kinney 
> > Cc: Liming Gao 
> > Cc: Dandan Bi 
> >
> > Zhichao Gao (3):
> >   MdePkg/UefiDebugLibConOut: Change the global variable name
> >   MdePkg/UefiDebugLibStdErr: Change the global variable name
> >   MdePkg/UefiDebugLibDebugPortProtocol: Change the global variable
> > name
> >
> >  MdePkg/Library/UefiDebugLibConOut/DebugLibConstructor.c   | 4 ++--
> >  .../UefiDebugLibDebugPortProtocol/DebugLibConstructor.c   | 4 ++--
> >  MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c   | 4 ++--
> >  3 files changed, 6 insertions(+), 6 deletions(-)
> >
> 
> The proper solution for this kind of error is to make as many as possible
> instances of "mExitBootServicesEvent" in edk2 STATIC.
> 
> See for example commit 7b13510f2a0a
> ("MdeModulePkg/BootMaintenanceManagerUiLib: hide library-internal
> symbol", 2016-05-17).
> 
> In particular, this patch renames three instances of mExitBootServicesEvent,
> but there are more:
> 
> -
> IntelFrameworkModulePkg/Library/SmmRuntimeDxeReportStatusCodeLibFr
> amework/SmmRuntimeDxeSupport.c
> -
> IntelFrameworkModulePkg/Universal/StatusCode/DatahubStatusCodeHandl
> erDxe/DatahubStatusCodeHandlerDxe.c
> - IntelFsp2WrapperPkg/FspWrapperNotifyDxe/FspWrapperNotifyDxe.c
> -
> MdeModulePkg/Universal/Acpi/FirmwarePerformanceDataTableDxe/Firmw
> arePerformanceDxe.c
> -
> MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHan
> dlerRuntimeDxe.c
> 
> Based on a brief investigation, it seems like the "STATIC" approach should
> work for all 8 (eight) files above. But, minimally, STATIC should be employed
> with library instances.
> 
> I seem to remember that there used to be debugging issues with Visual
> Studio if global variables were made STATIC -- but I think that only applied 
> to
> old (no longer supported by edk2?) Visual Studio versions. If you can't use
> STATIC here, please at least explain why, in the commit messages.

Thanks for your particular comments. I used to receive a comment to suggest me 
to make some global variable as 'STATIC'. But I consider the variable as the 
component scope that the variable may be used by the other files in the 
component. I forgot to consider the namespace collisions.
Agree with you, the variable such as 'mExitBootServicesEvent' is only used to 
create an event and close and it is useless for other files. All such variables 
should add a 'STATIC' description for them. I would update all the files your 
mentioned to decrease the namespace collisions.

Thanks,
Zhichao

> 
> Thanks,
> Laszlo

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

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

[edk2-devel] [staging/HBFA][PATCH] Announce to create "HBFA" branch in edk2-staging.

2019-04-23 Thread Sun, Tengfen

I have created a branch for evaluation version of Host-based Firmware Analyzer 
(HBFA) in my fork edk2-staging repo: 
https://github.com/tengfens/edk2-staging/tree/HBFA
Please refer to the Readme.md in above link to get the detail feature 
introduction and refer to wiki page in my fork repo to get execution and 
development content.

Note: The branch will be created in edk2-staging by the end of April if no 
objection.

Thanks & Best Regards,
Sun, Tengfen


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

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

[edk2-devel] [edk2-platforms/master] [patch 3/5] Platform/RaspberryPi: Update to use UefiDecompressLib in MdeModulePkg

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

We have moved the BaseUefiTianoCustomDecompressLib
from IntelFrameworkModulePkg to MdeModulePkg, so
update the consumer accordingly.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi 
---
 Platform/RaspberryPi/RPi3/RPi3.dsc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Platform/RaspberryPi/RPi3/RPi3.dsc 
b/Platform/RaspberryPi/RPi3/RPi3.dsc
index 26c8a0d040..f1143b1471 100644
--- a/Platform/RaspberryPi/RPi3/RPi3.dsc
+++ b/Platform/RaspberryPi/RPi3/RPi3.dsc
@@ -188,21 +188,21 @@
   
SecurityManagementLib|MdeModulePkg/Library/DxeSecurityManagementLib/DxeSecurityManagementLib.inf
   PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf
   
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
 
 [LibraryClasses.common.UEFI_APPLICATION]
-  
UefiDecompressLib|IntelFrameworkModulePkg/Library/BaseUefiTianoCustomDecompressLib/BaseUefiTianoCustomDecompressLib.inf
+  
UefiDecompressLib|MdeModulePkg/Library/BaseUefiTianoCustomDecompressLib/BaseUefiTianoCustomDecompressLib.inf
   PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf
   
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
   HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
   ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
   FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
   
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
 
 [LibraryClasses.common.UEFI_DRIVER]
   
ReportStatusCodeLib|IntelFrameworkModulePkg/Library/DxeReportStatusCodeLibFramework/DxeReportStatusCodeLib.inf
-  
UefiDecompressLib|IntelFrameworkModulePkg/Library/BaseUefiTianoCustomDecompressLib/BaseUefiTianoCustomDecompressLib.inf
+  
UefiDecompressLib|MdeModulePkg/Library/BaseUefiTianoCustomDecompressLib/BaseUefiTianoCustomDecompressLib.inf
   
ExtractGuidedSectionLib|MdePkg/Library/DxeExtractGuidedSectionLib/DxeExtractGuidedSectionLib.inf
   PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf
   
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
 
 [LibraryClasses.common.DXE_RUNTIME_DRIVER]
-- 
2.18.0.windows.1


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

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

[edk2-devel] [edk2-platforms/master] [patch 4/5] Platform/SoftIron: Update to use UefiDecompressLib in MdeModulePkg

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

We have moved the BaseUefiTianoCustomDecompressLib
from IntelFrameworkModulePkg to MdeModulePkg, so
update the consumer accordingly.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi 
---
 Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc 
b/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
index 7e9728d043..6ae0f2620c 100644
--- a/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
+++ b/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
@@ -216,19 +216,19 @@ DEFINE DO_FLASHER   = FALSE
 !if $(TARGET) != RELEASE
   
DebugLib|MdePkg/Library/DxeRuntimeDebugLibSerialPort/DxeRuntimeDebugLibSerialPort.inf
 !endif
 
 [LibraryClasses.common.UEFI_APPLICATION]
-  
UefiDecompressLib|IntelFrameworkModulePkg/Library/BaseUefiTianoCustomDecompressLib/BaseUefiTianoCustomDecompressLib.inf
+  
UefiDecompressLib|MdeModulePkg/Library/BaseUefiTianoCustomDecompressLib/BaseUefiTianoCustomDecompressLib.inf
   PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf
   
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
   HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
   
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
 
 [LibraryClasses.common.UEFI_DRIVER]
   
ReportStatusCodeLib|IntelFrameworkModulePkg/Library/DxeReportStatusCodeLibFramework/DxeReportStatusCodeLib.inf
-  
UefiDecompressLib|IntelFrameworkModulePkg/Library/BaseUefiTianoCustomDecompressLib/BaseUefiTianoCustomDecompressLib.inf
+  
UefiDecompressLib|MdeModulePkg/Library/BaseUefiTianoCustomDecompressLib/BaseUefiTianoCustomDecompressLib.inf
   
ExtractGuidedSectionLib|MdePkg/Library/DxeExtractGuidedSectionLib/DxeExtractGuidedSectionLib.inf
   PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf
   
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
 
 [LibraryClasses.ARM]
-- 
2.18.0.windows.1


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

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

[edk2-devel] [edk2-platforms/master] [patch 0/5] Update platforms to use UefiDecompressLib in MdeModulePkg

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

We have moved the BaseUefiTianoCustomDecompressLib
from IntelFrameworkModulePkg to MdeModulePkg, so
update consumers accordingly.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Michael D Kinney 

Dandan Bi (5):
  Platform/AMD: Update to use UefiDecompressLib in MdeModulePkg
  Platform/LeMaker: Update to use UefiDecompressLib in MdeModulePkg
  Platform/RaspberryPi: Update to use UefiDecompressLib in MdeModulePkg
  Platform/SoftIron: Update to use UefiDecompressLib in MdeModulePkg
  Silicon/Hisilicon: Update to use UefiDecompressLib in MdeModulePkg

 Platform/AMD/OverdriveBoard/OverdriveBoard.dsc  | 4 ++--
 Platform/LeMaker/CelloBoard/CelloBoard.dsc  | 4 ++--
 Platform/RaspberryPi/RPi3/RPi3.dsc  | 4 ++--
 Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc | 4 ++--
 Silicon/Hisilicon/Hisilicon.dsc.inc | 4 ++--
 5 files changed, 10 insertions(+), 10 deletions(-)

-- 
2.18.0.windows.1


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

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

Re: [edk2-devel] [edk2] Request to add new edk2-libc repository

2019-04-23 Thread Michael D Kinney

Hi Laszlo,

Many topics in here.  Please let me know if I missed anything.

1) I did use git filter-branch to extract the history of these
   packages.  The script I ran is shown below.  It results in 
   a local repo in the directory edk2-filter that contains
   the 3 packages with complete history and the Maintainers,
   License, and Readme files.  The step remaining is to add a 
   remote to the new edk2-libc repo and push the master branch
   in edk2-filter to edk2-libc.  I will add these details to
   the commit message.

export PATHS_TO_KEEP="./AppPkg ./ StdLib ./StdLibPrivateInternalFiles 
./Maintainers.txt ./License* ./Read*"
git clone https://github.com/tianocore/edk2.git edk2-filter
cd edk2-filter
git checkout master
git remote rm origin
git filter-branch -f --index-filter "git rm --ignore-unmatch --cached -qr -- . 
&& git reset -q \$GIT_COMMIT -- $PATHS_TO_KEEP" --prune-empty -- "master"

2) There are 2 reviews.  

2a)One to add new edk2-libc repo and populate with complete
   history and update the Maintainers.txt and Readme.md file.  

   https://github.com/mdkinney/edk2-libc

   https://github.com/mdkinney/edk2-libc/commits/master

   I think it makes sense to have a pointer to the edk2 repo
   from the edk2-libc repo in the Readme.md.  I am ok with
   removing the stewards from the edk2-libc Maintainers.txt
   and pointing to Maintainers.txt in edk2 repo.  However, I
   would prefer the list of packages in Maintainers.txt be
   limited to the packages in that repo.  So the Readme.md
   in edk2-libc would point to Maintainers.txt in the edk2-libc
   repo for the packages in edk2-libc and provide a link to 
   Maintainers.txt in edk2 repo for the stewards.

2b)Another review to remove the packages from the edk2 repo
   and remove those packages from Maintainers.txt
   and Readme.md.  I did edit the commit to edk2 repo to make
   it smaller.  I have a V2 that does the remove in the first
   patch, and updates Maintainers.txt and Readme.md in a second
   patch.

3) I understand your point about splitting actively maintained
   content into multiple repos and being able to use the 
   history effectively to find the cause of a regression.
   The current plans for moving content are limited to the 
   retiring packages that are no longer needed, adding the
   edk2-libc repo and moving content from the edk2 repo to the
   edk2-platforms repo.  We already have a number of platforms
   being maintained in edk2-platforms, so we will not be making
   it any worse by this move.  There are no plans to move the
   EmulatorPkg or the OvmfPkg out of the edk2 repo.

4) I agree that the unit test for OrderedCollectionLib should
   be in the package that defines that library class.  The
   SafeIntLib unit tests you point to is a better style.
   I do not think unit tests should have a dependency on libc.
   I recommend we port the OrderedCollectionLib to not depend
   on libc and remove it from the AppPkg.

   I would prefer to enter a separate BZ to work on this port.

Thanks,

Mike

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io]
> On Behalf Of Laszlo Ersek
> Sent: Tuesday, April 23, 2019 5:26 AM
> To: Kinney, Michael D ;
> devel@edk2.groups.io
> Cc: Carsey, Jaben ; Daryl
> McDaniel (edk2-li...@mc2research.org)  li...@mc2research.org>; leif.lindh...@linaro.org; Andrew
> Fish (af...@apple.com) 
> Subject: Re: [edk2-devel] [edk2] Request to add new edk2-
> libc repository
> 
> Hello Mike,
> 
> On 04/20/19 02:07, Kinney, Michael D wrote:
> > Hello,
> >
> > There were no objections to the following RFC to add
> > a new edk2-libc repository.
> >
> > https://edk2.groups.io/g/devel/message/35211
> >
> > I have entered the following Feature Request Bugzilla
> >
> > https://bugzilla.tianocore.org/show_bug.cgi?id=1734
> >
> > I have posted a version of the edk2-libc repository for
> > review at the following location.  It includes all the
> > history for the three packages from the edk2
> repository.
> >
> > https://github.com/mdkinney/edk2-libc
> >
> > Please review this branch.
> 
> Can we document how this branch was extracted from the
> edk2 history? (I
> assume some form of branch rewriting.)
> 
> If it's documented already, then I apologize for missing
> it.
> 
> > There is a single commit to update the Readme.md and
> Maintainers.txt
> > that scopes them to this new edk2-libc repository.
> 
> So it seems that said single commit (7e1bdd700213, "edk2-
> libc: Reduce
> scope of Readme.md and Maintainer.txt", 2019-04-19) is
> the only manually
> written one (not a result of branch rewriting). Is that
> right?
> 
> ... Possible improvements for this commit:
> 
> - Can we not duplicate the "Tianocore Stewards" section?
> Perhaps we can
>   include a pointer to the edk2 "Maintainers.txt" file.
> 
> - "Responsible Disclosure, Reporting Security Issues":
> according to
> 
> ,
> no issues
>   found under StdLib

Re: [edk2-devel] [PATCH] Emulator: update binary AARCH64 build of X64 PE/COFF emulator

2019-04-23 Thread Ard Biesheuvel

On Tue, 23 Apr 2019 at 22:33, Leif Lindholm  wrote:
>
> On Tue, Apr 23, 2019 at 10:21:46PM +0200, Ard Biesheuvel wrote:
> > Update the binary RELEASE build targeting AARCH64 systems, created
> > with Ubuntu's gcc 7.3.0 using the GCC5 profile. This fixes an issue
> > in the previous build which was built against the wrong version of
> > CacheMaintenanceLib.
> >
> > Repo:   http://github.com/ardbiesheuvel/X86EmulatorPkg.git
> > Commit: 4b3f43430729d2d9569b13743e3e7133ea502d91
> >
> >   4b3f43430729 Use the correct version of CacheMaintenanceLib
> >   67d5dd9ff915 Update README to reflect upstream status
> >
> > Repo:   http://github.com/tiancore/edk2.git
> > Commit: 2c0d39ac4704b76b7efb67b0aee23c2e78045cbc
> >
> > Signed-off-by: Ard Biesheuvel 
>
> Reviewed-by: Leif Lindholm 
>

Thanks

Pushed as 77b5eefd92ae..596043ffb61d

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

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

Re: [edk2-devel] TianoCore Community Design Meeting Minutes

2019-04-23 Thread Brian J. Johnson

On 4/23/19 1:22 PM, Laszlo Ersek wrote:

On 04/19/19 07:55, Ni, Ray wrote:

Hi everyone,

In the first design meeting, Matthew and Sean from Microsoft presented the Mu
tools.

Below are some notes Mike and I captured from the meeting.

Please reply to this mail for any questions and comments.

Matthew Carlson / Sean Brogan - Microsoft - Project Mu Tools
https://urldefense.proofpoint.com/v2/url?u=https-3A__edk2.groups.io_g_devel_files_Designs_2019_0418_2019-2D04-2D18-2520Microsoft-2520-2D-2520Build-2520Tools-2520-2D-2520Design-2520Review-2520.pdf=DwIC-g=C5b8zRQO1miGmBeVZ2LFWg=joEypYTP_0CJDmGFXzPM2s0mxEmiZkE9j8XY2t0muB0=JrIFm-OW7EUMJO_bZcr5RkYsyHrao3YmmSYnCOCMAAg=f18bByZUCGrcf2VKMVUAoPNNBz2TKQFLJw1BNphrDc0=

I've checked the slides; I'd like to comment on / ask about one
particular topic. The following three items relate to that topic:

(1):

Background

[...]

- Splitting the code: A platform only needs to see the code the platform uses
to build.

(2):

Build a platform through PlatformBuild.py

- Starts with ~1% of platform code

- Dependencies resolving phase pulls additional platform code

* Multiple GIT repos are needed by platform. The dep resolving phase simplifies the
code setup. "setup" phase is isolated and can be skipped or replaced with other
similar tools.

(3): slide 25 / 34:

How do you discover what repos you need?
Platforms define what they need to build and SDE finds it

and "SDE" is explained earlier on slide 22 / 34, "Self Describing
Environment":

Verifies dependencies declared thru ext_deps and updates as needed

While I agree that a platform need not "see" more code than it requires
for being built, the platform is also not *hurt* by seeing more than it
strictly requires.

On the other hand, under a split repos approach, how are
inter-dependencies (between sub-repos) tracked, and navigated? Assume
there is a regression (encountered in platform testing) -- how do you
narrow down the issue to a specific commit of a specific sub-repo? And,
how do you automate said narrowing-down?

In a common git repository / with a common git history, the
inter-dependencies are tracked implicitly, and they aren't hard to
navigate, manually or automatically. Such navigation doesn't need
external tooling; it's all built into git (for example into "git
checkout" and "git bisect").

git supports submodules internally, but that feature exists to mirror
the boundaries that already exist between developer communities. For
example, OpenSSL's developer community and edk2's developer community,
are mostly distinct. Their workflows differ, their release criteria
differ, their testing expectations differ, so it makes sense for edk2 to
consume OpenSSL via a submodule.

But, I don't think the same applies to core modules in e.g. MdeModulePkg
and UefiCpuPkg, vs. *open* firmware platforms. Those development
communities overlap (or should overlap) to a good extent; we shouldn't
fragment them by splitting repos. (Separate subsystem repos and mailing
lists are fine as long as everything is git-merged ultimately into the
central repo.)

Note: I'm not arguing what Project Mu should do for its own sake. I'm
arguing against adopting some Project Mu workflow bits for upstream
edk2, at the level I currently understand those workflow bits. My
understanding of Project Mu could be very lacking. (I missed the design
meeting due to an unresolvable, permanent conflict.) Slide 12/34 says,
"Next Steps: Propose RFC to TianoCore community: Create 3 git
repositories". I hope I can check that out in more detail.

Thanks,
Laszlo

I noticed similar things, and agree with Laszlo's points. My group has
attempted to develop a complex edk2-based project using multiple repos
and some external tooling in the past, and found it completely
unworkable. Perhaps Project Mu's tooling is better than ours was. But
for modules which are developed together by the same group of people,
keeping all the code in a single git repo lets you make the best use of
git, and removes a lot of room for errors when committing code across
multiple modules.

--
Brian J. Johnson
Enterprise X86 Lab

Hewlett Packard Enterprise

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

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

Re: [edk2-devel] [PATCH] Emulator: update binary AARCH64 build of X64 PE/COFF emulator

2019-04-23 Thread Leif Lindholm

On Tue, Apr 23, 2019 at 10:21:46PM +0200, Ard Biesheuvel wrote:
> Update the binary RELEASE build targeting AARCH64 systems, created
> with Ubuntu's gcc 7.3.0 using the GCC5 profile. This fixes an issue
> in the previous build which was built against the wrong version of
> CacheMaintenanceLib.
> 
> Repo:   http://github.com/ardbiesheuvel/X86EmulatorPkg.git
> Commit: 4b3f43430729d2d9569b13743e3e7133ea502d91
> 
>   4b3f43430729 Use the correct version of CacheMaintenanceLib
>   67d5dd9ff915 Update README to reflect upstream status
> 
> Repo:   http://github.com/tiancore/edk2.git
> Commit: 2c0d39ac4704b76b7efb67b0aee23c2e78045cbc
> 
> Signed-off-by: Ard Biesheuvel 

Reviewed-by: Leif Lindholm 

> ---
> Full patch can be found at
> https://git.linaro.org/leg/noupstream/edk2-non-osi.git/log/?h=upstream
> 
>  Emulator/X86EmulatorDxe/X86EmulatorDxe.depex | Bin 54 -> 36 bytes
>  Emulator/X86EmulatorDxe/X86EmulatorDxe.efi   | Bin 913408 -> 913408 bytes
>  2 files changed, 0 insertions(+), 0 deletions(-)
> 
> diff --git a/Emulator/X86EmulatorDxe/X86EmulatorDxe.depex 
> b/Emulator/X86EmulatorDxe/X86EmulatorDxe.depex
> index ffce8c06d8a5..addc7467048e 100644
> Binary files a/Emulator/X86EmulatorDxe/X86EmulatorDxe.depex and 
> b/Emulator/X86EmulatorDxe/X86EmulatorDxe.depex differ
> diff --git a/Emulator/X86EmulatorDxe/X86EmulatorDxe.efi 
> b/Emulator/X86EmulatorDxe/X86EmulatorDxe.efi
> index 316ef245f834..6e71de70ba76 100644
> Binary files a/Emulator/X86EmulatorDxe/X86EmulatorDxe.efi and 
> b/Emulator/X86EmulatorDxe/X86EmulatorDxe.efi differ
> -- 
> 2.17.1
> 

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

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

Re: [edk2-devel] TianoCore Community Design Meeting Minutes

On 04/19/19 07:55, Ni, Ray wrote:
> Hi everyone,
> 
> In the first design meeting, Matthew and Sean from Microsoft presented the Mu 
> tools.
> 
> Below are some notes Mike and I captured from the meeting.
> 
> Please reply to this mail for any questions and comments.
> 
> 
> 
> Matthew Carlson / Sean Brogan - Microsoft - Project Mu Tools 
> https://edk2.groups.io/g/devel/files/Designs/2019/0418/2019-04-18%20Microsoft%20-%20Build%20Tools%20-%20Design%20Review%20.pdf

I've checked the slides; I'd like to comment on / ask about one
particular topic. The following three items relate to that topic:

(1):

> Background
> 
> [...]
> 
> - Splitting the code: A platform only needs to see the code the platform uses 
> to build.

(2):

> Build a platform through PlatformBuild.py
> 
> - Starts with ~1% of platform code
> 
> - Dependencies resolving phase pulls additional platform code
> 
>* Multiple GIT repos are needed by platform. The dep resolving phase 
> simplifies the code setup. "setup" phase is isolated and can be skipped or 
> replaced with other similar tools.

(3): slide 25 / 34:

> How do you discover what repos you need?
> Platforms define what they need to build and SDE finds it

and "SDE" is explained earlier on slide 22 / 34, "Self Describing
Environment":

> Verifies dependencies declared thru ext_deps and updates as needed

While I agree that a platform need not "see" more code than it requires
for being built, the platform is also not *hurt* by seeing more than it
strictly requires.

On the other hand, under a split repos approach, how are
inter-dependencies (between sub-repos) tracked, and navigated? Assume
there is a regression (encountered in platform testing) -- how do you
narrow down the issue to a specific commit of a specific sub-repo? And,
how do you automate said narrowing-down?

In a common git repository / with a common git history, the
inter-dependencies are tracked implicitly, and they aren't hard to
navigate, manually or automatically. Such navigation doesn't need
external tooling; it's all built into git (for example into "git
checkout" and "git bisect").

git supports submodules internally, but that feature exists to mirror
the boundaries that already exist between developer communities. For
example, OpenSSL's developer community and edk2's developer community,
are mostly distinct. Their workflows differ, their release criteria
differ, their testing expectations differ, so it makes sense for edk2 to
consume OpenSSL via a submodule.

But, I don't think the same applies to core modules in e.g. MdeModulePkg
and UefiCpuPkg, vs. *open* firmware platforms. Those development
communities overlap (or should overlap) to a good extent; we shouldn't
fragment them by splitting repos. (Separate subsystem repos and mailing
lists are fine as long as everything is git-merged ultimately into the
central repo.)

Note: I'm not arguing what Project Mu should do for its own sake. I'm
arguing against adopting some Project Mu workflow bits for upstream
edk2, at the level I currently understand those workflow bits. My
understanding of Project Mu could be very lacking. (I missed the design
meeting due to an unresolvable, permanent conflict.) Slide 12/34 says,
"Next Steps: Propose RFC to TianoCore community: Create 3 git
repositories". I hope I can check that out in more detail.

Thanks,
Laszlo

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

View/Reply Online (#39425): https://edk2.groups.io/g/devel/message/39425
Mute This Topic: https://groups.io/mt/31242794/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] MdeModulePkg/AhciPei: Add PEI BlockIO support

2019-04-23 Thread Ni, Ray

Reviewed-by: Ray Ni 

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Wu, Hao A
> Sent: Tuesday, April 23, 2019 1:07 AM
> To: devel@edk2.groups.io
> Cc: Wu, Hao A ; Ni, Ray ; Dong,
> Eric ; Wang, Jian J 
> Subject: [edk2-devel] [PATCH v3 2/2] MdeModulePkg/AhciPei: Add PEI
> BlockIO support
> 
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1483
> 
> This commit will add the PEI BlockIO (2) PPIs support for AHCI mode ATA
> devices.
> 
> More specifically, the driver will consume the ATA AHCI host controller
> PPI for ATA controllers working under AHCI code within the system. And
> then produces the below additional PPIs for each controller:
> 
> EFI PEI Recovery Block IO PPI
> EFI PEI Recovery Block IO2 PPI
> 
> Cc: Ray Ni 
> Cc: Eric Dong 
> Cc: Jian J Wang 
> Signed-off-by: Hao Wu 
> ---
>  MdeModulePkg/Bus/Ata/AhciPei/AhciPei.inf  |   4 +
>  MdeModulePkg/Bus/Ata/AhciPei/AhciPei.h|  30 ++
>  MdeModulePkg/Bus/Ata/AhciPei/AhciPeiBlockIo.h | 257 ++
>  MdeModulePkg/Bus/Ata/AhciPei/AhciMode.c   | 118 +
>  MdeModulePkg/Bus/Ata/AhciPei/AhciPei.c|  35 ++
>  MdeModulePkg/Bus/Ata/AhciPei/AhciPeiBlockIo.c | 516
> 
>  6 files changed, 960 insertions(+)
> 
> diff --git a/MdeModulePkg/Bus/Ata/AhciPei/AhciPei.inf
> b/MdeModulePkg/Bus/Ata/AhciPei/AhciPei.inf
> index bf686a198f..912ff7a8ba 100644
> --- a/MdeModulePkg/Bus/Ata/AhciPei/AhciPei.inf
> +++ b/MdeModulePkg/Bus/Ata/AhciPei/AhciPei.inf
> @@ -26,6 +26,8 @@ [Defines]
>  [Sources]
>AhciPei.c
>AhciPei.h
> +  AhciPeiBlockIo.c
> +  AhciPeiBlockIo.h
>AhciPeiPassThru.c
>AhciPeiPassThru.h
>AhciPeiS3.c
> @@ -54,6 +56,8 @@ [Ppis]
>gEdkiiIoMmuPpiGuid ## CONSUMES
>gEfiEndOfPeiSignalPpiGuid  ## CONSUMES
>gEdkiiPeiAtaPassThruPpiGuid## SOMETIMES_PRODUCES
> +  gEfiPeiVirtualBlockIoPpiGuid   ## SOMETIMES_PRODUCES
> +  gEfiPeiVirtualBlockIo2PpiGuid  ## SOMETIMES_PRODUCES
>gEdkiiPeiStorageSecurityCommandPpiGuid ## SOMETIMES_PRODUCES
> 
>  [Guids]
> diff --git a/MdeModulePkg/Bus/Ata/AhciPei/AhciPei.h
> b/MdeModulePkg/Bus/Ata/AhciPei/AhciPei.h
> index e6a9c0a333..9a34dc6e4f 100644
> --- a/MdeModulePkg/Bus/Ata/AhciPei/AhciPei.h
> +++ b/MdeModulePkg/Bus/Ata/AhciPei/AhciPei.h
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> 
> @@ -35,6 +36,7 @@
>  typedef struct _PEI_AHCI_CONTROLLER_PRIVATE_DATA
> PEI_AHCI_CONTROLLER_PRIVATE_DATA;
> 
>  #include "AhciPeiPassThru.h"
> +#include "AhciPeiBlockIo.h"
>  #include "AhciPeiStorageSecurity.h"
> 
>  //
> @@ -312,6 +314,8 @@ struct _PEI_AHCI_CONTROLLER_PRIVATE_DATA {
> 
>EFI_ATA_PASS_THRU_MODEAtaPassThruMode;
>EDKII_PEI_ATA_PASS_THRU_PPI   AtaPassThruPpi;
> +  EFI_PEI_RECOVERY_BLOCK_IO_PPI BlkIoPpi;
> +  EFI_PEI_RECOVERY_BLOCK_IO2_PPIBlkIo2Ppi;
>EDKII_PEI_STORAGE_SECURITY_CMD_PPIStorageSecurityPpi;
>EFI_PEI_PPI_DESCRIPTORAtaPassThruPpiList;
>EFI_PEI_PPI_DESCRIPTORBlkIoPpiList;
> @@ -554,6 +558,32 @@ AhciModeInitialization (
>);
> 
>  /**
> +  Transfer data from ATA device.
> +
> +  This function performs one ATA pass through transaction to transfer data
> from/to
> +  ATA device. It chooses the appropriate ATA command and protocol to
> invoke PassThru
> +  interface of ATA pass through.
> +
> +  @param[in] DeviceDataA pointer to PEI_AHCI_ATA_DEVICE_DATA
> structure.
> +  @param[in,out] BufferThe pointer to the current transaction 
> buffer.
> +  @param[in] StartLba  The starting logical block address to be
> accessed.
> +  @param[in] TransferLengthThe block number or sector count of the
> transfer.
> +  @param[in] IsWrite   Indicates whether it is a write operation.
> +
> +  @retval EFI_SUCCESSThe data transfer is complete successfully.
> +  @return others Some error occurs when transferring data.
> +
> +**/
> +EFI_STATUS
> +TransferAtaDevice (
> +  IN PEI_AHCI_ATA_DEVICE_DATA*DeviceData,
> +  IN OUT VOID*Buffer,
> +  IN EFI_LBA StartLba,
> +  IN UINT32  TransferLength,
> +  IN BOOLEAN IsWrite
> +  );
> +
> +/**
>Trust transfer data from/to ATA device.
> 
>This function performs one ATA pass through transaction to do a trust
> transfer
> diff --git a/MdeModulePkg/Bus/Ata/AhciPei/AhciPeiBlockIo.h
> b/MdeModulePkg/Bus/Ata/AhciPei/AhciPeiBlockIo.h
> new file mode 100644
> index 00..5896ae5acf
> --- /dev/null
> +++ b/MdeModulePkg/Bus/Ata/AhciPei/AhciPeiBlockIo.h
> @@ -0,0 +1,257 @@
> +/** @file
> +  The AhciPei driver is used to manage ATA hard disk device working under
> AHCI
> +  mode at PEI phase.
> +
> +  Copyright (c) 2019, Intel Corporation. All rights

Re: [edk2-devel] [PATCH v3 1/2] MdeModulePkg/AhciPei: Limit max transfer blocknum for 48-bit address

2019-04-23 Thread Ni, Ray

Reviewed-by: Ray Ni 

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Wu, Hao A
> Sent: Tuesday, April 23, 2019 1:06 AM
> To: devel@edk2.groups.io
> Cc: Wu, Hao A ; Ni, Ray ; Dong,
> Eric ; Wang, Jian J 
> Subject: [edk2-devel] [PATCH v3 1/2] MdeModulePkg/AhciPei: Limit max
> transfer blocknum for 48-bit address
> 
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1483
> 
> Due to the limited resource on the VTd DMA buffer size in the PEI phase, the
> driver will limit the maximum transfer block number for 48-bit addressing.
> 
> According to PCDs:
> gIntelSiliconPkgTokenSpaceGuid.PcdVTdPeiDmaBufferSize|0x0040
> gIntelSiliconPkgTokenSpaceGuid.PcdVTdPeiDmaBufferSizeS3|0x0020
> 
> The default buffer size allocated for IOMMU mapping is:
> * 4M bytes for non-S3 cases;
> * 2M bytes for S3
> 
> For ATA devices in 48-bit address mode, the maximum block number is
> currently set to 0x. For a device with block size equal to 512 bytes, the
> maximum buffer allowed for mapping within AhciPei driver will be close to
> 32M bytes. Thus, this commit will limit the 48-bit mode maximum block
> number to 0x800, which means 1M-byte maximum buffer for mapping when
> the block size of a device is 512 bytes. By doing so, potential failure on 
> calls
> to the IOMMU 'Map' service can be avoided.
> 
> Cc: Ray Ni 
> Cc: Eric Dong 
> Cc: Jian J Wang 
> Signed-off-by: Hao Wu 
> ---
>  MdeModulePkg/Bus/Ata/AhciPei/AhciMode.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Bus/Ata/AhciPei/AhciMode.c
> b/MdeModulePkg/Bus/Ata/AhciPei/AhciMode.c
> index a83c213a47..11754b3057 100644
> --- a/MdeModulePkg/Bus/Ata/AhciPei/AhciMode.c
> +++ b/MdeModulePkg/Bus/Ata/AhciPei/AhciMode.c
> @@ -48,7 +48,13 @@ UINT8  mAtaTrustCommands[2] = {  // Look up table
> (Lba48Bit) for maximum transfer block number  //
>  #define MAX_28BIT_TRANSFER_BLOCK_NUM 0x100
> -#define MAX_48BIT_TRANSFER_BLOCK_NUM 0x
> +//
> +// Due to limited resource for VTd PEI DMA buffer on platforms, the
> +driver // limits the maximum transfer block number for 48-bit addressing.
> +// Here, setting to 0x800 means that for device with 512-byte block
> +size, the // maximum buffer for DMA mapping will be 1M bytes in size.
> +//
> +#define MAX_48BIT_TRANSFER_BLOCK_NUM 0x800
> 
>  UINT32 mMaxTransferBlockNumber[2] = {
>MAX_28BIT_TRANSFER_BLOCK_NUM,
> --
> 2.12.0.windows.1
> 
> 
> 


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

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

Re: [edk2-devel] Requestion for LTS version on EDK2

2019-04-23 Thread rebecca via Groups.Io

On 2019-04-18 17:26, Laszlo Ersek wrote:
>
> (1) Introduce stable *branches* to the development model. Those would be
> forked off at the stable tags (well, at some of them).

Would this be _re_ introducing stable branches? As explained in
https://github.com/tianocore/tianocore.github.io/wiki/UDK it seems the
project only recently moved from UDK stable branches (at least, I
took them to be stable branches) to periodically tagging master with a
stable tag.

-- 
Rebecca Cran

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

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

Re: [edk2-devel] [PATCH v2] MdeModulePkg/DxeCapsuleLibFmp: avoid ESRT accesses at runtime

2019-04-23 Thread Ard Biesheuvel

On Tue, 23 Apr 2019 at 01:02, Michael D Kinney
 wrote:
>
> Ard,
>
> I agree. Only consumer is only the DxeCapsuleLibFmp
> itself.
>
> I see I had a typo on the second option.  The
> statement to add after the copy and ASSERT()
> would be:
>
>   mEsrtTable->FwResourceCountMax = FwResourceCount;
>

I have added the following

//
// Set FwResourceCountMax to a sane value.
//
mEsrtTable->FwResourceCountMax = mEsrtTable->FwResourceCount;

and committed as 2c0d39ac4704b76b7efb67b0aee23c2e78045cbc

Thanks all

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

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

答复: [edk2-devel] Requestion for LTS version on EDK2

2019-04-23 Thread liyi 00215672

Hi Laszlo,

Glad to get your detailed advices, it's useful for us.

We can give a label like "New feature" or "Bug fixed" to state the 
patch or BZ, then the LTS maintainer can easy to distinguish whether put 
them(patch or BZ) into LTS version.

Yes, I agree we can publish the LTS version once a year.

Thanks!

Yi  

-邮件原件-
发件人: Laszlo Ersek [mailto:ler...@redhat.com] 
发送时间: 2019年4月23日 19:10
收件人: liyi 00215672 ; devel@edk2.groups.io
主题: Re: [edk2-devel] Requestion for LTS version on EDK2

On 04/19/19 13:11, liyi 00215672 wrote:
> Hi Laszlo,
> 
> 1. If we could put some human resources into stable-branch(LTS), so 
> could you give us an rough assessment, how many people should we put 
> them into that? :)

Honestly: no idea.

Maybe this could be estimated if all of the commits / BZs since the first 
stable tag, edk2-stable201808, were now reviewed in retrospect, as to whether 
each would be a candidate for backporting to a stable branch based on 
"edk2-stable201808". Alas, right now that means ~1500 commits, so not too easy 
either...

Perhaps you could dedicate one person ATM to monitor / investigate this 
question. Monitor all of the new BZs and all of the patches posted to 
edk2-devel, and try to determine, working with the subject package maintainers, 
whether each issue is a bug (= not a new feature) and whether it affects, say, 
"edk2-stable201903". If it does, then the patch is likely a backport candidate.

If this person managed to actually backport these patches, let's say to a 
personal stable branch for starters, and test them too, then in a few months we 
might have evidence that the process works -- and then the central repo could 
grow such an official stable branch.

It's difficult to say how much extra time is needed, without researching it 
first in practice.

> 2. If we make a stable-branch(LTS) into reality, we can invent some rules, 
> likes one year(or two years) to release a LTS version, the LTS version was 
> only merged the bug-fixed. After the one or two years ,we will release 
> another new  LTS version and the older one LTS we would maintain for 3-5 
> years.

I'd suggest starting small, and aiming at 1 year (tops) at first, for keeping a 
stable branch alive.

Thanks
Laszlo

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

View/Reply Online (#39419): https://edk2.groups.io/g/devel/message/39419
Mute This Topic: https://groups.io/mt/31309500/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: Remove AppPkg, StdLib, StdLibPrivateInternalFiles

Hi Mike,

On 04/20/19 02:17, Michael D Kinney wrote:
> https://bugzilla.tianocore.org/show_bug.cgi?id=1734
> 
> Remove the following packages and move them to the new
> edk2-libc repository
> 
> * AppPkg
> * StdLib
> * StdLibPrivateInternalFiles
> 
> Cc: Jaben Carsey 
> Cc: Daryl McDaniel 
> Signed-off-by: Michael D Kinney 
> ---
>  AppPkg
>  Maintainers.txt   |10 -
>  Readme.md | 3 -
>  StdLib
>  StdLibPrivateInternalFiles

the subject line suggests the patch is for the core edk2 repository. In
that case, I'd expect all edk2 files under AppPkg etc to be listed in
the diffstat at least (even if we -- likely justifiedly -- decide that
it makes little sense to include all the *code* that's being removed in
the patch).

If the patch is indeed for core edk2, then please see my comments in the
thread "[edk2] Request to add new edk2-libc repository".

Thanks!
Laszlo

> 
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 10c11b5dc5..a0f8d541d0 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -63,11 +63,6 @@ M: Liming Gao 
>  
>  EDK II Packages:
>  
> -AppPkg
> -W: https://github.com/tianocore/tianocore.github.io/wiki/AppPkg
> -M: Daryl McDaniel 
> -M: Jaben Carsey 
> -
>  ArmPkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/ArmPkg
>  M: Leif Lindholm 
> @@ -260,11 +255,6 @@ SourceLevelDebugPkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/SourceLevelDebugPkg
>  M: Hao Wu 
>  
> -StdLib, StdLibPrivateInternalFiles
> -W: https://github.com/tianocore/tianocore.github.io/wiki/StdLib
> -M: Daryl McDaniel 
> -M: Jaben Carsey 
> -
>  UefiCpuPkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/UefiCpuPkg
>  M: Eric Dong 
> diff --git a/Readme.md b/Readme.md
> index 177d51972a..1feba16075 100644
> --- a/Readme.md
> +++ b/Readme.md
> @@ -6,9 +6,6 @@ for the UEFI and PI specifications from www.uefi.org.
>  The majority of the content in the EDK II open source project uses a
>  [BSD-2-Clause Plus Patent License](License.txt).  The EDK II open source 
> project
>  contains the following components that are covered by additional licenses:
> -* 
> [AppPkg/Applications/Python/Python-2.7.2/Tools/pybench](AppPkg/Applications/Python/Python-2.7.2/Tools/pybench/LICENSE)
> -* 
> [AppPkg/Applications/Python/Python-2.7.2](AppPkg/Applications/Python/Python-2.7.2/LICENSE)
> -* 
> [AppPkg/Applications/Python/Python-2.7.10](AppPkg/Applications/Python/Python-2.7.10/LICENSE)
>  * 
> [BaseTools/Source/C/BrotliCompress](BaseTools/Source/C/BrotliCompress/LICENSE)
>  * 
> [MdeModulePkg/Library/BrotliCustomDecompressLib](MdeModulePkg/Library/BrotliCustomDecompressLib/LICENSE)
>  * 
> [BaseTools/Source/C/LzmaCompress](BaseTools/Source/C/LzmaCompress/LZMA-SDK-README.txt)
> 
> 
> 


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

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

Re: [edk2-devel] [PATCH 0/3] MdePkg/DebugLib: Change the global variable name

On 04/23/19 04:35, Gao, Zhichao wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1740
> 
> The DebugLib instances of DebugPortProtocol, ConOut and StdErr
> use a global variable "mExitBootServicesEvent" which is in
> conflict with the same variable in StatusCodeHandlerRuntimeDxe.inf.
> That would cause a build error through GCC5. So change the
> name to the "mDebugLibExitBootServicesEvent".
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Dandan Bi 
> 
> Zhichao Gao (3):
>   MdePkg/UefiDebugLibConOut: Change the global variable name
>   MdePkg/UefiDebugLibStdErr: Change the global variable name
>   MdePkg/UefiDebugLibDebugPortProtocol: Change the global variable name
> 
>  MdePkg/Library/UefiDebugLibConOut/DebugLibConstructor.c   | 4 ++--
>  .../UefiDebugLibDebugPortProtocol/DebugLibConstructor.c   | 4 ++--
>  MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c   | 4 ++--
>  3 files changed, 6 insertions(+), 6 deletions(-)
> 

The proper solution for this kind of error is to make as many as possible 
instances of "mExitBootServicesEvent" in edk2 STATIC.

See for example commit 7b13510f2a0a ("MdeModulePkg/BootMaintenanceManagerUiLib: 
hide library-internal symbol", 2016-05-17).

In particular, this patch renames three instances of mExitBootServicesEvent, 
but there are more:

- 
IntelFrameworkModulePkg/Library/SmmRuntimeDxeReportStatusCodeLibFramework/SmmRuntimeDxeSupport.c
- 
IntelFrameworkModulePkg/Universal/StatusCode/DatahubStatusCodeHandlerDxe/DatahubStatusCodeHandlerDxe.c
- IntelFsp2WrapperPkg/FspWrapperNotifyDxe/FspWrapperNotifyDxe.c
- 
MdeModulePkg/Universal/Acpi/FirmwarePerformanceDataTableDxe/FirmwarePerformanceDxe.c
- 
MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.c

Based on a brief investigation, it seems like the "STATIC" approach should work 
for all 8 (eight) files above. But, minimally, STATIC should be employed with 
library instances.

I seem to remember that there used to be debugging issues with Visual Studio if 
global variables were made STATIC -- but I think that only applied to old (no 
longer supported by edk2?) Visual Studio versions. If you can't use STATIC 
here, please at least explain why, in the commit messages.

Thanks,
Laszlo

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

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

Re: [edk2-devel] [PATCH V2 2/2] MdeModulePkg/GraphicsConsoleDxe: Do not clean the screen

On 04/23/19 09:04, Zhichao Gao wrote:
> From: Aaron Antone 
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1412
> 
> For now, most platform support to display during PEIM. It means the logo
> can show at PEI phase. But the screen would be cleared at BDS connect
> console phase. That may make the screen flush and turn into black screen.
> So do not clear the screen while set the text mode for graphics console
> device for the first time boot.
> As the shell reconnect command would make the same reslut with the first
> boot, use the gEfiEventReadyToBootGuid to distinguish them.
> 
> Also replace the debug code in GraphicsConsoleControllerDriverStart. The
> origin one would set a basic mode and then print the text info to graphic
> console device. Then the conspliter would set a best mode for graphics
> console device. If the best mode is different with the basic one, the
> screen would be cleared. So use the debug output instead.
> 
> This patch only affect the behavior of SetMode at the first boot during
> the graphics console devices first connect operations. That means at
> DXE phase before ReadyToBoot, the Graphics Simple Text Out SetMode would not
> clear the screen during the first connecttion of the graphics devices.

The UEFI spec requirement doesn't apply after ReadyToBoot only. What
about SysPrep applications, for example:

"""
When launched, the platform is required to provide the application
loaded by SysPrep, with the same services such as console and
network as are normally provided at launch to applications referenced by
a Boot variable. [...] 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 [...]
"""

Thus a SysPrep application is permitted to expect, and to use, the
console, but it is launched before ReadyToBoot; and so this patch could
break the console's std conformance for SysPrep apps.

I guess you have already investigated adding a boolean field to
GRAPHICS_CONSOLE_DEV, and found it unsuitable for those platforms that
need this anti-flicker tweak. So I'm not going to suggest such a boolean
field now.

Instead, I propose a PCD (feature PCD or dynamic boolean PCD). If you
add a PCD, I won't care about the particulars of this patch, as long as
platforms continue observing the std conformant behavior, under the
default value of the PCD (i.e., from "MdeModulePkg.dec").

Thanks,
Laszlo

> Cc: Jian J Wang 
> Cc: Hao Wu 
> Cc: Ray Ni 
> Cc: Star Zeng 
> Cc: Liming Gao 
> Cc: Sean Brogan 
> Cc: Michael Turner 
> Cc: Bret Barkelew 
> Cc: Laszlo Ersek 
> Signed-off-by: Zhichao Gao 
> ---
>  .../GraphicsConsoleDxe/GraphicsConsole.c  | 82 +--
>  .../GraphicsConsoleDxe/GraphicsConsoleDxe.inf |  3 +
>  2 files changed, 62 insertions(+), 23 deletions(-)
> 
> diff --git 
> a/MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsole.c 
> b/MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsole.c
> index 26ea19f300..39a999838c 100644
> --- a/MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsole.c
> +++ b/MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsole.c
> @@ -1,7 +1,7 @@
>  /** @file
>This is the main routine for initializing the Graphics Console support 
> routines.
>  
> -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>  SPDX-License-Identifier: BSD-2-Clause-Patent
>  
>  **/
> @@ -96,6 +96,12 @@ EFI_DRIVER_BINDING_PROTOCOL gGraphicsConsoleDriverBinding 
> = {
>NULL
>  };
>  
> +//
> +// Event and variable to indicate the boot phase.
> +//
> +EFI_EVENT   mGraphicsConsoleReadyToBootEvent;
> +BOOLEAN mGraphicsConsoleReadyToBoot   = FALSE;
> +
>  /**
>Test to see if Graphics Console could be supported on the Controller.
>  
> @@ -567,16 +573,7 @@ GraphicsConsoleControllerDriverStart (
>//
>Private->SimpleTextOutputMode.MaxMode = (INT32) MaxMode;
>  
> -  DEBUG_CODE_BEGIN ();
> -Status = GraphicsConsoleConOutSetMode (>SimpleTextOutput, 0);
> -if (EFI_ERROR (Status)) {
> -  goto Error;
> -}
> -Status = GraphicsConsoleConOutOutputString (>SimpleTextOutput, 
> (CHAR16 *)L"Graphics Console Started\n\r");
> -if (EFI_ERROR (Status)) {
> -  goto Error;
> -}
> -  DEBUG_CODE_END ();
> +  DEBUG ((DEBUG_INFO, "Graphics Console Started!\n\r"));
>  
>//
>// Install protocol interfaces for the Graphics Console device.
> @@ -1366,18 +1363,26 @@ GraphicsConsoleConOutSetMode (
>//
>// The current graphics mode is correct, so simply clear the entire 
> display
>//
> -  Status = GraphicsOutput->Blt (
> -  GraphicsOutput,
> -  [0],
> -  EfiBltVideoFill,
> -  0,
> -  0,
> -  0,
> -

Re: [edk2-devel] [staging/about Patch] Remove reference to Tiano Contributor's Agreement

On 04/20/19 00:54, Michael D Kinney wrote:
> Cc: Andrew Fish 
> Cc: Laszlo Ersek 
> Cc: Leif Lindholm 
> Signed-off-by: Michael D Kinney 
> ---
>  README | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/README b/README
> index b640a482f9..60f14a654a 100644
> --- a/README
> +++ b/README
> @@ -27,7 +27,7 @@ Process for creating, using, and maintaining staging efforts
>  
>   [staging/branch]: Subject
>  
> -3) All commits to edk2-staging must follow same edk2 rules (e.g. Tiano 
> Contributor's Agreement)
> +3) All commits to edk2-staging must follow same edk2 rules
>  
>  4) Process to add a new feature to edk2-staging
>   a) Maintainer sends patch email to edk2-devel mailing list announcing 
> the creation of a new 
> 

Acked-by: Laszlo Ersek 

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

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

Re: [edk2-devel] [edk2] Request to add new edk2-libc repository

Hello Mike,

On 04/20/19 02:07, Kinney, Michael D wrote:
> Hello,
>
> There were no objections to the following RFC to add
> a new edk2-libc repository.
>
> https://edk2.groups.io/g/devel/message/35211
>
> I have entered the following Feature Request Bugzilla
>
> https://bugzilla.tianocore.org/show_bug.cgi?id=1734
>
> I have posted a version of the edk2-libc repository for
> review at the following location.  It includes all the
> history for the three packages from the edk2 repository.
>
> https://github.com/mdkinney/edk2-libc
>
> Please review this branch.

Can we document how this branch was extracted from the edk2 history? (I
assume some form of branch rewriting.)

If it's documented already, then I apologize for missing it.

> There is a single commit to update the Readme.md and Maintainers.txt
> that scopes them to this new edk2-libc repository.

So it seems that said single commit (7e1bdd700213, "edk2-libc: Reduce
scope of Readme.md and Maintainer.txt", 2019-04-19) is the only manually
written one (not a result of branch rewriting). Is that right?

... Possible improvements for this commit:

- Can we not duplicate the "Tianocore Stewards" section? Perhaps we can
  include a pointer to the edk2 "Maintainers.txt" file.

- "Responsible Disclosure, Reporting Security Issues": according to
  , no issues
  found under StdLib will be classified as security issues. I think we
  should reflect that decision here.

- "EDK II Releases": I think if we split off StdLib, then "releases"
  will have to be defined from scratch. (But see my general objection
  (1) below, anyway.)

*

I've now re-read my comments under the RFC:

  [edk2] [RFC v2] Proposal to add edk2-libc

  https://lists.01.org/pipermail/edk2-devel/2019-January/035341.html
  https://edk2.groups.io/g/devel/message/35321
  http://mid.mail-archive.com/578c1f6c-945e-2f00-0cb4-d67f9dbdd50e@redhat.com

There I wrote,

> I'm not sure how closely the StdLib internals are tied to day-to-day
> changes in core edk2; that is, whether we should keep those histories
> interlinked. That's something for the StdLib maintainers to evaluate.
> Personally I don't remember many StdLib changes, so there seems to be
> a genuine separation that supports the new repo idea.

I'm not going back on those specific thoughts, but I'd like to voice my
disagreement on two points, one general and one specific.

(1) My general objection is that this change seems to set a precedent
for fragmenting the edk2 repository into multiple repositories. I'm
opposed to that. I'm *now* seeing the removal of StdLib as an action
for establishing prior art while it doesn't hurt in practice, and
then using it as "past evidence" in support of splitting off more
packages and modules. While I don't particularly mind StdLib, I
definitely object to such a *trend*. (When I last commented on the
RFC, in January, I didn't expect it to become a trend. I do worry
about it now.)

(2) My specific objection is that "Applications/OrderedCollectionTest"
is a unit test application for MdePkg's OrderedCollectionLib class.
This application has two relevant traits:

(2a) it depends on stdio for consuming input and producing output
 (please see the commit message on 424d84556d4d, "AppPkg:
 introduce OrderedCollectionTest", 2014-08-12),

(2b) it must be in sync with the OrderedCollectionLib class, and the
 (main) OrderedCollectionLib instance(s), at all times.

Due to (2b), I don't think this application should be removed from
the core edk2 repository (it's a validation tool). And, wrt. (2a), I
wouldn't like to give up the option of writing test apps /
"validators" that consume LibC -- the standard C library APIs allow
contributors to focus on the interfaces and tasks they actually want
to test.

I believe that, for "Applications/OrderedCollectionTest", it should
be "sort of" OK to split off StdLib; given that the application
assumes that StdLib "just works", and StdLib is not the app's main
focus. The standard C interfaces are specified separately
(independently of edk2), and so OrderedCollectionTest can be written
against ISO C, and we can expect users to make "some version" of
StdLib available through PACKAGES_PATH.

The same is not true of the
OrderedCollectionTest<->OrderedCollectionLib connection, which is
why I think the app itself should remain in core edk2. Perhaps we
should move the app under "MdeModulePkg/Application" first.

I'm not sure about the validation role of the other apps under AppPkg.
For example, "AppPkg/Applications/Sockets" used to be whole-sale helpful
for SNP driver testing. However, I agree it is different: first because
we now have HTTP boot over both IPv4 and IPv6, which is a good way to
test TCP and everything below, and second because an SNP driver again
implements

Re: [edk2-devel] [PATCH v2 3/5] BaseTools/PiFirmwareFile: fix undefined behavior in SECTION_SIZE

2019-04-23 Thread Bob Feng

Reviewed-by: Bob Feng 

-Original Message-
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Laszlo 
Ersek
Sent: Friday, April 19, 2019 1:47 AM
To: edk2-devel-groups-io 
Cc: Feng, Bob C ; Gao, Liming ; 
Zhu, Yonghong 
Subject: [edk2-devel] [PATCH v2 3/5] BaseTools/PiFirmwareFile: fix undefined 
behavior in SECTION_SIZE

Sync SECTION_SIZE() from MdePkg to BaseTools, from an earlier patch in this 
series.

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Yonghong Zhu 
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1710
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:

- sync with the v2 MdePkg/PiFirmwareFile SECTION_SIZE patch

 BaseTools/Source/C/Include/Common/PiFirmwareFile.h | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Source/C/Include/Common/PiFirmwareFile.h 
b/BaseTools/Source/C/Include/Common/PiFirmwareFile.h
index 5bc871df4855..7d8acb669b69 100644
--- a/BaseTools/Source/C/Include/Common/PiFirmwareFile.h
+++ b/BaseTools/Source/C/Include/Common/PiFirmwareFile.h
@@ -300,8 +300,15 @@ typedef struct {
   CHAR16  VersionString[1];
 } EFI_VERSION_SECTION2;
 
-#define SECTION_SIZE(SectionHeaderPtr) \
-((UINT32) (*((UINT32 *) ((EFI_COMMON_SECTION_HEADER *) 
SectionHeaderPtr)->Size) & 0x00ff))
+//
+// The argument passed as the SectionHeaderPtr parameter to the 
+SECTION_SIZE() // function-like macro below must not have side effects: 
+SectionHeaderPtr is // evaluated multiple times.
+//
+#define SECTION_SIZE(SectionHeaderPtr) ((UINT32) ( \
+(((EFI_COMMON_SECTION_HEADER *) (SectionHeaderPtr))->Size[0]  ) | \
+(((EFI_COMMON_SECTION_HEADER *) (SectionHeaderPtr))->Size[1] <<  8) | \
+(((EFI_COMMON_SECTION_HEADER *) (SectionHeaderPtr))->Size[2] << 
+16)))
 
 #pragma pack()
 
--
2.19.1.3.g30247aa5d201



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

View/Reply Online (#39309): https://edk2.groups.io/g/devel/message/39309
Mute This Topic: https://groups.io/mt/31233851/1768742
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [bob.c.f...@intel.com]
-=-=-=-=-=-=


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

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

Re: [edk2-devel] [PATCH v2 3/5] BaseTools/PiFirmwareFile: fix undefined behavior in SECTION_SIZE

Reviewed-by: Liming Gao 

Sorry for the missing. 

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, April 23, 2019 6:31 PM
> To: Feng, Bob C ; Gao, Liming ; 
> Zhu, Yonghong 
> Cc: edk2-devel-groups-io 
> Subject: Re: [edk2-devel] [PATCH v2 3/5] BaseTools/PiFirmwareFile: fix 
> undefined behavior in SECTION_SIZE
> 
> Bob, Liming, Yonghong,
> 
> On 04/18/19 19:47, Laszlo Ersek wrote:
> > Sync SECTION_SIZE() from MdePkg to BaseTools, from an earlier patch in
> > this series.
> >
> > Cc: Bob Feng 
> > Cc: Liming Gao 
> > Cc: Yonghong Zhu 
> > Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1710
> > Signed-off-by: Laszlo Ersek 
> > ---
> >
> > Notes:
> > v2:
> >
> > - sync with the v2 MdePkg/PiFirmwareFile SECTION_SIZE patch
> >
> >  BaseTools/Source/C/Include/Common/PiFirmwareFile.h | 11 +--
> >  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> can one of you please review this patch?
> 
> Thanks
> Laszlo
> 
> > diff --git a/BaseTools/Source/C/Include/Common/PiFirmwareFile.h 
> > b/BaseTools/Source/C/Include/Common/PiFirmwareFile.h
> > index 5bc871df4855..7d8acb669b69 100644
> > --- a/BaseTools/Source/C/Include/Common/PiFirmwareFile.h
> > +++ b/BaseTools/Source/C/Include/Common/PiFirmwareFile.h
> > @@ -300,8 +300,15 @@ typedef struct {
> >CHAR16  VersionString[1];
> >  } EFI_VERSION_SECTION2;
> >
> > -#define SECTION_SIZE(SectionHeaderPtr) \
> > -((UINT32) (*((UINT32 *) ((EFI_COMMON_SECTION_HEADER *) 
> > SectionHeaderPtr)->Size) & 0x00ff))
> > +//
> > +// The argument passed as the SectionHeaderPtr parameter to the 
> > SECTION_SIZE()
> > +// function-like macro below must not have side effects: SectionHeaderPtr 
> > is
> > +// evaluated multiple times.
> > +//
> > +#define SECTION_SIZE(SectionHeaderPtr) ((UINT32) ( \
> > +(((EFI_COMMON_SECTION_HEADER *) (SectionHeaderPtr))->Size[0]  ) | \
> > +(((EFI_COMMON_SECTION_HEADER *) (SectionHeaderPtr))->Size[1] <<  8) | \
> > +(((EFI_COMMON_SECTION_HEADER *) (SectionHeaderPtr))->Size[2] << 16)))
> >
> >  #pragma pack()
> >
> >


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

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

Re: [edk2-devel] Requestion for LTS version on EDK2

On 04/19/19 13:11, liyi 00215672 wrote:
> Hi Laszlo,
> 
> 1. If we could put some human resources into stable-branch(LTS), so could you 
> give us an rough assessment, how many people should we put them into that? :)

Honestly: no idea.

Maybe this could be estimated if all of the commits / BZs since the
first stable tag, edk2-stable201808, were now reviewed in retrospect, as
to whether each would be a candidate for backporting to a stable branch
based on "edk2-stable201808". Alas, right now that means ~1500 commits,
so not too easy either...

Perhaps you could dedicate one person ATM to monitor / investigate this
question. Monitor all of the new BZs and all of the patches posted to
edk2-devel, and try to determine, working with the subject package
maintainers, whether each issue is a bug (= not a new feature) and
whether it affects, say, "edk2-stable201903". If it does, then the patch
is likely a backport candidate.

If this person managed to actually backport these patches, let's say to
a personal stable branch for starters, and test them too, then in a few
months we might have evidence that the process works -- and then the
central repo could grow such an official stable branch.

It's difficult to say how much extra time is needed, without researching
it first in practice.

> 2. If we make a stable-branch(LTS) into reality, we can invent some rules, 
> likes one year(or two years) to release a LTS version, the LTS version was 
> only merged the bug-fixed. After the one or two years ,we will release 
> another new  LTS version and the older one LTS we would maintain for 3-5 
> years.

I'd suggest starting small, and aiming at 1 year (tops) at first, for
keeping a stable branch alive.

Thanks
Laszlo

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

View/Reply Online (#39411): https://edk2.groups.io/g/devel/message/39411
Mute This Topic: https://groups.io/mt/31222094/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] MdeModulePkg/AhciPei: Add PEI BlockIO support

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

This commit will add the PEI BlockIO (2) PPIs support for AHCI mode ATA
devices.

More specifically, the driver will consume the ATA AHCI host controller
PPI for ATA controllers working under AHCI code within the system. And
then produces the below additional PPIs for each controller:

EFI PEI Recovery Block IO PPI
EFI PEI Recovery Block IO2 PPI

Cc: Ray Ni 
Cc: Eric Dong 
Cc: Jian J Wang 
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Bus/Ata/AhciPei/AhciPei.inf  |   4 +
 MdeModulePkg/Bus/Ata/AhciPei/AhciPei.h|  30 ++
 MdeModulePkg/Bus/Ata/AhciPei/AhciPeiBlockIo.h | 257 ++
 MdeModulePkg/Bus/Ata/AhciPei/AhciMode.c   | 118 +
 MdeModulePkg/Bus/Ata/AhciPei/AhciPei.c|  35 ++
 MdeModulePkg/Bus/Ata/AhciPei/AhciPeiBlockIo.c | 516 
 6 files changed, 960 insertions(+)

diff --git a/MdeModulePkg/Bus/Ata/AhciPei/AhciPei.inf 
b/MdeModulePkg/Bus/Ata/AhciPei/AhciPei.inf
index bf686a198f..912ff7a8ba 100644
--- a/MdeModulePkg/Bus/Ata/AhciPei/AhciPei.inf
+++ b/MdeModulePkg/Bus/Ata/AhciPei/AhciPei.inf
@@ -26,6 +26,8 @@ [Defines]
 [Sources]
   AhciPei.c
   AhciPei.h
+  AhciPeiBlockIo.c
+  AhciPeiBlockIo.h
   AhciPeiPassThru.c
   AhciPeiPassThru.h
   AhciPeiS3.c
@@ -54,6 +56,8 @@ [Ppis]
   gEdkiiIoMmuPpiGuid ## CONSUMES
   gEfiEndOfPeiSignalPpiGuid  ## CONSUMES
   gEdkiiPeiAtaPassThruPpiGuid## SOMETIMES_PRODUCES
+  gEfiPeiVirtualBlockIoPpiGuid   ## SOMETIMES_PRODUCES
+  gEfiPeiVirtualBlockIo2PpiGuid  ## SOMETIMES_PRODUCES
   gEdkiiPeiStorageSecurityCommandPpiGuid ## SOMETIMES_PRODUCES
 
 [Guids]
diff --git a/MdeModulePkg/Bus/Ata/AhciPei/AhciPei.h 
b/MdeModulePkg/Bus/Ata/AhciPei/AhciPei.h
index e6a9c0a333..9a34dc6e4f 100644
--- a/MdeModulePkg/Bus/Ata/AhciPei/AhciPei.h
+++ b/MdeModulePkg/Bus/Ata/AhciPei/AhciPei.h
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -35,6 +36,7 @@
 typedef struct _PEI_AHCI_CONTROLLER_PRIVATE_DATA  
PEI_AHCI_CONTROLLER_PRIVATE_DATA;
 
 #include "AhciPeiPassThru.h"
+#include "AhciPeiBlockIo.h"
 #include "AhciPeiStorageSecurity.h"
 
 //
@@ -312,6 +314,8 @@ struct _PEI_AHCI_CONTROLLER_PRIVATE_DATA {
 
   EFI_ATA_PASS_THRU_MODEAtaPassThruMode;
   EDKII_PEI_ATA_PASS_THRU_PPI   AtaPassThruPpi;
+  EFI_PEI_RECOVERY_BLOCK_IO_PPI BlkIoPpi;
+  EFI_PEI_RECOVERY_BLOCK_IO2_PPIBlkIo2Ppi;
   EDKII_PEI_STORAGE_SECURITY_CMD_PPIStorageSecurityPpi;
   EFI_PEI_PPI_DESCRIPTORAtaPassThruPpiList;
   EFI_PEI_PPI_DESCRIPTORBlkIoPpiList;
@@ -554,6 +558,32 @@ AhciModeInitialization (
   );
 
 /**
+  Transfer data from ATA device.
+
+  This function performs one ATA pass through transaction to transfer data 
from/to
+  ATA device. It chooses the appropriate ATA command and protocol to invoke 
PassThru
+  interface of ATA pass through.
+
+  @param[in] DeviceDataA pointer to PEI_AHCI_ATA_DEVICE_DATA 
structure.
+  @param[in,out] BufferThe pointer to the current transaction 
buffer.
+  @param[in] StartLba  The starting logical block address to be 
accessed.
+  @param[in] TransferLengthThe block number or sector count of the 
transfer.
+  @param[in] IsWrite   Indicates whether it is a write operation.
+
+  @retval EFI_SUCCESSThe data transfer is complete successfully.
+  @return others Some error occurs when transferring data.
+
+**/
+EFI_STATUS
+TransferAtaDevice (
+  IN PEI_AHCI_ATA_DEVICE_DATA*DeviceData,
+  IN OUT VOID*Buffer,
+  IN EFI_LBA StartLba,
+  IN UINT32  TransferLength,
+  IN BOOLEAN IsWrite
+  );
+
+/**
   Trust transfer data from/to ATA device.
 
   This function performs one ATA pass through transaction to do a trust 
transfer
diff --git a/MdeModulePkg/Bus/Ata/AhciPei/AhciPeiBlockIo.h 
b/MdeModulePkg/Bus/Ata/AhciPei/AhciPeiBlockIo.h
new file mode 100644
index 00..5896ae5acf
--- /dev/null
+++ b/MdeModulePkg/Bus/Ata/AhciPei/AhciPeiBlockIo.h
@@ -0,0 +1,257 @@
+/** @file
+  The AhciPei driver is used to manage ATA hard disk device working under AHCI
+  mode at PEI phase.
+
+  Copyright (c) 2019, Intel Corporation. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef _AHCI_PEI_BLOCKIO_H_
+#define _AHCI_PEI_BLOCKIO_H_
+
+//
+// ATA hard disk device for EFI_PEI_BLOCK_DEVICE_TYPE
+//
+#define EDKII_PEI_BLOCK_DEVICE_TYPE_ATA_HARD_DISK 8
+
+/**
+  Gets the count of block I/O devices that one specific block driver detects.
+
+  This function is used for getting the count of block I/O devices that one
+  specific block driver detects. If no device is detected, then the function
+  will return zero.
+
+  @param[in]  PeiServices  General-purpose services that are available
+

[edk2-devel] [PATCH v3 0/2] Add PEI BlockIO support for ATA AHCI mode devices

The series is also available at:
https://github.com/hwu25/edk2/tree/ahci_pei_blockio_v3

V3 changes:
A. Update the comment for definition 'MAX_48BIT_TRANSFER_BLOCK_NUM'.

B. Add 'EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST' attribute for
   mAhciAtaPassThruPpiListTemplate/mAhciBlkIoPpiListTemplate. This will
   make the installation of AtaPassThruPpi and BlkIo(2)Ppi seperate from
   each other, thus making the code logic more straightforward.

C. Abstract the shared codes (validity check on 'DeviceIndex') in
   * AhciBlockIoGetMediaInfo()
   * AhciBlockIoReadBlocks()
   * AhciBlockIoGetMediaInfo2()
   into function SearchDeviceByIndex().


V2 history:

Due to the file license change, rebase the whole series onto the tip of
the master branch. The 'Contributed-under' tag is removed from the log
messages as well.

V1 history:

The series will add the PEI BlockIO support for ATA AHCI mode devices.

Cc: Ray Ni 
Cc: Eric Dong 
Cc: Jian J Wang 

Hao Wu (2):
  MdeModulePkg/AhciPei: Limit max transfer blocknum for 48-bit address
  MdeModulePkg/AhciPei: Add PEI BlockIO support

 MdeModulePkg/Bus/Ata/AhciPei/AhciPei.inf  |   4 +
 MdeModulePkg/Bus/Ata/AhciPei/AhciPei.h|  30 ++
 MdeModulePkg/Bus/Ata/AhciPei/AhciPeiBlockIo.h | 257 ++
 MdeModulePkg/Bus/Ata/AhciPei/AhciMode.c   | 126 -
 MdeModulePkg/Bus/Ata/AhciPei/AhciPei.c|  35 ++
 MdeModulePkg/Bus/Ata/AhciPei/AhciPeiBlockIo.c | 516 
 6 files changed, 967 insertions(+), 1 deletion(-)
 create mode 100644 MdeModulePkg/Bus/Ata/AhciPei/AhciPeiBlockIo.h
 create mode 100644 MdeModulePkg/Bus/Ata/AhciPei/AhciPeiBlockIo.c

-- 
2.12.0.windows.1


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

View/Reply Online (#39407): https://edk2.groups.io/g/devel/message/39407
Mute This Topic: https://groups.io/mt/31306789/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] MdeModulePkg/AhciPei: Limit max transfer blocknum for 48-bit address

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

Due to the limited resource on the VTd DMA buffer size in the PEI phase,
the driver will limit the maximum transfer block number for 48-bit
addressing.

According to PCDs:
gIntelSiliconPkgTokenSpaceGuid.PcdVTdPeiDmaBufferSize|0x0040
gIntelSiliconPkgTokenSpaceGuid.PcdVTdPeiDmaBufferSizeS3|0x0020

The default buffer size allocated for IOMMU mapping is:
* 4M bytes for non-S3 cases;
* 2M bytes for S3

For ATA devices in 48-bit address mode, the maximum block number is
currently set to 0x. For a device with block size equal to 512 bytes,
the maximum buffer allowed for mapping within AhciPei driver will be close
to 32M bytes. Thus, this commit will limit the 48-bit mode maximum block
number to 0x800, which means 1M-byte maximum buffer for mapping when the
block size of a device is 512 bytes. By doing so, potential failure on
calls to the IOMMU 'Map' service can be avoided.

Cc: Ray Ni 
Cc: Eric Dong 
Cc: Jian J Wang 
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Bus/Ata/AhciPei/AhciMode.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Bus/Ata/AhciPei/AhciMode.c 
b/MdeModulePkg/Bus/Ata/AhciPei/AhciMode.c
index a83c213a47..11754b3057 100644
--- a/MdeModulePkg/Bus/Ata/AhciPei/AhciMode.c
+++ b/MdeModulePkg/Bus/Ata/AhciPei/AhciMode.c
@@ -48,7 +48,13 @@ UINT8  mAtaTrustCommands[2] = {
 // Look up table (Lba48Bit) for maximum transfer block number
 //
 #define MAX_28BIT_TRANSFER_BLOCK_NUM 0x100
-#define MAX_48BIT_TRANSFER_BLOCK_NUM 0x
+//
+// Due to limited resource for VTd PEI DMA buffer on platforms, the driver
+// limits the maximum transfer block number for 48-bit addressing.
+// Here, setting to 0x800 means that for device with 512-byte block size, the
+// maximum buffer for DMA mapping will be 1M bytes in size.
+//
+#define MAX_48BIT_TRANSFER_BLOCK_NUM 0x800
 
 UINT32 mMaxTransferBlockNumber[2] = {
   MAX_28BIT_TRANSFER_BLOCK_NUM,
-- 
2.12.0.windows.1


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

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

Re: [edk2-devel] [staging/about Patch] Remove reference to Tiano Contributor's Agreement

On 4/20/19 12:54 AM, Michael D Kinney wrote:
> Cc: Andrew Fish 
> Cc: Laszlo Ersek 
> Cc: Leif Lindholm 
> Signed-off-by: Michael D Kinney 
> ---
>  README | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/README b/README
> index b640a482f9..60f14a654a 100644
> --- a/README
> +++ b/README
> @@ -27,7 +27,7 @@ Process for creating, using, and maintaining staging efforts
>  
>   [staging/branch]: Subject
>  
> -3) All commits to edk2-staging must follow same edk2 rules (e.g. Tiano 
> Contributor's Agreement)
> +3) All commits to edk2-staging must follow same edk2 rules
>  
>  4) Process to add a new feature to edk2-staging
>   a) Maintainer sends patch email to edk2-devel mailing list announcing 
> the creation of a new 
> 

Reviewed-by: Philippe Mathieu-Daude 

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

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

Re: [edk2-devel] [PATCH v2 4/5] MdePkg/PiFirmwareFile: fix undefined behavior in FFS_FILE_SIZE

On 4/18/19 7:47 PM, Laszlo Ersek wrote:
> Accessing "EFI_FFS_FILE_HEADER.Size", which is of type UINT8[3], through a
> (UINT32*), is undefined behavior. Fix it by accessing the array elements
> individually.
> 
> Cc: Liming Gao 
> Cc: Michael D Kinney 
> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1710
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> v2:
> 
> - eliminate intermediate macros [Mike]
> 
>  MdePkg/Include/Pi/PiFirmwareFile.h | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/MdePkg/Include/Pi/PiFirmwareFile.h 
> b/MdePkg/Include/Pi/PiFirmwareFile.h
> index 05470538de42..ec7729e9c36e 100644
> --- a/MdePkg/Include/Pi/PiFirmwareFile.h
> +++ b/MdePkg/Include/Pi/PiFirmwareFile.h
> @@ -179,8 +179,15 @@ typedef struct {
>  #define IS_FFS_FILE2(FfsFileHeaderPtr) \
>  (EFI_FFS_FILE_HEADER *) (UINTN) FfsFileHeaderPtr)->Attributes) & 
> FFS_ATTRIB_LARGE_FILE) == FFS_ATTRIB_LARGE_FILE)
>  
> -#define FFS_FILE_SIZE(FfsFileHeaderPtr) \
> -((UINT32) (*((UINT32 *) ((EFI_FFS_FILE_HEADER *) (UINTN) 
> FfsFileHeaderPtr)->Size) & 0x00ff))
> +///
> +/// The argument passed as the FfsFileHeaderPtr parameter to the
> +/// FFS_FILE_SIZE() function-like macro below must not have side effects:
> +/// FfsFileHeaderPtr is evaluated multiple times.
> +///
> +#define FFS_FILE_SIZE(FfsFileHeaderPtr) ((UINT32) ( \
> +(((EFI_FFS_FILE_HEADER *) (UINTN) (FfsFileHeaderPtr))->Size[0]  ) | \
> +(((EFI_FFS_FILE_HEADER *) (UINTN) (FfsFileHeaderPtr))->Size[1] <<  8) | \
> +(((EFI_FFS_FILE_HEADER *) (UINTN) (FfsFileHeaderPtr))->Size[2] << 16)))
>  
>  #define FFS_FILE2_SIZE(FfsFileHeaderPtr) \
>  ((UINT32) (((EFI_FFS_FILE_HEADER2 *) (UINTN) 
> FfsFileHeaderPtr)->ExtendedSize))
> 

Reviewed-by: Philippe Mathieu-Daude 

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

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

Re: [edk2-devel] [PATCH v2 2/5] MdePkg/PiFirmwareFile: fix undefined behavior in SECTION_SIZE

On 4/18/19 7:47 PM, Laszlo Ersek wrote:
> RH covscan justifiedly reports that accessing
> "EFI_COMMON_SECTION_HEADER.Size", which is of type UINT8[3], through a
> (UINT32*), is undefined behavior:
> 
>> Error: OVERRUN (CWE-119):
>> edk2-89910a39dcfd/OvmfPkg/Sec/SecMain.c:178: overrun-local: Overrunning
>> array of 3 bytes at byte offset 3 by dereferencing pointer
>> "(UINT32 *)((EFI_COMMON_SECTION_HEADER *)(UINTN)Section)->Size".
>> #  176|   Section = (EFI_COMMON_SECTION_HEADER*)(UINTN) CurrentAddress;
>> #  177|
>> #  178|-> Size = SECTION_SIZE (Section);
>> #  179|   if (Size < sizeof (*Section)) {
>> #  180| return EFI_VOLUME_CORRUPTED;
> 
> Fix this by accessing the array elements individually.
> 
> Cc: Liming Gao 
> Cc: Michael D Kinney 
> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1710
> Issue: scan-1007.txt
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> v2:
> 
> - replace EFI_COMMON_SECTION_HEADER_UNION with individual array element
>   access [Jordan, Phil, Mike]
> 
>  MdePkg/Include/Pi/PiFirmwareFile.h | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/MdePkg/Include/Pi/PiFirmwareFile.h 
> b/MdePkg/Include/Pi/PiFirmwareFile.h
> index a9f3bcc4eb8e..05470538de42 100644
> --- a/MdePkg/Include/Pi/PiFirmwareFile.h
> +++ b/MdePkg/Include/Pi/PiFirmwareFile.h
> @@ -480,8 +480,15 @@ typedef struct {
>CHAR16VersionString[1];
>  } EFI_VERSION_SECTION2;
>  
> -#define SECTION_SIZE(SectionHeaderPtr) \
> -((UINT32) (*((UINT32 *) ((EFI_COMMON_SECTION_HEADER *) (UINTN) 
> SectionHeaderPtr)->Size) & 0x00ff))
> +///
> +/// The argument passed as the SectionHeaderPtr parameter to the 
> SECTION_SIZE()
> +/// and IS_SECTION2() function-like macros below must not have side effects:
> +/// SectionHeaderPtr is evaluated multiple times.
> +///
> +#define SECTION_SIZE(SectionHeaderPtr) ((UINT32) ( \
> +(((EFI_COMMON_SECTION_HEADER *) (UINTN) (SectionHeaderPtr))->Size[0] 
>  ) | \
> +(((EFI_COMMON_SECTION_HEADER *) (UINTN) (SectionHeaderPtr))->Size[1] <<  
> 8) | \
> +(((EFI_COMMON_SECTION_HEADER *) (UINTN) (SectionHeaderPtr))->Size[2] << 
> 16)))
>  
>  #define IS_SECTION2(SectionHeaderPtr) \
>  (SECTION_SIZE (SectionHeaderPtr) == 0x00ff)
> 

Thanks!

Reviewed-by: Philippe Mathieu-Daude 

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

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

Re: [edk2-devel] [PATCH v2 3/5] BaseTools/PiFirmwareFile: fix undefined behavior in SECTION_SIZE

On 4/18/19 7:47 PM, Laszlo Ersek wrote:
> Sync SECTION_SIZE() from MdePkg to BaseTools, from an earlier patch in
> this series.
> 
> Cc: Bob Feng 
> Cc: Liming Gao 
> Cc: Yonghong Zhu 
> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1710
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> v2:
> 
> - sync with the v2 MdePkg/PiFirmwareFile SECTION_SIZE patch
> 
>  BaseTools/Source/C/Include/Common/PiFirmwareFile.h | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/BaseTools/Source/C/Include/Common/PiFirmwareFile.h 
> b/BaseTools/Source/C/Include/Common/PiFirmwareFile.h
> index 5bc871df4855..7d8acb669b69 100644
> --- a/BaseTools/Source/C/Include/Common/PiFirmwareFile.h
> +++ b/BaseTools/Source/C/Include/Common/PiFirmwareFile.h
> @@ -300,8 +300,15 @@ typedef struct {
>CHAR16  VersionString[1];
>  } EFI_VERSION_SECTION2;
>  
> -#define SECTION_SIZE(SectionHeaderPtr) \
> -((UINT32) (*((UINT32 *) ((EFI_COMMON_SECTION_HEADER *) 
> SectionHeaderPtr)->Size) & 0x00ff))
> +//
> +// The argument passed as the SectionHeaderPtr parameter to the 
> SECTION_SIZE()
> +// function-like macro below must not have side effects: SectionHeaderPtr is
> +// evaluated multiple times.
> +//
> +#define SECTION_SIZE(SectionHeaderPtr) ((UINT32) ( \
> +(((EFI_COMMON_SECTION_HEADER *) (SectionHeaderPtr))->Size[0]  ) | \
> +(((EFI_COMMON_SECTION_HEADER *) (SectionHeaderPtr))->Size[1] <<  8) | \
> +(((EFI_COMMON_SECTION_HEADER *) (SectionHeaderPtr))->Size[2] << 16)))
>  
>  #pragma pack()
>  
> 

Reviewed-by: Philippe Mathieu-Daude 

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

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

Re: [edk2-devel] [PATCH 0/3] MdePkg/DebugLib: Change the global variable name

On 4/23/19 4:35 AM, Gao, Zhichao wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1740
> 
> The DebugLib instances of DebugPortProtocol, ConOut and StdErr
> use a global variable "mExitBootServicesEvent" which is in
> conflict with the same variable in StatusCodeHandlerRuntimeDxe.inf.
> That would cause a build error through GCC5. So change the
> name to the "mDebugLibExitBootServicesEvent".
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Dandan Bi 
> 
> Zhichao Gao (3):
>   MdePkg/UefiDebugLibConOut: Change the global variable name
>   MdePkg/UefiDebugLibStdErr: Change the global variable name
>   MdePkg/UefiDebugLibDebugPortProtocol: Change the global variable name
> 
>  MdePkg/Library/UefiDebugLibConOut/DebugLibConstructor.c   | 4 ++--
>  .../UefiDebugLibDebugPortProtocol/DebugLibConstructor.c   | 4 ++--
>  MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c   | 4 ++--
>  3 files changed, 6 insertions(+), 6 deletions(-)
> 

Reviewed-by: Philippe Mathieu-Daude 

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

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

Re: [edk2-devel] [PATCH 0/3] Remove ICC tool chain

The change is good. And, please update the patch based on the latest trunk. 

Reviewed-by: Liming Gao 

Thanks
Liming
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Zhang, 
> Shenglei
> Sent: Tuesday, April 9, 2019 11:21 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Feng, Bob C 
> ; Gao, Liming ; Zhu,
> Yonghong 
> Subject: [edk2-devel] [PATCH 0/3] Remove ICC tool chain
> 
> There is no Intel complier test. So suggest to remove ICC
> tool chain from tools_def.template and remove support of Intel
> tool chain in BaseLib. And also IoLibIcc.c
> in MdePkg should update to be removed.
> https://bugzilla.tianocore.org/show_bug.cgi?id=1666
> 
> Cc: Michael D Kinney 
> Cc: Bob Feng 
> Cc: Liming Gao 
> Cc: Yonghong Zhu 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Shenglei Zhang 
> Shenglei Zhang (3):
>   MdePkg/BaseIoLibIntrinsic: Remove IoLibIcc.c
>   MdePkg/BaseLib: Remove support of INTEL tool chain
>   BaseTools: Remove ICC tool chain in tools_def.template
> 
>  BaseTools/Conf/tools_def.template | 1092 -
>  .../BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf |2 -
>  .../BaseIoLibIntrinsicSev.inf |2 -
>  MdePkg/Library/BaseIoLibIntrinsic/IoLibIcc.c  |  214 
>  MdePkg/Library/BaseLib/BaseLib.inf|  196 +--
>  5 files changed, 7 insertions(+), 1499 deletions(-)
>  delete mode 100644 MdePkg/Library/BaseIoLibIntrinsic/IoLibIcc.c
> 
> --
> 2.18.0.windows.1
> 
> 
> 


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

View/Reply Online (#39401): https://edk2.groups.io/g/devel/message/39401
Mute This Topic: https://groups.io/mt/30995499/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] MdeModulePkg/ConSplitterDxe: Optimize the ConSplitterTextOutSetMode

From: Aaron Antone 

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

For Console Out device, it would always set all present devices'
text out mode again through ConSplitterTextOutSetMode while adding
devices. That may cause the screen cleared for serval times.
So add a BOOLEAN to judge if it is adding device then we will not
set the same text mode again for same console out device.

Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ray Ni 
Cc: Star Zeng 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 
Cc: Laszlo Ersek 
Signed-off-by: Zhichao Gao 
---
 .../Console/ConSplitterDxe/ConSplitter.c  | 34 +--
 .../Console/ConSplitterDxe/ConSplitter.h  |  4 ++-
 2 files changed, 26 insertions(+), 12 deletions(-)

diff --git a/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c 
b/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
index 6fc0e4796f..fc9b9e08e5 100644
--- a/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
+++ b/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
@@ -16,7 +16,7 @@
   never removed. Such design ensures sytem function well during none console
   device situation.
 
-Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
 (C) Copyright 2016 Hewlett Packard Enterprise Development LP
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -180,7 +180,8 @@ GLOBAL_REMOVE_IF_UNREFERENCED 
TEXT_OUT_SPLITTER_PRIVATE_DATA mConOut = {
   0,
   (TEXT_OUT_SPLITTER_QUERY_DATA *) NULL,
   0,
-  (INT32 *) NULL
+  (INT32 *) NULL,
+  FALSE
 };
 
 //
@@ -235,7 +236,8 @@ GLOBAL_REMOVE_IF_UNREFERENCED 
TEXT_OUT_SPLITTER_PRIVATE_DATA mStdErr = {
   0,
   (TEXT_OUT_SPLITTER_QUERY_DATA *) NULL,
   0,
-  (INT32 *) NULL
+  (INT32 *) NULL,
+  FALSE
 };
 
 //
@@ -3132,8 +3134,9 @@ ConSplitterTextOutAddDevice (
   EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *Info;
   EFI_STATUS   DeviceStatus;
 
-  Status= EFI_SUCCESS;
-  CurrentNumOfConsoles  = Private->CurrentNumberOfConsoles;
+  Status  = EFI_SUCCESS;
+  CurrentNumOfConsoles= Private->CurrentNumberOfConsoles;
+  Private->AddingConOutDevice = TRUE;
 
   //
   // If the Text Out List is full, enlarge it by calling 
ConSplitterGrowBuffer().
@@ -3290,6 +3293,8 @@ ConSplitterTextOutAddDevice (
   //
   ConsplitterSetConsoleOutMode (Private);
 
+  Private->AddingConOutDevice = FALSE;
+
   return Status;
 }
 
@@ -4849,12 +4854,19 @@ ConSplitterTextOutSetMode (
   //
   TextOutModeMap = Private->TextOutModeMap + Private->TextOutListCount * 
ModeNumber;
   for (Index = 0, ReturnStatus = EFI_SUCCESS; Index < 
Private->CurrentNumberOfConsoles; Index++) {
-Status = Private->TextOutList[Index].TextOut->SetMode (
-
Private->TextOutList[Index].TextOut,
-TextOutModeMap[Index]
-);
-if (EFI_ERROR (Status)) {
-  ReturnStatus = Status;
+//
+// While adding a console out device do not set same mode again for the 
same device.
+//
+if (Private->AddingConOutDevice != TRUE ||
+  TextOutModeMap[Index] != 
Private->TextOutList[Index].TextOut->Mode->Mode) {
+
+  Status = Private->TextOutList[Index].TextOut->SetMode (
+  
Private->TextOutList[Index].TextOut,
+  TextOutModeMap[Index]
+  );
+  if (EFI_ERROR (Status)) {
+ReturnStatus = Status;
+  }
 }
   }
 
diff --git a/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.h 
b/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.h
index e9b68e58c6..419635c3f5 100644
--- a/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.h
+++ b/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.h
@@ -1,7 +1,7 @@
 /** @file
   Private data structures for the Console Splitter driver
 
-Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -218,6 +218,8 @@ typedef struct {
   UINTN TextOutQueryDataCount;
   INT32 *TextOutModeMap;
 
+  BOOLEAN   AddingConOutDevice;
+
 } TEXT_OUT_SPLITTER_PRIVATE_DATA;
 
 #define TEXT_OUT_SPLITTER_PRIVATE_DATA_FROM_THIS(a) \
-- 
2.21.0.windows.1


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

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

[edk2-devel] [PATCH V2 2/2] MdeModulePkg/GraphicsConsoleDxe: Do not clean the screen

From: Aaron Antone 

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

For now, most platform support to display during PEIM. It means the logo
can show at PEI phase. But the screen would be cleared at BDS connect
console phase. That may make the screen flush and turn into black screen.
So do not clear the screen while set the text mode for graphics console
device for the first time boot.
As the shell reconnect command would make the same reslut with the first
boot, use the gEfiEventReadyToBootGuid to distinguish them.

Also replace the debug code in GraphicsConsoleControllerDriverStart. The
origin one would set a basic mode and then print the text info to graphic
console device. Then the conspliter would set a best mode for graphics
console device. If the best mode is different with the basic one, the
screen would be cleared. So use the debug output instead.

This patch only affect the behavior of SetMode at the first boot during
the graphics console devices first connect operations. That means at
DXE phase before ReadyToBoot, the Graphics Simple Text Out SetMode would not
clear the screen during the first connecttion of the graphics devices.

Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ray Ni 
Cc: Star Zeng 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 
Cc: Laszlo Ersek 
Signed-off-by: Zhichao Gao 
---
 .../GraphicsConsoleDxe/GraphicsConsole.c  | 82 +--
 .../GraphicsConsoleDxe/GraphicsConsoleDxe.inf |  3 +
 2 files changed, 62 insertions(+), 23 deletions(-)

diff --git 
a/MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsole.c 
b/MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsole.c
index 26ea19f300..39a999838c 100644
--- a/MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsole.c
+++ b/MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsole.c
@@ -1,7 +1,7 @@
 /** @file
   This is the main routine for initializing the Graphics Console support 
routines.
 
-Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -96,6 +96,12 @@ EFI_DRIVER_BINDING_PROTOCOL gGraphicsConsoleDriverBinding = {
   NULL
 };
 
+//
+// Event and variable to indicate the boot phase.
+//
+EFI_EVENT   mGraphicsConsoleReadyToBootEvent;
+BOOLEAN mGraphicsConsoleReadyToBoot   = FALSE;
+
 /**
   Test to see if Graphics Console could be supported on the Controller.
 
@@ -567,16 +573,7 @@ GraphicsConsoleControllerDriverStart (
   //
   Private->SimpleTextOutputMode.MaxMode = (INT32) MaxMode;
 
-  DEBUG_CODE_BEGIN ();
-Status = GraphicsConsoleConOutSetMode (>SimpleTextOutput, 0);
-if (EFI_ERROR (Status)) {
-  goto Error;
-}
-Status = GraphicsConsoleConOutOutputString (>SimpleTextOutput, 
(CHAR16 *)L"Graphics Console Started\n\r");
-if (EFI_ERROR (Status)) {
-  goto Error;
-}
-  DEBUG_CODE_END ();
+  DEBUG ((DEBUG_INFO, "Graphics Console Started!\n\r"));
 
   //
   // Install protocol interfaces for the Graphics Console device.
@@ -1366,18 +1363,26 @@ GraphicsConsoleConOutSetMode (
   //
   // The current graphics mode is correct, so simply clear the entire 
display
   //
-  Status = GraphicsOutput->Blt (
-  GraphicsOutput,
-  [0],
-  EfiBltVideoFill,
-  0,
-  0,
-  0,
-  0,
-  ModeData->GopWidth,
-  ModeData->GopHeight,
-  0
-  );
+  //
+  // For the first time boot system, do not clear the display.
+  // Some platforms would show logo at PEIM and this would clear
+  // the whole screen. So for first boot set mode, do not clear
+  // the screen.
+  //
+  if (This->Mode->Mode != -1 || mGraphicsConsoleReadyToBoot) {
+Status = GraphicsOutput->Blt (
+GraphicsOutput,
+[0],
+EfiBltVideoFill,
+0,
+0,
+0,
+0,
+ModeData->GopWidth,
+ModeData->GopHeight,
+0
+);
+  }
 }
   } else if (FeaturePcdGet (PcdUgaConsumeSupport)) {
 //
@@ -2065,6 +2070,24 @@ RegisterFontPackage (
   FreePool (Package);
 }
 
+/**
+  Indicate the Boot phase is at ReadyToBoot.
+
+  @param[in]  Event   The Event that is being processed.
+  @param[in]  Context The Event Context.
+
+**/
+VOID
+GraphicsConsoleReadyToBootEvent (
+  IN EFI_EVENTEvent,
+  IN VOID *Context
+  )
+{
+  mGraphicsConsoleReadyToBoot = TRUE;
+
+  gBS->CloseEvent (mGraphicsConsoleReadyToBootEvent);
+}
+
 /**

[edk2-devel] [PATCH V2 0/2] MdeModulePkg: Make the screen seamless

For now most platforms support display function at PEI phase.
But the conspliter and graphics console driver would clear the
screen at BDS connect console phase. Maybe some platforms would
show logo in the next or maybe not. For consumers, it looks like
the screen flashed.
So change the behavior of graphics console devices while connect
console devices to maintain seamless screen from PEI.

Test has done on MinPlatform Kabylake-RVP3 which support PEI
display.

V2:
Make the SetMode not clear the screen only at the first boot during
the first conncettion of graphics device.

Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ray Ni 
Cc: Star Zeng 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 
Cc: Laszlo Ersek 

Aaron Antone (2):
  MdeModulePkg/ConSplitterDxe: Optimize the ConSplitterTextOutSetMode
  MdeModulePkg/GraphicsConsoleDxe: Do not clean the screen

 .../Console/ConSplitterDxe/ConSplitter.c  | 34 +---
 .../Console/ConSplitterDxe/ConSplitter.h  |  4 +-
 .../GraphicsConsoleDxe/GraphicsConsole.c  | 82 +--
 .../GraphicsConsoleDxe/GraphicsConsoleDxe.inf |  3 +
 4 files changed, 88 insertions(+), 35 deletions(-)

-- 
2.21.0.windows.1


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

View/Reply Online (#39398): https://edk2.groups.io/g/devel/message/39398
Mute This Topic: https://groups.io/mt/31306533/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] Fix Emulator ASSERT issue when re-enter setup

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

Currently Emulator meets ASSERT when enter setup->Continue->enter setup.
When re-enter setup, in the Constructor functions of some Libs linked
by UiApp, the handle is not NULL which cause InstallMultipleProtocolInterfaces
failure then ASSERT. So here set handle to NULL after uninstalling
protocols on it in Libs Destructor function to avoid this issue.

Cc: Liming Gao 
Cc: Eric Dong 
Cc: Hao Wu 
Cc: Ruiyu Ni 
Dandan Bi (2):
  MdeModulePkg/BMMUiLib: Set Handle to NULL after uninstall protocol
  MdeModulePkg/FileExplorer: Set Handle to NULL after uninstall protocol

 .../Library/BootMaintenanceManagerUiLib/BootMaintenance.c  | 3 ++-
 MdeModulePkg/Library/FileExplorerLib/FileExplorer.c| 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

-- 
2.18.0.windows.1


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

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

[edk2-devel] [patch 2/2] MdeModulePkg/FileExplorer: Set Handle to NULL after uninstall protocol

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

Currently Emulator meets ASSERT when enter setup->Continue->enter setup.
When re-enter setup, the FeDriverHandle in FileExplorerLib Constructor
is not NULL which cause InstallMultipleProtocolInterfaces failure,
then ASSERT. So here set FeDriverHandle to NULL after uninstalling
protocols on it in the Destructor function to avoid this issue.

Cc: Liming Gao 
Cc: Eric Dong 
Cc: Hao Wu 
Cc: Ruiyu Ni 
Signed-off-by: Dandan Bi 
---
 MdeModulePkg/Library/FileExplorerLib/FileExplorer.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/FileExplorerLib/FileExplorer.c 
b/MdeModulePkg/Library/FileExplorerLib/FileExplorer.c
index 27f12fcbf9..58e4910259 100644
--- a/MdeModulePkg/Library/FileExplorerLib/FileExplorer.c
+++ b/MdeModulePkg/Library/FileExplorerLib/FileExplorer.c
@@ -1,9 +1,9 @@
 /** @file
 File explorer related functions.
 
-Copyright (c) 2004 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2004 - 2019, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
 
 
@@ -1641,10 +1641,11 @@ FileExplorerLibDestructor (
 NULL
 );
 ASSERT_EFI_ERROR (Status);
 
 HiiRemovePackages (gFileExplorerPrivate.FeHiiHandle);
+gFileExplorerPrivate.FeDriverHandle = NULL;
   }
 
   FreePool (gHiiVendorDevicePath);
 
   return EFI_SUCCESS;
-- 
2.18.0.windows.1


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

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

Re: [edk2-devel] [PATCH v2 0/2] Add PEI BlockIO support for ATA AHCI mode devices

2019-04-23 Thread Ni, Ray




> -Original Message-
> From: Wu, Hao A
> Sent: Monday, April 22, 2019 10:18 PM
> To: Ni, Ray ; devel@edk2.groups.io
> Cc: Dong, Eric ; Wang, Jian J 
> Subject: RE: [PATCH v2 0/2] Add PEI BlockIO support for ATA AHCI mode
> devices
> 
> > -Original Message-
> > From: Ni, Ray
> > Sent: Tuesday, April 23, 2019 4:20 AM
> > To: Wu, Hao A; devel@edk2.groups.io
> > Cc: Dong, Eric; Wang, Jian J
> > Subject: RE: [PATCH v2 0/2] Add PEI BlockIO support for ATA AHCI mode
> > devices
> >
> > Comments:
> > 1. Can we add EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST to
> > mAhciAtaPassThruPpiListTemplate/mAhciBlkIoPpiListTemplate as well? I
> > understand that requires calling PeiServicesInstallPpi() 3 times instead of
> once.
> > But I see the benefit of change is the code is more understandable and
> 
> Agree. I will update the codes in V3.
Thanks.

> 
> > potential bug-free. And you could also create a global
> > mAhciBlkIoPpi/mAhciBlkIo2Ppi variables and let the
> > mAhciBlkIoPpiListTemplate/mAhciBlkIo2PpiListTemplate point to them
> 
> Please correct me if I am wrong.
> 
> The 'Ppi' field within
> mAhciBlkIoPpiListTemplate/mAhciBlkIo2PpiListTemplate
> will be used by BlockIO(2) PPI services implementation to get the private
> data for every AHCI ATA controller (or i.e. PPI instance), by using
> definitions:
> 
> GET_AHCI_PEIM_HC_PRIVATE_DATA_FROM_THIS_BLKIO
> GET_AHCI_PEIM_HC_PRIVATE_DATA_FROM_THIS_BLKIO2
> 
> If 'Ppi' field are of the same value among controllers, it seems to me getting
> the controller private data will not work.

I agree. Your current code is good.

> 
> > respectively. The reason we cannot have a global AtaPassThruPpi is
> > there is a Mode field in the PPI that cannot be read-only.
> > 2. Below code snip is used by
> > AhciBlockIoReadBlocks(),AhciBlockIoGetMediaInfo(),
> > AhciBlockIoGetMediaInfo2() in AhciPeiBlockIo.c, maybe you can re-write
> > SearchDeviceByIndex() to include the below code.
> >
> >   Private = GET_AHCI_PEIM_HC_PRIVATE_DATA_FROM_THIS_BLKIO (This);
> >
> >   //
> >   // Check parameters
> >   //
> >   if ((This == NULL) ||
> >   (DeviceIndex == 0) ||
> >   (DeviceIndex > Private->ActiveDevices)) {
> > return EFI_INVALID_PARAMETER;
> >   }
> >
> >   DeviceData = SearchDeviceByIndex (Private, DeviceIndex);
> >   if (DeviceData == NULL) {
> > return EFI_NOT_FOUND;
> >   }
> 
> OK. I can do this in V3.

Thanks.

> 
> >
> > 3. For the checks in AhciRead(), how about re-order as below?
> >
> >   BlockSize = DeviceData->Media.BlockSize;
> >   if ((BufferSize % BlockSize) != 0) {
> > return EFI_BAD_BUFFER_SIZE;
> >   }
> >
> >   if (StartLba > DeviceData->Media.LastBlock) {
> > return EFI_INVALID_PARAMETER;
> >   }
> >   NumberOfBlocks  = BufferSize / BlockSize;
> >   if (NumberOfBlocks - 1 > DeviceData->Media.LastBlock - StartLba) {
> > return EFI_INVALID_PARAMETER;
> >   }
> >
> >   if (BufferSize == 0) {
> > return EFI_SUCCESS;
> >   }
> >
> >   if (Buffer == NULL) {
> > return EFI_INVALID_PARAMETER;
> >   }
> 
> The current logic is align with its DXE counterpart:
> MdeModulePkg\Bus\Ata\AtaBusDxe\AtaBus.c - Line 1017: BlockIoReadWrite
> (
> 
> Could you help to provide some detailed reason for your suggestion?

Then I'm ok with that.

> 
> >
> > 4. Can you explain more for the first patch? Why VTd PEI module cannot
> > be changed to support 0x?
> 
> According to PCDs:
> gIntelSiliconPkgTokenSpaceGuid.PcdVTdPeiDmaBufferSize|0x0040|UIN
> T32|0x0003
> gIntelSiliconPkgTokenSpaceGuid.PcdVTdPeiDmaBufferSizeS3|0x0020|UI
> NT32|0x0004
> 
> The default buffer size for IOMMU mapping allocated is 2M bytes for S3 and
> 4M bytes for non-S3 cases.
> 
> When 48-bit maximum block number is 0x and block size is 512 bytes,
> the maximum buffer allowed for mapping within AhciPei driver will be close
> to 32M bytes. Thus, the 1st patch limits the 48-bit maximum block number
> to 0x800 (as mentioned by the comments for the definition), meaning 1M
> bytes for device with 512-byte block size.

Thanks for the explanation. Can you put the explanation to code comments?
 
> 
> Best Regards,
> Hao Wu
> 
> >
> > //
> > // Due to limited resource on VTd PEI DMA buffer size, driver limits
> > the // maximum transfer block number for 48-bit addressing.
> > // Setting to 0x800 here means 1M bytes for device with 512-byte block
> size.
> > //
> > #define MAX_48BIT_TRANSFER_BLOCK_NUM 0x800
> >
> >
> > > -Original Message-
> > > From: Wu, Hao A
> > > Sent: Tuesday, April 9, 2019 6:13 PM
> > > To: devel@edk2.groups.io
> > > Cc: Wu, Hao A ; Ni, Ray ;
> > > Dong, Eric ; Wang, Jian J
> > > 
> > > Subject: [PATCH v2 0/2] Add PEI BlockIO support for ATA AHCI mode
> > > devices
> > >
> > > The series is also available at:
> > > https://github.com/hwu25/edk2/tree/ahci_pei_blockio_v2
> > >
> > >
> > > V2 changges:
> > >
> > > Due to the file license change, rebase the whole series onto the tip
> > > of the master branch. The

Re: [edk2-devel] [PATCH] BaseTools/tools_def.template: Remove tools chain with ASL tool

Shenglei:
  Please also remove MS_ASL_ or WIN_ASL_ definitions in tools_def.template. 
After ASL tool chain is removed, those definitions will not be required. 

Thanks
Liming
> -Original Message-
> From: Zhang, Shenglei
> Sent: Tuesday, April 16, 2019 11:54 AM
> To: devel@edk2.groups.io
> Cc: Feng, Bob C ; Gao, Liming ; 
> Zhu, Yonghong 
> Subject: [PATCH] BaseTools/tools_def.template: Remove tools chain with ASL 
> tool
> 
> Microsoft ASL is not verified now.
> So remove tool chain with ASL tool. They are: VS2008xASL,
> VS2008x86xASL, VS2010xASL, VS2010x86xASL, VS2012xASL, VS2012x86xASL,
> VS2013xASL, VS2013x86xASL, VS2015xASL, VS2015x86xASL and CYGGCCxASL.
> https://bugzilla.tianocore.org/show_bug.cgi?id=1667
> 
> Cc: Bob Feng 
> Cc: Liming Gao 
> Cc: Yonghong Zhu 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Shenglei Zhang 
> ---
>  BaseTools/Conf/tools_def.template | 1254 -
>  1 file changed, 1254 deletions(-)
> 
> diff --git a/BaseTools/Conf/tools_def.template 
> b/BaseTools/Conf/tools_def.template
> index c1e5a57136..6a34fd82c7 100755
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -320,60 +320,6 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
>  # Required to build platforms or ACPI tables:
>  #   Intel(r) ACPI Compiler (iasl.exe) from
>  #   https://acpica.org/downloads
> -#   VS2008xASL  -win32-  Requires:
> -# Microsoft Visual Studio 2008 Team Suite
> -# Microsoft Windows Server 2003 Driver 
> Development Kit (Microsoft WINDDK) version 3790.1830
> -#Optional:
> -# Required to build EBC drivers:
> -#   Intel(r) Compiler for Efi Byte Code 
> (Intel(r) EBC Compiler)
> -# Required to build platforms or ACPI tables:
> -#   Microsoft ASL ACPI Compiler (asl.exe) v4.0.0 
> from
> -#
> http://download.microsoft.com/download/2/c/1/2c16c7e0-96c1-40f5-81fc-3e4bf7b65496/microsoft_asl_compiler-v4-0-0.msi
> -#   VS2010xASL  -win32-  Requires:
> -# Microsoft Visual Studio 2010 Premium Edition
> -# Microsoft Windows Server 2003 Driver 
> Development Kit (Microsoft WINDDK) version 3790.1830
> -#Optional:
> -# Required to build EBC drivers:
> -#   Intel(r) Compiler for Efi Byte Code 
> (Intel(r) EBC Compiler)
> -# Required to build platforms or ACPI tables:
> -#   Microsoft ASL ACPI Compiler (asl.exe) v4.0.0 
> from
> -#
> http://download.microsoft.com/download/2/c/1/2c16c7e0-96c1-40f5-81fc-3e4bf7b65496/microsoft_asl_compiler-v4-0-0.msi
> -#   VS2012xASL  -win32-  Requires:
> -# Microsoft Visual Studio 2012 Professional 
> Edition
> -# Microsoft Windows Server 2003 Driver 
> Development Kit (Microsoft WINDDK) version 3790.1830
> -#Optional:
> -# Required to build EBC drivers:
> -#   Intel(r) Compiler for Efi Byte Code 
> (Intel(r) EBC Compiler)
> -# Required to build platforms or ACPI tables:
> -#   Microsoft ASL ACPI Compiler (asl.exe) v4.0.0 
> from
> -#
> http://download.microsoft.com/download/2/c/1/2c16c7e0-96c1-40f5-81fc-3e4bf7b65496/microsoft_asl_compiler-v4-0-0.msi
> -#   VS2013xASL  -win32-  Requires:
> -# Microsoft Visual Studio 2013 Professional 
> Edition
> -# Microsoft Windows Server 2003 Driver 
> Development Kit (Microsoft WINDDK) version 3790.1830
> -#Optional:
> -# Required to build EBC drivers:
> -#   Intel(r) Compiler for Efi Byte Code 
> (Intel(r) EBC Compiler)
> -# Required to build platforms or ACPI tables:
> -#   Microsoft ASL ACPI Compiler (asl.exe) v4.0.0 
> from
> -#
> http://download.microsoft.com/download/2/c/1/2c16c7e0-96c1-40f5-81fc-3e4bf7b65496/microsoft_asl_compiler-v4-0-0.msi
> -#   VS2015xASL  -win32-  Requires:
> -# Microsoft Visual Studio 2015 Professional 
> Edition
> -# Microsoft Windows Server 2003 Driver 
> Development Kit (Microsoft WINDDK) version 3790.1830
> -#Optional:
> -# Required to build EBC drivers:
> -#   Intel(r) Compiler for Efi Byte Code 
> (Intel(r) EBC Compiler)
> -# Required to build platforms or ACPI tables:
> -#

Re: [edk2-devel] [PATCH 3/3] BaseTools: Remove ICC tool chain in tools_def.template