Re: [edk2] [PATCH 4/6] MdeModulePkg/FaultTolerantWriteDxe: implement standalone MM version

[Ard Biesheuvel]

On Thu, 10 Jan 2019 at 08:30, Zeng, Star  wrote:
>
> Hi Ard,
>
> Another minor feedback.
>
> On 2019/1/10 14:47, Zeng, Star wrote:
> > Hi Ard,
> >
> > Some minor feedback added inline.
> >
> > On 2019/1/4 2:28, Ard Biesheuvel wrote:
> >> Implement a new version of the fault tolerant write driver that can
> >> be used in the context of a standalone MM implementation.
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Ard Biesheuvel 
> >> ---
> >>
> >> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.c
> >> | 70 +++
> >>
> >> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf
> >> | 90 
> >>   2 files changed, 160 insertions(+)
>
> Please add it into MdeModulePkg.dsc for package build verification.
>

Hello Star,

Thanks for all the feedback. I will respond in more detail later.

However, to the point raised here: it is not possible to add these
drivers to MdeModulePkg.dsc unless we add a dummy implementation of
StandaloneMmDriverEntryPoint to MdeModulePkg. Do you think we should
do that?


> >>
> >> diff --git
> >> a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.c
> >> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.c
> >>
> >> new file mode 100644
> >> index ..b6fbf6c64f8a
> >> --- /dev/null
> >> +++
> >> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.c
> >>
> >> @@ -0,0 +1,70 @@
> >> +/** @file
> >> +
> >> +  Parts of the SMM/MM implementation that are specific to standalone MM
> >> +
> >> +Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
> >> +Copyright (c) 2018, Linaro, Ltd. All rights reserved.
> >> +This program and the accompanying materials
> >> +are licensed and made available under the terms and conditions of the
> >> BSD License
> >> +which accompanies this distribution.  The full text of the license
> >> may be found at
> >> +http://opensource.org/licenses/bsd-license.php
> >> +
> >> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> >> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
> >> IMPLIED.
> >> +
> >> +**/
> >> +
> >> +#include 
> >> +#include 
> >> +#include "FaultTolerantWrite.h"
> >> +#include "FaultTolerantWriteSmmCommon.h"
> >> +
> >> +BOOLEAN
> >> +FtwSmmIsBufferOutsideSmmValid (
> >> +  IN EFI_PHYSICAL_ADDRESS  Buffer,
> >> +  IN UINT64Length
> >> +  )
> >> +{
> >> +  return TRUE;
> >> +}
> >
> > Please add function comment header for it, otherwise some coding style
> > tool may report error.
> >
> >> +
> >> +/**
> >> +  Internal implementation of CRC32. Depending on the execution context
> >> +  (standalone SMM or DXE vs standalone MM), this function is implemented
> >> +  via a call to the CalculateCrc32 () boot service, or via a library
> >> +  call.
> >> +
> >> +  If Buffer is NULL, then ASSERT().
> >> +  If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
> >> +
> >> +  @param[in]  Buffer   A pointer to the buffer on which the
> >> 32-bit CRC is to be computed.
> >> +  @param[in]  Length   The number of bytes in the buffer Data.
> >> +
> >> +  @retval Crc32The 32-bit CRC was computed for the data
> >> buffer.
> >> +
> >> +**/
> >> +UINT32
> >> +FtwCalculateCrc32 (
> >> +  IN  VOID *Buffer,
> >> +  IN  UINTNLength
> >> +  )
> >> +{
> >> +  return CalculateCrc32 (Buffer, Length);
> >> +}
> >
> > Please add function comment header for it, otherwise some coding style
> > tool may report error.
> >
> >> +
> >> +VOID
> >> +FtwNotifySmmReady (
> >> +  VOID
> >> +  )
> >> +{
> >> +}
> >
> > Please add function comment header for it, otherwise some coding style
> > tool may report error.
> >
> > Thanks,
> > Star
> >
> >> +
> >> +EFI_STATUS
> >> +EFIAPI
> >> +StandaloneMmFaultTolerantWriteInitialize (
> >> +  IN EFI_HANDLEImageHandle,
> >> +  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
> >> +  )
> >> +{
> >> +  return MmFaultTolerantWriteInitialize ();
> >> +}
> >> diff --git
> >> a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf
> >> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf
> >>
> >> new file mode 100644
> >> index ..99bd62ad5ceb
> >> --- /dev/null
> >> +++
> >> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf
> >>
> >> @@ -0,0 +1,90 @@
> >> + ## @file
> >> +#   Fault Tolerant Write Smm Driver.
> >> +#
> >> +#   This driver installs SMM Fault Tolerant Write (FTW) protocol,
> >> which provides fault
> >> +#   tolerant write capability in SMM environment for block devices.
> >> Its implementation
> >> +#   depends on the full functionality SMM FVB protocol that support
> >> read, write/erase
> >> +#   flash access.
> >> +#
> >> +# Copyright (c) 2010 - 2018, Intel Corporation. All 

Re: [edk2] [PATCH 4/6] MdeModulePkg/FaultTolerantWriteDxe: implement standalone MM version

[Zeng, Star]

Hi Ard,

Another minor feedback.

On 2019/1/10 14:47, Zeng, Star wrote:

Hi Ard,

Some minor feedback added inline.

On 2019/1/4 2:28, Ard Biesheuvel wrote:

Implement a new version of the fault tolerant write driver that can
be used in the context of a standalone MM implementation.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
  
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.c   
| 70 +++
  
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf 
| 90 

  2 files changed, 160 insertions(+)


Please add it into MdeModulePkg.dsc for package build verification.

Thanks,
Star



diff --git 
a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.c 
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.c 


new file mode 100644
index ..b6fbf6c64f8a
--- /dev/null
+++ 
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.c 


@@ -0,0 +1,70 @@
+/** @file
+
+  Parts of the SMM/MM implementation that are specific to standalone MM
+
+Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2018, Linaro, Ltd. All rights reserved.
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the 
BSD License
+which accompanies this distribution.  The full text of the license 
may be found at

+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.

+
+**/
+
+#include 
+#include 
+#include "FaultTolerantWrite.h"
+#include "FaultTolerantWriteSmmCommon.h"
+
+BOOLEAN
+FtwSmmIsBufferOutsideSmmValid (
+  IN EFI_PHYSICAL_ADDRESS  Buffer,
+  IN UINT64    Length
+  )
+{
+  return TRUE;
+}


Please add function comment header for it, otherwise some coding style 
tool may report error.



+
+/**
+  Internal implementation of CRC32. Depending on the execution context
+  (standalone SMM or DXE vs standalone MM), this function is implemented
+  via a call to the CalculateCrc32 () boot service, or via a library
+  call.
+
+  If Buffer is NULL, then ASSERT().
+  If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
+
+  @param[in]  Buffer   A pointer to the buffer on which the 
32-bit CRC is to be computed.

+  @param[in]  Length   The number of bytes in the buffer Data.
+
+  @retval Crc32    The 32-bit CRC was computed for the data 
buffer.

+
+**/
+UINT32
+FtwCalculateCrc32 (
+  IN  VOID *Buffer,
+  IN  UINTN    Length
+  )
+{
+  return CalculateCrc32 (Buffer, Length);
+}


Please add function comment header for it, otherwise some coding style 
tool may report error.



+
+VOID
+FtwNotifySmmReady (
+  VOID
+  )
+{
+}


Please add function comment header for it, otherwise some coding style 
tool may report error.


Thanks,
Star


+
+EFI_STATUS
+EFIAPI
+StandaloneMmFaultTolerantWriteInitialize (
+  IN EFI_HANDLE    ImageHandle,
+  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
+  )
+{
+  return MmFaultTolerantWriteInitialize ();
+}
diff --git 
a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf 
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf 


new file mode 100644
index ..99bd62ad5ceb
--- /dev/null
+++ 
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf 


@@ -0,0 +1,90 @@
+ ## @file
+#   Fault Tolerant Write Smm Driver.
+#
+#   This driver installs SMM Fault Tolerant Write (FTW) protocol, 
which provides fault
+#   tolerant write capability in SMM environment for block devices. 
Its implementation
+#   depends on the full functionality SMM FVB protocol that support 
read, write/erase

+#   flash access.
+#
+# Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of 
the BSD License
+#  which accompanies this distribution. The full text of the license 
may be found at

+#  http://opensource.org/licenses/bsd-license.php
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS 
OR IMPLIED.

+#
+##
+
+[Defines]
+  INF_VERSION    = 0x0001001A
+  BASE_NAME  = FaultTolerantWriteStandaloneMm
+  FILE_GUID  = 3aade4ec-63cc-4a48-a928-5a374dd463eb
+  MODULE_TYPE    = MM_STANDALONE
+  VERSION_STRING = 1.0
+  PI_SPECIFICATION_VERSION   = 0x00010032
+  ENTRY_POINT    = 
StandaloneMmFaultTolerantWriteInitialize

+
+#
+# The following information is for reference only and not required by 
the build tools.

Re: [edk2] [PATCH 6/6] MdeModulePkg/VariableRuntimeDxe: implement standalone MM version

[Zeng, Star]

Hi Ard,

Some minor feedback added below.
With them handled, Reviewed-by: Sta Zeng .

On 2019/1/4 2:28, Ard Biesheuvel wrote:

Reuse most of the existing code to implement a variable runtime
driver that will be able to execute in the context of standalone
MM.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c   |  69 
++
  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf | 135 

  2 files changed, 204 insertions(+)


Please add it into MdeModulePkg.dsc for package build verification.



diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c
new file mode 100644
index ..fbc99467c057
--- /dev/null
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c
@@ -0,0 +1,69 @@
+/** @file
+
+  Parts of the SMM/MM implementation that are specific to standalone MM
+
+Copyright (c) 2011 - 2018, Intel Corporation. All rights reserved. 
+Copyright (c) 2018, Linaro, Ltd. All rights reserved. 
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD 
License
+which accompanies this distribution.  The full text of the license may be 
found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include "Variable.h"
+
+BOOLEAN
+VariableSmmIsBufferOutsideSmmValid (
+  IN EFI_PHYSICAL_ADDRESS  Buffer,
+  IN UINT64Length
+  )
+{
+  return TRUE;
+}


Please add function comment header for it.


+
+/**
+  Notify the system that the SMM variable driver is ready
+**/
+VOID
+VariableNotifySmmReady (
+  VOID
+  )
+{
+}
+
+/**
+  Notify the system that the SMM variable write driver is ready
+**/
+VOID
+VariableNotifySmmWriteReady (
+  VOID
+  )
+{
+}
+
+EFI_STATUS
+EFIAPI
+VariableServiceInitialize (
+  IN EFI_HANDLE   ImageHandle,
+  IN EFI_MM_SYSTEM_TABLE  *MmSystemTable
+  )
+{
+  return MmVariableServiceInitialize ();
+}


Please add function comment header for it.


+
+/**
+  Whether the TCG or TCG2 protocols are installed in the UEFI protocol 
database.
+  This information is used by the MorLock code to infer whether an existing
+  MOR variable is legitimate or not.


Add a line for return description?

Thanks,
Star


+**/
+BOOLEAN
+VariableHaveTcgProtocols (
+  VOID
+  )
+{
+  return FALSE;
+}
diff --git 
a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
new file mode 100644
index ..54d647af914c
--- /dev/null
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
@@ -0,0 +1,135 @@
+## @file
+#  Provides SMM variable service.
+#
+#  This module installs SMM variable protocol into SMM protocol database,
+#  which can be used by SMM driver, and installs SMM variable protocol
+#  into BS protocol database, which can be used to notify the SMM Runtime
+#  Dxe driver that the SMM variable service is ready.
+#  This module should be used with SMM Runtime DXE module together. The
+#  SMM Runtime DXE module would install variable arch protocol and variable
+#  write arch protocol based on SMM variable module.
+#
+#  Caution: This module requires additional review when modified.
+#  This driver will have external input - variable data and communicate buffer 
in SMM mode.
+#  This external input must be validated carefully to avoid security issues 
such as
+#  buffer overflow or integer overflow.
+#The whole SMM authentication variable design relies on the integrity of 
flash part and SMM.
+#  which is assumed to be protected by platform.  All variable code and 
metadata in flash/SMM Memory
+#  may not be modified without authorization. If platform fails to protect 
these resources,
+#  the authentication service provided in this driver will be broken, and the 
behavior is undefined.
+#
+# Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
+# This program and the accompanying materials
+# are licensed and made available under the terms and conditions of the BSD 
License
+# which accompanies this distribution. The full text of the license may be 
found at
+# http://opensource.org/licenses/bsd-license.php
+# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+#
+##
+
+[Defines]
+  INF_VERSION= 0x0001001A
+  BASE_NAME  = VariableStandaloneMm
+  FILE_GUID  = 7ee2c0c1-c21a-4113-a53a-66824a95696f
+  MODULE_TYPE= MM_STANDALONE
+  VERSION_STRING = 1.0
+  

Re: [edk2] [PATCH 5/6] MdeModulePkg/VariableRuntimeDxe: factor out boot service accesses

[Zeng, Star]

Hi Ard,

Some minor feedback added inline.

On 2019/1/4 2:28, Ard Biesheuvel wrote:

In preparation of providing a standalone MM based variable runtime
driver, move the existing SMM driver to the new MM services table,
and factor out some pieces that are specific to the traditional
driver, mainly related to the use of UEFI boot services, which are
not accessible to standalone MM drivers.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
  MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c |  18 +---
  MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h  |  50 
+
  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c   |  59 
--
  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf |   5 +-
  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableTraditionalMm.c | 114 

  5 files changed, 187 insertions(+), 59 deletions(-)

diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
index 28aa2893c6f8..009d96c3a65e 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
@@ -21,7 +21,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
  #include 
  #include 
  #include 
-#include 
  #include "Variable.h"
  
  typedef struct {

@@ -419,8 +418,6 @@ MorLockInitAtEndOfDxe (
  {
UINTN  MorSize;
EFI_STATUS MorStatus;
-  EFI_STATUS TcgStatus;
-  VOID   *TcgInterface;
  
if (!mMorLockInitializationRequired) {

  //
@@ -458,20 +455,7 @@ MorLockInitAtEndOfDxe (
  // can be deduced from the absence of the TCG / TCG2 protocols, as edk2's
  // MOR implementation depends on (one of) those protocols.
  //
-TcgStatus = gBS->LocateProtocol (
-   ,
-   NULL, // Registration
-   
-   );
-if (EFI_ERROR (TcgStatus)) {
-  TcgStatus = gBS->LocateProtocol (
- ,
- NULL,   // Registration
- 
- );
-}
-
-if (!EFI_ERROR (TcgStatus)) {
+if (VariableHaveTcgProtocols ()) {
//
// The MOR variable originates from the platform firmware; set the MOR
// Control Lock variable to report the locking capability to the OS.
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h
index 938eb5de61fa..11822575ac4d 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h
@@ -924,4 +924,54 @@ VariableExLibAtRuntime (
VOID
);
  
+/**

+  Notify the system that the SMM variable driver is ready
+**/
+VOID
+VariableNotifySmmReady (
+  VOID
+  );
+
+/**
+  Notify the system that the SMM variable write driver is ready
+**/
+VOID
+VariableNotifySmmWriteReady (
+  VOID
+  );
+
+/**
+  Variable service MM driver entry point
+**/
+EFI_STATUS
+EFIAPI
+MmVariableServiceInitialize (
+  VOID
+  );
+
+/**
+  This function check if the buffer is valid per processor architecture and 
not overlap with SMRAM.
+
+  @param Buffer  The buffer start address to be checked.
+  @param Length  The buffer length to be checked.
+
+  @retval TRUE  This buffer is valid per processor architecture and not 
overlap with SMRAM.
+  @retval FALSE This buffer is not valid per processor architecture or overlap 
with SMRAM.
+**/
+BOOLEAN
+VariableSmmIsBufferOutsideSmmValid (
+  IN EFI_PHYSICAL_ADDRESS  Buffer,
+  IN UINT64Length
+  );
+
+/**
+  Whether the TCG or TCG2 protocols are installed in the UEFI protocol 
database.
+  This information is used by the MorLock code to infer whether an existing
+  MOR variable is legitimate or not.


Add a line for return description?


+**/
+BOOLEAN
+VariableHaveTcgProtocols (
+  VOID
+  );
+
  #endif
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c
index 8c53f84ff6e8..7245587052df 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c
@@ -15,6 +15,7 @@
SmmVariableGetStatistics() should also do validation based on its own 
knowledge.
  
  Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.

+Copyright (c) 2018, Linaro, Ltd. All rights reserved.
  This program and the accompanying materials
  are licensed and made available under the terms and conditions of the BSD 
License
  which accompanies this distribution.  The full text of the license may be 
found at
@@ -28,18 +29,15 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
  #include 
  #include 
  #include 
-#include 
+#include 
  

Re: [edk2] [PATCH 5/6] MdeModulePkg/VariableRuntimeDxe: factor out boot service accesses

[Zeng, Star]

On 2019/1/10 10:33, Wang, Jian J wrote:

Laszlo,

Regards,
Jian


-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Tuesday, January 08, 2019 11:38 PM
To: Ard Biesheuvel ; edk2-devel@lists.01.org
Cc: Leif Lindholm ; Kinney, Michael D
; Gao, Liming ; Wang,
Jian J ; Wu, Hao A ; Jagadeesh
Ujja ; Achin Gupta ;
Thomas Panakamattam Abraham ; Sami Mujawar

Subject: Re: [PATCH 5/6] MdeModulePkg/VariableRuntimeDxe: factor out boot
service accesses

On 01/03/19 19:28, Ard Biesheuvel wrote:

In preparation of providing a standalone MM based variable runtime
driver, move the existing SMM driver to the new MM services table,
and factor out some pieces that are specific to the traditional
driver, mainly related to the use of UEFI boot services, which are
not accessible to standalone MM drivers.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
  MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c |  18

+---

  MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h  |  50

+

  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c   |  59

--

  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf |   5 +-
  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableTraditionalMm.c |

114 

  5 files changed, 187 insertions(+), 59 deletions(-)


I *vaguely* feel like we should extract the new functions to
"PrivilegePolymorphic.h", rather than to "Variable.h".

Please see initial commit 00663d047fc9
("MdeModulePkg/Variable/RuntimeDxe: move SecureBootHook() decl to new
header", 2017-10-10), and other commits that touched that file.

I realize this is not a 100% "constructive" suggestion, and I feel
appropriately bad about that. It's just that "Variable.h" has so many
internals that I feel it's not a good dumping ground for these new
functions. And the other header we have, looks closer in purpose.

For example, MorLockInitAtEndOfDxe() is already declared in
"PrivilegePolymorphic.h" (see commit f1304280435f,
"MdeModulePkg/Variable/RuntimeDxe: introduce MorLockInitAtEndOfDxe()
hook", 2017-10-10).

Admittedly, now that we're going to have three separate builds of this
driver, dedicating a separate header file to each "shared between A and
B" relationship is getting a bit too complex. In retrospect, introducing
"PrivilegePolymorphic.h" may not have been a "scalable" idea, after all,
and I should have just dumped those functions all in "Variable.h".

IOW, I think
- targeting "Variable.h" now is inconsistent with earlier code,
- extending "PrivilegePolymorphic.h" is also suboptimal (although still
better than the previous option),
- adding yet another header might be technically correct, but it would
be over-engineering,
- asking you to merge "PrivilegePolymorphic.h" back into "Variable.h"
feels awkward, especially after I argued *for* "PrivilegePolymorphic.h"
at length, when I originally introduced it. :/

Sigh. Can the variable driver maintainers comment please?

(I still plan to regression-test this series, but I feel like I should
force myself to at least skim the variable driver patches, beyond
testing them. Because, next time I can't avoid working with this very
complex driver, I wouldn't like to be *completely* lost.)



I agree "PrivilegePolymorphic.h" is more appropriate place for them.
Maybe Star have different opinion.


At current situation, I prefer PrivilegePolymorphic.h. :)

Some minor feedback will be added in another reply.

Thanks,
Star




Thanks,
Laszlo


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

Re: [edk2] [PATCH 2/6] MdePkg: implement MmServicesTableLib based on traditional SMM

[Zeng, Star]

Hi Ard,

Another minor feedback.

On 2019/1/10 14:14, Zeng, Star wrote:

Hi Ard,

Some minor feedback added inline.

On 2019/1/4 2:28, Ard Biesheuvel wrote:

The definitions of the rebranded MM protocol stack were chosen such
that the existing SMM based core drivers can be reused. So let's
implement MmServicesTableLib based on gEfiMmBaseProtocolGuid, which
is simply gEfiSmmBase2ProtocolGuid under the hood.


Good commit log.



Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
  MdePkg/Library/MmServicesTableLib/MmServicesTableLib.c   | 63 

  MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf | 45 
++

  MdePkg/Library/MmServicesTableLib/MmServicesTableLib.uni | 22 +++
  MdePkg/MdePkg.dsc    |  1 +
  4 files changed, 131 insertions(+)

diff --git a/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.c 
b/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.c

new file mode 100644
index ..f41d25e59805
--- /dev/null
+++ b/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.c
@@ -0,0 +1,63 @@
+/** @file
+  MM Services Table Library.
+
+  Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2018, Linaro, Ltd. All rights reserved.
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of 
the BSD License
+  which accompanies this distribution.  The full text of the license 
may be found at

+  http://opensource.org/licenses/bsd-license.php.
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS 
OR IMPLIED.

+
+**/
+
+#include 
+#include 
+#include 
+#include 
+
+EFI_MM_SYSTEM_TABLE   *gMmst = NULL;
+
+/**
+  The constructor function caches the pointer of SMM Services Table.


Use "MM" instead of "SMM" here?

Thanks,
Star


+
+  @param  ImageHandle   The firmware allocated handle for the EFI image.
+  @param  SystemTable   A pointer to the EFI System Table.
+
+  @retval EFI_SUCCESS   The constructor always returns EFI_SUCCESS.
+
+**/
+EFI_STATUS
+EFIAPI
+MmServicesTableLibConstructor (
+  IN EFI_HANDLE    ImageHandle,
+  IN EFI_SYSTEM_TABLE  *SystemTable
+  )
+{
+  EFI_STATUS  Status;
+  EFI_MM_BASE_PROTOCOL    *InternalMmBase;
+
+  InternalMmBase = NULL;
+  //
+  // Retrieve MM Base Protocol,  Do not use gBS from 
UefiBootServicesTableLib on purpose
+  // to prevent inclusion of gBS, gST, and gImageHandle from SMM 
Drivers unless the

+  // MM driver explicity declares that dependency.
+  //
+  Status = SystemTable->BootServices->LocateProtocol (
+    ,
+    NULL,
+    (VOID **)
+    );
+  ASSERT_EFI_ERROR (Status);
+  ASSERT (InternalMmBase != NULL);
+
+  //
+  // We are in MM, retrieve the pointer to MM System Table
+  //
+  InternalMmBase->GetMmstLocation (InternalMmBase, );
+  ASSERT (gMmst != NULL);
+
+  return EFI_SUCCESS;
+}
diff --git a/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf 
b/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf

new file mode 100644
index ..4418cc2f1464
--- /dev/null
+++ b/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
@@ -0,0 +1,45 @@
+## @file
+# MM Services Table Library.
+#
+# Copyright (c) 2009 - 2014, Intel Corporation. All rights reserved.
+# Copyright (c) 2018, Linaro, Ltd. All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of 
the BSD License
+#  which accompanies this distribution. The full text of the license 
may be found at

+#  http://opensource.org/licenses/bsd-license.php.
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS 
OR IMPLIED.

+#
+#
+##
+
+[Defines]
+  INF_VERSION    = 0x0001001B
+  BASE_NAME  = MmServicesTableLib
+  MODULE_UNI_FILE    = MmServicesTableLib.uni
+  FILE_GUID  = 9508ECFD-66D1-4B4C-9415-F25F0FFF9E93
+  MODULE_TYPE    = DXE_SMM_DRIVER
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = MmServicesTableLib|DXE_SMM_DRIVER
+  PI_SPECIFICATION_VERSION   = 0x00010032
+  CONSTRUCTOR    = MmServicesTableLibConstructor
+
+#
+#  VALID_ARCHITECTURES   = IA32 X64 ARM AARCH64
+#
+
+[Sources]
+  MmServicesTableLib.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+
+[LibraryClasses]
+  DebugLib
+
+[Protocols]
+  gEfiMmBaseProtocolGuid  ## CONSUMES
+
+[Depex]
+  gEfiMmBaseProtocolGuid
diff --git a/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.uni 
b/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.uni

new file 

Re: [edk2] [PATCH 4/6] MdeModulePkg/FaultTolerantWriteDxe: implement standalone MM version

[Zeng, Star]

Hi Ard,

Some minor feedback added inline.

On 2019/1/4 2:28, Ard Biesheuvel wrote:

Implement a new version of the fault tolerant write driver that can
be used in the context of a standalone MM implementation.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.c 
  | 70 +++
  
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf 
| 90 
  2 files changed, 160 insertions(+)

diff --git 
a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.c 
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.c
new file mode 100644
index ..b6fbf6c64f8a
--- /dev/null
+++ 
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.c
@@ -0,0 +1,70 @@
+/** @file
+
+  Parts of the SMM/MM implementation that are specific to standalone MM
+
+Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2018, Linaro, Ltd. All rights reserved.
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD 
License
+which accompanies this distribution.  The full text of the license may be 
found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include 
+#include 
+#include "FaultTolerantWrite.h"
+#include "FaultTolerantWriteSmmCommon.h"
+
+BOOLEAN
+FtwSmmIsBufferOutsideSmmValid (
+  IN EFI_PHYSICAL_ADDRESS  Buffer,
+  IN UINT64Length
+  )
+{
+  return TRUE;
+}


Please add function comment header for it, otherwise some coding style 
tool may report error.



+
+/**
+  Internal implementation of CRC32. Depending on the execution context
+  (standalone SMM or DXE vs standalone MM), this function is implemented
+  via a call to the CalculateCrc32 () boot service, or via a library
+  call.
+
+  If Buffer is NULL, then ASSERT().
+  If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
+
+  @param[in]  Buffer   A pointer to the buffer on which the 32-bit CRC is 
to be computed.
+  @param[in]  Length   The number of bytes in the buffer Data.
+
+  @retval Crc32The 32-bit CRC was computed for the data buffer.
+
+**/
+UINT32
+FtwCalculateCrc32 (
+  IN  VOID *Buffer,
+  IN  UINTNLength
+  )
+{
+  return CalculateCrc32 (Buffer, Length);
+}


Please add function comment header for it, otherwise some coding style 
tool may report error.



+
+VOID
+FtwNotifySmmReady (
+  VOID
+  )
+{
+}


Please add function comment header for it, otherwise some coding style 
tool may report error.


Thanks,
Star


+
+EFI_STATUS
+EFIAPI
+StandaloneMmFaultTolerantWriteInitialize (
+  IN EFI_HANDLEImageHandle,
+  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
+  )
+{
+  return MmFaultTolerantWriteInitialize ();
+}
diff --git 
a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf
 
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf
new file mode 100644
index ..99bd62ad5ceb
--- /dev/null
+++ 
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf
@@ -0,0 +1,90 @@
+ ## @file
+#   Fault Tolerant Write Smm Driver.
+#
+#   This driver installs SMM Fault Tolerant Write (FTW) protocol, which 
provides fault
+#   tolerant write capability in SMM environment for block devices. Its 
implementation
+#   depends on the full functionality SMM FVB protocol that support read, 
write/erase
+#   flash access.
+#
+# Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution. The full text of the license may be 
found at
+#  http://opensource.org/licenses/bsd-license.php
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+##
+
+[Defines]
+  INF_VERSION= 0x0001001A
+  BASE_NAME  = FaultTolerantWriteStandaloneMm
+  FILE_GUID  = 3aade4ec-63cc-4a48-a928-5a374dd463eb
+  MODULE_TYPE= MM_STANDALONE
+  VERSION_STRING = 1.0
+  PI_SPECIFICATION_VERSION   = 0x00010032
+  ENTRY_POINT= StandaloneMmFaultTolerantWriteInitialize
+
+#
+# The following information is for reference only and not required by the 
build tools.
+#
+#  VALID_ARCHITECTURES   = AARCH64
+#
+
+[Sources]
+  FtwMisc.c
+  UpdateWorkingBlock.c
+  FaultTolerantWrite.c
+  FaultTolerantWriteStandaloneMm.c
+  

Re: [edk2] [PATCH 3/6] MdeModulePkg/FaultTolerantWriteDxe: factor out boot service accesses

[Zeng, Star]

Hi Ard,

Some minor feedback added inline.

On 2019/1/4 2:28, Ard Biesheuvel wrote:

In preparation of providing a standalone MM based FTW driver, move
the existing SMM driver to the new MM services table, and factor out
some pieces that are specific to the traditional driver, mainly
related to the use of UEFI boot services, which are not accessible
to standalone MM drivers.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
  MdeModulePkg/MdeModulePkg.dsc 
 |  1 +
  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWrite.h 
 | 22 -
  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c  
 | 31 +++
  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c  
 | 54 +--
  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf
 |  5 +-
  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmmCommon.h
 | 31 +++
  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmmDxe.c   
 |  1 +
  
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteTraditionalMm.c 
| 94 
  MdeModulePkg/Universal/FaultTolerantWriteDxe/UpdateWorkingBlock.c 
 | 10 +--
  9 files changed, 205 insertions(+), 44 deletions(-)

diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
index 5d042be3a862..ef3c144ed524 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -153,6 +153,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
DebugLib|MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf

MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLib/SmmMemoryAllocationLib.inf

SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
+  MmServicesTableLib|MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf
SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
  
diff --git a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWrite.h b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWrite.h

index 844cf3bee04d..8d146264b129 100644
--- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWrite.h
+++ b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWrite.h
@@ -31,7 +31,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
  #include 
  #include 
  #include 
-#include 
  #include 
  
  //

@@ -766,4 +765,25 @@ WriteWorkSpaceData (
IN UINT8  *Buffer
);
  
+/**

+  Internal implementation of CRC32. Depending on the execution context
+  (traditional SMM or DXE vs standalone MM), this function is implemented
+  via a call to the CalculateCrc32 () boot service, or via a library
+  call.
+
+  If Buffer is NULL, then ASSERT().
+  If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
+
+  @param[in]  Buffer   A pointer to the buffer on which the 32-bit CRC is 
to be computed.
+  @param[in]  Length   The number of bytes in the buffer Data.
+
+  @retval Crc32The 32-bit CRC was computed for the data buffer.
+
+**/
+UINT32
+FtwCalculateCrc32 (
+  IN  VOID *Buffer,
+  IN  UINTNLength
+  );
+
  #endif
diff --git 
a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c 
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
index 094e40f9d86c..24e507104bbe 100644
--- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
+++ b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
@@ -51,6 +51,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
  
  **/
  
+#include 

  #include "FaultTolerantWrite.h"
  EFI_EVENT mFvbRegistration = NULL;
  
@@ -250,3 +251,33 @@ FaultTolerantWriteInitialize (
  
return EFI_SUCCESS;

  }
+
+/**
+  Internal implementation of CRC32. Depending on the execution context
+  (traditional SMM or DXE vs standalone MM), this function is implemented
+  via a call to the CalculateCrc32 () boot service, or via a library
+  call.
+
+  If Buffer is NULL, then ASSERT().
+  If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
+
+  @param[in]  Buffer   A pointer to the buffer on which the 32-bit CRC is 
to be computed.
+  @param[in]  Length   The number of bytes in the buffer Data.
+
+  @retval Crc32The 32-bit CRC was computed for the data buffer.
+
+**/
+UINT32
+FtwCalculateCrc32 (
+  IN  VOID *Buffer,
+  IN  UINTNLength
+  )
+{
+  EFI_STATUSStatus;
+  UINT32ReturnValue;
+
+  Status = gBS->CalculateCrc32 (Buffer, Length, );
+  ASSERT_EFI_ERROR (Status);
+
+  return ReturnValue;
+}
diff --git 

Re: [edk2] [PATCH 4/6] MdeModulePkg/FaultTolerantWriteDxe: implement standalone MM version

[Zeng, Star]

On 2019/1/10 9:41, Wang, Jian J wrote:

Ard,


Regards,
Jian



-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Friday, January 04, 2019 2:28 AM
To: edk2-devel@lists.01.org
Cc: Ard Biesheuvel ; Laszlo Ersek
; Leif Lindholm ; Kinney,
Michael D ; Gao, Liming ;
Wang, Jian J ; Wu, Hao A ;
Jagadeesh Ujja ; Achin Gupta
; Thomas Panakamattam Abraham
; Sami Mujawar 
Subject: [PATCH 4/6] MdeModulePkg/FaultTolerantWriteDxe: implement
standalone MM version

Implement a new version of the fault tolerant write driver that can
be used in the context of a standalone MM implementation.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---

MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandalon
eMm.c   | 70 +++

MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandalon
eMm.inf | 90 
  2 files changed, 160 insertions(+)

diff --git
a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
oneMm.c
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
oneMm.c
new file mode 100644
index ..b6fbf6c64f8a
--- /dev/null
+++
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
oneMm.c
@@ -0,0 +1,70 @@
+/** @file
+
+  Parts of the SMM/MM implementation that are specific to standalone MM
+
+Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2018, Linaro, Ltd. All rights reserved.
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD
License
+which accompanies this distribution.  The full text of the license may be found
at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS
OR IMPLIED.
+
+**/
+
+#include 
+#include 
+#include "FaultTolerantWrite.h"
+#include "FaultTolerantWriteSmmCommon.h"
+
+BOOLEAN
+FtwSmmIsBufferOutsideSmmValid (
+  IN EFI_PHYSICAL_ADDRESS  Buffer,
+  IN UINT64Length
+  )
+{
+  return TRUE;
+}
+
+/**
+  Internal implementation of CRC32. Depending on the execution context
+  (standalone SMM or DXE vs standalone MM), this function is implemented
+  via a call to the CalculateCrc32 () boot service, or via a library
+  call.
+
+  If Buffer is NULL, then ASSERT().
+  If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
+
+  @param[in]  Buffer   A pointer to the buffer on which the 32-bit CRC is 
to be
computed.
+  @param[in]  Length   The number of bytes in the buffer Data.
+
+  @retval Crc32The 32-bit CRC was computed for the data buffer.
+
+**/
+UINT32
+FtwCalculateCrc32 (
+  IN  VOID *Buffer,
+  IN  UINTNLength
+  )
+{
+  return CalculateCrc32 (Buffer, Length);
+}
+
+VOID
+FtwNotifySmmReady (
+  VOID
+  )
+{
+}
+
+EFI_STATUS
+EFIAPI
+StandaloneMmFaultTolerantWriteInitialize (
+  IN EFI_HANDLEImageHandle,
+  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
+  )
+{
+  return MmFaultTolerantWriteInitialize ();
+}
diff --git
a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
oneMm.inf
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
oneMm.inf
new file mode 100644
index ..99bd62ad5ceb
--- /dev/null
+++
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
oneMm.inf
@@ -0,0 +1,90 @@
+ ## @file
+#   Fault Tolerant Write Smm Driver.
+#
+#   This driver installs SMM Fault Tolerant Write (FTW) protocol, which 
provides
fault
+#   tolerant write capability in SMM environment for block devices. Its
implementation
+#   depends on the full functionality SMM FVB protocol that support read,
write/erase
+#   flash access.
+#
+# Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD
License
+#  which accompanies this distribution. The full text of the license may be 
found
at
+#  http://opensource.org/licenses/bsd-license.php
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
EXPRESS OR IMPLIED.
+#
+##
+
+[Defines]
+  INF_VERSION= 0x0001001A
+  BASE_NAME  = FaultTolerantWriteStandaloneMm
+  FILE_GUID  = 3aade4ec-63cc-4a48-a928-5a374dd463eb
+  MODULE_TYPE= MM_STANDALONE
+  VERSION_STRING = 1.0
+  PI_SPECIFICATION_VERSION   = 0x00010032
+  ENTRY_POINT= StandaloneMmFaultTolerantWriteInitialize
+
+#
+# The following information is for reference only and not required by the build
tools.
+#
+#  VALID_ARCHITECTURES   = AARCH64
+#
+
+[Sources]
+  FtwMisc.c
+  UpdateWorkingBlock.c
+  

Re: [edk2] [PATCH 2/6] MdePkg: implement MmServicesTableLib based on traditional SMM

[Zeng, Star]

Hi Ard,

Some minor feedback added inline.

On 2019/1/4 2:28, Ard Biesheuvel wrote:

The definitions of the rebranded MM protocol stack were chosen such
that the existing SMM based core drivers can be reused. So let's
implement MmServicesTableLib based on gEfiMmBaseProtocolGuid, which
is simply gEfiSmmBase2ProtocolGuid under the hood.


Good commit log.



Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
  MdePkg/Library/MmServicesTableLib/MmServicesTableLib.c   | 63 

  MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf | 45 ++
  MdePkg/Library/MmServicesTableLib/MmServicesTableLib.uni | 22 +++
  MdePkg/MdePkg.dsc|  1 +
  4 files changed, 131 insertions(+)

diff --git a/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.c 
b/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.c
new file mode 100644
index ..f41d25e59805
--- /dev/null
+++ b/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.c
@@ -0,0 +1,63 @@
+/** @file
+  MM Services Table Library.
+
+  Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2018, Linaro, Ltd. All rights reserved.
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php.
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+
+EFI_MM_SYSTEM_TABLE   *gMmst = NULL;
+
+/**
+  The constructor function caches the pointer of SMM Services Table.
+
+  @param  ImageHandle   The firmware allocated handle for the EFI image.
+  @param  SystemTable   A pointer to the EFI System Table.
+
+  @retval EFI_SUCCESS   The constructor always returns EFI_SUCCESS.
+
+**/
+EFI_STATUS
+EFIAPI
+MmServicesTableLibConstructor (
+  IN EFI_HANDLEImageHandle,
+  IN EFI_SYSTEM_TABLE  *SystemTable
+  )
+{
+  EFI_STATUS  Status;
+  EFI_MM_BASE_PROTOCOL*InternalMmBase;
+
+  InternalMmBase = NULL;
+  //
+  // Retrieve MM Base Protocol,  Do not use gBS from UefiBootServicesTableLib 
on purpose
+  // to prevent inclusion of gBS, gST, and gImageHandle from SMM Drivers 
unless the
+  // MM driver explicity declares that dependency.
+  //
+  Status = SystemTable->BootServices->LocateProtocol (
+,
+NULL,
+(VOID **)
+);
+  ASSERT_EFI_ERROR (Status);
+  ASSERT (InternalMmBase != NULL);
+
+  //
+  // We are in MM, retrieve the pointer to MM System Table
+  //
+  InternalMmBase->GetMmstLocation (InternalMmBase, );
+  ASSERT (gMmst != NULL);
+
+  return EFI_SUCCESS;
+}
diff --git a/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf 
b/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
new file mode 100644
index ..4418cc2f1464
--- /dev/null
+++ b/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
@@ -0,0 +1,45 @@
+## @file
+# MM Services Table Library.
+#
+# Copyright (c) 2009 - 2014, Intel Corporation. All rights reserved.
+# Copyright (c) 2018, Linaro, Ltd. All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution. The full text of the license may be 
found at
+#  http://opensource.org/licenses/bsd-license.php.
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+#
+##
+
+[Defines]
+  INF_VERSION= 0x0001001B
+  BASE_NAME  = MmServicesTableLib
+  MODULE_UNI_FILE= MmServicesTableLib.uni
+  FILE_GUID  = 9508ECFD-66D1-4B4C-9415-F25F0FFF9E93
+  MODULE_TYPE= DXE_SMM_DRIVER
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = MmServicesTableLib|DXE_SMM_DRIVER
+  PI_SPECIFICATION_VERSION   = 0x00010032
+  CONSTRUCTOR= MmServicesTableLibConstructor
+
+#
+#  VALID_ARCHITECTURES   = IA32 X64 ARM AARCH64
+#
+
+[Sources]
+  MmServicesTableLib.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+
+[LibraryClasses]
+  DebugLib
+
+[Protocols]
+  gEfiMmBaseProtocolGuid  ## CONSUMES
+
+[Depex]
+  gEfiMmBaseProtocolGuid
diff --git a/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.uni 
b/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.uni
new file mode 100644
index ..2b2c7e14024c
--- /dev/null
+++ b/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.uni
@@ -0,0 +1,22 

[edk2] A question about shell-application's argument make system blocked;

[krishnaLee]

Hi everybody,
I meet a question,a special arg can make system blocked,follow is my steps.
1,go to uefi shell v2.2(uefi v2.70),run this application in QEMU-ovmf:
testapp.efi
2,the output is "index:0,string:FS0:\testapp.efi"


3,testapp.efi #abc.
4,the output is same as step 2.  ///< I had read the uefi shell specification 
2.2,the '#' is a comment remark,so I think it is ok.


5 testapp.efi "#abc"
6,the system blocked(dead).  ///< I think it is a bug.


//follow is the testapp.efi source code:
EFI_STATUS
EFIAPI
UefiMain (
IN EFI_HANDLE ImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
)
{
EFI_STATUS status;
EFI_SHELL_PARAMETERS_PROTOCOL* param;
status=SystemTable->BootServices->HandleProtocol(ImageHandle,,);
if(status!=EFI_SUCCESS)
{
return0;
}


for(UINTN i=0;i< param->Argc;i++)
{
Print(L"index:%d,string:%s\n",i,param->Argv[i]);
}


return EFI_SUCCESS;
}


//test environment:
//QEMU v2.10.95 + edk2-2018-ovmf-x64.
//shell command line:
//"D:\qemu\qemu-system-x86_64.exe" -machine pc-q35-2.9 -pflash 
"D:\qemu\bios\OVMF_x64_debug.fd" -serial stdio -hda fat:rw:G:\temp -net none
//end






thanks,
krishna.



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

Re: [edk2] [PATCH 1/6] MdePkg/Include: add MmServicesTableLib header file

[Zeng, Star]

Hi Ard,

Some feedback added inline.

On 2019/1/4 2:28, Ard Biesheuvel wrote:

From: Jagadeesh Ujja 

SMM has been rebranded as MM, and can be implemented in traditional
mode or standalone mode, using the same prototype for the services
table. Expose this table via MmServicesTableLib, permitting the
respective implementations to expose a traditional or standalone
version.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jagadeesh Ujja 
Signed-off-by: Ard Biesheuvel 
---
  MdePkg/Include/Library/MmServicesTableLib.h | 25 
  MdePkg/MdePkg.dec   |  4 
  2 files changed, 29 insertions(+)

diff --git a/MdePkg/Include/Library/MmServicesTableLib.h 
b/MdePkg/Include/Library/MmServicesTableLib.h
new file mode 100644
index ..12bd01e98641
--- /dev/null
+++ b/MdePkg/Include/Library/MmServicesTableLib.h
@@ -0,0 +1,25 @@
+/** @file
+  Provides a service to retrieve a pointer to the Standalone MM Services Table.
+  Only available to Standalone MM module types.


This line should be "Only available to MM_STANDALONE, SMM/DXE Combined 
and SMM module types." to match the comments added in MdePkg.dec for 
this library class, right?


With it handled, Reviewed-by: Star Zeng 

Thanks,
Star

+
+Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
+
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD 
License
+which accompanies this distribution.  The full text of the license may be 
found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __MM_SERVICES_TABLE_LIB_H__
+#define __MM_SERVICES_TABLE_LIB_H__
+
+#include 
+
+extern EFI_MM_SYSTEM_TABLE *gMmst;
+
+#endif
diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 712bd46dd3d3..a7383b6daafb 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -243,6 +243,10 @@ [LibraryClasses]
##
SafeIntLib|Include/Library/SafeIntLib.h
  
+  ## @libraryclass Provides a service to retrieve a pointer to the Standalone MM Services Table.

+  #Only available to MM_STANDALONE, SMM/DXE Combined and SMM 
module types.
+  MmServicesTableLib|Include/Library/MmServicesTableLib.h
+
  [LibraryClasses.IA32, LibraryClasses.X64]
##  @libraryclass  Abstracts both S/W SMI generation and detection.
##



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

Re: [edk2] Conditional Compilation support in INF file

[KarunakarPoosapalli]

Hi All,

I agree with providing the support like "FixedAtBuild PCD in INF". And we need 
to modify or provide support in BaseTools to support this feature.

There are more use cases or flexibility to developer if we support Conditional 
compilation support in INF.
As we're providing support in BaseTools for FixedAtBuild PCD support in INF, Is 
there any challenges or drawbacks in  providing conditional compilation support 
in INF?  

Thanks & Regards,
Karunakar

-Original Message-
From: Gao, Liming [mailto:liming@intel.com] 
Sent: Wednesday, January 9, 2019 6:12 PM
To: Laszlo Ersek; Poosapalli, Karunakar; edk2-devel@lists.01.org
Subject: RE: [edk2] Conditional Compilation support in INF file


[EXTERNAL EMAIL] 

Laszlo:
  INF Spec: FixedAtBuild (VOID*) PCD use in the [DEPEX] section has been added 
into INF spec git book 
(g...@github.com:tianocore-docs/edk2-InfSpecification.git). BZ 
https://bugzilla.tianocore.org/show_bug.cgi?id=444
  The change is in INF spec trunk. New version INF spec will include it. 

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Laszlo Ersek
> Sent: Wednesday, January 9, 2019 7:00 PM
> To: karunakarpoosapa...@dell.com; edk2-devel@lists.01.org
> Subject: Re: [edk2] Conditional Compilation support in INF file
> 
> On 01/09/19 07:55, karunakarpoosapa...@dell.com wrote:
> > Hi ALL,
> >
> >
> >
> > I've an idea regards "Adding conditional compilation  support in INF files"
> >
> >
> >
> > Ides is like, we can condition check in INF file like below
> >
> >
> >
> > #if Condition1
> >
> >Protocol1
> >
> > #elif Condition2
> >
> >Protocol2
> >
> > #else
> >
> >Protocol3
> >
> > #endif
> >
> >
> >
> > If we've this support we can add different protocols in DEPEX 
> > section, Like we can put condition check and add rotococol1 for
> Notebook and Protocol2 for Desktop.
> >
> > And will have so many benefits adding this support.
> >
> >
> >
> > I don't think current EDK2 support this.
> >
> > Please let me know comments/suggestions, so that I will start working on it.
> 
> I'm not sure this feature is really required. We already have the 
> following tools at our disposal, to customize module builds at the INF 
> file level:
> 
> (1) Please see .
> (Unfortunately, the INF file spec doesn't seem to document the syntax; 
> 
> should help however.)
> 
> (2) If the number of cases that need to be distinguished is low, it's 
> possible to duplicate the INF file, keep the [Sources] section(s) and 
> similar sections identical, and only customize the sections that need 
> changes. Then include the right INF file in the platform DSC and FDF 
> files, dependent on PCD settings or build defines (macros).
> 
> (3) Sometimes it makes sense to delay the dispatching of a module 
> until another module makes a decision about a platform feature, dynamically.
> An important characteristic of this case is that the dependent module 
> should not be prevented from starting *completely* in case the 
> platform feature is absent; it should only be made wait until the 
> decision is recorded, by the other module. This way the dependent 
> module will not incorrectly customize its own behavior before the 
> decision on the platform feature is made.
> 
> In this case, it's usually possible to write the depex such as
> 
>   (gProtocolGuid1 AND gProtocolGuid2) OR
>   (gProtocolGuid3 AND gProtocolGuid4) OR
>   gThisParticularFeatureDisabledProtocolGuid
> 
> Here:
> - gProtocolGuid1 and gProtocolGuid2 could be specific to "Notebook",
> - gProtocolGuid3 and gProtocolGuid4 could be specific to "Desktop",
> - and gThisParticularFeatureDisabledProtocolGuid would be a 
> *synthetic* protocol GUID -- installed in the protocol database with a 
> NULL interface -- through which the decision-making module would 
> simply advertize, "none of the relevant features are available, and 
> you need not wait any longer".
> 
> "gThisParticularFeatureDisabledProtocolGuid" is usually defined / 
> declared as a platform Pkg-specific GUID, in the appropriate DEC file, 
> and in Include/Guid/, under the same Pkg.
> 
> (4) It is possible to hook such dependencies into other (core) modules.
> In the platform Package, you can implement a library that (a) has an 
> empty constructor function, and (b) the DEPEX of your choosing (see 
> above). The library should do nothing else. Then, in the package DSC 
> file, hook the library into the core module in question via NULL class 
> resolution. As a result, the library will not alter the behavior of 
> the core module, but the core module will inherit the depex (it will 
> be AND-ed together with other dependencies that the core module might have).
> 
> Thanks
> Laszlo
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> 

Re: [edk2] [Patch 1/3] UefiCpuPkg/RegisterCpuFeaturesLib: Avoid AP calls PeiService.

[Dong, Eric]

Hi  Laszlo,

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, January 9, 2019 6:35 PM
> To: Dong, Eric 
> Cc: Brian J. Johnson ; Yao, Jiewen
> ; Ni, Ray ; edk2-
> de...@lists.01.org; Kinney, Michael D 
> Subject: Re: [edk2] [Patch 1/3] UefiCpuPkg/RegisterCpuFeaturesLib: Avoid
> AP calls PeiService.
> 
> Hi Eric,
> 
> On 01/09/19 06:26, Dong, Eric wrote:
> > Hi all,
> >
> > We got some feedback about this BZ. Someone think this timeout is
> valuable for the debug purpose, and oppose to remove it.
> > https://bugzilla.tianocore.org/show_bug.cgi?id=1419
> >
> > So I'm back to here and want to still use this change. I not use "update
> PcdSpinLockTimeout to 0 in platform" solution because I think core driver
> depends on platform policy is not a good design.
> >
> > Do you guys have any other concern?
> 
> sorry, I don't understand.
> 
> (1) In , where
> currently comment #2 is the last comment, I don't see any request for
> keeping the timeout facility.

Please check Ray's comments I discussed with him offline.

> 
> (2) On the mailing list as well, you seem to have received comments only in
> favor of removing the timeout facility.
> 
> "Someone think this timeout is valuable for the debug purpose" doesn't cut
> it, for open development. I don't care about the identity of the person that
> wants to preserve the feature, but I certainly care about their use case. You
> shouldn't have to mediate and describe their use case for them, on the list;
> that's always a lossy process.
> 

Please check Ray's comments I discussed with him offline.

> Regarding the PCD: I think zeroing "PcdSpinLockTimeout" to disable the
> timeout case is a valid approach, it's just that we should change the default
> value in the DEC file to zero. Then the PCD setting will become a burden only
> for those platforms and those use cases that want to use the timeout
> feature (such as for debugging).
> 
> In general, PCD default values in DEC files have to be considered carefully,
> but in some cases, such changes are the right thing. Another example was
> 509f8425b75d ("UefiCpuPkg: change PcdCpuSmmStackGuard default to
> TRUE", 2016-06-06).
> 
> (You made the same point at the end of
> .)
> 
> 
> In addition to changing the default value to zero, I'd suggest moving
> "PcdSpinLockTimeout" from section
> 
> [PcdsFixedAtBuild,PcdsPatchableInModule]
> 
> to section
> 
> [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
> 
> so that platforms can enable the "debug" feature (i.e. set a nonzero
> value) more flexibly.

Agree to do both changes,  will submit BZ for it if we get the agreement in 
this mailing list.

Thanks,
Eric

> 
> Thanks
> Laszlo
> 
> >> -Original Message-
> >> From: Brian J. Johnson [mailto:brian.john...@hpe.com]
> >> Sent: Friday, December 21, 2018 12:36 AM
> >> To: Yao, Jiewen ; Ni, Ruiyu
> >> ; Dong, Eric ;
> >> edk2-devel@lists.01.org
> >> Cc: Laszlo Ersek 
> >> Subject: Re: [edk2] [Patch 1/3] UefiCpuPkg/RegisterCpuFeaturesLib:
> >> Avoid AP calls PeiService.
> >>
> >> Agreed.  We've seen issues on real platforms with timed-out spinlocks
> >> in DXE causing calls to GetPerformanceCounter and DebugAssert.  (DXE
> >> has the same code, with the same issues.)
> >>
> >> Note that it's possible to set PcdSpinLockTimeout=0 to work around
> >> the issue on a particular platform, or in a particular module.  But
> >> if you have to do that for every module which uses APs, and hence
> >> could contend for a spinlock, it kind of defeats the point  We're 
> >> better
> off removing the timeout code.
> >>
> >> Thanks,
> >> Brian
> >>
> >> On 12/19/18 8:08 PM, Yao, Jiewen wrote:
> >>> Yes, I agree, if we don't have any real case.
> >>>
> >>>
>  -Original Message-
>  From: Ni, Ruiyu
>  Sent: Thursday, December 20, 2018 10:07 AM
>  To: Dong, Eric ; Yao, Jiewen
>  ; edk2-devel@lists.01.org
>  Cc: Laszlo Ersek 
>  Subject: RE: [edk2] [Patch 1/3] UefiCpuPkg/RegisterCpuFeaturesLib:
>  Avoid AP calls PeiService.
> 
>  Can you just change the AcquireSpinLock() behavior to remove the
>  Timeout PCD consumption?
> 
>  I haven't seen a real case that the timed acquisition of spin lock is
> needed.
> 
> 
>  Thanks/Ray
> 
> > -Original Message-
> > From: Dong, Eric 
> > Sent: Thursday, December 20, 2018 9:23 AM
> > To: Yao, Jiewen ; edk2-devel@lists.01.org
> > Cc: Ni, Ruiyu ; Laszlo Ersek
> > 
> > Subject: RE: [edk2] [Patch 1/3] UefiCpuPkg/RegisterCpuFeaturesLib:
> > Avoid AP calls PeiService.
> >
> >
> > Agreed, Maybe it's time to add a new API like
> > AcquireSpinLockWithoutTimeOut?
> >
> > Thanks,
> > Eric
> >> -Original Message-
> >> From: Yao, Jiewen
> >> Sent: Thursday, December 20, 2018 9:19 AM

Re: [edk2] [PATCH 6/6] MdeModulePkg/VariableRuntimeDxe: implement standalone MM version

[Wang, Jian J]

Reviewed-by: Jian J Wang 


> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Friday, January 04, 2019 2:28 AM
> To: edk2-devel@lists.01.org
> Cc: Ard Biesheuvel ; Laszlo Ersek
> ; Leif Lindholm ; Kinney,
> Michael D ; Gao, Liming ;
> Wang, Jian J ; Wu, Hao A ;
> Jagadeesh Ujja ; Achin Gupta
> ; Thomas Panakamattam Abraham
> ; Sami Mujawar 
> Subject: [PATCH 6/6] MdeModulePkg/VariableRuntimeDxe: implement
> standalone MM version
> 
> Reuse most of the existing code to implement a variable runtime
> driver that will be able to execute in the context of standalone
> MM.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c   |
> 69 ++
>  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf |
> 135 
>  2 files changed, 204 insertions(+)
> 
> diff --git
> a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c
> new file mode 100644
> index ..fbc99467c057
> --- /dev/null
> +++
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c
> @@ -0,0 +1,69 @@
> +/** @file
> +
> +  Parts of the SMM/MM implementation that are specific to standalone MM
> +
> +Copyright (c) 2011 - 2018, Intel Corporation. All rights reserved. 
> +Copyright (c) 2018, Linaro, Ltd. All rights reserved. 
> +This program and the accompanying materials
> +are licensed and made available under the terms and conditions of the BSD
> License
> +which accompanies this distribution.  The full text of the license may be 
> found
> at
> +http://opensource.org/licenses/bsd-license.php
> +
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS
> OR IMPLIED.
> +
> +**/
> +
> +#include "Variable.h"
> +
> +BOOLEAN
> +VariableSmmIsBufferOutsideSmmValid (
> +  IN EFI_PHYSICAL_ADDRESS  Buffer,
> +  IN UINT64Length
> +  )
> +{
> +  return TRUE;
> +}
> +
> +/**
> +  Notify the system that the SMM variable driver is ready
> +**/
> +VOID
> +VariableNotifySmmReady (
> +  VOID
> +  )
> +{
> +}
> +
> +/**
> +  Notify the system that the SMM variable write driver is ready
> +**/
> +VOID
> +VariableNotifySmmWriteReady (
> +  VOID
> +  )
> +{
> +}
> +
> +EFI_STATUS
> +EFIAPI
> +VariableServiceInitialize (
> +  IN EFI_HANDLE   ImageHandle,
> +  IN EFI_MM_SYSTEM_TABLE  *MmSystemTable
> +  )
> +{
> +  return MmVariableServiceInitialize ();
> +}
> +
> +/**
> +  Whether the TCG or TCG2 protocols are installed in the UEFI protocol
> database.
> +  This information is used by the MorLock code to infer whether an existing
> +  MOR variable is legitimate or not.
> +**/
> +BOOLEAN
> +VariableHaveTcgProtocols (
> +  VOID
> +  )
> +{
> +  return FALSE;
> +}
> diff --git
> a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
> new file mode 100644
> index ..54d647af914c
> --- /dev/null
> +++
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
> @@ -0,0 +1,135 @@
> +## @file
> +#  Provides SMM variable service.
> +#
> +#  This module installs SMM variable protocol into SMM protocol database,
> +#  which can be used by SMM driver, and installs SMM variable protocol
> +#  into BS protocol database, which can be used to notify the SMM Runtime
> +#  Dxe driver that the SMM variable service is ready.
> +#  This module should be used with SMM Runtime DXE module together. The
> +#  SMM Runtime DXE module would install variable arch protocol and variable
> +#  write arch protocol based on SMM variable module.
> +#
> +#  Caution: This module requires additional review when modified.
> +#  This driver will have external input - variable data and communicate 
> buffer in
> SMM mode.
> +#  This external input must be validated carefully to avoid security issues 
> such
> as
> +#  buffer overflow or integer overflow.
> +#The whole SMM authentication variable design relies on the integrity of
> flash part and SMM.
> +#  which is assumed to be protected by platform.  All variable code and
> metadata in flash/SMM Memory
> +#  may not be modified without authorization. If platform fails to protect 
> these
> resources,
> +#  the authentication service provided in this driver will be broken, and the
> behavior is undefined.
> +#
> +# Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
> +# This program and the accompanying materials
> +# are licensed and made available under the terms and conditions of the BSD
> License
> +# which accompanies this distribution. The full text of the license may be 
> found
> at
> +# http://opensource.org/licenses/bsd-license.php
> +# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON 

Re: [edk2] [PATCH 5/6] MdeModulePkg/VariableRuntimeDxe: factor out boot service accesses

[Wang, Jian J]

Laszlo,

Regards,
Jian

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, January 08, 2019 11:38 PM
> To: Ard Biesheuvel ; edk2-devel@lists.01.org
> Cc: Leif Lindholm ; Kinney, Michael D
> ; Gao, Liming ; Wang,
> Jian J ; Wu, Hao A ; Jagadeesh
> Ujja ; Achin Gupta ;
> Thomas Panakamattam Abraham ; Sami Mujawar
> 
> Subject: Re: [PATCH 5/6] MdeModulePkg/VariableRuntimeDxe: factor out boot
> service accesses
> 
> On 01/03/19 19:28, Ard Biesheuvel wrote:
> > In preparation of providing a standalone MM based variable runtime
> > driver, move the existing SMM driver to the new MM services table,
> > and factor out some pieces that are specific to the traditional
> > driver, mainly related to the use of UEFI boot services, which are
> > not accessible to standalone MM drivers.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel 
> > ---
> >  MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c |  18
> +---
> >  MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h  |  50
> +
> >  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c   |  59
> --
> >  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf |   5 +-
> >  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableTraditionalMm.c |
> 114 
> >  5 files changed, 187 insertions(+), 59 deletions(-)
> 
> I *vaguely* feel like we should extract the new functions to
> "PrivilegePolymorphic.h", rather than to "Variable.h".
> 
> Please see initial commit 00663d047fc9
> ("MdeModulePkg/Variable/RuntimeDxe: move SecureBootHook() decl to new
> header", 2017-10-10), and other commits that touched that file.
> 
> I realize this is not a 100% "constructive" suggestion, and I feel
> appropriately bad about that. It's just that "Variable.h" has so many
> internals that I feel it's not a good dumping ground for these new
> functions. And the other header we have, looks closer in purpose.
> 
> For example, MorLockInitAtEndOfDxe() is already declared in
> "PrivilegePolymorphic.h" (see commit f1304280435f,
> "MdeModulePkg/Variable/RuntimeDxe: introduce MorLockInitAtEndOfDxe()
> hook", 2017-10-10).
> 
> Admittedly, now that we're going to have three separate builds of this
> driver, dedicating a separate header file to each "shared between A and
> B" relationship is getting a bit too complex. In retrospect, introducing
> "PrivilegePolymorphic.h" may not have been a "scalable" idea, after all,
> and I should have just dumped those functions all in "Variable.h".
> 
> IOW, I think
> - targeting "Variable.h" now is inconsistent with earlier code,
> - extending "PrivilegePolymorphic.h" is also suboptimal (although still
> better than the previous option),
> - adding yet another header might be technically correct, but it would
> be over-engineering,
> - asking you to merge "PrivilegePolymorphic.h" back into "Variable.h"
> feels awkward, especially after I argued *for* "PrivilegePolymorphic.h"
> at length, when I originally introduced it. :/
> 
> Sigh. Can the variable driver maintainers comment please?
> 
> (I still plan to regression-test this series, but I feel like I should
> force myself to at least skim the variable driver patches, beyond
> testing them. Because, next time I can't avoid working with this very
> complex driver, I wouldn't like to be *completely* lost.)
> 

I agree "PrivilegePolymorphic.h" is more appropriate place for them.
Maybe Star have different opinion.

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

Re: [edk2] [PATCH 6/6] MdeModulePkg/VariableRuntimeDxe: implement standalone MM version

[Wang, Jian J]

Reviewed-by: Jian J Wang 


> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Friday, January 04, 2019 2:28 AM
> To: edk2-devel@lists.01.org
> Cc: Ard Biesheuvel ; Laszlo Ersek
> ; Leif Lindholm ; Kinney,
> Michael D ; Gao, Liming ;
> Wang, Jian J ; Wu, Hao A ;
> Jagadeesh Ujja ; Achin Gupta
> ; Thomas Panakamattam Abraham
> ; Sami Mujawar 
> Subject: [PATCH 6/6] MdeModulePkg/VariableRuntimeDxe: implement
> standalone MM version
> 
> Reuse most of the existing code to implement a variable runtime
> driver that will be able to execute in the context of standalone
> MM.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c   |
> 69 ++
>  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf |
> 135 
>  2 files changed, 204 insertions(+)
> 
> diff --git
> a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c
> new file mode 100644
> index ..fbc99467c057
> --- /dev/null
> +++
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c
> @@ -0,0 +1,69 @@
> +/** @file
> +
> +  Parts of the SMM/MM implementation that are specific to standalone MM
> +
> +Copyright (c) 2011 - 2018, Intel Corporation. All rights reserved. 
> +Copyright (c) 2018, Linaro, Ltd. All rights reserved. 
> +This program and the accompanying materials
> +are licensed and made available under the terms and conditions of the BSD
> License
> +which accompanies this distribution.  The full text of the license may be 
> found
> at
> +http://opensource.org/licenses/bsd-license.php
> +
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS
> OR IMPLIED.
> +
> +**/
> +
> +#include "Variable.h"
> +
> +BOOLEAN
> +VariableSmmIsBufferOutsideSmmValid (
> +  IN EFI_PHYSICAL_ADDRESS  Buffer,
> +  IN UINT64Length
> +  )
> +{
> +  return TRUE;
> +}
> +
> +/**
> +  Notify the system that the SMM variable driver is ready
> +**/
> +VOID
> +VariableNotifySmmReady (
> +  VOID
> +  )
> +{
> +}
> +
> +/**
> +  Notify the system that the SMM variable write driver is ready
> +**/
> +VOID
> +VariableNotifySmmWriteReady (
> +  VOID
> +  )
> +{
> +}
> +
> +EFI_STATUS
> +EFIAPI
> +VariableServiceInitialize (
> +  IN EFI_HANDLE   ImageHandle,
> +  IN EFI_MM_SYSTEM_TABLE  *MmSystemTable
> +  )
> +{
> +  return MmVariableServiceInitialize ();
> +}
> +
> +/**
> +  Whether the TCG or TCG2 protocols are installed in the UEFI protocol
> database.
> +  This information is used by the MorLock code to infer whether an existing
> +  MOR variable is legitimate or not.
> +**/
> +BOOLEAN
> +VariableHaveTcgProtocols (
> +  VOID
> +  )
> +{
> +  return FALSE;
> +}
> diff --git
> a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
> new file mode 100644
> index ..54d647af914c
> --- /dev/null
> +++
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
> @@ -0,0 +1,135 @@
> +## @file
> +#  Provides SMM variable service.
> +#
> +#  This module installs SMM variable protocol into SMM protocol database,
> +#  which can be used by SMM driver, and installs SMM variable protocol
> +#  into BS protocol database, which can be used to notify the SMM Runtime
> +#  Dxe driver that the SMM variable service is ready.
> +#  This module should be used with SMM Runtime DXE module together. The
> +#  SMM Runtime DXE module would install variable arch protocol and variable
> +#  write arch protocol based on SMM variable module.
> +#
> +#  Caution: This module requires additional review when modified.
> +#  This driver will have external input - variable data and communicate 
> buffer in
> SMM mode.
> +#  This external input must be validated carefully to avoid security issues 
> such
> as
> +#  buffer overflow or integer overflow.
> +#The whole SMM authentication variable design relies on the integrity of
> flash part and SMM.
> +#  which is assumed to be protected by platform.  All variable code and
> metadata in flash/SMM Memory
> +#  may not be modified without authorization. If platform fails to protect 
> these
> resources,
> +#  the authentication service provided in this driver will be broken, and the
> behavior is undefined.
> +#
> +# Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
> +# This program and the accompanying materials
> +# are licensed and made available under the terms and conditions of the BSD
> License
> +# which accompanies this distribution. The full text of the license may be 
> found
> at
> +# http://opensource.org/licenses/bsd-license.php
> +# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON 

[edk2] [PATCH v2] ShellPkg/TftpDynamicCommand: Change file writing method in tftp

[Songpeng Li]

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

v2: Remove an unused variable.

Current logic of shell tftp download was writing file after tftp
download finished, when the file is large, it looks like the shell
tftp command hanged after download was finished. To improve
end-user experience, the solution is using split file writing
instead.

This patch update the code to open and close file inside
DownloadFile(), and save each packet to file within callback
function CheckPacket().

Since AllocatePage() is no-longer needed, This patch can also
remove the memory limitation. The download file can be larger
than system free memory now.

Cc: Jaben Carsey 
Cc: Ruiyu Ni 
Cc: Wu Jiaxin 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Songpeng Li 
---
 ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c | 154 
 1 file changed, 64 insertions(+), 90 deletions(-)

diff --git a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c 
b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
index ed081b5bad7c..ba753a279b00 100644
--- a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
+++ b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
@@ -41,6 +41,12 @@ STATIC CONST CHAR16 mTftpProgressFrame[] = L"[
 // (TFTP_PROGRESS_MESSAGE_SIZE-1) '\b'
 STATIC CONST CHAR16 mTftpProgressDelete[] = 
L"\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b";
 
+// Local File Handle
+SHELL_FILE_HANDLE mFileHandle;
+
+// Path of the local file, Unicode encoded
+CONST CHAR16 *mLocalFilePath;
+
 /**
   Check and convert the UINT16 option values of the 'tftp' command
 
@@ -166,9 +172,6 @@ GetFileSize (
   @param[in]   FileSize   Size of the file in number of bytes
   @param[in]   BlockSize  Value of the TFTP blksize option
   @param[in]   WindowSize Value of the TFTP window size option
-  @param[out]  Data   Address where to store the address of the buffer
-  where the data of the file were downloaded in
-  case of success.
 
   @retval  EFI_SUCCESS   The file was downloaded.
   @retval  EFI_OUT_OF_RESOURCES  A memory allocation failed.
@@ -184,8 +187,7 @@ DownloadFile (
   IN   CONST CHAR8  *AsciiFilePath,
   IN   UINTNFileSize,
   IN   UINT16   BlockSize,
-  IN   UINT16   WindowSize,
-  OUT  VOID **Data
+  IN   UINT16   WindowSize
   );
 
 /**
@@ -287,7 +289,6 @@ RunTftp (
   CHAR8   *AsciiRemoteFilePath;
   UINTN   FilePathSize;
   CONST CHAR16*Walker;
-  CONST CHAR16*LocalFilePath;
   EFI_MTFTP4_CONFIG_DATA  Mtftp4ConfigData;
   EFI_HANDLE  *Handles;
   UINTN   HandleCount;
@@ -297,9 +298,6 @@ RunTftp (
   EFI_HANDLE  Mtftp4ChildHandle;
   EFI_MTFTP4_PROTOCOL *Mtftp4;
   UINTN   FileSize;
-  UINTN   DataSize;
-  VOID*Data;
-  SHELL_FILE_HANDLE   FileHandle;
   UINT16  BlockSize;
   UINT16  WindowSize;
 
@@ -309,7 +307,6 @@ RunTftp (
   AsciiRemoteFilePath = NULL;
   Handles = NULL;
   FileSize= 0;
-  DataSize= 0;
   BlockSize   = MTFTP_DEFAULT_BLKSIZE;
   WindowSize  = MTFTP_DEFAULT_WINDOWSIZE;
 
@@ -385,7 +382,7 @@ RunTftp (
   UnicodeStrToAsciiStrS (RemoteFilePath, AsciiRemoteFilePath, FilePathSize);
 
   if (ParamCount == 4) {
-LocalFilePath = ShellCommandLineGetRawValue (CheckPackage, 3);
+mLocalFilePath = ShellCommandLineGetRawValue (CheckPackage, 3);
   } else {
 Walker = RemoteFilePath + StrLen (RemoteFilePath);
 while ((--Walker) >= RemoteFilePath) {
@@ -394,7 +391,7 @@ RunTftp (
 break;
   }
 }
-LocalFilePath = Walker + 1;
+mLocalFilePath = Walker + 1;
   }
 
   //
@@ -492,7 +489,6 @@ RunTftp (
(NicNumber < HandleCount) && (ShellStatus != SHELL_SUCCESS);
NicNumber++) {
 ControllerHandle = Handles[NicNumber];
-Data = NULL;
 
 Status = GetNicName (ControllerHandle, NicNumber, NicName);
 if (EFI_ERROR (Status)) {
@@ -543,7 +539,7 @@ RunTftp (
   goto NextHandle;
 }
 
-Status = DownloadFile (Mtftp4, RemoteFilePath, AsciiRemoteFilePath, 
FileSize, BlockSize, WindowSize, );
+Status = DownloadFile (Mtftp4, RemoteFilePath, AsciiRemoteFilePath, 
FileSize, BlockSize, WindowSize);
 if (EFI_ERROR (Status)) {
   ShellPrintHiiEx (
 -1, -1, NULL, STRING_TOKEN (STR_TFTP_ERR_DOWNLOAD),
@@ -552,45 +548,8 @@ RunTftp (
   goto NextHandle;
 }
 
-DataSize = FileSize;
-
-if (!EFI_ERROR (ShellFileExists (LocalFilePath))) {
-  ShellDeleteFileByName (LocalFilePath);
-}
-
-Status = ShellOpenFileByName (
-   LocalFilePath,
-   ,
-   EFI_FILE_MODE_CREATE |
-   EFI_FILE_MODE_WRITE  

[edk2] [platforms: PATCH v2 12/12] Marvell/Armada7k8k: Introduce NonDiscoverable device init routines

[Marcin Wojtas]

To abstract the initialization required for non-discoverable devices,
which is often platform specific (e.g. enable GPIO-driven power supply),
introduce a NonDiscoverableInitLib for use by the NonDiscoverable code,
for which each platform can supply its own version.

Add XHCI power supply (so called 'VBUS') enabling routines
for supported platforms (Armada70x0Db, Armada80x0Db, Armada80x0McBin).

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Silicon/Marvell/Marvell.dec
 |   1 +
 Platform/Marvell/Armada70x0Db/Armada70x0Db.dsc 
 |   3 +
 Platform/Marvell/Armada80x0Db/Armada80x0Db.dsc 
 |   3 +
 Platform/SolidRun/Armada80x0McBin/Armada80x0McBin.dsc  
 |   3 +
 
Platform/Marvell/Armada70x0Db/NonDiscoverableInitLib/NonDiscoverableInitLib.inf 
|  48 +
 
Platform/Marvell/Armada80x0Db/NonDiscoverableInitLib/NonDiscoverableInitLib.inf 
|  49 +
 
Platform/SolidRun/Armada80x0McBin/NonDiscoverableInitLib/NonDiscoverableInitLib.inf
 |  49 +
 Silicon/Marvell/Drivers/NonDiscoverableDxe/NonDiscoverableDxe.inf  
 |   1 +
 Platform/Marvell/Armada70x0Db/NonDiscoverableInitLib/NonDiscoverableInitLib.h  
 |  23 +
 Platform/Marvell/Armada80x0Db/NonDiscoverableInitLib/NonDiscoverableInitLib.h  
 |  28 ++
 
Platform/SolidRun/Armada80x0McBin/NonDiscoverableInitLib/NonDiscoverableInitLib.h
   |  20 
 Silicon/Marvell/Include/Library/NonDiscoverableInitLib.h   
 |  28 ++
 Platform/Marvell/Armada70x0Db/NonDiscoverableInitLib/NonDiscoverableInitLib.c  
 |  96 ++
 Platform/Marvell/Armada80x0Db/NonDiscoverableInitLib/NonDiscoverableInitLib.c  
 | 106 
 
Platform/SolidRun/Armada80x0McBin/NonDiscoverableInitLib/NonDiscoverableInitLib.c
   |  71 +
 Silicon/Marvell/Drivers/NonDiscoverableDxe/NonDiscoverableDxe.c
 |  13 ++-
 16 files changed, 539 insertions(+), 3 deletions(-)
 create mode 100644 
Platform/Marvell/Armada70x0Db/NonDiscoverableInitLib/NonDiscoverableInitLib.inf
 create mode 100644 
Platform/Marvell/Armada80x0Db/NonDiscoverableInitLib/NonDiscoverableInitLib.inf
 create mode 100644 
Platform/SolidRun/Armada80x0McBin/NonDiscoverableInitLib/NonDiscoverableInitLib.inf
 create mode 100644 
Platform/Marvell/Armada70x0Db/NonDiscoverableInitLib/NonDiscoverableInitLib.h
 create mode 100644 
Platform/Marvell/Armada80x0Db/NonDiscoverableInitLib/NonDiscoverableInitLib.h
 create mode 100644 
Platform/SolidRun/Armada80x0McBin/NonDiscoverableInitLib/NonDiscoverableInitLib.h
 create mode 100644 Silicon/Marvell/Include/Library/NonDiscoverableInitLib.h
 create mode 100644 
Platform/Marvell/Armada70x0Db/NonDiscoverableInitLib/NonDiscoverableInitLib.c
 create mode 100644 
Platform/Marvell/Armada80x0Db/NonDiscoverableInitLib/NonDiscoverableInitLib.c
 create mode 100644 
Platform/SolidRun/Armada80x0McBin/NonDiscoverableInitLib/NonDiscoverableInitLib.c

diff --git a/Silicon/Marvell/Marvell.dec b/Silicon/Marvell/Marvell.dec
index 616624e..12bac55 100644
--- a/Silicon/Marvell/Marvell.dec
+++ b/Silicon/Marvell/Marvell.dec
@@ -63,6 +63,7 @@
   ArmadaBoardDescLib|Include/Library/ArmadaBoardDescLib.h
   ArmadaIcuLib|Include/Library/ArmadaIcuLib.h
   ArmadaSoCDescLib|Include/Library/ArmadaSoCDescLib.h
+  NonDiscoverableInitLib|Include/Library/NonDiscoverableInitLib.h
   SampleAtResetLib|Include/Library/SampleAtResetLib.h
 
 [Protocols]
diff --git a/Platform/Marvell/Armada70x0Db/Armada70x0Db.dsc 
b/Platform/Marvell/Armada70x0Db/Armada70x0Db.dsc
index 31815e4..e8cd177 100644
--- a/Platform/Marvell/Armada70x0Db/Armada70x0Db.dsc
+++ b/Platform/Marvell/Armada70x0Db/Armada70x0Db.dsc
@@ -48,6 +48,9 @@
 
 !include Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
 
+[LibraryClasses.common]
+  
NonDiscoverableInitLib|Platform/Marvell/Armada70x0Db/NonDiscoverableInitLib/NonDiscoverableInitLib.inf
+
 [Components.common]
   Silicon/Marvell/Armada7k8k/DeviceTree/Armada70x0Db.inf
 
diff --git a/Platform/Marvell/Armada80x0Db/Armada80x0Db.dsc 
b/Platform/Marvell/Armada80x0Db/Armada80x0Db.dsc
index 42f7bd3..8e8c2ba 100644
--- a/Platform/Marvell/Armada80x0Db/Armada80x0Db.dsc
+++ b/Platform/Marvell/Armada80x0Db/Armada80x0Db.dsc
@@ -48,6 +48,9 @@
 
 !include Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
 
+[LibraryClasses.common]
+  
NonDiscoverableInitLib|Platform/Marvell/Armada80x0Db/NonDiscoverableInitLib/NonDiscoverableInitLib.inf
+
 [Components.common]
   Silicon/Marvell/Armada7k8k/DeviceTree/Armada80x0Db.inf
 
diff --git a/Platform/SolidRun/Armada80x0McBin/Armada80x0McBin.dsc 
b/Platform/SolidRun/Armada80x0McBin/Armada80x0McBin.dsc
index 077224d..d080136 100644
--- a/Platform/SolidRun/Armada80x0McBin/Armada80x0McBin.dsc
+++ b/Platform/SolidRun/Armada80x0McBin/Armada80x0McBin.dsc
@@ -49,6 +49,9 @@
 
 !include 

Re: [edk2] [PATCH 4/6] MdeModulePkg/FaultTolerantWriteDxe: implement standalone MM version

[Wang, Jian J]

Forget the previous comment, multiple comments for usage are allowed in INF.

Reviewed-by: Jian J Wang 


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Wang,
> Jian J
> Sent: Thursday, January 10, 2019 9:42 AM
> To: Ard Biesheuvel ; edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Gao, Liming ;
> Kinney, Michael D ; Laszlo Ersek
> 
> Subject: Re: [edk2] [PATCH 4/6] MdeModulePkg/FaultTolerantWriteDxe:
> implement standalone MM version
> 
> Ard,
> 
> 
> Regards,
> Jian
> 
> 
> > -Original Message-
> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > Sent: Friday, January 04, 2019 2:28 AM
> > To: edk2-devel@lists.01.org
> > Cc: Ard Biesheuvel ; Laszlo Ersek
> > ; Leif Lindholm ; Kinney,
> > Michael D ; Gao, Liming
> ;
> > Wang, Jian J ; Wu, Hao A ;
> > Jagadeesh Ujja ; Achin Gupta
> > ; Thomas Panakamattam Abraham
> > ; Sami Mujawar 
> > Subject: [PATCH 4/6] MdeModulePkg/FaultTolerantWriteDxe: implement
> > standalone MM version
> >
> > Implement a new version of the fault tolerant write driver that can
> > be used in the context of a standalone MM implementation.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel 
> > ---
> >
> >
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandalon
> > eMm.c   | 70 +++
> >
> >
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandalon
> > eMm.inf | 90 
> >  2 files changed, 160 insertions(+)
> >
> > diff --git
> >
> a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> > oneMm.c
> >
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> > oneMm.c
> > new file mode 100644
> > index ..b6fbf6c64f8a
> > --- /dev/null
> > +++
> >
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> > oneMm.c
> > @@ -0,0 +1,70 @@
> > +/** @file
> > +
> > +  Parts of the SMM/MM implementation that are specific to standalone MM
> > +
> > +Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
> > +Copyright (c) 2018, Linaro, Ltd. All rights reserved.
> > +This program and the accompanying materials
> > +are licensed and made available under the terms and conditions of the BSD
> > License
> > +which accompanies this distribution.  The full text of the license may be 
> > found
> > at
> > +http://opensource.org/licenses/bsd-license.php
> > +
> > +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> > +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS
> > OR IMPLIED.
> > +
> > +**/
> > +
> > +#include 
> > +#include 
> > +#include "FaultTolerantWrite.h"
> > +#include "FaultTolerantWriteSmmCommon.h"
> > +
> > +BOOLEAN
> > +FtwSmmIsBufferOutsideSmmValid (
> > +  IN EFI_PHYSICAL_ADDRESS  Buffer,
> > +  IN UINT64Length
> > +  )
> > +{
> > +  return TRUE;
> > +}
> > +
> > +/**
> > +  Internal implementation of CRC32. Depending on the execution context
> > +  (standalone SMM or DXE vs standalone MM), this function is implemented
> > +  via a call to the CalculateCrc32 () boot service, or via a library
> > +  call.
> > +
> > +  If Buffer is NULL, then ASSERT().
> > +  If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
> > +
> > +  @param[in]  Buffer   A pointer to the buffer on which the 32-bit CRC 
> > is to
> be
> > computed.
> > +  @param[in]  Length   The number of bytes in the buffer Data.
> > +
> > +  @retval Crc32The 32-bit CRC was computed for the data buffer.
> > +
> > +**/
> > +UINT32
> > +FtwCalculateCrc32 (
> > +  IN  VOID *Buffer,
> > +  IN  UINTNLength
> > +  )
> > +{
> > +  return CalculateCrc32 (Buffer, Length);
> > +}
> > +
> > +VOID
> > +FtwNotifySmmReady (
> > +  VOID
> > +  )
> > +{
> > +}
> > +
> > +EFI_STATUS
> > +EFIAPI
> > +StandaloneMmFaultTolerantWriteInitialize (
> > +  IN EFI_HANDLEImageHandle,
> > +  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
> > +  )
> > +{
> > +  return MmFaultTolerantWriteInitialize ();
> > +}
> > diff --git
> >
> a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> > oneMm.inf
> >
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> > oneMm.inf
> > new file mode 100644
> > index ..99bd62ad5ceb
> > --- /dev/null
> > +++
> >
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> > oneMm.inf
> > @@ -0,0 +1,90 @@
> > + ## @file
> > +#   Fault Tolerant Write Smm Driver.
> > +#
> > +#   This driver installs SMM Fault Tolerant Write (FTW) protocol, which
> provides
> > fault
> > +#   tolerant write capability in SMM environment for block devices. Its
> > implementation
> > +#   depends on the full functionality SMM FVB protocol that support read,
> > write/erase
> > +#   flash access.
> > +#
> > +# Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
> > 

[edk2] [PATCH v2] ShellPkg/TftpDynamicCommand: Change file writing method in tftp

[Songpeng Li]

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

v2: Remove an unused variable.

Current logic of shell tftp download was writing file after tftp
download finished, when the file is large, it looks like the shell
tftp command hanged after download was finished. To improve
end-user experience, the solution is using split file writing
instead.

This patch update the code to open and close file inside
DownloadFile(), and save each packet to file within callback
function CheckPacket().

Since AllocatePage() is no-longer needed, This patch can also
remove the memory limitation. The download file can be larger
than system free memory now.

Cc: Jaben Carsey 
Cc: Ruiyu Ni 
Cc: Wu Jiaxin 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Songpeng Li 
---
 ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c | 154 
 1 file changed, 64 insertions(+), 90 deletions(-)

diff --git a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c 
b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
index ed081b5bad7c..ba753a279b00 100644
--- a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
+++ b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
@@ -41,6 +41,12 @@ STATIC CONST CHAR16 mTftpProgressFrame[] = L"[
 // (TFTP_PROGRESS_MESSAGE_SIZE-1) '\b'
 STATIC CONST CHAR16 mTftpProgressDelete[] = 
L"\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b";
 
+// Local File Handle
+SHELL_FILE_HANDLE mFileHandle;
+
+// Path of the local file, Unicode encoded
+CONST CHAR16 *mLocalFilePath;
+
 /**
   Check and convert the UINT16 option values of the 'tftp' command
 
@@ -166,9 +172,6 @@ GetFileSize (
   @param[in]   FileSize   Size of the file in number of bytes
   @param[in]   BlockSize  Value of the TFTP blksize option
   @param[in]   WindowSize Value of the TFTP window size option
-  @param[out]  Data   Address where to store the address of the buffer
-  where the data of the file were downloaded in
-  case of success.
 
   @retval  EFI_SUCCESS   The file was downloaded.
   @retval  EFI_OUT_OF_RESOURCES  A memory allocation failed.
@@ -184,8 +187,7 @@ DownloadFile (
   IN   CONST CHAR8  *AsciiFilePath,
   IN   UINTNFileSize,
   IN   UINT16   BlockSize,
-  IN   UINT16   WindowSize,
-  OUT  VOID **Data
+  IN   UINT16   WindowSize
   );
 
 /**
@@ -287,7 +289,6 @@ RunTftp (
   CHAR8   *AsciiRemoteFilePath;
   UINTN   FilePathSize;
   CONST CHAR16*Walker;
-  CONST CHAR16*LocalFilePath;
   EFI_MTFTP4_CONFIG_DATA  Mtftp4ConfigData;
   EFI_HANDLE  *Handles;
   UINTN   HandleCount;
@@ -297,9 +298,6 @@ RunTftp (
   EFI_HANDLE  Mtftp4ChildHandle;
   EFI_MTFTP4_PROTOCOL *Mtftp4;
   UINTN   FileSize;
-  UINTN   DataSize;
-  VOID*Data;
-  SHELL_FILE_HANDLE   FileHandle;
   UINT16  BlockSize;
   UINT16  WindowSize;
 
@@ -309,7 +307,6 @@ RunTftp (
   AsciiRemoteFilePath = NULL;
   Handles = NULL;
   FileSize= 0;
-  DataSize= 0;
   BlockSize   = MTFTP_DEFAULT_BLKSIZE;
   WindowSize  = MTFTP_DEFAULT_WINDOWSIZE;
 
@@ -385,7 +382,7 @@ RunTftp (
   UnicodeStrToAsciiStrS (RemoteFilePath, AsciiRemoteFilePath, FilePathSize);
 
   if (ParamCount == 4) {
-LocalFilePath = ShellCommandLineGetRawValue (CheckPackage, 3);
+mLocalFilePath = ShellCommandLineGetRawValue (CheckPackage, 3);
   } else {
 Walker = RemoteFilePath + StrLen (RemoteFilePath);
 while ((--Walker) >= RemoteFilePath) {
@@ -394,7 +391,7 @@ RunTftp (
 break;
   }
 }
-LocalFilePath = Walker + 1;
+mLocalFilePath = Walker + 1;
   }
 
   //
@@ -492,7 +489,6 @@ RunTftp (
(NicNumber < HandleCount) && (ShellStatus != SHELL_SUCCESS);
NicNumber++) {
 ControllerHandle = Handles[NicNumber];
-Data = NULL;
 
 Status = GetNicName (ControllerHandle, NicNumber, NicName);
 if (EFI_ERROR (Status)) {
@@ -543,7 +539,7 @@ RunTftp (
   goto NextHandle;
 }
 
-Status = DownloadFile (Mtftp4, RemoteFilePath, AsciiRemoteFilePath, 
FileSize, BlockSize, WindowSize, );
+Status = DownloadFile (Mtftp4, RemoteFilePath, AsciiRemoteFilePath, 
FileSize, BlockSize, WindowSize);
 if (EFI_ERROR (Status)) {
   ShellPrintHiiEx (
 -1, -1, NULL, STRING_TOKEN (STR_TFTP_ERR_DOWNLOAD),
@@ -552,45 +548,8 @@ RunTftp (
   goto NextHandle;
 }
 
-DataSize = FileSize;
-
-if (!EFI_ERROR (ShellFileExists (LocalFilePath))) {
-  ShellDeleteFileByName (LocalFilePath);
-}
-
-Status = ShellOpenFileByName (
-   LocalFilePath,
-   ,
-   EFI_FILE_MODE_CREATE |
-   EFI_FILE_MODE_WRITE  

[edk2] [platforms: PATCH v2 11/12] Marvell/Armada7k8k: Enable GPIO drivers compilation

[Marcin Wojtas]

Enable building new GPIO drivers before adding VBUS
pins handling. Update relevant boards .dsc files with
IO expander information.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
Reviewed-by: Leif Lindholm 
---
 Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc | 2 ++
 Platform/Marvell/Armada70x0Db/Armada70x0Db.dsc| 4 ++--
 Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf.inc| 2 ++
 Platform/Marvell/Armada80x0Db/Armada80x0Db.fdf.inc| 2 ++
 Platform/SolidRun/Armada80x0McBin/Armada80x0McBin.fdf.inc | 2 ++
 5 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc 
b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
index b3fd184..a0175de 100644
--- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
+++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
@@ -455,6 +455,8 @@
   Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.inf
 
   # Platform drivers
+  Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.inf
+  Silicon/Marvell/Drivers/Gpio/MvPca95xxDxe/MvPca95xxDxe.inf
   Silicon/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.inf
   MdeModulePkg/Bus/I2c/I2cDxe/I2cDxe.inf
   Silicon/Marvell/Drivers/I2c/MvEepromDxe/MvEepromDxe.inf
diff --git a/Platform/Marvell/Armada70x0Db/Armada70x0Db.dsc 
b/Platform/Marvell/Armada70x0Db/Armada70x0Db.dsc
index a935f36..31815e4 100644
--- a/Platform/Marvell/Armada70x0Db/Armada70x0Db.dsc
+++ b/Platform/Marvell/Armada70x0Db/Armada70x0Db.dsc
@@ -89,8 +89,8 @@
   gMarvellTokenSpaceGuid.PcdChip1MppSel6|{ 0xE, 0xE, 0xE, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0 }
 
   # I2C
-  gMarvellTokenSpaceGuid.PcdI2cSlaveAddresses|{ 0x50, 0x57, 0x60 }
-  gMarvellTokenSpaceGuid.PcdI2cSlaveBuses|{ 0x0, 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdI2cSlaveAddresses|{ 0x50, 0x57, 0x60, 0x21 }
+  gMarvellTokenSpaceGuid.PcdI2cSlaveBuses|{ 0x0, 0x0, 0x0, 0x0 }
   gMarvellTokenSpaceGuid.PcdI2cControllersEnabled|{ 0x1, 0x1 }
   gMarvellTokenSpaceGuid.PcdEepromI2cAddresses|{ 0x50, 0x57 }
   gMarvellTokenSpaceGuid.PcdEepromI2cBuses|{ 0x0, 0x0 }
diff --git a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf.inc 
b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf.inc
index b7e7a65..7129606 100644
--- a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf.inc
+++ b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf.inc
@@ -12,6 +12,8 @@
 
 # Per-board additional content of the DXE phase firmware volume
 
+  INF Silicon/Marvell/Drivers/Gpio/MvPca95xxDxe/MvPca95xxDxe.inf
+
   # DTB
   INF RuleOverride = DTB Silicon/Marvell/Armada7k8k/DeviceTree/Armada70x0Db.inf
 
diff --git a/Platform/Marvell/Armada80x0Db/Armada80x0Db.fdf.inc 
b/Platform/Marvell/Armada80x0Db/Armada80x0Db.fdf.inc
index 81a81d0..f2fcc55 100644
--- a/Platform/Marvell/Armada80x0Db/Armada80x0Db.fdf.inc
+++ b/Platform/Marvell/Armada80x0Db/Armada80x0Db.fdf.inc
@@ -12,6 +12,8 @@
 
 # Per-board additional content of the DXE phase firmware volume
 
+  INF Silicon/Marvell/Drivers/Gpio/MvPca95xxDxe/MvPca95xxDxe.inf
+
   # DTB
   INF RuleOverride = DTB Silicon/Marvell/Armada7k8k/DeviceTree/Armada80x0Db.inf
 
diff --git a/Platform/SolidRun/Armada80x0McBin/Armada80x0McBin.fdf.inc 
b/Platform/SolidRun/Armada80x0McBin/Armada80x0McBin.fdf.inc
index 326da2e..254fcee 100644
--- a/Platform/SolidRun/Armada80x0McBin/Armada80x0McBin.fdf.inc
+++ b/Platform/SolidRun/Armada80x0McBin/Armada80x0McBin.fdf.inc
@@ -12,6 +12,8 @@
 
 # Per-board additional content of the DXE phase firmware volume
 
+  INF Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.inf
+
   # DTB
   INF RuleOverride = DTB 
Silicon/Marvell/Armada7k8k/DeviceTree/Armada80x0McBin.inf
 
-- 
2.7.4

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

[edk2] [platforms: PATCH v2 10/12] Marvell/Drivers: MvPca95xxDxe: Introduce GPIO expander driver

[Marcin Wojtas]

Marvell Armada 7k/8k-based platforms may use Pca95xx to extend
amount of the GPIO pins.

This patch introduces support for them. The new driver implements
a generic EMBEDDED_GPIO protocol.

In order to ease description of used PCA9XXX controllers
add a common enum type. It can be used e.g. in the board description
library to specify the expander model on a board (instead of passing
a raw number). Update relevant libraries.

Driver is based on initial work done by Allen Yan .

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Silicon/Marvell/Drivers/Gpio/MvPca95xxDxe/MvPca95xxDxe.inf 
   |  45 ++
 Silicon/Marvell/Drivers/Gpio/MvPca95xxDxe/MvPca95xxDxe.h   
   |  65 ++
 Silicon/Marvell/Include/Protocol/MvGpio.h  
   |  16 +
 
Platform/Marvell/Armada70x0Db/Armada70x0DbBoardDescLib/Armada70x0DbBoardDescLib.c
 |   2 +-
 
Platform/Marvell/Armada80x0Db/Armada80x0DbBoardDescLib/Armada80x0DbBoardDescLib.c
 |   4 +-
 Silicon/Marvell/Drivers/Gpio/MvPca95xxDxe/MvPca95xxDxe.c   
   | 651 
 6 files changed, 780 insertions(+), 3 deletions(-)
 create mode 100644 Silicon/Marvell/Drivers/Gpio/MvPca95xxDxe/MvPca95xxDxe.inf
 create mode 100644 Silicon/Marvell/Drivers/Gpio/MvPca95xxDxe/MvPca95xxDxe.h
 create mode 100644 Silicon/Marvell/Drivers/Gpio/MvPca95xxDxe/MvPca95xxDxe.c

diff --git a/Silicon/Marvell/Drivers/Gpio/MvPca95xxDxe/MvPca95xxDxe.inf 
b/Silicon/Marvell/Drivers/Gpio/MvPca95xxDxe/MvPca95xxDxe.inf
new file mode 100644
index 000..3b1ab4e
--- /dev/null
+++ b/Silicon/Marvell/Drivers/Gpio/MvPca95xxDxe/MvPca95xxDxe.inf
@@ -0,0 +1,45 @@
+## @file
+#
+#  Copyright (c) 2017, Marvell International Ltd. All rights reserved.
+#
+#  This program and the accompanying materials are licensed and made available
+#  under the terms and conditions of the BSD License which accompanies this
+#  distribution. The full text of the license may be found at
+#  http://opensource.org/licenses/bsd-license.php
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
+#  IMPLIED.
+#
+
+[Defines]
+  INF_VERSION= 0x0001001A
+  BASE_NAME  = MvPca95xxDxe
+  FILE_GUID  = f0e405eb-8407-43b9-88e6-2f7d70715c72
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+  ENTRY_POINT= MvPca95xxEntryPoint
+
+[Sources]
+  MvPca95xxDxe.c
+  MvPca95xxDxe.h
+
+[Packages]
+  EmbeddedPkg/EmbeddedPkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  MdePkg/MdePkg.dec
+  Silicon/Marvell/Marvell.dec
+
+[LibraryClasses]
+  DebugLib
+  MemoryAllocationLib
+  UefiDriverEntryPoint
+  UefiLib
+
+[Protocols]
+  gEfiDriverBindingProtocolGuid
+  gEfiI2cIoProtocolGuid
+  gEmbeddedGpioProtocolGuid
+  gMarvellBoardDescProtocolGuid
+
+[Depex]
+  TRUE
diff --git a/Silicon/Marvell/Drivers/Gpio/MvPca95xxDxe/MvPca95xxDxe.h 
b/Silicon/Marvell/Drivers/Gpio/MvPca95xxDxe/MvPca95xxDxe.h
new file mode 100644
index 000..1fed739
--- /dev/null
+++ b/Silicon/Marvell/Drivers/Gpio/MvPca95xxDxe/MvPca95xxDxe.h
@@ -0,0 +1,65 @@
+/**
+*
+*  Copyright (c) 2018, Marvell International Ltd. All rights reserved.
+*
+*  This program and the accompanying materials are licensed and made available
+*  under the terms and conditions of the BSD License which accompanies this
+*  distribution. The full text of the license may be found at
+*  http://opensource.org/licenses/bsd-license.php
+*
+*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+*
+**/
+#ifndef __MV_PCA953X_H__
+#define __MV_PCA953X_H__
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+#define PCA95XX_GPIO_SIGNATURE   SIGNATURE_32 ('I', 'O', 'E', 'X')
+
+#define PCA95XX_INPUT_REG0x0
+#define PCA95XX_OUTPUT_REG   0x2
+#define PCA95XX_DIRECTION_REG0x6
+
+#define PCA95XX_BANK_SIZE8
+#define PCA95XX_OPERATION_COUNT  2
+#define PCA95XX_OPERATION_LENGTH 1
+
+typedef enum {
+  PCA9505_PIN_COUNT = 40,
+  PCA9534_PIN_COUNT = 8,
+  PCA9535_PIN_COUNT = 16,
+  PCA9536_PIN_COUNT = 4,
+  PCA9537_PIN_COUNT = 4,
+  PCA9538_PIN_COUNT = 8,
+  PCA9539_PIN_COUNT = 16,
+  PCA9554_PIN_COUNT = 8,
+  PCA9555_PIN_COUNT = 16,
+  PCA9556_PIN_COUNT = 16,
+  PCA9557_PIN_COUNT = 16,
+} PCA95XX_PIN_COUNT;
+
+typedef struct {
+  EMBEDDED_GPIO  GpioProtocol;
+  MV_GPIO_EXPANDER  *GpioExpanders;
+  UINTN  GpioExpanderCount;
+  UINTN  Signature;
+  EFI_HANDLE ControllerHandle;
+} PCA95XX;
+
+#endif
diff --git a/Silicon/Marvell/Include/Protocol/MvGpio.h 
b/Silicon/Marvell/Include/Protocol/MvGpio.h
index 3319b79..5037fc2 100644
--- 

[edk2] [platforms: PATCH v2 09/12] Marvell/Drivers: I2c: Use common header for macros

[Marcin Wojtas]

Hitherto I2c solution used same macros, defined in multiple
places. Move them to a new common header.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
Reviewed-by: Leif Lindholm 
---
 Silicon/Marvell/Drivers/I2c/MvEepromDxe/MvEepromDxe.h | 10 ---
 Silicon/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.h   | 17 ++-
 Silicon/Marvell/Include/Protocol/MvI2c.h  | 31 
 Silicon/Marvell/Applications/EepromCmd/EepromCmd.c|  5 +---
 Silicon/Marvell/Drivers/I2c/MvEepromDxe/MvEepromDxe.c |  3 +-
 Silicon/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c   |  4 +--
 6 files changed, 37 insertions(+), 33 deletions(-)
 create mode 100644 Silicon/Marvell/Include/Protocol/MvI2c.h

diff --git a/Silicon/Marvell/Drivers/I2c/MvEepromDxe/MvEepromDxe.h 
b/Silicon/Marvell/Drivers/I2c/MvEepromDxe/MvEepromDxe.h
index b1af645..c32ee48 100644
--- a/Silicon/Marvell/Drivers/I2c/MvEepromDxe/MvEepromDxe.h
+++ b/Silicon/Marvell/Drivers/I2c/MvEepromDxe/MvEepromDxe.h
@@ -41,16 +41,6 @@ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
 #define MAX_BUFFER_LENGTH 64
 
-/*
- * I2C_FLAG_NORESTART is not part of PI spec, it allows to continue
- * transmission without repeated start operation.
- * FIXME: This flag is also defined in Drivers/I2c/MvI2cDxe/MvI2cDxe.h
- * and it's important to have both version synced. This solution is
- * temporary and shared flag should be used by both files.
- * Situation is analogous with I2C_GUID, which also should be common, but is
- * for now defined same way in two header files.
- */
-#define I2C_FLAG_NORESTART 0x0002
 #define I2C_GUID \
   { \
   0xadc1901b, 0xb83c, 0x4831, { 0x8f, 0x59, 0x70, 0x89, 0x8f, 0x26, 0x57, 0x1e 
} \
diff --git a/Silicon/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.h 
b/Silicon/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.h
index 3c9beaf..6850c34 100644
--- a/Silicon/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.h
+++ b/Silicon/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.h
@@ -32,8 +32,8 @@ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
 
***/
 
-#ifndef __MV_I2C_H__
-#define __MV_I2C_H__
+#ifndef __MV_I2C_DXE_H__
+#define __MV_I2C_DXE_H__
 
 #include 
 
@@ -75,17 +75,6 @@ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 #define I2C_FAST   0x2
 #define I2C_FASTEST0x3
 
-/*
- * I2C_FLAG_NORESTART is not part of PI spec, it allows to continue
- * transmission without repeated start operation.
- * FIXME: This flag is also defined in
- * Platforms/Marvell/Include/Protocol/Eeprom.h and it's important to have both
- * version synced. This solution is temporary and shared flag should be used by
- * both files.
- * Situation is analogous with I2C_GUID, which also should be common, but is
- * for now defined same way in two header files.
- */
-#define I2C_FLAG_NORESTART 0x0002
 #define I2C_GUID \
   { \
   0xadc1901b, 0xb83c, 0x4831, { 0x8f, 0x59, 0x70, 0x89, 0x8f, 0x26, 0x57, 0x1e 
} \
@@ -266,4 +255,4 @@ MvI2cEnableConf (
   IN EFI_STATUS  *I2cStatus OPTIONAL
   );
 
-#endif // __MV_I2C_H__
+#endif // __MV_I2C_DXE_H__
diff --git a/Silicon/Marvell/Include/Protocol/MvI2c.h 
b/Silicon/Marvell/Include/Protocol/MvI2c.h
new file mode 100644
index 000..d8e644e
--- /dev/null
+++ b/Silicon/Marvell/Include/Protocol/MvI2c.h
@@ -0,0 +1,31 @@
+/**
+*
+*  Copyright (c) 2018, Marvell International Ltd. All rights reserved.
+*
+*  This program and the accompanying materials are licensed and made available
+*  under the terms and conditions of the BSD License which accompanies this
+*  distribution. The full text of the license may be found at
+*  http://opensource.org/licenses/bsd-license.php
+*
+*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+*
+**/
+#ifndef __MV_I2C_H__
+#define __MV_I2C_H__
+
+/*
+ * I2C_FLAG_NORESTART is not part of PI spec, it allows to continue
+ * transmission without repeated start operation.
+ */
+#define I2C_FLAG_NORESTART 0x0002
+
+/*
+ * Helper macros for maintaining multiple I2C buses
+ * and devices defined via EFI_I2C_DEVICE.
+ */
+#define I2C_DEVICE_ADDRESS(Index)  ((Index) & MAX_UINT16)
+#define I2C_DEVICE_BUS(Index)  ((Index) >> 16)
+#define I2C_DEVICE_INDEX(Bus, Address) (((Address) & MAX_UINT16) | (Bus) << 16)
+
+#endif
diff --git a/Silicon/Marvell/Applications/EepromCmd/EepromCmd.c 
b/Silicon/Marvell/Applications/EepromCmd/EepromCmd.c
index dc3c95f..712aba9 100644
--- a/Silicon/Marvell/Applications/EepromCmd/EepromCmd.c
+++ b/Silicon/Marvell/Applications/EepromCmd/EepromCmd.c
@@ -51,10 +51,7 @@ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 #include 
 
 #include 
-
-#define I2C_DEVICE_INDEX(bus, address) (((address) & 0x) | (bus) << 16)
-#define I2C_DEVICE_ADDRESS(index) ((index) & 

[edk2] [platforms: PATCH v2 08/12] Marvell/Drivers: MvGpioDxe: Introduce platform GPIO driver

[Marcin Wojtas]

Marvell Armada 7k/8k SoCs comprise integrated GPIO controllers,
one in AP806 and two in each south bridge hardware blocks.

This patch introduces support for them. The new driver implements
a generic EMBEDDED_GPIO protocol.

In order to ease description of used GPIO pins and controllers
of the Armada 7k8k platforms, add a common enum type.

Based on original work of Jing Hua .

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.inf |  44 +++
 Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.h   |  49 +++
 Silicon/Marvell/Include/Protocol/MvGpio.h|  10 +
 Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.c   | 372 
 4 files changed, 475 insertions(+)
 create mode 100644 Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.inf
 create mode 100644 Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.h
 create mode 100644 Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.c

diff --git a/Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.inf 
b/Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.inf
new file mode 100644
index 000..5ff9130
--- /dev/null
+++ b/Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.inf
@@ -0,0 +1,44 @@
+## @file
+#
+#  Copyright (c) 2017, Marvell International Ltd. All rights reserved.
+#
+#  This program and the accompanying materials are licensed and made available
+#  under the terms and conditions of the BSD License which accompanies this
+#  distribution. The full text of the license may be found at
+#  http://opensource.org/licenses/bsd-license.php
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
+#  IMPLIED.
+#
+
+[Defines]
+  INF_VERSION= 0x0001001A
+  BASE_NAME  = MvGpioDxe
+  FILE_GUID  = 706eb761-b3b5-4f41-8558-5fd9217c0079
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+  ENTRY_POINT= MvGpioEntryPoint
+
+[Sources]
+  MvGpioDxe.c
+  MvGpioDxe.h
+
+[Packages]
+  EmbeddedPkg/EmbeddedPkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  MdePkg/MdePkg.dec
+  Silicon/Marvell/Marvell.dec
+
+[LibraryClasses]
+  ArmadaSoCDescLib
+  DebugLib
+  MemoryAllocationLib
+  UefiDriverEntryPoint
+  UefiLib
+
+[Protocols]
+  gEmbeddedGpioProtocolGuid
+  gMarvellBoardDescProtocolGuid
+
+[Depex]
+  TRUE
diff --git a/Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.h 
b/Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.h
new file mode 100644
index 000..4e5422b
--- /dev/null
+++ b/Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.h
@@ -0,0 +1,49 @@
+/**
+*
+*  Copyright (c) 2018, Marvell International Ltd. All rights reserved.
+*
+*  This program and the accompanying materials are licensed and made available
+*  under the terms and conditions of the BSD License which accompanies this
+*  distribution. The full text of the license may be found at
+*  http://opensource.org/licenses/bsd-license.php
+*
+*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+*
+**/
+#ifndef __MV_GPIO_H__
+#define __MV_GPIO_H__
+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+
+#define MV_GPIO_SIGNATURESIGNATURE_32 ('G', 'P', 'I', 'O')
+
+// Marvell MV_GPIO Controller Registers
+#define MV_GPIO_DATA_OUT_REG (0x0)
+#define MV_GPIO_OUT_EN_REG   (0x4)
+#define MV_GPIO_BLINK_EN_REG (0x8)
+#define MV_GPIO_DATA_IN_POL_REG  (0xc)
+#define MV_GPIO_DATA_IN_REG  (0x10)
+
+typedef struct {
+  EMBEDDED_GPIO GpioProtocol;
+  GPIO_CONTROLLER  *SoCGpio;
+  UINTN GpioDeviceCount;
+  UINTN Signature;
+  EFI_HANDLEHandle;
+} MV_GPIO;
+
+#endif // __MV_GPIO_H__
diff --git a/Silicon/Marvell/Include/Protocol/MvGpio.h 
b/Silicon/Marvell/Include/Protocol/MvGpio.h
index c9f1007..3319b79 100644
--- a/Silicon/Marvell/Include/Protocol/MvGpio.h
+++ b/Silicon/Marvell/Include/Protocol/MvGpio.h
@@ -27,6 +27,16 @@ typedef enum {
   MV_GPIO_DRIVER_TYPE_SOC_CONTROLLER,
 } MV_GPIO_DRIVER_TYPE;
 
+typedef enum {
+  MV_GPIO_AP806_CONTROLLER0,
+  MV_GPIO_CP0_CONTROLLER0,
+  MV_GPIO_CP0_CONTROLLER1,
+  MV_GPIO_CP1_CONTROLLER0,
+  MV_GPIO_CP1_CONTROLLER1,
+  MV_GPIO_CP2_CONTROLLER0,
+  MV_GPIO_CP2_CONTROLLER1,
+} MV_GPIO_SOC_CONTROLLER_TYPE;
+
 typedef struct {
   VENDOR_DEVICE_PATHHeader;
   MV_GPIO_DRIVER_TYPE   GpioDriverType;
diff --git a/Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.c 
b/Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.c
new file mode 100644
index 000..4d5e530
--- /dev/null
+++ b/Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.c
@@ -0,0 +1,372 @@
+/**
+*
+*  Copyright (c) 2018, Marvell International Ltd. All rights reserved.
+*
+*  This program and the accompanying 

[edk2] [platforms: PATCH v2 07/12] Marvell/Protocol: Introduce GPIO helper header

[Marcin Wojtas]

From: jinghua 

This patch introduces a helper header that can be used by
multiple EMBEDDED_GPIO protocol producers (e.g. platform
driver or GPIO expanders). The drives are differentiated by
MV_GPIO_DRIVER_TYPE field of driver's MV_GPIO_DEVICE_PATH.

In order to ease selection of the desired GPIO controller
a helper function was added - MarvellGpioGetProtocol().

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Silicon/Marvell/Include/Protocol/MvGpio.h | 156 
 1 file changed, 156 insertions(+)
 create mode 100644 Silicon/Marvell/Include/Protocol/MvGpio.h

diff --git a/Silicon/Marvell/Include/Protocol/MvGpio.h 
b/Silicon/Marvell/Include/Protocol/MvGpio.h
new file mode 100644
index 000..c9f1007
--- /dev/null
+++ b/Silicon/Marvell/Include/Protocol/MvGpio.h
@@ -0,0 +1,156 @@
+/**
+*
+*  Copyright (C) 2018, Marvell International Ltd. and its affiliates.
+*
+*  This program and the accompanying materials are licensed and made available
+*  under the terms and conditions of the BSD License which accompanies this
+*  distribution. The full text of the license may be found at
+*  http://opensource.org/licenses/bsd-license.php
+*
+*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+*
+**/
+#ifndef __MV_GPIO_PROTOCOL_H__
+#define __MV_GPIO_PROTOCOL_H__
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+typedef enum {
+  MV_GPIO_DRIVER_TYPE_SOC_CONTROLLER,
+} MV_GPIO_DRIVER_TYPE;
+
+typedef struct {
+  VENDOR_DEVICE_PATHHeader;
+  MV_GPIO_DRIVER_TYPE   GpioDriverType;
+  EFI_DEVICE_PATH_PROTOCOL  End;
+} MV_GPIO_DEVICE_PATH;
+
+typedef struct {
+  UINTNControllerId;
+  UINTNPinNumber;
+  BOOLEAN  ActiveHigh;
+} MV_GPIO_PIN;
+
+/*
+ * Check if the driver type matches the requested value.
+ * In case of the success open the GPIO protocol and return.
+ */
+STATIC
+inline
+EFI_STATUS
+EFIAPI
+MvGpioFindMatchingDriver (
+  IN MV_GPIO_DRIVER_TYPEGpioDriverType,
+  IN EFI_HANDLE HandleBuffer,
+  IN EFI_DEVICE_PATH   *DevicePath,
+  IN OUT EMBEDDED_GPIO**GpioProtocol
+  )
+{
+  MV_GPIO_DEVICE_PATH *GpioDevicePath;
+  EFI_STATUS   Status;
+
+  while (!IsDevicePathEndType (DevicePath)) {
+/* Check if GpioDriverType matches one found in the device path */
+GpioDevicePath = (MV_GPIO_DEVICE_PATH *)DevicePath;
+if (GpioDevicePath->GpioDriverType != GpioDriverType) {
+  DevicePath = NextDevicePathNode (DevicePath);
+  continue;
+}
+
+/*
+ * Open GpioProtocol. With EFI_OPEN_PROTOCOL_GET_PROTOCOL attribute
+ * the consumer is not obliged to call CloseProtocol.
+ */
+Status = gBS->OpenProtocol (HandleBuffer,
+,
+(VOID **)GpioProtocol,
+gImageHandle,
+NULL,
+EFI_OPEN_PROTOCOL_GET_PROTOCOL);
+return Status;
+  }
+
+  return EFI_NOT_FOUND;
+}
+
+/*
+ * Select desired protocol producer upon MV_GPIO_DRIVER_TYPE
+ * field of driver's MV_GPIO_DEVICE_PATH.
+ */
+STATIC
+inline
+EFI_STATUS
+EFIAPI
+MvGpioGetProtocol (
+  IN MV_GPIO_DRIVER_TYPEGpioDriverType,
+  IN OUT EMBEDDED_GPIO**GpioProtocol
+  )
+{
+  EFI_DEVICE_PATH *DevicePath;
+  EFI_HANDLE  *HandleBuffer;
+  EFI_STATUS   Status;
+  UINTNHandleCount;
+  UINTNIndex;
+
+  /* Locate Handles of all EMBEDDED_GPIO producers */
+  Status = gBS->LocateHandleBuffer (ByProtocol,
+  ,
+  NULL,
+  ,
+  );
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "%a: Unable to locate handles\n", __FUNCTION__));
+return Status;
+  }
+
+  /* Iterate over all protocol producers */
+  for (Index = 0; Index < HandleCount; Index++) {
+/* Open device path protocol installed on each handle */
+Status = gBS->OpenProtocol (HandleBuffer[Index],
+,
+(VOID **),
+gImageHandle,
+NULL,
+EFI_OPEN_PROTOCOL_GET_PROTOCOL);
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR, "%a: Unable to find DevicePath\n", __FUNCTION__));
+  continue;
+}
+
+/*
+ * Check if the driver type matches the requested value.
+ * In case of the success open the GPIO protocol and return.
+ * If there is no match, repeat procedure with the next handle.
+ */
+Status = MvGpioFindMatchingDriver (GpioDriverType,
+   HandleBuffer[Index],
+   DevicePath,
+   GpioProtocol);
+if (Status == EFI_NOT_FOUND) {
+  continue;
+} else if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR,
+"%a: Unable to open GPIO protocol\n",
+__FUNCTION__));
+}
+
+gBS->FreePool (HandleBuffer);
+
+return Status;
+  }
+
+  

[edk2] [platforms: PATCH v2 06/12] Marvell/Drivers: MvBoardDesc: Extend protocol with GPIO support

[Marcin Wojtas]

Introduce new callback that can provide information
about GPIO SoC controllers, as well as on-board
I2C IO expanders. According ArmadaSoCDescLib
ArmadaBoardDescLib routines are used for
obtaining required data.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Silicon/Marvell/Include/Protocol/BoardDesc.h   |  8 
 Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe.c | 43 
 2 files changed, 51 insertions(+)

diff --git a/Silicon/Marvell/Include/Protocol/BoardDesc.h 
b/Silicon/Marvell/Include/Protocol/BoardDesc.h
index 1d57a16..02905ea 100644
--- a/Silicon/Marvell/Include/Protocol/BoardDesc.h
+++ b/Silicon/Marvell/Include/Protocol/BoardDesc.h
@@ -50,6 +50,13 @@ EFI_STATUS
 
 typedef
 EFI_STATUS
+(EFIAPI *MV_BOARD_GPIO_DESCRIPTION_GET) (
+  IN MARVELL_BOARD_DESC_PROTOCOL*This,
+  IN OUT MV_BOARD_GPIO_DESCRIPTION **GpioDescription
+  );
+
+typedef
+EFI_STATUS
 (EFIAPI *MV_BOARD_DESC_I2C_GET) (
   IN MARVELL_BOARD_DESC_PROTOCOL  *This,
   IN OUT MV_BOARD_I2C_DESC   **I2cDesc
@@ -113,6 +120,7 @@ struct _MARVELL_BOARD_DESC_PROTOCOL {
   MV_BOARD_DESC_UTMI_GET BoardDescUtmiGet;
   MV_BOARD_DESC_XHCI_GET BoardDescXhciGet;
   MV_BOARD_DESC_FREE BoardDescFree;
+  MV_BOARD_GPIO_DESCRIPTION_GET  GpioDescriptionGet;
 };
 
 #endif // __MARVELL_BOARD_DESC_PROTOCOL_H__
diff --git a/Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe.c 
b/Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe.c
index f71bfc4..e348b85 100644
--- a/Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe.c
+++ b/Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe.c
@@ -100,6 +100,48 @@ MvBoardDescComPhyGet (
 
 STATIC
 EFI_STATUS
+MvBoardGpioDescriptionGet (
+  IN MARVELL_BOARD_DESC_PROTOCOL*This,
+  IN OUT MV_BOARD_GPIO_DESCRIPTION **GpioDescription
+  )
+{
+  MV_BOARD_GPIO_DESCRIPTION *Description;
+  UINTN SoCGpioCount, GpioExpanderCount;
+  MV_GPIO_EXPANDER *GpioExpanders;
+  GPIO_CONTROLLER *SoCGpio;
+  EFI_STATUS Status;
+
+  /* Get SoC data about all available GPIO controllers */
+  Status = ArmadaSoCGpioGet (, );
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+
+  /* Get per-board information about all available I2C IO expanders */
+  Status = ArmadaBoardGpioExpanderGet (, );
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+
+  /* Allocate and fill board description */
+  Description = AllocateZeroPool (sizeof (MV_BOARD_GPIO_DESCRIPTION));
+  if (Description == NULL) {
+DEBUG ((DEBUG_ERROR, "%a: Cannot allocate memory\n", __FUNCTION__));
+return EFI_OUT_OF_RESOURCES;
+  }
+
+  Description->SoCGpio = SoCGpio;
+  Description->GpioDeviceCount = SoCGpioCount;
+  Description->GpioExpanders = GpioExpanders;
+  Description->GpioExpanderCount = GpioExpanderCount;
+
+  *GpioDescription = Description;
+
+  return EFI_SUCCESS;
+}
+
+STATIC
+EFI_STATUS
 MvBoardDescI2cGet (
   IN MARVELL_BOARD_DESC_PROTOCOL  *This,
   IN OUT MV_BOARD_I2C_DESC   **I2cDesc
@@ -571,6 +613,7 @@ MvBoardDescInitProtocol (
   BoardDescProtocol->BoardDescUtmiGet = MvBoardDescUtmiGet;
   BoardDescProtocol->BoardDescXhciGet = MvBoardDescXhciGet;
   BoardDescProtocol->BoardDescFree = MvBoardDescFree;
+  BoardDescProtocol->GpioDescriptionGet = MvBoardGpioDescriptionGet;
 
   return EFI_SUCCESS;
 }
-- 
2.7.4

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

[edk2] [platforms: PATCH v2 05/12] Marvell/Armada80x0Db: Extend board description library with GPIO

[Marcin Wojtas]

This patch implements ArmadaBoarDescLib library for
Armada80x0Db comunity board and introduces ArmadaBoardGpioGet
routine with per-board GPIO expander description.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 
Platform/Marvell/Armada80x0Db/Armada80x0DbBoardDescLib/Armada80x0DbBoardDescLib.inf
 |  1 +
 
Platform/Marvell/Armada80x0Db/Armada80x0DbBoardDescLib/Armada80x0DbBoardDescLib.c
   | 31 
 2 files changed, 32 insertions(+)

diff --git 
a/Platform/Marvell/Armada80x0Db/Armada80x0DbBoardDescLib/Armada80x0DbBoardDescLib.inf
 
b/Platform/Marvell/Armada80x0Db/Armada80x0DbBoardDescLib/Armada80x0DbBoardDescLib.inf
index 2d39d96..786b7f0 100644
--- 
a/Platform/Marvell/Armada80x0Db/Armada80x0DbBoardDescLib/Armada80x0DbBoardDescLib.inf
+++ 
b/Platform/Marvell/Armada80x0Db/Armada80x0DbBoardDescLib/Armada80x0DbBoardDescLib.inf
@@ -25,6 +25,7 @@
   Armada80x0DbBoardDescLib.c
 
 [Packages]
+  EmbeddedPkg/EmbeddedPkg.dec
   MdeModulePkg/MdeModulePkg.dec
   MdePkg/MdePkg.dec
   Silicon/Marvell/Marvell.dec
diff --git 
a/Platform/Marvell/Armada80x0Db/Armada80x0DbBoardDescLib/Armada80x0DbBoardDescLib.c
 
b/Platform/Marvell/Armada80x0Db/Armada80x0DbBoardDescLib/Armada80x0DbBoardDescLib.c
index feb69ad..f6e3675 100644
--- 
a/Platform/Marvell/Armada80x0Db/Armada80x0DbBoardDescLib/Armada80x0DbBoardDescLib.c
+++ 
b/Platform/Marvell/Armada80x0Db/Armada80x0DbBoardDescLib/Armada80x0DbBoardDescLib.c
@@ -21,6 +21,37 @@
 #include 
 #include 
 
+#include 
+
+//
+// GPIO Expanders
+//
+STATIC MV_GPIO_EXPANDER mGpioExpanders[] = {
+  {
+8, /* PCA9555 */
+0x21,
+0x0,
+  },
+  {
+8, /* PCA9555 */
+0x25,
+0x0,
+  },
+};
+
+EFI_STATUS
+EFIAPI
+ArmadaBoardGpioExpanderGet (
+  IN OUT MV_GPIO_EXPANDER **GpioExpanders,
+  IN OUT UINTN *GpioExpanderCount
+  )
+{
+  *GpioExpanderCount = ARRAY_SIZE (mGpioExpanders);
+  *GpioExpanders = mGpioExpanders;
+
+  return EFI_SUCCESS;
+}
+
 //
 // Order of devices in SdMmcDescTemplate has to be in par with ArmadaSoCDescLib
 //
-- 
2.7.4

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

[edk2] [platforms: PATCH v2 04/12] Marvell/Armada70x0Db: Extend board description library with GPIO

[Marcin Wojtas]

This patch implements ArmadaBoarDescLib library for
Armada70x0Db comunity board and introduces ArmadaBoardGpioGet
routine with per-board GPIO expander description.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 
Platform/Marvell/Armada70x0Db/Armada70x0DbBoardDescLib/Armada70x0DbBoardDescLib.inf
 |  1 +
 
Platform/Marvell/Armada70x0Db/Armada70x0DbBoardDescLib/Armada70x0DbBoardDescLib.c
   | 25 
 2 files changed, 26 insertions(+)

diff --git 
a/Platform/Marvell/Armada70x0Db/Armada70x0DbBoardDescLib/Armada70x0DbBoardDescLib.inf
 
b/Platform/Marvell/Armada70x0Db/Armada70x0DbBoardDescLib/Armada70x0DbBoardDescLib.inf
index b26f55b..c995515 100644
--- 
a/Platform/Marvell/Armada70x0Db/Armada70x0DbBoardDescLib/Armada70x0DbBoardDescLib.inf
+++ 
b/Platform/Marvell/Armada70x0Db/Armada70x0DbBoardDescLib/Armada70x0DbBoardDescLib.inf
@@ -25,6 +25,7 @@
   Armada70x0DbBoardDescLib.c
 
 [Packages]
+  EmbeddedPkg/EmbeddedPkg.dec
   MdeModulePkg/MdeModulePkg.dec
   MdePkg/MdePkg.dec
   Silicon/Marvell/Marvell.dec
diff --git 
a/Platform/Marvell/Armada70x0Db/Armada70x0DbBoardDescLib/Armada70x0DbBoardDescLib.c
 
b/Platform/Marvell/Armada70x0Db/Armada70x0DbBoardDescLib/Armada70x0DbBoardDescLib.c
index 48c68e4..f63d8fd 100644
--- 
a/Platform/Marvell/Armada70x0Db/Armada70x0DbBoardDescLib/Armada70x0DbBoardDescLib.c
+++ 
b/Platform/Marvell/Armada70x0Db/Armada70x0DbBoardDescLib/Armada70x0DbBoardDescLib.c
@@ -21,6 +21,31 @@
 #include 
 #include 
 
+#include 
+
+//
+// GPIO Expander
+//
+STATIC MV_GPIO_EXPANDER mGpioExpander = {
+  8, /* PCA9555 */
+  0x21,
+  0x0,
+};
+
+
+EFI_STATUS
+EFIAPI
+ArmadaBoardGpioExpanderGet (
+  IN OUT MV_GPIO_EXPANDER **GpioExpanders,
+  IN OUT UINTN *GpioExpanderCount
+  )
+{
+  *GpioExpanderCount = 1;
+  *GpioExpanders = 
+
+  return EFI_SUCCESS;
+}
+
 //
 // Order of devices in SdMmcDescTemplate has to be in par with ArmadaSoCDescLib
 //
-- 
2.7.4

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

[edk2] [platforms: PATCH v2 03/12] SolidRun/Armada80x0McBin: Extend board description library with GPIO

[Marcin Wojtas]

This patch implements ArmadaBoarDescLib library for
Armada80x0McBin comunity board and introduces ArmadaBoardGpioGet
routine with per-board GPIO expander description.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 
Platform/SolidRun/Armada80x0McBin/Armada80x0McBinBoardDescLib/Armada80x0McBinBoardDescLib.inf
 |  1 +
 
Platform/SolidRun/Armada80x0McBin/Armada80x0McBinBoardDescLib/Armada80x0McBinBoardDescLib.c
   | 17 +
 2 files changed, 18 insertions(+)

diff --git 
a/Platform/SolidRun/Armada80x0McBin/Armada80x0McBinBoardDescLib/Armada80x0McBinBoardDescLib.inf
 
b/Platform/SolidRun/Armada80x0McBin/Armada80x0McBinBoardDescLib/Armada80x0McBinBoardDescLib.inf
index 63a4f66..43e4b9e 100644
--- 
a/Platform/SolidRun/Armada80x0McBin/Armada80x0McBinBoardDescLib/Armada80x0McBinBoardDescLib.inf
+++ 
b/Platform/SolidRun/Armada80x0McBin/Armada80x0McBinBoardDescLib/Armada80x0McBinBoardDescLib.inf
@@ -25,6 +25,7 @@
   Armada80x0McBinBoardDescLib.c
 
 [Packages]
+  EmbeddedPkg/EmbeddedPkg.dec
   MdeModulePkg/MdeModulePkg.dec
   MdePkg/MdePkg.dec
   Silicon/Marvell/Marvell.dec
diff --git 
a/Platform/SolidRun/Armada80x0McBin/Armada80x0McBinBoardDescLib/Armada80x0McBinBoardDescLib.c
 
b/Platform/SolidRun/Armada80x0McBin/Armada80x0McBinBoardDescLib/Armada80x0McBinBoardDescLib.c
index d52adfc..32596ad 100644
--- 
a/Platform/SolidRun/Armada80x0McBin/Armada80x0McBinBoardDescLib/Armada80x0McBinBoardDescLib.c
+++ 
b/Platform/SolidRun/Armada80x0McBin/Armada80x0McBinBoardDescLib/Armada80x0McBinBoardDescLib.c
@@ -22,6 +22,23 @@
 #include 
 
 //
+// GPIO Expander
+//
+EFI_STATUS
+EFIAPI
+ArmadaBoardGpioExpanderGet (
+  IN OUT MV_GPIO_EXPANDER **GpioExpanders,
+  IN OUT UINTN *GpioExpanderCount
+  )
+{
+  /* No GPIO expanders on board */
+  *GpioExpanders = NULL;
+  *GpioExpanderCount = 0;
+
+  return EFI_SUCCESS;
+}
+
+//
 // Order of devices in SdMmcDescTemplate has to be in par with ArmadaSoCDescLib
 //
 STATIC
-- 
2.7.4

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

[edk2] [platforms: PATCH v2 02/12] Marvell/Library: ArmadaBoardDescLib: Add GPIO information

[Marcin Wojtas]

This patch extends library with GPIO devices per-board
description. Both embedded SoC controllers and
I2C IO expanders are supported. Add a helper routine
for obtaining information about the latter.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Silicon/Marvell/Include/Library/ArmadaBoardDescLib.h | 23 
 1 file changed, 23 insertions(+)

diff --git a/Silicon/Marvell/Include/Library/ArmadaBoardDescLib.h 
b/Silicon/Marvell/Include/Library/ArmadaBoardDescLib.h
index 3fe2988..6ec5ace 100644
--- a/Silicon/Marvell/Include/Library/ArmadaBoardDescLib.h
+++ b/Silicon/Marvell/Include/Library/ArmadaBoardDescLib.h
@@ -25,6 +25,29 @@ typedef struct {
 } MV_BOARD_COMPHY_DESC;
 
 //
+// GPIO devices per-board description
+//
+typedef struct {
+  UINTN ChipId;
+  UINTN I2cAddress;
+  UINTN I2cBus;
+} MV_GPIO_EXPANDER;
+
+typedef struct {
+  GPIO_CONTROLLER  *SoCGpio;
+  UINTN GpioDeviceCount;
+  MV_GPIO_EXPANDER *GpioExpanders;
+  UINTN GpioExpanderCount;
+} MV_BOARD_GPIO_DESCRIPTION;
+
+EFI_STATUS
+EFIAPI
+ArmadaBoardGpioExpanderGet (
+  IN OUT MV_GPIO_EXPANDER **GpioExpanders,
+  IN OUT UINTN *GpioExpanderCount
+  );
+
+//
 // I2C devices per-board description
 //
 typedef struct {
-- 
2.7.4

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

[edk2] [platforms: PATCH v2 01/12] Marvell/Library: ArmadaSoCDescLib: Add GPIO information

[Marcin Wojtas]

This patch introduces new library callback (ArmadaSoCGpioGet ()),
which dynamically allocates and fills EmbeddedGpio's
GPIO_CONTROLLER structure with the SoC description of GPIO controllers.

Because the library header is indirectly used in many modules,
update all dependencies after including EmbeddedGpio.h.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.inf 
  |  1 +
 
Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.inf
 |  1 +
 Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe.inf   
  |  1 +
 Silicon/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.inf  
  |  1 +
 Silicon/Marvell/Drivers/Net/MvMdioDxe/MvMdioDxe.inf
  |  1 +
 Silicon/Marvell/Drivers/SdMmc/XenonDxe/XenonDxe.inf
  |  1 +
 Silicon/Marvell/Library/ComPhyLib/ComPhyLib.inf
  |  1 +
 Silicon/Marvell/Library/IcuLib/IcuLib.inf  
  |  1 +
 Silicon/Marvell/Library/UtmiPhyLib/UtmiPhyLib.inf  
  |  1 +
 Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.h 
  | 10 +
 Silicon/Marvell/Include/Library/ArmadaSoCDescLib.h 
  | 12 ++
 Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.c 
  | 39 
 12 files changed, 70 insertions(+)

diff --git a/Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.inf 
b/Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.inf
index 5503463..e707fe9 100644
--- a/Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.inf
+++ b/Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.inf
@@ -25,6 +25,7 @@
   PlatInitDxe.c
 
 [Packages]
+  EmbeddedPkg/EmbeddedPkg.dec
   MdeModulePkg/MdeModulePkg.dec
   MdePkg/MdePkg.dec
   Silicon/Marvell/Marvell.dec
diff --git 
a/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.inf
 
b/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.inf
index 2b73b73..48a320c 100644
--- 
a/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.inf
+++ 
b/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.inf
@@ -24,6 +24,7 @@
   Armada7k8kSoCDescLib.c
 
 [Packages]
+  EmbeddedPkg/EmbeddedPkg.dec
   MdeModulePkg/MdeModulePkg.dec
   MdePkg/MdePkg.dec
   Silicon/Marvell/Marvell.dec
diff --git a/Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe.inf 
b/Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe.inf
index 0b93948..0b641fe 100644
--- a/Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe.inf
+++ b/Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe.inf
@@ -42,6 +42,7 @@
   MvBoardDescDxe.h
 
 [Packages]
+  EmbeddedPkg/EmbeddedPkg.dec
   MdeModulePkg/MdeModulePkg.dec
   MdePkg/MdePkg.dec
   Silicon/Marvell/Marvell.dec
diff --git a/Silicon/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.inf 
b/Silicon/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.inf
index 0eef350..e5bd370 100755
--- a/Silicon/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.inf
+++ b/Silicon/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.inf
@@ -41,6 +41,7 @@
   MvI2cDxe.c
 
 [Packages]
+  EmbeddedPkg/EmbeddedPkg.dec
   MdePkg/MdePkg.dec
   MdeModulePkg/MdeModulePkg.dec
   ArmPlatformPkg/ArmPlatformPkg.dec
diff --git a/Silicon/Marvell/Drivers/Net/MvMdioDxe/MvMdioDxe.inf 
b/Silicon/Marvell/Drivers/Net/MvMdioDxe/MvMdioDxe.inf
index 739576f..8a877da 100644
--- a/Silicon/Marvell/Drivers/Net/MvMdioDxe/MvMdioDxe.inf
+++ b/Silicon/Marvell/Drivers/Net/MvMdioDxe/MvMdioDxe.inf
@@ -45,6 +45,7 @@
 [Packages]
   ArmPkg/ArmPkg.dec
   ArmPlatformPkg/ArmPlatformPkg.dec
+  EmbeddedPkg/EmbeddedPkg.dec
   MdeModulePkg/MdeModulePkg.dec
   MdePkg/MdePkg.dec
   Silicon/Marvell/Marvell.dec
diff --git a/Silicon/Marvell/Drivers/SdMmc/XenonDxe/XenonDxe.inf 
b/Silicon/Marvell/Drivers/SdMmc/XenonDxe/XenonDxe.inf
index 00c738a..09c5842 100644
--- a/Silicon/Marvell/Drivers/SdMmc/XenonDxe/XenonDxe.inf
+++ b/Silicon/Marvell/Drivers/SdMmc/XenonDxe/XenonDxe.inf
@@ -35,6 +35,7 @@
   XenonSdMmcOverride.h
 
 [Packages]
+  EmbeddedPkg/EmbeddedPkg.dec
   MdePkg/MdePkg.dec
   MdeModulePkg/MdeModulePkg.dec
   Silicon/Marvell/Marvell.dec
diff --git a/Silicon/Marvell/Library/ComPhyLib/ComPhyLib.inf 
b/Silicon/Marvell/Library/ComPhyLib/ComPhyLib.inf
index 36f498b..c360edd 100644
--- a/Silicon/Marvell/Library/ComPhyLib/ComPhyLib.inf
+++ b/Silicon/Marvell/Library/ComPhyLib/ComPhyLib.inf
@@ -41,6 +41,7 @@
 [Packages]
   MdePkg/MdePkg.dec
   MdeModulePkg/MdeModulePkg.dec
+  EmbeddedPkg/EmbeddedPkg.dec
   ArmPkg/ArmPkg.dec
   ArmPlatformPkg/ArmPlatformPkg.dec
   Silicon/Marvell/Marvell.dec
diff --git a/Silicon/Marvell/Library/IcuLib/IcuLib.inf 
b/Silicon/Marvell/Library/IcuLib/IcuLib.inf
index 0010141..ea662be 100644
--- a/Silicon/Marvell/Library/IcuLib/IcuLib.inf
+++ 

[edk2] [platforms: PATCH v2 00/12] Armada 7k8k GPIO support

[Marcin Wojtas]

Hi,

With a big delay caused by private and professional matters,
I finaly submit the second version of the GPIO support for
Marvell Armada SoCs. The rework was HUGE. The biggest change
is dropping custom GPIO protocol and start using the generic
EMBEDDED_GPIO with all its types. I think I answered
all of the review remarks, the details can be found in the changelog
below.

Patches are available in the github:
https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/gpio-upstream-r20190110

I also enclose a diff between v1 and v2, which maybe can ease a bit
the effort of review:
https://pastebin.com/GvAiYfJD

I am looking forward to your feedback.

Best regards,
Marcin

Changelog:
v1->v2:
* All
  - rebase on top of the master branch and Xenon changes

* 1/12
  - s/AP/AP806/ in order to avoid confusion
  - drop desc/DESC usage and improve variables naming
  - use GPIO_CONTROLLER from EmbeddedGpio.h instead of custom MV_SOC_GPIO
  - update commit message

* 2,3,4,5/12
  - drop desc/DESC usage and improve variables naming
  - drop reference to I2c and use GpioExpander
  - improve commit logs

* 6/12
  - drop desc/DESC usage and improve variables naming
  - drop reference to I2c and use GpioExpander
  - remove global variable - same as for other interfaces the consumer
is responsible for avoiding memory leak

* 7/12
  - use MV_GPIO_ prefix
  - switch to EMBEDDED_GPIO
  - remove custom Marvell GPIO Protocol and types
  - add subroutine to MvGpioGetProtocol and more coments to clarify the code
  - add driver types and related enums in other commits

* 8/12
  - extend error path in the entry point, rename variables
  - use MV_GPIO_ prefix
  - switch to EMBEDDED_GPIO
  - remove custom Marvell GPIO Protocol and types
  - replace '!!' expression for obtaining pin state
  - remove BIT() macro
  - use generic mDevicePathTemplate name
  - put validate function under '#if !defined(MDEPKG_NDEBUG)' and
 call from inside ASSERT_EFI_ERROR, add comment
  - update commit message
  - add common enum for describing controllers
  - change authorship

- 9/12
  - Add Leif's RB

* 10/12
  - same modifications as 8/12
  - use I2C flags directly and remove PCA95XX_OPERATION enum
  - add common enum for describing controllers

* 11/12
  - Add Leif's RB

* 12/12
  - Add local headers
  - Make STATIC names more generic
  - s/GetInitializerForType/NonDiscoverableDeviceInitializerGet/
  - Use global enum for McBin GPIO controller

Marcin Wojtas (11):
  Marvell/Library: ArmadaSoCDescLib: Add GPIO information
  Marvell/Library: ArmadaBoardDescLib: Add GPIO information
  SolidRun/Armada80x0McBin: Extend board description library with GPIO
  Marvell/Armada70x0Db: Extend board description library with GPIO
  Marvell/Armada80x0Db: Extend board description library with GPIO
  Marvell/Drivers: MvBoardDesc: Extend protocol with GPIO support
  Marvell/Drivers: MvGpioDxe: Introduce platform GPIO driver
  Marvell/Drivers: I2c: Use common header for macros
  Marvell/Drivers: MvPca95xxDxe: Introduce GPIO expander driver
  Marvell/Armada7k8k: Enable GPIO drivers compilation
  Marvell/Armada7k8k: Introduce NonDiscoverable device init routines

jinghua (1):
  Marvell/Protocol: Introduce GPIO helper header

 Silicon/Marvell/Marvell.dec
   |   1 +
 Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc  
   |   2 +
 Platform/Marvell/Armada70x0Db/Armada70x0Db.dsc 
   |   7 +-
 Platform/Marvell/Armada80x0Db/Armada80x0Db.dsc 
   |   3 +
 Platform/SolidRun/Armada80x0McBin/Armada80x0McBin.dsc  
   |   3 +
 
Platform/Marvell/Armada70x0Db/Armada70x0DbBoardDescLib/Armada70x0DbBoardDescLib.inf
   |   1 +
 
Platform/Marvell/Armada70x0Db/NonDiscoverableInitLib/NonDiscoverableInitLib.inf 
  |  48 ++
 
Platform/Marvell/Armada80x0Db/Armada80x0DbBoardDescLib/Armada80x0DbBoardDescLib.inf
   |   1 +
 
Platform/Marvell/Armada80x0Db/NonDiscoverableInitLib/NonDiscoverableInitLib.inf 
  |  49 ++
 
Platform/SolidRun/Armada80x0McBin/Armada80x0McBinBoardDescLib/Armada80x0McBinBoardDescLib.inf
 |   1 +
 
Platform/SolidRun/Armada80x0McBin/NonDiscoverableInitLib/NonDiscoverableInitLib.inf
   |  49 ++
 Silicon/Marvell/Armada7k8k/Drivers/PlatInitDxe/PlatInitDxe.inf 
   |   1 +
 
Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.inf
  |   1 +
 Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe.inf   
   |   1 +
 Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.inf   
   |  44 ++
 Silicon/Marvell/Drivers/Gpio/MvPca95xxDxe/MvPca95xxDxe.inf 
   |  45 ++
 Silicon/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.inf  
  

Re: [edk2] [PATCH 4/6] MdeModulePkg/FaultTolerantWriteDxe: implement standalone MM version

[Wang, Jian J]

Ard,


Regards,
Jian


> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Friday, January 04, 2019 2:28 AM
> To: edk2-devel@lists.01.org
> Cc: Ard Biesheuvel ; Laszlo Ersek
> ; Leif Lindholm ; Kinney,
> Michael D ; Gao, Liming ;
> Wang, Jian J ; Wu, Hao A ;
> Jagadeesh Ujja ; Achin Gupta
> ; Thomas Panakamattam Abraham
> ; Sami Mujawar 
> Subject: [PATCH 4/6] MdeModulePkg/FaultTolerantWriteDxe: implement
> standalone MM version
> 
> Implement a new version of the fault tolerant write driver that can
> be used in the context of a standalone MM implementation.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
> 
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandalon
> eMm.c   | 70 +++
> 
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandalon
> eMm.inf | 90 
>  2 files changed, 160 insertions(+)
> 
> diff --git
> a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> oneMm.c
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> oneMm.c
> new file mode 100644
> index ..b6fbf6c64f8a
> --- /dev/null
> +++
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> oneMm.c
> @@ -0,0 +1,70 @@
> +/** @file
> +
> +  Parts of the SMM/MM implementation that are specific to standalone MM
> +
> +Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2018, Linaro, Ltd. All rights reserved.
> +This program and the accompanying materials
> +are licensed and made available under the terms and conditions of the BSD
> License
> +which accompanies this distribution.  The full text of the license may be 
> found
> at
> +http://opensource.org/licenses/bsd-license.php
> +
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS
> OR IMPLIED.
> +
> +**/
> +
> +#include 
> +#include 
> +#include "FaultTolerantWrite.h"
> +#include "FaultTolerantWriteSmmCommon.h"
> +
> +BOOLEAN
> +FtwSmmIsBufferOutsideSmmValid (
> +  IN EFI_PHYSICAL_ADDRESS  Buffer,
> +  IN UINT64Length
> +  )
> +{
> +  return TRUE;
> +}
> +
> +/**
> +  Internal implementation of CRC32. Depending on the execution context
> +  (standalone SMM or DXE vs standalone MM), this function is implemented
> +  via a call to the CalculateCrc32 () boot service, or via a library
> +  call.
> +
> +  If Buffer is NULL, then ASSERT().
> +  If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
> +
> +  @param[in]  Buffer   A pointer to the buffer on which the 32-bit CRC 
> is to be
> computed.
> +  @param[in]  Length   The number of bytes in the buffer Data.
> +
> +  @retval Crc32The 32-bit CRC was computed for the data buffer.
> +
> +**/
> +UINT32
> +FtwCalculateCrc32 (
> +  IN  VOID *Buffer,
> +  IN  UINTNLength
> +  )
> +{
> +  return CalculateCrc32 (Buffer, Length);
> +}
> +
> +VOID
> +FtwNotifySmmReady (
> +  VOID
> +  )
> +{
> +}
> +
> +EFI_STATUS
> +EFIAPI
> +StandaloneMmFaultTolerantWriteInitialize (
> +  IN EFI_HANDLEImageHandle,
> +  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
> +  )
> +{
> +  return MmFaultTolerantWriteInitialize ();
> +}
> diff --git
> a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> oneMm.inf
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> oneMm.inf
> new file mode 100644
> index ..99bd62ad5ceb
> --- /dev/null
> +++
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> oneMm.inf
> @@ -0,0 +1,90 @@
> + ## @file
> +#   Fault Tolerant Write Smm Driver.
> +#
> +#   This driver installs SMM Fault Tolerant Write (FTW) protocol, which 
> provides
> fault
> +#   tolerant write capability in SMM environment for block devices. Its
> implementation
> +#   depends on the full functionality SMM FVB protocol that support read,
> write/erase
> +#   flash access.
> +#
> +# Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
> +#
> +#  This program and the accompanying materials
> +#  are licensed and made available under the terms and conditions of the BSD
> License
> +#  which accompanies this distribution. The full text of the license may be 
> found
> at
> +#  http://opensource.org/licenses/bsd-license.php
> +#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> +#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +#
> +##
> +
> +[Defines]
> +  INF_VERSION= 0x0001001A
> +  BASE_NAME  = FaultTolerantWriteStandaloneMm
> +  FILE_GUID  = 3aade4ec-63cc-4a48-a928-5a374dd463eb
> +  MODULE_TYPE= MM_STANDALONE
> +  VERSION_STRING = 1.0
> +  PI_SPECIFICATION_VERSION   = 

Re: [edk2] [PATCH 3/6] MdeModulePkg/FaultTolerantWriteDxe: factor out boot service accesses

[Wang, Jian J]

Reviewed-by: Jian J Wang 

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Friday, January 04, 2019 2:28 AM
> To: edk2-devel@lists.01.org
> Cc: Ard Biesheuvel ; Laszlo Ersek
> ; Leif Lindholm ; Kinney,
> Michael D ; Gao, Liming ;
> Wang, Jian J ; Wu, Hao A ;
> Jagadeesh Ujja ; Achin Gupta
> ; Thomas Panakamattam Abraham
> ; Sami Mujawar 
> Subject: [PATCH 3/6] MdeModulePkg/FaultTolerantWriteDxe: factor out boot
> service accesses
> 
> In preparation of providing a standalone MM based FTW driver, move
> the existing SMM driver to the new MM services table, and factor out
> some pieces that are specific to the traditional driver, mainly
> related to the use of UEFI boot services, which are not accessible
> to standalone MM drivers.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  MdeModulePkg/MdeModulePkg.dsc
>   |  1 +
>  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWrite.h
> | 22 -
>  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
> | 31 +++
>  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
> | 54 +--
>  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf
> |  5 +-
> 
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmmCom
> mon.h | 31 +++
> 
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmmDxe.c
> |  1 +
> 
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteTraditiona
> lMm.c | 94 
>  MdeModulePkg/Universal/FaultTolerantWriteDxe/UpdateWorkingBlock.c
> | 10 +--
>  9 files changed, 205 insertions(+), 44 deletions(-)
> 
> diff --git a/MdeModulePkg/MdeModulePkg.dsc
> b/MdeModulePkg/MdeModulePkg.dsc
> index 5d042be3a862..ef3c144ed524 100644
> --- a/MdeModulePkg/MdeModulePkg.dsc
> +++ b/MdeModulePkg/MdeModulePkg.dsc
> @@ -153,6 +153,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
>DebugLib|MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf
> 
> MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLib/SmmMemory
> AllocationLib.inf
> 
> SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTable
> Lib.inf
> +
> MmServicesTableLib|MdePkg/Library/MmServicesTableLib/MmServicesTableLib
> .inf
>LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf
>SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
> 
> diff --git
> a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWrite.h
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWrite.h
> index 844cf3bee04d..8d146264b129 100644
> --- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWrite.h
> +++ b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWrite.h
> @@ -31,7 +31,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
> 
>  //
> @@ -766,4 +765,25 @@ WriteWorkSpaceData (
>IN UINT8  *Buffer
>);
> 
> +/**
> +  Internal implementation of CRC32. Depending on the execution context
> +  (traditional SMM or DXE vs standalone MM), this function is implemented
> +  via a call to the CalculateCrc32 () boot service, or via a library
> +  call.
> +
> +  If Buffer is NULL, then ASSERT().
> +  If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
> +
> +  @param[in]  Buffer   A pointer to the buffer on which the 32-bit CRC 
> is to be
> computed.
> +  @param[in]  Length   The number of bytes in the buffer Data.
> +
> +  @retval Crc32The 32-bit CRC was computed for the data buffer.
> +
> +**/
> +UINT32
> +FtwCalculateCrc32 (
> +  IN  VOID *Buffer,
> +  IN  UINTNLength
> +  );
> +
>  #endif
> diff --git
> a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
> index 094e40f9d86c..24e507104bbe 100644
> ---
> a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
> +++
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
> @@ -51,6 +51,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
> 
>  **/
> 
> +#include 
>  #include "FaultTolerantWrite.h"
>  EFI_EVENT mFvbRegistration = NULL;
> 
> @@ -250,3 +251,33 @@ FaultTolerantWriteInitialize (
> 
>return EFI_SUCCESS;
>  }
> +
> +/**
> +  Internal implementation of CRC32. Depending on the execution context
> +  (traditional SMM or DXE vs standalone MM), this function is implemented
> +  via a call to the CalculateCrc32 () boot service, or via a library
> +  call.
> +
> +  If Buffer is NULL, then ASSERT().
> +  If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
> +
> +  @param[in]  Buffer   A pointer to the buffer on which the 

Re: [edk2] [PATCH 2/6] MdePkg: implement MmServicesTableLib based on traditional SMM

[Wang, Jian J]

Ard,

Regards,
Jian


> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Friday, January 04, 2019 2:28 AM
> To: edk2-devel@lists.01.org
> Cc: Ard Biesheuvel ; Laszlo Ersek
> ; Leif Lindholm ; Kinney,
> Michael D ; Gao, Liming ;
> Wang, Jian J ; Wu, Hao A ;
> Jagadeesh Ujja ; Achin Gupta
> ; Thomas Panakamattam Abraham
> ; Sami Mujawar 
> Subject: [PATCH 2/6] MdePkg: implement MmServicesTableLib based on
> traditional SMM
> 
> The definitions of the rebranded MM protocol stack were chosen such
> that the existing SMM based core drivers can be reused. So let's
> implement MmServicesTableLib based on gEfiMmBaseProtocolGuid, which
> is simply gEfiSmmBase2ProtocolGuid under the hood.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  MdePkg/Library/MmServicesTableLib/MmServicesTableLib.c   | 63
> 
>  MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf | 45
> ++
>  MdePkg/Library/MmServicesTableLib/MmServicesTableLib.uni | 22 +++
>  MdePkg/MdePkg.dsc|  1 +
>  4 files changed, 131 insertions(+)
> 
> diff --git a/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.c
> b/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.c
> new file mode 100644
> index ..f41d25e59805
> --- /dev/null
> +++ b/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.c
> @@ -0,0 +1,63 @@
> +/** @file
> +  MM Services Table Library.
> +
> +  Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
> +  Copyright (c) 2018, Linaro, Ltd. All rights reserved.
> +  This program and the accompanying materials
> +  are licensed and made available under the terms and conditions of the BSD
> License
> +  which accompanies this distribution.  The full text of the license may be 
> found
> at
> +  http://opensource.org/licenses/bsd-license.php.
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +EFI_MM_SYSTEM_TABLE   *gMmst = NULL;
> +
> +/**
> +  The constructor function caches the pointer of SMM Services Table.
> +
> +  @param  ImageHandle   The firmware allocated handle for the EFI image.
> +  @param  SystemTable   A pointer to the EFI System Table.
> +
> +  @retval EFI_SUCCESS   The constructor always returns EFI_SUCCESS.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +MmServicesTableLibConstructor (
> +  IN EFI_HANDLEImageHandle,
> +  IN EFI_SYSTEM_TABLE  *SystemTable
> +  )
> +{
> +  EFI_STATUS  Status;
> +  EFI_MM_BASE_PROTOCOL*InternalMmBase;
> +
> +  InternalMmBase = NULL;
> +  //
> +  // Retrieve MM Base Protocol,  Do not use gBS from
> UefiBootServicesTableLib on purpose
> +  // to prevent inclusion of gBS, gST, and gImageHandle from SMM Drivers
> unless the
> +  // MM driver explicity declares that dependency.
> +  //
> +  Status = SystemTable->BootServices->LocateProtocol (
> +,
> +NULL,
> +(VOID **)
> +);
> +  ASSERT_EFI_ERROR (Status);
> +  ASSERT (InternalMmBase != NULL);
> +
> +  //
> +  // We are in MM, retrieve the pointer to MM System Table
> +  //
> +  InternalMmBase->GetMmstLocation (InternalMmBase, );
> +  ASSERT (gMmst != NULL);
> +
> +  return EFI_SUCCESS;
> +}
> diff --git a/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
> b/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
> new file mode 100644
> index ..4418cc2f1464
> --- /dev/null
> +++ b/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
> @@ -0,0 +1,45 @@
> +## @file
> +# MM Services Table Library.
> +#
> +# Copyright (c) 2009 - 2014, Intel Corporation. All rights reserved.
> +# Copyright (c) 2018, Linaro, Ltd. All rights reserved.
> +#
> +#  This program and the accompanying materials
> +#  are licensed and made available under the terms and conditions of the BSD
> License
> +#  which accompanies this distribution. The full text of the license may be 
> found
> at
> +#  http://opensource.org/licenses/bsd-license.php.
> +#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> +#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +#
> +#
> +##
> +
> +[Defines]
> +  INF_VERSION= 0x0001001B
> +  BASE_NAME  = MmServicesTableLib
> +  MODULE_UNI_FILE= MmServicesTableLib.uni
> +  FILE_GUID  = 9508ECFD-66D1-4B4C-9415-F25F0FFF9E93
> +  MODULE_TYPE= DXE_SMM_DRIVER
> +  VERSION_STRING = 1.0
> +  LIBRARY_CLASS  = MmServicesTableLib|DXE_SMM_DRIVER
> +  PI_SPECIFICATION_VERSION   = 0x00010032
> +  

Re: [edk2] [PATCH v1] ShellPkg/TftpDynamicCommand: Change file writing method in tftp

[Wu, Jiaxin]

Reviewed-by: Wu Jiaxin 

Thanks,
Jiaxin


> -Original Message-
> From: Li, Songpeng
> Sent: Wednesday, January 9, 2019 4:42 PM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Ni, Ray ;
> Wu, Jiaxin 
> Subject: [PATCH v1] ShellPkg/TftpDynamicCommand: Change file writing
> method in tftp
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1433
> 
> Current logic of shell tftp download was writing file after tftp
> download finished, when the file is large, it looks like the shell
> tftp command hanged after download was finished. To improve
> end-user experience, the solution is using split file writing
> instead.
> 
> This patch update the code to open and close file inside
> DownloadFile(), and save each packet to file within callback
> function CheckPacket().
> 
> Since AllocatePage() is no-longer needed, This patch can also
> remove the memory limitation. The download file can be larger
> than system free memory now.
> 
> Cc: Jaben Carsey 
> Cc: Ruiyu Ni 
> Cc: Wu Jiaxin 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Songpeng Li 
> ---
>  ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c | 152
> +---
>  1 file changed, 64 insertions(+), 88 deletions(-)
> 
> diff --git a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> index ed081b5bad7c..a53fe16f0683 100644
> --- a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> +++ b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> @@ -41,6 +41,12 @@ STATIC CONST CHAR16 mTftpProgressFrame[] = L"[
>  // (TFTP_PROGRESS_MESSAGE_SIZE-1) '\b'
>  STATIC CONST CHAR16 mTftpProgressDelete[] =
> L"\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\
> b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b";
> 
> +// Local File Handle
> +SHELL_FILE_HANDLE mFileHandle;
> +
> +// Path of the local file, Unicode encoded
> +CONST CHAR16 *mLocalFilePath;
> +
>  /**
>Check and convert the UINT16 option values of the 'tftp' command
> 
> @@ -166,9 +172,6 @@ GetFileSize (
>@param[in]   FileSize   Size of the file in number of bytes
>@param[in]   BlockSize  Value of the TFTP blksize option
>@param[in]   WindowSize Value of the TFTP window size option
> -  @param[out]  Data   Address where to store the address of the 
> buffer
> -  where the data of the file were downloaded in
> -  case of success.
> 
>@retval  EFI_SUCCESS   The file was downloaded.
>@retval  EFI_OUT_OF_RESOURCES  A memory allocation failed.
> @@ -184,8 +187,7 @@ DownloadFile (
>IN   CONST CHAR8  *AsciiFilePath,
>IN   UINTNFileSize,
>IN   UINT16   BlockSize,
> -  IN   UINT16   WindowSize,
> -  OUT  VOID **Data
> +  IN   UINT16   WindowSize
>);
> 
>  /**
> @@ -287,7 +289,6 @@ RunTftp (
>CHAR8   *AsciiRemoteFilePath;
>UINTN   FilePathSize;
>CONST CHAR16*Walker;
> -  CONST CHAR16*LocalFilePath;
>EFI_MTFTP4_CONFIG_DATA  Mtftp4ConfigData;
>EFI_HANDLE  *Handles;
>UINTN   HandleCount;
> @@ -297,9 +298,7 @@ RunTftp (
>EFI_HANDLE  Mtftp4ChildHandle;
>EFI_MTFTP4_PROTOCOL *Mtftp4;
>UINTN   FileSize;
> -  UINTN   DataSize;
>VOID*Data;
> -  SHELL_FILE_HANDLE   FileHandle;
>UINT16  BlockSize;
>UINT16  WindowSize;
> 
> @@ -309,7 +308,6 @@ RunTftp (
>AsciiRemoteFilePath = NULL;
>Handles = NULL;
>FileSize= 0;
> -  DataSize= 0;
>BlockSize   = MTFTP_DEFAULT_BLKSIZE;
>WindowSize  = MTFTP_DEFAULT_WINDOWSIZE;
> 
> @@ -385,7 +383,7 @@ RunTftp (
>UnicodeStrToAsciiStrS (RemoteFilePath, AsciiRemoteFilePath, FilePathSize);
> 
>if (ParamCount == 4) {
> -LocalFilePath = ShellCommandLineGetRawValue (CheckPackage, 3);
> +mLocalFilePath = ShellCommandLineGetRawValue (CheckPackage, 3);
>} else {
>  Walker = RemoteFilePath + StrLen (RemoteFilePath);
>  while ((--Walker) >= RemoteFilePath) {
> @@ -394,7 +392,7 @@ RunTftp (
>  break;
>}
>  }
> -LocalFilePath = Walker + 1;
> +mLocalFilePath = Walker + 1;
>}
> 
>//
> @@ -543,7 +541,7 @@ RunTftp (
>goto NextHandle;
>  }
> 
> -Status = DownloadFile (Mtftp4, RemoteFilePath, AsciiRemoteFilePath,
> FileSize, BlockSize, WindowSize, );
> +Status = DownloadFile (Mtftp4, RemoteFilePath, AsciiRemoteFilePath,
> FileSize, BlockSize, WindowSize);
>  if (EFI_ERROR (Status)) {
>ShellPrintHiiEx (
>  -1, -1, NULL, STRING_TOKEN (STR_TFTP_ERR_DOWNLOAD),
> @@ -552,45 +550,8 @@ RunTftp (
>goto NextHandle;
>  }
> 
> -DataSize = FileSize;
> -
> -if (!EFI_ERROR (ShellFileExists 

Re: [edk2] [PATCH v4 0/2] Provide UEFILib functions for protocol uninstallation

[Ashish Singhal]

Thanks Mike. Hope to see the patches merged soon. Please let me know if you 
want me to file the BZ.

Hi Liming,

Please let me know if you need me to take care of anything in the patch before 
you push it.

Hi Siyuan/Jiaxin,

I think you reviewed the changes in PATCH v2 which is same as in PATCH v4. 
Please let me know if you have any issues with this going in.

Thanks
Ashish

-Original Message-
From: Kinney, Michael D  
Sent: Wednesday, January 9, 2019 5:56 PM
To: Ashish Singhal ; edk2-devel@lists.01.org; Kinney, 
Michael D 
Cc: Gao, Liming ; Fu, Siyuan ; Wu, 
Jiaxin 
Subject: RE: [PATCH v4 0/2] Provide UEFILib functions for protocol 
uninstallation

Hi Ashish,

This V4 version of the patch produces the expected size results for platform 
and driver builds.

There are some very minor issues with some extra carriage returns, but those 
can be handled by Liming when the patch series is committed.

I may be good to have an additional BZ to use these new APIs from all UEFI 
Driver Model drivers that have failure paths in their entry point or support 
the unload feature.
Those updates can be done later.

Thanks,

Mike

> -Original Message-
> From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> Sent: Wednesday, January 9, 2019 12:59 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Gao, Liming 
> ; Fu, Siyuan ; Wu, Jiaxin 
> ; Ashish Singhal 
> Subject: [PATCH v4 0/2] Provide UEFILib functions for protocol 
> uninstallation
> 
> An issue was seen in IScsiDxe in NetworkPkg where driver cleanup after 
> initialization failure was not done right. Bug 1428 was filed in this 
> regard.
> As per discussions with Mike, it was also discussed that having 
> UEFILib provide protocol uninstallation abstraction would help to 
> avoid these issues in the future. Bug 1429 was found to track this.
> These 2 patches
> take care of this.
> 
> 
> Ashish Singhal (2):
>   MdePkg/UefiLib: Abstract driver model protocol uninstallation
>   NetworkPkg/IScsiDxe: Use UEFILib APIs to uninstall protocols.
> 
>  MdePkg/Include/Library/UefiLib.h | 103 
>  MdePkg/Library/UefiLib/UefiDriverModel.c | 972
> ++-
>  NetworkPkg/IScsiDxe/IScsiDriver.c|  31 +-
>  3 files changed, 1085 insertions(+), 21 deletions(-)
> 
> --
> 2.7.4

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v4 0/2] Provide UEFILib functions for protocol uninstallation

[Kinney, Michael D]

Hi Ashish,

This V4 version of the patch produces the expected size 
results for platform and driver builds.

There are some very minor issues with some extra carriage
returns, but those can be handled by Liming when the patch
series is committed.

I may be good to have an additional BZ to use these new
APIs from all UEFI Driver Model drivers that have failure
paths in their entry point or support the unload feature.
Those updates can be done later.

Thanks,

Mike

> -Original Message-
> From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> Sent: Wednesday, January 9, 2019 12:59 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Gao,
> Liming ; Fu, Siyuan
> ; Wu, Jiaxin ;
> Ashish Singhal 
> Subject: [PATCH v4 0/2] Provide UEFILib functions for
> protocol uninstallation
> 
> An issue was seen in IScsiDxe in NetworkPkg where driver
> cleanup after
> initialization failure was not done right. Bug 1428 was
> filed in this regard.
> As per discussions with Mike, it was also discussed that
> having UEFILib
> provide protocol uninstallation abstraction would help
> to avoid these
> issues in the future. Bug 1429 was found to track this.
> These 2 patches
> take care of this.
> 
> 
> Ashish Singhal (2):
>   MdePkg/UefiLib: Abstract driver model protocol
> uninstallation
>   NetworkPkg/IScsiDxe: Use UEFILib APIs to uninstall
> protocols.
> 
>  MdePkg/Include/Library/UefiLib.h | 103 
>  MdePkg/Library/UefiLib/UefiDriverModel.c | 972
> ++-
>  NetworkPkg/IScsiDxe/IScsiDriver.c|  31 +-
>  3 files changed, 1085 insertions(+), 21 deletions(-)
> 
> --
> 2.7.4

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

Re: [edk2] [v2 1/1] BaseTools: fix imports

[Feng, Bob C]

Reviewed-by: Bob Feng  

-Original Message-
From: Carsey, Jaben 
Sent: Thursday, January 10, 2019 3:01 AM
To: edk2-devel@lists.01.org
Cc: Feng, Bob C ; Gao, Liming 
Subject: [v2 1/1] BaseTools: fix imports

1 - Some of these imports are cascaded from another file. Import them locally.
2 - Some of these imports are not used. Remove them.
3 - Some of these were missing the namespace used to import them.

These changes facilitate optimization of BaseTools:
https://bugzilla.tianocore.org/show_bug.cgi?id=42

Cc: Bob Feng 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jaben Carsey 
---
 BaseTools/Source/Python/AutoGen/AutoGen.py  |  6 ++
 BaseTools/Source/Python/AutoGen/GenC.py |  2 +-
 BaseTools/Source/Python/AutoGen/GenPcdDb.py |  3 +++
 BaseTools/Source/Python/Common/RangeExpression.py   |  3 ++-
 BaseTools/Source/Python/Common/ToolDefClassObject.py|  4 ++--
 BaseTools/Source/Python/Ecc/MetaFileWorkspace/MetaFileParser.py |  4 ++--
 BaseTools/Source/Python/GenFds/FdfParser.py |  4 ++--
 BaseTools/Source/Python/GenFds/FfsInfStatement.py   |  3 ++-
 BaseTools/Source/Python/GenFds/GenFds.py|  2 +-
 BaseTools/Source/Python/GenFds/GuidSection.py   |  1 -
 BaseTools/Source/Python/Workspace/DecBuildData.py   |  9 ++---
 BaseTools/Source/Python/Workspace/DscBuildData.py   |  4 ++--
 BaseTools/Source/Python/Workspace/MetaFileParser.py |  9 +
 BaseTools/Source/Python/build/build.py  | 16 

 14 files changed, 38 insertions(+), 32 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py 
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index d646cd50ce8e..acd34692b6c2 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -1,7 +1,7 @@
 ## @file
 # Generate AutoGen.h, AutoGen.c and *.depex files  # -# Copyright (c) 2007 - 
2018, Intel Corporation. All rights reserved.
+# Copyright (c) 2007 - 2019, Intel Corporation. All rights 
+reserved.
 # Copyright (c) 2018, Hewlett Packard Enterprise Development, L.P.  #  # 
This program and the accompanying materials @@ -52,6 +52,7 @@ from .GenVar 
import VariableMgr, var_info  from collections import OrderedDict  from 
collections import defaultdict  from Workspace.WorkspaceCommon import 
OrderedListDict
+from Common.ToolDefClassObject import gDefaultToolsDefFile
 
 from Common.caching import cached_property, cached_class_function
 
@@ -85,9 +86,6 @@ gMakeTypeMap = {TAB_COMPILER_MSFT:"nmake", "GCC":"gmake"}  ## 
Build rule configuration file  gDefaultBuildRuleFile = 'build_rule.txt'
 
-## Tools definition configuration file
-gDefaultToolsDefFile = 'tools_def.txt'
-
 ## Build rule default version
 AutoGenReqBuildRuleVerNum = "0.1"
 
diff --git a/BaseTools/Source/Python/AutoGen/GenC.py 
b/BaseTools/Source/Python/AutoGen/GenC.py
index 09626d0b9610..e224568db1ed 100644
--- a/BaseTools/Source/Python/AutoGen/GenC.py
+++ b/BaseTools/Source/Python/AutoGen/GenC.py
@@ -18,7 +18,7 @@ import string
 import collections
 import struct
 from Common import EdkLogger
-
+from Common import GlobalData
 from Common.BuildToolError import *
 from Common.DataType import *
 from Common.Misc import *
diff --git a/BaseTools/Source/Python/AutoGen/GenPcdDb.py 
b/BaseTools/Source/Python/AutoGen/GenPcdDb.py
index 876fcf1efb8a..a9068d2d7a86 100644
--- a/BaseTools/Source/Python/AutoGen/GenPcdDb.py
+++ b/BaseTools/Source/Python/AutoGen/GenPcdDb.py
@@ -22,6 +22,9 @@ from Common.VariableAttributes import VariableAttributes  
import copy  from struct import unpack  from Common.DataType import *
+from Common import GlobalData
+from Common import EdkLogger
+import Common.LongFilePathOs as os
 
 DATABASE_VERSION = 7
 
diff --git a/BaseTools/Source/Python/Common/RangeExpression.py 
b/BaseTools/Source/Python/Common/RangeExpression.py
index 407dc06ccf0b..40958451d286 100644
--- a/BaseTools/Source/Python/Common/RangeExpression.py
+++ b/BaseTools/Source/Python/Common/RangeExpression.py
@@ -19,6 +19,7 @@ from CommonDataClass.Exceptions import WrnExpression  import 
uuid  from Common.Expression import PcdPattern, BaseExpression  from 
Common.DataType import *
+from re import compile
 
 ERR_STRING_EXPR = 'This operator cannot be used in string expression: [%s].'
 ERR_SNYTAX = 'Syntax error, the rest of expression cannot be evaluated: [%s].'
@@ -202,7 +203,7 @@ class RangeExpression(BaseExpression):
 
 NonLetterOpLst = ['+', '-', '&', '|', '^', '!', '=', '>', '<']
 
-RangePattern = re.compile(r'[0-9]+ - [0-9]+')
+RangePattern = compile(r'[0-9]+ - [0-9]+')
 
 def preProcessRangeExpr(self, expr):
 # convert hex to int
diff --git a/BaseTools/Source/Python/Common/ToolDefClassObject.py 
b/BaseTools/Source/Python/Common/ToolDefClassObject.py
index 

Re: [edk2] [PATCH] Maintainers.txt: Update mail address

[Gao, Liming]

Reviewed-by: Liming Gao 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
> Ersek
> Sent: Wednesday, January 9, 2019 11:19 PM
> To: Ni, Ray ; edk2-devel@lists.01.org
> Cc: Gao, Liming 
> Subject: Re: [edk2] [PATCH] Maintainers.txt: Update mail address
> 
> On 01/09/19 10:59, Ruiyu Ni wrote:
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ray Ni 
> > Cc: Liming Gao 
> > ---
> >  Maintainers.txt | 20 ++--
> >  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> And I'll update my address book in Thunderbird :)
> 
> > diff --git a/Maintainers.txt b/Maintainers.txt
> > index 7f2f9de79f..3b2676bc32 100644
> > --- a/Maintainers.txt
> > +++ b/Maintainers.txt
> > @@ -124,12 +124,12 @@ EmulatorPkg
> >  W: https://github.com/tianocore/tianocore.github.io/wiki/EmulatorPkg
> >  M: Jordan Justen 
> >  M: Andrew Fish 
> > -M: Ruiyu Ni 
> > +M: Ray Ni 
> >  S: Maintained
> >
> >  FatPkg
> >  W: https://github.com/tianocore/tianocore.github.io/wiki/Edk2-fat-driver
> > -M: Ruiyu Ni 
> > +M: Ray Ni 
> >  T: svn - https://svn.code.sf.net/p/edk2-fatdriver2/code/trunk/EnhancedFat
> >  T: git - https://github.com/tianocore/edk2-FatPkg.git
> >
> > @@ -173,7 +173,7 @@ R: Star Zeng 
> >
> >  IntelSiliconPkg
> >  W: https://github.com/tianocore/tianocore.github.io/wiki/IntelSiliconPkg
> > -M: Ruiyu Ni 
> > +M: Ray Ni 
> >  M: Rangasai V Chaganty 
> >
> >  MdeModulePkg
> > @@ -182,7 +182,7 @@ M: Jian J Wang 
> >  M: Hao Wu 
> >  M: NetworkPkg maintainers
> >(Universal/Network and related libraries, header files)
> > -R: Ruiyu Ni 
> > +R: Ray Ni 
> >(especially for Bus, Universal/Console, Universal/Disk,
> > Universal/BdsDxe and related libraries, header files)
> >  R: Star Zeng 
> > @@ -199,7 +199,7 @@ M: Jiaxin Wu 
> >
> >  Nt32Pkg
> >  W: https://github.com/tianocore/tianocore.github.io/wiki/Nt32Pkg
> > -M: Ruiyu Ni 
> > +M: Ray Ni 
> >  M: Hao Wu 
> >
> >  Omap35xxPkg
> > @@ -209,7 +209,7 @@ M: Ard Biesheuvel 
> >
> >  OptionRomPkg
> >  W: https://github.com/tianocore/tianocore.github.io/wiki/OptionRomPkg
> > -M: Ruiyu Ni 
> > +M: Ray Ni 
> >
> >  OvmfPkg
> >  W: http://www.tianocore.org/ovmf/
> > @@ -222,7 +222,7 @@ S: Maintained
> >
> >  PcAtChipsetPkg
> >  W: https://github.com/tianocore/tianocore.github.io/wiki/PcAtChipsetPkg
> > -M: Ruiyu Ni 
> > +M: Ray Ni 
> >
> >  QuarkPlatformPkg, QuarkSocPkg
> >  M: Michael D Kinney 
> > @@ -236,14 +236,14 @@ M: Jiewen Yao 
> >  ShellBinPkg
> >  W: https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg
> >  M: Jaben Carsey   (Ia32/X64)
> > -M: Ruiyu Ni   (Ia32/X64)
> > +M: Ray Ni   (Ia32/X64)
> >  M: Leif Lindholm(ARM/AArch64)
> >  M: Ard Biesheuvel  (ARM/AArch64)
> >
> >  ShellPkg
> >  W: https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg
> >  M: Jaben Carsey 
> > -M: Ruiyu Ni 
> > +M: Ray Ni 
> >
> >  SignedCapsulePkg
> >  W: https://github.com/tianocore/tianocore.github.io/wiki/SignedCapsulePkg
> > @@ -262,7 +262,7 @@ M: Jaben Carsey 
> >  UefiCpuPkg
> >  W: https://github.com/tianocore/tianocore.github.io/wiki/UefiCpuPkg
> >  M: Eric Dong 
> > -M: Ruiyu Ni 
> > +M: Ray Ni 
> >  R: Laszlo Ersek 
> >
> >  Vlv2DeviceRefCodePkg
> >
> 
> Ugh, don't you have a bit too much on your plate? Co-maintaining 9
> packages, and being a reviewer for another one. That can't be easy!
> 
> (Side topic: here's a list of maintainers/reviewers (lumped together)
> with responsibility for more than one "area" (not just package), ordered
> descending by area count:
> 
> $ grep '^[MR]: ' Maintainers.txt \
> | cut -c 4- \
> | sort \
> | uniq -c \
> | sort -rn
> 
>   9 Ruiyu Ni 
>   7 Liming Gao 
>   7 Ard Biesheuvel 
>   6 Leif Lindholm 
>   5 Star Zeng 
>   5 Michael D Kinney 
>   4 Nate DeSimone 
>   4 Laszlo Ersek 
>   4 Chasel Chiu 
>   3 Jiewen Yao 
>   3 Jaben Carsey 
>   3 Hao Wu 
>   2 Zailiang Sun 
>   2 Yi Qian 
>   2 Julien Grall 
>   2 Jordan Justen 
>   2 Daryl McDaniel 
>   2 Chao Zhang 
>   2 Andrew Fish 
> )
> 
> Anyway it looks like all occurrences in the text file are covered.
> 
> Reviewed-by: Laszlo Ersek 
> 
> Thanks,
> Laszlo
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/6] implement standalone MM versions of the variable runtime drivers

[Ard Biesheuvel]

On Wed, 9 Jan 2019 at 22:46, Laszlo Ersek  wrote:
>
> On 01/09/19 16:04, Laszlo Ersek wrote:
> > On 01/09/19 11:28, Ard Biesheuvel wrote:
> >> In the mean time, the hunk below should suffice to complete your
> >> regression testing.
>
> I used:
>
> > diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> > index 3f3533e5c163..908450eda174 100644
> > --- a/OvmfPkg/OvmfPkgIa32.dsc
> > +++ b/OvmfPkg/OvmfPkgIa32.dsc
> > @@ -386,6 +386,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
> >HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
> >SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
> >
> > SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
> > +  
> > MmServicesTableLib|MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
> >  !ifdef $(DEBUG_ON_SERIAL_PORT)
> >DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
> >  !else
> > diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> > index 6c08b2728d63..14166e946a93 100644
> > --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> > +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> > @@ -391,6 +391,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
> >HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
> >SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
> >
> > SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
> > +  
> > MmServicesTableLib|MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
> >  !ifdef $(DEBUG_ON_SERIAL_PORT)
> >DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
> >  !else
> > diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> > index 4072c839d73f..0cd5f76cccd9 100644
> > --- a/OvmfPkg/OvmfPkgX64.dsc
> > +++ b/OvmfPkg/OvmfPkgX64.dsc
> > @@ -391,6 +391,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
> >HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
> >SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
> >
> > SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
> > +  
> > MmServicesTableLib|MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
> >  !ifdef $(DEBUG_ON_SERIAL_PORT)
> >DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
> >  !else
>
> On 01/09/19 16:04, Laszlo Ersek wrote:
> > I'll be back with test results later.
>
> Regression-tested-by: Laszlo Ersek 
>

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

Re: [edk2] [PATCH 0/6] implement standalone MM versions of the variable runtime drivers

[Laszlo Ersek]

On 01/09/19 16:04, Laszlo Ersek wrote:
> On 01/09/19 11:28, Ard Biesheuvel wrote:
>> In the mean time, the hunk below should suffice to complete your
>> regression testing.

I used:

> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index 3f3533e5c163..908450eda174 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -386,6 +386,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
>HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
>SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
>
> SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
> +  MmServicesTableLib|MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
>  !ifdef $(DEBUG_ON_SERIAL_PORT)
>DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
>  !else
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 6c08b2728d63..14166e946a93 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -391,6 +391,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
>HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
>SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
>
> SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
> +  MmServicesTableLib|MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
>  !ifdef $(DEBUG_ON_SERIAL_PORT)
>DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
>  !else
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 4072c839d73f..0cd5f76cccd9 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -391,6 +391,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
>HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
>SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
>
> SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
> +  MmServicesTableLib|MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
>  !ifdef $(DEBUG_ON_SERIAL_PORT)
>DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
>  !else

On 01/09/19 16:04, Laszlo Ersek wrote:
> I'll be back with test results later.

Regression-tested-by: Laszlo Ersek 

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

[edk2] [PATCH v4 1/2] MdePkg/UefiLib: Abstract driver model protocol uninstallation

[Ashish Singhal]

Provided functions in UEFILib that abstract driver model protocol
uninstallation. This helps drivers to install and uninstall protocols
using a library to keep things seemless.

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

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ashish Singhal 
---
 MdePkg/Include/Library/UefiLib.h | 103 
 MdePkg/Library/UefiLib/UefiDriverModel.c | 972 ++-
 2 files changed, 1074 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/Library/UefiLib.h b/MdePkg/Include/Library/UefiLib.h
index 468bffc..08222d4 100644
--- a/MdePkg/Include/Library/UefiLib.h
+++ b/MdePkg/Include/Library/UefiLib.h
@@ -12,6 +12,7 @@
   of size reduction when compiler optimization is disabled. If MDEPKG_NDEBUG is
   defined, then debug and assert related macros wrapped by it are the NULL 
implementations.
 
+Copyright (c) 2019, NVIDIA Corporation. All rights reserved.
 Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
 This program and the accompanying materials are licensed and made available 
under
 the terms and conditions of the BSD License that accompanies this distribution.
@@ -1283,6 +1284,7 @@ AsciiPrintXY (
   ...
   );
 
+
 /**
   Installs and completes the initialization of a Driver Binding Protocol 
instance.
 
@@ -1316,6 +1318,25 @@ EfiLibInstallDriverBinding (
 
 
 /**
+  Uninstalls a Driver Binding Protocol instance.
+
+  If DriverBinding is NULL, then ASSERT().
+  If DriverBinding can not be uninstalled, then ASSERT().
+
+  @param  DriverBindingA Driver Binding Protocol instance that this 
driver produced.
+
+  @retval EFI_SUCCESS   The protocol uninstallation successfully 
completed.
+  @retval OthersStatus from 
gBS->UninstallMultipleProtocolInterfaces().
+
+**/
+EFI_STATUS
+EFIAPI
+EfiLibUninstallDriverBinding (
+  IN EFI_DRIVER_BINDING_PROTOCOL  *DriverBinding
+  );
+
+
+/**
   Installs and completes the initialization of a Driver Binding Protocol 
instance and
   optionally installs the Component Name, Driver Configuration and Driver 
Diagnostics Protocols.
 
@@ -1354,6 +1375,31 @@ EfiLibInstallAllDriverProtocols (
   );
 
 
+/**
+  Uninstalls a Driver Binding Protocol instance and optionally uninstalls the
+  Component Name, Driver Configuration and Driver Diagnostics Protocols.
+
+  If DriverBinding is NULL, then ASSERT().
+  If the uninstallation fails, then ASSERT().
+
+  @param  DriverBindingA Driver Binding Protocol instance that this 
driver produced.
+  @param  ComponentNameA Component Name Protocol instance that this 
driver produced.
+  @param  DriverConfiguration  A Driver Configuration Protocol instance that 
this driver produced.
+  @param  DriverDiagnosticsA Driver Diagnostics Protocol instance that 
this driver produced.
+
+  @retval EFI_SUCCESS   The protocol uninstallation successfully 
completed.
+  @retval OthersStatus from 
gBS->UninstallMultipleProtocolInterfaces().
+
+**/
+EFI_STATUS
+EFIAPI
+EfiLibUninstallAllDriverProtocols (
+  IN EFI_DRIVER_BINDING_PROTOCOL  *DriverBinding,
+  IN CONST EFI_COMPONENT_NAME_PROTOCOL*ComponentName,   OPTIONAL
+  IN CONST EFI_DRIVER_CONFIGURATION_PROTOCOL  *DriverConfiguration, OPTIONAL
+  IN CONST EFI_DRIVER_DIAGNOSTICS_PROTOCOL*DriverDiagnosticsOPTIONAL
+  );
+
 
 /**
   Installs Driver Binding Protocol with optional Component Name and Component 
Name 2 Protocols.
@@ -1391,6 +1437,29 @@ EfiLibInstallDriverBindingComponentName2 (
 
 
 /**
+  Uninstalls Driver Binding Protocol with optional Component Name and 
Component Name 2 Protocols.
+
+  If DriverBinding is NULL, then ASSERT().
+  If the uninstallation fails, then ASSERT().
+
+  @param  DriverBindingA Driver Binding Protocol instance that this 
driver produced.
+  @param  ComponentNameA Component Name Protocol instance that this 
driver produced.
+  @param  ComponentName2   A Component Name 2 Protocol instance that this 
driver produced.
+
+  @retval EFI_SUCCESS   The protocol installation successfully 
completed.
+  @retval OthersStatus from 
gBS->UninstallMultipleProtocolInterfaces().
+
+**/
+EFI_STATUS
+EFIAPI
+EfiLibUninstallDriverBindingComponentName2 (
+  IN EFI_DRIVER_BINDING_PROTOCOL  *DriverBinding,
+  IN CONST EFI_COMPONENT_NAME_PROTOCOL*ComponentName,   OPTIONAL
+  IN CONST EFI_COMPONENT_NAME2_PROTOCOL   *ComponentName2   OPTIONAL
+  );
+
+
+/**
   Installs Driver Binding Protocol with optional Component Name, Component 
Name 2, Driver
   Configuration, Driver Configuration 2, Driver Diagnostics, and Driver 
Diagnostics 2 Protocols.
 
@@ -1434,6 +1503,40 @@ EfiLibInstallAllDriverProtocols2 (
   IN CONST EFI_DRIVER_DIAGNOSTICS2_PROTOCOL   *DriverDiagnostics2OPTIONAL
   );
 
+
+/**
+  Uninstalls Driver Binding Protocol with optional Component Name, Component 
Name 2, Driver
+  

[edk2] [PATCH v4 2/2] NetworkPkg/IScsiDxe: Use UEFILib APIs to uninstall protocols.

[Ashish Singhal]

During cleanup in case of initialization failure, some driver
bindings are not installed. Using abstractions in UEFILib takes
care of it.

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

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ashish Singhal 
---
 NetworkPkg/IScsiDxe/IScsiDriver.c | 31 +++
 1 file changed, 11 insertions(+), 20 deletions(-)

diff --git a/NetworkPkg/IScsiDxe/IScsiDriver.c 
b/NetworkPkg/IScsiDxe/IScsiDriver.c
index 91176e6..8747de7 100644
--- a/NetworkPkg/IScsiDxe/IScsiDriver.c
+++ b/NetworkPkg/IScsiDxe/IScsiDriver.c
@@ -1,6 +1,7 @@
 /** @file
   The entry point of IScsi driver.
 
+Copyright (c) 2019, NVIDIA Corporation. All rights reserved.
 Copyright (c) 2004 - 2018, Intel Corporation. All rights reserved.
 (C) Copyright 2017 Hewlett Packard Enterprise Development LP
 
@@ -1861,28 +1862,18 @@ Error3:
  );
 
 Error2:
-  gBS->UninstallMultipleProtocolInterfaces (
- gIScsiIp6DriverBinding.DriverBindingHandle,
- ,
- ,
- ,
- ,
- ,
- ,
- NULL
- );
+  EfiLibUninstallDriverBindingComponentName2 (
+,
+,
+
+);
 
 Error1:
-  gBS->UninstallMultipleProtocolInterfaces (
- ImageHandle,
- ,
- ,
- ,
- ,
- ,
- ,
- NULL
- );
+  EfiLibUninstallDriverBindingComponentName2 (
+,
+,
+
+);
 
   return Status;
 }
-- 
2.7.4

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

[edk2] [PATCH v4 0/2] Provide UEFILib functions for protocol uninstallation

[Ashish Singhal]

An issue was seen in IScsiDxe in NetworkPkg where driver cleanup after
initialization failure was not done right. Bug 1428 was filed in this regard.
As per discussions with Mike, it was also discussed that having UEFILib
provide protocol uninstallation abstraction would help to avoid these
issues in the future. Bug 1429 was found to track this. These 2 patches
take care of this.


Ashish Singhal (2):
  MdePkg/UefiLib: Abstract driver model protocol uninstallation
  NetworkPkg/IScsiDxe: Use UEFILib APIs to uninstall protocols.

 MdePkg/Include/Library/UefiLib.h | 103 
 MdePkg/Library/UefiLib/UefiDriverModel.c | 972 ++-
 NetworkPkg/IScsiDxe/IScsiDriver.c|  31 +-
 3 files changed, 1085 insertions(+), 21 deletions(-)

-- 
2.7.4

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

[edk2] [v2 1/1] BaseTools: fix imports

[Jaben Carsey]

1 - Some of these imports are cascaded from another file. Import them locally.
2 - Some of these imports are not used. Remove them.
3 - Some of these were missing the namespace used to import them.

These changes facilitate optimization of BaseTools:
https://bugzilla.tianocore.org/show_bug.cgi?id=42

Cc: Bob Feng 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jaben Carsey 
---
 BaseTools/Source/Python/AutoGen/AutoGen.py  |  6 ++
 BaseTools/Source/Python/AutoGen/GenC.py |  2 +-
 BaseTools/Source/Python/AutoGen/GenPcdDb.py |  3 +++
 BaseTools/Source/Python/Common/RangeExpression.py   |  3 ++-
 BaseTools/Source/Python/Common/ToolDefClassObject.py|  4 ++--
 BaseTools/Source/Python/Ecc/MetaFileWorkspace/MetaFileParser.py |  4 ++--
 BaseTools/Source/Python/GenFds/FdfParser.py |  4 ++--
 BaseTools/Source/Python/GenFds/FfsInfStatement.py   |  3 ++-
 BaseTools/Source/Python/GenFds/GenFds.py|  2 +-
 BaseTools/Source/Python/GenFds/GuidSection.py   |  1 -
 BaseTools/Source/Python/Workspace/DecBuildData.py   |  9 ++---
 BaseTools/Source/Python/Workspace/DscBuildData.py   |  4 ++--
 BaseTools/Source/Python/Workspace/MetaFileParser.py |  9 +
 BaseTools/Source/Python/build/build.py  | 16 

 14 files changed, 38 insertions(+), 32 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py 
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index d646cd50ce8e..acd34692b6c2 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -1,7 +1,7 @@
 ## @file
 # Generate AutoGen.h, AutoGen.c and *.depex files
 #
-# Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
+# Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.
 # Copyright (c) 2018, Hewlett Packard Enterprise Development, L.P.
 #
 # This program and the accompanying materials
@@ -52,6 +52,7 @@ from .GenVar import VariableMgr, var_info
 from collections import OrderedDict
 from collections import defaultdict
 from Workspace.WorkspaceCommon import OrderedListDict
+from Common.ToolDefClassObject import gDefaultToolsDefFile
 
 from Common.caching import cached_property, cached_class_function
 
@@ -85,9 +86,6 @@ gMakeTypeMap = {TAB_COMPILER_MSFT:"nmake", "GCC":"gmake"}
 ## Build rule configuration file
 gDefaultBuildRuleFile = 'build_rule.txt'
 
-## Tools definition configuration file
-gDefaultToolsDefFile = 'tools_def.txt'
-
 ## Build rule default version
 AutoGenReqBuildRuleVerNum = "0.1"
 
diff --git a/BaseTools/Source/Python/AutoGen/GenC.py 
b/BaseTools/Source/Python/AutoGen/GenC.py
index 09626d0b9610..e224568db1ed 100644
--- a/BaseTools/Source/Python/AutoGen/GenC.py
+++ b/BaseTools/Source/Python/AutoGen/GenC.py
@@ -18,7 +18,7 @@ import string
 import collections
 import struct
 from Common import EdkLogger
-
+from Common import GlobalData
 from Common.BuildToolError import *
 from Common.DataType import *
 from Common.Misc import *
diff --git a/BaseTools/Source/Python/AutoGen/GenPcdDb.py 
b/BaseTools/Source/Python/AutoGen/GenPcdDb.py
index 876fcf1efb8a..a9068d2d7a86 100644
--- a/BaseTools/Source/Python/AutoGen/GenPcdDb.py
+++ b/BaseTools/Source/Python/AutoGen/GenPcdDb.py
@@ -22,6 +22,9 @@ from Common.VariableAttributes import VariableAttributes
 import copy
 from struct import unpack
 from Common.DataType import *
+from Common import GlobalData
+from Common import EdkLogger
+import Common.LongFilePathOs as os
 
 DATABASE_VERSION = 7
 
diff --git a/BaseTools/Source/Python/Common/RangeExpression.py 
b/BaseTools/Source/Python/Common/RangeExpression.py
index 407dc06ccf0b..40958451d286 100644
--- a/BaseTools/Source/Python/Common/RangeExpression.py
+++ b/BaseTools/Source/Python/Common/RangeExpression.py
@@ -19,6 +19,7 @@ from CommonDataClass.Exceptions import WrnExpression
 import uuid
 from Common.Expression import PcdPattern, BaseExpression
 from Common.DataType import *
+from re import compile
 
 ERR_STRING_EXPR = 'This operator cannot be used in string expression: [%s].'
 ERR_SNYTAX = 'Syntax error, the rest of expression cannot be evaluated: [%s].'
@@ -202,7 +203,7 @@ class RangeExpression(BaseExpression):
 
 NonLetterOpLst = ['+', '-', '&', '|', '^', '!', '=', '>', '<']
 
-RangePattern = re.compile(r'[0-9]+ - [0-9]+')
+RangePattern = compile(r'[0-9]+ - [0-9]+')
 
 def preProcessRangeExpr(self, expr):
 # convert hex to int
diff --git a/BaseTools/Source/Python/Common/ToolDefClassObject.py 
b/BaseTools/Source/Python/Common/ToolDefClassObject.py
index 186d279840c1..0a78123e2c4b 100644
--- a/BaseTools/Source/Python/Common/ToolDefClassObject.py
+++ b/BaseTools/Source/Python/Common/ToolDefClassObject.py
@@ -1,7 +1,7 @@
 ## @file
 # This file is used to define each component of 

Re: [edk2] [Patch 1/3 V2] BaseTools: Remove unused logic for EDKI

[Carsey, Jaben]

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: Feng, Bob C
> Sent: Tuesday, January 08, 2019 11:15 PM
> To: edk2-devel@lists.01.org
> Cc: Feng, Bob C ; Gao, Liming
> ; Carsey, Jaben 
> Subject: [Patch 1/3 V2] BaseTools: Remove unused logic for EDKI
> Importance: High
> 
> From: "Feng, Bob C" 
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1350
> Remove EDK module type support from BaseTools python code.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Bob Feng 
> Cc: Liming Gao 
> Cc: Jaben Carsey 
> ---
>  BaseTools/Source/Python/AutoGen/AutoGen.py|  93 ++---
>  BaseTools/Source/Python/AutoGen/GenC.py   |  90 -
>  BaseTools/Source/Python/AutoGen/GenMake.py|  18 +-
>  BaseTools/Source/Python/Common/DataType.py|   2 -
>  BaseTools/Source/Python/Common/GlobalData.py  |   6 -
>  .../Source/Python/Workspace/DecBuildData.py   |   1 -
>  .../Source/Python/Workspace/DscBuildData.py   |   3 -
>  .../Source/Python/Workspace/InfBuildData.py   | 191 +-
>  .../Source/Python/Workspace/MetaFileParser.py |  22 --
>  .../Python/Workspace/WorkspaceCommon.py   |  29 +--
>  BaseTools/Source/Python/build/BuildReport.py  |  54 ++---
>  BaseTools/Source/Python/build/build.py|  65 --
>  edksetup.bat  |   3 -
>  13 files changed, 116 insertions(+), 461 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py
> b/BaseTools/Source/Python/AutoGen/AutoGen.py
> index d646cd50ce..d3d0d96e71 100644
> --- a/BaseTools/Source/Python/AutoGen/AutoGen.py
> +++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
> @@ -2174,46 +2174,11 @@ class PlatformAutoGen(AutoGen):
>  Pcd.MaxDatumSize = str(len(Value.split(',')))
>  else:
>  Pcd.MaxDatumSize = str(len(Value) - 1)
>  return Pcds.values()
> 
> -## Resolve library names to library modules
> -#
> -# (for Edk.x modules)
> -#
> -#   @param  Module  The module from which the library names will be
> resolved
> -#
> -#   @retval library_listThe list of library modules
> -#
> -def ResolveLibraryReference(self, Module):
> -EdkLogger.verbose("")
> -EdkLogger.verbose("Library instances of module [%s] [%s]:" %
> (str(Module), self.Arch))
> -LibraryConsumerList = [Module]
> -
> -# "CompilerStub" is a must for Edk modules
> -if Module.Libraries:
> -Module.Libraries.append("CompilerStub")
> -LibraryList = []
> -while len(LibraryConsumerList) > 0:
> -M = LibraryConsumerList.pop()
> -for LibraryName in M.Libraries:
> -Library = self.Platform.LibraryClasses[LibraryName, 
> ':dummy:']
> -if Library is None:
> -for Key in self.Platform.LibraryClasses.data:
> -if LibraryName.upper() == Key.upper():
> -Library = self.Platform.LibraryClasses[Key, 
> ':dummy:']
> -break
> -if Library is None:
> -EdkLogger.warn("build", "Library [%s] is not found" %
> LibraryName, File=str(M),
> -ExtraData="\t%s [%s]" % (str(Module), self.Arch))
> -continue
> 
> -if Library not in LibraryList:
> -LibraryList.append(Library)
> -LibraryConsumerList.append(Library)
> -EdkLogger.verbose("\t" + LibraryName + " : " + 
> str(Library) + ' ' +
> str(type(Library)))
> -return LibraryList
> 
>  ## Calculate the priority value of the build option
>  #
>  # @paramKeyBuild option definition contain:
> TARGET_TOOLCHAIN_ARCH_COMMANDTYPE_ATTRIBUTE
>  #
> @@ -2377,16 +2342,12 @@ class PlatformAutoGen(AutoGen):
>  #
>  #   @retval options The options appended with build options in 
> platform
>  #
>  def ApplyBuildOption(self, Module):
>  # Get the different options for the different style module
> -if Module.AutoGenVersion < 0x00010005:
> -PlatformOptions = self.EdkBuildOption
> -ModuleTypeOptions =
> self.Platform.GetBuildOptionsByModuleType(EDK_NAME,
> Module.ModuleType)
> -else:
> -PlatformOptions = self.EdkIIBuildOption
> -ModuleTypeOptions =
> self.Platform.GetBuildOptionsByModuleType(EDKII_NAME,
> Module.ModuleType)
> +PlatformOptions = self.EdkIIBuildOption
> +ModuleTypeOptions =
> self.Platform.GetBuildOptionsByModuleType(EDKII_NAME,
> Module.ModuleType)
>  ModuleTypeOptions = self._ExpandBuildOption(ModuleTypeOptions)
>  ModuleOptions = self._ExpandBuildOption(Module.BuildOptions)
>  if Module in self.Platform.Modules:
>  PlatformModule = self.Platform.Modules[str(Module)]
>  PlatformModuleOptions =
> 

Re: [edk2] [Patch 3/3 V2] BaseTools: Remove unused logic from C tools

[Carsey, Jaben]

Reviewed-by: Jaben Carsey 

Note: in BaseTools/Source/C/EfiRom/EfiRom.h.  it looks like you both delete and 
add EBC.

> -Original Message-
> From: Feng, Bob C
> Sent: Wednesday, January 09, 2019 12:34 AM
> To: edk2-devel@lists.01.org
> Cc: Feng, Bob C ; Gao, Liming
> ; Carsey, Jaben 
> Subject: [Patch 3/3 V2] BaseTools: Remove unused logic from C tools
> Importance: High
> 
> From: "Feng, Bob C" 
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=1350
> Remove IA64 support from BaseTools C code.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Bob Feng 
> Cc: Liming Gao 
> Cc: Jaben Carsey 
> ---
>  BaseTools/Source/C/Common/BasePeCoff.c|  14 +-
>  BaseTools/Source/C/Common/PeCoffLoaderEx.c| 162 +-
>  BaseTools/Source/C/EfiRom/EfiRom.h|   3 +-
>  BaseTools/Source/C/GenFv/GenFvInternalLib.c   |  72 +---
>  BaseTools/Source/C/GenFv/GenFvInternalLib.h   |  10 --
>  BaseTools/Source/C/GenFw/Elf64Convert.c   |   5 -
>  BaseTools/Source/C/GenFw/GenFw.c  |   6 +-
>  BaseTools/Source/C/GenFw/elf_common.h |  85 -
>  .../C/Include/IndustryStandard/PeImage.h  |   3 -
>  BaseTools/Source/C/Makefiles/header.makefile  |   1 -
>  BaseTools/Source/C/VolInfo/VolInfo.c  |   2 +-
>  11 files changed, 10 insertions(+), 353 deletions(-)
> 
> diff --git a/BaseTools/Source/C/Common/BasePeCoff.c
> b/BaseTools/Source/C/Common/BasePeCoff.c
> index 1d89a300de..d5cefbd0b0 100644
> --- a/BaseTools/Source/C/Common/BasePeCoff.c
> +++ b/BaseTools/Source/C/Common/BasePeCoff.c
> @@ -54,17 +54,10 @@ PeCoffLoaderRelocateIa32Image (
>IN OUT CHAR8   *Fixup,
>IN OUT CHAR8   **FixupData,
>IN UINT64  Adjust
>);
> 
> -RETURN_STATUS
> -PeCoffLoaderRelocateIpfImage (
> -  IN UINT16  *Reloc,
> -  IN OUT CHAR8   *Fixup,
> -  IN OUT CHAR8   **FixupData,
> -  IN UINT64  Adjust
> -  );
> 
>  RETURN_STATUS
>  PeCoffLoaderRelocateArmImage (
>IN UINT16  **Reloc,
>IN OUT CHAR8   *Fixup,
> @@ -182,11 +175,10 @@ Returns:
>} else {
>  ImageContext->Machine = TeHdr->Machine;
>}
> 
>if (ImageContext->Machine != EFI_IMAGE_MACHINE_IA32 && \
> -  ImageContext->Machine != EFI_IMAGE_MACHINE_IA64 && \
>ImageContext->Machine != EFI_IMAGE_MACHINE_X64  && \
>ImageContext->Machine != EFI_IMAGE_MACHINE_ARMT && \
>ImageContext->Machine != EFI_IMAGE_MACHINE_EBC  && \
>ImageContext->Machine != EFI_IMAGE_MACHINE_AARCH64) {
>  if (ImageContext->Machine == IMAGE_FILE_MACHINE_ARM) {
> @@ -814,13 +806,10 @@ Returns:
>Status = PeCoffLoaderRelocateIa32Image (Reloc, Fixup, ,
> Adjust);
>break;
>  case EFI_IMAGE_MACHINE_ARMT:
>Status = PeCoffLoaderRelocateArmImage (, Fixup, ,
> Adjust);
>break;
> -case EFI_IMAGE_MACHINE_IA64:
> -  Status = PeCoffLoaderRelocateIpfImage (Reloc, Fixup, ,
> Adjust);
> -  break;
>  default:
>Status = RETURN_UNSUPPORTED;
>break;
>  }
>  if (RETURN_ERROR (Status)) {
> @@ -1317,13 +1306,12 @@ PeCoffLoaderGetPdbPointer (
>// Assume PE32 image with IA32 Machine field.
>//
>Magic = EFI_IMAGE_NT_OPTIONAL_HDR32_MAGIC;
>break;
>  case EFI_IMAGE_MACHINE_X64:
> -case EFI_IMAGE_MACHINE_IPF:
>//
> -  // Assume PE32+ image with X64 or IPF Machine field
> +  // Assume PE32+ image with X64 Machine field
>//
>Magic = EFI_IMAGE_NT_OPTIONAL_HDR64_MAGIC;
>break;
>  default:
>//
> diff --git a/BaseTools/Source/C/Common/PeCoffLoaderEx.c
> b/BaseTools/Source/C/Common/PeCoffLoaderEx.c
> index 2d9a2a8978..fa8c7e3d17 100644
> --- a/BaseTools/Source/C/Common/PeCoffLoaderEx.c
> +++ b/BaseTools/Source/C/Common/PeCoffLoaderEx.c
> @@ -1,7 +1,7 @@
>  /** @file
> -IA32, X64 and IPF Specific relocation fixups
> +IA32 and X64 Specific relocation fixups
> 
>  Copyright (c) 2004 - 2018, Intel Corporation. All rights reserved.
>  Portions Copyright (c) 2011 - 2013, ARM Ltd. All rights reserved.
>  This program and the accompanying materials
>  are licensed and made available under the terms and conditions of the BSD
> License
> @@ -97,170 +97,10 @@ Returns:
>  --*/
>  {
>return RETURN_UNSUPPORTED;
>  }
> 
> -RETURN_STATUS
> -PeCoffLoaderRelocateIpfImage (
> -  IN UINT16  *Reloc,
> -  IN OUT CHAR8   *Fixup,
> -  IN OUT CHAR8   **FixupData,
> -  IN UINT64  Adjust
> -  )
> -/*++
> -
> -Routine Description:
> -
> -  Performs an Itanium-based specific relocation fixup
> -
> -Arguments:
> -
> -  Reloc  - Pointer to the relocation record
> -
> -  Fixup  - Pointer to the address to fix up
> -
> -  FixupData  - Pointer to a buffer to log the fixups
> -
> -  Adjust - The offset to adjust the fixup
> -
> -Returns:
> -
> -  Status code
> -
> ---*/
> -{
> -  UINT64  *F64;
> -  UINT64  FixupVal;
> -
> -  switch ((*Reloc) >> 12) {
> -
> -

Re: [edk2] [Patch 3/3 V2] BaseTools: Remove unused ECP related code from C tools

[Carsey, Jaben]

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: Feng, Bob C
> Sent: Wednesday, January 09, 2019 12:35 AM
> To: edk2-devel@lists.01.org
> Cc: Feng, Bob C ; Gao, Liming
> ; Carsey, Jaben 
> Subject: [Patch 3/3 V2] BaseTools: Remove unused ECP related code from C
> tools
> Importance: High
> 
> From: "Feng, Bob C" 
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=1350
> Remove ECP support from BaseTools C code.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Bob Feng 
> Cc: Liming Gao 
> Cc: Jaben Carsey 
> ---
>  BaseTools/Source/C/Include/IndustryStandard/pci22.h | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/BaseTools/Source/C/Include/IndustryStandard/pci22.h
> b/BaseTools/Source/C/Include/IndustryStandard/pci22.h
> index d7c5f0c858..873ce69094 100644
> --- a/BaseTools/Source/C/Include/IndustryStandard/pci22.h
> +++ b/BaseTools/Source/C/Include/IndustryStandard/pci22.h
> @@ -178,11 +178,10 @@ typedef struct {
>  #define PCI_IF_16850  0x05
>  #define PCI_IF_16950  0x06
>  #define PCI_SUBCLASS_PARALLEL 0x01
>  #define PCI_IF_PARALLEL_PORT  0x00
>  #define PCI_IF_BI_DIR_PARALLEL_PORT   0x01
> -#define PCI_IF_ECP_PARALLEL_PORT  0x02
>  #define PCI_IF_1284_CONTROLLER0x03
>  #define PCI_IF_1284_DEVICE0xFE
>  #define PCI_SUBCLASS_MULTIPORT_SERIAL 0x02
>  #define PCI_SUBCLASS_MODEM0x03
>  #define PCI_IF_GENERIC_MODEM  0x00
> --
> 2.19.1.windows.1

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

Re: [edk2] [RFC] Edk2 BaseTools Python3 Migration Update

[Carsey, Jaben]

Liming,

I think that the user should not need to set PYTHON3_ENABLE at all if they 
manually set PYTHON_COMMAND.

-Jaben


> -Original Message-
> From: Gao, Liming
> Sent: Tuesday, January 08, 2019 4:43 PM
> To: Carsey, Jaben ; Laszlo Ersek
> ; Ni, Ray ; edk2-devel@lists.01.org;
> leif.lindh...@linaro.org; af...@apple.com; Kinney, Michael D
> 
> Subject: RE: [edk2] [RFC] Edk2 BaseTools Python3 Migration Update
> Importance: High
> 
> Jaben:
>   I also think this way. Now, we have two envs PYTHON3_ENABLE and
> PYTHON_COMMAND. The behavior can be combined as the below to
> support this usage. If user wants the specific python interpreter, he only
> needs to set PYTHON_COMMAND env.
> 
> If PYTHON3_ENABLE is set, PYTHON_COMMAND will be set to the found one
> by edk2 scripts based on PYTHON3_ENABLE value.
> If PYTHON3_ENABLE is not set, but PYTHON_COMMAND is set, then
> PYTHON_COMMAND will be used to run python script. No version check
> here.
> If PYTHON3_ENABLE is not set, but PYTHON_COMMAND is not set,
> PYTHON_COMMAND will be set to the high version python installed in OS.
> 
> Thanks
> Liming
> >-Original Message-
> >From: Carsey, Jaben
> >Sent: Wednesday, January 09, 2019 2:06 AM
> >To: Laszlo Ersek ; Gao, Liming
> ;
> >Ni, Ray ; edk2-devel@lists.01.org;
> leif.lindh...@linaro.org;
> >af...@apple.com; Kinney, Michael D 
> >Subject: RE: [edk2] [RFC] Edk2 BaseTools Python3 Migration Update
> >
> >
> >
> >> -Original Message-
> >> From: Laszlo Ersek [mailto:ler...@redhat.com]
> >> Sent: Tuesday, January 08, 2019 9:26 AM
> >> To: Carsey, Jaben ; Gao, Liming
> >> ; Ni, Ray ; edk2-
> >> de...@lists.01.org; leif.lindh...@linaro.org; af...@apple.com; Kinney,
> >> Michael D 
> >> Subject: Re: [edk2] [RFC] Edk2 BaseTools Python3 Migration Update
> >> Importance: High
> >>
> >> On 01/08/19 17:22, Carsey, Jaben wrote:
> >> > Liming and Laszlo,
> >> >  What if we add a 4th option to the environment variable - the path to
> >> a specific python interpreter for use.
> >>
> >> I thought of that, but how do the build tools derive the python version
> >> just from the pathname of the interpreter?
> >>
> >> Will they run "$INTERPRETER --version" and parse the output?
> >>
> >> I think that could be brittle; distributions sometimes customize the
> >> version strings of their executables. The "--version" output is usually
> >> human-readable, not machine-readable (per intent).
> >
> >Laszlo, you lost me. How is that related to an exact path?   If the user
> specifies
> >the path, then always use that specific interpreter.
> >
> >>
> >> Thanks,
> >> Laszlo
> >>
> >> >
> >> > -Jaben
> >> >
> >> >
> >> >> -Original Message-
> >> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> >Of
> >> >> Gao, Liming
> >> >> Sent: Tuesday, January 08, 2019 6:23 AM
> >> >> To: Laszlo Ersek ; Ni, Ray ;
> >edk2-
> >> >> de...@lists.01.org; leif.lindh...@linaro.org; af...@apple.com; Kinney,
> >> >> Michael D 
> >> >> Subject: Re: [edk2] [RFC] Edk2 BaseTools Python3 Migration Update
> >> >>
> >> >> Laszlo:
> >> >>   Yes. This can be supported. But, I don't know what purpose to specify
> >> >> python minor version of Python3. Current implementation in Python3
> >> branch
> >> >> always tries to find the high version installed in OS. For example,
> >> Python3.4,
> >> >> Python3.7 are both installed, Python3.7 will be chosen. Does this policy
> >> meet
> >> >> with your usage?
> >> >>
> >> >> Thanks
> >> >> Liming
> >> >>> -Original Message-
> >> >>> From: Laszlo Ersek [mailto:ler...@redhat.com]
> >> >>> Sent: Tuesday, January 8, 2019 3:04 AM
> >> >>> To: Gao, Liming ; Ni, Ray ;
> >> edk2-
> >> >> de...@lists.01.org; leif.lindh...@linaro.org;
> >> >>> af...@apple.com; Kinney, Michael D 
> >> >>> Subject: Re: [edk2] [RFC] Edk2 BaseTools Python3 Migration Update
> >> >>>
> >> >>> On 01/07/19 14:41, Gao, Liming wrote:
> >>  Ray:
> >>   I think this proposal is good to recommend Python3 as the default
> >> >> interpreter. I summary the updated proposal.
> >> 
> >>  1. PYTHON3_ENABLE env is not set. edksetup.bat/edksetup.sh will
> >find
> >> >> higher version python installed in OS. If Python3 is found,
> >> >>> Python3 will be used. Then, if python2 is found, and python2 is used.
> If
> >> not
> >> >> found, report error and stop build. This will change the
> >> >>> default python interpreter from Python2 to Python3 when they both
> >are
> >> >> installed.
> >>  2. PYTHON3_EANBLE env is set to TRUE. edksetup.bat/edksetup.sh
> >will
> >> >> find Python3. If Python3 is found, Python3 will be used. If not
> >> >>> found, report error and stop build.
> >>  3. PYTHON3_ENABLE env is set to not TRUE.
> >edksetup.bat/edksetup.sh
> >> >> will find Python2. If Python2 is found, Python2 will be used. If
> >> >>> not found, report error and stop build.
> >>  Once Python is found, edksetup.bat/edksetup.sh and build tool will
> >> both
> >> >> print message to let user aware 

Re: [edk2] [Patch v1 1/1] MdeModulePkg: fix comments in BaseSortLib

[Carsey, Jaben]

I did the work last year so I didn't do anything but the email this year...

> -Original Message-
> From: Zeng, Star
> Sent: Tuesday, January 08, 2019 5:18 PM
> To: Carsey, Jaben ; edk2-devel@lists.01.org
> Cc: Wang, Jian J ; Zeng, Star 
> Subject: RE: [Patch v1 1/1] MdeModulePkg: fix comments in BaseSortLib
> Importance: High
> 
> How about updating "2018" to "2019"? :)
> 
> 
> With that, Reviewed-by: Star Zeng .
> 
> Thanks,
> Star
> -Original Message-
> From: Carsey, Jaben
> Sent: Wednesday, January 9, 2019 5:58 AM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Wang, Jian J 
> Subject: [Patch v1 1/1] MdeModulePkg: fix comments in BaseSortLib
> 
> The comments are incorrect for the base version of this lib.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jaben Carsey 
> Cc: Star Zeng 
> Cc: Jian J Wang 
> ---
>  MdeModulePkg/Library/BaseSortLib/BaseSortLib.c | 22 
>  1 file changed, 9 insertions(+), 13 deletions(-)
> 
> diff --git a/MdeModulePkg/Library/BaseSortLib/BaseSortLib.c
> b/MdeModulePkg/Library/BaseSortLib/BaseSortLib.c
> index ab8a60585ee2..8f30c00971eb 100644
> --- a/MdeModulePkg/Library/BaseSortLib/BaseSortLib.c
> +++ b/MdeModulePkg/Library/BaseSortLib/BaseSortLib.c
> @@ -1,7 +1,7 @@
>  /** @file
>Library used for sorting routines.
> 
> -  Copyright (c) 2009 - 2014, Intel Corporation. All rights reserved. 
> +  Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
> + 
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
>which accompanies this distribution.  The full text of the license may be
> found at @@ -193,14 +193,12 @@ DevicePathCompare (  }
> 
>  /**
> -  Function to compare 2 strings without regard to case of the characters.
> +  Not supported in Base version.
> 
> -  @param[in] Buffer1Pointer to String to compare.
> -  @param[in] Buffer2Pointer to second String to compare.
> +  @param[in] Buffer1  Ignored.
> +  @param[in] Buffer2  Ignored.
> 
> -  @retval 0 Buffer1 equal to Buffer2.
> -  @return < 0   Buffer1 is less than Buffer2.
> -  @return > 0   Buffer1 is greater than Buffer2.
> +  ASSERT and return 0.
>  **/
>  INTN
>  EFIAPI
> @@ -215,14 +213,12 @@ StringNoCaseCompare (
> 
> 
>  /**
> -  Function to compare 2 strings.
> +  Not supported in Base version.
> 
> -  @param[in] Buffer1Pointer to String to compare (CHAR16**).
> -  @param[in] Buffer2Pointer to second String to compare 
> (CHAR16**).
> +  @param[in] Buffer1  Ignored.
> +  @param[in] Buffer2  Ignored.
> 
> -  @retval 0 Buffer1 equal to Buffer2.
> -  @return < 0   Buffer1 is less than Buffer2.
> -  @return > 0   Buffer1 is greater than Buffer2.
> +  ASSERT and return 0.
>  **/
>  INTN
>  EFIAPI
> --
> 2.16.2.windows.1

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

Re: [edk2] [PATCH 0/6] implement standalone MM versions of the variable runtime drivers

[Ard Biesheuvel]

On Wed, 9 Jan 2019 at 14:56, Gao, Liming  wrote:
>
> Ard:
>   Now, the impact is to update platform DSC to include MmServicesTableLib 
> library instance. This change is acceptable for me. I suggest your create one 
> BZ for this patch set.

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

>   Besides, I can't apply for these patches in my machine. Could you share git 
> branch to me? Then, I can further verify its functionality on SMM mode.
>

https://github.com/ardbiesheuvel/edk2/tree/variable-ftw-standalone-mm-conversion

Note that I included the changes to add the MmServicesTableLib
resolution to consumers of the FTW and variable drivers.

Thanks,
Ard.



> Thanks
> Liming
> > -Original Message-
> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > Sent: Monday, January 7, 2019 9:06 PM
> > To: Gao, Liming 
> > Cc: edk2-devel@lists.01.org; Laszlo Ersek ; Leif 
> > Lindholm ; Kinney, Michael D
> > ; Wang, Jian J ; Wu, Hao 
> > A ; Jagadeesh Ujja
> > ; Achin Gupta ; Thomas 
> > Panakamattam Abraham ;
> > Sami Mujawar 
> > Subject: Re: [PATCH 0/6] implement standalone MM versions of the variable 
> > runtime drivers
> >
> > On Mon, 7 Jan 2019 at 13:44, Gao, Liming  wrote:
> > >
> > > Ard:
> > >   I agree this design is good. But, I need some time to evaluate its 
> > > impact on our X86 platform. Could you wait for several days?
> > >
> >
> > Of course.
> >
> > Thanks,
> >
> > > > -Original Message-
> > > > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > > > Sent: Friday, January 4, 2019 2:28 AM
> > > > To: edk2-devel@lists.01.org
> > > > Cc: Ard Biesheuvel ; Laszlo Ersek 
> > > > ; Leif Lindholm ;
> > Kinney,
> > > > Michael D ; Gao, Liming 
> > > > ; Wang, Jian J ; Wu, Hao A
> > > > ; Jagadeesh Ujja ; Achin 
> > > > Gupta ; Thomas Panakamattam
> > > > Abraham ; Sami Mujawar 
> > > > Subject: [PATCH 0/6] implement standalone MM versions of the variable 
> > > > runtime drivers
> > > >
> > > > This series proposed an alternative approach to the series sent out by
> > > > Jagadeesh [0]. In particular, it gets rid of the InMm() calls and the
> > > > special PCD, as well as some other if() conditionals.
> > > >
> > > > The primary difference is that this series defines and implements
> > > > MmServicesTableLib in such a way that the traditional SMM drivers
> > > > can use it as well. This is appropriate, considering that the PI
> > > > spec has rebranded traditional SMM as one implementation of the generic
> > > > MM framework.
> > > >
> > > > Patch #1 is based on Jagadeesh's patch, and introduces the 
> > > > MmServicesTableLib
> > > > library class, but for all SMM flavours, not only for standalone MM.
> > > >
> > > > Patch #2 implements MmServicesTableLib for traditional SMM 
> > > > implementations.
> > > >
> > > > Patch #3 refactors FaultTolerantWriteDxe so that the parts of the SMM
> > > > driver that invoke boot services are separated from the core SMM pieces.
> > > >
> > > > Patch #4 implements FaultTolerantWriteSmm for the standalone MM 
> > > > environment.
> > > >
> > > > Patches #5 and #6 do the same, respectively, for the variable runtime 
> > > > driver.
> > > >
> > > > This approach minimizes the delta, and thus the maintenance burden, 
> > > > between
> > > > the traditional SMM and standalone MM drivers, while not resorting to 
> > > > runtime
> > > > checks or other conditionals in the code to implement logic that should 
> > > > be
> > > > decided at build time.
> > > >
> > > > Note that this series only covers part of the work contributed by 
> > > > Jagadeesh.
> > > > This series focuses on the MdePkg and MdeModulePkg changes that affect 
> > > > shared
> > > > code.
> > > >
> > > > Cc: Laszlo Ersek 
> > > > Cc: Leif Lindholm 
> > > > Cc: Michael D Kinney 
> > > > Cc: Liming Gao 
> > > > Cc: Jian J Wang 
> > > > Cc: Hao Wu 
> > > > Cc: Jagadeesh Ujja 
> > > > Cc: Achin Gupta 
> > > > Cc: Thomas Panakamattam Abraham 
> > > > Cc: Sami Mujawar 
> > > >
> > > > Ard Biesheuvel (5):
> > > >   MdePkg: implement MmServicesTableLib based on traditional SMM
> > > >   MdeModulePkg/FaultTolerantWriteDxe: factor out boot service accesses
> > > >   MdeModulePkg/FaultTolerantWriteDxe: implement standalone MM version
> > > >   MdeModulePkg/VariableRuntimeDxe: factor out boot service accesses
> > > >   MdeModulePkg/VariableRuntimeDxe: implement standalone MM version
> > > >
> > > > Jagadeesh Ujja (1):
> > > >   MdePkg/Include: add MmServicesTableLib header file
> > > >
> > > >  MdeModulePkg/MdeModulePkg.dsc |   1 +
> > > >  .../FaultTolerantWrite.h  |  22 ++-
> > > >  .../FaultTolerantWriteDxe.c   |  31 
> > > >  .../FaultTolerantWriteSmm.c   |  54 +++
> > > >  .../FaultTolerantWriteSmm.inf |   5 +-
> > > >  .../FaultTolerantWriteSmmCommon.h |  31 
> > > >  .../FaultTolerantWriteSmmDxe.c|   1 +
> > > >  .../FaultTolerantWriteStandaloneMm.c   

Re: [edk2] [PATCH] Maintainers.txt: Update mail address

[Laszlo Ersek]

On 01/09/19 10:59, Ruiyu Ni wrote:
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ray Ni 
> Cc: Liming Gao 
> ---
>  Maintainers.txt | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)

And I'll update my address book in Thunderbird :)

> diff --git a/Maintainers.txt b/Maintainers.txt
> index 7f2f9de79f..3b2676bc32 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -124,12 +124,12 @@ EmulatorPkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/EmulatorPkg
>  M: Jordan Justen 
>  M: Andrew Fish 
> -M: Ruiyu Ni 
> +M: Ray Ni 
>  S: Maintained
>  
>  FatPkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/Edk2-fat-driver
> -M: Ruiyu Ni 
> +M: Ray Ni 
>  T: svn - https://svn.code.sf.net/p/edk2-fatdriver2/code/trunk/EnhancedFat
>  T: git - https://github.com/tianocore/edk2-FatPkg.git
>  
> @@ -173,7 +173,7 @@ R: Star Zeng 
>  
>  IntelSiliconPkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/IntelSiliconPkg
> -M: Ruiyu Ni 
> +M: Ray Ni 
>  M: Rangasai V Chaganty 
>  
>  MdeModulePkg
> @@ -182,7 +182,7 @@ M: Jian J Wang 
>  M: Hao Wu 
>  M: NetworkPkg maintainers
>(Universal/Network and related libraries, header files)
> -R: Ruiyu Ni 
> +R: Ray Ni 
>(especially for Bus, Universal/Console, Universal/Disk,
> Universal/BdsDxe and related libraries, header files)
>  R: Star Zeng 
> @@ -199,7 +199,7 @@ M: Jiaxin Wu 
>  
>  Nt32Pkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/Nt32Pkg
> -M: Ruiyu Ni 
> +M: Ray Ni 
>  M: Hao Wu 
>  
>  Omap35xxPkg
> @@ -209,7 +209,7 @@ M: Ard Biesheuvel 
>  
>  OptionRomPkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/OptionRomPkg
> -M: Ruiyu Ni 
> +M: Ray Ni 
>  
>  OvmfPkg
>  W: http://www.tianocore.org/ovmf/
> @@ -222,7 +222,7 @@ S: Maintained
>  
>  PcAtChipsetPkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/PcAtChipsetPkg
> -M: Ruiyu Ni 
> +M: Ray Ni 
>  
>  QuarkPlatformPkg, QuarkSocPkg
>  M: Michael D Kinney 
> @@ -236,14 +236,14 @@ M: Jiewen Yao 
>  ShellBinPkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg
>  M: Jaben Carsey   (Ia32/X64)
> -M: Ruiyu Ni   (Ia32/X64)
> +M: Ray Ni   (Ia32/X64)
>  M: Leif Lindholm(ARM/AArch64)
>  M: Ard Biesheuvel  (ARM/AArch64)
>  
>  ShellPkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg
>  M: Jaben Carsey 
> -M: Ruiyu Ni 
> +M: Ray Ni 
>  
>  SignedCapsulePkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/SignedCapsulePkg
> @@ -262,7 +262,7 @@ M: Jaben Carsey 
>  UefiCpuPkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/UefiCpuPkg
>  M: Eric Dong 
> -M: Ruiyu Ni 
> +M: Ray Ni 
>  R: Laszlo Ersek 
>  
>  Vlv2DeviceRefCodePkg
> 

Ugh, don't you have a bit too much on your plate? Co-maintaining 9
packages, and being a reviewer for another one. That can't be easy!

(Side topic: here's a list of maintainers/reviewers (lumped together)
with responsibility for more than one "area" (not just package), ordered
descending by area count:

$ grep '^[MR]: ' Maintainers.txt \
| cut -c 4- \
| sort \
| uniq -c \
| sort -rn

  9 Ruiyu Ni 
  7 Liming Gao 
  7 Ard Biesheuvel 
  6 Leif Lindholm 
  5 Star Zeng 
  5 Michael D Kinney 
  4 Nate DeSimone 
  4 Laszlo Ersek 
  4 Chasel Chiu 
  3 Jiewen Yao 
  3 Jaben Carsey 
  3 Hao Wu 
  2 Zailiang Sun 
  2 Yi Qian 
  2 Julien Grall 
  2 Jordan Justen 
  2 Daryl McDaniel 
  2 Chao Zhang 
  2 Andrew Fish 
)

Anyway it looks like all occurrences in the text file are covered.

Reviewed-by: Laszlo Ersek 

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

Re: [edk2] [PATCH 0/6] implement standalone MM versions of the variable runtime drivers

[Laszlo Ersek]

On 01/09/19 11:28, Ard Biesheuvel wrote:
> On Wed, 9 Jan 2019 at 10:44, Laszlo Ersek  wrote:

>> But, it's still not clear to me (without trying) whether I should
>> resolve MmServicesTableLib  for DXE_SMM_DRIVER in addition to
>> SmmServicesTableLib, or in its place. I'd prefer not experimenting with
>> this myself; I'd just like to apply the series, and build & test it. :)
>>
> 
> At the moment, you will need both resolutions for DXE_SMM_DRIVERS
> globally. Based on the outcome of the review of this series, this is
> something we will need to clean up going forward, but currently, even
> the drivers that are updated to use MmServicesTableLib pull in
> libraries that depend on SmmServicesTableLib.
> 
> This should be a rather straight-forward search/replace operation
> [famous last words], and I can commit to dedicating some of my time to
> getting this fixed throughout, at least to the point where modules
> that consume MmServicesTableLib no longer have to supply a resolution
> for SmmServicesTableLib as well.
> 
> So, I will include a patch in the next revision of the series.

Great, thank you. This is exactly the info I needed.

> In the mean time, the hunk below should suffice to complete your regression
> testing.
> 
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -391,6 +391,7 @@
>HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
>SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
>
> SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
> +  MmServicesTableLib|MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
>  !ifdef $(DEBUG_ON_SERIAL_PORT)
>DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
>  !else
> 

I'll replicate this to the other two DSC files [*], and then retry the
tests.

[*] SMM in OVMF has a non-intuitive restriction, in relation to X64 PEI.
SMM "just works" in the IA32 and IA32X64 builds, however, in the X64
build, one has to disable S3 support on the QEMU command line, or else
we hang the boot intentionally. See commit 5133d1f1d297 ("OvmfPkg:
replace README fine print about X64 SMM S3 with PlatformPei check",
2015-11-30).

For this reason, the IA32X64 build is considered the most-featureful, if
-D SMM_REQUIRE is desired.


For those that insist on the X64 build nevertheless, OvmfPkg/README
documents the QEMU option that disables S3, on the Q35 machine type,
which is required for SMM anyway:

  -global ICH9-LPC.disable_s3=1

When using libvirt, the matching knob is:

https://libvirt.org/formatdomain.html#elementsPowerManagement


  



Personally, I focus my SMM testing on IA32 and IA32X64; I almost never
test SMM in the X64 build. This is because S3 has historically proved
very effective at triggering multiprocessing bugs in core SMM code, and
in general UefiCpuPkg infrastructure. Thus, my SMM regression tests:

https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt

always include S3 suspend/resume, and that precludes the X64 build of OVMF.

... Sorry about the wall of text, I just wanted to explain why precisely
the short hunk you pasted is unhelpful in this case. Obviously, it does
answer my question, I can copy the class resolution to the other two DSC
files, and in the final OvmfPkg patch, we should update all three DSC files.

I'll be back with test results later.

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

Re: [edk2] Conditional Compilation support in INF file

[Laszlo Ersek]

On 01/09/19 13:42, Gao, Liming wrote:
> Laszlo:
>   INF Spec: FixedAtBuild (VOID*) PCD use in the [DEPEX] section has been 
> added into INF spec git book 
> (g...@github.com:tianocore-docs/edk2-InfSpecification.git). BZ 
> https://bugzilla.tianocore.org/show_bug.cgi?id=444
>   The change is in INF spec trunk. New version INF spec will include it. 

Ouch. I should have remembered. BZ#444 was filed by me. :) I've only
checked the v1.27 INF spec now, on gitbooks.io.

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

Re: [edk2] [PATCH 0/6] implement standalone MM versions of the variable runtime drivers

[Gao, Liming]

Ard:
  Now, the impact is to update platform DSC to include MmServicesTableLib 
library instance. This change is acceptable for me. I suggest your create one 
BZ for this patch set.
  Besides, I can't apply for these patches in my machine. Could you share git 
branch to me? Then, I can further verify its functionality on SMM mode. 
  
Thanks
Liming
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Monday, January 7, 2019 9:06 PM
> To: Gao, Liming 
> Cc: edk2-devel@lists.01.org; Laszlo Ersek ; Leif Lindholm 
> ; Kinney, Michael D
> ; Wang, Jian J ; Wu, Hao A 
> ; Jagadeesh Ujja
> ; Achin Gupta ; Thomas 
> Panakamattam Abraham ;
> Sami Mujawar 
> Subject: Re: [PATCH 0/6] implement standalone MM versions of the variable 
> runtime drivers
> 
> On Mon, 7 Jan 2019 at 13:44, Gao, Liming  wrote:
> >
> > Ard:
> >   I agree this design is good. But, I need some time to evaluate its impact 
> > on our X86 platform. Could you wait for several days?
> >
> 
> Of course.
> 
> Thanks,
> 
> > > -Original Message-
> > > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > > Sent: Friday, January 4, 2019 2:28 AM
> > > To: edk2-devel@lists.01.org
> > > Cc: Ard Biesheuvel ; Laszlo Ersek 
> > > ; Leif Lindholm ;
> Kinney,
> > > Michael D ; Gao, Liming 
> > > ; Wang, Jian J ; Wu, Hao A
> > > ; Jagadeesh Ujja ; Achin 
> > > Gupta ; Thomas Panakamattam
> > > Abraham ; Sami Mujawar 
> > > Subject: [PATCH 0/6] implement standalone MM versions of the variable 
> > > runtime drivers
> > >
> > > This series proposed an alternative approach to the series sent out by
> > > Jagadeesh [0]. In particular, it gets rid of the InMm() calls and the
> > > special PCD, as well as some other if() conditionals.
> > >
> > > The primary difference is that this series defines and implements
> > > MmServicesTableLib in such a way that the traditional SMM drivers
> > > can use it as well. This is appropriate, considering that the PI
> > > spec has rebranded traditional SMM as one implementation of the generic
> > > MM framework.
> > >
> > > Patch #1 is based on Jagadeesh's patch, and introduces the 
> > > MmServicesTableLib
> > > library class, but for all SMM flavours, not only for standalone MM.
> > >
> > > Patch #2 implements MmServicesTableLib for traditional SMM 
> > > implementations.
> > >
> > > Patch #3 refactors FaultTolerantWriteDxe so that the parts of the SMM
> > > driver that invoke boot services are separated from the core SMM pieces.
> > >
> > > Patch #4 implements FaultTolerantWriteSmm for the standalone MM 
> > > environment.
> > >
> > > Patches #5 and #6 do the same, respectively, for the variable runtime 
> > > driver.
> > >
> > > This approach minimizes the delta, and thus the maintenance burden, 
> > > between
> > > the traditional SMM and standalone MM drivers, while not resorting to 
> > > runtime
> > > checks or other conditionals in the code to implement logic that should be
> > > decided at build time.
> > >
> > > Note that this series only covers part of the work contributed by 
> > > Jagadeesh.
> > > This series focuses on the MdePkg and MdeModulePkg changes that affect 
> > > shared
> > > code.
> > >
> > > Cc: Laszlo Ersek 
> > > Cc: Leif Lindholm 
> > > Cc: Michael D Kinney 
> > > Cc: Liming Gao 
> > > Cc: Jian J Wang 
> > > Cc: Hao Wu 
> > > Cc: Jagadeesh Ujja 
> > > Cc: Achin Gupta 
> > > Cc: Thomas Panakamattam Abraham 
> > > Cc: Sami Mujawar 
> > >
> > > Ard Biesheuvel (5):
> > >   MdePkg: implement MmServicesTableLib based on traditional SMM
> > >   MdeModulePkg/FaultTolerantWriteDxe: factor out boot service accesses
> > >   MdeModulePkg/FaultTolerantWriteDxe: implement standalone MM version
> > >   MdeModulePkg/VariableRuntimeDxe: factor out boot service accesses
> > >   MdeModulePkg/VariableRuntimeDxe: implement standalone MM version
> > >
> > > Jagadeesh Ujja (1):
> > >   MdePkg/Include: add MmServicesTableLib header file
> > >
> > >  MdeModulePkg/MdeModulePkg.dsc |   1 +
> > >  .../FaultTolerantWrite.h  |  22 ++-
> > >  .../FaultTolerantWriteDxe.c   |  31 
> > >  .../FaultTolerantWriteSmm.c   |  54 +++
> > >  .../FaultTolerantWriteSmm.inf |   5 +-
> > >  .../FaultTolerantWriteSmmCommon.h |  31 
> > >  .../FaultTolerantWriteSmmDxe.c|   1 +
> > >  .../FaultTolerantWriteStandaloneMm.c  |  70 +
> > >  .../FaultTolerantWriteStandaloneMm.inf|  90 
> > >  .../FaultTolerantWriteTraditionalMm.c |  94 
> > >  .../UpdateWorkingBlock.c  |  10 +-
> > >  .../Variable/RuntimeDxe/TcgMorLockSmm.c   |  18 +--
> > >  .../Universal/Variable/RuntimeDxe/Variable.h  |  50 +++
> > >  .../Variable/RuntimeDxe/VariableSmm.c |  59 +++-
> > >  .../Variable/RuntimeDxe/VariableSmm.inf   |   5 +-
> > >  .../RuntimeDxe/VariableStandaloneMm.c |  69 +
> 

Re: [edk2] Conditional Compilation support in INF file

[Gao, Liming]

Laszlo:
  INF Spec: FixedAtBuild (VOID*) PCD use in the [DEPEX] section has been added 
into INF spec git book 
(g...@github.com:tianocore-docs/edk2-InfSpecification.git). BZ 
https://bugzilla.tianocore.org/show_bug.cgi?id=444
  The change is in INF spec trunk. New version INF spec will include it. 

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
> Ersek
> Sent: Wednesday, January 9, 2019 7:00 PM
> To: karunakarpoosapa...@dell.com; edk2-devel@lists.01.org
> Subject: Re: [edk2] Conditional Compilation support in INF file
> 
> On 01/09/19 07:55, karunakarpoosapa...@dell.com wrote:
> > Hi ALL,
> >
> >
> >
> > I've an idea regards "Adding conditional compilation  support in INF files"
> >
> >
> >
> > Ides is like, we can condition check in INF file like below
> >
> >
> >
> > #if Condition1
> >
> >Protocol1
> >
> > #elif Condition2
> >
> >Protocol2
> >
> > #else
> >
> >Protocol3
> >
> > #endif
> >
> >
> >
> > If we've this support we can add different protocols in DEPEX section, Like 
> > we can put condition check and add rotococol1 for
> Notebook and Protocol2 for Desktop.
> >
> > And will have so many benefits adding this support.
> >
> >
> >
> > I don't think current EDK2 support this.
> >
> > Please let me know comments/suggestions, so that I will start working on it.
> 
> I'm not sure this feature is really required. We already have the
> following tools at our disposal, to customize module builds at the INF
> file level:
> 
> (1) Please see .
> (Unfortunately, the INF file spec doesn't seem to document the syntax;
> 
> should help however.)
> 
> (2) If the number of cases that need to be distinguished is low, it's
> possible to duplicate the INF file, keep the [Sources] section(s) and
> similar sections identical, and only customize the sections that need
> changes. Then include the right INF file in the platform DSC and FDF
> files, dependent on PCD settings or build defines (macros).
> 
> (3) Sometimes it makes sense to delay the dispatching of a module until
> another module makes a decision about a platform feature, dynamically.
> An important characteristic of this case is that the dependent module
> should not be prevented from starting *completely* in case the platform
> feature is absent; it should only be made wait until the decision is
> recorded, by the other module. This way the dependent module will not
> incorrectly customize its own behavior before the decision on the
> platform feature is made.
> 
> In this case, it's usually possible to write the depex such as
> 
>   (gProtocolGuid1 AND gProtocolGuid2) OR
>   (gProtocolGuid3 AND gProtocolGuid4) OR
>   gThisParticularFeatureDisabledProtocolGuid
> 
> Here:
> - gProtocolGuid1 and gProtocolGuid2 could be specific to "Notebook",
> - gProtocolGuid3 and gProtocolGuid4 could be specific to "Desktop",
> - and gThisParticularFeatureDisabledProtocolGuid would be a *synthetic*
> protocol GUID -- installed in the protocol database with a NULL
> interface -- through which the decision-making module would simply
> advertize, "none of the relevant features are available, and you need
> not wait any longer".
> 
> "gThisParticularFeatureDisabledProtocolGuid" is usually defined /
> declared as a platform Pkg-specific GUID, in the appropriate DEC file,
> and in Include/Guid/, under the same Pkg.
> 
> (4) It is possible to hook such dependencies into other (core) modules.
> In the platform Package, you can implement a library that (a) has an
> empty constructor function, and (b) the DEPEX of your choosing (see
> above). The library should do nothing else. Then, in the package DSC
> file, hook the library into the core module in question via NULL class
> resolution. As a result, the library will not alter the behavior of the
> core module, but the core module will inherit the depex (it will be
> AND-ed together with other dependencies that the core module might have).
> 
> Thanks
> Laszlo
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Conditional Compilation support in INF file

[Laszlo Ersek]

On 01/09/19 07:55, karunakarpoosapa...@dell.com wrote:
> Hi ALL,
> 
> 
> 
> I've an idea regards "Adding conditional compilation  support in INF files"
> 
> 
> 
> Ides is like, we can condition check in INF file like below
> 
> 
> 
> #if Condition1
> 
>Protocol1
> 
> #elif Condition2
> 
>Protocol2
> 
> #else
> 
>Protocol3
> 
> #endif
> 
> 
> 
> If we've this support we can add different protocols in DEPEX section, Like 
> we can put condition check and add rotococol1 for Notebook and Protocol2 for 
> Desktop.
> 
> And will have so many benefits adding this support.
> 
> 
> 
> I don't think current EDK2 support this.
> 
> Please let me know comments/suggestions, so that I will start working on it.

I'm not sure this feature is really required. We already have the
following tools at our disposal, to customize module builds at the INF
file level:

(1) Please see .
(Unfortunately, the INF file spec doesn't seem to document the syntax;

should help however.)

(2) If the number of cases that need to be distinguished is low, it's
possible to duplicate the INF file, keep the [Sources] section(s) and
similar sections identical, and only customize the sections that need
changes. Then include the right INF file in the platform DSC and FDF
files, dependent on PCD settings or build defines (macros).

(3) Sometimes it makes sense to delay the dispatching of a module until
another module makes a decision about a platform feature, dynamically.
An important characteristic of this case is that the dependent module
should not be prevented from starting *completely* in case the platform
feature is absent; it should only be made wait until the decision is
recorded, by the other module. This way the dependent module will not
incorrectly customize its own behavior before the decision on the
platform feature is made.

In this case, it's usually possible to write the depex such as

  (gProtocolGuid1 AND gProtocolGuid2) OR
  (gProtocolGuid3 AND gProtocolGuid4) OR
  gThisParticularFeatureDisabledProtocolGuid

Here:
- gProtocolGuid1 and gProtocolGuid2 could be specific to "Notebook",
- gProtocolGuid3 and gProtocolGuid4 could be specific to "Desktop",
- and gThisParticularFeatureDisabledProtocolGuid would be a *synthetic*
protocol GUID -- installed in the protocol database with a NULL
interface -- through which the decision-making module would simply
advertize, "none of the relevant features are available, and you need
not wait any longer".

"gThisParticularFeatureDisabledProtocolGuid" is usually defined /
declared as a platform Pkg-specific GUID, in the appropriate DEC file,
and in Include/Guid/, under the same Pkg.

(4) It is possible to hook such dependencies into other (core) modules.
In the platform Package, you can implement a library that (a) has an
empty constructor function, and (b) the DEPEX of your choosing (see
above). The library should do nothing else. Then, in the package DSC
file, hook the library into the core module in question via NULL class
resolution. As a result, the library will not alter the behavior of the
core module, but the core module will inherit the depex (it will be
AND-ed together with other dependencies that the core module might have).

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

Re: [edk2] [Patch 1/3] UefiCpuPkg/RegisterCpuFeaturesLib: Avoid AP calls PeiService.

[Laszlo Ersek]

Hi Eric,

On 01/09/19 06:26, Dong, Eric wrote:
> Hi all,
> 
> We got some feedback about this BZ. Someone think this timeout is valuable 
> for the debug purpose, and oppose to remove it. 
> https://bugzilla.tianocore.org/show_bug.cgi?id=1419
> 
> So I'm back to here and want to still use this change. I not use "update 
> PcdSpinLockTimeout to 0 in platform" solution because I think core driver 
> depends on platform policy is not a good design. 
> 
> Do you guys have any other concern?

sorry, I don't understand.

(1) In , where
currently comment #2 is the last comment, I don't see any request for
keeping the timeout facility.

(2) On the mailing list as well, you seem to have received comments only
in favor of removing the timeout facility.

"Someone think this timeout is valuable for the debug purpose" doesn't
cut it, for open development. I don't care about the identity of the
person that wants to preserve the feature, but I certainly care about
their use case. You shouldn't have to mediate and describe their use
case for them, on the list; that's always a lossy process.

Regarding the PCD: I think zeroing "PcdSpinLockTimeout" to disable the
timeout case is a valid approach, it's just that we should change the
default value in the DEC file to zero. Then the PCD setting will become
a burden only for those platforms and those use cases that want to use
the timeout feature (such as for debugging).

In general, PCD default values in DEC files have to be considered
carefully, but in some cases, such changes are the right thing. Another
example was 509f8425b75d ("UefiCpuPkg: change PcdCpuSmmStackGuard
default to TRUE", 2016-06-06).

(You made the same point at the end of
.)


In addition to changing the default value to zero, I'd suggest moving
"PcdSpinLockTimeout" from section

[PcdsFixedAtBuild,PcdsPatchableInModule]

to section

[PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]

so that platforms can enable the "debug" feature (i.e. set a nonzero
value) more flexibly.

Thanks
Laszlo

>> -Original Message-
>> From: Brian J. Johnson [mailto:brian.john...@hpe.com]
>> Sent: Friday, December 21, 2018 12:36 AM
>> To: Yao, Jiewen ; Ni, Ruiyu ;
>> Dong, Eric ; edk2-devel@lists.01.org
>> Cc: Laszlo Ersek 
>> Subject: Re: [edk2] [Patch 1/3] UefiCpuPkg/RegisterCpuFeaturesLib: Avoid
>> AP calls PeiService.
>>
>> Agreed.  We've seen issues on real platforms with timed-out spinlocks in DXE
>> causing calls to GetPerformanceCounter and DebugAssert.  (DXE has the
>> same code, with the same issues.)
>>
>> Note that it's possible to set PcdSpinLockTimeout=0 to work around the issue
>> on a particular platform, or in a particular module.  But if you have to do 
>> that
>> for every module which uses APs, and hence could contend for a spinlock, it
>> kind of defeats the point  We're better off removing the timeout code.
>>
>> Thanks,
>> Brian
>>
>> On 12/19/18 8:08 PM, Yao, Jiewen wrote:
>>> Yes, I agree, if we don't have any real case.
>>>
>>>
 -Original Message-
 From: Ni, Ruiyu
 Sent: Thursday, December 20, 2018 10:07 AM
 To: Dong, Eric ; Yao, Jiewen
 ; edk2-devel@lists.01.org
 Cc: Laszlo Ersek 
 Subject: RE: [edk2] [Patch 1/3] UefiCpuPkg/RegisterCpuFeaturesLib:
 Avoid AP calls PeiService.

 Can you just change the AcquireSpinLock() behavior to remove the
 Timeout PCD consumption?

 I haven't seen a real case that the timed acquisition of spin lock is 
 needed.


 Thanks/Ray

> -Original Message-
> From: Dong, Eric 
> Sent: Thursday, December 20, 2018 9:23 AM
> To: Yao, Jiewen ; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Laszlo Ersek 
> Subject: RE: [edk2] [Patch 1/3] UefiCpuPkg/RegisterCpuFeaturesLib:
> Avoid AP calls PeiService.
>
>
> Agreed, Maybe it's time to add a new API like
> AcquireSpinLockWithoutTimeOut?
>
> Thanks,
> Eric
>> -Original Message-
>> From: Yao, Jiewen
>> Sent: Thursday, December 20, 2018 9:19 AM
>> To: Dong, Eric ; edk2-devel@lists.01.org
>> Cc: Ni, Ruiyu ; Laszlo Ersek
>> 
>> Subject: RE: [edk2] [Patch 1/3] UefiCpuPkg/RegisterCpuFeaturesLib:
>> Avoid AP calls PeiService.
>>
>> Hi
>> If we think below code is generic, can we have an API for that?
>>
>> +  //
>> +  // Wait for the AP to release the MSR spin lock.
>> +  //
>> +  while (!AcquireSpinLockOrFail (>ConsoleLogLock)) {
>> +CpuPause ();
>> +  }
>>
>>
>>
>>
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
>>> Behalf Of Eric Dong
>>> Sent: Thursday, December 20, 2018 9:16 AM
>>> To: edk2-devel@lists.01.org
>>> Cc: Ni, Ruiyu ; Laszlo Ersek
>>> 
>>> Subject: [edk2] 

Re: [edk2] [PATCH 0/6] implement standalone MM versions of the variable runtime drivers

[Ard Biesheuvel]

On Wed, 9 Jan 2019 at 10:44, Laszlo Ersek  wrote:
>
> On 01/03/19 19:28, Ard Biesheuvel wrote:
> > This series proposed an alternative approach to the series sent out by
> > Jagadeesh [0]. In particular, it gets rid of the InMm() calls and the
> > special PCD, as well as some other if() conditionals.
> >
> > The primary difference is that this series defines and implements
> > MmServicesTableLib in such a way that the traditional SMM drivers can
> > use it as well. This is appropriate, considering that the PI spec has
> > rebranded traditional SMM as one implementation of the generic MM
> > framework.
> >
> > Patch #1 is based on Jagadeesh's patch, and introduces the
> > MmServicesTableLib library class, but for all SMM flavours, not only
> > for standalone MM.
> >
> > Patch #2 implements MmServicesTableLib for traditional SMM
> > implementations.
> >
> > Patch #3 refactors FaultTolerantWriteDxe so that the parts of the SMM
> > driver that invoke boot services are separated from the core SMM
> > pieces.
> >
> > Patch #4 implements FaultTolerantWriteSmm for the standalone MM
> > environment.
> >
> > Patches #5 and #6 do the same, respectively, for the variable runtime
> > driver.
> >
> > This approach minimizes the delta, and thus the maintenance burden,
> > between the traditional SMM and standalone MM drivers, while not
> > resorting to runtime checks or other conditionals in the code to
> > implement logic that should be decided at build time.
> >
> > Note that this series only covers part of the work contributed by
> > Jagadeesh. This series focuses on the MdePkg and MdeModulePkg changes
> > that affect shared code.
> >
> > Cc: Laszlo Ersek 
> > Cc: Leif Lindholm 
> > Cc: Michael D Kinney 
> > Cc: Liming Gao 
> > Cc: Jian J Wang 
> > Cc: Hao Wu 
> > Cc: Jagadeesh Ujja 
> > Cc: Achin Gupta 
> > Cc: Thomas Panakamattam Abraham 
> > Cc: Sami Mujawar 
>
> I tried building this, on top of commit a53a888de8f5:
>
> build \
>   -a IA32 \
>   -p OvmfPkg/OvmfPkgIa32.dsc \
>   -t GCC48 \
>   -b NOOPT \
>   -D HTTP_BOOT_ENABLE \
>   -D NETWORK_IP6_ENABLE \
>   -D SECURE_BOOT_ENABLE \
>   -D SMM_REQUIRE \
>   -D TLS_ENABLE \
>   --cmd-len=65536 \
>   --hash \
>   --genfds-multi-thread
>
> but it failed with:
>
> > OvmfPkg/OvmfPkgIa32.dsc(...): error 4000: Instance of library class 
> > [MmServicesTableLib] is not found
> > in 
> > [MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf] 
> > [IA32]
> > consumed by module 
> > [MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf]
>
> You did mention earlier that adding new lib class resolutions to several
> x86 DSC files would be necessary, so this is not unexpected. Can you
> please insert such a patch for OvmfPkg between patches #2 and #3?
>

Ah yes, of course.

> I've looked at the current OVMF DSC files, and SmmServicesTableLib is
> resolved for two module types,
>
> > [LibraryClasses.common.DXE_SMM_DRIVER]
> >   
> > SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
> >
> > [LibraryClasses.common.SMM_CORE]
> >   
> > SmmServicesTableLib|MdeModulePkg/Library/PiSmmCoreSmmServicesTableLib/PiSmmCoreSmmServicesTableLib.inf
>
> I assume it should be enough, for this series, to update the
> DXE_SMM_DRIVER resolution only, and to leave SMM_CORE alone.
>
> (Because, my understanding is that the current, x86 specific
>
>   MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
>
> module, of type SMM_CORE, will not be refactored; instead, it is
> entirely supplanted -- in the affected platforms -- by the
>
>   StandaloneMmPkg/Core/StandaloneMmCore.inf
>
> module, which is of type MM_CORE_STANDALONE.)
>
> But, it's still not clear to me (without trying) whether I should
> resolve MmServicesTableLib  for DXE_SMM_DRIVER in addition to
> SmmServicesTableLib, or in its place. I'd prefer not experimenting with
> this myself; I'd just like to apply the series, and build & test it. :)
>

At the moment, you will need both resolutions for DXE_SMM_DRIVERS
globally. Based on the outcome of the review of this series, this is
something we will need to clean up going forward, but currently, even
the drivers that are updated to use MmServicesTableLib pull in
libraries that depend on SmmServicesTableLib.

This should be a rather straight-forward search/replace operation
[famous last words], and I can commit to dedicating some of my time to
getting this fixed throughout, at least to the point where modules
that consume MmServicesTableLib no longer have to supply a resolution
for SmmServicesTableLib as well.

So, I will include a patch in the next revision of the series. In the
mean time, the hunk below should suffice to complete your regression
testing.

--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -391,6 +391,7 @@
   HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
   SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
   
SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
+  

Re: [edk2] [RFC] Edk2 BaseTools Python3 Migration Update

[Laszlo Ersek]

On 01/08/19 19:05, Carsey, Jaben wrote:
> 
> 
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Tuesday, January 08, 2019 9:26 AM
>> To: Carsey, Jaben ; Gao, Liming
>> ; Ni, Ray ; edk2-
>> de...@lists.01.org; leif.lindh...@linaro.org; af...@apple.com; Kinney,
>> Michael D 
>> Subject: Re: [edk2] [RFC] Edk2 BaseTools Python3 Migration Update
>> Importance: High
>>
>> On 01/08/19 17:22, Carsey, Jaben wrote:
>>> Liming and Laszlo,
>>> What if we add a 4th option to the environment variable - the path to
>> a specific python interpreter for use.
>>
>> I thought of that, but how do the build tools derive the python version
>> just from the pathname of the interpreter?
>>
>> Will they run "$INTERPRETER --version" and parse the output?
>>
>> I think that could be brittle; distributions sometimes customize the
>> version strings of their executables. The "--version" output is usually
>> human-readable, not machine-readable (per intent).
> 
> Laszlo, you lost me. How is that related to an exact path?   If the user 
> specifies the path, then always use that specific interpreter.

Sorry, my fault. I've been confused by an *earlier* approach that was
described here:

  https://bugzilla.tianocore.org/show_bug.cgi?id=55#c10
  https://bugzilla.tianocore.org/show_bug.cgi?id=55#c12

In that case, if the user only specified the interpreter path, it would
be clear what *interpreter* to use, however it would not be not clear
what *sub-codebase* from BaseTools to run on that interpreter: the
Python2 one, or the Python3 one.

However, now I remember, from

  https://bugzilla.tianocore.org/show_bug.cgi?id=55#c14
  https://bugzilla.tianocore.org/show_bug.cgi?id=55#c15

that after all, the goal is a single common set of BaseTools source code
that runs on Python2 and Python3 alike. In that regard, I agree that the
interpreter pathname is the *only* input we should take & accept from
the user, and the particular python *language version* need neither be
provided by the user, nor be detected by BaseTools themselves.

Sorry about the confusion!

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

[edk2] [PATCH] Maintainers.txt: Update mail address

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ray Ni 
Cc: Liming Gao 
---
 Maintainers.txt | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index 7f2f9de79f..3b2676bc32 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -124,12 +124,12 @@ EmulatorPkg
 W: https://github.com/tianocore/tianocore.github.io/wiki/EmulatorPkg
 M: Jordan Justen 
 M: Andrew Fish 
-M: Ruiyu Ni 
+M: Ray Ni 
 S: Maintained
 
 FatPkg
 W: https://github.com/tianocore/tianocore.github.io/wiki/Edk2-fat-driver
-M: Ruiyu Ni 
+M: Ray Ni 
 T: svn - https://svn.code.sf.net/p/edk2-fatdriver2/code/trunk/EnhancedFat
 T: git - https://github.com/tianocore/edk2-FatPkg.git
 
@@ -173,7 +173,7 @@ R: Star Zeng 
 
 IntelSiliconPkg
 W: https://github.com/tianocore/tianocore.github.io/wiki/IntelSiliconPkg
-M: Ruiyu Ni 
+M: Ray Ni 
 M: Rangasai V Chaganty 
 
 MdeModulePkg
@@ -182,7 +182,7 @@ M: Jian J Wang 
 M: Hao Wu 
 M: NetworkPkg maintainers
   (Universal/Network and related libraries, header files)
-R: Ruiyu Ni 
+R: Ray Ni 
   (especially for Bus, Universal/Console, Universal/Disk,
Universal/BdsDxe and related libraries, header files)
 R: Star Zeng 
@@ -199,7 +199,7 @@ M: Jiaxin Wu 
 
 Nt32Pkg
 W: https://github.com/tianocore/tianocore.github.io/wiki/Nt32Pkg
-M: Ruiyu Ni 
+M: Ray Ni 
 M: Hao Wu 
 
 Omap35xxPkg
@@ -209,7 +209,7 @@ M: Ard Biesheuvel 
 
 OptionRomPkg
 W: https://github.com/tianocore/tianocore.github.io/wiki/OptionRomPkg
-M: Ruiyu Ni 
+M: Ray Ni 
 
 OvmfPkg
 W: http://www.tianocore.org/ovmf/
@@ -222,7 +222,7 @@ S: Maintained
 
 PcAtChipsetPkg
 W: https://github.com/tianocore/tianocore.github.io/wiki/PcAtChipsetPkg
-M: Ruiyu Ni 
+M: Ray Ni 
 
 QuarkPlatformPkg, QuarkSocPkg
 M: Michael D Kinney 
@@ -236,14 +236,14 @@ M: Jiewen Yao 
 ShellBinPkg
 W: https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg
 M: Jaben Carsey   (Ia32/X64)
-M: Ruiyu Ni   (Ia32/X64)
+M: Ray Ni   (Ia32/X64)
 M: Leif Lindholm(ARM/AArch64)
 M: Ard Biesheuvel  (ARM/AArch64)
 
 ShellPkg
 W: https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg
 M: Jaben Carsey 
-M: Ruiyu Ni 
+M: Ray Ni 
 
 SignedCapsulePkg
 W: https://github.com/tianocore/tianocore.github.io/wiki/SignedCapsulePkg
@@ -262,7 +262,7 @@ M: Jaben Carsey 
 UefiCpuPkg
 W: https://github.com/tianocore/tianocore.github.io/wiki/UefiCpuPkg
 M: Eric Dong 
-M: Ruiyu Ni 
+M: Ray Ni 
 R: Laszlo Ersek 
 
 Vlv2DeviceRefCodePkg
-- 
2.20.1.windows.1

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

Re: [edk2] [PATCH 0/6] implement standalone MM versions of the variable runtime drivers

[Laszlo Ersek]

On 01/03/19 19:28, Ard Biesheuvel wrote:
> This series proposed an alternative approach to the series sent out by
> Jagadeesh [0]. In particular, it gets rid of the InMm() calls and the
> special PCD, as well as some other if() conditionals.
>
> The primary difference is that this series defines and implements
> MmServicesTableLib in such a way that the traditional SMM drivers can
> use it as well. This is appropriate, considering that the PI spec has
> rebranded traditional SMM as one implementation of the generic MM
> framework.
>
> Patch #1 is based on Jagadeesh's patch, and introduces the
> MmServicesTableLib library class, but for all SMM flavours, not only
> for standalone MM.
>
> Patch #2 implements MmServicesTableLib for traditional SMM
> implementations.
>
> Patch #3 refactors FaultTolerantWriteDxe so that the parts of the SMM
> driver that invoke boot services are separated from the core SMM
> pieces.
>
> Patch #4 implements FaultTolerantWriteSmm for the standalone MM
> environment.
>
> Patches #5 and #6 do the same, respectively, for the variable runtime
> driver.
>
> This approach minimizes the delta, and thus the maintenance burden,
> between the traditional SMM and standalone MM drivers, while not
> resorting to runtime checks or other conditionals in the code to
> implement logic that should be decided at build time.
>
> Note that this series only covers part of the work contributed by
> Jagadeesh. This series focuses on the MdePkg and MdeModulePkg changes
> that affect shared code.
>
> Cc: Laszlo Ersek 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Jian J Wang 
> Cc: Hao Wu 
> Cc: Jagadeesh Ujja 
> Cc: Achin Gupta 
> Cc: Thomas Panakamattam Abraham 
> Cc: Sami Mujawar 

I tried building this, on top of commit a53a888de8f5:

build \
  -a IA32 \
  -p OvmfPkg/OvmfPkgIa32.dsc \
  -t GCC48 \
  -b NOOPT \
  -D HTTP_BOOT_ENABLE \
  -D NETWORK_IP6_ENABLE \
  -D SECURE_BOOT_ENABLE \
  -D SMM_REQUIRE \
  -D TLS_ENABLE \
  --cmd-len=65536 \
  --hash \
  --genfds-multi-thread

but it failed with:

> OvmfPkg/OvmfPkgIa32.dsc(...): error 4000: Instance of library class 
> [MmServicesTableLib] is not found
> in 
> [MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf] 
> [IA32]
> consumed by module 
> [MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf]

You did mention earlier that adding new lib class resolutions to several
x86 DSC files would be necessary, so this is not unexpected. Can you
please insert such a patch for OvmfPkg between patches #2 and #3?

I've looked at the current OVMF DSC files, and SmmServicesTableLib is
resolved for two module types,

> [LibraryClasses.common.DXE_SMM_DRIVER]
>   
> SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
>
> [LibraryClasses.common.SMM_CORE]
>   
> SmmServicesTableLib|MdeModulePkg/Library/PiSmmCoreSmmServicesTableLib/PiSmmCoreSmmServicesTableLib.inf

I assume it should be enough, for this series, to update the
DXE_SMM_DRIVER resolution only, and to leave SMM_CORE alone.

(Because, my understanding is that the current, x86 specific

  MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf

module, of type SMM_CORE, will not be refactored; instead, it is
entirely supplanted -- in the affected platforms -- by the

  StandaloneMmPkg/Core/StandaloneMmCore.inf

module, which is of type MM_CORE_STANDALONE.)

But, it's still not clear to me (without trying) whether I should
resolve MmServicesTableLib  for DXE_SMM_DRIVER in addition to
SmmServicesTableLib, or in its place. I'd prefer not experimenting with
this myself; I'd just like to apply the series, and build & test it. :)

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

[edk2] [PATCH v1] ShellPkg/TftpDynamicCommand: Change file writing method in tftp

[Songpeng Li]

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

Current logic of shell tftp download was writing file after tftp
download finished, when the file is large, it looks like the shell
tftp command hanged after download was finished. To improve
end-user experience, the solution is using split file writing
instead.

This patch update the code to open and close file inside
DownloadFile(), and save each packet to file within callback
function CheckPacket().

Since AllocatePage() is no-longer needed, This patch can also
remove the memory limitation. The download file can be larger
than system free memory now.

Cc: Jaben Carsey 
Cc: Ruiyu Ni 
Cc: Wu Jiaxin 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Songpeng Li 
---
 ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c | 152 +---
 1 file changed, 64 insertions(+), 88 deletions(-)

diff --git a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c 
b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
index ed081b5bad7c..a53fe16f0683 100644
--- a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
+++ b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
@@ -41,6 +41,12 @@ STATIC CONST CHAR16 mTftpProgressFrame[] = L"[
 // (TFTP_PROGRESS_MESSAGE_SIZE-1) '\b'
 STATIC CONST CHAR16 mTftpProgressDelete[] = 
L"\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b";
 
+// Local File Handle
+SHELL_FILE_HANDLE mFileHandle;
+
+// Path of the local file, Unicode encoded
+CONST CHAR16 *mLocalFilePath;
+
 /**
   Check and convert the UINT16 option values of the 'tftp' command
 
@@ -166,9 +172,6 @@ GetFileSize (
   @param[in]   FileSize   Size of the file in number of bytes
   @param[in]   BlockSize  Value of the TFTP blksize option
   @param[in]   WindowSize Value of the TFTP window size option
-  @param[out]  Data   Address where to store the address of the buffer
-  where the data of the file were downloaded in
-  case of success.
 
   @retval  EFI_SUCCESS   The file was downloaded.
   @retval  EFI_OUT_OF_RESOURCES  A memory allocation failed.
@@ -184,8 +187,7 @@ DownloadFile (
   IN   CONST CHAR8  *AsciiFilePath,
   IN   UINTNFileSize,
   IN   UINT16   BlockSize,
-  IN   UINT16   WindowSize,
-  OUT  VOID **Data
+  IN   UINT16   WindowSize
   );
 
 /**
@@ -287,7 +289,6 @@ RunTftp (
   CHAR8   *AsciiRemoteFilePath;
   UINTN   FilePathSize;
   CONST CHAR16*Walker;
-  CONST CHAR16*LocalFilePath;
   EFI_MTFTP4_CONFIG_DATA  Mtftp4ConfigData;
   EFI_HANDLE  *Handles;
   UINTN   HandleCount;
@@ -297,9 +298,7 @@ RunTftp (
   EFI_HANDLE  Mtftp4ChildHandle;
   EFI_MTFTP4_PROTOCOL *Mtftp4;
   UINTN   FileSize;
-  UINTN   DataSize;
   VOID*Data;
-  SHELL_FILE_HANDLE   FileHandle;
   UINT16  BlockSize;
   UINT16  WindowSize;
 
@@ -309,7 +308,6 @@ RunTftp (
   AsciiRemoteFilePath = NULL;
   Handles = NULL;
   FileSize= 0;
-  DataSize= 0;
   BlockSize   = MTFTP_DEFAULT_BLKSIZE;
   WindowSize  = MTFTP_DEFAULT_WINDOWSIZE;
 
@@ -385,7 +383,7 @@ RunTftp (
   UnicodeStrToAsciiStrS (RemoteFilePath, AsciiRemoteFilePath, FilePathSize);
 
   if (ParamCount == 4) {
-LocalFilePath = ShellCommandLineGetRawValue (CheckPackage, 3);
+mLocalFilePath = ShellCommandLineGetRawValue (CheckPackage, 3);
   } else {
 Walker = RemoteFilePath + StrLen (RemoteFilePath);
 while ((--Walker) >= RemoteFilePath) {
@@ -394,7 +392,7 @@ RunTftp (
 break;
   }
 }
-LocalFilePath = Walker + 1;
+mLocalFilePath = Walker + 1;
   }
 
   //
@@ -543,7 +541,7 @@ RunTftp (
   goto NextHandle;
 }
 
-Status = DownloadFile (Mtftp4, RemoteFilePath, AsciiRemoteFilePath, 
FileSize, BlockSize, WindowSize, );
+Status = DownloadFile (Mtftp4, RemoteFilePath, AsciiRemoteFilePath, 
FileSize, BlockSize, WindowSize);
 if (EFI_ERROR (Status)) {
   ShellPrintHiiEx (
 -1, -1, NULL, STRING_TOKEN (STR_TFTP_ERR_DOWNLOAD),
@@ -552,45 +550,8 @@ RunTftp (
   goto NextHandle;
 }
 
-DataSize = FileSize;
-
-if (!EFI_ERROR (ShellFileExists (LocalFilePath))) {
-  ShellDeleteFileByName (LocalFilePath);
-}
-
-Status = ShellOpenFileByName (
-   LocalFilePath,
-   ,
-   EFI_FILE_MODE_CREATE |
-   EFI_FILE_MODE_WRITE  |
-   EFI_FILE_MODE_READ,
-   0
-   );
-if (EFI_ERROR (Status)) {
-  ShellPrintHiiEx (
--1, -1, NULL, STRING_TOKEN (STR_GEN_FILE_OPEN_FAIL),
-mTftpHiiHandle, L"tftp", LocalFilePath
-  );
-  goto NextHandle;
-}
-
-Status = ShellWriteFile 

[edk2] [Patch 3/3 V2] BaseTools: Remove unused ECP related code from C tools

[BobCF]

From: "Feng, Bob C" 

https://bugzilla.tianocore.org/show_bug.cgi?id=1350
Remove ECP support from BaseTools C code.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng 
Cc: Liming Gao 
Cc: Jaben Carsey 
---
 BaseTools/Source/C/Include/IndustryStandard/pci22.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/BaseTools/Source/C/Include/IndustryStandard/pci22.h 
b/BaseTools/Source/C/Include/IndustryStandard/pci22.h
index d7c5f0c858..873ce69094 100644
--- a/BaseTools/Source/C/Include/IndustryStandard/pci22.h
+++ b/BaseTools/Source/C/Include/IndustryStandard/pci22.h
@@ -178,11 +178,10 @@ typedef struct {
 #define PCI_IF_16850  0x05
 #define PCI_IF_16950  0x06
 #define PCI_SUBCLASS_PARALLEL 0x01
 #define PCI_IF_PARALLEL_PORT  0x00
 #define PCI_IF_BI_DIR_PARALLEL_PORT   0x01
-#define PCI_IF_ECP_PARALLEL_PORT  0x02
 #define PCI_IF_1284_CONTROLLER0x03
 #define PCI_IF_1284_DEVICE0xFE
 #define PCI_SUBCLASS_MULTIPORT_SERIAL 0x02
 #define PCI_SUBCLASS_MODEM0x03
 #define PCI_IF_GENERIC_MODEM  0x00
-- 
2.19.1.windows.1

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

[edk2] [Patch 3/3 V2] BaseTools: Remove unused logic from C tools

[BobCF]

From: "Feng, Bob C" 

https://bugzilla.tianocore.org/show_bug.cgi?id=1350
Remove IA64 support from BaseTools C code.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng 
Cc: Liming Gao 
Cc: Jaben Carsey 
---
 BaseTools/Source/C/Common/BasePeCoff.c|  14 +-
 BaseTools/Source/C/Common/PeCoffLoaderEx.c| 162 +-
 BaseTools/Source/C/EfiRom/EfiRom.h|   3 +-
 BaseTools/Source/C/GenFv/GenFvInternalLib.c   |  72 +---
 BaseTools/Source/C/GenFv/GenFvInternalLib.h   |  10 --
 BaseTools/Source/C/GenFw/Elf64Convert.c   |   5 -
 BaseTools/Source/C/GenFw/GenFw.c  |   6 +-
 BaseTools/Source/C/GenFw/elf_common.h |  85 -
 .../C/Include/IndustryStandard/PeImage.h  |   3 -
 BaseTools/Source/C/Makefiles/header.makefile  |   1 -
 BaseTools/Source/C/VolInfo/VolInfo.c  |   2 +-
 11 files changed, 10 insertions(+), 353 deletions(-)

diff --git a/BaseTools/Source/C/Common/BasePeCoff.c 
b/BaseTools/Source/C/Common/BasePeCoff.c
index 1d89a300de..d5cefbd0b0 100644
--- a/BaseTools/Source/C/Common/BasePeCoff.c
+++ b/BaseTools/Source/C/Common/BasePeCoff.c
@@ -54,17 +54,10 @@ PeCoffLoaderRelocateIa32Image (
   IN OUT CHAR8   *Fixup,
   IN OUT CHAR8   **FixupData,
   IN UINT64  Adjust
   );
 
-RETURN_STATUS
-PeCoffLoaderRelocateIpfImage (
-  IN UINT16  *Reloc,
-  IN OUT CHAR8   *Fixup,
-  IN OUT CHAR8   **FixupData,
-  IN UINT64  Adjust
-  );
 
 RETURN_STATUS
 PeCoffLoaderRelocateArmImage (
   IN UINT16  **Reloc,
   IN OUT CHAR8   *Fixup,
@@ -182,11 +175,10 @@ Returns:
   } else {
 ImageContext->Machine = TeHdr->Machine;
   }
 
   if (ImageContext->Machine != EFI_IMAGE_MACHINE_IA32 && \
-  ImageContext->Machine != EFI_IMAGE_MACHINE_IA64 && \
   ImageContext->Machine != EFI_IMAGE_MACHINE_X64  && \
   ImageContext->Machine != EFI_IMAGE_MACHINE_ARMT && \
   ImageContext->Machine != EFI_IMAGE_MACHINE_EBC  && \
   ImageContext->Machine != EFI_IMAGE_MACHINE_AARCH64) {
 if (ImageContext->Machine == IMAGE_FILE_MACHINE_ARM) {
@@ -814,13 +806,10 @@ Returns:
   Status = PeCoffLoaderRelocateIa32Image (Reloc, Fixup, , 
Adjust);
   break;
 case EFI_IMAGE_MACHINE_ARMT:
   Status = PeCoffLoaderRelocateArmImage (, Fixup, , 
Adjust);
   break;
-case EFI_IMAGE_MACHINE_IA64:
-  Status = PeCoffLoaderRelocateIpfImage (Reloc, Fixup, , 
Adjust);
-  break;
 default:
   Status = RETURN_UNSUPPORTED;
   break;
 }
 if (RETURN_ERROR (Status)) {
@@ -1317,13 +1306,12 @@ PeCoffLoaderGetPdbPointer (
   // Assume PE32 image with IA32 Machine field.
   //
   Magic = EFI_IMAGE_NT_OPTIONAL_HDR32_MAGIC;
   break;
 case EFI_IMAGE_MACHINE_X64:
-case EFI_IMAGE_MACHINE_IPF:
   //
-  // Assume PE32+ image with X64 or IPF Machine field
+  // Assume PE32+ image with X64 Machine field
   //
   Magic = EFI_IMAGE_NT_OPTIONAL_HDR64_MAGIC;
   break;
 default:
   //
diff --git a/BaseTools/Source/C/Common/PeCoffLoaderEx.c 
b/BaseTools/Source/C/Common/PeCoffLoaderEx.c
index 2d9a2a8978..fa8c7e3d17 100644
--- a/BaseTools/Source/C/Common/PeCoffLoaderEx.c
+++ b/BaseTools/Source/C/Common/PeCoffLoaderEx.c
@@ -1,7 +1,7 @@
 /** @file
-IA32, X64 and IPF Specific relocation fixups
+IA32 and X64 Specific relocation fixups
 
 Copyright (c) 2004 - 2018, Intel Corporation. All rights reserved.
 Portions Copyright (c) 2011 - 2013, ARM Ltd. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
@@ -97,170 +97,10 @@ Returns:
 --*/
 {
   return RETURN_UNSUPPORTED;
 }
 
-RETURN_STATUS
-PeCoffLoaderRelocateIpfImage (
-  IN UINT16  *Reloc,
-  IN OUT CHAR8   *Fixup,
-  IN OUT CHAR8   **FixupData,
-  IN UINT64  Adjust
-  )
-/*++
-
-Routine Description:
-
-  Performs an Itanium-based specific relocation fixup
-
-Arguments:
-
-  Reloc  - Pointer to the relocation record
-
-  Fixup  - Pointer to the address to fix up
-
-  FixupData  - Pointer to a buffer to log the fixups
-
-  Adjust - The offset to adjust the fixup
-
-Returns:
-
-  Status code
-
---*/
-{
-  UINT64  *F64;
-  UINT64  FixupVal;
-
-  switch ((*Reloc) >> 12) {
-
-case EFI_IMAGE_REL_BASED_IA64_IMM64:
-
-  //
-  // Align it to bundle address before fixing up the
-  // 64-bit immediate value of the movl instruction.
-  //
-
-  Fixup = (CHAR8 *)((UINTN) Fixup & (UINTN) ~(15));
-  FixupVal = (UINT64)0;
-
-  //
-  // Extract the lower 32 bits of IMM64 from bundle
-  //
-  EXT_IMM64(FixupVal,
-(UINT32 *)Fixup + IMM64_IMM7B_INST_WORD_X,
-IMM64_IMM7B_SIZE_X,
-IMM64_IMM7B_INST_WORD_POS_X,
-IMM64_IMM7B_VAL_POS_X
-);
-
-  EXT_IMM64(FixupVal,
-(UINT32 *)Fixup + IMM64_IMM9D_INST_WORD_X,
-   

Re: [edk2] [Patch v1 1/1] BaseTools: fix imports

[Feng, Bob C]

Hi Jaben,

I have a minor comment

In GenFds, The following code is duplicated within GenFds.py
+from re import compile

Thanks,
Bob


-Original Message-
From: Carsey, Jaben 
Sent: Wednesday, January 9, 2019 7:00 AM
To: edk2-devel@lists.01.org
Cc: Feng, Bob C ; Gao, Liming 
Subject: [Patch v1 1/1] BaseTools: fix imports

1 - Some of these imports are cascaded from another file. Import them locally.
2 - Some of these imports are not used. Remove them.
3 - Some of these were missing the namespace used to import them.

These changes facilitate optimization of BaseTools:
https://bugzilla.tianocore.org/show_bug.cgi?id=42

Cc: Bob Feng 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jaben Carsey 
---
 BaseTools/Source/Python/AutoGen/AutoGen.py  |  6 ++
 BaseTools/Source/Python/AutoGen/GenC.py |  2 +-
 BaseTools/Source/Python/AutoGen/GenPcdDb.py |  3 +++
 BaseTools/Source/Python/Common/RangeExpression.py   |  3 ++-
 BaseTools/Source/Python/Common/ToolDefClassObject.py|  4 ++--
 BaseTools/Source/Python/Ecc/MetaFileWorkspace/MetaFileParser.py |  4 ++--
 BaseTools/Source/Python/GenFds/FdfParser.py |  4 ++--
 BaseTools/Source/Python/GenFds/FfsInfStatement.py   |  3 ++-
 BaseTools/Source/Python/GenFds/GenFds.py|  1 +
 BaseTools/Source/Python/GenFds/GuidSection.py   |  1 -
 BaseTools/Source/Python/Workspace/DecBuildData.py   |  9 ++---
 BaseTools/Source/Python/Workspace/DscBuildData.py   |  4 ++--
 BaseTools/Source/Python/Workspace/MetaFileParser.py |  9 +
 BaseTools/Source/Python/build/build.py  | 16 

 14 files changed, 38 insertions(+), 31 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py 
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index d646cd50ce8e..acd34692b6c2 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -1,7 +1,7 @@
 ## @file
 # Generate AutoGen.h, AutoGen.c and *.depex files  # -# Copyright (c) 2007 - 
2018, Intel Corporation. All rights reserved.
+# Copyright (c) 2007 - 2019, Intel Corporation. All rights 
+reserved.
 # Copyright (c) 2018, Hewlett Packard Enterprise Development, L.P.  #  # 
This program and the accompanying materials @@ -52,6 +52,7 @@ from .GenVar 
import VariableMgr, var_info  from collections import OrderedDict  from 
collections import defaultdict  from Workspace.WorkspaceCommon import 
OrderedListDict
+from Common.ToolDefClassObject import gDefaultToolsDefFile
 
 from Common.caching import cached_property, cached_class_function
 
@@ -85,9 +86,6 @@ gMakeTypeMap = {TAB_COMPILER_MSFT:"nmake", "GCC":"gmake"}  ## 
Build rule configuration file  gDefaultBuildRuleFile = 'build_rule.txt'
 
-## Tools definition configuration file
-gDefaultToolsDefFile = 'tools_def.txt'
-
 ## Build rule default version
 AutoGenReqBuildRuleVerNum = "0.1"
 
diff --git a/BaseTools/Source/Python/AutoGen/GenC.py 
b/BaseTools/Source/Python/AutoGen/GenC.py
index 09626d0b9610..e224568db1ed 100644
--- a/BaseTools/Source/Python/AutoGen/GenC.py
+++ b/BaseTools/Source/Python/AutoGen/GenC.py
@@ -18,7 +18,7 @@ import string
 import collections
 import struct
 from Common import EdkLogger
-
+from Common import GlobalData
 from Common.BuildToolError import *
 from Common.DataType import *
 from Common.Misc import *
diff --git a/BaseTools/Source/Python/AutoGen/GenPcdDb.py 
b/BaseTools/Source/Python/AutoGen/GenPcdDb.py
index 876fcf1efb8a..a9068d2d7a86 100644
--- a/BaseTools/Source/Python/AutoGen/GenPcdDb.py
+++ b/BaseTools/Source/Python/AutoGen/GenPcdDb.py
@@ -22,6 +22,9 @@ from Common.VariableAttributes import VariableAttributes  
import copy  from struct import unpack  from Common.DataType import *
+from Common import GlobalData
+from Common import EdkLogger
+import Common.LongFilePathOs as os
 
 DATABASE_VERSION = 7
 
diff --git a/BaseTools/Source/Python/Common/RangeExpression.py 
b/BaseTools/Source/Python/Common/RangeExpression.py
index 407dc06ccf0b..40958451d286 100644
--- a/BaseTools/Source/Python/Common/RangeExpression.py
+++ b/BaseTools/Source/Python/Common/RangeExpression.py
@@ -19,6 +19,7 @@ from CommonDataClass.Exceptions import WrnExpression  import 
uuid  from Common.Expression import PcdPattern, BaseExpression  from 
Common.DataType import *
+from re import compile
 
 ERR_STRING_EXPR = 'This operator cannot be used in string expression: [%s].'
 ERR_SNYTAX = 'Syntax error, the rest of expression cannot be evaluated: [%s].'
@@ -202,7 +203,7 @@ class RangeExpression(BaseExpression):
 
 NonLetterOpLst = ['+', '-', '&', '|', '^', '!', '=', '>', '<']
 
-RangePattern = re.compile(r'[0-9]+ - [0-9]+')
+RangePattern = compile(r'[0-9]+ - [0-9]+')
 
 def preProcessRangeExpr(self, expr):
 # convert hex to int
diff --git