Re: [edk2] [patch] UefiCpuPkg/PiSmmCpuDxeSmm: Add "extern" keyword for "gPatchxxx"

[Kinney, Michael D]

Laszlo,

I think I would rather see the ECC tool fixed.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Laszlo Ersek
> Sent: Thursday, April 12, 2018 2:34 AM
> To: Bi, Dandan ; edk2-
> de...@lists.01.org
> Cc: Dong, Eric 
> Subject: Re: [edk2] [patch] UefiCpuPkg/PiSmmCpuDxeSmm:
> Add "extern" keyword for "gPatchxxx"
> 
> Hello Dandan,
> 
> On 04/12/18 10:50, Dandan Bi wrote:
> > Background description:
> > In SmmProfileInternal.h, ECC check tool report an
> issue at line 103.
> > Detailed ECC Error info:Variable definition appears
> in header file.
> > Include files should contain only public or only
> private data and
> > cannot contain code or define data variables
> >
> > ECC report similar issues in PiSmmCpuDxeSmm.h.
> >
> > Then we review all the new introduced "gPatchxxx",
> since they have
> > been defined in the nasm file, we can add "extern"
> keyword for them
> > in the C source or header files.
> >
> > Cc: Eric Dong 
> > Cc: Laszlo Ersek 
> > Contributed-under: TianoCore Contribution Agreement
> 1.1
> > Signed-off-by: Dandan Bi 
> > ---
> >  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h | 8
> 
> >  UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfileInternal.h | 2
> +-
> >  UefiCpuPkg/PiSmmCpuDxeSmm/SmramSaveState.c | 6
> +++---
> >  UefiCpuPkg/PiSmmCpuDxeSmm/X64/Semaphore.c  | 4
> ++--
> >  4 files changed, 10 insertions(+), 10 deletions(-)
> 
> This is a bug (a false positive) in the ECC tool. The
> following
> declaration:
> 
> > X86_ASSEMBLY_PATCH_LABELgPatchSmmCr0;
> 
> does not declare an *object* (a variable). Instead, it
> declares a
> *function* (and not a pointer to a function!), because
> (from
> "MdePkg/Include/Library/BaseLib.h"):
> 
> > ///
> > /// Type definition for representing labels in NASM
> source code that allow for
> > /// the patching of immediate operands of IA32 and
> X64 instructions.
> > ///
> > /// While the type is technically defined as a
> function type (note: not a
> > /// pointer-to-function type), such labels in NASM
> source code never stand for
> > /// actual functions, and identifiers declared with
> this function type should
> > /// never be called. This is also why the EFIAPI
> calling convention specifier
> > /// is missing from the typedef, and why the typedef
> does not follow the usual
> > /// edk2 coding style for function (or pointer-to-
> function) typedefs. The VOID
> > /// return type and the VOID argument list are merely
> artifacts.
> > ///
> > typedef VOID (X86_ASSEMBLY_PATCH_LABEL) (VOID);
> 
> That is, when you see
> 
> > X86_ASSEMBLY_PATCH_LABELgPatchSmmCr0;
> 
> That is identical to the following function
> declaration:
> 
> > VOID gPatchSmmCr0 (VOID);
> 
> Now, the ISO C99 standard says:
> 
> > 6.2.2 Linkages of identifiers
> >
> > [...]
> >
> >   5 If the declaration of an identifier for a
> function has no
> > storage-class specifier, its linkage is
> determined exactly as if
> > it were declared with the storage-class specifier
> /extern/. [...]
> 
> Thus, the report from ECC is a false positive.
> 
> I don't mind the patch (the changes don't make any
> difference at the
> C-language level, see the spec above); however, the
> commit message
> should be 100% clear that the patch works around a
> limitation with the
> ECC tool.
> 
> Can you please submit v2 with an updated commit
> message?
> 
> 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] MdePkg: add big-endian MMIO BaseBeIoLib

[Kinney, Michael D]

Hi Leif,

I think we need to look at the names.  I see a mix of
"Be" and "Swap".  We should pick one and use it 
consistently.

Mike

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Friday, April 13, 2018 10:42 AM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>;
> Gao, Liming <liming@intel.com>; Laszlo Ersek
> <ler...@redhat.com>; udit.ku...@nxp.com
> Subject: [PATCH] MdePkg: add big-endian MMIO
> BaseBeIoLib
> 
> When performing MMIO to a destination of the opposite
> endianness to the
> executing processor, this library provides automatic
> byte order reversal
> on inputs and outputs.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Leif Lindholm <leif.lindh...@linaro.org>
> ---
> 
> Udit, many apologies for this dragging out - back-to-
> back conferences,
> holidays, and lots of catching up.
> 
> This modified version introduces a single BeIoLib
> instance, backed by
> a source-file that could be used also for a
> hypothetical LeIoLib.
> There is no LeIoLib.h included though.
> 
> While this is arguably overengineered, I do feel
> reasonably strongly
> that code should be named for what it does, not for how
> it is used,
> and doing it this way lets me follow that rule.
> 
> I have not duplicated the .uni file together with the
> .inf, since
> this follows what is done in BaseIoLibIntrinsic.
> 
>  MdePkg/Include/Library/BeIoLib.h   | 376
> +++
>  MdePkg/Library/BaseIoLibSwap/BaseBeIoLib.inf   |  48
> +++
>  MdePkg/Library/BaseIoLibSwap/BaseIoLibSwap.uni |  23
> ++
>  MdePkg/Library/BaseIoLibSwap/IoLibSwap.c   | 477
> +
>  MdePkg/MdePkg.dec  |   3 +
>  5 files changed, 927 insertions(+)
>  create mode 100644 MdePkg/Include/Library/BeIoLib.h
>  create mode 100644
> MdePkg/Library/BaseIoLibSwap/BaseBeIoLib.inf
>  create mode 100644
> MdePkg/Library/BaseIoLibSwap/BaseIoLibSwap.uni
>  create mode 100644
> MdePkg/Library/BaseIoLibSwap/IoLibSwap.c
> 
> diff --git a/MdePkg/Include/Library/BeIoLib.h
> b/MdePkg/Include/Library/BeIoLib.h
> new file mode 100644
> index 00..5b2dc1a8e1
> --- /dev/null
> +++ b/MdePkg/Include/Library/BeIoLib.h
> @@ -0,0 +1,376 @@
> +/** @file
> +  Provide byte-swapping services to access MMIO
> registers.
> +
> +Copyright (c) 2006 - 2012, Intel Corporation. All
> rights reserved.
> +Copyright (c) 2017, AMD Incorporated. 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.
> +
> +**/
> +
> +#ifndef __BE_IO_LIB_H__
> +#define __BE_IO_LIB_H__
> +
> +/**
> +  Reads a 16-bit MMIO register of opposite endianness.
> +
> +  Reads the 16-bit MMIO register specified by Address.
> +  The 16-bit read value is returned in reversed byte
> order.
> +  This function must guarantee that all MMIO read and
> write
> +  operations are serialized.
> +
> +  @param  Address The MMIO register to read.
> +
> +  @return The value read.
> +
> +**/
> +UINT16
> +EFIAPI
> +BeMmioRead16 (
> +  IN  UINTN Address
> +  );
> +
> +/**
> +  Writes a 16-bit MMIO register of opposite
> endianness.
> +
> +  Writes the 16-bit MMIO register specified by Address
> with the byte-reversed
> +  version of the value specified by Value and returns
> the original Value.
> +  This function must guarantee that all MMIO read and
> write
> +  operations are serialized.
> +
> +  @param  Address The MMIO register to write.
> +  @param  Value   The value to write to the MMIO
> register.
> +
> +  @return Value.
> +
> +**/
> +UINT16
> +EFIAPI
> +BeMmioWrite16 (
> +  IN  UINTN Address,
> +  IN  UINT16Value
> +  );
> +
> +/**
> +  Reads a 16-bit MMIO register of opposite endianness,
> performs a bitwise OR,
> +  and writes the result back to the 16-bit MMIO
> register.
> +
> +  Reads the 16-bit MMIO register specified by Address,
> byte-reverses the read
> +  result, performs a bitwise OR between the read
> result and th

Re: [edk2] [PATCH] MdePkg: add big-endian MMIO BaseBeIoLib

[Kinney, Michael D]

Leif,

I am curious why a Swap class/instances is not sufficient.

Currently EDK II follows the UEFI/PI specs, which for
all supported CPU architectures use little endian ABI.
The BaseIoLib follows the endianness of the CPU.  If
UEFI/PI added a CPU that was big endian, I would expect
BaseIoLib when built for that CPU would perform big endian
operations.

Am I missing something?

Mike


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Leif Lindholm
> Sent: Friday, April 13, 2018 12:32 PM
> To: Kinney, Michael D <michael.d.kin...@intel.com>
> Cc: edk2-devel@lists.01.org; Laszlo Ersek
> <ler...@redhat.com>; Gao, Liming <liming@intel.com>
> Subject: Re: [edk2] [PATCH] MdePkg: add big-endian MMIO
> BaseBeIoLib
> 
> On Fri, Apr 13, 2018 at 07:24:06PM +, Kinney,
> Michael D wrote:
> > Hi Leif,
> >
> > I think we need to look at the names.  I see a mix of
> > "Be" and "Swap".  We should pick one and use it
> > consistently.
> 
> This was what I meant by the comments:
> ---
> This modified version introduces a single BeIoLib
> instance, backed by
> a source-file that could be used also for a
> hypothetical LeIoLib.
> There is no LeIoLib.h included though.
> 
> While this is arguably overengineered, I do feel
> reasonably strongly
> that code should be named for what it does, not for how
> it is used,
> and doing it this way lets me follow that rule.
> ---
> 
> Clearly this is open for discussion, but the above is
> my opinion and
> the code intentionally reflects that.
> 
> Regards,
> 
> Leif
> 
> > Mike
> >
> > > -Original Message-
> > > From: Leif Lindholm
> [mailto:leif.lindh...@linaro.org]
> > > Sent: Friday, April 13, 2018 10:42 AM
> > > To: edk2-devel@lists.01.org
> > > Cc: Kinney, Michael D <michael.d.kin...@intel.com>;
> > > Gao, Liming <liming@intel.com>; Laszlo Ersek
> > > <ler...@redhat.com>; udit.ku...@nxp.com
> > > Subject: [PATCH] MdePkg: add big-endian MMIO
> > > BaseBeIoLib
> > >
> > > When performing MMIO to a destination of the
> opposite
> > > endianness to the
> > > executing processor, this library provides
> automatic
> > > byte order reversal
> > > on inputs and outputs.
> > >
> > > Contributed-under: TianoCore Contribution Agreement
> 1.1
> > > Signed-off-by: Leif Lindholm
> <leif.lindh...@linaro.org>
> > > ---
> > >
> > > Udit, many apologies for this dragging out - back-
> to-
> > > back conferences,
> > > holidays, and lots of catching up.
> > >
> > > This modified version introduces a single BeIoLib
> > > instance, backed by
> > > a source-file that could be used also for a
> > > hypothetical LeIoLib.
> > > There is no LeIoLib.h included though.
> > >
> > > While this is arguably overengineered, I do feel
> > > reasonably strongly
> > > that code should be named for what it does, not for
> how
> > > it is used,
> > > and doing it this way lets me follow that rule.
> > >
> > > I have not duplicated the .uni file together with
> the
> > > .inf, since
> > > this follows what is done in BaseIoLibIntrinsic.
> > >
> > >  MdePkg/Include/Library/BeIoLib.h   |
> 376
> > > +++
> > >  MdePkg/Library/BaseIoLibSwap/BaseBeIoLib.inf   |
> 48
> > > +++
> > >  MdePkg/Library/BaseIoLibSwap/BaseIoLibSwap.uni |
> 23
> > > ++
> > >  MdePkg/Library/BaseIoLibSwap/IoLibSwap.c   |
> 477
> > > +
> > >  MdePkg/MdePkg.dec  |
> 3 +
> > >  5 files changed, 927 insertions(+)
> > >  create mode 100644
> MdePkg/Include/Library/BeIoLib.h
> > >  create mode 100644
> > > MdePkg/Library/BaseIoLibSwap/BaseBeIoLib.inf
> > >  create mode 100644
> > > MdePkg/Library/BaseIoLibSwap/BaseIoLibSwap.uni
> > >  create mode 100644
> > > MdePkg/Library/BaseIoLibSwap/IoLibSwap.c
> > >
> > > diff --git a/MdePkg/Include/Library/BeIoLib.h
> > > b/MdePkg/Include/Library/BeIoLib.h
> > > new file mode 100644
> > > index 00..5b2dc1a8e1
> > > --- /dev/null
> > > +++ b/MdePkg/Include/Library/BeIoLib.h
> > > @@ -0,0 +1,376 @@
> > > +/** @file
> > > +  Provide byte-swapping services to access MMIO
> > > registers.
> >

[edk2] [Patch 1/2] SignedCapsulePkg/SystemFirmwareUpdateDxe: Single FMP

[Kinney, Michael D]

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

Uninstall all System FMP Protocols for the current FW device.

If an FMP Protocol for the current FW device is already present,
then install the new System FMP protocol onto the same handle as
the FMP Protocol.  Otherwise, install the FMP protocol onto a
new handle.

This supports use cases where multiple capsules for the
same system firmware device are processed on the same
boot of the platform.  It guarantees there is at most one
FMP protocol for each system firmware device.

Cc: Jiewen Yao 
Signed-off-by: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
---
 .../SystemFirmwareUpdate/SystemFirmwareUpdateDxe.c | 343 +++--
 1 file changed, 322 insertions(+), 21 deletions(-)

diff --git 
a/SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareUpdateDxe.c 
b/SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareUpdateDxe.c
index fd6641eb3e..d0b1c9913c 100644
--- a/SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareUpdateDxe.c
+++ b/SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareUpdateDxe.c
@@ -8,7 +8,7 @@
 
   FmpSetImage() will receive untrusted input and do basic validation.
 
-  Copyright (c) 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2016 - 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
@@ -476,54 +476,355 @@ FmpSetImage (
   return Status;
 }
 
+/**
+  Get the set of EFI_FIRMWARE_IMAGE_DESCRIPTOR structures from an FMP Protocol.
+
+  @param[in]  Handle Handle with an FMP Protocol or a System FMP
+ Protocol.
+  @param[in]  ProtocolGuid   Pointer to the FMP Protocol GUID or System FMP
+ Protocol GUID.
+  @param[out] FmpImageInfoCount  Pointer to the number of
+ EFI_FIRMWARE_IMAGE_DESCRIPTOR structures.
+  @param[out] DescriptorSize Pointer to the size, in bytes, of each
+ EFI_FIRMWARE_IMAGE_DESCRIPTOR structure.
+
+  @return NULL   No EFI_FIRMWARE_IMAGE_DESCRIPTOR structures found.
+  @return !NULL  Pointer to a buffer of EFI_FIRMWARE_IMAGE_DESCRIPTOR 
structures
+ allocated using AllocatePool().  Caller must free buffer with
+ FreePool().
+**/
+EFI_FIRMWARE_IMAGE_DESCRIPTOR *
+GetFmpImageDescriptors (
+  IN  EFI_HANDLE  Handle,
+  IN  EFI_GUID*ProtocolGuid,
+  OUT UINT8   *FmpImageInfoCount,
+  OUT UINTN   *DescriptorSize
+  )
+{
+  EFI_STATUSStatus;
+  EFI_FIRMWARE_MANAGEMENT_PROTOCOL  *Fmp;
+  UINTN ImageInfoSize;
+  EFI_FIRMWARE_IMAGE_DESCRIPTOR *FmpImageInfoBuf;
+  UINT32FmpImageInfoDescriptorVer;
+  UINT32PackageVersion;
+  CHAR16*PackageVersionName;
+
+  *FmpImageInfoCount = 0;
+  *DescriptorSize= 0;
+
+  Status = gBS->HandleProtocol (
+  Handle,
+  ProtocolGuid,
+  (VOID **)
+  );
+  if (EFI_ERROR (Status)) {
+return NULL;
+  }
+
+  //
+  // Determine the size required for the set of EFI_FIRMWARE_IMAGE_DESCRIPTORs.
+  //
+  ImageInfoSize = 0;
+  Status = Fmp->GetImageInfo (
+  Fmp, // FMP Pointer
+  ,  // Buffer Size (in this case 0)
+  NULL,// NULL so we can get size
+  ,  // DescriptorVersion
+  FmpImageInfoCount,   // DescriptorCount
+  DescriptorSize,  // DescriptorSize
+  , // PackageVersion
+// PackageVersionName
+  );
+  if (Status != EFI_BUFFER_TOO_SMALL) {
+DEBUG ((DEBUG_ERROR, "SystemFirmwareUpdateDxe: Unexpected Failure.  Status 
= %r\n", Status));
+return NULL;
+  }
+
+  //
+  // Allocate buffer for the set of EFI_FIRMWARE_IMAGE_DESCRIPTORs.
+  //
+  FmpImageInfoBuf = NULL;
+  FmpImageInfoBuf = AllocateZeroPool (ImageInfoSize);
+  if (FmpImageInfoBuf == NULL) {
+DEBUG ((DEBUG_ERROR, "SystemFirmwareUpdateDxe: Failed to allocate memory 
for descriptors.\n"));
+return NULL;
+  }
+
+  //
+  // Retrieve the set of EFI_FIRMWARE_IMAGE_DESCRIPTORs.
+  //
+  PackageVersionName = NULL;
+  Status = Fmp->GetImageInfo (
+  Fmp,
+  ,  // ImageInfoSize
+  FmpImageInfoBuf, // ImageInfo
+  ,  // DescriptorVersion
+  FmpImageInfoCount,   // DescriptorCount
+  DescriptorSize,  // DescriptorSize

[edk2] [Patch 0/2] SignedCapsulePkg/SystemFirmwareUpdate:

[Kinney, Michael D]

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

* SystemFirmwareReportDxe: Only looks for System FMP Protocol on same handle
  as FMP Protocol
* SystemFirmwareUpdateDxe: Do not allow multiple FMP Protocols to be installed
  for the same system firmware device.

Cc: Jiewen Yao <jiewen@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kin...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1

Kinney, Michael D (2):
  SignedCapsulePkg/SystemFirmwareUpdateDxe: Single FMP
  SignedCapsulePkg/SystemFirmwareReportDxe: Pass thru on same handle

 .../SystemFirmwareUpdate/SystemFirmwareReportDxe.c |  10 +-
 .../SystemFirmwareUpdate/SystemFirmwareUpdateDxe.c | 343 +++--
 2 files changed, 329 insertions(+), 24 deletions(-)

-- 
2.14.2.windows.3

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

[edk2] [Patch 2/2] SignedCapsulePkg/SystemFirmwareReportDxe: Pass thru on same handle

[Kinney, Michael D]

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

Use HandleProtocol() to pass thru a SetImage() call to the
System FMP Protocol that must be on the same handle as the
FMP Protocol.

Cc: Jiewen Yao 
Signed-off-by: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
---
 .../Universal/SystemFirmwareUpdate/SystemFirmwareReportDxe.c   | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git 
a/SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareReportDxe.c 
b/SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareReportDxe.c
index f5f9827c77..e750e5d4ce 100644
--- a/SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareReportDxe.c
+++ b/SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareReportDxe.c
@@ -8,7 +8,7 @@
 
   FmpSetImage() will receive untrusted input and do basic validation.
 
-  Copyright (c) 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2016 - 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
@@ -194,9 +194,13 @@ FmpSetImage (
   }
 
   //
-  // Pass Thru
+  // Pass Thru to System FMP Protocol on same handle as FMP Protocol
   //
-  Status = gBS->LocateProtocol(, NULL, (VOID 
**));
+  Status = gBS->HandleProtocol(
+  SystemFmpPrivate->Handle,
+  ,
+  (VOID **)
+  );
   if (EFI_ERROR(Status)) {
 DEBUG((DEBUG_INFO, "(Agent)SetImage - SystemFmpProtocol - %r\n", Status));
 SystemFmpPrivate->LastAttempt.LastAttemptStatus = 
LAST_ATTEMPT_STATUS_ERROR_INVALID_FORMAT;
-- 
2.14.2.windows.3

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

Re: [edk2] [Patch 9/9] SignedCapsulePkg/SystemFirmwareUpdateDxe: Use progress API

[Kinney, Michael D]

Ard,

Yes.  I need to do an edk2-platforms patch to
go with this one.

The current API can be implemented on top of
the new API with no use of progress. That is the
simple patch.  Each platform can choose to use
progress for portions of flash update if needed.

Mike

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Friday, April 6, 2018 6:55 AM
> To: Kinney, Michael D <michael.d.kin...@intel.com>
> Cc: edk2-devel@lists.01.org; Yao, Jiewen
> <jiewen@intel.com>
> Subject: Re: [edk2] [Patch 9/9]
> SignedCapsulePkg/SystemFirmwareUpdateDxe: Use progress
> API
> 
> On 4 April 2018 at 22:25, Michael D Kinney
> <michael.d.kin...@intel.com> wrote:
> > From: "Kinney, Michael D"
> <michael.d.kin...@intel.com>
> >
> > https://bugzilla.tianocore.org/show_bug.cgi?id=801
> >
> > Use PlatformFlashWriteWithProgress() instead of
> PlatformFLashWrite()
> > so the user can be informed of the progress as a
> capsule is used
> > to update a firmware image in a firmware device.
> >
> > Cc: Jiewen Yao <jiewen@intel.com>
> > Signed-off-by: Michael D Kinney
> <michael.d.kin...@intel.com>
> > Contributed-under: TianoCore Contribution Agreement
> 1.1
> 
> Doesn't this break existing platforms that do not
> implement this in
> their PlatformFlashAccessLib?
> 
> > ---
> >  .../SystemFirmwareUpdate/SystemFirmwareUpdateDxe.c |
> 92 --
> >  1 file changed, 68 insertions(+), 24 deletions(-)
> >
> > diff --git
> a/SignedCapsulePkg/Universal/SystemFirmwareUpdate/Syste
> mFirmwareUpdateDxe.c
> b/SignedCapsulePkg/Universal/SystemFirmwareUpdate/Syste
> mFirmwareUpdateDxe.c
> > index fd6641eb3e..8d2e0df81c 100644
> > ---
> a/SignedCapsulePkg/Universal/SystemFirmwareUpdate/Syste
> mFirmwareUpdateDxe.c
> > +++
> b/SignedCapsulePkg/Universal/SystemFirmwareUpdate/Syste
> mFirmwareUpdateDxe.c
> > @@ -8,7 +8,7 @@
> >
> >FmpSetImage() will receive untrusted input and do
> basic validation.
> >
> > -  Copyright (c) 2016, Intel Corporation. All rights
> reserved.
> > +  Copyright (c) 2016 - 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
> > @@ -65,11 +65,14 @@ ParseUpdateDataFile (
> >  **/
> >  EFI_STATUS
> >  PerformUpdate (
> > -  IN VOID
> *SystemFirmwareImage,
> > -  IN UINTN
> SystemFirmwareImageSize,
> > -  IN UPDATE_CONFIG_DATA   *ConfigData,
> > -  OUT UINT32
> *LastAttemptVersion,
> > -  OUT UINT32  *LastAttemptStatus
> > +  IN VOID
> *SystemFirmwareImage,
> > +  IN UINTN
> SystemFirmwareImageSize,
> > +  IN UPDATE_CONFIG_DATA
> *ConfigData,
> > +  OUT UINT32
> *LastAttemptVersion,
> > +  OUT UINT32
> *LastAttemptStatus,
> > +  IN EFI_FIRMWARE_MANAGEMENT_UPDATE_IMAGE_PROGRESS
> Progress,
> > +  IN UINTN
> StartPercentage,
> > +  IN UINTN
> EndPercentage
> >)
> >  {
> >EFI_STATUS   Status;
> > @@ -78,12 +81,15 @@ PerformUpdate (
> >DEBUG((DEBUG_INFO, "  BaseAddress - 0x%lx,",
> ConfigData->BaseAddress));
> >DEBUG((DEBUG_INFO, "  ImageOffset - 0x%x,",
> ConfigData->ImageOffset));
> >DEBUG((DEBUG_INFO, "  Legnth - 0x%x\n",
> ConfigData->Length));
> > -  Status = PerformFlashWrite (
> > +  Status = PerformFlashWriteWithProgress (
> >   ConfigData->FirmwareType,
> >   ConfigData->BaseAddress,
> >   ConfigData->AddressType,
> >   (VOID *)((UINTN)SystemFirmwareImage +
> (UINTN)ConfigData->ImageOffset),
> > - ConfigData->Length
> > + ConfigData->Length,
> > + Progress,
> > + StartPercentage,
> > + EndPercentage
> >   );
> >if (!EFI_ERROR(Status)) {
> >  *LastAttemptStatus =
> LAST_ATTEMPT_STATUS_SUCCESS;
> > @@ -111,12 +117,13 @@ PerformUpdate (
> >  **/
> >  EFI_STATUS
> >  UpdateImage (
> > -  IN VOID
> *SystemFirmwareImage,
> > -  IN UINTN
> SystemFirmwareImageSize,
> > -  IN VOID *ConfigImage,
> > -  IN UINTNConfigImageSize,
> > -  OUT UINT32
> *LastAttemptVersion,
> > -  OUT UINT32   

Re: [edk2] [PATCH V2] MdeModulePkg/Gcd: Filter gCpu->SetMemoryAttributes() calls

[Kinney, Michael D]

Star,

Thanks for adding the comments

Reviewed-by: Michael D Kinney <michael.d.kin...@intel.com>

Mike

> -Original Message-
> From: Yao, Jiewen
> Sent: Wednesday, April 4, 2018 1:13 AM
> To: Zeng, Star <star.z...@intel.com>; edk2-
> de...@lists.01.org
> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Yi Li
> <phoenix.l...@huawei.com>; Dong, Eric
> <eric.d...@intel.com>; Renhao Liang
> <liangren...@huawei.com>; Gao, Liming
> <liming@intel.com>; Heyi Guo <heyi@linaro.org>;
> Kinney, Michael D <michael.d.kin...@intel.com>; Zeng,
> Star <star.z...@intel.com>
> Subject: RE: [edk2] [PATCH V2] MdeModulePkg/Gcd: Filter
> gCpu->SetMemoryAttributes() calls
> 
> Thanks.
> 
> Reviewed-by: jiewen@intel.com
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Star
> > Zeng
> > Sent: Wednesday, April 4, 2018 10:08 AM
> > To: edk2-devel@lists.01.org
> > Cc: Ni, Ruiyu <ruiyu...@intel.com>; Yi Li
> <phoenix.l...@huawei.com>; Dong, Eric
> > <eric.d...@intel.com>; Renhao Liang
> <liangren...@huawei.com>; Gao, Liming
> > <liming@intel.com>; Heyi Guo
> <heyi....@linaro.org>; Kinney, Michael D
> > <michael.d.kin...@intel.com>; Zeng, Star
> <star.z...@intel.com>
> > Subject: [edk2] [PATCH V2] MdeModulePkg/Gcd: Filter
> > gCpu->SetMemoryAttributes() calls
> >
> > From: "Kinney, Michael D"
> <michael.d.kin...@intel.com>
> >
> > This patch fixes an issue with VlvTbltDevicePkg
> introduced
> > by commit 5b91bf82c67b586b9588cbe4bbffa1588f6b5926.
> >
> > The history is as below.
> > To support heap guard feature,
> > 14dde9e903bb9a719ebb8f3381da72b19509bc36
> > added support for SetMemorySpaceAttributes() to
> handle page attributes,
> > but after that, a combination of CPU arch attributes
> and other attributes
> > was not allowed anymore, for example, UC + RUNTIME.
> It is a regression.
> > Then 5b91bf82c67b586b9588cbe4bbffa1588f6b5926 was to
> fix the regression,
> > and we thought 0 CPU arch attributes may be used to
> clear CPU arch
> > attributes, so 0 CPU arch attributes was allowed to
> be sent to
> > gCpu->SetMemoryAttributes().
> >
> > But some implementation of CPU driver may return
> error for 0 CPU arch
> > attributes. That fails the case that caller just
> calls
> > SetMemorySpaceAttributes() with none CPU arch
> attributes (for example,
> > RUNTIME), and the purpose of the case is not to clear
> CPU arch attributes.
> >
> > This patch filters the call to gCpu-
> >SetMemoryAttributes()
> > if the requested attributes is 0.  It also removes
> the #define
> > INVALID_CPU_ARCH_ATTRIBUTES that is no longer used.
> >
> > Cc: Heyi Guo <heyi@linaro.org>
> > Cc: Yi Li <phoenix.l...@huawei.com>
> > Cc: Renhao Liang <liangren...@huawei.com>
> > Cc: Star Zeng <star.z...@intel.com>
> > Cc: Eric Dong <eric.d...@intel.com>
> > Cc: Liming Gao <liming@intel.com>
> > Cc: Jian J Wang <jian.j.w...@intel.com>
> > Cc: Ruiyu Ni <ruiyu...@intel.com>
> > Signed-off-by: Michael D Kinney
> <michael.d.kin...@intel.com>
> > Signed-off-by: Star Zeng <star.z...@intel.com>
> > Contributed-under: TianoCore Contribution Agreement
> 1.1
> > ---
> >  MdeModulePkg/Core/Dxe/Gcd/Gcd.c | 25
> ++---
> >  1 file changed, 22 insertions(+), 3 deletions(-)
> >
> > diff --git a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> > b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> > index 907245a3f512..31ddf9c3bb51 100644
> > --- a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> > +++ b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> > @@ -48,8 +48,6 @@ WITHOUT WARRANTIES OR
> REPRESENTATIONS OF ANY
> > KIND, EITHER EXPRESS OR IMPLIED.
> >  #define NONEXCLUSIVE_MEMORY_ATTRIBUTES
> (EFI_MEMORY_XP |
> > EFI_MEMORY_RP | \
> >
> EFI_MEMORY_RO)
> >
> > -#define INVALID_CPU_ARCH_ATTRIBUTES   0x
> > -
> >  //
> >  // Module Variables
> >  //
> > @@ -873,7 +871,21 @@ CoreConvertSpace (
> >  // Call CPU Arch Protocol to attempt to set
> attributes on the range
> >  //
> >  CpuArchAttributes = ConverToCpuArchAttributes
> (Attributes);
> > -if (CpuArchAttributes !=
> INVALID_CPU_ARCH_ATTRIBUTES) {
> > +//
> > +// CPU arch attributes include page attributes
> and cache attributes.
> > +// Only page attributes supp

[edk2] [Patch V2 2/9] MdeModulePkg: Add DisplayUpdateProgressLib instances

[Kinney, Michael D]

From: Michael D Kinney 

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

Based on content from the following branch/commits:
https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport

Add DisplayUpdateProgressLib instances for text consoles
and graphical consoles.

Cc: Sean Brogan 
Cc: Star Zeng 
Cc: Eric Dong 
Signed-off-by: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
---
 .../DisplayUpdateProgressLibGraphics.c | 475 +
 .../DisplayUpdateProgressLibGraphics.inf   |  60 +++
 .../DisplayUpdateProgressLibGraphics.uni   |  18 +
 .../DisplayUpdateProgressLibText.c | 174 
 .../DisplayUpdateProgressLibText.inf   |  53 +++
 .../DisplayUpdateProgressLibText.uni   |  18 +
 MdeModulePkg/MdeModulePkg.dsc  |   3 +
 7 files changed, 801 insertions(+)
 create mode 100644 
MdeModulePkg/Library/DisplayUpdateProgressLibGraphics/DisplayUpdateProgressLibGraphics.c
 create mode 100644 
MdeModulePkg/Library/DisplayUpdateProgressLibGraphics/DisplayUpdateProgressLibGraphics.inf
 create mode 100644 
MdeModulePkg/Library/DisplayUpdateProgressLibGraphics/DisplayUpdateProgressLibGraphics.uni
 create mode 100644 
MdeModulePkg/Library/DisplayUpdateProgressLibText/DisplayUpdateProgressLibText.c
 create mode 100644 
MdeModulePkg/Library/DisplayUpdateProgressLibText/DisplayUpdateProgressLibText.inf
 create mode 100644 
MdeModulePkg/Library/DisplayUpdateProgressLibText/DisplayUpdateProgressLibText.uni

diff --git 
a/MdeModulePkg/Library/DisplayUpdateProgressLibGraphics/DisplayUpdateProgressLibGraphics.c
 
b/MdeModulePkg/Library/DisplayUpdateProgressLibGraphics/DisplayUpdateProgressLibGraphics.c
new file mode 100644
index 00..007522cea0
--- /dev/null
+++ 
b/MdeModulePkg/Library/DisplayUpdateProgressLibGraphics/DisplayUpdateProgressLibGraphics.c
@@ -0,0 +1,475 @@
+/**  @file
+  Provides services to display completion progress of a firmware update on a
+  graphical console that supports the Graphics Output Protocol.
+
+  Copyright (c) 2016, Microsoft Corporation. All rights reserved.
+  Copyright (c) 2018, Intel Corporation. All rights reserved.
+
+  Redistribution and use in source and binary forms, with or without
+  modification, are permitted provided that the following conditions are met:
+  1. Redistributions of source code must retain the above copyright notice,
+  this list of conditions and the following disclaimer.
+  2. Redistributions in binary form must reproduce the above copyright notice,
+  this list of conditions and the following disclaimer in the documentation
+  and/or other materials provided with the distribution.
+
+  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" 
AND
+  ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+  WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 
DISCLAIMED.
+  IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY 
DIRECT,
+  INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES 
(INCLUDING,
+  BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY 
OF
+  LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING 
NEGLIGENCE
+  OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+  ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+//
+// Values in percent of of logo height.
+//
+#define LOGO_BOTTOM_PADDING20
+#define PROGRESS_BLOCK_HEIGHT  10
+
+//
+// Graphics Output Protocol instance to display progress bar
+//
+EFI_GRAPHICS_OUTPUT_PROTOCOL  *mGop = NULL;
+
+//
+// Set to 100 percent so it is reset on first call.
+//
+UINTN mPreviousProgress = 100;
+
+//
+// Display coordinates for the progress bar.
+//
+UINTN  mStartX = 0;
+UINTN  mStartY = 0;
+
+//
+// Width and height of the progress bar.
+//
+UINTN  mBlockWidth  = 0;
+UINTN  mBlockHeight = 0;
+
+//
+// GOP bitmap of the progress bar. Initialized on every new progress of 100%
+//
+EFI_GRAPHICS_OUTPUT_BLT_PIXEL  *mBlockBitmap;
+
+//
+// GOP bitmap of the progress bar backround.  Initialized once.
+//
+EFI_GRAPHICS_OUTPUT_BLT_PIXEL  *mProgressBarBackground;
+
+//
+// Default mask used to detect the left, right , top, and bottom of logo.  Only
+// green and blue pixels are used for logo detection.
+//
+const EFI_GRAPHICS_OUTPUT_BLT_PIXEL_UNION  mLogoDetectionColorMask = {
+  {
+0xFF,  // Blue
+0xFF,  // Green
+0x00,  // Red
+0x00   // Reserved
+  }
+};
+
+//
+// Background color of progress bar.  Grey.
+//
+const EFI_GRAPHICS_OUTPUT_BLT_PIXEL_UNION  mProgressBarBackgroundColor = {
+  {
+

[edk2] [Patch V2 5/9] MdeModulePkg/DxeCapsuleLibFmp: Add progress bar support

[Kinney, Michael D]

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

Based on content from the following branch/commits:
https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport

* Change Update_Image_Progress() to UpdateImageProcess()
* Call DisplayUpdateProgressLib from UpdateImageProgress().
* Split out a boot service and runtime version of
  UpdateImageProgress() so the DisplayUpdateProgressLib is
  not used at runtime.
* If gEdkiiFirmwareManagementProgressProtocolGuid is present,
  then use its progress bar color and watchdog timer value.
* If gEdkiiFirmwareManagementProgressProtocolGuid is not present,
  then use default progress bar color and 5 min watchdog timer.
* Remove Print() calls during capsule processing.  Instead,
  the DisplayUpdateProgressLib is used to inform the user
  of progress during a capsule update.

Cc: Star Zeng 
Cc: Eric Dong 
Cc: Jiewen Yao 
Cc: Sean Brogan 
Signed-off-by: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
---
 .../Library/DxeCapsuleLibFmp/DxeCapsuleLib.c   | 47 +---
 .../Library/DxeCapsuleLibFmp/DxeCapsuleLib.inf |  8 ++-
 .../DxeCapsuleLibFmp/DxeCapsuleProcessLib.c| 84 --
 .../DxeCapsuleLibFmp/DxeCapsuleProcessLibNull.c| 21 +-
 .../DxeCapsuleLibFmp/DxeRuntimeCapsuleLib.inf  |  7 +-
 5 files changed, 131 insertions(+), 36 deletions(-)

diff --git a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c 
b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
index 555c5971d0..5be6bf386e 100644
--- a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
+++ b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
@@ -45,6 +45,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 EFI_SYSTEM_RESOURCE_TABLE *mEsrtTable  = NULL;
@@ -53,6 +54,8 @@ BOOLEAN   mIsVirtualAddrConverted  = 
FALSE;
 BOOLEAN   mDxeCapsuleLibEndOfDxe   = FALSE;
 EFI_EVENT mDxeCapsuleLibEndOfDxeEvent  = NULL;
 
+EDKII_FIRMWARE_MANAGEMENT_PROGRESS_PROTOCOL  *mFmpProgress = NULL;
+
 /**
   Initialize capsule related variables.
 **/
@@ -101,18 +104,17 @@ RecordFmpCapsuleStatusVariable (
   Function indicate the current completion progress of the firmware
   update. Platform may override with own specific progress function.
 
-  @param[in]  CompletionA value between 1 and 100 indicating the current 
completion progress of the firmware update
+  @param[in]  Completion  A value between 1 and 100 indicating the current
+  completion progress of the firmware update
 
-  @retval EFI_SUCESSInput capsule is a correct FMP capsule.
+  @retval EFI_SUCESS The capsule update progress was updated.
+  @retval EFI_INVALID_PARAMETER  Completion is greater than 100%.
 **/
 EFI_STATUS
 EFIAPI
-Update_Image_Progress (
+UpdateImageProgress (
   IN UINTN  Completion
-  )
-{
-  return EFI_SUCCESS;
-}
+  );
 
 /**
   Return if this CapsuleGuid is a FMP capsule GUID or not.
@@ -849,6 +851,19 @@ SetFmpImageData (
 return Status;
   }
 
+  //
+  // Lookup Firmware Management Progress Protocol before SetImage() is called
+  // This is an optional protocol that may not be present on Handle.
+  //
+  Status = gBS->HandleProtocol (
+  Handle,
+  ,
+  (VOID **)
+  );
+  if (EFI_ERROR (Status)) {
+mFmpProgress = NULL;
+  }
+
   if (ImageHeader->Version >= 
EFI_FIRMWARE_MANAGEMENT_CAPSULE_IMAGE_HEADER_INIT_VERSION) {
 Image = (UINT8 *)(ImageHeader + 1);
   } else {
@@ -873,21 +888,37 @@ SetFmpImageData (
 DEBUG((DEBUG_INFO, "(UpdateHardwareInstance - 0x%x)", 
ImageHeader->UpdateHardwareInstance));
   }
   DEBUG((DEBUG_INFO, "\n"));
+
+  //
+  // Before calling SetImage(), reset the progress bar to 0%
+  //
+  UpdateImageProgress (0);
+
   Status = Fmp->SetImage(
   Fmp,
   ImageHeader->UpdateImageIndex,  // ImageIndex
   Image,  // Image
   ImageHeader->UpdateImageSize,   // ImageSize
   VendorCode, // VendorCode
-  Update_Image_Progress,  // Progress
+  UpdateImageProgress,// Progress
   // AbortReason
   );
+  //
+  // Set the progress bar to 100% after returning from SetImage()
+  //
+  UpdateImageProgress (100);
+
   DEBUG((DEBUG_INFO, "Fmp->SetImage - %r\n", Status));
   if (AbortReason != NULL) {
 DEBUG ((DEBUG_ERROR, "%s\n", AbortReason));
 FreePool(AbortReason);
   }
 
+  //
+  // Clear mFmpProgress after SetImage() returns
+  //
+  mFmpProgress = NULL;
+
   return Status;
 }
 
diff --git a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.inf 

[edk2] [Patch V2 3/9] Vlv2Tbl2DevicePkg: Add DisplayUpdateProgressLib mapping

[Kinney, Michael D]

From: Michael D Kinney 

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

Based on content from the following branch/commits:
https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport

Cc: Sean Brogan 
Cc: David Wei 
Cc: Mang Guo 
Signed-off-by: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
---
 Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 1 +
 Vlv2TbltDevicePkg/PlatformPkgIA32.dsc   | 1 +
 Vlv2TbltDevicePkg/PlatformPkgX64.dsc| 1 +
 3 files changed, 3 insertions(+)

diff --git a/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc 
b/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
index f918e44851..b6741257e7 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
@@ -195,6 +195,7 @@ [LibraryClasses.common]
   IniParsingLib|SignedCapsulePkg/Library/IniParsingLib/IniParsingLib.inf
   
PlatformFlashAccessLib|Vlv2TbltDevicePkg/Feature/Capsule/Library/PlatformFlashAccessLib/PlatformFlashAccessLib.inf
   
MicrocodeFlashAccessLib|Vlv2TbltDevicePkg/Feature/Capsule/Library/PlatformFlashAccessLib/PlatformFlashAccessLib.inf
+  
DisplayUpdateProgressLib|MdeModulePkg/Library/DisplayUpdateProgressLibGraphics/DisplayUpdateProgressLibGraphics.inf
   
LanguageLib|EdkCompatibilityPkg/Compatibility/Library/UefiLanguageLib/UefiLanguageLib.inf
   
SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
   
SecurityManagementLib|MdeModulePkg/Library/DxeSecurityManagementLib/DxeSecurityManagementLib.inf
diff --git a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc 
b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
index 0a95d95557..bd276f0643 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
@@ -195,6 +195,7 @@ [LibraryClasses.common]
   IniParsingLib|SignedCapsulePkg/Library/IniParsingLib/IniParsingLib.inf
   
PlatformFlashAccessLib|Vlv2TbltDevicePkg/Feature/Capsule/Library/PlatformFlashAccessLib/PlatformFlashAccessLib.inf
   
MicrocodeFlashAccessLib|Vlv2TbltDevicePkg/Feature/Capsule/Library/PlatformFlashAccessLib/PlatformFlashAccessLib.inf
+  
DisplayUpdateProgressLib|MdeModulePkg/Library/DisplayUpdateProgressLibGraphics/DisplayUpdateProgressLibGraphics.inf
   
LanguageLib|EdkCompatibilityPkg/Compatibility/Library/UefiLanguageLib/UefiLanguageLib.inf
   
SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
   
SecurityManagementLib|MdeModulePkg/Library/DxeSecurityManagementLib/DxeSecurityManagementLib.inf
diff --git a/Vlv2TbltDevicePkg/PlatformPkgX64.dsc 
b/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
index fb2743c727..042a35b2b7 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
@@ -195,6 +195,7 @@ [LibraryClasses.common]
   IniParsingLib|SignedCapsulePkg/Library/IniParsingLib/IniParsingLib.inf
   
PlatformFlashAccessLib|Vlv2TbltDevicePkg/Feature/Capsule/Library/PlatformFlashAccessLib/PlatformFlashAccessLib.inf
   
MicrocodeFlashAccessLib|Vlv2TbltDevicePkg/Feature/Capsule/Library/PlatformFlashAccessLib/PlatformFlashAccessLib.inf
+  
DisplayUpdateProgressLib|MdeModulePkg/Library/DisplayUpdateProgressLibGraphics/DisplayUpdateProgressLibGraphics.inf
   
LanguageLib|EdkCompatibilityPkg/Compatibility/Library/UefiLanguageLib/UefiLanguageLib.inf
   
SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
   
SecurityManagementLib|MdeModulePkg/Library/DxeSecurityManagementLib/DxeSecurityManagementLib.inf
-- 
2.14.2.windows.3

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

[edk2] [Patch V2 8/9] QuarkPlatformPkg/PlatformFlashAccessLib: Add progress API

[Kinney, Michael D]

From: Michael D Kinney 

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

Add PerformFlashWriteWithProgress() to the PlatformFlashAccessLib.
This allows the platform to inform the user of progress when a
firmware storage device is being updated with a new firmware
image.

Cc: Kelly Steele 
Signed-off-by: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
---
 .../PlatformFlashAccessLibDxe.c| 78 +++---
 1 file changed, 70 insertions(+), 8 deletions(-)

diff --git 
a/QuarkPlatformPkg/Feature/Capsule/Library/PlatformFlashAccessLib/PlatformFlashAccessLibDxe.c
 
b/QuarkPlatformPkg/Feature/Capsule/Library/PlatformFlashAccessLib/PlatformFlashAccessLibDxe.c
index 839c3a726e..69d76df785 100644
--- 
a/QuarkPlatformPkg/Feature/Capsule/Library/PlatformFlashAccessLib/PlatformFlashAccessLibDxe.c
+++ 
b/QuarkPlatformPkg/Feature/Capsule/Library/PlatformFlashAccessLib/PlatformFlashAccessLibDxe.c
@@ -1,7 +1,7 @@
 /** @file
   Platform Flash Access library.
 
-  Copyright (c) 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2016 - 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
@@ -112,13 +112,29 @@ FlashFdErase (
 }
 
 /**
-  Perform flash write opreation.
+  Perform flash write operation with progress indicator.  The start and end
+  completion percentage values are passed into this function.  If the requested
+  flash write operation is broken up, then completion percentage between the
+  start and end values may be passed to the provided Progress function.  The
+  caller of this function is required to call the Progress function for the
+  start and end completion percentage values.  This allows the Progress,
+  StartPercentage, and EndPercentage parameters to be ignored if the requested
+  flash write operation can not be broken up
 
   @param[in] FirmwareType  The type of firmware.
   @param[in] FlashAddress  The address of flash device to be accessed.
   @param[in] FlashAddressType  The type of flash device address.
   @param[in] BufferThe pointer to the data buffer.
   @param[in] LengthThe length of data buffer in bytes.
+  @param[in] Progress  A function used report the progress of the
+   firmware update.  This is an optional parameter
+   that may be NULL.
+  @param[in] StartPercentage   The start completion percentage value that may
+   be used to report progress during the flash
+   write operation.
+  @param[in] EndPercentage The end completion percentage value that may
+   be used to report progress during the flash
+   write operation.
 
   @retval EFI_SUCCESS   The operation returns successfully.
   @retval EFI_WRITE_PROTECTED   The flash device is read only.
@@ -127,12 +143,15 @@ FlashFdErase (
 **/
 EFI_STATUS
 EFIAPI
-PerformFlashWrite (
-  IN PLATFORM_FIRMWARE_TYPE   FirmwareType,
-  IN EFI_PHYSICAL_ADDRESS FlashAddress,
-  IN FLASH_ADDRESS_TYPE   FlashAddressType,
-  IN VOID *Buffer,
-  IN UINTNLength
+PerformFlashWriteWithProgress (
+  IN PLATFORM_FIRMWARE_TYPE FirmwareType,
+  IN EFI_PHYSICAL_ADDRESS   FlashAddress,
+  IN FLASH_ADDRESS_TYPE FlashAddressType,
+  IN VOID   *Buffer,
+  IN UINTN  Length,
+  IN EFI_FIRMWARE_MANAGEMENT_UPDATE_IMAGE_PROGRESS  Progress,OPTIONAL
+  IN UINTN  StartPercentage,
+  IN UINTN  EndPercentage
   )
 {
   EFI_STATUS  Status;
@@ -150,6 +169,10 @@ PerformFlashWrite (
   //
   SectorNum = Length / SPI_ERASE_SECTOR_SIZE;
   for (Index = 0; Index < SectorNum; Index++){
+if (Progress != NULL) {
+  Progress (StartPercentage + ((Index * (EndPercentage - StartPercentage)) 
/ SectorNum));
+}
+
 if (CompareMem(
   (UINT8 *)(UINTN)(FlashAddress + mInternalFdAddress) + Index * 
SPI_ERASE_SECTOR_SIZE,
   (UINT8 *)Buffer + Index * SPI_ERASE_SECTOR_SIZE,
@@ -175,10 +198,49 @@ PerformFlashWrite (
   break;
 }
   }
+  if (Progress != NULL) {
+Progress (EndPercentage);
+  }
 
   return EFI_SUCCESS;
 }
 
+/**
+  Perform flash write operation.
+
+  @param[in] FirmwareType  The type of firmware.
+  @param[in] FlashAddress  The address of flash device to be accessed.
+  @param[in] FlashAddressType  The type of flash device address.
+  

[edk2] [Patch V2 7/9] Vlv2TbltDevicePkg/PlatformFlashAccessLib: Add progress API

[Kinney, Michael D]

From: Michael D Kinney 

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

Add PerformFlashWriteWithProgress() to the PlatformFlashAccessLib.
This allows the platform to inform the user of progress when a
firmware storage device is being updated with a new firmware
image.

Cc: David Wei 
Cc: Mang Guo 
Signed-off-by: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
---
 .../PlatformFlashAccessLib.c   | 102 +++--
 .../PlatformFlashAccessLib.inf |   3 +-
 2 files changed, 77 insertions(+), 28 deletions(-)

diff --git 
a/Vlv2TbltDevicePkg/Feature/Capsule/Library/PlatformFlashAccessLib/PlatformFlashAccessLib.c
 
b/Vlv2TbltDevicePkg/Feature/Capsule/Library/PlatformFlashAccessLib/PlatformFlashAccessLib.c
index 9162e025ed..06278d202a 100644
--- 
a/Vlv2TbltDevicePkg/Feature/Capsule/Library/PlatformFlashAccessLib/PlatformFlashAccessLib.c
+++ 
b/Vlv2TbltDevicePkg/Feature/Capsule/Library/PlatformFlashAccessLib/PlatformFlashAccessLib.c
@@ -1,7 +1,7 @@
 /** @file
   Platform Flash Access library.
 
-  Copyright (c) 2017, Intel Corporation. All rights reserved.
+  Copyright (c) 2016 - 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
@@ -381,13 +381,29 @@ InternalWriteBlock (
 }
 
 /**
-  Perform flash write opreation.
+  Perform flash write operation with progress indicator.  The start and end
+  completion percentage values are passed into this function.  If the requested
+  flash write operation is broken up, then completion percentage between the
+  start and end values may be passed to the provided Progress function.  The
+  caller of this function is required to call the Progress function for the
+  start and end completion percentage values.  This allows the Progress,
+  StartPercentage, and EndPercentage parameters to be ignored if the requested
+  flash write operation can not be broken up
 
   @param[in] FirmwareType  The type of firmware.
   @param[in] FlashAddress  The address of flash device to be accessed.
   @param[in] FlashAddressType  The type of flash device address.
   @param[in] BufferThe pointer to the data buffer.
   @param[in] LengthThe length of data buffer in bytes.
+  @param[in] Progress  A function used report the progress of the
+   firmware update.  This is an optional parameter
+   that may be NULL.
+  @param[in] StartPercentage   The start completion percentage value that may
+   be used to report progress during the flash
+   write operation.
+  @param[in] EndPercentage The end completion percentage value that may
+   be used to report progress during the flash
+   write operation.
 
   @retval EFI_SUCCESS   The operation returns successfully.
   @retval EFI_WRITE_PROTECTED   The flash device is read only.
@@ -396,12 +412,15 @@ InternalWriteBlock (
 **/
 EFI_STATUS
 EFIAPI
-PerformFlashWrite (
-  IN PLATFORM_FIRMWARE_TYPE   FirmwareType,
-  IN EFI_PHYSICAL_ADDRESS FlashAddress,
-  IN FLASH_ADDRESS_TYPE   FlashAddressType,
-  IN VOID *Buffer,
-  IN UINTNLength
+PerformFlashWriteWithProgress (
+  IN PLATFORM_FIRMWARE_TYPE FirmwareType,
+  IN EFI_PHYSICAL_ADDRESS   FlashAddress,
+  IN FLASH_ADDRESS_TYPE FlashAddressType,
+  IN VOID   *Buffer,
+  IN UINTN  Length,
+  IN EFI_FIRMWARE_MANAGEMENT_UPDATE_IMAGE_PROGRESS  Progress,OPTIONAL
+  IN UINTN  StartPercentage,
+  IN UINTN  EndPercentage
   )
 {
   EFI_STATUSStatus = EFI_SUCCESS;
@@ -456,42 +475,40 @@ PerformFlashWrite (
 // Raise TPL to TPL_NOTIFY to block any event handler,
 // while still allowing RaiseTPL(TPL_NOTIFY) within
 // output driver during Print()
-  //
+//
 OldTpl = gBS->RaiseTPL (TPL_NOTIFY);
 for (Index = 0; Index < CountOfBlocks; Index++) {
+  if (Progress != NULL) {
+Progress (StartPercentage + ((Index * (EndPercentage - 
StartPercentage)) / CountOfBlocks));
+  }
   //
   // Handle block based on address and contents.
   //
   if (!EFI_ERROR (InternalCompareBlock (Address, Buf))) {
 DEBUG((DEBUG_INFO, "Skipping block at 0x%lx (already programmed)\n", 
Address));
   } else {
-//
-// Display a dot for each block being 

[edk2] [Patch V2 9/9] SignedCapsulePkg/SystemFirmwareUpdateDxe: Use progress API

[Kinney, Michael D]

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

Use PlatformFlashWriteWithProgress() instead of PlatformFLashWrite()
so the user can be informed of the progress as a capsule is used
to update a firmware image in a firmware device.

Cc: Jiewen Yao 
Signed-off-by: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
---
 .../SystemFirmwareUpdate/SystemFirmwareUpdateDxe.c | 90 --
 1 file changed, 67 insertions(+), 23 deletions(-)

diff --git 
a/SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareUpdateDxe.c 
b/SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareUpdateDxe.c
index d0b1c9913c..19b63695d2 100644
--- a/SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareUpdateDxe.c
+++ b/SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareUpdateDxe.c
@@ -65,11 +65,14 @@ ParseUpdateDataFile (
 **/
 EFI_STATUS
 PerformUpdate (
-  IN VOID *SystemFirmwareImage,
-  IN UINTNSystemFirmwareImageSize,
-  IN UPDATE_CONFIG_DATA   *ConfigData,
-  OUT UINT32  *LastAttemptVersion,
-  OUT UINT32  *LastAttemptStatus
+  IN VOID   *SystemFirmwareImage,
+  IN UINTN  SystemFirmwareImageSize,
+  IN UPDATE_CONFIG_DATA *ConfigData,
+  OUT UINT32*LastAttemptVersion,
+  OUT UINT32*LastAttemptStatus,
+  IN EFI_FIRMWARE_MANAGEMENT_UPDATE_IMAGE_PROGRESS  Progress,
+  IN UINTN  StartPercentage,
+  IN UINTN  EndPercentage
   )
 {
   EFI_STATUS   Status;
@@ -78,13 +81,22 @@ PerformUpdate (
   DEBUG((DEBUG_INFO, "  BaseAddress - 0x%lx,", ConfigData->BaseAddress));
   DEBUG((DEBUG_INFO, "  ImageOffset - 0x%x,", ConfigData->ImageOffset));
   DEBUG((DEBUG_INFO, "  Legnth - 0x%x\n", ConfigData->Length));
-  Status = PerformFlashWrite (
+  if (Progress != NULL) {
+Progress (StartPercentage);
+  }
+  Status = PerformFlashWriteWithProgress (
  ConfigData->FirmwareType,
  ConfigData->BaseAddress,
  ConfigData->AddressType,
  (VOID *)((UINTN)SystemFirmwareImage + 
(UINTN)ConfigData->ImageOffset),
- ConfigData->Length
+ ConfigData->Length,
+ Progress,
+ StartPercentage,
+ EndPercentage
  );
+  if (Progress != NULL) {
+Progress (EndPercentage);
+  }
   if (!EFI_ERROR(Status)) {
 *LastAttemptStatus = LAST_ATTEMPT_STATUS_SUCCESS;
 if (ConfigData->FirmwareType == PlatformFirmwareTypeNvRam) {
@@ -111,12 +123,13 @@ PerformUpdate (
 **/
 EFI_STATUS
 UpdateImage (
-  IN VOID *SystemFirmwareImage,
-  IN UINTNSystemFirmwareImageSize,
-  IN VOID *ConfigImage,
-  IN UINTNConfigImageSize,
-  OUT UINT32  *LastAttemptVersion,
-  OUT UINT32  *LastAttemptStatus
+  IN VOID   *SystemFirmwareImage,
+  IN UINTN  SystemFirmwareImageSize,
+  IN VOID   *ConfigImage,
+  IN UINTN  ConfigImageSize,
+  OUT UINT32*LastAttemptVersion,
+  OUT UINT32*LastAttemptStatus,
+  IN EFI_FIRMWARE_MANAGEMENT_UPDATE_IMAGE_PROGRESS  Progress
   )
 {
   EFI_STATUSStatus;
@@ -124,19 +137,34 @@ UpdateImage (
   UPDATE_CONFIG_DATA*UpdateConfigData;
   CONFIG_HEADER ConfigHeader;
   UINTN Index;
+  UINTN TotalSize;
+  UINTN BytesWritten;
+  UINTN StartPercentage;
+  UINTN EndPercentage;
 
   if (ConfigImage == NULL) {
 DEBUG((DEBUG_INFO, "PlatformUpdate (NoConfig):"));
 DEBUG((DEBUG_INFO, "  BaseAddress - 0x%x,", 0));
 DEBUG((DEBUG_INFO, "  Length - 0x%x\n", SystemFirmwareImageSize));
 // ASSUME the whole System Firmware include NVRAM region.
-Status = PerformFlashWrite (
+StartPercentage = 0;
+EndPercentage = 100;
+if (Progress != NULL) {
+  Progress (StartPercentage);
+}
+Status = PerformFlashWriteWithProgress (
PlatformFirmwareTypeNvRam,
0,
FlashAddressTypeRelativeAddress,
SystemFirmwareImage,
-   SystemFirmwareImageSize
+   SystemFirmwareImageSize,
+   Progress,
+   StartPercentage,
+   

[edk2] [Patch V2 6/9] SignedCapsulePkg/PlatformFlashAccessLib: Add progress API

[Kinney, Michael D]

From: Michael D Kinney 

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

Add a new API to the PlatformFlashAccessLib that passes
in an optional Progress() function along with a start and
end percentage to call the Progress() function with.
If the Progress() function is not NULL, then it is the
Progress() function that was passed into the Firmware
Management Protocol SetImage() services and is used
to update the user on the progress as a firmware device
is updated with a firmware image.

Implementations of the PlatformFlashAccessLib are
recommended to call the Progress() function as work
is performed to update to contents of a firmware
storage device.

Cc: Jiewen Yao 
Signed-off-by: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
---
 .../Include/Library/PlatformFlashAccessLib.h   | 49 ++-
 .../PlatformFlashAccessLibNull.c   | 70 +++---
 2 files changed, 110 insertions(+), 9 deletions(-)

diff --git a/SignedCapsulePkg/Include/Library/PlatformFlashAccessLib.h 
b/SignedCapsulePkg/Include/Library/PlatformFlashAccessLib.h
index 0a8858e4c4..e3308251c2 100644
--- a/SignedCapsulePkg/Include/Library/PlatformFlashAccessLib.h
+++ b/SignedCapsulePkg/Include/Library/PlatformFlashAccessLib.h
@@ -1,7 +1,7 @@
 /** @file
   Platform flash device access library.
 
-  Copyright (c) 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2016 - 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
@@ -16,6 +16,8 @@
 #ifndef __PLATFORM_FLASH_ACCESS_LIB_H__
 #define __PLATFORM_FLASH_ACCESS_LIB_H__
 
+#include 
+
 typedef enum {
   FlashAddressTypeRelativeAddress,
   FlashAddressTypeAbsoluteAddress,
@@ -31,7 +33,7 @@ typedef enum {
 } PLATFORM_FIRMWARE_TYPE;
 
 /**
-  Perform flash write opreation.
+  Perform flash write operation.
 
   @param[in] FirmwareType  The type of firmware.
   @param[in] FlashAddress  The address of flash device to be accessed.
@@ -54,4 +56,47 @@ PerformFlashWrite (
   IN UINTNLength
   );
 
+/**
+  Perform flash write operation with progress indicator.  The start and end
+  completion percentage values are passed into this function.  If the requested
+  flash write operation is broken up, then completion percentage between the
+  start and end values may be passed to the provided Progress function.  The
+  caller of this function is required to call the Progress function for the
+  start and end completion percentage values.  This allows the Progress,
+  StartPercentage, and EndPercentage parameters to be ignored if the requested
+  flash write operation can not be broken up
+
+  @param[in] FirmwareType  The type of firmware.
+  @param[in] FlashAddress  The address of flash device to be accessed.
+  @param[in] FlashAddressType  The type of flash device address.
+  @param[in] BufferThe pointer to the data buffer.
+  @param[in] LengthThe length of data buffer in bytes.
+  @param[in] Progress  A function used report the progress of the
+   firmware update.  This is an optional parameter
+   that may be NULL.
+  @param[in] StartPercentage   The start completion percentage value that may
+   be used to report progress during the flash
+   write operation.
+  @param[in] EndPercentage The end completion percentage value that may
+   be used to report progress during the flash
+   write operation.
+
+  @retval EFI_SUCCESS   The operation returns successfully.
+  @retval EFI_WRITE_PROTECTED   The flash device is read only.
+  @retval EFI_UNSUPPORTED   The flash device access is unsupported.
+  @retval EFI_INVALID_PARAMETER The input parameter is not valid.
+**/
+EFI_STATUS
+EFIAPI
+PerformFlashWriteWithProgress (
+  IN PLATFORM_FIRMWARE_TYPE FirmwareType,
+  IN EFI_PHYSICAL_ADDRESS   FlashAddress,
+  IN FLASH_ADDRESS_TYPE FlashAddressType,
+  IN VOID   *Buffer,
+  IN UINTN  Length,
+  IN EFI_FIRMWARE_MANAGEMENT_UPDATE_IMAGE_PROGRESS  Progress,OPTIONAL
+  IN UINTN  StartPercentage,
+  IN UINTN  EndPercentage
+  );
+
 #endif
diff --git 
a/SignedCapsulePkg/Library/PlatformFlashAccessLibNull/PlatformFlashAccessLibNull.c
 
b/SignedCapsulePkg/Library/PlatformFlashAccessLibNull/PlatformFlashAccessLibNull.c
index b34ebbba1e..854f108cf4 100644
--- 

[edk2] [Patch V2 4/9] QuarkPlatformPkg: Add DisplayUpdateProgressLib mapping

[Kinney, Michael D]

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

Based on content from the following branch/commits:
https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport

Cc: Sean Brogan 
Cc: Kelly Steele 
Signed-off-by: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
---
 QuarkPlatformPkg/Quark.dsc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/QuarkPlatformPkg/Quark.dsc b/QuarkPlatformPkg/Quark.dsc
index a43a5595d4..14142087bd 100644
--- a/QuarkPlatformPkg/Quark.dsc
+++ b/QuarkPlatformPkg/Quark.dsc
@@ -241,6 +241,7 @@ [LibraryClasses]
   
FmpAuthenticationLib|MdeModulePkg/Library/FmpAuthenticationLibNull/FmpAuthenticationLibNull.inf
   IniParsingLib|SignedCapsulePkg/Library/IniParsingLib/IniParsingLib.inf
   
PlatformFlashAccessLib|QuarkPlatformPkg/Feature/Capsule/Library/PlatformFlashAccessLib/PlatformFlashAccessLibDxe.inf
+  
DisplayUpdateProgressLib|MdeModulePkg/Library/DisplayUpdateProgressLibText/DisplayUpdateProgressLibText.inf
 
 [LibraryClasses.common.SEC]
   #
-- 
2.14.2.windows.3

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

[edk2] [edk2-platforms Patch V2 4/6] AMD/OverdriveBoard: Add DisplayUpdateProgressLib mapping

[Kinney, Michael D]

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

Based on content from the following branch/commits:
https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Signed-off-by: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
---
 Platform/AMD/OverdriveBoard/OverdriveBoard.dsc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc 
b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
index 348828e18d..f86b42e1c1 100644
--- a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
+++ b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
@@ -127,6 +127,7 @@ [LibraryClasses.common]
   
RealTimeClockLib|Silicon/AMD/Styx/Library/RealTimeClockLib/RealTimeClockLib.inf
 
   CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.inf
+  
DisplayUpdateProgressLib|MdeModulePkg/Library/DisplayUpdateProgressLibGraphics/DisplayUpdateProgressLibGraphics.inf
 !if $(DO_CAPSULE) == TRUE
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
   OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
-- 
2.14.2.windows.3

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

[edk2] [edk2-platforms Patch V2 2/6] Hisilicon/PlatformFlashAccessLib: Add progress API

[Kinney, Michael D]

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

Add PerformFlashWriteWithProgress() to the PlatformFlashAccessLib.
This allows the platform to inform the user of progress when a
firmware storage device is being updated with a new firmware
image.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Signed-off-by: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
---
 .../PlatformFlashAccessLibDxe.c| 71 +++---
 1 file changed, 63 insertions(+), 8 deletions(-)

diff --git 
a/Silicon/Hisilicon/Library/PlatformFlashAccessLib/PlatformFlashAccessLibDxe.c 
b/Silicon/Hisilicon/Library/PlatformFlashAccessLib/PlatformFlashAccessLibDxe.c
index 62da61c79b..585f7ef0e8 100644
--- 
a/Silicon/Hisilicon/Library/PlatformFlashAccessLib/PlatformFlashAccessLibDxe.c
+++ 
b/Silicon/Hisilicon/Library/PlatformFlashAccessLib/PlatformFlashAccessLibDxe.c
@@ -3,7 +3,7 @@
 
   Copyright (c) 2018, Hisilicon Limited. All rights reserved.
   Copyright (c) 2018, Linaro Limited. All rights reserved.
-  Copyright (c) 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2016 - 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
@@ -30,13 +30,29 @@ STATIC EFI_PHYSICAL_ADDRESS mSFCMEM0BaseAddress;
 STATIC HISI_SPI_FLASH_PROTOCOL *mSpiProtocol;
 
 /**
-  Perform flash write opreation.
+  Perform flash write operation with progress indicator.  The start and end
+  completion percentage values are passed into this function.  If the requested
+  flash write operation is broken up, then completion percentage between the
+  start and end values may be passed to the provided Progress function.  The
+  caller of this function is required to call the Progress function for the
+  start and end completion percentage values.  This allows the Progress,
+  StartPercentage, and EndPercentage parameters to be ignored if the requested
+  flash write operation can not be broken up
 
   @param[in] FirmwareType  The type of firmware.
   @param[in] FlashAddress  The address of flash device to be accessed.
   @param[in] FlashAddressType  The type of flash device address.
   @param[in] BufferThe pointer to the data buffer.
   @param[in] LengthThe length of data buffer in bytes.
+  @param[in] Progress  A function used report the progress of the
+   firmware update.  This is an optional parameter
+   that may be NULL.
+  @param[in] StartPercentage   The start completion percentage value that may
+   be used to report progress during the flash
+   write operation.
+  @param[in] EndPercentage The end completion percentage value that may
+   be used to report progress during the flash
+   write operation.
 
   @retval EFI_SUCCESS   The operation returns successfully.
   @retval EFI_WRITE_PROTECTED   The flash device is read only.
@@ -45,12 +61,15 @@ STATIC HISI_SPI_FLASH_PROTOCOL *mSpiProtocol;
 **/
 EFI_STATUS
 EFIAPI
-PerformFlashWrite (
-  IN PLATFORM_FIRMWARE_TYPE   FirmwareType,
-  IN EFI_PHYSICAL_ADDRESS FlashAddress,
-  IN FLASH_ADDRESS_TYPE   FlashAddressType,
-  IN VOID *Buffer,
-  IN UINTNLength
+PerformFlashWriteWithProgress (
+  IN PLATFORM_FIRMWARE_TYPE FirmwareType,
+  IN EFI_PHYSICAL_ADDRESS   FlashAddress,
+  IN FLASH_ADDRESS_TYPE FlashAddressType,
+  IN VOID   *Buffer,
+  IN UINTN  Length,
+  IN EFI_FIRMWARE_MANAGEMENT_UPDATE_IMAGE_PROGRESS  Progress,OPTIONAL
+  IN UINTN  StartPercentage,
+  IN UINTN  EndPercentage
   )
 {
   UINT32   RomAddress;
@@ -83,6 +102,42 @@ PerformFlashWrite (
   return Status;
 }
 
+/**
+  Perform flash write operation.
+
+  @param[in] FirmwareType  The type of firmware.
+  @param[in] FlashAddress  The address of flash device to be accessed.
+  @param[in] FlashAddressType  The type of flash device address.
+  @param[in] BufferThe pointer to the data buffer.
+  @param[in] LengthThe length of data buffer in bytes.
+
+  @retval EFI_SUCCESS   The operation returns successfully.
+  @retval EFI_WRITE_PROTECTED   The flash device is read only.
+  @retval EFI_UNSUPPORTED   The flash device access is unsupported.
+  @retval EFI_INVALID_PARAMETER The input parameter is not valid.
+**/
+EFI_STATUS
+EFIAPI
+PerformFlashWrite (
+  IN PLATFORM_FIRMWARE_TYPE   FirmwareType,
+  

[edk2] [edk2-platforms Patch V2 1/6] Styx/PlatformFlashAccessLib: Add progress API

[Kinney, Michael D]

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

Add PerformFlashWriteWithProgress() to the PlatformFlashAccessLib.
This allows the platform to inform the user of progress when a
firmware storage device is being updated with a new firmware
image.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Signed-off-by: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
---
 .../StyxPlatformFlashAccessLib.c   | 70 +++---
 1 file changed, 63 insertions(+), 7 deletions(-)

diff --git 
a/Silicon/AMD/Styx/Library/StyxPlatformFlashAccessLib/StyxPlatformFlashAccessLib.c
 
b/Silicon/AMD/Styx/Library/StyxPlatformFlashAccessLib/StyxPlatformFlashAccessLib.c
index a94373bb4b..38f1830b5c 100644
--- 
a/Silicon/AMD/Styx/Library/StyxPlatformFlashAccessLib/StyxPlatformFlashAccessLib.c
+++ 
b/Silicon/AMD/Styx/Library/StyxPlatformFlashAccessLib/StyxPlatformFlashAccessLib.c
@@ -2,6 +2,7 @@
   Platform flash device access library for AMD Styx
 
   Copyright (c) 2017, Linaro, Ltd. All rights reserved.
+  Copyright (c) 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
@@ -27,13 +28,29 @@ STATIC CONST UINT64 mFlashMaxSize = FixedPcdGet64 
(PcdFdSize);
 STATIC CONST UINTN mBlockSize = SIZE_64KB;
 
 /**
-  Perform flash write operation.
+  Perform flash write operation with progress indicator.  The start and end
+  completion percentage values are passed into this function.  If the requested
+  flash write operation is broken up, then completion percentage between the
+  start and end values may be passed to the provided Progress function.  The
+  caller of this function is required to call the Progress function for the
+  start and end completion percentage values.  This allows the Progress,
+  StartPercentage, and EndPercentage parameters to be ignored if the requested
+  flash write operation can not be broken up
 
   @param[in] FirmwareType  The type of firmware.
   @param[in] FlashAddress  The address of flash device to be accessed.
   @param[in] FlashAddressType  The type of flash device address.
   @param[in] BufferThe pointer to the data buffer.
   @param[in] LengthThe length of data buffer in bytes.
+  @param[in] Progress  A function used report the progress of the
+   firmware update.  This is an optional parameter
+   that may be NULL.
+  @param[in] StartPercentage   The start completion percentage value that may
+   be used to report progress during the flash
+   write operation.
+  @param[in] EndPercentage The end completion percentage value that may
+   be used to report progress during the flash
+   write operation.
 
   @retval EFI_SUCCESS   The operation returns successfully.
   @retval EFI_WRITE_PROTECTED   The flash device is read only.
@@ -42,12 +59,15 @@ STATIC CONST UINTN mBlockSize = SIZE_64KB;
 **/
 EFI_STATUS
 EFIAPI
-PerformFlashWrite (
-  IN PLATFORM_FIRMWARE_TYPE   FirmwareType,
-  IN EFI_PHYSICAL_ADDRESS FlashAddress,
-  IN FLASH_ADDRESS_TYPE   FlashAddressType,
-  IN VOID *Buffer,
-  IN UINTNLength
+PerformFlashWriteWithProgress (
+  IN PLATFORM_FIRMWARE_TYPE FirmwareType,
+  IN EFI_PHYSICAL_ADDRESS   FlashAddress,
+  IN FLASH_ADDRESS_TYPE FlashAddressType,
+  IN VOID   *Buffer,
+  IN UINTN  Length,
+  IN EFI_FIRMWARE_MANAGEMENT_UPDATE_IMAGE_PROGRESS  Progress,OPTIONAL
+  IN UINTN  StartPercentage,
+  IN UINTN  EndPercentage
   )
 {
   EFI_STATUS  Status;
@@ -122,3 +142,39 @@ PerformFlashWrite (
 
   return EFI_SUCCESS;
 }
+
+/**
+  Perform flash write operation.
+
+  @param[in] FirmwareType  The type of firmware.
+  @param[in] FlashAddress  The address of flash device to be accessed.
+  @param[in] FlashAddressType  The type of flash device address.
+  @param[in] BufferThe pointer to the data buffer.
+  @param[in] LengthThe length of data buffer in bytes.
+
+  @retval EFI_SUCCESS   The operation returns successfully.
+  @retval EFI_WRITE_PROTECTED   The flash device is read only.
+  @retval EFI_UNSUPPORTED   The flash device access is unsupported.
+  @retval EFI_INVALID_PARAMETER The input parameter is not valid.
+**/
+EFI_STATUS
+EFIAPI
+PerformFlashWrite (
+  IN PLATFORM_FIRMWARE_TYPE   FirmwareType,
+  IN EFI_PHYSICAL_ADDRESS FlashAddress,
+  IN 

[edk2] [edk2-platforms Patch V2 5/6] Socionext/DeveloperBox: Add DisplayUpdateProgressLib mapping

[Kinney, Michael D]

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

Based on content from the following branch/commits:
https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Signed-off-by: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
---
 Platform/Socionext/DeveloperBox/DeveloperBox.dsc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc 
b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
index cc36c2ed17..80eb84d551 100644
--- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
+++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
@@ -174,6 +174,7 @@ [LibraryClasses.common.DXE_DRIVER]
   # Firmware update
   #
   CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.inf
+  
DisplayUpdateProgressLib|MdeModulePkg/Library/DisplayUpdateProgressLibGraphics/DisplayUpdateProgressLibGraphics.inf
   
EdkiiSystemCapsuleLib|SignedCapsulePkg/Library/EdkiiSystemCapsuleLib/EdkiiSystemCapsuleLib.inf
   
FmpAuthenticationLib|SecurityPkg/Library/FmpAuthenticationLibPkcs7/FmpAuthenticationLibPkcs7.inf
   
PlatformFlashAccessLib|Silicon/Socionext/SynQuacer/Library/SynQuacerPlatformFlashAccessLib/SynQuacerPlatformFlashAccessLib.inf
-- 
2.14.2.windows.3

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

[edk2] [edk2-platforms Patch V2 6/6] Socionext/SynQuacerEvalBoard: Add DisplayUpdateProgressLib mapping

[Kinney, Michael D]

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

Based on content from the following branch/commits:
https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Signed-off-by: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
---
 Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc 
b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
index f2c6aa15fe..9ee5a838ad 100644
--- a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
+++ b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
@@ -171,6 +171,7 @@ [LibraryClasses.common.DXE_DRIVER]
   # Firmware update
   #
   CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.inf
+  
DisplayUpdateProgressLib|MdeModulePkg/Library/DisplayUpdateProgressLibGraphics/DisplayUpdateProgressLibGraphics.inf
   
EdkiiSystemCapsuleLib|SignedCapsulePkg/Library/EdkiiSystemCapsuleLib/EdkiiSystemCapsuleLib.inf
   
FmpAuthenticationLib|SecurityPkg/Library/FmpAuthenticationLibPkcs7/FmpAuthenticationLibPkcs7.inf
   
PlatformFlashAccessLib|Silicon/Socionext/SynQuacer/Library/SynQuacerPlatformFlashAccessLib/SynQuacerPlatformFlashAccessLib.inf
-- 
2.14.2.windows.3

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

Re: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when enter/exit setup menu

[Kinney, Michael D]

Dandan Bi,

Is it possible to move the enter/exit event signaling
into the FormBrowwer SendForm() function?  The current
patch set adds these signal calls in all the places that
SendForm() is called and if one of these is missed, 
a notification will be missed.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Dandan Bi
> Sent: Wednesday, April 11, 2018 6:32 PM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric ; Gao, Liming
> 
> Subject: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal
> event when enter/exit setup menu
> 
> These changes are to support notify callbacks when
> enter/exit
> setup menu, since some driver may need to hook setup
> enter/exit
> points to do something.
> 
> We will signal setup enter/exit events for all setup
> menu
> enter/exit cases.Then the module which pay attention to
> these
> events can execute the callback.
> 
> Cc: Eric Dong 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi 
> 
> Dandan Bi (3):
>   MdeModulePkg/UiApp: Signal event when enter/exit setup
> menu
>   MdeModulePkg/BMMUiLib: Signal event when enter/exit
> setup menu
>   MdeModulePkg/BMUiLib: Signal event when enter/exit
> setup menu
> 
>  MdeModulePkg/Application/UiApp/FrontPage.c
> | 4 +++-
> 
> MdeModulePkg/Application/UiApp/FrontPageCustomizedUiSupp
> ort.c | 3 ++-
>  MdeModulePkg/Application/UiApp/UiApp.inf
> | 4 +++-
> 
> .../BootMaintenanceManagerUiLib/BootMaintenanceManagerUi
> Lib.inf   | 4 +++-
> 
> MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootOpt
> ion.c | 8 +++-
>  MdeModulePkg/Library/BootManagerUiLib/BootManager.c
> | 7 ++-
> 
> MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.i
> nf| 4 +++-
>  MdeModulePkg/MdeModulePkg.dec
> | 6 ++
>  8 files changed, 33 insertions(+), 7 deletions(-)
> 
> --
> 2.14.3.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch V2 0/9] Add DisplayUpdateProgressLib for capsules

[Kinney, Michael D]

I have also posted a branch for review. 

https://github.com/mdkinney/edk2/tree/Bug_801_DisplayUpdateProgressLib_V2

Mike


> -Original Message-
> From: Kinney, Michael D
> Sent: Wednesday, April 11, 2018 5:48 PM
> To: edk2-devel@lists.01.org
> Cc: Sean Brogan <sean.bro...@microsoft.com>; Zeng, Star
> <star.z...@intel.com>; Dong, Eric <eric.d...@intel.com>;
> Yao, Jiewen <jiewen@intel.com>; Wei, David
> <david@intel.com>; Guo, Mang <mang....@intel.com>;
> Steele, Kelly <kelly.ste...@intel.com>; Kinney, Michael
> D <michael.d.kin...@intel.com>
> Subject: [Patch V2 0/9] Add DisplayUpdateProgressLib for
> capsules
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=801
> 
> Based on content from:
> 
> https://github.com/Microsoft/MS_UEFI/blob/share/MsCapsul
> eSupport/MsCapsuleUpdatePkg/Include/Library/DisplayUpdat
> eProgressLib.h
> https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsul
> eSupport/MsCapsuleUpdatePkg/Library/DisplayUpdateProgres
> sGraphicsLib
> https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsul
> eSupport/MsCapsuleUpdatePkg/Library/DisplayUpdateProgres
> sTextLib
> 
> Updates for V2
> ==
> * Change DisplayUpdateProgressGraphicsLib to
> DisplayUpdateProgressLibGraphics
> * Change DisplayUpdateProgressTextLib to
> DisplayUpdateProgressLibText
> * Clarify that color in Firmware Management Progress
> Protocol is the foreground color
> * Add missing parameters to
> PerformFlashWriteWithProgress() function header.
> * Update PerformFlashWriteWithProgress() function header
> describing the use of
>   the start and end percentage values.
> * Update QuarkPlatformPkg
> PerformFlashWriteWithProgress() to call Progress() for
>   the end precentage.
> * Update Vlv2Tbl2DevicePkg
> PerformFlashWriteWithProgress() to call Progress()
>   for the end precentage.
> 
> Add DisplayUpdateProgressLib class along implementations
> for both graphical
> (Graphics Output Protocol based) and text (Simple Text
> Output Protocol based)
> consoles.  Also add the EDK II Firmware Management
> Progress Protocol that is an
> optional protocol that provides the progress bar color
> and a watchdog timeout
> value thaty can be used when a firmware image is updated
> in a firmware device.
> 
> * Add progress support to DxeCapsuleLibFmp
> * Add progress support to SystemFirmwareUpdateDxe
> * Add progress support to PlatformFlashAccessLib class
> and instances.
> * Reduce Print() calls during a firmware update.
> 
> Cc: Sean Brogan <sean.bro...@microsoft.com>
> Cc: Star Zeng <star.z...@intel.com>
> Cc: Eric Dong <eric.d...@intel.com>
> Cc: Jiewen Yao <jiewen@intel.com>
> Cc: David Wei <david@intel.com>
> Cc: Mang Guo <mang@intel.com>
> Cc: Kelly Steele <kelly.ste...@intel.com>
> 
> Signed-off-by: Michael D Kinney
> <michael.d.kin...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> 
> Kinney, Michael D (3):
>   QuarkPlatformPkg: Add DisplayUpdateProgressLib mapping
>   MdeModulePkg/DxeCapsuleLibFmp: Add progress bar
> support
>   SignedCapsulePkg/SystemFirmwareUpdateDxe: Use progress
> API
> 
> Michael D Kinney (6):
>   MdeModulePkg: Add DisplayUpdateProgressLib class
>   MdeModulePkg: Add DisplayUpdateProgressLib instances
>   Vlv2Tbl2DevicePkg: Add DisplayUpdateProgressLib
> mapping
>   SignedCapsulePkg/PlatformFlashAccessLib: Add progress
> API
>   Vlv2TbltDevicePkg/PlatformFlashAccessLib: Add progress
> API
>   QuarkPlatformPkg/PlatformFlashAccessLib: Add progress
> API
> 
>  .../Include/Library/DisplayUpdateProgressLib.h |
> 65 +++
>  .../Include/Protocol/FirmwareManagementProgress.h  |
> 51 +++
>  .../DisplayUpdateProgressLibGraphics.c |
> 475 +
>  .../DisplayUpdateProgressLibGraphics.inf   |
> 60 +++
>  .../DisplayUpdateProgressLibGraphics.uni   |
> 18 +
>  .../DisplayUpdateProgressLibText.c |
> 174 
>  .../DisplayUpdateProgressLibText.inf   |
> 53 +++
>  .../DisplayUpdateProgressLibText.uni   |
> 18 +
>  .../Library/DxeCapsuleLibFmp/DxeCapsuleLib.c   |
> 47 +-
>  .../Library/DxeCapsuleLibFmp/DxeCapsuleLib.inf |
> 8 +-
>  .../DxeCapsuleLibFmp/DxeCapsuleProcessLib.c|
> 84 +++-
>  .../DxeCapsuleLibFmp/DxeCapsuleProcessLibNull.c|
> 21 +-
>  .../DxeCapsuleLibFmp/DxeRuntimeCapsuleLib.inf  |
> 7 +-
>  MdeModulePkg/MdeModulePkg.dec  |
> 11 +
>  MdeModulePkg/MdeModulePkg.dsc  |
> 3 +
>  .../PlatformFlashAccessLibDxe.c  

[edk2] [Patch V2 0/9] Add DisplayUpdateProgressLib for capsules

[Kinney, Michael D]

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

Based on content from:

https://github.com/Microsoft/MS_UEFI/blob/share/MsCapsuleSupport/MsCapsuleUpdatePkg/Include/Library/DisplayUpdateProgressLib.h
https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport/MsCapsuleUpdatePkg/Library/DisplayUpdateProgressGraphicsLib
https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport/MsCapsuleUpdatePkg/Library/DisplayUpdateProgressTextLib

Updates for V2
==
* Change DisplayUpdateProgressGraphicsLib to DisplayUpdateProgressLibGraphics
* Change DisplayUpdateProgressTextLib to DisplayUpdateProgressLibText
* Clarify that color in Firmware Management Progress Protocol is the foreground 
color
* Add missing parameters to PerformFlashWriteWithProgress() function header.
* Update PerformFlashWriteWithProgress() function header describing the use of
  the start and end percentage values.
* Update QuarkPlatformPkg PerformFlashWriteWithProgress() to call Progress() for
  the end precentage.
* Update Vlv2Tbl2DevicePkg PerformFlashWriteWithProgress() to call Progress()
  for the end precentage.

Add DisplayUpdateProgressLib class along implementations for both graphical
(Graphics Output Protocol based) and text (Simple Text Output Protocol based)
consoles.  Also add the EDK II Firmware Management Progress Protocol that is an
optional protocol that provides the progress bar color and a watchdog timeout
value thaty can be used when a firmware image is updated in a firmware device.

* Add progress support to DxeCapsuleLibFmp
* Add progress support to SystemFirmwareUpdateDxe
* Add progress support to PlatformFlashAccessLib class and instances.
* Reduce Print() calls during a firmware update.

Cc: Sean Brogan <sean.bro...@microsoft.com>
Cc: Star Zeng <star.z...@intel.com>
Cc: Eric Dong <eric.d...@intel.com>
Cc: Jiewen Yao <jiewen@intel.com>
Cc: David Wei <david@intel.com>
Cc: Mang Guo <mang@intel.com>
Cc: Kelly Steele <kelly.ste...@intel.com>

Signed-off-by: Michael D Kinney <michael.d.kin...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1

Kinney, Michael D (3):
  QuarkPlatformPkg: Add DisplayUpdateProgressLib mapping
  MdeModulePkg/DxeCapsuleLibFmp: Add progress bar support
  SignedCapsulePkg/SystemFirmwareUpdateDxe: Use progress API

Michael D Kinney (6):
  MdeModulePkg: Add DisplayUpdateProgressLib class
  MdeModulePkg: Add DisplayUpdateProgressLib instances
  Vlv2Tbl2DevicePkg: Add DisplayUpdateProgressLib mapping
  SignedCapsulePkg/PlatformFlashAccessLib: Add progress API
  Vlv2TbltDevicePkg/PlatformFlashAccessLib: Add progress API
  QuarkPlatformPkg/PlatformFlashAccessLib: Add progress API

 .../Include/Library/DisplayUpdateProgressLib.h |  65 +++
 .../Include/Protocol/FirmwareManagementProgress.h  |  51 +++
 .../DisplayUpdateProgressLibGraphics.c | 475 +
 .../DisplayUpdateProgressLibGraphics.inf   |  60 +++
 .../DisplayUpdateProgressLibGraphics.uni   |  18 +
 .../DisplayUpdateProgressLibText.c | 174 
 .../DisplayUpdateProgressLibText.inf   |  53 +++
 .../DisplayUpdateProgressLibText.uni   |  18 +
 .../Library/DxeCapsuleLibFmp/DxeCapsuleLib.c   |  47 +-
 .../Library/DxeCapsuleLibFmp/DxeCapsuleLib.inf |   8 +-
 .../DxeCapsuleLibFmp/DxeCapsuleProcessLib.c|  84 +++-
 .../DxeCapsuleLibFmp/DxeCapsuleProcessLibNull.c|  21 +-
 .../DxeCapsuleLibFmp/DxeRuntimeCapsuleLib.inf  |   7 +-
 MdeModulePkg/MdeModulePkg.dec  |  11 +
 MdeModulePkg/MdeModulePkg.dsc  |   3 +
 .../PlatformFlashAccessLibDxe.c|  78 +++-
 QuarkPlatformPkg/Quark.dsc |   1 +
 .../Include/Library/PlatformFlashAccessLib.h   |  49 ++-
 .../PlatformFlashAccessLibNull.c   |  70 ++-
 .../SystemFirmwareUpdate/SystemFirmwareUpdateDxe.c |  90 +++-
 .../PlatformFlashAccessLib.c   | 102 +++--
 .../PlatformFlashAccessLib.inf |   3 +-
 Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc|   1 +
 Vlv2TbltDevicePkg/PlatformPkgIA32.dsc  |   1 +
 Vlv2TbltDevicePkg/PlatformPkgX64.dsc   |   1 +
 25 files changed, 1387 insertions(+), 104 deletions(-)
 create mode 100644 MdeModulePkg/Include/Library/DisplayUpdateProgressLib.h
 create mode 100644 MdeModulePkg/Include/Protocol/FirmwareManagementProgress.h
 create mode 100644 
MdeModulePkg/Library/DisplayUpdateProgressLibGraphics/DisplayUpdateProgressLibGraphics.c
 create mode 100644 
MdeModulePkg/Library/DisplayUpdateProgressLibGraphics/DisplayUpdateProgressLibGraphics.inf
 create mode 100644 
MdeModulePkg/Library/DisplayUpdateProgressLibGraphics/DisplayUpdateProgressLibGraphics.uni
 create mode 100644 
MdeModulePkg/Library/DisplayUpdateProgressLibText/DisplayUpdateProgressLibText.c
 create mode 100644 
MdeModulePkg/Library/DisplayUpdateProgressLibTe

[edk2] [Patch V2 1/9] MdeModulePkg: Add DisplayUpdateProgressLib class

[Kinney, Michael D]

From: Michael D Kinney 

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

Based on content from the following branch/commits:
https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport

Add the DisplayUpdateProgressLib class that is used
to inform the user of progress during updates of
firmware images in firmware devices.  A platform
specific instance of this library can be used to
customize how the user is informed of progress.

Add the EDK II Firmware Management Progress Protocol.
This is an optional protocol that must be installed
onto the same handle as a Firmware Management Protocol.
This new protocol provides the color of a progress
bar that allows different firmware devices to use
different colors during a firmware update.  It also
provides a watchdog timer value in seconds that is
armed each time the Progress() service passed
into Firmware Management Protocol SetImage()
is called.

Cc: Sean Brogan 
Cc: Star Zeng 
Cc: Eric Dong 
Signed-off-by: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
---
 .../Include/Library/DisplayUpdateProgressLib.h | 65 ++
 .../Include/Protocol/FirmwareManagementProgress.h  | 51 +
 MdeModulePkg/MdeModulePkg.dec  | 11 
 3 files changed, 127 insertions(+)
 create mode 100644 MdeModulePkg/Include/Library/DisplayUpdateProgressLib.h
 create mode 100644 MdeModulePkg/Include/Protocol/FirmwareManagementProgress.h

diff --git a/MdeModulePkg/Include/Library/DisplayUpdateProgressLib.h 
b/MdeModulePkg/Include/Library/DisplayUpdateProgressLib.h
new file mode 100644
index 00..ad1f2cae38
--- /dev/null
+++ b/MdeModulePkg/Include/Library/DisplayUpdateProgressLib.h
@@ -0,0 +1,65 @@
+/** @file
+  Provides services to display completion progress when processing a
+  firmware update that updates the firmware image in a firmware device.
+  A platform may provide its own instance of this library class to custoimize
+  how a user is informed of completion progress.
+
+  Copyright (c) 2016, Microsoft Corporation
+  Copyright (c) 2018, Intel Corporation. All rights reserved.
+
+  All rights reserved.
+  Redistribution and use in source and binary forms, with or without
+  modification, are permitted provided that the following conditions are met:
+  1. Redistributions of source code must retain the above copyright notice,
+  this list of conditions and the following disclaimer.
+  2. Redistributions in binary form must reproduce the above copyright notice,
+  this list of conditions and the following disclaimer in the documentation
+   and/or other materials provided with the distribution.
+
+  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" 
AND
+  ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+  WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 
DISCLAIMED.
+  IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY 
DIRECT,
+  INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES 
(INCLUDING,
+  BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY 
OF
+  LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING 
NEGLIGENCE
+  OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+  ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+**/
+
+#ifndef __DISPLAY_PROGRESS_LIB__
+#define __DISPLAY_PROGRESS_LIB__
+
+#include 
+
+/**
+  Indicates the current completion progress of a firmware update.
+
+  @param[in] Completion  A value between 0 and 100 indicating the current
+ completion progress of a firmware update.  This
+ value must the the same or higher than previous
+ calls to this service.  The first call of 0 or a
+ value of 0 after reaching a value of 100 resets
+ the progress indicator to 0.
+  @param[in] Color   Color of the progress indicator.  Only used when
+ Completion is 0 to set the color of the progress
+ indicator.  If Color is NULL, then the default color
+ is used.
+
+  @retval EFI_SUCCESSProgress displayed successfully.
+  @retval EFI_INVALID_PARAMETER  Completion is not in range 0..100.
+  @retval EFI_INVALID_PARAMETER  Completion is less than Completion value from
+ a previous call to this service.
+  @retval EFI_NOT_READY  The device used to indicate progress is not
+ available.
+**/
+EFI_STATUS
+EFIAPI
+DisplayUpdateProgress (
+  IN UINTNCompletion,
+  IN EFI_GRAPHICS_OUTPUT_BLT_PIXEL_UNION  *Color   

[edk2] [edk2-platforms Patch V2 3/6] SynQuacer/PlatformFlashAccessLib: Add progress API

[Kinney, Michael D]

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

Add PerformFlashWriteWithProgress() to the PlatformFlashAccessLib.
This allows the platform to inform the user of progress when a
firmware storage device is being updated with a new firmware
image.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Signed-off-by: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
---
 .../SynQuacerPlatformFlashAccessLib.c  | 78 +++---
 1 file changed, 67 insertions(+), 11 deletions(-)

diff --git 
a/Silicon/Socionext/SynQuacer/Library/SynQuacerPlatformFlashAccessLib/SynQuacerPlatformFlashAccessLib.c
 
b/Silicon/Socionext/SynQuacer/Library/SynQuacerPlatformFlashAccessLib/SynQuacerPlatformFlashAccessLib.c
index fbb8f1f9e4..4cf8318a93 100644
--- 
a/Silicon/Socionext/SynQuacer/Library/SynQuacerPlatformFlashAccessLib/SynQuacerPlatformFlashAccessLib.c
+++ 
b/Silicon/Socionext/SynQuacer/Library/SynQuacerPlatformFlashAccessLib/SynQuacerPlatformFlashAccessLib.c
@@ -2,6 +2,7 @@
   Platform flash device access library for Socionext SynQuacer
 
   Copyright (c) 2016, Linaro, Ltd. All rights reserved.
+  Copyright (c) 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
@@ -117,13 +118,29 @@ GetFvbByAddress (
 }
 
 /**
-  Perform flash write operation.
+  Perform flash write operation with progress indicator.  The start and end
+  completion percentage values are passed into this function.  If the requested
+  flash write operation is broken up, then completion percentage between the
+  start and end values may be passed to the provided Progress function.  The
+  caller of this function is required to call the Progress function for the
+  start and end completion percentage values.  This allows the Progress,
+  StartPercentage, and EndPercentage parameters to be ignored if the requested
+  flash write operation can not be broken up
 
   @param[in] FirmwareType  The type of firmware.
   @param[in] FlashAddress  The address of flash device to be accessed.
   @param[in] FlashAddressType  The type of flash device address.
   @param[in] BufferThe pointer to the data buffer.
   @param[in] LengthThe length of data buffer in bytes.
+  @param[in] Progress  A function used report the progress of the
+   firmware update.  This is an optional parameter
+   that may be NULL.
+  @param[in] StartPercentage   The start completion percentage value that may
+   be used to report progress during the flash
+   write operation.
+  @param[in] EndPercentage The end completion percentage value that may
+   be used to report progress during the flash
+   write operation.
 
   @retval EFI_SUCCESS   The operation returns successfully.
   @retval EFI_WRITE_PROTECTED   The flash device is read only.
@@ -132,12 +149,15 @@ GetFvbByAddress (
 **/
 EFI_STATUS
 EFIAPI
-PerformFlashWrite (
-  IN PLATFORM_FIRMWARE_TYPE   FirmwareType,
-  IN EFI_PHYSICAL_ADDRESS FlashAddress,
-  IN FLASH_ADDRESS_TYPE   FlashAddressType,
-  IN VOID *Buffer,
-  IN UINTNLength
+PerformFlashWriteWithProgress (
+  IN PLATFORM_FIRMWARE_TYPE FirmwareType,
+  IN EFI_PHYSICAL_ADDRESS   FlashAddress,
+  IN FLASH_ADDRESS_TYPE FlashAddressType,
+  IN VOID   *Buffer,
+  IN UINTN  Length,
+  IN EFI_FIRMWARE_MANAGEMENT_UPDATE_IMAGE_PROGRESS  Progress,OPTIONAL
+  IN UINTN  StartPercentage,
+  IN UINTN  EndPercentage
   )
 {
   EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL  *Fvb;
@@ -150,7 +170,7 @@ PerformFlashWrite (
   EFI_GRAPHICS_OUTPUT_BLT_PIXEL_UNION Black;
   EFI_GRAPHICS_OUTPUT_BLT_PIXEL_UNION White;
   UINTN   Resolution;
-  UINTN   Progress;
+  UINTN   CurrentProgress;
   BOOLEAN HaveBootGraphics;
 
   Black.Raw = 0x;
@@ -228,7 +248,7 @@ PerformFlashWrite (
 
   if (HaveBootGraphics) {
 Resolution = (BlockSize * 100) / Length + 1;
-Progress = 0;
+CurrentProgress = 0;
 
 Status = BootLogoUpdateProgress (White.Pixel, Black.Pixel,
L"Updating firmware - please wait", Black.Pixel, 100, 0);
@@ -268,8 +288,8 @@ PerformFlashWrite (
 if (HaveBootGraphics) {
   Status = BootLogoUpdateProgress (White.Pixel, Black.Pixel,
 L"Updating firmware - please wait", White.Pixel,
-  

[edk2] [edk2-platforms Patch V2 0/6] Add DisplayUpdateProgressLib for capsules

[Kinney, Michael D]

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

Based on content from the following branch/commits:
https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport

* Add DisplayUpdateProgressLib mappings for platforms that use the
  DxeCapsuleLibFmp.
* Add the PerformFlashWriteWithProgress() API to all PlatformFlashAccessLib
  instances.

The PlatformFlashAccessLib instances have not been updated to use the Progress()
API.  The current progress behavior is preserved.  The PlatformFlashAccessLib
instances could be updated to remove the current progress indication and use the
progress bar provided by DxeCapsuleLibFmp and DisplayUpdateProgressLib.

Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
Cc: Leif Lindholm <leif.lindh...@linaro.org>
Signed-off-by: Michael D Kinney <michael.d.kin...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1

Kinney, Michael D (6):
  Styx/PlatformFlashAccessLib: Add progress API
  Hisilicon/PlatformFlashAccessLib: Add progress API
  SynQuacer/PlatformFlashAccessLib: Add progress API
  AMD/OverdriveBoard: Add DisplayUpdateProgressLib mapping
  Socionext/DeveloperBox: Add DisplayUpdateProgressLib mapping
  Socionext/SynQuacerEvalBoard: Add DisplayUpdateProgressLib mapping

 Platform/AMD/OverdriveBoard/OverdriveBoard.dsc |  1 +
 Platform/Socionext/DeveloperBox/DeveloperBox.dsc   |  1 +
 .../SynQuacerEvalBoard/SynQuacerEvalBoard.dsc  |  1 +
 .../StyxPlatformFlashAccessLib.c   | 70 +--
 .../PlatformFlashAccessLibDxe.c| 71 +---
 .../SynQuacerPlatformFlashAccessLib.c  | 78 +++---
 6 files changed, 196 insertions(+), 26 deletions(-)

-- 
2.14.2.windows.3

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

Re: [edk2] [edk2-platforms Patch V2 3/6] SynQuacer/PlatformFlashAccessLib: Add progress API

[Kinney, Michael D]

Ard,

I agree.  I mentioned it in the patch summary.  I will
add it to the commit log for each patch.

Thanks,

Mike

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Wednesday, April 11, 2018 11:18 PM
> To: Kinney, Michael D <michael.d.kin...@intel.com>
> Cc: edk2-devel@lists.01.org; Leif Lindholm
> <leif.lindh...@linaro.org>
> Subject: Re: [edk2-platforms Patch V2 3/6]
> SynQuacer/PlatformFlashAccessLib: Add progress API
> 
> On 12 April 2018 at 03:01, Kinney, Michael D
> <michael.d.kin...@intel.com> wrote:
> > https://bugzilla.tianocore.org/show_bug.cgi?id=801
> >
> > Add PerformFlashWriteWithProgress() to the
> PlatformFlashAccessLib.
> > This allows the platform to inform the user of
> progress when a
> > firmware storage device is being updated with a new
> firmware
> > image.
> >
> > Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
> > Cc: Leif Lindholm <leif.lindh...@linaro.org>
> > Signed-off-by: Michael D Kinney
> <michael.d.kin...@intel.com>
> > Contributed-under: TianoCore Contribution Agreement
> 1.1
> 
> IIUC, this is the bare minimum to get it building again,
> and we'll
> need to replace the existing progress indicator
> implementation with
> calls into the generic on, right? That's fine, but it
> would be useful
> to mention this in the commit log.
> 
> 
> > ---
> >  .../SynQuacerPlatformFlashAccessLib.c  |
> 78 +++---
> >  1 file changed, 67 insertions(+), 11 deletions(-)
> >
> > diff --git
> a/Silicon/Socionext/SynQuacer/Library/SynQuacerPlatformF
> lashAccessLib/SynQuacerPlatformFlashAccessLib.c
> b/Silicon/Socionext/SynQuacer/Library/SynQuacerPlatformF
> lashAccessLib/SynQuacerPlatformFlashAccessLib.c
> > index fbb8f1f9e4..4cf8318a93 100644
> > ---
> a/Silicon/Socionext/SynQuacer/Library/SynQuacerPlatformF
> lashAccessLib/SynQuacerPlatformFlashAccessLib.c
> > +++
> b/Silicon/Socionext/SynQuacer/Library/SynQuacerPlatformF
> lashAccessLib/SynQuacerPlatformFlashAccessLib.c
> > @@ -2,6 +2,7 @@
> >Platform flash device access library for Socionext
> SynQuacer
> >
> >Copyright (c) 2016, Linaro, Ltd. All rights
> reserved.
> > +  Copyright (c) 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
> > @@ -117,13 +118,29 @@ GetFvbByAddress (
> >  }
> >
> >  /**
> > -  Perform flash write operation.
> > +  Perform flash write operation with progress
> indicator.  The start and end
> > +  completion percentage values are passed into this
> function.  If the requested
> > +  flash write operation is broken up, then completion
> percentage between the
> > +  start and end values may be passed to the provided
> Progress function.  The
> > +  caller of this function is required to call the
> Progress function for the
> > +  start and end completion percentage values.  This
> allows the Progress,
> > +  StartPercentage, and EndPercentage parameters to be
> ignored if the requested
> > +  flash write operation can not be broken up
> >
> >@param[in] FirmwareType  The type of firmware.
> >@param[in] FlashAddress  The address of flash
> device to be accessed.
> >@param[in] FlashAddressType  The type of flash
> device address.
> >@param[in] BufferThe pointer to the
> data buffer.
> >@param[in] LengthThe length of data
> buffer in bytes.
> > +  @param[in] Progress  A function used report
> the progress of the
> > +   firmware update.  This
> is an optional parameter
> > +   that may be NULL.
> > +  @param[in] StartPercentage   The start completion
> percentage value that may
> > +   be used to report
> progress during the flash
> > +   write operation.
> > +  @param[in] EndPercentage The end completion
> percentage value that may
> > +   be used to report
> progress during the flash
> > +   write operation.
> >
> >@retval EFI_SUCCESS   The operation returns
> successfully.
> >@retval EFI_WRITE_PROTECTED   The flash device is
> read only.
> > @@ -132,12 +149,15 @@ GetFvbByAddress (
> >  **/
> >  EFI_STATUS
> >  EFIAPI
> > -PerformFlashWrite (
> > -  IN PLAT

Re: [edk2] [PATCH] Maintainers.txt: add Laszlo Ersek to stewards

[Kinney, Michael D]

Welcome Laszlo!

Reviewed-by: Michael D Kinney <michael.d.kin...@intel.com>

Mike

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Friday, April 13, 2018 12:26 PM
> To: edk2-devel@lists.01.org
> Cc: Andrew Fish <af...@apple.com>; Laszlo Ersek
> <ler...@redhat.com>; Kinney, Michael D
> <michael.d.kin...@intel.com>
> Subject: [PATCH] Maintainers.txt: add Laszlo Ersek to
> stewards
> 
> Cc: Andrew Fish <af...@apple.com>
> Cc: Laszlo Ersek <ler...@redhat.com>
> Cc: Michael D Kinney <michael.d.kin...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Leif Lindholm <leif.lindh...@linaro.org>
> ---
>  Maintainers.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 256133810f..7295cd6b83 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -41,6 +41,7 @@ T: svn (read-only, deprecated) -
> https://svn.code.sf.net/p/edk2/code/trunk/edk2
>  Tianocore Stewards
>  --
>  M: Andrew Fish <af...@apple.com>
> +M: Laszlo Ersek <ler...@redhat.com>
>  M: Leif Lindholm <leif.lindh...@linaro.org>
>  M: Michael D Kinney <michael.d.kin...@intel.com>
> 
> --
> 2.11.0

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

Re: [edk2] [PATCH] MdePkg: add big-endian MMIO BaseBeIoLib

[Kinney, Michael D]

Leif,

Yes.  I think the single swap lib is sufficient for
the specific use case.

We can wait until there is a request to add support 
for a BE CPU to look at a more complete solution to
reusing the same module sources for all combinations
of CPU and I/O endianness.

Thanks,

Mike

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Tuesday, April 17, 2018 6:27 AM
> To: Kinney, Michael D <michael.d.kin...@intel.com>;
> Gao, Liming <liming@intel.com>; Laszlo Ersek
> <ler...@redhat.com>
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH] MdePkg: add big-endian MMIO
> BaseBeIoLib
> 
> On Mon, Apr 16, 2018 at 10:42:26PM +0200, Laszlo Ersek
> wrote:
> > On 04/16/18 16:34, Michael Brown wrote:
> > > On 16/04/18 15:10, Kinney, Michael D wrote:
> > >> I agree that the opposite use case is a BE CPU
> > >> needing a LE operation.
> > >>
> > >> I think we only need a single lib class and lib
> > >> Instance that does the byte swap and we should
> > >> not use Le or Be in any of the names of the class,
> > >> instance, or APIs.  Just "Swap".
> > >
> > > I may have misunderstood, but wouldn't using "Swap"
> within the API names
> > > effectively encode knowledge of the endianness of
> the _build_ platform
> > > into the source code?  This would prevent the same
> source code being
> > > built for both little-endian and big-endian CPUs.
> >
> > Under this scenario, all drivers meant to be portable
> to both byte
> > orders would have to:
> > - link against both IoLib and IoSwapLib,
> > - determine at device binding time, from CPU
> endianness and device
> >   endianness combined, whether swapping was needed
> for that device,
> > - call the IoLib or IoSwapLib APIs through wrapper
> functions, or
> >   function pointers.
> 
> Yes. I'm thinking that is a good enough solution for
> this type of
> situation and I overcomplicated things. Apologies for
> that.
> 
> We are talking about the relatively unusual situation
> where an
> otherwise driver-compatible device can in some
> platforms be of a
> different endianness than in others.
> 
> So, Mike, Liming - would you be OK with a solution
> similar to
> https://www.mail-archive.com/edk2-
> de...@lists.01.org/msg36520.html.
> 
> /
> Leif
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC v2 0/4] Add FmpDevicePkg

[Kinney, Michael D]

Star,

Thanks for the feedback.  I think the "BuildTime" helps
clarify the scope and usage of this PCD.  The 
LowestSupportedVersion name is used in many places.  
The name of this PCD clarifies that this is the 
LowestSupportedVersion value provided at the time the 
FmpDxe module was built and is only used when the 
LowestSupportedVersion value is not available from 
any other source.

Mike


> -Original Message-
> From: Zeng, Star
> Sent: Thursday, April 19, 2018 9:53 PM
> To: Yao, Jiewen <jiewen@intel.com>; Kinney, Michael
> D <michael.d.kin...@intel.com>; edk2-devel@lists.01.org
> Cc: Zeng, Star <star.z...@intel.com>
> Subject: RE: [RFC v2 0/4] Add FmpDevicePkg
> 
> I had a minor comment at
> https://lists.01.org/pipermail/edk2-devel/2018-
> April/023570.html to
> PcdFmpDeviceBuildTimeLowestSupportedVersion before.
> 
> 
> Thanks,
> Star
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Yao, Jiewen
> Sent: Friday, April 20, 2018 12:18 PM
> To: Kinney, Michael D <michael.d.kin...@intel.com>;
> edk2-devel@lists.01.org
> Subject: Re: [edk2] [RFC v2 0/4] Add FmpDevicePkg
> 
> Thanks Mike.
> 
> I am a little confused about naming:
> CheckLowestSupportedVersion() and
> LockFmpDeviceAtLockEventGuid().
> 
> At the first glace, I think those 2 API will *do the
> check* for LSV, or *do the lock* FMP.
> 
> But actually, it returns a state to indicate *if* the
> caller need check LSV and *if* the caller need lock FMP.
> 
> Can we rename them to be
> NeedCheckLowestSupportedVersion() and
> NeedLockFmpDeviceAtLockEventGuid() ?
> 
> 
> Other update seems good. Reviewed-by:
> jiewen@intel.com
> 
> 
> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: Kinney, Michael D
> > Sent: Wednesday, April 18, 2018 5:05 AM
> > To: edk2-devel@lists.01.org
> > Cc: Sean Brogan <sean.bro...@microsoft.com>; Yao,
> Jiewen
> > <jiewen@intel.com>; Kinney, Michael D
> <michael.d.kin...@intel.com>
> > Subject: [RFC v2 0/4] Add FmpDevicePkg
> >
> > https://bugzilla.tianocore.org/show_bug.cgi?id=922
> >
> > Changes in V2
> > =
> > * FmpDevicePkg DEC file
> >   + Change PcdFmpDeviceSystemResetRequired from
> FeatureFlag
> > to FixedAtBuild
> >   + Add PcdFmpDeviceTestKeySha256Digest for test key
> detection.
> > Set to {0} to disable test key detection.
> > * FmpDevicePkg DSC file
> >   + Fix ARM and AARCH64 build issues
> >   + Update DisplayUpdateProgressLib mappings to match
> patches in
> > Bug_801_DisplayUpdateProgressLib_V2
> > * FmpDeviceLib Class and Instance
> >   + Update FmpDeviceGetSize() to return EFI_STATUS
> >   + Update FmpDeviceGetAttributes() to return
> EFI_STATUS
> >   + Update FmpDeviceGetVersionString() to return
> EFI_STATUS
> > * FmpDxe
> >   + Set depex to Variable Arch Write Protocol and
> Variable Lock Protocol
> >   + Break out test key detection in FmpDxe into
> DetectTestKey.c
> >   + Change LockAllVars() to LockAllFmpVariables()
> >   + Update LockAllFmpVariables() to lock each of the
> UEFI variables used.
> >   + Always lock UEFI variables when
> PcdFmpDeviceLockEventGuid is signaled
> >   + Remove ComputeVersionName().  FmpDeviceLib must
> provide version
> > string
> >
> > Based on content from the following branch:
> >
> >
> https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsul
> eSupport/MsCap
> > su
> > leUpdatePkg
> >
> > Branch for review:
> >
> >
> https://github.com/mdkinney/edk2/tree/Bug_922_FmpDeviceP
> kg_V2
> >
> > This package provides an implementation of a Firmware
> Management
> > Protocol instance that supports the update of firmware
> storage devices
> > using UEFI Capsules.  The behavior of the Firmware
> Management Protocol
> > instance is customized using libraries and PCDs.
> >
> > Cc: Sean Brogan <sean.bro...@microsoft.com>
> > Cc: Jiewen Yao <jiewen@intel.com>
> > Contributed-under: TianoCore Contribution Agreement
> 1.1
> > Signed-off-by: Michael D Kinney
> <michael.d.kin...@intel.com>
> >
> > Kinney, Michael D (4):
> >   FmpDevicePkg: Add package, library classes, and PCDs
> >   FmpDevicePkg: Add library instances
> >   FmpDevicePkg: Add FmpDxe module
> >   FmpDevicePkg: Add DSC file to build all package
> components
> >
> >  FmpDevicePkg/FmpDevicePkg.dec  |
> 132 ++
> >  FmpDevicePkg/FmpDevic

Re: [edk2] [RFC v2 0/4] Add FmpDevicePkg

[Kinney, Michael D]

How about:

LowestSupportedVersionCheckRequired()
LockFmpDeviceAtLockEventGuidRequired()

Mike

> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, April 19, 2018 9:18 PM
> To: Kinney, Michael D <michael.d.kin...@intel.com>;
> edk2-devel@lists.01.org
> Cc: Sean Brogan <sean.bro...@microsoft.com>
> Subject: RE: [RFC v2 0/4] Add FmpDevicePkg
> 
> Thanks Mike.
> 
> I am a little confused about naming:
> CheckLowestSupportedVersion() and
> LockFmpDeviceAtLockEventGuid().
> 
> At the first glace, I think those 2 API will *do the
> check* for LSV, or *do the lock* FMP.
> 
> But actually, it returns a state to indicate *if* the
> caller need check LSV and *if* the caller need lock FMP.
> 
> Can we rename them to be
> NeedCheckLowestSupportedVersion() and
> NeedLockFmpDeviceAtLockEventGuid() ?
> 
> 
> Other update seems good. Reviewed-by:
> jiewen....@intel.com
> 
> 
> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: Kinney, Michael D
> > Sent: Wednesday, April 18, 2018 5:05 AM
> > To: edk2-devel@lists.01.org
> > Cc: Sean Brogan <sean.bro...@microsoft.com>; Yao,
> Jiewen
> > <jiewen@intel.com>; Kinney, Michael D
> <michael.d.kin...@intel.com>
> > Subject: [RFC v2 0/4] Add FmpDevicePkg
> >
> > https://bugzilla.tianocore.org/show_bug.cgi?id=922
> >
> > Changes in V2
> > =
> > * FmpDevicePkg DEC file
> >   + Change PcdFmpDeviceSystemResetRequired from
> FeatureFlag
> > to FixedAtBuild
> >   + Add PcdFmpDeviceTestKeySha256Digest for test key
> detection.
> > Set to {0} to disable test key detection.
> > * FmpDevicePkg DSC file
> >   + Fix ARM and AARCH64 build issues
> >   + Update DisplayUpdateProgressLib mappings to match
> patches in
> > Bug_801_DisplayUpdateProgressLib_V2
> > * FmpDeviceLib Class and Instance
> >   + Update FmpDeviceGetSize() to return EFI_STATUS
> >   + Update FmpDeviceGetAttributes() to return
> EFI_STATUS
> >   + Update FmpDeviceGetVersionString() to return
> EFI_STATUS
> > * FmpDxe
> >   + Set depex to Variable Arch Write Protocol and
> Variable Lock Protocol
> >   + Break out test key detection in FmpDxe into
> DetectTestKey.c
> >   + Change LockAllVars() to LockAllFmpVariables()
> >   + Update LockAllFmpVariables() to lock each of the
> UEFI variables used.
> >   + Always lock UEFI variables when
> PcdFmpDeviceLockEventGuid is signaled
> >   + Remove ComputeVersionName().  FmpDeviceLib must
> provide version
> > string
> >
> > Based on content from the following branch:
> >
> >
> https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsul
> eSupport/MsCapsu
> > leUpdatePkg
> >
> > Branch for review:
> >
> >
> https://github.com/mdkinney/edk2/tree/Bug_922_FmpDeviceP
> kg_V2
> >
> > This package provides an implementation of a Firmware
> Management Protocol
> > instance that supports the update of firmware storage
> devices using UEFI
> > Capsules.  The behavior of the Firmware Management
> Protocol instance is
> > customized using libraries and PCDs.
> >
> > Cc: Sean Brogan <sean.bro...@microsoft.com>
> > Cc: Jiewen Yao <jiewen@intel.com>
> > Contributed-under: TianoCore Contribution Agreement
> 1.1
> > Signed-off-by: Michael D Kinney
> <michael.d.kin...@intel.com>
> >
> > Kinney, Michael D (4):
> >   FmpDevicePkg: Add package, library classes, and PCDs
> >   FmpDevicePkg: Add library instances
> >   FmpDevicePkg: Add FmpDxe module
> >   FmpDevicePkg: Add DSC file to build all package
> components
> >
> >  FmpDevicePkg/FmpDevicePkg.dec  |
> 132 ++
> >  FmpDevicePkg/FmpDevicePkg.dsc  |
> 134 ++
> >  FmpDevicePkg/FmpDevicePkg.uni  |
> 80 ++
> >  FmpDevicePkg/FmpDevicePkgExtra.uni |
> 18 +
> >  FmpDevicePkg/FmpDxe/DetectTestKey.c|
> 166 +++
> >  FmpDevicePkg/FmpDxe/FmpDxe.c   |
> 1451
> > 
> >  FmpDevicePkg/FmpDxe/FmpDxe.inf |
> 93 ++
> >  FmpDevicePkg/FmpDxe/FmpDxe.uni |
> 20 +
> >  FmpDevicePkg/FmpDxe/FmpDxeExtra.uni|
> 18 +
> >  FmpDevicePkg/FmpDxe/FmpDxeLib.inf  |
> 90 ++
> >  FmpDevicePkg/FmpDxe/VariableSupport.c  |
> 461 +++
> >  FmpDevicePkg/FmpDxe/VariableSupport.h  |
> 180 +++
> >  .../Include/Library/CapsuleUpdatePolicyLib.h

Re: [edk2] [Patch V2 0/9] Add DisplayUpdateProgressLib for capsules

[Kinney, Michael D]

Star,

I did consider a PCD based method and I even prototyped
it.  It does work.  However, it uses the Dynamic PCD memory
database as a shared resource between all the FMP modules
and depends on the FMP modules to set the PCDs when their
SetImage() service is called.  Since not all FMP modules
may need to use these settings, the PCDs may contain values
from other FMP modules that were processing capsules in
the same boot.  This requires the caller of SetImage() to
always reset the PCDs each time SetImage() is called for
any FMP.

The Protocol per FMP device provides the information
for all FMP consumers on the same handle as the FMP
Protocol so the rules for usage are clear from a consumer
perspective.

Mike


> -Original Message-
> From: Zeng, Star
> Sent: Thursday, April 19, 2018 9:51 PM
> To: Yao, Jiewen <jiewen....@intel.com>; Kinney, Michael
> D <michael.d.kin...@intel.com>; edk2-devel@lists.01.org
> Cc: Sean Brogan <sean.bro...@microsoft.com>; Dong, Eric
> <eric.d...@intel.com>; Wei, David <david@intel.com>;
> Guo, Mang <mang@intel.com>; Steele, Kelly
> <kelly.ste...@intel.com>; Zeng, Star
> <star.z...@intel.com>
> Subject: RE: [Patch V2 0/9] Add DisplayUpdateProgressLib
> for capsules
> 
> I also had another comment to the protocol at
> https://lists.01.org/pipermail/edk2-devel/2018-
> April/023720.html before.
> 
> Thanks,
> Star
> -----Original Message-
> From: Yao, Jiewen
> Sent: Friday, April 20, 2018 12:23 PM
> To: Kinney, Michael D <michael.d.kin...@intel.com>;
> edk2-devel@lists.01.org
> Cc: Sean Brogan <sean.bro...@microsoft.com>; Zeng, Star
> <star.z...@intel.com>; Dong, Eric <eric.d...@intel.com>;
> Wei, David <david@intel.com>; Guo, Mang
> <mang@intel.com>; Steele, Kelly
> <kelly.ste...@intel.com>
> Subject: RE: [Patch V2 0/9] Add DisplayUpdateProgressLib
> for capsules
> 
> Thanks Mike.
> 
> I still think we should add a Version flag for
> EDKII_FIRMWARE_MANAGEMENT_PROGRESS_PROTOCOL for future
> extension, as we discussed in V1.
> 
> Other update seems good to me. Reviewed-by:
> jiewen@intel.com
> 
> 
> Thank you
> Yao Jiewen
> 
> 
> > -Original Message-
> > From: Kinney, Michael D
> > Sent: Thursday, April 12, 2018 8:48 AM
> > To: edk2-devel@lists.01.org
> > Cc: Sean Brogan <sean.bro...@microsoft.com>; Zeng,
> Star
> > <star.z...@intel.com>; Dong, Eric
> <eric.d...@intel.com>; Yao, Jiewen
> > <jiewen@intel.com>; Wei, David
> <david@intel.com>; Guo, Mang
> > <mang@intel.com>; Steele, Kelly
> <kelly.ste...@intel.com>; Kinney,
> > Michael D <michael.d.kin...@intel.com>
> > Subject: [Patch V2 0/9] Add DisplayUpdateProgressLib
> for capsules
> >
> > https://bugzilla.tianocore.org/show_bug.cgi?id=801
> >
> > Based on content from:
> >
> >
> https://github.com/Microsoft/MS_UEFI/blob/share/MsCapsul
> eSupport/MsCap
> > s
> uleUpdatePkg/Include/Library/DisplayUpdateProgressLib.h
> >
> https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsul
> eSupport/MsCap
> > su
> leUpdatePkg/Library/DisplayUpdateProgressGraphicsLib
> >
> https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsul
> eSupport/MsCap
> > su leUpdatePkg/Library/DisplayUpdateProgressTextLib
> >
> > Updates for V2
> > ==
> > * Change DisplayUpdateProgressGraphicsLib to
> > DisplayUpdateProgressLibGraphics
> > * Change DisplayUpdateProgressTextLib to
> DisplayUpdateProgressLibText
> > * Clarify that color in Firmware Management Progress
> Protocol is the
> > foreground color
> > * Add missing parameters to
> PerformFlashWriteWithProgress() function header.
> > * Update PerformFlashWriteWithProgress() function
> header describing
> > the use of
> >   the start and end percentage values.
> > * Update QuarkPlatformPkg
> PerformFlashWriteWithProgress() to call
> > Progress() for
> >   the end precentage.
> > * Update Vlv2Tbl2DevicePkg
> PerformFlashWriteWithProgress() to call Progress()
> >   for the end precentage.
> >
> > Add DisplayUpdateProgressLib class along
> implementations for both
> > graphical (Graphics Output Protocol based) and text
> (Simple Text
> > Output Protocol based) consoles.  Also add the EDK II
> Firmware
> > Management Progress Protocol that is an optional
> protocol that
> > provides the progress bar color and a watchdog timeout
> value thaty can
> > be used when a firmware image is updated in a firmware
> device.
> >
> > * Add p

Re: [edk2] [Patch V2 0/9] Add DisplayUpdateProgressLib for capsules

[Kinney, Michael D]

Jiewen,

Thanks for the reminder.  

I will add a 32-bit Version field.

Mike

> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, April 19, 2018 9:23 PM
> To: Kinney, Michael D <michael.d.kin...@intel.com>;
> edk2-devel@lists.01.org
> Cc: Sean Brogan <sean.bro...@microsoft.com>; Zeng, Star
> <star.z...@intel.com>; Dong, Eric <eric.d...@intel.com>;
> Wei, David <david@intel.com>; Guo, Mang
> <mang@intel.com>; Steele, Kelly
> <kelly.ste...@intel.com>
> Subject: RE: [Patch V2 0/9] Add DisplayUpdateProgressLib
> for capsules
> 
> Thanks Mike.
> 
> I still think we should add a Version flag for
> EDKII_FIRMWARE_MANAGEMENT_PROGRESS_PROTOCOL for future
> extension, as we discussed in V1.
> 
> Other update seems good to me. Reviewed-by:
> jiewen....@intel.com
> 
> 
> Thank you
> Yao Jiewen
> 
> 
> > -Original Message-
> > From: Kinney, Michael D
> > Sent: Thursday, April 12, 2018 8:48 AM
> > To: edk2-devel@lists.01.org
> > Cc: Sean Brogan <sean.bro...@microsoft.com>; Zeng,
> Star
> > <star.z...@intel.com>; Dong, Eric
> <eric.d...@intel.com>; Yao, Jiewen
> > <jiewen@intel.com>; Wei, David
> <david@intel.com>; Guo, Mang
> > <mang@intel.com>; Steele, Kelly
> <kelly.ste...@intel.com>; Kinney, Michael
> > D <michael.d.kin...@intel.com>
> > Subject: [Patch V2 0/9] Add DisplayUpdateProgressLib
> for capsules
> >
> > https://bugzilla.tianocore.org/show_bug.cgi?id=801
> >
> > Based on content from:
> >
> >
> https://github.com/Microsoft/MS_UEFI/blob/share/MsCapsul
> eSupport/MsCaps
> >
> uleUpdatePkg/Include/Library/DisplayUpdateProgressLib.h
> >
> https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsul
> eSupport/MsCapsu
> > leUpdatePkg/Library/DisplayUpdateProgressGraphicsLib
> >
> https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsul
> eSupport/MsCapsu
> > leUpdatePkg/Library/DisplayUpdateProgressTextLib
> >
> > Updates for V2
> > ==
> > * Change DisplayUpdateProgressGraphicsLib to
> > DisplayUpdateProgressLibGraphics
> > * Change DisplayUpdateProgressTextLib to
> DisplayUpdateProgressLibText
> > * Clarify that color in Firmware Management Progress
> Protocol is the
> > foreground color
> > * Add missing parameters to
> PerformFlashWriteWithProgress() function header.
> > * Update PerformFlashWriteWithProgress() function
> header describing the use
> > of
> >   the start and end percentage values.
> > * Update QuarkPlatformPkg
> PerformFlashWriteWithProgress() to call Progress()
> > for
> >   the end precentage.
> > * Update Vlv2Tbl2DevicePkg
> PerformFlashWriteWithProgress() to call Progress()
> >   for the end precentage.
> >
> > Add DisplayUpdateProgressLib class along
> implementations for both graphical
> > (Graphics Output Protocol based) and text (Simple Text
> Output Protocol based)
> > consoles.  Also add the EDK II Firmware Management
> Progress Protocol that is
> > an
> > optional protocol that provides the progress bar color
> and a watchdog timeout
> > value thaty can be used when a firmware image is
> updated in a firmware device.
> >
> > * Add progress support to DxeCapsuleLibFmp
> > * Add progress support to SystemFirmwareUpdateDxe
> > * Add progress support to PlatformFlashAccessLib class
> and instances.
> > * Reduce Print() calls during a firmware update.
> >
> > Cc: Sean Brogan <sean.bro...@microsoft.com>
> > Cc: Star Zeng <star.z...@intel.com>
> > Cc: Eric Dong <eric.d...@intel.com>
> > Cc: Jiewen Yao <jiewen@intel.com>
> > Cc: David Wei <david@intel.com>
> > Cc: Mang Guo <mang@intel.com>
> > Cc: Kelly Steele <kelly.ste...@intel.com>
> >
> > Signed-off-by: Michael D Kinney
> <michael.d.kin...@intel.com>
> > Contributed-under: TianoCore Contribution Agreement
> 1.1
> >
> > Kinney, Michael D (3):
> >   QuarkPlatformPkg: Add DisplayUpdateProgressLib
> mapping
> >   MdeModulePkg/DxeCapsuleLibFmp: Add progress bar
> support
> >   SignedCapsulePkg/SystemFirmwareUpdateDxe: Use
> progress API
> >
> > Michael D Kinney (6):
> >   MdeModulePkg: Add DisplayUpdateProgressLib class
> >   MdeModulePkg: Add DisplayUpdateProgressLib instances
> >   Vlv2Tbl2DevicePkg: Add DisplayUpdateProgressLib
> mapping
> >   SignedCapsulePkg/PlatformFlashAccessLib: Add
> progress API
> >   Vlv2TbltDevicePkg/Platfo

Re: [edk2] [PATCH] MdePkg: add big-endian MMIO BaseBeIoLib

[Kinney, Michael D]

Leif,

I agree that the opposite use case is a BE CPU
needing a LE operation. 

I think we only need a single lib class and lib
Instance that does the byte swap and we should
not use Le or Be in any of the names of the class,
instance, or APIs.  Just "Swap".

The 4 cases

* LE CPU, LE I/O.  Use BaseIoLib
* BE CPU, BE I/O.  Use BaseIoLib
* LE CPU, BE I/O.  Use BaseIoSwapLib
* BE CPU, LE I/O.  Use BaseIoSwapLib

Mike


> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Monday, April 16, 2018 3:07 AM
> To: Kinney, Michael D <michael.d.kin...@intel.com>
> Cc: edk2-devel@lists.01.org; Laszlo Ersek
> <ler...@redhat.com>; Gao, Liming <liming@intel.com>
> Subject: Re: [edk2] [PATCH] MdePkg: add big-endian MMIO
> BaseBeIoLib
> 
> On Fri, Apr 13, 2018 at 11:32:35PM +, Kinney,
> Michael D wrote:
> > Leif,
> >
> > I am curious why a Swap class/instances is not
> sufficient.
> >
> > Currently EDK II follows the UEFI/PI specs, which for
> > all supported CPU architectures use little endian
> ABI.
> > The BaseIoLib follows the endianness of the CPU.  If
> > UEFI/PI added a CPU that was big endian, I would
> expect
> > BaseIoLib when built for that CPU would perform big
> endian
> > operations.
> >
> > Am I missing something?
> 
> If you did add a big-endian CPU, you could then find
> yourself in the
> exact opposite situation and require a little-endian
> i/o access
> library. Which would be implemented exactly as the
> contents of
> IoLibSwap.c.
> 
> The header file necessarily needs to be endianness-
> specific, and if
> the coding style had permitted functions in header
> files, my automatic
> reaction would have been to make all of these static
> inline helper
> functions (even with the code duplication).
> 
> /
> Leif
> 
> > Mike
> >
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-
> > > boun...@lists.01.org] On Behalf Of Leif Lindholm
> > > Sent: Friday, April 13, 2018 12:32 PM
> > > To: Kinney, Michael D <michael.d.kin...@intel.com>
> > > Cc: edk2-devel@lists.01.org; Laszlo Ersek
> > > <ler...@redhat.com>; Gao, Liming
> <liming@intel.com>
> > > Subject: Re: [edk2] [PATCH] MdePkg: add big-endian
> MMIO
> > > BaseBeIoLib
> > >
> > > On Fri, Apr 13, 2018 at 07:24:06PM +, Kinney,
> > > Michael D wrote:
> > > > Hi Leif,
> > > >
> > > > I think we need to look at the names.  I see a
> mix of
> > > > "Be" and "Swap".  We should pick one and use it
> > > > consistently.
> > >
> > > This was what I meant by the comments:
> > > ---
> > > This modified version introduces a single BeIoLib
> > > instance, backed by
> > > a source-file that could be used also for a
> > > hypothetical LeIoLib.
> > > There is no LeIoLib.h included though.
> > >
> > > While this is arguably overengineered, I do feel
> > > reasonably strongly
> > > that code should be named for what it does, not for
> how
> > > it is used,
> > > and doing it this way lets me follow that rule.
> > > ---
> > >
> > > Clearly this is open for discussion, but the above
> is
> > > my opinion and
> > > the code intentionally reflects that.
> > >
> > > Regards,
> > >
> > > Leif
> > >
> > > > Mike
> > > >
> > > > > -Original Message-
> > > > > From: Leif Lindholm
> > > [mailto:leif.lindh...@linaro.org]
> > > > > Sent: Friday, April 13, 2018 10:42 AM
> > > > > To: edk2-devel@lists.01.org
> > > > > Cc: Kinney, Michael D
> <michael.d.kin...@intel.com>;
> > > > > Gao, Liming <liming@intel.com>; Laszlo
> Ersek
> > > > > <ler...@redhat.com>; udit.ku...@nxp.com
> > > > > Subject: [PATCH] MdePkg: add big-endian MMIO
> > > > > BaseBeIoLib
> > > > >
> > > > > When performing MMIO to a destination of the
> > > opposite
> > > > > endianness to the
> > > > > executing processor, this library provides
> > > automatic
> > > > > byte order reversal
> > > > > on inputs and outputs.
> > > > >
> > > > > Contributed-under: TianoCore Contribution
> Agreement
> > > 1.1
> > > > > Signed-of

Re: [edk2] [PATCH] SignedCapsulePkg SystemFirmwareUpdateDxe: Fix failure caused by d69d922

[Kinney, Michael D]

Star,

Thanks for fixing these issues.

Reviewed-by: Michael D Kinney <michael.d.kin...@intel.com>

Mike

> -Original Message-
> From: Yao, Jiewen
> Sent: Sunday, April 15, 2018 6:49 PM
> To: Zeng, Star <star.z...@intel.com>; edk2-
> de...@lists.01.org
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>
> Subject: RE: [PATCH] SignedCapsulePkg
> SystemFirmwareUpdateDxe: Fix failure caused by d69d922
> 
> Reviewed-by: jiewen@intel.com
> 
> 
> 
> > -Original Message-
> > From: Zeng, Star
> > Sent: Friday, April 13, 2018 6:06 PM
> > To: edk2-devel@lists.01.org
> > Cc: Zeng, Star <star.z...@intel.com>; Kinney, Michael
> D
> > <michael.d.kin...@intel.com>; Yao, Jiewen
> <jiewen@intel.com>
> > Subject: [PATCH] SignedCapsulePkg
> SystemFirmwareUpdateDxe: Fix failure
> > caused by d69d922
> >
> > d69d9227d046211265de1fab5580c50a65944614 caused
> system firmware
> > update
> > failure. It is because FindMatchingFmpHandles() is
> expected to return
> > handles matched, but the function returns all handles
> found.
> >
> > This patch is to fix the issue.
> > This patch also assigns mSystemFmpPrivate->Handle for
> "case 1:" path
> > in case the Handle is needed by other place in
> future.
> >
> > Cc: Michael D Kinney <michael.d.kin...@intel.com>
> > Cc: Jiewen Yao <jiewen@intel.com>
> > Contributed-under: TianoCore Contribution Agreement
> 1.1
> > Signed-off-by: Star Zeng <star.z...@intel.com>
> > ---
> >  .../SystemFirmwareUpdate/SystemFirmwareUpdateDxe.c
> | 21
> > -
> >  1 file changed, 16 insertions(+), 5 deletions(-)
> >
> > diff --git
> >
> a/SignedCapsulePkg/Universal/SystemFirmwareUpdate/Syste
> mFirmwareUpdate
> > Dxe.c
> >
> b/SignedCapsulePkg/Universal/SystemFirmwareUpdate/Syste
> mFirmwareUpdat
> > eDxe.c
> > index d0b1c9913ca8..fa0c5f03ffdd 100644
> > ---
> >
> a/SignedCapsulePkg/Universal/SystemFirmwareUpdate/Syste
> mFirmwareUpdate
> > Dxe.c
> > +++
> >
> b/SignedCapsulePkg/Universal/SystemFirmwareUpdate/Syste
> mFirmwareUpdat
> > eDxe.c
> > @@ -602,6 +602,7 @@ FindMatchingFmpHandles (
> >)
> >  {
> >EFI_STATUS Status;
> > +  UINTN  TempHandleCount;
> >EFI_HANDLE *HandleBuffer;
> >UINTN  Index;
> >UINTN  Index2;
> > @@ -613,20 +614,20 @@ FindMatchingFmpHandles (
> >BOOLEANMatchFound;
> >
> >*HandleCount  = 0;
> > +  TempHandleCount = 0;
> >HandleBuffer = NULL;
> >Status = gBS->LocateHandleBuffer (
> > ByProtocol,
> > ProtocolGuid,
> > NULL,
> > -   HandleCount,
> > +   ,
> > 
> > );
> >if (EFI_ERROR (Status)) {
> > -*HandleCount  = 0;
> >  return NULL;
> >}
> >
> > -  for (Index = 0; Index < *HandleCount; Index++) {
> > +  for (Index = 0; Index < TempHandleCount; Index++)
> {
> >  OriginalFmpImageInfoBuf = GetFmpImageDescriptors
> (
> >  HandleBuffer[Index],
> >  ProtocolGuid,
> > @@ -657,12 +658,21 @@ FindMatchingFmpHandles (
> >//
> >FmpImageInfoBuf =
> (EFI_FIRMWARE_IMAGE_DESCRIPTOR *)(((UINT8
> > *)FmpImageInfoBuf) + DescriptorSize);
> >  }
> > -if (!MatchFound) {
> > -  HandleBuffer[Index] = NULL;
> > +if (MatchFound) {
> > +  HandleBuffer[*HandleCount] =
> HandleBuffer[Index];
> > +  (*HandleCount)++;
> >  }
> >
> >  FreePool (OriginalFmpImageInfoBuf);
> >}
> > +
> > +  if ((*HandleCount) == 0) {
> > +//
> > +// No any matching handle.
> > +//
> > +FreePool (HandleBuffer);
> > +return NULL;
> > +  }
> >return HandleBuffer;
> >  }
> >
> > @@ -801,6 +811,7 @@ SystemFirmwareUpdateMainDxe (
> >  // Install System FMP protocol onto handle with
> matching FMP Protocol
> >  //
> >  DEBUG ((DEBUG_INFO, "SystemFirmwareUpdateDxe:
> Install System FMP
> > onto matching FMP handle\n"));
> > +mSystemFmpPrivate->Handle = HandleBuffer[0];
> >  Status = gBS->InstallMultipleProtocolInterfaces
> (
> >  [0],
> >  ,
> > --
> > 2.7.0.windows.1

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

[edk2] [RFC v2 2/4] FmpDevicePkg: Add library instances

[Kinney, Michael D]

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

Based on content from the following branch:

https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport/MsCapsuleUpdatePkg

Add library instances for FmpDeviceLib, CapsuleUpdatePolicyLib,
and FmpPayloadHeaderLib.

Library Classes
===
* FmpDeviceLibNull - Non-functional template of the FmpDeviceLib
  that can be used as a starting point for an FmpDeviceLib for
  a specific firmware storage device.
* CapsuleUpdatePolicyLibNull - Functional template of the
  CapsuleUpdatePolicyLib that can be used as a starting point
  of a platform specific implementation.
* FmpPayloadHeaderLibV1 - Version 1 of the FmpPayloadHeaderLib.
  This library is indented to be used "as is" with no need for
  any device specific or platform specific changes.

Cc: Sean Brogan 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney 
---
 .../CapsuleUpdatePolicyLibNull.c   | 136 +++
 .../CapsuleUpdatePolicyLibNull.inf |  45 +++
 .../CapsuleUpdatePolicyLibNull.uni |  17 +
 .../Library/FmpDeviceLibNull/FmpDeviceLib.c| 427 +
 .../Library/FmpDeviceLibNull/FmpDeviceLibNull.inf  |  48 +++
 .../Library/FmpDeviceLibNull/FmpDeviceLibNull.uni  |  18 +
 .../FmpPayloadHeaderLibV1/FmpPayloadHeaderLib.c| 188 +
 .../FmpPayloadHeaderLibV1.inf  |  48 +++
 .../FmpPayloadHeaderLibV1.uni  |  21 +
 9 files changed, 948 insertions(+)
 create mode 100644 
FmpDevicePkg/Library/CapsuleUpdatePolicyLibNull/CapsuleUpdatePolicyLibNull.c
 create mode 100644 
FmpDevicePkg/Library/CapsuleUpdatePolicyLibNull/CapsuleUpdatePolicyLibNull.inf
 create mode 100644 
FmpDevicePkg/Library/CapsuleUpdatePolicyLibNull/CapsuleUpdatePolicyLibNull.uni
 create mode 100644 FmpDevicePkg/Library/FmpDeviceLibNull/FmpDeviceLib.c
 create mode 100644 FmpDevicePkg/Library/FmpDeviceLibNull/FmpDeviceLibNull.inf
 create mode 100644 FmpDevicePkg/Library/FmpDeviceLibNull/FmpDeviceLibNull.uni
 create mode 100644 
FmpDevicePkg/Library/FmpPayloadHeaderLibV1/FmpPayloadHeaderLib.c
 create mode 100644 
FmpDevicePkg/Library/FmpPayloadHeaderLibV1/FmpPayloadHeaderLibV1.inf
 create mode 100644 
FmpDevicePkg/Library/FmpPayloadHeaderLibV1/FmpPayloadHeaderLibV1.uni

diff --git 
a/FmpDevicePkg/Library/CapsuleUpdatePolicyLibNull/CapsuleUpdatePolicyLibNull.c 
b/FmpDevicePkg/Library/CapsuleUpdatePolicyLibNull/CapsuleUpdatePolicyLibNull.c
new file mode 100644
index 00..943fe372cb
--- /dev/null
+++ 
b/FmpDevicePkg/Library/CapsuleUpdatePolicyLibNull/CapsuleUpdatePolicyLibNull.c
@@ -0,0 +1,136 @@
+/**  @file
+  Provides platform policy services used during a capsule update.
+
+  Copyright (c) 2016, Microsoft Corporation. All rights reserved.
+  Copyright (c) 2018, Intel Corporation. All rights reserved.
+
+  Redistribution and use in source and binary forms, with or without
+  modification, are permitted provided that the following conditions are met:
+  1. Redistributions of source code must retain the above copyright notice,
+  this list of conditions and the following disclaimer.
+  2. Redistributions in binary form must reproduce the above copyright notice,
+  this list of conditions and the following disclaimer in the documentation
+  and/or other materials provided with the distribution.
+
+  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" 
AND
+  ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+  WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 
DISCLAIMED.
+  IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY 
DIRECT,
+  INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES 
(INCLUDING,
+  BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY 
OF
+  LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING 
NEGLIGENCE
+  OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+  ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+**/
+
+#include 
+#include 
+
+/**
+  Determine if the system power state supports a capsule update.
+
+  @param[out] Good  Returns TRUE if system power state supports a capsule
+update.  Returns FALSE if system power state does not
+support a capsule update.  Return value is only valid if
+return status is EFI_SUCCESS.
+
+  @retval EFI_SUCCESSGood parameter has been updated with result.
+  @retval EFI_INVALID_PARAMETER  Good is NULL.
+  @retval EFI_DEVICE_ERROR   System power state can not be determined.
+
+**/
+EFI_STATUS
+EFIAPI
+CheckSystemPower (
+  OUT BOOLEAN  *Good
+  )
+{
+  *Good = TRUE;
+  return EFI_SUCCESS;
+}
+
+/**
+  Determines 

[edk2] [RFC v2 0/4] Add FmpDevicePkg

[Kinney, Michael D]

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

Changes in V2
=
* FmpDevicePkg DEC file
  + Change PcdFmpDeviceSystemResetRequired from FeatureFlag
to FixedAtBuild
  + Add PcdFmpDeviceTestKeySha256Digest for test key detection.
Set to {0} to disable test key detection.
* FmpDevicePkg DSC file
  + Fix ARM and AARCH64 build issues
  + Update DisplayUpdateProgressLib mappings to match patches in
Bug_801_DisplayUpdateProgressLib_V2
* FmpDeviceLib Class and Instance
  + Update FmpDeviceGetSize() to return EFI_STATUS
  + Update FmpDeviceGetAttributes() to return EFI_STATUS
  + Update FmpDeviceGetVersionString() to return EFI_STATUS
* FmpDxe
  + Set depex to Variable Arch Write Protocol and Variable Lock Protocol
  + Break out test key detection in FmpDxe into DetectTestKey.c
  + Change LockAllVars() to LockAllFmpVariables()
  + Update LockAllFmpVariables() to lock each of the UEFI variables used.
  + Always lock UEFI variables when PcdFmpDeviceLockEventGuid is signaled
  + Remove ComputeVersionName().  FmpDeviceLib must provide version string

Based on content from the following branch:

https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport/MsCapsuleUpdatePkg

Branch for review:

https://github.com/mdkinney/edk2/tree/Bug_922_FmpDevicePkg_V2

This package provides an implementation of a Firmware Management Protocol
instance that supports the update of firmware storage devices using UEFI
Capsules.  The behavior of the Firmware Management Protocol instance is
customized using libraries and PCDs.

Cc: Sean Brogan <sean.bro...@microsoft.com>
Cc: Jiewen Yao <jiewen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney <michael.d.kin...@intel.com>

Kinney, Michael D (4):
  FmpDevicePkg: Add package, library classes, and PCDs
  FmpDevicePkg: Add library instances
  FmpDevicePkg: Add FmpDxe module
  FmpDevicePkg: Add DSC file to build all package components

 FmpDevicePkg/FmpDevicePkg.dec  |  132 ++
 FmpDevicePkg/FmpDevicePkg.dsc  |  134 ++
 FmpDevicePkg/FmpDevicePkg.uni  |   80 ++
 FmpDevicePkg/FmpDevicePkgExtra.uni |   18 +
 FmpDevicePkg/FmpDxe/DetectTestKey.c|  166 +++
 FmpDevicePkg/FmpDxe/FmpDxe.c   | 1451 
 FmpDevicePkg/FmpDxe/FmpDxe.inf |   93 ++
 FmpDevicePkg/FmpDxe/FmpDxe.uni |   20 +
 FmpDevicePkg/FmpDxe/FmpDxeExtra.uni|   18 +
 FmpDevicePkg/FmpDxe/FmpDxeLib.inf  |   90 ++
 FmpDevicePkg/FmpDxe/VariableSupport.c  |  461 +++
 FmpDevicePkg/FmpDxe/VariableSupport.h  |  180 +++
 .../Include/Library/CapsuleUpdatePolicyLib.h   |  120 ++
 FmpDevicePkg/Include/Library/FmpDeviceLib.h|  405 ++
 FmpDevicePkg/Include/Library/FmpPayloadHeaderLib.h |  100 ++
 .../CapsuleUpdatePolicyLibNull.c   |  136 ++
 .../CapsuleUpdatePolicyLibNull.inf |   45 +
 .../CapsuleUpdatePolicyLibNull.uni |   17 +
 .../Library/FmpDeviceLibNull/FmpDeviceLib.c|  427 ++
 .../Library/FmpDeviceLibNull/FmpDeviceLibNull.inf  |   48 +
 .../Library/FmpDeviceLibNull/FmpDeviceLibNull.uni  |   18 +
 .../FmpPayloadHeaderLibV1/FmpPayloadHeaderLib.c|  188 +++
 .../FmpPayloadHeaderLibV1.inf  |   48 +
 .../FmpPayloadHeaderLibV1.uni  |   21 +
 24 files changed, 4416 insertions(+)
 create mode 100644 FmpDevicePkg/FmpDevicePkg.dec
 create mode 100644 FmpDevicePkg/FmpDevicePkg.dsc
 create mode 100644 FmpDevicePkg/FmpDevicePkg.uni
 create mode 100644 FmpDevicePkg/FmpDevicePkgExtra.uni
 create mode 100644 FmpDevicePkg/FmpDxe/DetectTestKey.c
 create mode 100644 FmpDevicePkg/FmpDxe/FmpDxe.c
 create mode 100644 FmpDevicePkg/FmpDxe/FmpDxe.inf
 create mode 100644 FmpDevicePkg/FmpDxe/FmpDxe.uni
 create mode 100644 FmpDevicePkg/FmpDxe/FmpDxeExtra.uni
 create mode 100644 FmpDevicePkg/FmpDxe/FmpDxeLib.inf
 create mode 100644 FmpDevicePkg/FmpDxe/VariableSupport.c
 create mode 100644 FmpDevicePkg/FmpDxe/VariableSupport.h
 create mode 100644 FmpDevicePkg/Include/Library/CapsuleUpdatePolicyLib.h
 create mode 100644 FmpDevicePkg/Include/Library/FmpDeviceLib.h
 create mode 100644 FmpDevicePkg/Include/Library/FmpPayloadHeaderLib.h
 create mode 100644 
FmpDevicePkg/Library/CapsuleUpdatePolicyLibNull/CapsuleUpdatePolicyLibNull.c
 create mode 100644 
FmpDevicePkg/Library/CapsuleUpdatePolicyLibNull/CapsuleUpdatePolicyLibNull.inf
 create mode 100644 
FmpDevicePkg/Library/CapsuleUpdatePolicyLibNull/CapsuleUpdatePolicyLibNull.uni
 create mode 100644 FmpDevicePkg/Library/FmpDeviceLibNull/FmpDeviceLib.c
 create mode 100644 FmpDevicePkg/Library/FmpDeviceLibNull/FmpDeviceLibNull.inf
 create mode 100644 FmpDevicePkg/Library/FmpDeviceLibNull/FmpDeviceLibNull.uni
 create mode 100644 
FmpDevicePkg/Library/FmpPayloadHeaderLibV1/FmpPayloadHeaderLib.c
 

[edk2] [RFC v2 1/4] FmpDevicePkg: Add package, library classes, and PCDs

[Kinney, Michael D]

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

Based on content from the following branch:

https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport/MsCapsuleUpdatePkg

Create FmpDevicePkg with library classes and PCDs used to
customize the behavior of a Firmware Management Protocol
instance.

Library Classes
===
* FmpDeviceLib - Provides firmware device specific services
  to support updates of a firmware image stored in a firmware
  device.
* CapsuleUpdatePolicyLib - Provides platform policy services
  used during a capsule update.
* FmpPayloadHeaderLib - Provides services to retrieve values
  from a capsule's FMP Payload Header.  The structure is not
  included in the library class.  Instead, services are
  provided to retrieve information from the FMP Payload Header.
  If information is added to the FMP Payload Header, then new
  services may be added to this library class to retrieve the
  new information.

PCDs set per module

* PcdFmpDeviceSystemResetRequired - Indicates if a full
  system reset is required before a firmware update to a
  firmware devices takes effect
* PcdFmpDeviceTestKeySha256Digest - The SHA-256 hash of a
  PKCS7 test key that is used to detect if a test key is
  being used to authenticate capsules.  Test key detection
  is disabled by setting the value to {0}.
* PcdFmpDeviceProgressColor - The color of the progress bar
  during a firmware update.
* PcdFmpDeviceImageIdName - The Null-terminated Unicode
  string used to fill in the ImageIdName field of the
  EFI_FIRMWARE_IMAGE_DESCRIPTOR structure that is returned
  by the GetImageInfo() service of the Firmware Management
  Protocol for the firmware device.
* PcdFmpDeviceBuildTimeLowestSupportedVersion - The build
  time value used to fill in the LowestSupportedVersion field
  of the EFI_FIRMWARE_IMAGE_DESCRIPTOR structure that is
  returned by the GetImageInfo() service of the Firmware
  Management Protocol.
* PcdFmpDeviceProgressWatchdogTimeInSeconds - The time in
  seconds to arm a watchdog timer during the update of a
  firmware device.

PCDs set per module or for entire platform
==
* PcdFmpDevicePkcs7CertBufferXdr - One or more PKCS7
  certificates used to verify a firmware device capsule
  update image.
* PcdFmpDeviceLockEventGuid - An event GUID that locks
  the firmware device when the event is signaled.

Cc: Sean Brogan 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney 
---
 FmpDevicePkg/FmpDevicePkg.dec  | 132 +++
 FmpDevicePkg/FmpDevicePkg.uni  |  80 
 FmpDevicePkg/FmpDevicePkgExtra.uni |  18 +
 .../Include/Library/CapsuleUpdatePolicyLib.h   | 120 ++
 FmpDevicePkg/Include/Library/FmpDeviceLib.h| 405 +
 FmpDevicePkg/Include/Library/FmpPayloadHeaderLib.h | 100 +
 6 files changed, 855 insertions(+)
 create mode 100644 FmpDevicePkg/FmpDevicePkg.dec
 create mode 100644 FmpDevicePkg/FmpDevicePkg.uni
 create mode 100644 FmpDevicePkg/FmpDevicePkgExtra.uni
 create mode 100644 FmpDevicePkg/Include/Library/CapsuleUpdatePolicyLib.h
 create mode 100644 FmpDevicePkg/Include/Library/FmpDeviceLib.h
 create mode 100644 FmpDevicePkg/Include/Library/FmpPayloadHeaderLib.h

diff --git a/FmpDevicePkg/FmpDevicePkg.dec b/FmpDevicePkg/FmpDevicePkg.dec
new file mode 100644
index 00..9ea0d73359
--- /dev/null
+++ b/FmpDevicePkg/FmpDevicePkg.dec
@@ -0,0 +1,132 @@
+## @file
+# Firmware Management Protocol Device Package
+#
+# This package provides an implementation of a Firmware Management Protocol
+# instance that supports the update of firmware storage devices using UEFI
+# Capsules.  The behavior of the Firmware Management Protocol instance is
+# customized using libraries and PCDs.
+#
+# Copyright (c) 2016, Microsoft Corporation. All rights reserved.
+# Copyright (c) 2018, Intel Corporation. All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions are met:
+# 1. Redistributions of source code must retain the above copyright notice,
+# this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright notice,
+# this list of conditions and the following disclaimer in the documentation
+# and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" 
AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+# WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 
DISCLAIMED.
+# IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY 
DIRECT,
+# INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES 
(INCLUDING,
+# 

[edk2] [RFC v2 4/4] FmpDevicePkg: Add DSC file to build all package components

[Kinney, Michael D]

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

Based on content from the following branch:

https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport/MsCapsuleUpdatePkg

Adds a DSC file that is used to verify that all of the
FmpDevicePkg libraries and modules build without error.

Cc: Sean Brogan 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney 
---
 FmpDevicePkg/FmpDevicePkg.dsc | 134 ++
 1 file changed, 134 insertions(+)
 create mode 100644 FmpDevicePkg/FmpDevicePkg.dsc

diff --git a/FmpDevicePkg/FmpDevicePkg.dsc b/FmpDevicePkg/FmpDevicePkg.dsc
new file mode 100644
index 00..4d08a2cf9e
--- /dev/null
+++ b/FmpDevicePkg/FmpDevicePkg.dsc
@@ -0,0 +1,134 @@
+## @file
+# Firmware Management Protocol Device Package
+#
+# This package provides an implementation of a Firmware Management Protocol
+# instance that supports the update of firmware storage devices using UEFI
+# Capsules.  The behavior of the Firmware Management Protocol instance is
+# customized using libraries and PCDs.
+#
+# Copyright (c) 2016, Microsoft Corporation. All rights reserved.
+# Copyright (c) 2018, Intel Corporation. All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions are met:
+# 1. Redistributions of source code must retain the above copyright notice,
+# this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright notice,
+# this list of conditions and the following disclaimer in the documentation
+# and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" 
AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+# WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 
DISCLAIMED.
+# IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY 
DIRECT,
+# INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES 
(INCLUDING,
+# BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY 
OF
+# LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING 
NEGLIGENCE
+# OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+# ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+#
+##
+
+[Defines]
+  PLATFORM_NAME  = FmpDevicePkg
+  PLATFORM_GUID  = 0af3d540-27c6-11e8-828b-f8597177a00a
+  PLATFORM_VERSION   = 0.1
+  DSC_SPECIFICATION  = 0x00010005
+  OUTPUT_DIRECTORY   = Build/FmpDevicePkg
+  SUPPORTED_ARCHITECTURES= IA32|IPF|X64|ARM|AARCH64
+  BUILD_TARGETS  = DEBUG|RELEASE
+  SKUID_IDENTIFIER   = DEFAULT
+
+  #
+  # Define ESRT GUIDs for Firmware Management Protocol instances
+  #
+  DEFINE FMP_GRAPHICS_ESRT_GUID  = B461B3BD-E62A-4A71-841C-50BA4E500267
+  DEFINE FMP_TEXT_ESRT_GUID  = 226034C4-8B67-4536-8653-D6EE7CE5A316
+
+[LibraryClasses]
+  
UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf
+  
UefiApplicationEntryPoint|MdePkg/Library/UefiApplicationEntryPoint/UefiApplicationEntryPoint.inf
+  
UefiBootServicesTableLib|MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf
+  UefiLib|MdePkg/Library/UefiLib/UefiLib.inf
+  
UefiRuntimeServicesTableLib|MdePkg/Library/UefiRuntimeServicesTableLib/UefiRuntimeServicesTableLib.inf
+  UefiRuntimeLib|MdePkg/Library/UefiRuntimeLib/UefiRuntimeLib.inf
+  
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
+  DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
+  UefiUsbLib|MdePkg/Library/UefiUsbLib/UefiUsbLib.inf
+  UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
+  BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
+  BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
+  
SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
+  PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
+  DebugLib|MdePkg/Library/UefiDebugLibStdErr/UefiDebugLibStdErr.inf
+  
DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf
+  PostCodeLib|MdePkg/Library/BasePostCodeLibPort80/BasePostCodeLibPort80.inf
+  PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
+  DxeServicesLib|MdePkg/Library/DxeServicesLib/DxeServicesLib.inf
+
+  
UefiRuntimeServicesTableLib|MdePkg/Library/UefiRuntimeServicesTableLib/UefiRuntimeServicesTableLib.inf
+  UefiLib|MdePkg/Library/UefiLib/UefiLib.inf
+  DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
+  

[edk2] [RFC v2 3/4] FmpDevicePkg: Add FmpDxe module

[Kinney, Michael D]

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

Based on content from the following branch:

https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport/MsCapsuleUpdatePkg

The FmpDxe directory contains 2 INF files.  FmpDxe.inf
is a DXE driver that is used in a platform to add a
Firmware Management Protocol for firmware device that
supports firmware updates.

FmpDxeLib.inf is a NULL library instance with the exact
same functionality as FmpDxe.inf, but allows the the
Firmware Management Protocol feature to be added to
an existing device driver.

The FmpDxe component is intended to be used "as is"
with no need for any device specific or platform specific
changes.

Cc: Sean Brogan 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney 
---
 FmpDevicePkg/FmpDxe/DetectTestKey.c   |  166 
 FmpDevicePkg/FmpDxe/FmpDxe.c  | 1451 +
 FmpDevicePkg/FmpDxe/FmpDxe.inf|   93 +++
 FmpDevicePkg/FmpDxe/FmpDxe.uni|   20 +
 FmpDevicePkg/FmpDxe/FmpDxeExtra.uni   |   18 +
 FmpDevicePkg/FmpDxe/FmpDxeLib.inf |   90 ++
 FmpDevicePkg/FmpDxe/VariableSupport.c |  461 +++
 FmpDevicePkg/FmpDxe/VariableSupport.h |  180 
 8 files changed, 2479 insertions(+)
 create mode 100644 FmpDevicePkg/FmpDxe/DetectTestKey.c
 create mode 100644 FmpDevicePkg/FmpDxe/FmpDxe.c
 create mode 100644 FmpDevicePkg/FmpDxe/FmpDxe.inf
 create mode 100644 FmpDevicePkg/FmpDxe/FmpDxe.uni
 create mode 100644 FmpDevicePkg/FmpDxe/FmpDxeExtra.uni
 create mode 100644 FmpDevicePkg/FmpDxe/FmpDxeLib.inf
 create mode 100644 FmpDevicePkg/FmpDxe/VariableSupport.c
 create mode 100644 FmpDevicePkg/FmpDxe/VariableSupport.h

diff --git a/FmpDevicePkg/FmpDxe/DetectTestKey.c 
b/FmpDevicePkg/FmpDxe/DetectTestKey.c
new file mode 100644
index 00..0a6e37eded
--- /dev/null
+++ b/FmpDevicePkg/FmpDxe/DetectTestKey.c
@@ -0,0 +1,166 @@
+/**  @file
+  Detects if PcdFmpDevicePkcs7CertBufferXdr contains a test key.
+
+  Copyright (c) 2018, Intel Corporation. All rights reserved.
+
+  Redistribution and use in source and binary forms, with or without
+  modification, are permitted provided that the following conditions are met:
+  1. Redistributions of source code must retain the above copyright notice,
+  this list of conditions and the following disclaimer.
+  2. Redistributions in binary form must reproduce the above copyright notice,
+  this list of conditions and the following disclaimer in the documentation
+  and/or other materials provided with the distribution.
+
+  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" 
AND
+  ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+  WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 
DISCLAIMED.
+  IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY 
DIRECT,
+  INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES 
(INCLUDING,
+  BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY 
OF
+  LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING 
NEGLIGENCE
+  OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+  ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+  Check to see if any of the keys in PcdFmpDevicePkcs7CertBufferXdr matches
+  the test key.  PcdFmpDeviceTestKeySha256Digest contains the SHA256 hash of
+  the test key.  For each key in PcdFmpDevicePkcs7CertBufferXdr, compute the
+  SHA256 hash and compare it to PcdFmpDeviceTestKeySha256Digest.  If the
+  SHA256 hash matches or there is then error computing the SHA256 hash, then
+  set PcdTestKeyUsed to TRUE.  Skip this check if PcdTestKeyUsed is already
+  TRUE or PcdFmpDeviceTestKeySha256Digest is not exactly SHA256_DIGEST_SIZE
+  bytes.
+**/
+VOID
+DetectTestKey (
+  VOID
+  )
+{
+  BOOLEAN  TestKeyUsed;
+  UINTNPublicKeyDataLength;
+  UINT8*PublicKeyDataXdr;
+  UINT8*PublicKeyDataXdrEnd;
+  VOID *HashContext;
+  UINT8Digest[SHA256_DIGEST_SIZE];
+
+  //
+  // If PcdFmpDeviceTestKeySha256Digest is not exacty SHA256_DIGEST_SIZE bytes,
+  // then skip the test key detection.
+  //
+  if (PcdGetSize (PcdFmpDeviceTestKeySha256Digest) != SHA256_DIGEST_SIZE) {
+return;
+  }
+
+  //
+  // If PcdTestKeyUsed is already TRUE, then skip test key detection
+  //
+  TestKeyUsed = PcdGetBool (PcdTestKeyUsed);
+  if (TestKeyUsed) {
+return;
+  }
+
+  //
+  // If PcdFmpDevicePkcs7CertBufferXdr is invalid, then skip test key detection
+  //
+  PublicKeyDataXdr= PcdGetPtr (PcdFmpDevicePkcs7CertBufferXdr);
+  PublicKeyDataXdrEnd = PublicKeyDataXdr + PcdGetSize 
(PcdFmpDevicePkcs7CertBufferXdr);
+  if (PublicKeyDataXdr == NULL 

[edk2] [Patch 5/5] Vlv2TbltDevicePkg: Sync FLASH libraries from UDK2017 branch

[Kinney, Michael D]

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

Update Minnow Max FLASH libraries to match libraries in
the UDK2017 development branch in edk2-platforms.

https://github.com/tianocore/edk2-platforms/tree/devel-MinnowBoardMax-UDK2017

Cc: David Wei 
Cc: Mang Guo 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney 
---
 .../PlatformFlashAccessLib.c   | 491 -
 .../PlatformFlashAccessLib.inf |  19 +-
 .../Library/FlashDeviceLib/FlashDeviceLib.c| 158 ++-
 .../Library/FlashDeviceLib/FlashDeviceLib.inf  |   6 +-
 .../Library/FlashDeviceLib/SpiChipDefinitions.h|   1 +
 5 files changed, 639 insertions(+), 36 deletions(-)

diff --git 
a/Vlv2TbltDevicePkg/Feature/Capsule/Library/PlatformFlashAccessLib/PlatformFlashAccessLib.c
 
b/Vlv2TbltDevicePkg/Feature/Capsule/Library/PlatformFlashAccessLib/PlatformFlashAccessLib.c
index f3cb31daaa..9162e025ed 100644
--- 
a/Vlv2TbltDevicePkg/Feature/Capsule/Library/PlatformFlashAccessLib/PlatformFlashAccessLib.c
+++ 
b/Vlv2TbltDevicePkg/Feature/Capsule/Library/PlatformFlashAccessLib/PlatformFlashAccessLib.c
@@ -1,7 +1,7 @@
 /** @file
   Platform Flash Access library.
 
-  Copyright (c) 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2017, 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
@@ -11,6 +11,7 @@
   WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 
 **/
+#include 
 
 #include 
 
@@ -19,14 +20,366 @@
 #include 
 #include 
 #include 
-#include 
+//#include 
 #include 
+#include 
+#include 
+#include "PchAccess.h"
+#include 
+#include 
+#include 
+#include 
 
-#define SECTOR_SIZE_64KB  0x1  // Common 64kBytes sector size
-#define ALINGED_SIZE  SECTOR_SIZE_64KB
+//#define SECTOR_SIZE_64KB  0x1  // Common 64kBytes sector size
+//#define ALINGED_SIZE  SECTOR_SIZE_64KB
+
+#define BLOCK_SIZE 0x1000
+#define ALINGED_SIZE BLOCK_SIZE
+
+#define R_PCH_LPC_BIOS_CNTL   0xDC
+#define B_PCH_LPC_BIOS_CNTL_SMM_BWP   0x20///< SMM 
BIOS write protect disable
+
+//
+// Prefix Opcode Index on the host SPI controller
+//
+typedef enum {
+  SPI_WREN, // Prefix Opcode 0: Write Enable
+  SPI_EWSR, // Prefix Opcode 1: Enable Write Status Register
+} PREFIX_OPCODE_INDEX;
+//
+// Opcode Menu Index on the host SPI controller
+//
+typedef enum {
+  SPI_READ_ID,// Opcode 0: READ ID, Read cycle with address
+  SPI_READ,   // Opcode 1: READ, Read cycle with address
+  SPI_RDSR,   // Opcode 2: Read Status Register, No address
+  SPI_WRDI_SFDP,  // Opcode 3: Write Disable or Discovery Parameters, No 
address
+  SPI_SERASE, // Opcode 4: Sector Erase (4KB), Write cycle with address
+  SPI_BERASE, // Opcode 5: Block Erase (32KB), Write cycle with address
+  SPI_PROG,   // Opcode 6: Byte Program, Write cycle with address
+  SPI_WRSR,   // Opcode 7: Write Status Register, No address
+} SPI_OPCODE_INDEX;
 
 STATIC EFI_PHYSICAL_ADDRESS mInternalFdAddress;
 
+EFI_SPI_PROTOCOL  *mSpiProtocol;
+
+/**
+  Read NumBytes bytes of data from the address specified by
+  PAddress into Buffer.
+
+  @param[in]  Address   The starting physical address of the read.
+  @param[in,out]  NumBytes  On input, the number of bytes to read. On 
output, the number
+of bytes actually read.
+  @param[out] BufferThe destination data buffer for the read.
+
+  @retval EFI_SUCCESS   Opertion is successful.
+  @retval EFI_DEVICE_ERROR  If there is any device errors.
+
+**/
+EFI_STATUS
+EFIAPI
+SpiFlashRead (
+  IN UINTN Address,
+  IN OUT UINT32*NumBytes,
+ OUT UINT8 *Buffer
+  )
+{
+  EFI_STATUSStatus = EFI_SUCCESS;
+  UINTN Offset = 0;
+
+  ASSERT ((NumBytes != NULL) && (Buffer != NULL));
+
+
+  //if (Address >= (UINTN)PcdGet32 (PcdGbeRomBase) && Address < 
(UINTN)PcdGet32 (PcdPDRRomBase)) {
+Offset = Address - (UINTN)PcdGet32 (PcdFlashChipBase);
+
+Status = mSpiProtocol->Execute (
+   mSpiProtocol,
+   1, //SPI_READ,
+   0, //SPI_WREN,
+   TRUE,
+   TRUE,
+   FALSE,
+   Offset,
+   BLOCK_SIZE,
+   Buffer,
+   EnumSpiRegionAll
+   );
+return Status;
+}
+
+/**
+  Write NumBytes bytes of data from Buffer 

[edk2] [Patch 2/5] Vlv2TbltDevicePkg: Fix VS2015 build breaks

[Kinney, Michael D]

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

Fix minor code issues that break VS2015 builds.

Cc: David Wei 
Cc: Mang Guo 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney 
---
 Vlv2TbltDevicePkg/PlatformSetupDxe/SetupInfoRecords.c| 1 -
 Vlv2TbltDevicePkg/SmBiosMiscDxe/MiscProcessorCacheFunction.c | 6 --
 Vlv2TbltDevicePkg/VlvPlatformInitDxe/VlvPlatformInit.c   | 2 +-
 3 files changed, 1 insertion(+), 8 deletions(-)

diff --git a/Vlv2TbltDevicePkg/PlatformSetupDxe/SetupInfoRecords.c 
b/Vlv2TbltDevicePkg/PlatformSetupDxe/SetupInfoRecords.c
index b0e29f02d0..f608651cd4 100644
--- a/Vlv2TbltDevicePkg/PlatformSetupDxe/SetupInfoRecords.c
+++ b/Vlv2TbltDevicePkg/PlatformSetupDxe/SetupInfoRecords.c
@@ -1185,7 +1185,6 @@ UpdatePlatformInformation (
   EFI_STATUS   Status;
   UINT8CpuFlavor=0;
   EFI_PEI_HOB_POINTERS GuidHob;
-  EFI_PLATFORM_INFO_HOB*mPlatformInfo=NULL;
   UINTNNumHandles;
   EFI_HANDLE*HandleBuffer;
   UINTN Index;
diff --git a/Vlv2TbltDevicePkg/SmBiosMiscDxe/MiscProcessorCacheFunction.c 
b/Vlv2TbltDevicePkg/SmBiosMiscDxe/MiscProcessorCacheFunction.c
index b18a6aaa3b..4a83aedc97 100644
--- a/Vlv2TbltDevicePkg/SmBiosMiscDxe/MiscProcessorCacheFunction.c
+++ b/Vlv2TbltDevicePkg/SmBiosMiscDxe/MiscProcessorCacheFunction.c
@@ -28,12 +28,6 @@ Abstract:
 #include 
 #include 
 
-
-extern  SMBIOS_TABLE_TYPE7*SmbiosRecordL1;
-extern  SMBIOS_TABLE_TYPE7*SmbiosRecordL2;
-extern  SMBIOS_TABLE_TYPE7*SmbiosRecordL3;
-
-
 UINT32
 ConvertBase2ToRaw (
   IN  EFI_EXP_BASE2_DATA *Data)
diff --git a/Vlv2TbltDevicePkg/VlvPlatformInitDxe/VlvPlatformInit.c 
b/Vlv2TbltDevicePkg/VlvPlatformInitDxe/VlvPlatformInit.c
index 5e8d95ae9f..f8274e9df0 100644
--- a/Vlv2TbltDevicePkg/VlvPlatformInitDxe/VlvPlatformInit.c
+++ b/Vlv2TbltDevicePkg/VlvPlatformInitDxe/VlvPlatformInit.c
@@ -147,7 +147,7 @@ PostPmInitCallBack (
 EFI_STATUS
 IgdPmHook (
   IN EFI_HANDLE  ImageHandle,
-  IN DXE_VLV_PLATFORM_POLICY_PROTOCOL *DxePlatformSaPolicy
+  IN DXE_VLV_PLATFORM_POLICY_PROTOCOL *DxePlatformSaPolicyParam
   )
 {
 
-- 
2.14.2.windows.3

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

[edk2] [Patch 3/5] Vlv2TbltDevicePkg: Fix build issues in DSC/FDF

[Kinney, Michael D]

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

Fix a the following issues in DSC/FDF files

* Remove references to  drivers that are not present
* Enable the Tianocore boot logo and BGRT table
* Enable full UEFI shell
* Enable more debug messages in DXE phase

Cc: David Wei 
Cc: Mang Guo 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney 
---
 Vlv2TbltDevicePkg/PlatformPkg.fdf   | 15 ---
 Vlv2TbltDevicePkg/PlatformPkgGcc.fdf| 17 +
 Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 12 
 Vlv2TbltDevicePkg/PlatformPkgIA32.dsc   | 12 
 Vlv2TbltDevicePkg/PlatformPkgX64.dsc| 14 +-
 5 files changed, 50 insertions(+), 20 deletions(-)

diff --git a/Vlv2TbltDevicePkg/PlatformPkg.fdf 
b/Vlv2TbltDevicePkg/PlatformPkg.fdf
index 846db044b4..85309650db 100644
--- a/Vlv2TbltDevicePkg/PlatformPkg.fdf
+++ b/Vlv2TbltDevicePkg/PlatformPkg.fdf
@@ -319,7 +319,7 @@ [FV.FVRECOVERY2]
 INF 
EdkCompatibilityPkg/Compatibility/AcpiVariableHobOnSmramReserveHobThunk/AcpiVariableHobOnSmramReserveHobThunk.inf
 !endif
 
-INF RuleOverride = BINARY 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/IA32/PiSmmCommunicationPei.inf
+# INF RuleOverride = BINARY 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/IA32/PiSmmCommunicationPei.inf
 !if $(TPM_ENABLED) == TRUE
 INF SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf
 INF SecurityPkg/Tcg/TcgPei/TcgPei.inf
@@ -473,6 +473,7 @@ [FV.FVMAIN]
 INF RuleOverride = BINARY 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/$(DXE_ARCHITECTURE)/MpCpu.inf
 INF $(PLATFORM_PACKAGE)/Metronome/Metronome.inf
 INF IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
+INF USE=X64 MdeModulePkg/Logo/Logo.inf
 INF MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
 INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
 INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
@@ -612,6 +613,8 @@ [FV.FVMAIN]
 
 INF $(PLATFORM_PACKAGE)/AcpiPlatform/AcpiPlatform.inf
 
+INF 
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
+
   #
   # PCI
   #
@@ -635,8 +638,8 @@ [FV.FVMAIN]
 #
 # SDIO
 #
-INF RuleOverride = BINARY 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/$(DXE_ARCHITECTURE)/MmcHost.inf
-INF RuleOverride = BINARY 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/$(DXE_ARCHITECTURE)/MmcMediaDevice.inf
+#INF RuleOverride = BINARY 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/$(DXE_ARCHITECTURE)/MmcHost.inf
+#INF RuleOverride = BINARY 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/$(DXE_ARCHITECTURE)/MmcMediaDevice.inf
 #
 # IDE/SCSI/AHCI
 #
@@ -1091,6 +1094,12 @@ [Rule.Common.USER_DEFINED]
 RAW BIN|.bin
   }
 
+[Rule.Common.USER_DEFINED.BINARY]
+  FILE FREEFORM = $(NAMED_GUID) {
+UI  STRING="$(MODULE_NAME)" Optional
+RAW BIN|.bin
+  }
+
 [Rule.Common.USER_DEFINED.ACPITABLE]
   FILE FREEFORM = $(NAMED_GUID) {
 RAW ACPI  Optional|.acpi
diff --git a/Vlv2TbltDevicePkg/PlatformPkgGcc.fdf 
b/Vlv2TbltDevicePkg/PlatformPkgGcc.fdf
index 479c4c7264..51a620ea15 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgGcc.fdf
+++ b/Vlv2TbltDevicePkg/PlatformPkgGcc.fdf
@@ -276,7 +276,7 @@ [FV.FVRECOVERY2]
 INF 
EdkCompatibilityPkg/Compatibility/AcpiVariableHobOnSmramReserveHobThunk/AcpiVariableHobOnSmramReserveHobThunk.inf
 !endif
 
-INF RuleOverride = BINARY 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/IA32/PiSmmCommunicationPei.inf
+# INF RuleOverride = BINARY 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/IA32/PiSmmCommunicationPei.inf
 !if $(TPM_ENABLED) == TRUE
 INF SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf
 INF SecurityPkg/Tcg/TcgPei/TcgPei.inf
@@ -430,6 +430,7 @@ [FV.FVMAIN]
 INF RuleOverride = BINARY 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/$(DXE_ARCHITECTURE)/MpCpu.inf
 INF $(PLATFORM_PACKAGE)/Metronome/Metronome.inf
 INF IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
+INF USE=X64 MdeModulePkg/Logo/Logo.inf
 INF MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
 INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
 INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
@@ -569,6 +570,8 @@ [FV.FVMAIN]
 
 INF $(PLATFORM_PACKAGE)/AcpiPlatform/AcpiPlatform.inf
 
+INF 
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
+
   #
   # PCI
   #
@@ -592,8 +595,8 @@ [FV.FVMAIN]
 #
 # SDIO
 #
-INF RuleOverride = BINARY 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/$(DXE_ARCHITECTURE)/MmcHost.inf
-INF RuleOverride = BINARY 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/$(DXE_ARCHITECTURE)/MmcMediaDevice.inf
+#INF RuleOverride = BINARY 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/$(DXE_ARCHITECTURE)/MmcHost.inf
+#INF 

[edk2] [Patch 4/5] Vlv2TbltDevicePkg: Display logo on BOOT_ON_FLASH_UPDATE

[Kinney, Michael D]

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

Update PlatformBdsLib to show boot logo when the boot
mode is BOOT_ON_FLASH_UPDATE.

Cc: David Wei 
Cc: Mang Guo 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney 
---
 Vlv2TbltDevicePkg/Library/PlatformBdsLib/BdsPlatform.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/Vlv2TbltDevicePkg/Library/PlatformBdsLib/BdsPlatform.c 
b/Vlv2TbltDevicePkg/Library/PlatformBdsLib/BdsPlatform.c
index e42e82b678..c25e1d301a 100644
--- a/Vlv2TbltDevicePkg/Library/PlatformBdsLib/BdsPlatform.c
+++ b/Vlv2TbltDevicePkg/Library/PlatformBdsLib/BdsPlatform.c
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2004  - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2004  - 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.  
@@ -1871,6 +1871,7 @@ PlatformBdsPolicyBehavior (
 //
 PlatformBdsConnectConsole (gPlatformConsole);
 PlatformBdsDiagnostics (EXTENSIVE, FALSE, BaseMemoryTest);
+EnableQuietBoot (PcdGetPtr(PcdLogoFile));
 
 DEBUG((DEBUG_INFO, "ProcessCapsules Before EndOfDxe..\n"));
 ProcessCapsules ();
@@ -2642,6 +2643,8 @@ PlatformBdsEnterFrontPageWithHotKey (
 {
   EFI_STATUSStatus;
 
+  EFI_STATUS LogoStatus;
+  EFI_BOOT_LOGO_PROTOCOL *BootLogo;
   EFI_GRAPHICS_OUTPUT_PROTOCOL   *GraphicsOutput;
   EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL*SimpleTextOut;
   UINTN  BootTextColumn;
@@ -2721,6 +2724,14 @@ PlatformBdsEnterFrontPageWithHotKey (
 gST->ConOut->EnableCursor (gST->ConOut, TRUE);
 gST->ConOut->ClearScreen (gST->ConOut);
 
+//
+// Boot Logo is corrupted, report it using Boot Logo protocol.
+//
+LogoStatus = gBS->LocateProtocol (, NULL, (VOID 
**) );
+if (!EFI_ERROR (LogoStatus) && (BootLogo != NULL)) {
+  BootLogo->SetBootLogo (BootLogo, NULL, 0, 0, 0, 0);
+}
+
 if (EFI_ERROR (Status)) {
   //
   // Timeout or user press enter to continue
@@ -2728,6 +2739,7 @@ PlatformBdsEnterFrontPageWithHotKey (
   goto Exit;
 }
   }
+
   //
   // Install BM HiiPackages. 
   // Keep BootMaint HiiPackage, so that it can be covered by global setting. 
-- 
2.14.2.windows.3

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

[edk2] [Patch 1/5] Vlv2TbltDevicePkg: Fix build scripts

[Kinney, Michael D]

From: Michael D Kinney 

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

Update build scripts to work with edk2 and Vlv2Binaries
in PACKAGES_PATH.

Cc: David Wei 
Cc: Mang Guo 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney 
---
 Vlv2TbltDevicePkg/.gitignore|   3 +
 Vlv2TbltDevicePkg/Build_IFWI.bat|   8 +--
 Vlv2TbltDevicePkg/Stitch/IFWIStitch.bat |   2 +-
 Vlv2TbltDevicePkg/bld_vlv.bat   | 117 +---
 4 files changed, 72 insertions(+), 58 deletions(-)
 create mode 100644 Vlv2TbltDevicePkg/.gitignore

diff --git a/Vlv2TbltDevicePkg/.gitignore b/Vlv2TbltDevicePkg/.gitignore
new file mode 100644
index 00..b4699122b8
--- /dev/null
+++ b/Vlv2TbltDevicePkg/.gitignore
@@ -0,0 +1,3 @@
+AutoPlatformCFG.txt
+Stitch/Stitching.log
+Stitch/MNW*.bin
diff --git a/Vlv2TbltDevicePkg/Build_IFWI.bat b/Vlv2TbltDevicePkg/Build_IFWI.bat
index ac22a76b73..c8e3ec3d76 100644
--- a/Vlv2TbltDevicePkg/Build_IFWI.bat
+++ b/Vlv2TbltDevicePkg/Build_IFWI.bat
@@ -1,7 +1,7 @@
 @REM @file
 @REM   Windows batch file to build BIOS ROM
 @REM
-@REM Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.
+@REM Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
 @REM This program and the accompanying materials
 @REM are licensed and made available under the terms and conditions of the BSD 
License
 @REM which accompanies this distribution.  The full text of the license may be 
found at
@@ -131,11 +131,11 @@ if %ERRORLEVEL% NEQ 0 (
 echo.
 echo Finished Building BIOS.
 @REM Set BIOS_ID environment variable here.
-call Conf\BiosId.bat
+call %WORKSPACE%\Conf\BiosId.bat
 echo BIOS_ID=%BIOS_ID%
 
 :: Set the Board_Id, Build_Type, Version_Major, and Version_Minor environment 
variables
-find /v "#" Conf\BiosId.env > ver_strings
+find /v "#" %WORKSPACE%\Conf\BiosId.env > ver_strings
 for /f "tokens=1,3" %%i in (ver_strings) do set %%i=%%j
 del /f/q ver_strings >nul
 set 
BIOS_Name=%BOARD_ID%_%Arch%_%BUILD_TYPE%_%VERSION_MAJOR%_%VERSION_MINOR%.ROM
@@ -149,7 +149,7 @@ if "%Platform_Type%" == "BYTC" (
 pushd %PLATFORM_PACKAGE%\Stitch
 )
:: IFWIStitch.bat [/nG] [/nM] [/nB] [/B BIOS.rom] [/C StitchConfig] [/S 
IFWISuffix]
-   call IFWIStitch.bat %Stitch_Flags% /B ..\..\%BIOS_Name% %IFWI_Suffix%
+   call IFWIStitch.bat %Stitch_Flags% /B %WORKSPACE%\%BIOS_Name% %IFWI_Suffix%

@echo off
 popd
diff --git a/Vlv2TbltDevicePkg/Stitch/IFWIStitch.bat 
b/Vlv2TbltDevicePkg/Stitch/IFWIStitch.bat
index f3a9cf3d74..5f19983c91 100644
--- a/Vlv2TbltDevicePkg/Stitch/IFWIStitch.bat
+++ b/Vlv2TbltDevicePkg/Stitch/IFWIStitch.bat
@@ -191,7 +191,7 @@ for %%i in (%BIOS_Names%) do (
 echo Generating IFWI... %BIOS_ID%.bin
 echo.
 
-copy /b/y !IFWI_HEADER_FILE! + 
..\..\Vlv2MiscBinariesPkg\SEC\!SEC_VERSION!\VLV_SEC_REGION.bin + 
..\..\Vlv2MiscBinariesPkg\SEC\!SEC_VERSION!\Vacant.bin + !BIOS_Rom! 
%BIOS_ID%.bin
+copy /b/y !IFWI_HEADER_FILE! + 
%WORKSPACE%\Vlv2Binaries\Vlv2MiscBinariesPkg\SEC\!SEC_VERSION!\VLV_SEC_REGION.bin
 + %WORKSPACE%\Vlv2Binaries\Vlv2MiscBinariesPkg\SEC\!SEC_VERSION!\Vacant.bin + 
!BIOS_Rom! %BIOS_ID%.bin
 echo.
 echo 
===
 )
diff --git a/Vlv2TbltDevicePkg/bld_vlv.bat b/Vlv2TbltDevicePkg/bld_vlv.bat
index a1d8c5b525..27bc4e7c41 100644
--- a/Vlv2TbltDevicePkg/bld_vlv.bat
+++ b/Vlv2TbltDevicePkg/bld_vlv.bat
@@ -20,8 +20,8 @@ echo.
 ::**
 :: Initial Setup
 ::**
-set WORKSPACE=%CD%
-if %WORKSPACE:~-1%==\ set WORKSPACE=%WORKSPACE:~0,-1%
+REM set WORKSPACE=%CD%
+REM if %WORKSPACE:~-1%==\ set WORKSPACE=%WORKSPACE:~0,-1%
 set /a build_threads=1
 set "Build_Flags= "
 set exitCode=0
@@ -36,7 +36,7 @@ if exist %WORKSPACE%\Conf\target.txt del 
%WORKSPACE%\Conf\target.txt
 if exist %WORKSPACE%\Conf\tools_def.txt del %WORKSPACE%\Conf\tools_def.txt
 if exist %WORKSPACE%\Conf\build_rule.txt del %WORKSPACE%\Conf\build_rule.txt
 if exist %WORKSPACE%\Conf\FrameworkDatabase.db del 
%WORKSPACE%\Conf\FrameworkDatabase.db
-if exist conf\.cache rmdir /q/s conf\.cache
+if exist %WORKSPACE%\Conf\.cache rmdir /q/s %WORKSPACE%\Conf\.cache
 
 :: Setup EDK environment. Edksetup puts new copies of target.txt, 
tools_def.txt, build_rule.txt in WorkSpace\Conf
 :: Also run edksetup as soon as possible to avoid it from changing environment 
variables we're overriding
@@ -48,7 +48,7 @@ set PLATFORM_PACKAGE=Vlv2TbltDevicePkg
 set config_file=.\%PLATFORM_PACKAGE%\PlatformPkgConfig.dsc
 set auto_config_inc=.\%PLATFORM_PACKAGE%\AutoPlatformCFG.txt
 
-set EDK_SOURCE=%WORKSPACE%\EdkCompatibilityPkg
+REM set EDK_SOURCE=%WORKSPACE%\EdkCompatibilityPkg
 
 ::create new AutoPlatformCFG.txt file
 

[edk2] [Patch 0/5] Fix Vlv2TbltDevicePkg build and boot issues

[Kinney, Michael D]

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

Fix a the following issues

* Update build scripts to work when Vlv2Binaries are placed in PACKAGES_PATH
* Fix some compiler build breaks when using VS2015
* Remove references to  drivers that are not present
* Enable the Tianocore boot logo and BGRT table
* Enable full UEFI shell
* Enable more debug messages in DXE phase
* Update PlatformBdsLib to show boot logo when the boot
  mode is BOOT_ON_FLASH_UPDATE.
* Update FLASH libraries to match libraries in the UDK2017
  development branch in edk2-platforms.

Cc: David Wei <david@intel.com>
Cc: Mang Guo <mang@intel.com>
Cc: Jiewen Yao <jiewen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney <michael.d.kin...@intel.com>

Kinney, Michael D (4):
  Vlv2TbltDevicePkg: Fix VS2015 build breaks
  Vlv2TbltDevicePkg: Fix build issues in DSC/FDF
  Vlv2TbltDevicePkg: Display logo on BOOT_ON_FLASH_UPDATE
  Vlv2TbltDevicePkg: Sync FLASH libraries from UDK2017 branch

Michael D Kinney (1):
  Vlv2TbltDevicePkg: Fix build scripts

 Vlv2TbltDevicePkg/.gitignore   |   3 +
 Vlv2TbltDevicePkg/Build_IFWI.bat   |   8 +-
 .../PlatformFlashAccessLib.c   | 491 -
 .../PlatformFlashAccessLib.inf |  19 +-
 .../Library/FlashDeviceLib/FlashDeviceLib.c| 158 ++-
 .../Library/FlashDeviceLib/FlashDeviceLib.inf  |   6 +-
 .../Library/FlashDeviceLib/SpiChipDefinitions.h|   1 +
 .../Library/PlatformBdsLib/BdsPlatform.c   |  14 +-
 Vlv2TbltDevicePkg/PlatformPkg.fdf  |  15 +-
 Vlv2TbltDevicePkg/PlatformPkgGcc.fdf   |  17 +-
 Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc|  12 +-
 Vlv2TbltDevicePkg/PlatformPkgIA32.dsc  |  12 +-
 Vlv2TbltDevicePkg/PlatformPkgX64.dsc   |  14 +-
 .../PlatformSetupDxe/SetupInfoRecords.c|   1 -
 .../SmBiosMiscDxe/MiscProcessorCacheFunction.c |   6 -
 Vlv2TbltDevicePkg/Stitch/IFWIStitch.bat|   2 +-
 .../VlvPlatformInitDxe/VlvPlatformInit.c   |   2 +-
 Vlv2TbltDevicePkg/bld_vlv.bat  | 117 ++---
 18 files changed, 775 insertions(+), 123 deletions(-)
 create mode 100644 Vlv2TbltDevicePkg/.gitignore

-- 
2.14.2.windows.3

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

[edk2] [Patch] MdeModulePkg/Gcd: Filter gCpu->SetMemoryAttributes() calls

[Kinney, Michael D]

This patch fixes an issue with VlvTbltDevicePkg introduced
by commit:

https://github.com/tianocore/edk2/commit/5b91bf82c67b586b9588cbe4bbffa1588f6b5926

This patch filters the call to gCpu->SetMemoryAttributes()
if the requested attributes is 0.  It also removes the #define
INVALID_CPU_ARCH_ATTRIBUTES that is no longer used.

Cc: Heyi Guo 
Cc: Yi Li 
Cc: Renhao Liang 
Cc: Star Zeng 
Cc: Eric Dong 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Ruiyu Ni 
Signed-off-by: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
---
 MdeModulePkg/Core/Dxe/Gcd/Gcd.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
index 907245a3f5..45ed6280db 100644
--- a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
+++ b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
@@ -48,8 +48,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #define NONEXCLUSIVE_MEMORY_ATTRIBUTES (EFI_MEMORY_XP | EFI_MEMORY_RP | \
 EFI_MEMORY_RO)
 
-#define INVALID_CPU_ARCH_ATTRIBUTES   0x
-
 //
 // Module Variables
 //
@@ -873,7 +871,7 @@ CoreConvertSpace (
 // Call CPU Arch Protocol to attempt to set attributes on the range
 //
 CpuArchAttributes = ConverToCpuArchAttributes (Attributes);
-if (CpuArchAttributes != INVALID_CPU_ARCH_ATTRIBUTES) {
+if (CpuArchAttributes != 0) {
   if (gCpu == NULL) {
 Status = EFI_NOT_AVAILABLE_YET;
   } else {
-- 
2.14.2.windows.3

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

Re: [edk2] [PATCH 1/1] MdeModulePkg/Gcd: Fix bug of attribute conversion

[Kinney, Michael D]

Star,

This commit breaks Vlv2TbltDevicePkg.

On this platform, there are 2 calls to 
gDS->SetMemorySpaceAttributes() for an MMIO
range to set only the EFI_MEMORY_RUNTIME bit.

With this commit, ConverToCpuArchAttributes()returns 0,
and 0 is passed to gCpu->SetMemoryAttributes()that
returns EFI_INVALID_PARAMETER on Vlv2TbltDevicePkg.

Before this commit, ConverToCpuArchAttributes()
returns INVALID_CPU_ARCH_ATTRIBUTES which causes
the call to gCpu->SetMemoryAttributes()to be
skipped so no error is generated.

I think the right fix is to skip the call to 
gCpu->SetMemoryAttributes() if CpuArchAttributes
is 0 so a call that only sets the RUNTIME attribute
can be supported along with call the set both the
RUNTIME bit and other cache related bits.

I will send a patch soon with the proposed fix.

Mike

> -Original Message-
> From: Zeng, Star
> Sent: Sunday, April 1, 2018 10:59 PM
> To: Heyi Guo <heyi@linaro.org>; edk2-
> de...@lists.01.org
> Cc: Yi Li <phoenix.l...@huawei.com>; Renhao Liang
> <liangren...@huawei.com>; Dong, Eric
> <eric.d...@intel.com>; Kinney, Michael D
> <michael.d.kin...@intel.com>; Gao, Liming
> <liming@intel.com>; Wang, Jian J
> <jian.j.w...@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>;
> Zeng, Star <star.z...@intel.com>
> Subject: RE: [PATCH 1/1] MdeModulePkg/Gcd: Fix bug of
> attribute conversion
> 
> Pushed at 5b91bf82c67b586b9588cbe4bbffa1588f6b5926.
> 
> Thanks,
> Star
> -Original Message-
> From: Heyi Guo [mailto:heyi@linaro.org]
> Sent: Thursday, March 29, 2018 4:20 PM
> To: edk2-devel@lists.01.org
> Cc: Heyi Guo <heyi@linaro.org>; Yi Li
> <phoenix.l...@huawei.com>; Renhao Liang
> <liangren...@huawei.com>; Zeng, Star
> <star.z...@intel.com>; Dong, Eric <eric.d...@intel.com>;
> Kinney, Michael D <michael.d.kin...@intel.com>; Gao,
> Liming <liming@intel.com>; Wang, Jian J
> <jian.j.w...@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>
> Subject: [PATCH 1/1] MdeModulePkg/Gcd: Fix bug of
> attribute conversion
> 
> For gDS->SetMemorySpaceAttributes(), when user passes a
> combined memory attribute including CPU arch attribute
> and other attributes, like EFI_MEMORY_RUNTIME,
> ConverToCpuArchAttributes() will return
> INVALID_CPU_ARCH_ATTRIBUTES and skip setting page/cache
> attribute for the specified memory space.
> 
> We don't see any reason to forbid combining CPU arch
> attributes and non-CPU-arch attributes when calling gDS-
> >SetMemorySpaceAttributes(), so we remove the check code
> in ConverToCpuArchAttributes(); the remaining code is
> enough to grab the interested bits for
> Cpu->SetMemoryAttributes().
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Heyi Guo <heyi@linaro.org>
> Signed-off-by: Yi Li <phoenix.l...@huawei.com>
> Signed-off-by: Renhao Liang <liangren...@huawei.com>
> Cc: Star Zeng <star.z...@intel.com>
> Cc: Eric Dong <eric.d...@intel.com>
> Cc: Michael D Kinney <michael.d.kin...@intel.com>
> Cc: Liming Gao <liming@intel.com>
> Cc: Jian J Wang <jian.j.w...@intel.com>
> Cc: Ruiyu Ni <ruiyu...@intel.com>
> ---
>  MdeModulePkg/Core/Dxe/Gcd/Gcd.c | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c index
> 77f4adb4bc01..907245a3f512 100644
> --- a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> +++ b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> @@ -673,11 +673,6 @@ ConverToCpuArchAttributes (  {
>UINT64  CpuArchAttributes;
> 
> -  if ((Attributes & ~(EXCLUSIVE_MEMORY_ATTRIBUTES |
> -  NONEXCLUSIVE_MEMORY_ATTRIBUTES))
> != 0) {
> -return INVALID_CPU_ARCH_ATTRIBUTES;
> -  }
> -
>CpuArchAttributes = Attributes &
> NONEXCLUSIVE_MEMORY_ATTRIBUTES;
> 
>if ( (Attributes & EFI_MEMORY_UC) == EFI_MEMORY_UC) {
> --
> 2.7.4

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

[edk2] [edk2-MetaDataExpressionSyntaxSpecification] Create release/1.30 branch

[Kinney, Michael D]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 book.json | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/book.json b/book.json
index 0cf1c3e..e535b93 100644
--- a/book.json
+++ b/book.json
@@ -1,8 +1,7 @@
 {
   "variables" : {
-"draft"   : "yes",
 "title"   : "EDK II Meta-Data Expression Syntax Specification",
-"version" : "Revision 1.2"
+"version" : "Revision 1.3"
   },
 
   "plugins": ["puml"],
-- 
2.14.2.windows.3

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

[edk2] [edk2-InfSpecification] Create release/1.27 branch

[Kinney, Michael D]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 book.json | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/book.json b/book.json
index 1fdd962..447dfe4 100644
--- a/book.json
+++ b/book.json
@@ -1,8 +1,7 @@
 {
   "variables" : {
-"draft"   : "yes",
 "title"   : "EDK II Module Information (INF) File Specification",
-"version" : "Revision 1.26"
+"version" : "Revision 1.27"
   },
 
   "plugins": ["puml"],
-- 
2.14.2.windows.3

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

[edk2] [edk2-BuildSpecification] Create release/1.28 branch

[Kinney, Michael D]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 book.json | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/book.json b/book.json
index 3450248..5a8fef1 100644
--- a/book.json
+++ b/book.json
@@ -1,8 +1,7 @@
 {
   "variables" : {
-"draft"   : "yes",
 "title"   : "EDK II Build Specification",
-"version" : "Revision 1.27"
+"version" : "Revision 1.28"
   },
 
   "plugins": ["puml"],
-- 
2.14.2.windows.3

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

[edk2] [edk2-DecSpecification] Create release/1.27 branch

[Kinney, Michael D]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 book.json | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/book.json b/book.json
index 46135ac..45f99c9 100644
--- a/book.json
+++ b/book.json
@@ -1,8 +1,7 @@
 {
   "variables" : {
-"draft"   : "yes",
 "title"   : "EDK II Package Declaration (DEC) File Format Specification",
-"version" : "Revision 1.26"
+"version" : "Revision 1.27"
   },
 
   "plugins": ["puml"],
-- 
2.14.2.windows.3

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

[edk2] [edk2-DscSpecification] Create release/1.28 branch

[Kinney, Michael D]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 book.json | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/book.json b/book.json
index 2ae4968..225e4eb 100644
--- a/book.json
+++ b/book.json
@@ -1,8 +1,7 @@
 {
   "variables" : {
-"draft"   : "yes",
 "title"   : "EDK II Platform Description (DSC) File Specification",
-"version" : "Revision 1.27"
+"version" : "Revision 1.28"
   },
 
   "plugins": ["puml"],
-- 
2.14.2.windows.3

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

[edk2] [edk2-FdfSpecification] Create release/1.28.01 branch

[Kinney, Michael D]

The release/1.28 branch already exists and contains the
1.27 version of the document.  Renaming the this release
branch  may break links to the document, so the branch
name is extended to 1.28.01.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 book.json | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/book.json b/book.json
index 8095a93..d33bf4e 100644
--- a/book.json
+++ b/book.json
@@ -1,8 +1,7 @@
 {
   "variables" : {
-"draft"   : "yes",
 "title"   : "EDK II Flash Description (FDF) File Specification",
-"version" : "Revision 1.28"
+"version" : "Revision 1.28.01"
   },
 
   "plugins": ["puml"],
-- 
2.14.2.windows.3

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

Re: [edk2] [PATCH 1/1] MdeModulePkg/Gcd: Fix bug of attribute conversion

[Kinney, Michael D]

Star,

Can you update my patch with the additional comments
and commit log message that clarifies the behavior
of gDS->SetMemorySpaceAttributes() for different bit 
settings?

Thanks,

Mike

> -Original Message-
> From: Yao, Jiewen
> Sent: Monday, April 2, 2018 7:34 PM
> To: Zeng, Star <star.z...@intel.com>; Wang, Jian J
> <jian.j.w...@intel.com>; Kinney, Michael D
> <michael.d.kin...@intel.com>; Heyi Guo
> <heyi@linaro.org>; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Yi Li
> <phoenix.l...@huawei.com>; Gao, Liming
> <liming@intel.com>; Dong, Eric
> <eric.d...@intel.com>; Renhao Liang
> <liangren...@huawei.com>
> Subject: RE: [PATCH 1/1] MdeModulePkg/Gcd: Fix bug of
> attribute conversion
> 
> That is good idea.
> 
> Just add more description as the code comment, please.
> 
> It is easy for code review later.
> 
> Thank you
> Yao Jiewen
> 
> 
> > -Original Message-
> > From: Zeng, Star
> > Sent: Tuesday, April 3, 2018 10:33 AM
> > To: Yao, Jiewen <jiewen@intel.com>; Wang, Jian J
> <jian.j.w...@intel.com>;
> > Kinney, Michael D <michael.d.kin...@intel.com>; Heyi
> Guo
> > <heyi@linaro.org>; edk2-devel@lists.01.org
> > Cc: Ni, Ruiyu <ruiyu...@intel.com>; Yi Li
> <phoenix.l...@huawei.com>; Gao,
> > Liming <liming@intel.com>; Dong, Eric
> <eric.d...@intel.com>; Renhao
> > Liang <liangren...@huawei.com>; Zeng, Star
> <star.z...@intel.com>
> > Subject: RE: [PATCH 1/1] MdeModulePkg/Gcd: Fix bug of
> attribute conversion
> >
> > Agree.
> >
> > And I agree we need the fix at
> > https://lists.01.org/pipermail/edk2-devel/2018-
> April/023364.html from Mike
> > for compatibility.
> > And I think more precious and precise information need
> to be added into the
> > commit log or code comments since we have been crazy
> about handling
> > attributes in the GCD service. :)
> >
> >
> > Thanks,
> > Star
> > -Original Message-
> > From: Yao, Jiewen
> > Sent: Tuesday, April 3, 2018 10:26 AM
> > To: Wang, Jian J <jian.j.w...@intel.com>; Zeng, Star
> <star.z...@intel.com>;
> > Kinney, Michael D <michael.d.kin...@intel.com>; Heyi
> Guo
> > <heyi@linaro.org>; edk2-devel@lists.01.org
> > Cc: Ni, Ruiyu <ruiyu...@intel.com>; Yi Li
> <phoenix.l...@huawei.com>; Gao,
> > Liming <liming@intel.com>; Dong, Eric
> <eric.d...@intel.com>; Renhao
> > Liang <liangren...@huawei.com>
> > Subject: RE: [PATCH 1/1] MdeModulePkg/Gcd: Fix bug of
> attribute conversion
> >
> > I have a discussion with Star/Jian.
> >
> > The expectation for the CPU driver is to handle
> PageAttribute.
> > The expectation for the platform driver is to use
> GetAttribute(), AND/OR
> > attribute, then call SetAttribute().
> > Because the DRAM always has a cache attribute (no
> matter UC or WB), 0 should
> > not happen. (0 might happen for a GCD reserved memory,
> but there is no need
> > to set page attribute)
> >
> > If all drivers use above way, there won't be any
> issue. There is no need to
> > introduce a new protocol so far.
> >
> > We did encounter some error, because the
> platform/silicon/CPU code is not
> > updated yet. (For example, the MinnowMax which is
> using binary) The fix to
> > filter 0 seems a workable way to resolve the
> compatibility issue.
> >
> > Later, I suggest we update MinnowMax binary - Add
> paging handling for CPU
> > driver, and use GetAttribute()/SetAttribute() for
> platform/silicon code.
> >
> >
> > Thank you
> > Yao Jiewen
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of
> > > Wang, Jian J
> > > Sent: Tuesday, April 3, 2018 9:24 AM
> > > To: Zeng, Star <star.z...@intel.com>; Kinney,
> Michael D
> > > <michael.d.kin...@intel.com>; Heyi Guo
> <heyi@linaro.org>;
> > > edk2-devel@lists.01.org
> > > Cc: Ni, Ruiyu <ruiyu...@intel.com>; Yi Li
> <phoenix.l...@huawei.com>;
> > > Gao, Liming <liming@intel.com>; Dong, Eric
> <eric.d...@intel.com>;
> > > Renhao Liang <liangren...@huawei.com>
> > > Subject: Re: [edk2] [PATCH 1/1] MdeModulePkg/Gcd:
> Fix bug of attribute
> > > conversion
> > >
> > > The NX Memory Protection and Heap Guard features
> need to clear

Re: [edk2] Question regarding structure PCD

[Kinney, Michael D]

Jeff,

You can provide default values for structure fields
in the DEC file.

Liming has an example posted in the following branch:

https://github.com/lgao4/edk2/tree/UDK2018

DEC file example in TestPkg:

https://github.com/lgao4/edk2/blob/UDK2018/TestPkg/TestPkg.dec

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of jbrasen.qdt
> Sent: Monday, March 26, 2018 11:51 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] Question regarding structure PCD
> 
> Hello,
> 
>I was implementing support for PCDs in my platform
> using the new structure PCD support, and I had a
> question regarding this. Is it possible in the dec file
> to define the default values of a PCD defined as a
> structure using this format or just the byte array
> format?
> 
> Thanks,
> Jeff Brasen
> 
> ___
> 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] [edk2 UsbMassStorageDxe v1 1/1] MdeModulePkg/Usb: Replace macro USB_BOOT_IO_BLOCKS

[Kinney, Michael D]

One minor comment.

  #define USB_BOOT_MAX_CARRY_SIZE 0x1

Should be

  #define USB_BOOT_MAX_CARRY_SIZE SIZE_64KB

Mike

> -Original Message-
> From: Zeng, Star
> Sent: Wednesday, March 21, 2018 5:41 AM
> To: Ming Huang <ming.hu...@linaro.org>; Ni, Ruiyu
> <ruiyu...@intel.com>; leif.lindh...@linaro.org; linaro-
> u...@lists.linaro.org; edk2-devel@lists.01.org; Dong,
> Eric <eric.d...@intel.com>
> Cc: ard.biesheu...@linaro.org; Kinney, Michael D
> <michael.d.kin...@intel.com>; Gao, Liming
> <liming@intel.com>; guoh...@huawei.com;
> wanghuiqi...@huawei.com; huangmin...@huawei.com;
> zhangjinso...@huawei.com; mengfanr...@huawei.com;
> huangda...@hisilicon.com; wai...@126.com
> Subject: RE: [edk2 UsbMassStorageDxe v1 1/1]
> MdeModulePkg/Usb: Replace macro USB_BOOT_IO_BLOCKS
> 
> Ming,
> 
> Basically, I am ok with the change in this patch. There
> are two comments.
> 
> 1. Please add more background information about the
> specific device in the commit log. For example, you
> mentioned " like some virtual CD-ROM from BMC " in
> previous patch.
> 2. Please make sure building pass with the patch on
> different tool chains. I tried to build with the patch
> on VS2015, but met building failure like below.
> warning C4244: '=': conversion from 'UINT32' to
> 'UINT16', possible loss of data
> 
> 
> Ray,
> 
> Do you have other concern?
> 
> 
> Thanks,
> Star
> -Original Message-
> From: Ming Huang [mailto:ming.hu...@linaro.org]
> Sent: Thursday, March 15, 2018 8:30 PM
> To: leif.lindh...@linaro.org; linaro-
> u...@lists.linaro.org; edk2-devel@lists.01.org; Zeng,
> Star <star.z...@intel.com>; Dong, Eric
> <eric.d...@intel.com>
> Cc: ard.biesheu...@linaro.org; Kinney, Michael D
> <michael.d.kin...@intel.com>; Gao, Liming
> <liming@intel.com>; guoh...@huawei.com;
> wanghuiqi...@huawei.com; huangmin...@huawei.com;
> zhangjinso...@huawei.com; mengfanr...@huawei.com;
> huangda...@hisilicon.com; wai...@126.com; Ming Huang
> <ming.hu...@linaro.org>
> Subject: [edk2 UsbMassStorageDxe v1 1/1]
> MdeModulePkg/Usb: Replace macro USB_BOOT_IO_BLOCKS
> 
> Booting from USB may fail while the macro
> USB_BOOT_IO_BLOCKS set to 128 because the block size of
> some USB devices are exceeded 512. So,the count blocks
> to transfer should be calculated by block size of the
> USB devices.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang <ming.hu...@linaro.org>
> ---
>  MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c |
> 16 
> MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.h |
> 4 ++--
>  2 files changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git
> a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
> b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
> index b84bfd2d7290..b38cb6116bf4 100644
> ---
> a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
> +++
> b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
> @@ -814,11 +814,13 @@ UsbBootReadBlocks (
>USB_BOOT_READ10_CMD   ReadCmd;
>EFI_STATUSStatus;
>UINT16Count;
> +  UINT16CountMax;
>UINT32BlockSize;
>UINT32ByteSize;
>UINT32Timeout;
> 
>BlockSize = UsbMass->BlockIoMedia.BlockSize;
> +  CountMax = USB_BOOT_MAX_CARRY_SIZE / BlockSize;
>Status= EFI_SUCCESS;
> 
>while (TotalBlock > 0) {
> @@ -827,7 +829,7 @@ UsbBootReadBlocks (
>  // on the device. We must split the total block
> because the READ10
>  // command only has 16 bit transfer length (in the
> unit of block).
>  //
> -Count = (UINT16)((TotalBlock <
> USB_BOOT_IO_BLOCKS) ? TotalBlock : USB_BOOT_IO_BLOCKS);
> +Count = (UINT16)((TotalBlock < CountMax) ?
> TotalBlock : CountMax);
>  ByteSize  = (UINT32)Count * BlockSize;
> 
>  //
> @@ -890,11 +892,13 @@ UsbBootWriteBlocks (
>USB_BOOT_WRITE10_CMD  WriteCmd;
>EFI_STATUSStatus;
>UINT16Count;
> +  UINT16CountMax;
>UINT32BlockSize;
>UINT32ByteSize;
>UINT32Timeout;
> 
>BlockSize = UsbMass->BlockIoMedia.BlockSize;
> +  CountMax = USB_BOOT_MAX_CARRY_SIZE / BlockSize;
>Status= EFI_SUCCESS;
> 
>while (TotalBlock > 0) {
> @@ -903,7 +907,7 @@ UsbBootWriteBlocks (
>  // on the device. We must split the total block
> because the WRITE10
>  // command only has 16 bit tra

Re: [edk2] [PATCH 00/14] rid PiSmmCpuDxeSmm of DB-encoded instructions

[Kinney, Michael D]

Laszlo,

I do like this typedef idea.

  typedef VOID (X86_ASSEMBLY_LABEL) (VOID);

Maybe change the name so it is clearer that 
this should never be used in a call.  A comment
block about the typedef can also clarify the
expected usage.

  typedef VOID (X86_ASSEMBLY_PATCH_LABEL) (VOID);

Thanks,

Mike

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, February 5, 2018 11:23 AM
> To: Kinney, Michael D <michael.d.kin...@intel.com>;
> edk2-devel-01 <edk2-devel@lists.01.org>
> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>; Dong,
> Eric <eric.d...@intel.com>; Yao, Jiewen
> <jiewen@intel.com>; Leif Lindholm
> <leif.lindh...@linaro.org>; Gao, Liming
> <liming@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>
> Subject: Re: [PATCH 00/14] rid PiSmmCpuDxeSmm of DB-
> encoded instructions
> 
> On 02/05/18 19:22, Kinney, Michael D wrote:
> > Laszlo,
> >
> > Let's see if we can close on the timeline for
> > the .S/.asm RFC this week.
> >
> > I am concerned about making them UINT8 from C code
> > because future maintainer may think that the patch
> > value type is UINT8.
> >
> > Labels in assembly that are defined to be a function
> > that is callable from C code does not have a storage
> > type.  Why can't we make these labels the same way?
> 
> To my understanding, the labels in the NASM source code
> for functions
> and variables look the same; the actual declaration
> only comes from the
> C code.
> 
> (Assuming we declare a NASM label as a function in the
> C source, nothing
> in the toolchain enforces an actual match between
> caller and callee; it
> is possible to call the function (from C) through a
> declaration that
> doesn't match the actual assembly implementation. IOW
> it's up to us to
> avoid such bugs.)
> 
> If I understand correctly, you are suggesting that we
> take a label from
> the NASM source that stands right after an instruction
> to patch, and we
> declare it as a function in the C source. (With what
> prototype though?
> The label does not actually introduce a function
> definition in the
> assembly code; it would make no sense to call it.)
> Then, for the
> patching, I presume your suggestion is to convert the
> address of the
> function to UINTN, perform the subtraction, etc.
> Something like:
> 
>   typedef VOID (X86_ASSEMBLY_LABEL) (VOID);
> 
> (This is not a pointer-to-function type, but a function
> type.)
> 
> A declaration using the typedef would be
> 
>   extern X86_ASSEMBLY_LABEL gPatchCr3;
> 
> (This declares an extern function, not a pointer to a
> function.)
> 
> The patching function would take a pointer to a
> function:
> 
>   VOID
>   EFIAPI
>   PatchInstructionX86 (
> OUT X86_ASSEMBLY_LABEL *InstructionEnd,
> IN  UINT64 PatchValue,
> IN  UINTN  ValueSize
> );
> 
> and the implementation would have to do e.g.
> 
>   WriteUnaligned32 (
> (UINT32 *)(UINTN)InstructionEnd - 1,
> (UINT32)PatchValue
> );
> 
> It would be called like
> 
>   PatchInstructionX86 (, Value, 4);
> 
> 
> But, what does this buy us in comparison to just:
> 
>   typedef UINT8 X86_ASSEMBLY_LABEL;
> 
> ?
> 
> If you worry that a future maintainer misunderstands
> the UINT8, then we
> can as well hide the UINT8 behind a typedef;
> X86_ASSEMBLY_LABEL doesn't
> have to be a function type for the hiding. (Conversely,
> when using a
> function type as underlying type, I worry that a future
> maintainer might
> be tempted to call them :) )
> 
> Thanks,
> Laszlo
> 
> >> -Original Message-
> >> From: Laszlo Ersek [mailto:ler...@redhat.com]
> >> Sent: Monday, February 5, 2018 2:28 AM
> >> To: Kinney, Michael D <michael.d.kin...@intel.com>;
> edk2-
> >> devel-01 <edk2-devel@lists.01.org>
> >> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>;
> Dong,
> >> Eric <eric.d...@intel.com>; Yao, Jiewen
> >> <jiewen@intel.com>; Leif Lindholm
> >> <leif.lindh...@linaro.org>; Gao, Liming
> >> <liming@intel.com>; Ni, Ruiyu
> <ruiyu...@intel.com>
> >> Subject: Re: [PATCH 00/14] rid PiSmmCpuDxeSmm of DB-
> >> encoded instructions
> >>
> >> On 02/03/18 01:45, Kinney, Michael D wrote:
> >>> Laszlo,
> >>>
> >>> Thanks for all the work on this series and the very
> >>> detailed commit messages.
> >>>
> >>> Liming's email on removing the .S and .asm files is
> an

Re: [edk2] [PATCH 1/2] MdePkg/Base.h: Ensure safe bitwise operations.

[Kinney, Michael D]

Marvin,

Thanks.  I agree that there may be some compiler behavior assumptions.

I would prefer we add to Base.h tests for the expected behavior 
assumptions and break the build if the compiler does not adhere
to those assumptions.  We have already added these to verify the
size of base types and the size of enums.

/**
  Verifies the storage size of a given data type.

  This macro generates a divide by zero error or a zero size array declaration 
in
  the preprocessor if the size is incorrect.  These are declared as "extern" so
  the space for these arrays will not be in the modules.

  @param  TYPE  The date type to determine the size of.
  @param  Size  The expected size for the TYPE.

**/
#define VERIFY_SIZE_OF(TYPE, Size) extern UINT8 
_VerifySizeof##TYPE[(sizeof(TYPE) == (Size)) / (sizeof(TYPE) == (Size))]

//
// Verify that ProcessorBind.h produced UEFI Data Types that are compliant with
// Section 2.3.1 of the UEFI 2.3 Specification.
//
VERIFY_SIZE_OF (BOOLEAN, 1);
VERIFY_SIZE_OF (INT8, 1);
VERIFY_SIZE_OF (UINT8, 1);
VERIFY_SIZE_OF (INT16, 2);
VERIFY_SIZE_OF (UINT16, 2);
VERIFY_SIZE_OF (INT32, 4);
VERIFY_SIZE_OF (UINT32, 4);
VERIFY_SIZE_OF (INT64, 8);
VERIFY_SIZE_OF (UINT64, 8);
VERIFY_SIZE_OF (CHAR8, 1);
VERIFY_SIZE_OF (CHAR16, 2);

//
// The following three enum types are used to verify that the compiler
// configuration for enum types is compliant with Section 2.3.1 of the 
// UEFI 2.3 Specification. These enum types and enum values are not 
// intended to be used. A prefix of '__' is used avoid conflicts with
// other types.
//
typedef enum {
  __VerifyUint8EnumValue = 0xff
} __VERIFY_UINT8_ENUM_SIZE;

typedef enum {
  __VerifyUint16EnumValue = 0x
} __VERIFY_UINT16_ENUM_SIZE;

typedef enum {
  __VerifyUint32EnumValue = 0x
} __VERIFY_UINT32_ENUM_SIZE;

VERIFY_SIZE_OF (__VERIFY_UINT8_ENUM_SIZE, 4);
VERIFY_SIZE_OF (__VERIFY_UINT16_ENUM_SIZE, 4);
VERIFY_SIZE_OF (__VERIFY_UINT32_ENUM_SIZE, 4);


Mike


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Marvin Häuser
> Sent: Thursday, March 1, 2018 3:11 AM
> To: edk2-devel@lists.01.org; Kinney, Michael D
> <michael.d.kin...@intel.com>
> Cc: ler...@redhat.com; Gao, Liming
> <liming@intel.com>
> Subject: Re: [edk2] [PATCH 1/2] MdePkg/Base.h: Ensure
> safe bitwise operations.
> 
> 
> > -Original Message-
> > From: Kinney, Michael D <michael.d.kin...@intel.com>
> > Sent: Thursday, March 1, 2018 2:42 AM
> > To: Marvin Häuser <marvin.haeu...@outlook.com>; edk2-
> > de...@lists.01.org; Kinney, Michael D
> <michael.d.kin...@intel.com>
> > Cc: ler...@redhat.com; Gao, Liming
> <liming@intel.com>
> > Subject: RE: [edk2] [PATCH 1/2] MdePkg/Base.h: Ensure
> safe bitwise
> > operations.
> >
> > Hi Marvin,
> >
> > Yes.  I have been reading the thread.
> >
> > Lots of really good analysis.
> >
> > However, it does not make sense to me to add 'u' to
> the smaller BITxx,
> > BASExx, and SIZExx macros if we have constants in
> other places that do not
> > add the 'u'. I think this patch may increase the
> inconsistency of the whole
> > tree.
> 
> Basically applying this to the BIT definitions first
> was to see whether the concept is percepted as a whole.
> Of course this should be applied to all definitions
> that are at some point used as a mask, which I
> continued to do locally.
> 
> >
> > If we don’t make this change, what types of issues do
> we need to fix and
> > what would the fix entail?
> 
> To be honest, actual issues are very unlikely to happen
> as all architectures supported by the specification use
> two-complements for negative values.
> Furthermore, all currently supported compilers
> implement bitwise operations for signed integers
> seemingly the same way as for unsigned types.
> However, if either will change in the future, code will
> silently break as in many mask operations will return
> values not intended by the code.
> 
> If you are not interested in the solution concepts
> previously discussed, I propose as least a Unit Test to
> verify the operations used in praxis work out fine.
> 
> Thanks,
> Marvin.
> 
> >
> > Mike
> >
> > > -Original Message-
> > > From: Marvin Häuser
> [mailto:marvin.haeu...@outlook.com]
> > > Sent: Wednesday, February 28, 2018 10:52 AM
> > > To: edk2-devel@lists.01.org; Kinney, Michael D
> > > <michael.d.kin...@intel.com>
> > > Cc: ler...@redhat.com; Gao, Liming
> > > <liming@intel.com>
> > > Subject: RE: [edk2] [PATCH 1/2] MdePkg/Base.h:
> Ensure safe bitwise
> > > operations.
> > >
>

Re: [edk2] [PATCH 01/20] OvmfPkg/MemEncryptSevLib: rewrap to 79 characters width

[Kinney, Michael D]

Laszlo,

Sorting #includes looks strange to me.

We usually include the top level environment include
first (e.g. ) and then the libs, protocols,
ppis, GUIDs grouped together.

If it is a lib module, the produced libs are listed
first followed by the consumed libs.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Laszlo Ersek
> Sent: Thursday, March 1, 2018 4:04 PM
> To: edk2-devel-01 
> Cc: Justen, Jordan L ;
> Brijesh Singh ; Ard Biesheuvel
> 
> Subject: [edk2] [PATCH 01/20] OvmfPkg/MemEncryptSevLib:
> rewrap to 79 characters width
> 
> There are many overlong lines; it's hard to work with
> the library like
> this. Rewrap all files to 79 columns.
> 
> Cc: Ard Biesheuvel 
> Cc: Brijesh Singh 
> Cc: Jordan Justen 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Laszlo Ersek 
> ---
> 
> OvmfPkg/Library/BaseMemEncryptSevLib/BaseMemEncryptSevL
> ib.inf   |   7 +-
>  OvmfPkg/Include/Library/MemEncryptSevLib.h
> |  20 ++-
> 
> OvmfPkg/Library/BaseMemEncryptSevLib/X64/VirtualMemory.
> h| 111 --
> 
> OvmfPkg/Library/BaseMemEncryptSevLib/Ia32/MemEncryptSev
> Lib.c|  34 +++--
> 
> OvmfPkg/Library/BaseMemEncryptSevLib/MemEncryptSevLibIn
> ternal.c |   8 +-
> 
> OvmfPkg/Library/BaseMemEncryptSevLib/X64/MemEncryptSevL
> ib.c |  58 ---
> 
> OvmfPkg/Library/BaseMemEncryptSevLib/X64/VirtualMemory.
> c| 158 +---
>  7 files changed, 253 insertions(+), 143 deletions(-)
> 
> diff --git
> a/OvmfPkg/Library/BaseMemEncryptSevLib/BaseMemEncryptSe
> vLib.inf
> b/OvmfPkg/Library/BaseMemEncryptSevLib/BaseMemEncryptSe
> vLib.inf
> index 3cfd80a28c1d..81b075194ace 100644
> ---
> a/OvmfPkg/Library/BaseMemEncryptSevLib/BaseMemEncryptSe
> vLib.inf
> +++
> b/OvmfPkg/Library/BaseMemEncryptSevLib/BaseMemEncryptSe
> vLib.inf
> @@ -1,45 +1,48 @@
>  ## @file
>  #  Library provides the helper functions for SEV guest
>  #
>  # Copyright (c) 2017 Advanced Micro Devices. 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.
> +#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND,
> EITHER EXPRESS OR
> +#  IMPLIED.
>  #
>  #
>  ##
> 
>  [Defines]
>INF_VERSION= 1.25
>BASE_NAME  = MemEncryptSevLib
>FILE_GUID  = c1594631-3888-4be4-
> 949f-9c630dbc842b
>MODULE_TYPE= BASE
>VERSION_STRING = 1.0
>LIBRARY_CLASS  =
> MemEncryptSevLib|PEIM DXE_DRIVER DXE_RUNTIME_DRIVER
> DXE_SMM_DRIVER UEFI_DRIVER
> 
>  #
> -# The following information is for reference only and
> not required by the build tools.
> +# The following information is for reference only and
> not required by the build
> +# tools.
>  #
>  # VALID_ARCHITECTURES   = IA32 X64
>  #
> 
>  [Packages]
>MdePkg/MdePkg.dec
>MdeModulePkg/MdeModulePkg.dec
>OvmfPkg/OvmfPkg.dec
>UefiCpuPkg/UefiCpuPkg.dec
> 
>  [Sources.X64]
>MemEncryptSevLibInternal.c
>X64/MemEncryptSevLib.c
>X64/VirtualMemory.c
> 
>  [Sources.IA32]
>MemEncryptSevLibInternal.c
>Ia32/MemEncryptSevLib.c
> 
>  [LibraryClasses]
> diff --git a/OvmfPkg/Include/Library/MemEncryptSevLib.h
> b/OvmfPkg/Include/Library/MemEncryptSevLib.h
> index b6753762423e..4f3ba9f22cb4 100644
> --- a/OvmfPkg/Include/Library/MemEncryptSevLib.h
> +++ b/OvmfPkg/Include/Library/MemEncryptSevLib.h
> @@ -18,64 +18,68 @@
>  #define _MEM_ENCRYPT_SEV_LIB_H_
> 
>  #include 
> 
>  /**
>Returns a boolean to indicate whether SEV is enabled
> 
>@retval TRUE   SEV is active
>@retval FALSE  SEV is not enabled
>**/
>  BOOLEAN
>  EFIAPI
>  MemEncryptSevIsEnabled (
>VOID
>);
> 
>  /**
>This function clears memory encryption bit for the
> memory region specified
>by BaseAddress and Number of pages from the current
> page table context.
> 
> -  @param[in]  BaseAddress   The physical
> address that is the start address
> -of a memory
> region.
> -  @param[in]  NumberOfPages The number of
> pages from start memory region.
> +  @param[in]  BaseAddress   The physical
> address that is the start
> +address of a
> memory region.
> +  @param[in]  NumberOfPages The number of
> pages from start memory
> + 

Re: [edk2] Can you set a PCD value DSC default per ModuleType?

[Kinney, Michael D]

Andrew,

DSC does not support module type specific syntax.
Just arch specific syntax.

https://edk2-docs.gitbooks.io/edk-ii-dsc-specification/content/2_dsc_overview/29_pcd_sections.html#29-pcd-sections

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Andrew Fish
> Sent: Thursday, March 1, 2018 8:07 PM
> To: edk2-devel 
> Subject: Re: [edk2] Can you set a PCD value DSC default
> per ModuleType?
> 
> Sorry for a FeatureFlag, obviously anything dynamic
> needs to be generic.
> 
> Thanks,
> 
> Andrew Fish
> 
> > On Mar 1, 2018, at 8:05 PM, Andrew Fish
>  wrote:
> >
> > Can you set a PCD value DSC default per ModuleType?
> If not why not?
> >
> > Thanks,
> >
> > Andrew Fish
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdePkg/UefiDevicePathLib: Fix print logic in DevPathToTextiSCSI

[Kinney, Michael D]

Why divide by sizeof(UINT8)?  sizeof() always returns the size in bytes.

Index is type UINTN, so it will always be >=0, so I do
think the loop will ever exit.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Songpeng Li
> Sent: Thursday, September 27, 2018 12:37 AM
> To: edk2-devel@lists.01.org
> Cc: Fu, Siyuan ; Wu, Jiaxin
> ; Gao, Liming
> 
> Subject: [edk2] [PATCH] MdePkg/UefiDevicePathLib: Fix
> print logic in DevPathToTextiSCSI
> 
> In DevPathToTextiSCSI(), ISCSIDevPath->Lun is printed
> in reversed orders.
> 
> Ref:
> https://bugzilla.tianocore.org/show_bug.cgi?id=1216
> Cc: Fu Siyuan 
> Cc: Wu Jiaxin 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Songpeng Li 
> ---
>  MdePkg/Library/UefiDevicePathLib/DevicePathToText.c |
> 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git
> a/MdePkg/Library/UefiDevicePathLib/DevicePathToText.c
> b/MdePkg/Library/UefiDevicePathLib/DevicePathToText.c
> index 7d8d304f6f..3f6478e43c 100644
> ---
> a/MdePkg/Library/UefiDevicePathLib/DevicePathToText.c
> +++
> b/MdePkg/Library/UefiDevicePathLib/DevicePathToText.c
> @@ -1548,7 +1548,7 @@ DevPathToTextiSCSI (
>  ISCSIDevPath->TargetName,
>  ISCSIDevPath->TargetPortalGroupTag
>  );
> -  for (Index = 0; Index < sizeof (ISCSIDevPath->Lun) /
> sizeof (UINT8); Index++) {
> +  for (Index = sizeof (ISCSIDevPath->Lun) / sizeof
> (UINT8) - 1; Index >= 0; Index--) {
>  UefiDevicePathLibCatPrint (Str, L"%02x", ((UINT8
> *)>Lun)[Index]);
>}
>Options = ISCSIDevPath->LoginOption;
> --
> 2.18.0.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 1/7] MdeModulePkg: introduce PE/COFF image emulator protocol

[Kinney, Michael D]

Hi Ard,

Yes.  I think it is simpler if an emulator module registers
one machine type at a time.  If an emulator module wants
to do a single registration and that registration supports
multiple machine types, then the emulator implementation
is more complex, but it is still feasible.

I think I see where things got confused.  The proposal from
Star for a new protocol produced by the DXE Core has some issues.
A refined proposal is shown below.  It also supports the idea that
an emulator module can be loaded and unloaded to support testing
from environments like the UEFI Shell to soft load an emulator,
test some images, and unload it.

Also, by having a protocol produced by the DXE Core, the emulator
module can tell if the DXE Core supports emulators or not 
by checking for the presence of this protocol.  The emulator
module can fail gracefully with some DEBUG() message and unload
if DXE Core does not support emulators.  This also allows the
option to update the DXE Core module to optionally support 
emulators using a PCD Feature Flag and remove some logic if
emulators are not required on a specific platform.

typedef
EFI_STATUS
(EFIAPI *EDKII_PECOFF_IMAGE_EMULATOR_ADD_EMULATOR) (
  IN EDKII_PECOFF_IMAGE_EMULATOR_PROTOCOL*This,
  IN EDKII_PECOFF_IMAGE_EMULATOR_IS_IMAGE_SUPPORTED  IsImageSupported,
  IN EDKII_PECOFF_IMAGE_EMULATOR_REGISTER_IMAGE  RegisterImage,
  IN EDKII_PECOFF_IMAGE_EMULATOR_UNREGISTER_IMAGEUnregisterImage
  );

typedef
EFI_STATUS
(EFIAPI *EDKII_PECOFF_IMAGE_EMULATOR_REMOVE_EMULATOR) (
  IN EDKII_PECOFF_IMAGE_EMULATOR_PROTOCOL*This,
  IN EDKII_PECOFF_IMAGE_EMULATOR_IS_IMAGE_SUPPORTED  IsImageSupported,
  IN EDKII_PECOFF_IMAGE_EMULATOR_REGISTER_IMAGE  RegisterImage,
  IN EDKII_PECOFF_IMAGE_EMULATOR_UNREGISTER_IMAGEUnregisterImage
  );

typedef struct _EDKII_PECOFF_IMAGE_EMULATOR_PROTOCOL {
  EDKII_PECOFF_IMAGE_EMULATOR_ADD_EMULATOR AddEmulator;
  EDKII_PECOFF_IMAGE_EMULATOR_REMOVE_EMULATOR  RemoveEmulator;
} EDKII_PECOFF_IMAGE_EMULATOR_PROTOCOL

The IsImageSupported(), RegisterImage(), and UnRegisterImage()
are added in a set in a single call to AddEmulator() from the
emulator module.  In LoadImage(), if IsImageSupported() returns
TRUE, LoadImage() uses the RegisterImage() and UnRegisterImage()
APIs that were added with the IsImageSupported() API in the
call to AddEmulator().

Thanks,

Mike

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, September 27, 2018 3:59 AM
> To: Zeng, Star 
> Cc: Kinney, Michael D ;
> edk2-devel@lists.01.org; Zimmer, Vincent
> ; Richardson, Brian
> ; Andrew Fish
> ; Leif Lindholm
> ; Dong, Eric
> ; Ni, Ruiyu ;
> Gao, Liming ; Carsey, Jaben
> ; Shi, Steven
> 
> Subject: Re: [PATCH v3 1/7] MdeModulePkg: introduce
> PE/COFF image emulator protocol
> 
> On 27 September 2018 at 02:48, Zeng, Star
>  wrote:
> > Yes. This idea also came to my mind last night, then
> no need introduce PeCoffEmulatorDxe and no platform
> change is needed.
> >
> 
> The only problem with this approach is that we cannot
> keep track of
> which emulator returned TRUE for IsSupported(), and so
> RegisterImage()
> and also UnregisterImage() will have to do some
> internal bookkeeping
> in the 'manager' protocol implementation that
> duplicates code in the
> emulators.
> 
> So could we flesh this out a bit before I dive into the
> code again and
> turn everything upside down?
> 
> - the PCI bus driver no longer checks the machine type
> - the BDS no longer checks the machine type for
> Driver images
> - CoreLoadImage() checks IsSupported() to establish
> whether the
> emulator manager has an emulator available that is
> willing to take
> charge of the image
> - what happens next? CoreLoadImage() calls
> RegisterImage() on what?
> Should IsSupported() return some kind of handle?
> 
> Also, perhaps we should simply stick with one emulator
> per machine
> type (which doesn't preclude an implementation from
> registering itself
> for multiple ones). That simplifies the IsSupported vs
> RegisterImage
> issue above as well (i.e., it is unambiguous *which*
> RegisterImage()
> should be called)
> 
> 
> 
> > -Original Message-
> > From: Kinney, Michael D
> > Sent: Thursday, September 27, 2018 1:32 AM
> > To: Ard Biesheuvel ; Zeng,
> Star ; Kinney, Michael D
> 
> > Cc: edk2-devel@lists.01.org; Zimmer, Vincent
> ; Richardson, Brian
> ; Andrew Fish
> ; Leif Lindholm
> ; Dong, Eric
> ; Ni, Ruiyu ;
> Gao, Liming ; Carsey, Jaben
> ; Shi, Steven
> 
> > Subject: RE: [PATCH v3 1/7] MdeModulePkg: introduce
> PE/COFF image emulator protocol
> >
> > Hi Ard,
> >
> > I think this registration protocol would be a new
> p

Re: [edk2] [PATCH v3 1/1] OvmfPkg/PlatformPei: clear CPU caches

[Kinney, Michael D]

Reviewed-by: Michael D Kinney 

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of
> marcandre.lur...@redhat.com
> Sent: Tuesday, October 2, 2018 5:17 AM
> To: edk2-devel@lists.01.org
> Cc: Justen, Jordan L ;
> Anthony Perard ; Laszlo Ersek
> 
> Subject: [edk2] [PATCH v3 1/1] OvmfPkg/PlatformPei:
> clear CPU caches
> 
> From: Marc-André Lureau 
> 
> This is for conformance with the TCG "Platform Reset
> Attack Mitigation
> Specification". Because clearing the CPU caches at boot
> doesn't impact
> performance significantly, do it unconditionally, for
> simplicity's
> sake.
> 
> Flush the cache on all logical processors, thanks to
> EFI_PEI_MP_SERVICES_PPI and CacheMaintenanceLib.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Anthony Perard 
> Cc: Julien Grall 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marc-André Lureau
> 
> Message-Id: <20181002120730.13013-1-
> marcandre.lur...@redhat.com>
> ---
> 
> v3:
>   - update top comment with notes about TCG spec
>   - sort headers inclusion
> 
>  OvmfPkg/PlatformPei/PlatformPei.inf |   2 +
>  OvmfPkg/PlatformPei/Platform.h  |   5 +
>  OvmfPkg/PlatformPei/ClearCache.c| 117
> 
>  OvmfPkg/PlatformPei/Platform.c  |   1 +
>  4 files changed, 125 insertions(+)
> 
> diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf
> b/OvmfPkg/PlatformPei/PlatformPei.inf
> index 9c5ad9961c4a..5c8dd0fe6d72 100644
> --- a/OvmfPkg/PlatformPei/PlatformPei.inf
> +++ b/OvmfPkg/PlatformPei/PlatformPei.inf
> @@ -30,6 +30,7 @@
> 
>  [Sources]
>AmdSev.c
> +  ClearCache.c
>Cmos.c
>Cmos.h
>FeatureControl.c
> @@ -54,6 +55,7 @@
> 
>  [LibraryClasses]
>BaseLib
> +  CacheMaintenanceLib
>DebugLib
>HobLib
>IoLib
> diff --git a/OvmfPkg/PlatformPei/Platform.h
> b/OvmfPkg/PlatformPei/Platform.h
> index f942e61bb4f9..b12a5c1f5f78 100644
> --- a/OvmfPkg/PlatformPei/Platform.h
> +++ b/OvmfPkg/PlatformPei/Platform.h
> @@ -83,6 +83,11 @@ InstallFeatureControlCallback (
>VOID
>);
> 
> +VOID
> +InstallClearCacheCallback (
> +  VOID
> +  );
> +
>  EFI_STATUS
>  InitializeXen (
>VOID
> diff --git a/OvmfPkg/PlatformPei/ClearCache.c
> b/OvmfPkg/PlatformPei/ClearCache.c
> new file mode 100644
> index ..7d15fd925c3c
> --- /dev/null
> +++ b/OvmfPkg/PlatformPei/ClearCache.c
> @@ -0,0 +1,117 @@
> +/**@file
> +  Install a callback to clear cache on all processors.
> +  This is for conformance with the TCG "Platform Reset
> Attack Mitigation
> +  Specification". Because clearing the CPU caches at
> boot doesn't impact
> +  performance significantly, do it unconditionally, for
> simplicity's
> +  sake.
> +
> +  Copyright (C) 2018, Red Hat, Inc.
> +
> +  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 
> +
> +#include "Platform.h"
> +
> +/**
> +  Invalidate data & instruction caches.
> +  All APs execute this function in parallel. The BSP
> executes the function
> +  separately.
> +
> +  @param[in,out] WorkSpace  Pointer to the input/output
> argument workspace
> +shared by all processors.
> +**/
> +STATIC
> +VOID
> +EFIAPI
> +ClearCache (
> +  IN OUT VOID *WorkSpace
> +  )
> +{
> +  WriteBackInvalidateDataCache ();
> +  InvalidateInstructionCache ();
> +}
> +
> +/**
> +  Notification function called when
> EFI_PEI_MP_SERVICES_PPI becomes available.
> +
> +  @param[in] PeiServices  Indirect reference to the
> PEI Services Table.
> +  @param[in] NotifyDescriptor Address of the
> notification descriptor data
> +  structure.
> +  @param[in] Ppi  Address of the PPI that
> was installed.
> +
> +  @return  Status of the notification. The status code
> returned from this
> +   function is ignored.
> +**/
> +STATIC
> +EFI_STATUS
> +EFIAPI
> +ClearCacheOnMpServicesAvailable (
> +  IN EFI_PEI_SERVICES   **PeiServices,
> +  IN EFI_PEI_NOTIFY_DESCRIPTOR  *NotifyDescriptor,
> +  IN VOID   *Ppi
> +  )
> +{
> +  EFI_PEI_MP_SERVICES_PPI *MpServices;
> +  EFI_STATUS  Status;
> +
> +  DEBUG ((DEBUG_INFO, "%a: %a\n", gEfiCallerBaseName,
> __FUNCTION__));
> +
> +  //
> +  // Clear cache on all the APs in parallel.
> +  //
> +  MpServices = Ppi;
> +  Status = MpServices->StartupAllAPs (
> + (CONST EFI_PEI_SERVICES
> **)PeiServices,
> + MpServices,
> + ClearCache,  //
> Procedure
> +

Re: [edk2] [PATCH] Maintainers.txt: add DynamicTablesPkg

[Kinney, Michael D]

Reviewed-by: Michael D Kinney 

Mike

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Tuesday, October 2, 2018 9:04 AM
> To: edk2-devel@lists.01.org
> Cc: Andrew Fish ; Laszlo Ersek
> ; Kinney, Michael D
> ; Evan Lloyd
> ; Sami Mujawar
> 
> Subject: [PATCH] Maintainers.txt: add DynamicTablesPkg
> 
> DynamicTablesPkg has been in edk2-staging[1] for some
> time now, and it is
> time for it to move into the main tree.
> [1] https://github.com/tianocore/edk2-
> staging/tree/dynamictables
> 
> Add Evan and Sami as maintainers of the new package, and
> let them bring
> it in themselves.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Leif Lindholm 
> ---
> 
> We'll need Reviewed-by: from both new maintainers.
> Github write permissions need to be added separately.
> 
> Please add some documentation at the specified URL
> before
> you import any code :)
> 
>  Maintainers.txt | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 7ebd53f662..072cf3ce8f 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -105,6 +105,11 @@ W:
> https://github.com/tianocore/tianocore.github.io/wiki/Du
> etPkg
>  M: Ruiyu Ni 
>  M: Hao Wu 
> 
> +DynamicTablesPkg
> +W:
> https://github.com/tianocore/tianocore.github.io/wiki/Dy
> namicTablesPkg
> +M: Evan Lloyd 
> +M: Sami Mujawar 
> +
>  EdkCompatibilityPkg
>  W:
> https://github.com/tianocore/tianocore.github.io/wiki/Ed
> kCompatibilityPkg
>  M: Liming Gao 
> --
> 2.11.0
D 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] Create new edk2-test repo

[Kinney, Michael D]

Supreeth,

I have created the edk2-test repository with the 
Readme.md, License.txt, and Contributions.txt files.

I have also created the "EDK II Test Maintainers"
team for developers that are maintainers of the test
infrastructure and test cases in this repository.

Best regards,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Supreeth Venkatesh
> Sent: Friday, October 5, 2018 9:53 AM
> To: Kinney, Michael D ;
> edk2-devel@lists.01.org
> Cc: Dong Wei ; Jin, Eric
> 
> Subject: Re: [edk2] [RFC] Create new edk2-test repo
> 
> Thanks Mike. I second that.
> Also, UEFI-SCT needs to find a place within edk2-test.
> Hope we can get this created before UEFI Taipei PlugFest
> (Oct 16) and after everyone's comments/review and
> approval.
> 
> Thanks,
> Supreeth
> 
> -Original Message-
> From: edk2-devel  On
> Behalf Of Kinney, Michael D
> Sent: Tuesday, September 25, 2018 6:34 PM
> To: edk2-devel@lists.01.org; Kinney, Michael D
> 
> Subject: [edk2] [RFC] Create new edk2-test repo
> 
> This is a proposal to create a new repository for tests
> called edk2-test.
> 
> The purpose of this repository is to provide test
> harnesses and test cases to test EDK II based firmware.
> 
> There is test related content in edk2-staging branches
> and as that content is completed, a location for tests
> is required.  This will provide core and platform
> developers the ability to test changes before commits
> are made and also provide a place to add new test cases
> for new features and functionality.
> 
> Thanks,
> 
> Mike
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> IMPORTANT NOTICE: The contents of this email and any
> attachments are confidential and may also be privileged.
> If you are not the intended recipient, please notify the
> sender immediately and do not disclose the contents to
> any other person, use it for any purpose, or store or
> copy the information in any medium. Thank you.
> ___
> 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 v1 1/6] PcAtChipsetPkg: Add MMIO Support to SerialIo Lib

[Kinney, Michael D]

Sami,

The BaseSerialPortLib16550 supports I/O port, MMIO, and PCI based UARTs.

PCDs are used to select the modes.

I would like to see the BaseSerialPortLib16550 used instead of
the serial port lib in PcAtChipsetPkg.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> On Behalf Of Sami Mujawar
> Sent: Friday, October 12, 2018 8:06 AM
> To: Ard Biesheuvel 
> Cc: Ni, Ruiyu ; nd ;
> Stephanie Hughes-Fitt ;
> edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH v1 1/6] PcAtChipsetPkg: Add
> MMIO Support to SerialIo Lib
> 
> Hi Ard,
> 
> I believe you are referring to
> MdeModulePkg\Library\BaseSerialPortLib16550\BaseSerialPor
> tLib16550.inf
> I have tried using this Serial Port Library. However,
> this has a dependency on PciLib which is difficult to
> resolve as we use the Serial port early in the boot.
> Please do let me know if you know a workaround to solve
> this issue.
> 
> Regards,
> 
> Sami Mujawar
> 
> -Original Message-
> From: Ard Biesheuvel 
> Sent: 12 October 2018 03:50 PM
> To: Sami Mujawar 
> Cc: edk2-devel@lists.01.org; Leif Lindholm
> ; Ruiyu Ni
> ; Evan Lloyd ;
> Matteo Carlini ; Stephanie
> Hughes-Fitt ; nd
> 
> Subject: Re: [PATCH v1 1/6] PcAtChipsetPkg: Add MMIO
> Support to SerialIo Lib
> 
> On 12 October 2018 at 16:40, Sami Mujawar
>  wrote:
> > Some virtual machine managers like kvmtool emulate the
> PC AT Serial
> > Port UART in the MMIO space so that architectures that
> do not support
> > I/O Mapped I/O can use the UART.
> >
> > This patch adds MMIO support to the PC AT
> SerialPortLib.
> >
> > PcdSerialUseMmio is used to select I/O or MMIO support.
> >   If PcdSerialUseMmio is
> > TRUE  - The value is read/written from MMIO space.
> > FALSE - The value is read/written from I/O space.
> > The Default is I/O space.
> >
> 
> IIUC kvmtool exposes a 8250, and our 8250 driver already
> implements support for MMIO mapped registers. Can't you
> use that instead?
> 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Sami Mujawar 
> > ---
> > The changes can be seen at
> >
> https://github.com/samimujawar/edk2/commit/84f908387d2031
> def5d374759e7
> > ad4cf90786c91
> >
> > Notes:
> > v1:
> > - Add support to read/write from UART registers
> using MMIO access
> > [SAMI]
> >
> >  PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf |
> 4 +
> > PcAtChipsetPkg/Library/SerialIoLib/SerialPortLib.c | 98
> > 
> >  2 files changed, 84 insertions(+), 18 deletions(-)
> >
> > diff --git
> a/PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
> > b/PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
> > index
> >
> 959d6e27c9812d201d44d9249070ab7758cbfe00..d0689793040fd93
> 0701b02dae51f
> > f59ea16a10c4 100644
> > ---
> a/PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
> > +++
> b/PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
> > @@ -2,6 +2,7 @@
> >  #   Library instance for SerialIo library class
> >  #
> >  #  Copyright (c) 2006 - 2014, Intel Corporation. All
> rights
> > reserved.
> > +#  Copyright (c) 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 @@ -23,6 +24,7 @@ [Defines]
> >
> >  [Packages]
> >MdePkg/MdePkg.dec
> > +  MdeModulePkg/MdeModulePkg.dec
> >
> >  [LibraryClasses]
> >BaseLib
> > @@ -31,3 +33,5 @@ [LibraryClasses]
> >  [Sources]
> >SerialPortLib.c
> >
> > +[FixedPcd]
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialUseMmio
> ## CONSUMES
> > diff --git
> a/PcAtChipsetPkg/Library/SerialIoLib/SerialPortLib.c
> > b/PcAtChipsetPkg/Library/SerialIoLib/SerialPortLib.c
> > index
> >
> d1a1c6a03facad09e781b5605e22a24e5f51c618..898e5f957aae998
> 624189c6b5389
> > 12da0439dfe8 100644
> > ---
> a/PcAtChipsetPkg/Library/SerialIoLib/SerialPortLib.c
> > +++
> b/PcAtChipsetPkg/Library/SerialIoLib/SerialPortLib.c
> > @@ -2,6 +2,8 @@
> >UART Serial Port library functions
> >
> >Copyright (c) 2006 - 2018, Intel Corporation. All
> rights
> > reserved.
> > +  Copyright (c) 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
> > @@ -57,6 +59,66 @@ UINT8   gParity   = 0;
> >  UINT8   gBreakSet = 0;
> >
> >  /**
> > +  Reads an 8-bit value from the serial port.
> > +
> > +  This function checks PcdSerialUseMmio to determine
> if I/O  mapped
> > + IO or Memory Mapped IO operations must be performed
> on  the serial
> > + port. It then uses the appropriate interface to  read
> the Value from
> > + the serial port.
> > +
> > +  If PcdSerialUseMmio is TRUE, then the value is read
> from MMIO space.
> > +  

Re: [edk2] TianoCore Community Meeting Minutes

[Kinney, Michael D]

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> On Behalf Of Leif Lindholm
> Sent: Friday, October 12, 2018 11:06 AM
> To: Laszlo Ersek 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] TianoCore Community Meeting Minutes
> 
> On Fri, Oct 12, 2018 at 06:07:01PM +0200, Laszlo Ersek
> wrote:
> > On 10/12/18 15:27, Leif Lindholm wrote:
> > > On Thu, Oct 11, 2018 at 10:43:57AM -0700, stephano
> wrote:
> >
> > >> Switching to Standard C Types
> > >> -
> > >> Both Shawn and Nate mentioned that the current
> system has been in place for
> > >> a long time and some people prefer the current
> setup. I can start an email
> > >> discussion around this issue specifically if anyone
> feels strongly that we
> > >> should be using standard types.
> > >
> > > So, I don't think we made it this far down the agenda
> on the US-EU
> > > call.
> > >
> > > One way would be to simply explicitly permit it,
> possibly with the
> > > constraint that every module needs to pick one and
> stick with it,
> > > unless people object.
> > >
> > > I think we'll want to discuss this in a US-EU call as
> well.
> >
> > I'm playing devil's advocate here -- because, in
> general, I'm a fan of
> > sticking with standard C as much as possible --, but I
> see a big
> > obstacle in the way.
> >
> > That obstacle is "Table 5. Common UEFI Data Types", in
> the UEFI spec.
> > Until a good portion of that table is expressed in
> terms of standard C
> > types as well (expanding upon the current definitions),
> possibly in an
> > edk2-level spec (i.e. not necessarily in the UEFI spec
> itself), I think
> > there's no chance to enable standard C types in edk2
> *meaningfully*.
> >
> > Because, as soon as you have to call a PI or UEFI
> interface, you'll have
> > to stick with the PI/UEFI spec types anyway.
> 
> I don't necessarily see that as an issue. But it is a
> good point that
> it can't just be the codebase changing.
> 
> Since we are however extremely specificly not looking to
> change the
> underlying storage types, all it would take would be to
> make a
> 2-column table into a 3-column table in both specs. Or
> just add a
> separate table for the mapping. Then edk2 could adopt the
> "permitted"
> rule as soon as the specs were out. Arguably (because
> we're not
> changing underlying types) we could do it before, but we
> _are_
> supposed to be the reference implementation, so it would
> be poor form.

I agree that it would be best if the specs list synonymous
type names.  We would have to guarantee in the edk2 implementation
that they types are identical.  One potential issue is support
for really old compilers.  If we can decide to only support
compilers that fully support the synonymous types, then that
would be clean.  Not sure what the ANSI C equivalents are for
INTN/UINTN on all compilers.

> 
> > >> Using Git Submodules (like we do with OpenSSL)
> > >> 
> > >
> > > We didn't make it here either. What would we use it
> _for_?
> > > I think the openssl case makes a lot of sense, but
> what else?
> >
> > We embed a bunch of other projects (libraries, mainly):
> > - Oniguruma
> > - Brotli
> > - fdt
> > - LZMA SDK
> > - ...
> 
> Sure. But do we know that is what was meant?
> 
> I certainly recall the "each package should be a
> submodule" idea from
> a (much) earlier conversation, and would like to ensure
> we're not
> resurrecting that.

Yes.  Those other projects was the brief discussion.
Not submodule per package.

> 
> Regards,
> 
> Leif
> ___
> 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/5] MdePkg/BaseSynchronizationLib GCC: fixes, cleanups

[Kinney, Michael D]

Laszlo,

Thanks for the reminder.  My knowledge of inline
GCC assembly syntax is very limited, so I am not
able to review this patch for correctness.  I can
ack it.

Acked-by: Michael D Kinney 

Perhaps Liming can do a more complete review.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Laszlo Ersek
> Sent: Monday, October 15, 2018 11:05 AM
> To: Kinney, Michael D ; Gao,
> Liming 
> Cc: edk2-devel-01 
> Subject: Re: [edk2] [PATCH 0/5]
> MdePkg/BaseSynchronizationLib GCC: fixes, cleanups
> 
> On 10/08/18 15:44, Laszlo Ersek wrote:
> > On 09/30/18 00:23, Laszlo Ersek wrote:
> >> Repo:   https://github.com/lersek/edk2.git
> >> Branch: inline_asm_rw_ops_1208
> >>
> >> This series mainly fixes the operand constraints
> (missing input-output
> >> qualifications) in
> "BaseSynchronizationLib/*/GccInline.c".
> >>
> >> (It would be better to remove these files altogether
> in favor of the
> >> already existing NASM implementation, but due to
> >> <https://bugzilla.tianocore.org/show_bug.cgi?id=881>,
> we can't generally
> >> do that in libraries yet.)
> >>
> >> Cc: Liming Gao 
> >> Cc: Michael D Kinney 
> >>
> >> Thanks,
> >> Laszlo
> >>
> >> Laszlo Ersek (5):
> >>   MdePkg/BaseSynchronizationLib GCC: fix whitespace
> and comments
> >>   MdePkg/BaseSynchronizationLib GCC: fix
> InternalSyncCompareExchange16()
> >>   MdePkg/BaseSynchronizationLib GCC: fix
> InternalSyncCompareExchange32()
> >>   MdePkg/BaseSynchronizationLib GCC: fix X64
> >> InternalSyncCompareExchange64()
> >>   MdePkg/BaseSynchronizationLib GCC: simplify IA32
> >> InternalSyncCompareExchange64()
> >>
> >>
> MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c |
> 42 +++--
> >>
> MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c  |
> 47 +++-
> >>  2 files changed, 34 insertions(+), 55 deletions(-)
> >>
> >
> > Ping :)
> 
> Ping
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdePkg/BaseStackCheckLib: add MSFT toolchain support

[Kinney, Michael D]

Jian,

I do not see a description of the parameters, return
values or required behavior for those APIs in the header
files.  How do you know if they are implemented correctly?

How would we write tests for these APIs?

Mike

> -Original Message-
> From: Wang, Jian J
> Sent: Wednesday, October 17, 2018 7:16 PM
> To: Kinney, Michael D ; Gao,
> Liming ; edk2-devel  boun...@lists.01.org>; edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Andrew Fish
> 
> Subject: RE: [edk2] [PATCH] MdePkg/BaseStackCheckLib: add
> MSFT toolchain support
> 
> Mike,
> 
> All those functions are declared in source files in
> Visual Studio except to
> __GSHandlerCheck(). But I can't find there's online link
> or document to those files
> and APIs. Is it ok to just list the file names?
> 
> VC\INCLUDE\vcruntime.h:
> __security_check_cookie
> __report_gsfailure
> 
> VC\INCLUDE\rtcapi.h:
> _RTC_CheckEsp
> _RTC_CheckStackVars
> _RTC_Shutdown
> _RTC_InitBase
> 
> VC\crt\src\vcruntime\gs_report.c
> __report_rangecheckfailure
> 
> I built the lib with all supported VS toolchains and all
> passed, but only tested
> with VS2015. I think I need to do more tests. Thanks for
> pointing it out.
> 
> Regards,
> Jian
> 
> 
> > -Original Message-
> > From: Kinney, Michael D
> > Sent: Thursday, October 18, 2018 9:36 AM
> > To: Gao, Liming ; Wang, Jian J
> ;
> > edk2-devel ; edk2-
> de...@lists.01.org;
> > Kinney, Michael D 
> > Cc: Yao, Jiewen ; Andrew Fish
> 
> > Subject: RE: [edk2] [PATCH] MdePkg/BaseStackCheckLib:
> add MSFT toolchain
> > support
> >
> > Jian,
> >
> > Is there a link to the documentation for these new
> > functions?  We should put the link in the file
> > headers.
> >
> > The link to docs should also be added to the BZ.
> >
> > Also, which VS compilers was this tested with?  Are
> > different implementations required for different VS
> > compilers?
> >
> > Mike
> >
> > > -Original Message-
> > > From: Gao, Liming
> > > Sent: Wednesday, October 17, 2018 6:22 PM
> > > To: Wang, Jian J ; edk2-devel
> > > ; edk2-
> > > de...@lists.01.org
> > > Cc: Kinney, Michael D ;
> Yao,
> > > Jiewen ; Andrew Fish
> > > 
> > > Subject: RE: [edk2] [PATCH] MdePkg/BaseStackCheckLib:
> add
> > > MSFT toolchain support
> > >
> > > Jian:
> > >   The patch is good to me. Reviewed-by: Liming Gao
> > > 
> > >
> > > Thanks
> > > Liming
> > > >-Original Message-
> > > >From: Wang, Jian J
> > > >Sent: Thursday, October 18, 2018 9:19 AM
> > > >To: edk2-devel ;
> edk2-
> > > de...@lists.01.org
> > > >Cc: Kinney, Michael D ;
> Yao,
> > > Jiewen
> > > >; Andrew Fish
> ;
> > > Gao, Liming
> > > >
> > > >Subject: RE: [edk2] [PATCH]
> MdePkg/BaseStackCheckLib:
> > > add MSFT toolchain
> > > >support
> > > >
> > > >Ping ... :)
> > > >
> > > >Regards,
> > > >Jian
> > > >
> > > >
> > > >> -Original Message-
> > > >> From: edk2-devel [mailto:edk2-devel-
> > > boun...@lists.01.org]
> > > >> Sent: Tuesday, October 16, 2018 8:59 AM
> > > >> To: edk2-devel ;
> > > edk2-
> > > >de...@lists.01.org
> > > >> Cc: Kinney, Michael D
> ;
> > > Yao, Jiewen
> > > >> ; Andrew Fish
> ;
> > > Gao, Liming
> > > >> 
> > > >> Subject: Re: [edk2] [PATCH]
> MdePkg/BaseStackCheckLib:
> > > add MSFT
> > > >toolchain
> > > >> support
> > > >>
> > > >> REF:
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=1239
> > > >>
> > > >> Regards,
> > > >> Jian
> > > >>
> > > >>
> > > >> > -Original Message-
> > > >> > From: edk2-devel [mailto:edk2-devel-
> > > boun...@lists.01.org]
> > > >> > Sent: Tuesday, October 16, 2018 8:55 AM
> > > >> > To: edk2-devel@lists.01.org
> > > >> > Cc: Kinney, Michael D
> ;
> > > Yao, Jiewen
> > > >> > ; Andrew Fish
> > > ; Gao, Liming
> > > >> > 
> > > >> > Subject: [edk2] [PATCH]
> MdePkg/BaseStackCheckLib:
> > >

Re: [edk2] Community Discussion: General Code and Commit message standards

[Kinney, Michael D]

I would also hope that most (if not all) patches do have
an associated BZ.  For either a feature request or a bug
fix.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> On Behalf Of stephano
> Sent: Thursday, October 18, 2018 10:21 AM
> To: Andrew Fish 
> Cc: Carsey, Jaben ; edk2-
> de...@lists.01.org
> Subject: Re: [edk2] Community Discussion: General Code
> and Commit message standards
> 
> On 10/18/2018 6:11 PM, Andrew Fish wrote:> What I've done
> in the past on
> a branch based github PR flow is have a naming convention
> for the
> branch. For example eng/PR--.
> Then we have a
> git hook that looks at the branch name and if it sees a
> Bugzilla number
> it inserts the Bugzilla reference in the bottom of every
> commit message
> for that branch. The CI also played tricks with the
> branch names and
> could update the bug tracker with CI results, and the
> process status of
> the bug.
> Interesting. This will make a good point for coming
> discussions. I'll
> make a note of it.
> 
> I would hope that most modern workflows have a way to
> accomplish this in
> some automated way. Seems like a pretty standard ask.
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdePkg/BaseStackCheckLib: add MSFT toolchain support

[Kinney, Michael D]

Jian,

Please add the list of VSxxx tool chain tags you
tested with in the commit message.

Mike

> -Original Message-
> From: Wang, Jian J
> Sent: Wednesday, October 17, 2018 11:36 PM
> To: Kinney, Michael D ; Gao,
> Liming ; edk2-devel  boun...@lists.01.org>; edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Andrew Fish
> 
> Subject: RE: [edk2] [PATCH] MdePkg/BaseStackCheckLib: add
> MSFT toolchain support
> 
> Mike,
> 
> I tested the lib with all supported MSFT toolchains. No
> difference found so far.
> 
> Regards,
> Jian
> 
> 
> > -Original Message-
> > From: Kinney, Michael D
> > Sent: Thursday, October 18, 2018 9:36 AM
> > To: Gao, Liming ; Wang, Jian J
> ;
> > edk2-devel ; edk2-
> de...@lists.01.org;
> > Kinney, Michael D 
> > Cc: Yao, Jiewen ; Andrew Fish
> 
> > Subject: RE: [edk2] [PATCH] MdePkg/BaseStackCheckLib:
> add MSFT toolchain
> > support
> >
> > Jian,
> >
> > Is there a link to the documentation for these new
> > functions?  We should put the link in the file
> > headers.
> >
> > The link to docs should also be added to the BZ.
> >
> > Also, which VS compilers was this tested with?  Are
> > different implementations required for different VS
> > compilers?
> >
> > Mike
> >
> > > -Original Message-
> > > From: Gao, Liming
> > > Sent: Wednesday, October 17, 2018 6:22 PM
> > > To: Wang, Jian J ; edk2-devel
> > > ; edk2-
> > > de...@lists.01.org
> > > Cc: Kinney, Michael D ;
> Yao,
> > > Jiewen ; Andrew Fish
> > > 
> > > Subject: RE: [edk2] [PATCH] MdePkg/BaseStackCheckLib:
> add
> > > MSFT toolchain support
> > >
> > > Jian:
> > >   The patch is good to me. Reviewed-by: Liming Gao
> > > 
> > >
> > > Thanks
> > > Liming
> > > >-Original Message-
> > > >From: Wang, Jian J
> > > >Sent: Thursday, October 18, 2018 9:19 AM
> > > >To: edk2-devel ;
> edk2-
> > > de...@lists.01.org
> > > >Cc: Kinney, Michael D ;
> Yao,
> > > Jiewen
> > > >; Andrew Fish
> ;
> > > Gao, Liming
> > > >
> > > >Subject: RE: [edk2] [PATCH]
> MdePkg/BaseStackCheckLib:
> > > add MSFT toolchain
> > > >support
> > > >
> > > >Ping ... :)
> > > >
> > > >Regards,
> > > >Jian
> > > >
> > > >
> > > >> -Original Message-
> > > >> From: edk2-devel [mailto:edk2-devel-
> > > boun...@lists.01.org]
> > > >> Sent: Tuesday, October 16, 2018 8:59 AM
> > > >> To: edk2-devel ;
> > > edk2-
> > > >de...@lists.01.org
> > > >> Cc: Kinney, Michael D
> ;
> > > Yao, Jiewen
> > > >> ; Andrew Fish
> ;
> > > Gao, Liming
> > > >> 
> > > >> Subject: Re: [edk2] [PATCH]
> MdePkg/BaseStackCheckLib:
> > > add MSFT
> > > >toolchain
> > > >> support
> > > >>
> > > >> REF:
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=1239
> > > >>
> > > >> Regards,
> > > >> Jian
> > > >>
> > > >>
> > > >> > -Original Message-
> > > >> > From: edk2-devel [mailto:edk2-devel-
> > > boun...@lists.01.org]
> > > >> > Sent: Tuesday, October 16, 2018 8:55 AM
> > > >> > To: edk2-devel@lists.01.org
> > > >> > Cc: Kinney, Michael D
> ;
> > > Yao, Jiewen
> > > >> > ; Andrew Fish
> > > ; Gao, Liming
> > > >> > 
> > > >> > Subject: [edk2] [PATCH]
> MdePkg/BaseStackCheckLib:
> > > add MSFT toolchain
> > > >> > support
> > > >> >
> > > >> > This patch adds stack check support for MSFT
> > > toolchain, with
> > > >> > compiler option /GS and /RTCs. This
> functionality is
> > > similar
> > > >> > to the original ones supported by GCC toolchain.
> > > >> >
> > > >> > Usage example:
> > > >> > This is a NULL library instance. Add it under a
> > > [LibraryClasses]
> > > >> > section in dsc file to let it be built into all
> > > modules employed
> > > >> > in a platform.
> > > >> >
> > > >

Re: [edk2] [PATCH] MdePkg/BaseStackCheckLib: add MSFT toolchain support

[Kinney, Michael D]

Jian,

Is there a link to the documentation for these new
functions?  We should put the link in the file
headers.

The link to docs should also be added to the BZ.

Also, which VS compilers was this tested with?  Are
different implementations required for different VS
compilers?

Mike

> -Original Message-
> From: Gao, Liming
> Sent: Wednesday, October 17, 2018 6:22 PM
> To: Wang, Jian J ; edk2-devel
> ; edk2-
> de...@lists.01.org
> Cc: Kinney, Michael D ; Yao,
> Jiewen ; Andrew Fish
> 
> Subject: RE: [edk2] [PATCH] MdePkg/BaseStackCheckLib: add
> MSFT toolchain support
> 
> Jian:
>   The patch is good to me. Reviewed-by: Liming Gao
> 
> 
> Thanks
> Liming
> >-Original Message-
> >From: Wang, Jian J
> >Sent: Thursday, October 18, 2018 9:19 AM
> >To: edk2-devel ; edk2-
> de...@lists.01.org
> >Cc: Kinney, Michael D ; Yao,
> Jiewen
> >; Andrew Fish ;
> Gao, Liming
> >
> >Subject: RE: [edk2] [PATCH] MdePkg/BaseStackCheckLib:
> add MSFT toolchain
> >support
> >
> >Ping ... :)
> >
> >Regards,
> >Jian
> >
> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org]
> >> Sent: Tuesday, October 16, 2018 8:59 AM
> >> To: edk2-devel ;
> edk2-
> >de...@lists.01.org
> >> Cc: Kinney, Michael D ;
> Yao, Jiewen
> >> ; Andrew Fish ;
> Gao, Liming
> >> 
> >> Subject: Re: [edk2] [PATCH] MdePkg/BaseStackCheckLib:
> add MSFT
> >toolchain
> >> support
> >>
> >> REF:
> https://bugzilla.tianocore.org/show_bug.cgi?id=1239
> >>
> >> Regards,
> >> Jian
> >>
> >>
> >> > -Original Message-
> >> > From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org]
> >> > Sent: Tuesday, October 16, 2018 8:55 AM
> >> > To: edk2-devel@lists.01.org
> >> > Cc: Kinney, Michael D ;
> Yao, Jiewen
> >> > ; Andrew Fish
> ; Gao, Liming
> >> > 
> >> > Subject: [edk2] [PATCH] MdePkg/BaseStackCheckLib:
> add MSFT toolchain
> >> > support
> >> >
> >> > This patch adds stack check support for MSFT
> toolchain, with
> >> > compiler option /GS and /RTCs. This functionality is
> similar
> >> > to the original ones supported by GCC toolchain.
> >> >
> >> > Usage example:
> >> > This is a NULL library instance. Add it under a
> [LibraryClasses]
> >> > section in dsc file to let it be built into all
> modules employed
> >> > in a platform.
> >> >
> >> > [LibraryClasses]
> >> >
> NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.i
> nf
> >> >
> >> > Please note all not modules can be built against
> this library. Most
> >> > of them are SEC type of modules, such as
> >> >
> >> > OvmfPkg/ResetVector/ResetVector.inf
> >> >
> >> > In this case, this library should not be added to a
> common
> >> > [LibraryClasses] section but to specific ones, like
> >> > [LibraryClasses.common.PEI_CORE/PEIM/...].
> >> >
> >> > In addition, /GS and/or /RTCs should be added to
> compiler command line.
> >> > This can be done by adding something like below
> under [BuildOptions]
> >> > section in dsc file.
> >> >
> >> > [BuildOptions]
> >> >   MSFT:DEBUG_*_*_CC_FLAGS = /GS /GL-
> >> >   MSFT:DEBUG_*_*_CC_FLAGS = /RTCs /Od
> >> >
> >> > Note: /GL- is required for /GS, and /Od is required
> for /RTCs.
> >> > Note: The flash layout might be needed to update to
> accommodate larger
> >> >   image size due to /Od is enforced.
> >> >
> >> > Pass tests:
> >> > a. Overwrite a local buffer variable (in a 32-bit
> and 64-bit driver)and
> >> >check if it's caught by new code (on both real
> platform and virtual
> >> >platform)
> >> > b. Boot Windows 10 and Ubuntu 18.04 on real platform
> with this
> >> >lib built-in
> >> >
> >> > Cc: Michael D Kinney 
> >> > Cc: Liming Gao 
> >> > Cc: Jiewen Yao 
> >> > Cc: Andrew Fish 
> >> > Contributed-under: TianoCore Contribution Agreement
> 1.1
> >> > Signed-off-by: Jian J Wang 
> >> > ---
> >> >  .../BaseStackCheckLib/BaseStackCheckLib.inf
> |  11 +-
> >> >  ...

Re: [edk2] OpenProtocolInformation

[Kinney, Michael D]

The same protocol can be installed on many handles in
the handle database.  For example, if there are multiple
mass storage devices in a platform, there will be
multiple Block I/O Protocols in the handle database.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of TVKR
> Sent: Tuesday, October 23, 2018 4:06 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] OpenProtocolInformation
> 
> Hi,
> 
> If the main purpose of the OpenProtocolInformation
> service is to provide
> the complete list of agents currently using a specific
> protocol interface
> then what is the need for providing the Handle argument
> too as an input?
> Why does it matter what Handle was this queried protocol
> installed on?
> 
> Thanks
> ___
> 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] ** NOTICE ** edk2-devel mailing list configuration changes

[Kinney, Michael D]

Leif,

Very strange.  When I do the same on that email, it
shows Paul on the To address line.  

Mike

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Monday, October 29, 2018 1:40 PM
> To: Kinney, Michael D 
> Cc: EDK II Development ;
> Cetola, Stephano 
> Subject: Re: [edk2] ** NOTICE ** edk2-devel mailing list
> configuration changes
> 
> Hi Mike,
> 
> When I try to "reply-to", the email from Paul A Lohr,
> sent 10 minutes
> after your one below, he does not show up in either "to"
> or "cc".
> 
> OK, I missed the excitement during the plugfest. I'll go
> back and see
> what I can find there.
> 
> Regards,
> 
> Leif
> 
> On Mon, Oct 29, 2018 at 08:23:43PM +, Kinney,
> Michael D wrote:
> > Leif,
> >
> > I have enabled a different configuration setting
> > that should be better.
> >
> > Please try some emails and let me know if there
> > are any impacts.
> >
> > The reason for these changes is the DMARC related
> > issue that occurred on 10-19-2018 that required a
> > number of users to be disabled.  The goal of these
> > changes is to enable those users to be re-activated.
> >
> > Thanks,
> >
> > Mike
> >
> > > -Original Message-
> > > From: Leif Lindholm
> [mailto:leif.lindh...@linaro.org]
> > > Sent: Monday, October 29, 2018 12:54 PM
> > > To: EDK II Development 
> > > Cc: Kinney, Michael D ;
> > > Cetola, Stephano 
> > > Subject: Re: [edk2] ** NOTICE ** edk2-devel mailing
> list
> > > configuration changes
> > >
> > > Hi Mike,
> > >
> > > On Mon, Oct 29, 2018 at 06:42:44PM +, Kinney,
> > > Michael D wrote:
> > > > Some configuration changes have been made to
> > > > the edk2-devel mailing list to handle posts from
> > > > a domain with a DMARC Reject/Quarantine policy
> > > > enabled. If this is detected then the from address
> > > > is now munged.
> > > >
> > > > One side effect of this setting is that the
> > > > behavior of Reply has changed.  Instead of being
> > > > a reply to the poster of the message, the Reply
> > > > address is the edk2-devel mailing list.
> > >
> > > The behaviour looks somewhat broken, since as far as
> I
> > > can tell,
> > > replies now longer include the person you're
> replying
> > > to.
> > > (This doesn't happen when replying specifically to
> > > _you_, because you
> > > cc yourself on everything).
> > >
> > > > If you wish to send a private reply to only the
> > > > poster of the message, you may have to perform
> > > > some manual steps.
> > > >
> > > > Please let me know if you have any concerns about
> > > > these changes or if these configuration changes
> > > > cause any other side effects.
> > >
> > > Can we make sure the person being replied to is at
> least
> > > on cc?
> > > Otherwise, we've just broken the workflow for anyone
> > > filtering on
> > > whether they are on "to" or "cc".
> > >
> > > Why was this change necessary?
> > >
> > > Regards,
> > >
> > > Leif
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Test message. Please ignore.

[Kinney, Michael D]

Hi Chris,

I am trying a different configuration setting to see
if the posters reply-to address can be preserved.

Please try both a Reply and a Reply-All to
this test message.

Thanks,

Mike

> -Original Message-
> From: Kinney, Michael D
> Sent: Monday, October 29, 2018 11:32 AM
> To: EDK II Development ;
> Gretzinger, Adam R ;
> Jeremiah Cox ; Kinney, Michael D
> 
> Cc: Chris Co ; Chad Mace
> ; Sean Brogan
> ; Cetola, Stephano
> 
> Subject: RE: Test message. Please ignore.
> 
> Chris,
> 
> Thanks.  That looks like what I expected.
> 
> Mike
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-
> > boun...@lists.01.org] On Behalf Of Chris Co via edk2-
> > devel
> > Sent: Monday, October 29, 2018 11:22 AM
> > To: Kinney, Michael D ;
> > Gretzinger, Adam R ;
> edk2-
> > de...@lists.01.org; Jeremiah Cox
> 
> > Cc: Chris Co ; Chad Mace
> > ; Sean Brogan
> > ; Cetola, Stephano
> > 
> > Subject: Re: [edk2] Test message. Please ignore.
> >
> > Hi Mike,
> >
> > Here is a Reply All to the test message.
> >
> > Chris
> >
> > > -----Original Message-
> > > From: Kinney, Michael D 
> > > Sent: Monday, October 29, 2018 10:31 AM
> > > To: Chris Co ;
> > Gretzinger, Adam R
> > > ; edk2-
> > de...@lists.01.org; Kinney, Michael D
> > > ; Jeremiah Cox
> > 
> > > Cc: Sean Brogan ; Cetola,
> > Stephano
> > > ; Chad Mace
> > 
> > > Subject: RE: Test message. Please ignore.
> > >
> > > Hi Chris,
> > >
> > > This is a response to this test message.  The Reply-
> To
> > setting has been
> > > updated to make sure edk2-devel is always present.
> > >
> > > Please do a Reply All to this test message.
> > >
> > > Thanks,
> > >
> > > Mike
> > >
> > > From: Chris Co [mailto:christopher...@microsoft.com]
> > > Sent: Friday, October 26, 2018 6:09 PM
> > > To: Kinney, Michael D ;
> > Gretzinger, Adam R
> > > ; edk2-
> de...@lists.01.org
> > > Cc: Sean Brogan ;
> Jeremiah
> > Cox
> > > ; Cetola, Stephano
> > ;
> > > Chad Mace 
> > > Subject: Test message. Please ignore.
> > >
> > > Test message. Checking for DMARC bounces...
> > >
> > > Chris
> > ___
> > 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] ** NOTICE ** edk2-devel mailing list configuration changes

[Kinney, Michael D]

Leif,

I have enabled a different configuration setting 
that should be better.

Please try some emails and let me know if there
are any impacts.

The reason for these changes is the DMARC related
issue that occurred on 10-19-2018 that required a
number of users to be disabled.  The goal of these
changes is to enable those users to be re-activated.

Thanks,

Mike

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Monday, October 29, 2018 12:54 PM
> To: EDK II Development 
> Cc: Kinney, Michael D ;
> Cetola, Stephano 
> Subject: Re: [edk2] ** NOTICE ** edk2-devel mailing list
> configuration changes
> 
> Hi Mike,
> 
> On Mon, Oct 29, 2018 at 06:42:44PM +, Kinney,
> Michael D wrote:
> > Some configuration changes have been made to
> > the edk2-devel mailing list to handle posts from
> > a domain with a DMARC Reject/Quarantine policy
> > enabled. If this is detected then the from address
> > is now munged.
> >
> > One side effect of this setting is that the
> > behavior of Reply has changed.  Instead of being
> > a reply to the poster of the message, the Reply
> > address is the edk2-devel mailing list.
> 
> The behaviour looks somewhat broken, since as far as I
> can tell,
> replies now longer include the person you're replying
> to.
> (This doesn't happen when replying specifically to
> _you_, because you
> cc yourself on everything).
> 
> > If you wish to send a private reply to only the
> > poster of the message, you may have to perform
> > some manual steps.
> >
> > Please let me know if you have any concerns about
> > these changes or if these configuration changes
> > cause any other side effects.
> 
> Can we make sure the person being replied to is at least
> on cc?
> Otherwise, we've just broken the workflow for anyone
> filtering on
> whether they are on "to" or "cc".
> 
> Why was this change necessary?
> 
> Regards,
> 
> Leif
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Another Test Message - please ignore

[Kinney, Michael D]

Start new test message thread.

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

Re: [edk2] ** NOTICE ** edk2-devel mailing list configuration changes

[Kinney, Michael D]

Hi Leif,

I can put the reply_goes_to_list option back to "Poster".

In that configuration, a user that has a DMARC policy of
reject will still have their from address munged.

But I noticed that the edk2-devel mailing list is not
present when anyone does a Reply-all to an email with
a munged from address.  That implied to me that everyone
would need to check if the edk2-devel mailing has been
removed from a Reply-all and add it back manually.  This
also seems like a non-ideal configuration option.

However, the behavior I am seeing could be due to some
of my client settings.

So I will put the reply_goes_to_list option back to
"Poster".

Mike

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Monday, October 29, 2018 2:10 PM
> To: Kinney, Michael D 
> Cc: EDK II Development ;
> Cetola, Stephano 
> Subject: Re: [edk2] ** NOTICE ** edk2-devel mailing list
> configuration changes
> 
> Hi Mike,
> 
> I could hypothesise about which email client you may be
> using :)
> 
> But let me instead mention that the two email clients I
> have (mutt and
> gmail web interface) behave identically - neither adds
> the original
> sender to cc when the list server forces a reply-to
> header.
> 
> Regards,
> 
> Leif
> 
> On Mon, Oct 29, 2018 at 08:49:09PM +, Kinney,
> Michael D wrote:
> > Leif,
> >
> > Very strange.  When I do the same on that email, it
> > shows Paul on the To address line.
> >
> > Mike
> >
> > > -Original Message-
> > > From: Leif Lindholm
> [mailto:leif.lindh...@linaro.org]
> > > Sent: Monday, October 29, 2018 1:40 PM
> > > To: Kinney, Michael D 
> > > Cc: EDK II Development ;
> > > Cetola, Stephano 
> > > Subject: Re: [edk2] ** NOTICE ** edk2-devel mailing
> list
> > > configuration changes
> > >
> > > Hi Mike,
> > >
> > > When I try to "reply-to", the email from Paul A
> Lohr,
> > > sent 10 minutes
> > > after your one below, he does not show up in either
> "to"
> > > or "cc".
> > >
> > > OK, I missed the excitement during the plugfest.
> I'll go
> > > back and see
> > > what I can find there.
> > >
> > > Regards,
> > >
> > > Leif
> > >
> > > On Mon, Oct 29, 2018 at 08:23:43PM +, Kinney,
> > > Michael D wrote:
> > > > Leif,
> > > >
> > > > I have enabled a different configuration setting
> > > > that should be better.
> > > >
> > > > Please try some emails and let me know if there
> > > > are any impacts.
> > > >
> > > > The reason for these changes is the DMARC related
> > > > issue that occurred on 10-19-2018 that required a
> > > > number of users to be disabled.  The goal of these
> > > > changes is to enable those users to be re-
> activated.
> > > >
> > > > Thanks,
> > > >
> > > > Mike
> > > >
> > > > > -Original Message-
> > > > > From: Leif Lindholm
> > > [mailto:leif.lindh...@linaro.org]
> > > > > Sent: Monday, October 29, 2018 12:54 PM
> > > > > To: EDK II Development 
> > > > > Cc: Kinney, Michael D
> ;
> > > > > Cetola, Stephano 
> > > > > Subject: Re: [edk2] ** NOTICE ** edk2-devel
> mailing
> > > list
> > > > > configuration changes
> > > > >
> > > > > Hi Mike,
> > > > >
> > > > > On Mon, Oct 29, 2018 at 06:42:44PM +,
> Kinney,
> > > > > Michael D wrote:
> > > > > > Some configuration changes have been made to
> > > > > > the edk2-devel mailing list to handle posts
> from
> > > > > > a domain with a DMARC Reject/Quarantine policy
> > > > > > enabled. If this is detected then the from
> address
> > > > > > is now munged.
> > > > > >
> > > > > > One side effect of this setting is that the
> > > > > > behavior of Reply has changed.  Instead of
> being
> > > > > > a reply to the poster of the message, the
> Reply
> > > > > > address is the edk2-devel mailing list.
> > > > >
> > > > > The behaviour looks somewhat broken, since as
> far as
> > > I
> > > > > can tell,
> > > > > replies now longer include the person you're
> > > replying
> > > > > to.
> > > > > (This doesn't happen when replying specifically
> to
> > > > > _you_, because you
> > > > > cc yourself on everything).
> > > > >
> > > > > > If you wish to send a private reply to only
> the
> > > > > > poster of the message, you may have to perform
> > > > > > some manual steps.
> > > > > >
> > > > > > Please let me know if you have any concerns
> about
> > > > > > these changes or if these configuration
> changes
> > > > > > cause any other side effects.
> > > > >
> > > > > Can we make sure the person being replied to is
> at
> > > least
> > > > > on cc?
> > > > > Otherwise, we've just broken the workflow for
> anyone
> > > > > filtering on
> > > > > whether they are on "to" or "cc".
> > > > >
> > > > > Why was this change necessary?
> > > > >
> > > > > Regards,
> > > > >
> > > > > Leif
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Test message. Please ignore.

[Kinney, Michael D]

Another test with reply_goes_to_list set to "Poster".

Mike

> -Original Message-
> From: Chris Co [mailto:christopher...@microsoft.com]
> Sent: Monday, October 29, 2018 1:12 PM
> To: Kinney, Michael D ; EDK
> II Development ; Gretzinger,
> Adam R ; Jeremiah Cox
> 
> Cc: Chad Mace ; Sean Brogan
> ; Cetola, Stephano
> 
> Subject: RE: Test message. Please ignore.
> 
> Hi Mike,
> 
> This is a Reply-All.
> 
> Chris
> 
> > -Original Message-
> > From: Kinney, Michael D 
> > Sent: Monday, October 29, 2018 1:11 PM
> > To: EDK II Development ;
> Gretzinger, Adam R
> > ; Jeremiah Cox
> ;
> > Kinney, Michael D 
> > Cc: Chris Co ; Chad Mace
> > ; Sean Brogan
> ;
> > Cetola, Stephano 
> > Subject: RE: Test message. Please ignore.
> >
> > Hi Chris,
> >
> > I am trying a different configuration setting to see
> if the posters reply-to
> > address can be preserved.
> >
> > Please try both a Reply and a Reply-All to this test
> message.
> >
> > Thanks,
> >
> > Mike
> >
> > > -Original Message-
> > > From: Kinney, Michael D
> > > Sent: Monday, October 29, 2018 11:32 AM
> > > To: EDK II Development ;
> Gretzinger, Adam R
> > > ; Jeremiah Cox
> ;
> > > Kinney, Michael D 
> > > Cc: Chris Co ; Chad
> Mace
> > > ; Sean Brogan
> ;
> > > Cetola, Stephano 
> > > Subject: RE: Test message. Please ignore.
> > >
> > > Chris,
> > >
> > > Thanks.  That looks like what I expected.
> > >
> > > Mike
> > >
> > > > -Original Message-
> > > > From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf
> > > > Of Chris Co via edk2- devel
> > > > Sent: Monday, October 29, 2018 11:22 AM
> > > > To: Kinney, Michael D
> ; Gretzinger, Adam
> > > > R ;
> > > edk2-
> > > > de...@lists.01.org; Jeremiah Cox
> > > 
> > > > Cc: Chris Co ; Chad
> Mace
> > > > ; Sean Brogan
> ;
> > > > Cetola, Stephano 
> > > > Subject: Re: [edk2] Test message. Please ignore.
> > > >
> > > > Hi Mike,
> > > >
> > > > Here is a Reply All to the test message.
> > > >
> > > > Chris
> > > >
> > > > > -Original Message-
> > > > > From: Kinney, Michael D
> 
> > > > > Sent: Monday, October 29, 2018 10:31 AM
> > > > > To: Chris Co ;
> > > > Gretzinger, Adam R
> > > > > ; edk2-
> > > > de...@lists.01.org; Kinney, Michael D
> > > > > ; Jeremiah Cox
> > > > 
> > > > > Cc: Sean Brogan ;
> Cetola,
> > > > Stephano
> > > > > ; Chad Mace
> > > > 
> > > > > Subject: RE: Test message. Please ignore.
> > > > >
> > > > > Hi Chris,
> > > > >
> > > > > This is a response to this test message.  The
> Reply-
> > > To
> > > > setting has been
> > > > > updated to make sure edk2-devel is always
> present.
> > > > >
> > > > > Please do a Reply All to this test message.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Mike
> > > > >
> > > > > From: Chris Co
> [mailto:christopher...@microsoft.com]
> > > > > Sent: Friday, October 26, 2018 6:09 PM
> > > > > To: Kinney, Michael D
> ;
> > > > Gretzinger, Adam R
> > > > > ; edk2-
> > > de...@lists.01.org
> > > > > Cc: Sean Brogan ;
> > > Jeremiah
> > > > Cox
> > > > > ; Cetola, Stephano
> > > > ;
> > > > > Chad Mace 
> > > > > Subject: Test message. Please ignore.
> > > > >
> > > > > Test message. Checking for DMARC bounces...
> > > > >
> > > > > Chris
> > > > ___
> > > > edk2-devel mailing list
> > > > edk2-devel@lists.01.org
> > > >
> https://na01.safelinks.protection.outlook.com/?url=https
> %3A%2F%2Flis
> > > > ts.01.org%2Fmailman%2Flistinfo%2Fedk2-
> > develdata=02%7C01%7CChris
> > > >
> >
> topher.Co%40microsoft.com%7C868cbd744373450b6b3b08d63dda
> 97d8%7C72
> > f98
> > > >
> >
> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C636764406403589714
> sda
> > ta=G
> > > >
> AoQ6V1QtnZJ1DDVKRFy2kvjtPJfWyEM6Pd4KGgzzf4%3Dreserv
> ed=0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Another Test Message - please ignore

[Kinney, Michael D]

Chris,

Thanks!  That is working as expected now.

Mike

> -Original Message-
> From: Chris Co [mailto:christopher...@microsoft.com]
> Sent: Monday, October 29, 2018 3:50 PM
> To: Kinney, Michael D ;
> edk2-devel@lists.01.org
> Subject: RE: Another Test Message - please ignore
> 
> Testing Reply-All
> 
> Chris
> 
> > -Original Message-
> > From: edk2-devel  On
> Behalf Of Kinney,
> > Michael D
> > Sent: Monday, October 29, 2018 3:44 PM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] Another Test Message - please ignore
> >
> > Start new test message thread.
> >
> > Mike
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> >
> https://na01.safelinks.protection.outlook.com/?url=https
> %3A%2F%2Flists.01.o
> > rg%2Fmailman%2Flistinfo%2Fedk2-
> >
> develdata=02%7C01%7Cchristopher.co%40microsoft.com%
> 7C3b7c858a6
> >
> e34427ebfd308d63df007f3%7C72f988bf86f141af91ab2d7cd011db
> 47%7C1%7C0
> >
> %7C636764498470253846sdata=D96MYFbrcqLcaZr72ukFJ6XY
> enR4z50rD
> > hGNopmHgNc%3Dreserved=0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1 0/7] Delete TCP, PXE, iSCSI driver in MdeModulePkg.

[Kinney, Michael D]

Fu Siyuan,

Just edk2-platforms/master.

Maintainers for devel and stable branches need to device
when to move to a new version of edk2 repo and perform
integration tasks. 

The patch for edk2-platforms/master should include this
notification so maintainer of devel and stable branches
will know that the need to pay attention to this change.

Mike

> -Original Message-
> From: Fu, Siyuan
> Sent: Tuesday, October 30, 2018 5:52 PM
> To: Kinney, Michael D ;
> Zeng, Star ; edk2-
> de...@lists.01.org
> Cc: Leif Lindholm ; Andrew
> Fish (af...@apple.com) ; Laszlo Ersek
> (ler...@redhat.com) ; Gao, Liming
> 
> Subject: RE: [edk2] [PATCH v1 0/7] Delete TCP, PXE,
> iSCSI driver in MdeModulePkg.
> 
> Mike,
> 
> Should I also update the devel branches in edk2-
> platform? Or the branch owner will take care of it?
> 
> BestRegards
> Fu Siyuan
> 
> 
> > -Original Message-
> > From: Kinney, Michael D
> > Sent: Wednesday, October 31, 2018 5:15 AM
> > To: Fu, Siyuan ; Zeng, Star
> ;
> > edk2-devel@lists.01.org; Kinney, Michael D
> 
> > Cc: Leif Lindholm ; Andrew
> Fish (af...@apple.com)
> > ; Laszlo Ersek (ler...@redhat.com)
> ;
> > Gao, Liming 
> > Subject: RE: [edk2] [PATCH v1 0/7] Delete TCP, PXE,
> iSCSI driver in
> > MdeModulePkg.
> >
> > Fu Siyuan,
> >
> > Please review edk2-platform/master and prepare a patch
> > for that branch if there are DSC/FDF files that refer
> > to the network drivers that are being removed.
> >
> > We should never break any platforms in edk2-
> platform/master.
> > The commits should be performed to the repos in the
> correct
> > order to guarantee no build breaks.
> >
> > Thanks,
> >
> > Mike
> >
> > > -Original Message-
> > > From: Fu, Siyuan
> > > Sent: Tuesday, October 30, 2018 1:23 AM
> > > To: Zeng, Star ; edk2-
> > > de...@lists.01.org
> > > Cc: Kinney, Michael D ;
> Leif
> > > Lindholm ; Andrew Fish
> > > (af...@apple.com) ; Laszlo Ersek
> > > (ler...@redhat.com) ; Gao, Liming
> > > 
> > > Subject: RE: [edk2] [PATCH v1 0/7] Delete TCP, PXE,
> > > iSCSI driver in MdeModulePkg.
> > >
> > > Hi, Star
> > >
> > > This patch only covers the platforms in
> > > https://github.com/tianocore/edk2
> > >
> > > I will modify the edk2 network wiki page for an
> updated
> > > sample DSC/FDF section, if this patch could pass
> review
> > > w/o objection.
> > >
> https://github.com/tianocore/tianocore.github.io/wiki/Ne
> > > tworkPkg-Getting-Started-Guide
> > >
> > > Let's wait a few days to see if there is any
> objection
> > > on deleting these driver first, and I will be happy
> to
> > > generate another patch for edk2-platforms then.
> > >
> > > Thanks for your reminder.
> > >
> > >
> > > BestRegards
> > > Fu Siyuan
> > >
> > > > -Original Message-
> > > > From: Zeng, Star
> > > > Sent: Tuesday, October 30, 2018 3:43 PM
> > > > To: Fu, Siyuan ; edk2-
> > > de...@lists.01.org
> > > > Cc: Kinney, Michael D
> ;
> > > Leif Lindholm
> > > > ; Andrew Fish
> > > (af...@apple.com)
> > > > ; Laszlo Ersek
> (ler...@redhat.com)
> > > ;
> > > > Gao, Liming ; Zeng, Star
> > > 
> > > > Subject: RE: [edk2] [PATCH v1 0/7] Delete TCP,
> PXE,
> > > iSCSI driver in
> > > > MdeModulePkg.
> > > >
> > > > Hi Siyuan,
> > > >
> > > > Have you checked the platforms in
> > > https://github.com/tianocore/edk2-
> > > > platforms to see whether they need to be updated
> > > accordingly or not?
> > > >
> > > > Cc more people.
> > > >
> > > > Thanks,
> > > > Star
> > > > -Original Message-
> > > > From: edk2-devel [mailto:edk2-devel-
> > > boun...@lists.01.org] On Behalf Of Fu
> > > > Siyuan
> > > > Sent: Tuesday, October 30, 2018 3:33 PM
> > > > To: edk2-devel@lists.01.org
> > > > Subject: [edk2] [PATCH v1 0/7] Delete TCP, PXE,
> iSCSI
> > > driver in
> > > > MdeModulePkg.
> > > >
> > > > This patch series is to delete the Tcp4Dxe,
> > > UefiPxeBcDxe and IScsi4Dxe
> > > > drivers in MdeModulePkg. These drivers will not be
> > > maintained and can't
>

Re: [edk2] [PATCH v1 0/7] Delete TCP, PXE, iSCSI driver in MdeModulePkg.

[Kinney, Michael D]

Fu Siyuan,

Please review edk2-platform/master and prepare a patch
for that branch if there are DSC/FDF files that refer
to the network drivers that are being removed. 

We should never break any platforms in edk2-platform/master.
The commits should be performed to the repos in the correct
order to guarantee no build breaks.

Thanks,

Mike

> -Original Message-
> From: Fu, Siyuan
> Sent: Tuesday, October 30, 2018 1:23 AM
> To: Zeng, Star ; edk2-
> de...@lists.01.org
> Cc: Kinney, Michael D ; Leif
> Lindholm ; Andrew Fish
> (af...@apple.com) ; Laszlo Ersek
> (ler...@redhat.com) ; Gao, Liming
> 
> Subject: RE: [edk2] [PATCH v1 0/7] Delete TCP, PXE,
> iSCSI driver in MdeModulePkg.
> 
> Hi, Star
> 
> This patch only covers the platforms in
> https://github.com/tianocore/edk2
> 
> I will modify the edk2 network wiki page for an updated
> sample DSC/FDF section, if this patch could pass review
> w/o objection.
> https://github.com/tianocore/tianocore.github.io/wiki/Ne
> tworkPkg-Getting-Started-Guide
> 
> Let's wait a few days to see if there is any objection
> on deleting these driver first, and I will be happy to
> generate another patch for edk2-platforms then.
> 
> Thanks for your reminder.
> 
> 
> BestRegards
> Fu Siyuan
> 
> > -Original Message-
> > From: Zeng, Star
> > Sent: Tuesday, October 30, 2018 3:43 PM
> > To: Fu, Siyuan ; edk2-
> de...@lists.01.org
> > Cc: Kinney, Michael D ;
> Leif Lindholm
> > ; Andrew Fish
> (af...@apple.com)
> > ; Laszlo Ersek (ler...@redhat.com)
> ;
> > Gao, Liming ; Zeng, Star
> 
> > Subject: RE: [edk2] [PATCH v1 0/7] Delete TCP, PXE,
> iSCSI driver in
> > MdeModulePkg.
> >
> > Hi Siyuan,
> >
> > Have you checked the platforms in
> https://github.com/tianocore/edk2-
> > platforms to see whether they need to be updated
> accordingly or not?
> >
> > Cc more people.
> >
> > Thanks,
> > Star
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Fu
> > Siyuan
> > Sent: Tuesday, October 30, 2018 3:33 PM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] [PATCH v1 0/7] Delete TCP, PXE, iSCSI
> driver in
> > MdeModulePkg.
> >
> > This patch series is to delete the Tcp4Dxe,
> UefiPxeBcDxe and IScsi4Dxe
> > drivers in MdeModulePkg. These drivers will not be
> maintained and can't
> > co-work with the dual-stack drivers in NetworkPkg.
> >
> > People should use below NetworkPkg drivers instead:
> >   NetworkPkg/IScsiDxe/IScsiDxe.inf
> >   NetworkPkg/TcpDxe/TcpDxe.inf
> >   NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
> > These drivers are actively maintained with more bug
> fixes and new feature
> > support.
> >
> > Patch 1~5 update edk2 platform DSC/FDF files to use
> NetworkPkg drivers.
> > Patch 6 deletes the TCP,PXE,iSCSI driver in
> MdeModulePkg.
> > Patch 7 removes some clarification in NetworkPkg
> drivers since the related
> > driver has been deleted in Patch 6.
> >
> > Fu Siyuan (7):
> >   Nt32Pkg: Replace obsoleted network drivers from NT32
> platform DSC/FDF.
> >   EmulatorPkg: Replace obsoleted network drivers from
> platform DSC/FDF.
> >   OvmfPkg: Replace obsoleted network drivers from
> platform DSC/FDF.
> >   Vlv2TbltDevicePkg: Replace obsoleted drivers from
> platform DSC/FDF.
> >   ArmVirtPkg: Replace obsoleted network drivers from
> platform DSC/FDF.
> >   MdeModulePkg: Delete the TCP/PXE/ISCSI drivers in
> MdeModulePkg.
> >   NetworkPkg: Remove some clarification from
> TCP/PXE/ISCSI driver INF.
> >
> >  .../Network/IScsiDxe/ComponentName.c  |  283
> --
> >  .../Universal/Network/IScsiDxe/IScsiCHAP.c|  430
> ---
> >  .../Universal/Network/IScsiDxe/IScsiConfig.c  | 1264
> ---
> >  .../Universal/Network/IScsiDxe/IScsiDhcp.c|  472
> ---
> >  .../Universal/Network/IScsiDxe/IScsiDriver.c  |  676
> 
> >  .../Network/IScsiDxe/IScsiExtScsiPassThru.c   |  412
> ---
> >  .../Universal/Network/IScsiDxe/IScsiIbft.c|  539
> ---
> >  .../Network/IScsiDxe/IScsiInitiatorName.c |  116
> -
> >  .../Universal/Network/IScsiDxe/IScsiMisc.c|  948
> --
> >  .../Universal/Network/IScsiDxe/IScsiProto.c   | 2799
> ---
> >  .../Universal/Network/IScsiDxe/IScsiTcp4Io.c  |  487
> ---
> > MdeModulePkg/Universal/Network/IScsiDxe/Md5.c |  350 -
> -
> >   .../Universal/Network/Tcp4Dxe/ComponentName.c |  433
> ---
> >  .../Universal/Network/Tcp4Dxe/SockImpl.c  | 1201
> 

Re: [edk2] [PATCH 1/1] MdePkg/Base.h: Implement BASE_CR() via OFFSET_OF().

[Kinney, Michael D]

Marvin,

Thanks.  This is a good improvement.

Reviewed-by: Michael D Kinney 

Mike

> -Original Message-
> From: Gao, Liming
> Sent: Thursday, November 1, 2018 6:33 PM
> To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> Cc: Kinney, Michael D 
> Subject: RE: [PATCH 1/1] MdePkg/Base.h: Implement
> BASE_CR() via OFFSET_OF().
> 
> The change is good. Reviewed-by: Liming Gao
> 
> 
> >-Original Message-
> >From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of
> >Marvin H?user
> >Sent: Thursday, November 01, 2018 4:09 AM
> >To: edk2-devel@lists.01.org
> >Cc: Kinney, Michael D ;
> Gao, Liming
> >
> >Subject: [edk2] [PATCH 1/1] MdePkg/Base.h: Implement
> BASE_CR() via
> >OFFSET_OF().
> >
> >Replace the current NULL pointer dereference to
> retrieve Field's
> >offset with a call to OFFSET_OF().  This is implemented
> via
> >__builtin_offsetof for GCC and Clang, which eliminates
> UB caught by
> >Clang UndefinedBehaviorSanitizer.
> >
> >Contributed-under: TianoCore Contribution Agreement 1.1
> >Signed-off-by: Marvin Haeuser
> 
> >---
> > MdePkg/Include/Base.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/MdePkg/Include/Base.h
> b/MdePkg/Include/Base.h
> >index 523192fd79fc..bc877d8125a5 100644
> >--- a/MdePkg/Include/Base.h
> >+++ b/MdePkg/Include/Base.h
> >@@ -869,7 +869,7 @@ typedef UINTN  *BASE_LIST;
> >   @return  A pointer to the structure from one of it's
> elements.
> >
> > **/
> >-#define BASE_CR(Record, TYPE, Field)  ((TYPE *)
> ((CHAR8 *) (Record) -
> >(CHAR8 *) &(((TYPE *) 0)->Field)))
> >+#define BASE_CR(Record, TYPE, Field)  ((TYPE *)
> ((CHAR8 *) (Record) -
> >OFFSET_OF (TYPE, Field)))
> >
> > /**
> >   Rounds a value up to the next boundary using a
> specified alignment.
> >--
> >2.19.1.windows.1
> >
> >___
> >edk2-devel mailing list
> >edk2-devel@lists.01.org
> >https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/6] AppPkg: fix webserver build for !Ia32/X64

[Kinney, Michael D]

Leif,

The MSR definitions are only used by Mtrr.c, and Mtrr.c is only
used for IA32 and X64 builds in the INF file.

It would be simpler to move the #include 
into Mtrr.c.  That would avoid the use of #if.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Leif Lindholm
> Sent: Thursday, November 1, 2018 8:37 AM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Daryl
> McDaniel 
> Subject: [edk2] [PATCH 1/6] AppPkg: fix webserver build
> for !Ia32/X64
> 
> The WebServer application is really quite Ia32/X64
> specific, but fundamentally
> it builds for other architectures as long as the
> architecture-specific
>   #include 
> header file is filtered out.
> So add an architecture-based filter on that to enable
> AppPkg.dsc to build for
> AARCH64/ARM (both listed in SUPPORTED_ARCHITECTURES).
> 
> Cc: Daryl McDaniel 
> Cc: Jaben Carsey 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Leif Lindholm 
> ---
> 
> Note: there is definitely a case here for just
> disabling this component
>   for !Ia32/X64, but the _interesting_ bits of this
> application are
>   completely architecture independent, so my
> preference would be to
>   do this for now, and worry about remaining issues
> (like MTRR dump)
>   at some point in the future.
> 
>  AppPkg/Applications/Sockets/WebServer/WebServer.h | 2
> ++
>  1 file changed, 2 insertions(+)
> 
> diff --git
> a/AppPkg/Applications/Sockets/WebServer/WebServer.h
> b/AppPkg/Applications/Sockets/WebServer/WebServer.h
> index 21b07b63df..610abdcf9e 100644
> --- a/AppPkg/Applications/Sockets/WebServer/WebServer.h
> +++ b/AppPkg/Applications/Sockets/WebServer/WebServer.h
> @@ -20,7 +20,9 @@
> 
>  #include 
> 
> +#if defined(__x86_64__) || defined(__i386__)
>  #include 
> +#endif
>  #include 
>  #include 
>  #include 
> --
> 2.11.0
> 
> ___
> 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 3/6] IntelFrameworkPkg: fix build for AARCH64/ARM

[Kinney, Michael D]

Reviewed-by: Michael D Kinney 

Mike


> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Thursday, November 1, 2018 8:37 AM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ;
> Gao, Liming 
> Subject: [PATCH 3/6] IntelFrameworkPkg: fix build for
> AARCH64/ARM
> 
> Contrary to what the name suggests, some modules in
> this package are used
> on other architecture. ARM is already listed in
> SUPPORTED_ARCHITECTURES
> in the .dsc, but AARCH64 was never added - so do that.
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Leif Lindholm 
> ---
>  IntelFrameworkPkg/IntelFrameworkPkg.dsc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/IntelFrameworkPkg/IntelFrameworkPkg.dsc
> b/IntelFrameworkPkg/IntelFrameworkPkg.dsc
> index bd5df8c5d9..f957af78fb 100644
> --- a/IntelFrameworkPkg/IntelFrameworkPkg.dsc
> +++ b/IntelFrameworkPkg/IntelFrameworkPkg.dsc
> @@ -26,7 +26,7 @@ [Defines]
>PLATFORM_VERSION   = 0.96
>DSC_SPECIFICATION  = 0x00010005
>OUTPUT_DIRECTORY   =
> Build/IntelFramework
> -  SUPPORTED_ARCHITECTURES= IA32|X64|EBC|ARM
> +  SUPPORTED_ARCHITECTURES=
> IA32|X64|EBC|ARM|AARCH64
>BUILD_TARGETS  = DEBUG|RELEASE|NOOPT
>SKUID_IDENTIFIER   = DEFAULT
> 
> --
> 2.11.0

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

Re: [edk2] Test message. Please ignore.

[Kinney, Michael D]

Hi Chris,

This is a response to this test message.  The Reply-To setting
has been updated to make sure edk2-devel is always present.

Please do a Reply All to this test message.

Thanks,

Mike

From: Chris Co [mailto:christopher...@microsoft.com] 
Sent: Friday, October 26, 2018 6:09 PM
To: Kinney, Michael D ; Gretzinger, Adam R 
; edk2-devel@lists.01.org
Cc: Sean Brogan ; Jeremiah Cox 
; Cetola, Stephano ; Chad 
Mace 
Subject: Test message. Please ignore.

Test message. Checking for DMARC bounces...

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

Re: [edk2] Test message. Please ignore.

[Kinney, Michael D]

Chris,

Thanks.  That looks like what I expected.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Chris Co via edk2-
> devel
> Sent: Monday, October 29, 2018 11:22 AM
> To: Kinney, Michael D ;
> Gretzinger, Adam R ; edk2-
> de...@lists.01.org; Jeremiah Cox 
> Cc: Chris Co ; Chad Mace
> ; Sean Brogan
> ; Cetola, Stephano
> 
> Subject: Re: [edk2] Test message. Please ignore.
> 
> Hi Mike,
> 
> Here is a Reply All to the test message.
> 
> Chris
> 
> > -Original Message-
> > From: Kinney, Michael D 
> > Sent: Monday, October 29, 2018 10:31 AM
> > To: Chris Co ;
> Gretzinger, Adam R
> > ; edk2-
> de...@lists.01.org; Kinney, Michael D
> > ; Jeremiah Cox
> 
> > Cc: Sean Brogan ; Cetola,
> Stephano
> > ; Chad Mace
> 
> > Subject: RE: Test message. Please ignore.
> >
> > Hi Chris,
> >
> > This is a response to this test message.  The Reply-To
> setting has been
> > updated to make sure edk2-devel is always present.
> >
> > Please do a Reply All to this test message.
> >
> > Thanks,
> >
> > Mike
> >
> > From: Chris Co [mailto:christopher...@microsoft.com]
> > Sent: Friday, October 26, 2018 6:09 PM
> > To: Kinney, Michael D ;
> Gretzinger, Adam R
> > ; edk2-devel@lists.01.org
> > Cc: Sean Brogan ; Jeremiah
> Cox
> > ; Cetola, Stephano
> ;
> > Chad Mace 
> > Subject: Test message. Please ignore.
> >
> > Test message. Checking for DMARC bounces...
> >
> > Chris
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] ** NOTICE ** edk2-devel mailing list configuration changes

[Kinney, Michael D]

Hello,

Some configuration changes have been made to 
the edk2-devel mailing list to handle posts from
a domain with a DMARC Reject/Quarantine policy
enabled. If this is detected then the from address
is now munged.

One side effect of this setting is that the 
behavior of Reply has changed.  Instead of being 
a reply to the poster of the message, the Reply
address is the edk2-devel mailing list.

If you wish to send a private reply to only the
poster of the message, you may have to perform
some manual steps.

Please let me know if you have any concerns about
these changes or if these configuration changes 
cause any other side effects.

Thanks,

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

Re: [edk2] [PATCH edk2-staging 00/19] IntelUndiPkg/GigUndiDxe: build fixes for AARCH64/ARM/GCC

[Kinney, Michael D]

Hi Ard,

Can you please add CC lines to the commit message
for the developers that have contributed to the
edk2-staging/Intel_UNDI branch?

This would include:

Cc: Maciej Rabeda 
Cc: Kamil Kacperski 
Cc: Pawel Orlowski 

Thanks,

Mike


> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Tuesday, November 6, 2018 9:58 AM
> To: edk2-devel@lists.01.org
> Cc: Rabeda, Maciej ; Kinney,
> Michael D ; Jin, Eric
> ; leif.lindh...@linaro.org; Ard
> Biesheuvel 
> Subject: [PATCH edk2-staging 00/19]
> IntelUndiPkg/GigUndiDxe: build fixes for AARCH64/ARM/GCC
> 
> This series fixes the GigUndiDxe in the edk2-
> staging/Intel_UNDI branch
> at github.com/tianocore so it can be built with GCC on
> Linux for ARM
> and AARCH64 (as well as X64)
> 
> Ard Biesheuvel (19):
>   IntelOpenSourceUndiPkg.dsc: add AARCH64 and ARM to
> supported
> architectures
>   IntelUndiPkg: remove EOF markers
>   IntelUndiPkg/GigUndiDxe: consistently use lowercase
> for e1000 in
> filenames
>   IntelUndiPkg/GigUndiDxe: consistently use forward
> slashes as path
> separators
>   IntelUndiPkg/GigUndiDxe: move BRAND_STRUCT declaration
> after type
> definition
>   IntelUndiPkg/GigUndiDxe: use intermediate UINTN casts
> for pointers
>   IntelUndiPkg/GigUndiDxe: create GCC alternatives for
> MSFT build
> options
>   IntelUndiPkg/GigUndiDxe: add missing VOID** cast
>   IntelUndiPkg/GigUndiDxe: add missing UINT8* cast
>   IntelUndiPkg/GigUndiDxe: add missing braces to GUID
> literals
>   IntelUndiPkg/GigUndiDxe: fix incorrect use of CPP
> token pasting
>   IntelUndiPkg/GigUndiDxe: cast E1000MemCopy () args to
> correct pointer
> type
>   IntelUndiPkg/GigUndiDxe: don't take address of cast
> expression
>   IntelUndiPkg/GigUndiDxe: redefine
> UNREFERENCED_nPARAMETER macros for
> GCC
>   IntelUndiPkg/GigUndiDxe: remove forward declaration of
> non-existent
> function
>   IntelUndiPkg/GigUndiDxe: fix incorrect indentation
>   IntelUndiPkg/GigUndiDxe: move MSFT warning overrides
> to INF file
>   IntelUndiPkg/GigUndiDxe: add missing EFIAPI modifiers
>   IntelUndiPkg/GigUndiDxe: remove or reorganize unused
> variables
> 
>  IntelUndiPkg/GigUndiDxe/AdapterInformation.c  |  6 ++-
>  IntelUndiPkg/GigUndiDxe/AdapterInformation.h  |  1 -
>  IntelUndiPkg/GigUndiDxe/Brand.c   |  1 -
>  IntelUndiPkg/GigUndiDxe/ComponentName.c   |  5 ++-
>  IntelUndiPkg/GigUndiDxe/ComponentName.h   |  2 +-
>  IntelUndiPkg/GigUndiDxe/Decode.c  |  5 +--
>  IntelUndiPkg/GigUndiDxe/Decode.h  |  1 -
>  IntelUndiPkg/GigUndiDxe/DeviceSupport.c   |  1 -
>  IntelUndiPkg/GigUndiDxe/DeviceSupport.h   |  9 ++--
> -
>  IntelUndiPkg/GigUndiDxe/Dma.c | 11 +++-
> --
>  IntelUndiPkg/GigUndiDxe/Dma.h |  1 -
>  IntelUndiPkg/GigUndiDxe/DriverConfiguration.c |  6 ++-
>  IntelUndiPkg/GigUndiDxe/DriverConfiguration.h |  1 -
>  IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c   | 12 +++-
> --
>  IntelUndiPkg/GigUndiDxe/DriverDiagnostics.h   |  1 -
>  IntelUndiPkg/GigUndiDxe/DriverHealth.c|  5 ++-
>  IntelUndiPkg/GigUndiDxe/EepromConfig.c|  1 -
>  IntelUndiPkg/GigUndiDxe/EepromConfig.h|  3 +-
>  IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf| 39
> +--
>  IntelUndiPkg/GigUndiDxe/Hii.c | 11 +++-
> --
>  IntelUndiPkg/GigUndiDxe/Hii.h |  1 -
>  IntelUndiPkg/GigUndiDxe/HiiInternalLib.c  |  3 --
>  IntelUndiPkg/GigUndiDxe/HiiInternalLib.h  |  1 -
>  IntelUndiPkg/GigUndiDxe/Init.c| 11 +++-
> --
>  IntelUndiPkg/GigUndiDxe/Init.h|  1 -
>  IntelUndiPkg/GigUndiDxe/Inventory.vfr |  1 -
>  IntelUndiPkg/GigUndiDxe/NVDataStruc.h |  7 ++--
>  IntelUndiPkg/GigUndiDxe/StartStop.c   |  5 ++-
>  IntelUndiPkg/GigUndiDxe/StartStop.h   |  7 ++--
>  IntelUndiPkg/GigUndiDxe/Version.h |  1 -
>  IntelUndiPkg/GigUndiDxe/{E1000.c => e1000.c}  | 37
> --
>  IntelUndiPkg/GigUndiDxe/{E1000.h => e1000.h}  |  5 +--
>  IntelUndiPkg/GigUndiDxe/e1000_80003es2lan.c   |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_80003es2lan.h   |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_82571.c |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_82571.h |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_82575.c |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_82575.h |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_api.c   |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_api.h   |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_defines.h   | 10
> -
>  IntelUndiPkg/GigUndiDxe/e1000_hw.h|  1 -
>  I

Re: [edk2] [PATCH v1] Maintainers.txt: Change DynamicTablesPkg maintainer

[Kinney, Michael D]

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Tuesday, November 13, 2018 2:08 PM
> To: Sami Mujawar 
> Cc: edk2-devel@lists.01.org; ard.biesheu...@linaro.org;
> matteo.carl...@arm.com; stephanie.hughes-f...@arm.com;
> alexei.fedo...@arm.com; Andrew Fish ;
> Laszlo Ersek ; Kinney, Michael D
> 
> Subject: Re: [PATCH v1] Maintainers.txt: Change
> DynamicTablesPkg maintainer
> 
> +Andrew, Laszlo and Mike.
> 
> Hi Sami,
> 
> For my part, I can confirm that Evan is no longer
> evan.ll...@arm.com,
> so that account can't give an r-b on the change.
> 
> Reviewed-by: Leif Lindholm 
> 
> On Mon, Nov 12, 2018 at 04:27:46PM +, Sami Mujawar
> wrote:
> > Removing Evan and adding Alexei as the co-maintainer.
> >
> > Contributed-under: TianoCore Contribution Agreement
> 1.1
> > Signed-off-by: Sami Mujawar 
> > ---
> >  Maintainers.txt | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Maintainers.txt b/Maintainers.txt
> > index
> cd2a310cbd8c17a8d893c5c747025d1cef1ac433..7b3cb9a0255bf
> 7c249c8202666332e3c4fd83e6c 100644
> > --- a/Maintainers.txt
> > +++ b/Maintainers.txt
> > @@ -106,8 +106,8 @@ M: Hao Wu 
> >
> >  DynamicTablesPkg
> >  W:
> https://github.com/tianocore/tianocore.github.io/wiki/D
> ynamicTablesPkg
> > -M: Evan Lloyd 
> >  M: Sami Mujawar 
> > +M: Alexei Fedorov 
> >
> >  EdkCompatibilityPkg
> >  W:
> https://github.com/tianocore/tianocore.github.io/wiki/E
> dkCompatibilityPkg
> > --
> > 'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'
> >
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/4] SecurityPkg: add TpmIoLibMmio instance

[Kinney, Michael D]

Hi Eugene,

My experience is with DTPM and some I2C TPMs at 1.2 level.

One of the I2C TPMs was significantly different, so the TpmIoLib concept does 
not apply.

QuarkPlatformPkg\Library\Tpm12DeviceLibAtmelI2c

The other could potentially use something like TpmIoLib, but may require some 
different delays and timeout values than DTPM.

QuarkPlatformPkg\Library\Tpm12DeviceLibInfineonI2c

So maybe we offer 2 methods to port a TPM.  Once is TpmIoLib if the register 
layout and required delays are the same as DTPM with potentially a different 
base, and the other is to just implement the DeviceLib.

I would recommend that a full implementation of TpmIoLib for a few non MMIO TPM 
devices be completed and pass validation before we consider adding new lib 
class to edk2.  Perhaps using an edk2-staging branch would be a better place to 
start and you can document in the Readme.md the criteria that must be met 
before the new lib class meets the requirements for edk2/master.

Mike

From: Cohen, Eugene [mailto:eug...@hp.com]
Sent: Tuesday, November 13, 2018 3:24 PM
To: Kinney, Michael D ; edk2-devel@lists.01.org; 
Yao, Jiewen ; Zhang, Chao B 
Cc: Bin, Sung-Uk (빈성욱) 
Subject: RE: [PATCH 3/4] SecurityPkg: add TpmIoLibMmio instance

Mike,

There is a prevalence of base address nomenclature in the DTPM library like:

return TisPcRequestUseTpm ((TIS_PC_REGISTERS_PTR) (UINTN) 
PcdGet64 (PcdTpmBaseAddress));

like from Tpm2Tis.c.


Ø  shouldn’t the Address be the relative address from a base?

I think it is, to the extent that the PcdTpmBaseAddress already exists.


Ø  Or are you using the full DTPM MMIO address on purpose and you expect non 
DTPM MMIO implementations to translate from the DTPM MMIO address to the 
equivalent register access in on an alternate bus type?

My thought is that the PcdTpmBaseAddress could be set to zero (or whatever 
non-MMIO offset makes sense).


Ø  Wouldn't it be better to have an abstraction for different TPM registers and 
the DTPM implementation would convert to a full MMIO address in the lib 
implementation?

I've been led to understand that the TPM registers are the same in both cases.  
I haven't verified this myself - but if you have data to the contrary please 
let us know so we stop going down this path.

My main reason for resisting creating a new library at the Tpm2DeviceLib layer 
because the DTPM library contains a lot of logic around how to talk to the TPM 
that extends well beyond the access mechanism that we would not want to 
duplicate to another library instance.  I'm looking inside Tpm2Tis.c and 
Tpm2Ptp.c to get this perspective.

Thanks,

Eugene

From: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Sent: Tuesday, November 13, 2018 3:58 PM
To: Cohen, Eugene mailto:eug...@hp.com>>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Yao, Jiewen 
mailto:jiewen@intel.com>>; Zhang, Chao B 
mailto:chao.b.zh...@intel.com>>; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Cc: Bin, Sung-Uk (빈성욱) mailto:sunguk-...@hp.com>>
Subject: RE: [PATCH 3/4] SecurityPkg: add TpmIoLibMmio instance

Eugene,

It appears you are expecting the Address parameter
to be the full MMIO address for DTPM. If you are
wanting this lib class to abstract the access for
different bus types, shouldn’t the Address be the
relative address from a base?

Or are you using the full DTPM MMIO address on
purpose and you expect non DTPM MMIO implementations
to translate from the DTPM MMIO address to the
equivalent register access in on an alternate bus
type?

Wouldn't it be better to have an abstraction for
different TPM registers and the DTPM implementation
would convert to a full MMIO address in the lib
implementation?

Thanks,

Mike


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org<mailto:boun...@lists.01.org>] On Behalf Of Cohen, Eugene
> Sent: Tuesday, November 13, 2018 2:13 PM
> To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Yao, Jiewen
> mailto:jiewen@intel.com>>; Zhang, Chao B
> mailto:chao.b.zh...@intel.com>>
> Cc: Bin, Sung-Uk (빈성욱) mailto:sunguk-...@hp.com>>
> Subject: [edk2] [PATCH 3/4] SecurityPkg: add
> TpmIoLibMmio instance
>
> SecurityPkg: add TpmIoLibMmio instance
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Cc: Chao Zhang mailto:chao.b.zh...@intel.com>>
> Cc: Jiewen Yao mailto:jiewen@intel.com>>
> Signed-off-by: Eugene Cohen mailto:eug...@hp.com>>
> ---
> SecurityPkg/Library/TpmIoLibMmio/TpmIoLibMmio.c |
> 221 
> SecurityPkg/Library/TpmIoLibMmio/TpmIoLibMmio.inf |
> 41 
> 2 files changed, 262 insertions(+)
>
> diff --git
> a/SecurityPkg/Library/TpmIoLibMmio/TpmIoLibMmio.c
> b/SecurityPkg/Library/TpmIoLibMmio/TpmIoLibMmio.c
> new file mode 100644
> index 000..56f3187
&

Re: [edk2] [PATCH 3/4] SecurityPkg: add TpmIoLibMmio instance

[Kinney, Michael D]

Eugene,

It appears you are expecting the Address parameter
to be the full MMIO address for DTPM.  If you are
wanting this lib class to abstract the access for
different bus types, shouldn’t the Address be the
relative address from a base?

Or are you using the full DTPM MMIO address on 
purpose and you expect non DTPM MMIO implementations
to translate from the DTPM MMIO address to the
equivalent register access in on an alternate bus
type?

Wouldn't it be better to have an abstraction for
different TPM registers and the DTPM implementation
would convert to a full MMIO address in the lib
implementation?

Thanks,

Mike


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Cohen, Eugene
> Sent: Tuesday, November 13, 2018 2:13 PM
> To: edk2-devel@lists.01.org; Yao, Jiewen
> ; Zhang, Chao B
> 
> Cc: Bin, Sung-Uk (빈성욱) 
> Subject: [edk2] [PATCH 3/4] SecurityPkg: add
> TpmIoLibMmio instance
> 
> SecurityPkg: add TpmIoLibMmio instance
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Cc: Chao Zhang 
> Cc: Jiewen Yao 
> Signed-off-by: Eugene Cohen 
> ---
>  SecurityPkg/Library/TpmIoLibMmio/TpmIoLibMmio.c   |
> 221 
>  SecurityPkg/Library/TpmIoLibMmio/TpmIoLibMmio.inf |
> 41 
>  2 files changed, 262 insertions(+)
> 
> diff --git
> a/SecurityPkg/Library/TpmIoLibMmio/TpmIoLibMmio.c
> b/SecurityPkg/Library/TpmIoLibMmio/TpmIoLibMmio.c
> new file mode 100644
> index 000..56f3187
> --- /dev/null
> +++ b/SecurityPkg/Library/TpmIoLibMmio/TpmIoLibMmio.c
> @@ -0,0 +1,221 @@
> +/** @file
> +  This library is to abstract TPM2 register accesses
> so that a common
> +  interface can be used for multiple underlying busses
> such as TPM,
> +  SPI, or I2C access.
> +
> +Copyright (c) 2018 HP Development Company, L.P.
> +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 
> +
> +
> +
> +/**
> +  Reads an 8-bit TPM register.
> +
> +  Reads the 8-bit TPM register specified by Address.
> The 8-bit read value is
> +  returned. This function must guarantee that all TPM
> read and write
> +  operations are serialized.
> +
> +  If 8-bit TPM register operations are not supported,
> then ASSERT().
> +
> +  @param  Address The TPM register to read.
> +
> +  @return The value read.
> +
> +**/
> +UINT8
> +EFIAPI
> +TpmRead8 (
> +  IN  UINTN Address
> +  )
> +{
> +  return MmioRead8 (Address);
> +}
> +
> +/**
> +  Writes an 8-bit TPM register.
> +
> +  Writes the 8-bit TPM register specified by Address
> with the value specified
> +  by Value and returns Value. This function must
> guarantee that all TPM read
> +  and write operations are serialized.
> +
> +  If 8-bit TPM register operations are not supported,
> then ASSERT().
> +
> +  @param  Address The TPM register to write.
> +  @param  Value   The value to write to the TPM
> register.
> +
> +  @return Value.
> +
> +**/
> +UINT8
> +EFIAPI
> +TpmWrite8 (
> +  IN  UINTN Address,
> +  IN  UINT8 Value
> +  )
> +{
> +  return MmioWrite8 (Address, Value);
> +}
> +
> +
> +/**
> +  Reads a 16-bit TPM register.
> +
> +  Reads the 16-bit TPM register specified by Address.
> The 16-bit read value is
> +  returned. This function must guarantee that all TPM
> read and write
> +  operations are serialized.
> +
> +  If 16-bit TPM register operations are not supported,
> then ASSERT().
> +  If Address is not aligned on a 16-bit boundary, then
> ASSERT().
> +
> +  @param  Address The TPM register to read.
> +
> +  @return The value read.
> +
> +**/
> +UINT16
> +EFIAPI
> +TpmRead16 (
> +  IN  UINTN Address
> +  )
> +{
> +  return MmioRead16 (Address);
> +}
> +
> +
> +/**
> +  Writes a 16-bit TPM register.
> +
> +  Writes the 16-bit TPM register specified by Address
> with the value specified
> +  by Value and returns Value. This function must
> guarantee that all TPM read
> +  and write operations are serialized.
> +
> +  If 16-bit TPM register operations are not supported,
> then ASSERT().
> +  If Address is not aligned on a 16-bit boundary, then
> ASSERT().
> +
> +  @param  Address The TPM register to write.
> +  @param  Value   The value to write to the TPM
> register.
> +
> +  @return Value.
> +
> +**/
> +UINT16
> +EFIAPI
> +TpmWrite16 (
> +  IN  UINTN Address,
> +  IN  UINT16Value
> +  )
> +{
> +  return MmioWrite16 (Address, Value);
> +}
> +
> +/**
> +  Reads a 32-bit TPM register.
> +
> +  Reads the 32-bit TPM register specified by 

Re: [edk2] [PATCH 1/4] SecurityPkg: enable TPM components to build for ARM and AARCH64

[Kinney, Michael D]

Jiewen,

There are I2C examples for TPM12 in the
QuarkPlatformPkg.  Would that we a good example
too?

Could this new lib class be used for both 
TPM12 and TPM20 devices?

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Yao, Jiewen
> Sent: Tuesday, November 13, 2018 2:22 PM
> To: Cohen, Eugene ; edk2-
> de...@lists.01.org; Zhang, Chao B
> 
> Cc: Bin, Sung-Uk (???) 
> Subject: Re: [edk2] [PATCH 1/4] SecurityPkg: enable TPM
> components to build for ARM and AARCH64
> 
> HI Eugene
> Thanks to enable SPI TPM chip.
> In general, I am OK on this patch series.
> 
> There are some additional work here.
> 1) Please split this patch to 2. The TpmIoLib is not
> present in at this point of time. We should add it
> after TpmIoLib instance is added.
> 
> 2) Since this patch series adds the dependency of
> TpmIoLib, please update *all* impacted platform in
> EDKII repo and EDKII platform repo.
> We need make sure this patch series does not break any
> existing platform build.
> 
> 3) I hope, (if possible) you can provide one *real
> example* on how to add SPI instance, to demonstrate the
> usage and value of this one more layer abstraction.
> 
> Thank you
> Yao Jiewen
> 
> 
> > -Original Message-
> > From: Cohen, Eugene [mailto:eug...@hp.com]
> > Sent: Wednesday, November 14, 2018 6:13 AM
> > To: edk2-devel@lists.01.org; Yao, Jiewen
> ; Zhang,
> > Chao B 
> > Cc: Bin, Sung-Uk (빈성욱) 
> > Subject: [PATCH 1/4] SecurityPkg: enable TPM
> components to build for ARM
> > and AARCH64
> >
> >  SecurityPkg: enable TPM components to build for ARM
> and AARCH64
> >
> > Contributed-under: TianoCore Contribution Agreement
> 1.1
> > Cc: Chao Zhang 
> > Cc: Jiewen Yao 
> > Signed-off-by: Eugene Cohen 
> > ---
> >  SecurityPkg/SecurityPkg.dsc | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/SecurityPkg/SecurityPkg.dsc
> b/SecurityPkg/SecurityPkg.dsc
> > index 68a2953..6fb9ad2 100644
> > --- a/SecurityPkg/SecurityPkg.dsc
> > +++ b/SecurityPkg/SecurityPkg.dsc
> > @@ -53,6 +53,7 @@
> >
> IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLi
> b.inf
> >
> OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf
> >
> IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrin
> sic.inf
> > +
> TpmIoLib|SecurityPkg/Library/TpmIoLibMmio/TpmIoLibMmio.
> inf
> >
> TpmCommLib|SecurityPkg/Library/TpmCommLib/TpmCommLib.in
> f
> >
> >
> PlatformSecureLib|SecurityPkg/Library/PlatformSecureLib
> Null/PlatformSecu
> > reLibNull.inf
> >
> >
> TcgPhysicalPresenceLib|SecurityPkg/Library/DxeTcgPhysic
> alPresenceLib/Dxe
> > TcgPhysicalPresenceLib.inf
> > @@ -199,7 +200,7 @@
> >  [Components.IA32, Components.X64, Components.ARM,
> > Components.AARCH64]
> >
> SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
> >
> > -[Components.IA32, Components.X64]
> > +[Components.IA32, Components.X64 Components.ARM,
> > Components.AARCH64]
> >  #
> >
> SecurityPkg/UserIdentification/PwdCredentialProviderDxe
> /PwdCredentialPr
> > oviderDxe.inf
> >  #
> >
> SecurityPkg/UserIdentification/UsbCredentialProviderDxe
> /UsbCredentialPro
> > viderDxe.inf
> >
> >
> SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/S
> ecureBootConfi
> > gDxe.inf
> > --
> > 2.7.4
> 
> ___
> 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 6/8] IntelFrameworkPkg: Remove the redundant INFs

[Kinney, Michael D]

Shenglei,

I would prefer we work towards the goal of removing
the use of the Intel Framework Packages by all platforms
so the entire packages can be removed from edk2/master.

This would be better than trying to remove a few items
at a time.

Thanks,

Mike

> -Original Message-
> From: Zhang, Shenglei
> Sent: Tuesday, November 13, 2018 7:32 PM
> To: Ni, Ruiyu ; edk2-
> de...@lists.01.org
> Cc: Kinney, Michael D ;
> Gao, Liming 
> Subject: RE: [edk2] [PATCH 6/8] IntelFrameworkPkg:
> Remove the redundant INFs
> 
> Ray
> Thanks for your constructive comments. I'll improve it
> in next version.
> 
> Thanks,
> Shenglei
> > -Original Message-
> > From: Ni, Ruiyu
> > Sent: Wednesday, November 14, 2018 11:12 AM
> > To: Zhang, Shenglei ; edk2-
> de...@lists.01.org
> > Cc: Kinney, Michael D ;
> Gao, Liming
> > 
> > Subject: Re: [edk2] [PATCH 6/8] IntelFrameworkPkg:
> Remove the redundant
> > INFs
> >
> > On 11/13/2018 4:35 PM, Shenglei Zhang wrote:
> > > All INFs of unused Library instances in
> IntelFrameworkPkg
> > > are removed as they are not actually used.
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=1190
> > >
> > > Cc: Liming Gao 
> > > Cc: Michael D Kinney 
> > > Contributed-under: TianoCore Contribution Agreement
> 1.1
> > > Signed-off-by: Shenglei Zhang
> 
> > > ---
> > >   IntelFrameworkPkg/IntelFrameworkPkg.dsc | 7 -
> --
> > >   1 file changed, 7 deletions(-)
> > >
> > > diff --git
> a/IntelFrameworkPkg/IntelFrameworkPkg.dsc
> > b/IntelFrameworkPkg/IntelFrameworkPkg.dsc
> > > index bd5df8c5d9..802a80e3eb 100644
> > > --- a/IntelFrameworkPkg/IntelFrameworkPkg.dsc
> > > +++ b/IntelFrameworkPkg/IntelFrameworkPkg.dsc
> > > @@ -63,13 +63,6 @@
> > >   #   generated for it, but the binary will not
> be put into any firmware
> > volume.
> > >   #
> > >
> >
> ###
> ###
> > #
> > > -[Components]
> > > -
> IntelFrameworkPkg/Library/DxeIoLibCpuIo/DxeIoLibCpuIo.i
> nf
> > > -
> IntelFrameworkPkg/Library/FrameworkUefiLib/FrameworkUef
> iLib.inf
> > > -
> >
> IntelFrameworkPkg/Library/DxeSmmDriverEntryPoint/DxeSmm
> DriverEntryP
> > oint.inf
> > > -
> >
> IntelFrameworkPkg/Library/PeiSmbusLibSmbusPpi/PeiSmbusL
> ibSmbusPpi.in
> > f
> > > -
> >
> IntelFrameworkPkg/Library/PeiHobLibFramework/PeiHobLibF
> ramework.inf
> > > -
> > >   [BuildOptions]
> > > *_*_*_CC_FLAGS = -D
> DISABLE_NEW_DEPRECATED_INTERFACES
> > >
> > >
> > Shenglei,
> > You cannot remove the INF in the separate patch like
> this.
> > You should either put this patch in the first patch
> in your serial,
> > or combine the DSC change with your library removal.
> > The goal is the the build won't fail when committing
> the patches one by one.
> >
> > --
> > Thanks,
> > Ray
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Edk2 uni file encoding

[Kinney, Michael D]

Sean,

As a clarification.  The UNI specs does list 2 on-disk formats.
This was done so tools could support both in the transition
from UTF-16LE with BOM to UTF-8 without BOM.

The strong recommendation is for all EDK II open source packages to
use UTF-8 without a BOM.  Since platform packages not maintained
in EDK II could be pulling forward UNI files in UTF-16LE, we
have not changed the UNI spec or tools to consider UTF-16LE
as unsupported.

Doing patch email reviews of UNI files in UTF-16LE is a challenge
so requiring UTF-8 without a BOM make this much easier.

The EDK II open source package conversion to UTF-8 without a BO
was performed in late 2015.  Here is one example:

https://github.com/tianocore/edk2/commit/3f5287971ffdb5c42e3325a3a94c101f08d3a02a#diff-14d2171dacfcac1fd2e1b1f7b885e530

A helper python script was added to help perform these conversions:

https://github.com/tianocore/edk2/blob/master/BaseTools/Scripts/ConvertUni.py

At some point, it may make sense to *require* UTF-8 without a 
BOM for all UNI files and all tools and for tools to reject
UNI files that are not in UTF-8 without a BOM format.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Sean Brogan via
> edk2-devel
> Sent: Wednesday, November 7, 2018 11:11 PM
> To: Gao, Liming 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] Edk2 uni file encoding
> 
> Liming,
> That was exactly what I was looking for.
> 
> Thanks
> Sean
> 
> 
> 
> 
> -Original Message-
> From: Gao, Liming 
> Sent: Wednesday, November 7, 2018 10:01 PM
> To: Sean Brogan 
> Cc: edk2-devel@lists.01.org
> Subject: RE: Edk2 uni file encoding
> 
> Sean:
>   EDKII UNI spec
> (https://na01.safelinks.protection.outlook.com/?url=htt
> ps%3A%2F%2Fgithub.com%2Ftianocore%2Ftianocore.github.io
> %2Fwiki%2FEDK-II-
> Specificationsdata=02%7C01%7Csean.brogan%40microso
> ft.com%7C5ffeb105737e4c00150208d6453fa46a%7C72f988bf86f
> 141af91ab2d7cd011db47%7C1%7C0%7C636772536983024335
> sdata=veov60rbEtr3ub7RcreuFuqJvc4%2BdtAowph7kBGXW54%3D&
> amp;reserved=0) Chapter 2 defines UNI file format.
> EdkCompatibilityPkg is obsolete. BZ
> https://na01.safelinks.protection.outlook.com/?url=http
> s%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D
> 1103data=02%7C01%7Csean.brogan%40microsoft.com%7C5
> ffeb105737e4c00150208d6453fa46a%7C72f988bf86f141af91ab2
> d7cd011db47%7C1%7C0%7C636772536983024335sdata=LOLe
> zJzuK9kwu8QK78UM5nnCD%2FZEY5fxr1VQzk8sqY8%3Dreserv
> ed=0 is submitted to delete EdkCompatibilityPkg from
> edk2/master. We will work on it.
> 
> EDK II Unicode files are used for mapping token names
> to localized strings that are identified by an RFC4646
> language code. The format for storing EDK II Unicode
> files on disk is UTF-8 (without a BOM character) or
> UTF-16LE (with a BOM character). The character content
> must be UCS-2.
> 
> Thanks
> Liming
> >-Original Message-
> >From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of
> >Sean Brogan via edk2-devel
> >Sent: Thursday, November 08, 2018 7:00 AM
> >To: edk2-devel@lists.01.org
> >Subject: [edk2] Edk2 uni file encoding
> >
> >Is there a definitive answer for the file encoding for
> all UNI files in edk2?
> >If not I would like to propose one.  Incorrect
> encoding causes tool
> >issues and is something we can easily check for and
> fix.
> >
> >Proposal: All UNI files in edk2 should be
> >
> >
> >  1.  UTF-8
> >Or
> >
> >  1.  Use a BOM and be UTF-16
> >
> >https://na01.safelinks.protection.outlook.com/?url=htt
> ps%3A%2F%2Fen.wik
> >ipedia.org%2Fwiki%2FByte_order_markdata=02%7C01%7
> Csean.brogan%40mi
> >crosoft.com%7C5ffeb105737e4c00150208d6453fa46a%7C72f98
> 8bf86f141af91ab2d
> >7cd011db47%7C1%7C0%7C636772536983024335sdata=1IET
> 4LN5l9FfMscffzgk0
> >t7IqYGyYNU9IrZafvi9osU%3Dreserved=0
> >
> >Results from searching edk2:
> >1 - UTF-16 LE BOM file:
> >EdkCompatibilityPkg\Compatibility\FrameworkHiiOnUefiHi
> iThunk\Strings.un
> >i
> >919 - Without BOM and decoded as UTF-8
> >
> >Thoughts?
> >
> >Future question:  Can we make rule for all other
> standard file types
> >(c, h, dec, dsc, fdf, inf,)?
> >
> >Thanks
> >Sean
> >
> >
> >
> >___
> >edk2-devel mailing list
> >edk2-devel@lists.01.org
> >https://na01.safelinks.protection.outlook.com/?url=htt
> ps%3A%2F%2Flists.
> >01.org%2Fmailman%2Flistinfo%2Fedk2-
> develdata=02%7C01%7Csean.brogan
> >%40microsoft.com%7C5ffeb105737e4c00150208d6453fa46a%7C
> 72f988bf86f141af9
> >1ab2d7cd011db47%7C1%7C0%7C636772536983024335sdata
> =HhfPaCyS0sKHu1fF
> >Gkfh%2FQ4pm34X68YKiaM6IN7%2Fzj0%3Dreserved=0
> ___
> 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] BaseTools: Optimize string concatenation

[Kinney, Michael D]

Bob,

Is this for edk2/master or for the Python 3 conversion in the
edk2-staging branch?  If it is for the edk-staging branch, then
the Subject is not correct.

Thanks,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of BobCF
> Sent: Thursday, November 8, 2018 2:16 AM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Gao, Liming
> 
> Subject: [edk2] [Patch] BaseTools: Optimize string
> concatenation
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=1288
> 
> This patch is one of build tool performance improvement
> series patches.
> 
> This patch is going to use join function instead of
> string += string2 statement.
> 
> Current code use string += string2 in a loop to combine
> a string. while creating a string list in a loop and
> using
> "".join(stringlist) after the loop will be much faster.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: BobCF 
> Cc: Liming Gao 
> Cc: Jaben Carsey 
> ---
>  BaseTools/Source/Python/AutoGen/StrGather.py  | 39
> +--
>  BaseTools/Source/Python/Common/Misc.py| 21
> +-
>  .../Source/Python/Workspace/InfBuildData.py   |  4 +-
>  .../Python/Workspace/WorkspaceCommon.py   | 11 ++-
> ---
>  4 files changed, 44 insertions(+), 31 deletions(-)
> 
> diff --git
> a/BaseTools/Source/Python/AutoGen/StrGather.py
> b/BaseTools/Source/Python/AutoGen/StrGather.py
> index 361d499076..d34a9e9447 100644
> --- a/BaseTools/Source/Python/AutoGen/StrGather.py
> +++ b/BaseTools/Source/Python/AutoGen/StrGather.py
> @@ -135,11 +135,11 @@ def AscToHexList(Ascii):
>  # @param UniGenCFlag  UniString is generated into
> AutoGen C file when it is set to True
>  #
>  # @retval Str:   A string of .h file content
>  #
>  def CreateHFileContent(BaseName, UniObjectClass,
> IsCompatibleMode, UniGenCFlag):
> -Str = ''
> +Str = []
>  ValueStartPtr = 60
>  Line = COMMENT_DEFINE_STR + ' ' +
> LANGUAGE_NAME_STRING_NAME + ' ' * (ValueStartPtr -
> len(DEFINE_STR + LANGUAGE_NAME_STRING_NAME)) +
> DecToHexStr(0, 4) + COMMENT_NOT_REFERENCED
>  Str = WriteLine(Str, Line)
>  Line = COMMENT_DEFINE_STR + ' ' +
> PRINTABLE_LANGUAGE_NAME_STRING_NAME + ' ' *
> (ValueStartPtr - len(DEFINE_STR +
> PRINTABLE_LANGUAGE_NAME_STRING_NAME)) + DecToHexStr(1,
> 4) + COMMENT_NOT_REFERENCED
>  Str = WriteLine(Str, Line)
> @@ -164,16 +164,16 @@ def CreateHFileContent(BaseName,
> UniObjectClass, IsCompatibleMode, UniGenCFlag):
>  Line = COMMENT_DEFINE_STR + ' ' +
> Name + ' ' + DecToHexStr(Token, 4) +
> COMMENT_NOT_REFERENCED
>  else:
>  Line = COMMENT_DEFINE_STR + ' ' +
> Name + ' ' * (ValueStartPtr - len(DEFINE_STR + Name)) +
> DecToHexStr(Token, 4) + COMMENT_NOT_REFERENCED
>  UnusedStr = WriteLine(UnusedStr, Line)
> 
> -Str = ''.join([Str, UnusedStr])
> +Str.extend( UnusedStr)
> 
>  Str = WriteLine(Str, '')
>  if IsCompatibleMode or UniGenCFlag:
>  Str = WriteLine(Str, 'extern unsigned char ' +
> BaseName + 'Strings[];')
> -return Str
> +return "".join(Str)
> 
>  ## Create a complete .h file
>  #
>  # Create a complet .h file with file header and file
> content
>  #
> @@ -185,11 +185,11 @@ def CreateHFileContent(BaseName,
> UniObjectClass, IsCompatibleMode, UniGenCFlag):
>  # @retval Str:   A string of complete .h file
>  #
>  def CreateHFile(BaseName, UniObjectClass,
> IsCompatibleMode, UniGenCFlag):
>  HFile = WriteLine('', CreateHFileContent(BaseName,
> UniObjectClass, IsCompatibleMode, UniGenCFlag))
> 
> -return HFile
> +return "".join(HFile)
> 
>  ## Create a buffer to store all items in an array
>  #
>  # @param BinBuffer   Buffer to contain Binary data.
>  # @param Array:  The array need to be formatted
> @@ -209,11 +209,11 @@ def CreateBinBuffer(BinBuffer,
> Array):
>  #
>  def CreateArrayItem(Array, Width = 16):
>  MaxLength = Width
>  Index = 0
>  Line = '  '
> -ArrayItem = ''
> +ArrayItem = []
> 
>  for Item in Array:
>  if Index < MaxLength:
>  Line = Line + Item + ',  '
>  Index = Index + 1
> @@ -221,11 +221,11 @@ def CreateArrayItem(Array, Width
> = 16):
>  ArrayItem = WriteLine(ArrayItem, Line)
>  Line = '  ' + Item + ',  '
>  Index = 1
>  ArrayItem = Write(ArrayItem, Line.rstrip())
> 
> -return ArrayItem
> +return "".join(ArrayItem)
> 
>  ## CreateCFileStringValue
>  #
>  # Create a line with string value
>  #
> @@ -236,11 +236,11 @@ def CreateArrayItem(Array, Width
> = 16):
> 
>  def CreateCFileStringValue(Value):
>  Value = [StringBlockType] + Value
>  Str = WriteLine('', CreateArrayItem(Value))
> 
> -return Str
> +return "".join(Str)
> 
>  ## GetFilteredLanguage
>  #
>  # apply get best language rules to the UNI language
> code list
>  #
> @@ -438,11 +438,11 @@ def CreateCFileContent(BaseName,
> 

Re: [edk2] [Patch] BaseTools: Optimize string concatenation

[Kinney, Michael D]

Liming,

If we can support both Python2 and Python3 equally,
then I agree that these types of performance enhancements
can be added to edk2/master after the stable tag.

Let's make sure we enter a BZ for each performance
improvement and as Leif has asked, put evidence of the
performance improvement in the BZ.

Mike

> -Original Message-
> From: Gao, Liming
> Sent: Friday, November 9, 2018 6:17 AM
> To: Kinney, Michael D ;
> Feng, Bob C ; edk2-
> de...@lists.01.org
> Cc: Carsey, Jaben 
> Subject: RE: [edk2] [Patch] BaseTools: Optimize string
> concatenation
> 
> Mike:
>   This patch bases on edk2 master with Python27.
> Seemly, most people are not aware that Python3
> migration
> (https://bugzilla.tianocore.org/show_bug.cgi?id=55) is
> added for next edk2-stable201903 tag planning. In BZ
> 55, I propose to keep Python2 and Python3 both, and new
> feature and patches are created based on Python3. I
> will send the mail to collect the feedback on this
> approach.
> 
> Thanks
> Liming
> > -Original Message-
> > From: Kinney, Michael D
> > Sent: Friday, November 9, 2018 12:41 AM
> > To: Feng, Bob C ; edk2-
> de...@lists.01.org; Kinney, Michael D
> 
> > Cc: Carsey, Jaben ; Gao,
> Liming 
> > Subject: RE: [edk2] [Patch] BaseTools: Optimize
> string concatenation
> >
> > Bob,
> >
> > Is this for edk2/master or for the Python 3
> conversion in the
> > edk2-staging branch?  If it is for the edk-staging
> branch, then
> > the Subject is not correct.
> >
> > Thanks,
> >
> > Mike
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-
> > > boun...@lists.01.org] On Behalf Of BobCF
> > > Sent: Thursday, November 8, 2018 2:16 AM
> > > To: edk2-devel@lists.01.org
> > > Cc: Carsey, Jaben ; Gao,
> Liming
> > > 
> > > Subject: [edk2] [Patch] BaseTools: Optimize string
> > > concatenation
> > >
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=1288
> > >
> > > This patch is one of build tool performance
> improvement
> > > series patches.
> > >
> > > This patch is going to use join function instead of
> > > string += string2 statement.
> > >
> > > Current code use string += string2 in a loop to
> combine
> > > a string. while creating a string list in a loop
> and
> > > using
> > > "".join(stringlist) after the loop will be much
> faster.
> > >
> > > Contributed-under: TianoCore Contribution Agreement
> 1.1
> > > Signed-off-by: BobCF 
> > > Cc: Liming Gao 
> > > Cc: Jaben Carsey 
> > > ---
> > >  BaseTools/Source/Python/AutoGen/StrGather.py  | 39
> > > +--
> > >  BaseTools/Source/Python/Common/Misc.py| 21
> > > +-
> > >  .../Source/Python/Workspace/InfBuildData.py   |  4
> +-
> > >  .../Python/Workspace/WorkspaceCommon.py   | 11
> ++-
> > > ---
> > >  4 files changed, 44 insertions(+), 31 deletions(-)
> > >
> > > diff --git
> > > a/BaseTools/Source/Python/AutoGen/StrGather.py
> > > b/BaseTools/Source/Python/AutoGen/StrGather.py
> > > index 361d499076..d34a9e9447 100644
> > > --- a/BaseTools/Source/Python/AutoGen/StrGather.py
> > > +++ b/BaseTools/Source/Python/AutoGen/StrGather.py
> > > @@ -135,11 +135,11 @@ def AscToHexList(Ascii):
> > >  # @param UniGenCFlag  UniString is generated
> into
> > > AutoGen C file when it is set to True
> > >  #
> > >  # @retval Str:   A string of .h file
> content
> > >  #
> > >  def CreateHFileContent(BaseName, UniObjectClass,
> > > IsCompatibleMode, UniGenCFlag):
> > > -Str = ''
> > > +Str = []
> > >  ValueStartPtr = 60
> > >  Line = COMMENT_DEFINE_STR + ' ' +
> > > LANGUAGE_NAME_STRING_NAME + ' ' * (ValueStartPtr -
> > > len(DEFINE_STR + LANGUAGE_NAME_STRING_NAME)) +
> > > DecToHexStr(0, 4) + COMMENT_NOT_REFERENCED
> > >  Str = WriteLine(Str, Line)
> > >  Line = COMMENT_DEFINE_STR + ' ' +
> > > PRINTABLE_LANGUAGE_NAME_STRING_NAME + ' ' *
> > > (ValueStartPtr - len(DEFINE_STR +
> > > PRINTABLE_LANGUAGE_NAME_STRING_NAME)) +
> DecToHexStr(1,
> > > 4) + COMMENT_NOT_REFERENCED
> > >  Str = WriteLine(Str, Line)
> > > @@ -164,16 +164,16 @@ def
> CreateHFileContent(BaseName,
> > > UniObjectClass, IsCompatibleMode, UniGenCFlag):
> > >  

Re: [edk2] [edk2-wiki PATCH] release planning: announce the soft and hard feature freezes

[Kinney, Michael D]

Perhaps we should update Maintainers.txt with some lines
that identify the developers that are currently assigned
to the release/release planning role.  That way, the Wiki
can reference Maintainters.txt and we can update
Maintainers.txt as the assignments change over time.

Thanks,

Mike

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Friday, November 9, 2018 8:27 AM
> To: Gao, Liming ; Leif Lindholm
> 
> Cc: edk2-devel@lists.01.org; Andrew Fish
> ; Richardson, Brian
> ; Kinney, Michael D
> ; Cetola, Stephano
> 
> Subject: Re: [edk2-wiki PATCH] release planning:
> announce the soft and hard feature freezes
> 
> On 11/09/18 16:09, Gao, Liming wrote:
> > Laszlo:
> >  Can ';' be removed from below sentence?
> >
> > an announcement email is sent to the edk2-devel
> mailing list; by default by Liming Gao.
> >
> > ==>
> >
> > an announcement email is sent to the edk2-devel
> mailing list by default by Liming Gao.
> 
> Hmm I don't really like that, to me it makes the
> sentence a lot harder
> to read. How about this simplified version instead
> (i.e., drop "by
> default", and the semicolon):
> 
> "an announcement email is sent to the edk2-devel
> mailing list by Liming Gao"
> 
> ?
> 
> Thanks!
> Laszlo
> 
> 
> 
> >
> > Thanks
> > Liming
> >> -Original Message-
> >> From: Leif Lindholm
> [mailto:leif.lindh...@linaro.org]
> >> Sent: Friday, November 9, 2018 6:05 PM
> >> To: Laszlo Ersek 
> >> Cc: edk2-devel@lists.01.org; Andrew Fish
> ; Richardson, Brian
> ; Gao, Liming
> >> ; Kinney, Michael D
> ; Cetola, Stephano
> 
> >> Subject: Re: [edk2-wiki PATCH] release planning:
> announce the soft and hard feature freezes
> >>
> >> On Thu, Nov 08, 2018 at 06:28:07PM +0100, Laszlo
> Ersek wrote:
> >>> Add a paragraph to each of the SoftFeatureFreeze
> and HardFeatureFreeze
> >>> articles about the respective announcements on
> edk2-devel.
> >>>
> >>> Cc: Andrew Fish 
> >>> Cc: Brian Richardson 
> >>> Cc: Leif Lindholm 
> >>> Cc: Liming Gao 
> >>> Cc: Michael Kinney 
> >>> Cc: Stephano Cetola 
> >>> Contributed-under: TianoCore Contribution Agreement
> 1.1
> >>> Signed-off-by: Laszlo Ersek 
> >>
> >> Reviewed-by: Leif Lindholm
> 
> >>
> >>> ---
> >>>
> >>> Notes:
> >>> Check out the rendered pages in my clone of the
> wiki:
> >>>
> >>>
> https://github.com/lersek/edk2/wiki/SoftFeatureFreeze
> >>>
> https://github.com/lersek/edk2/wiki/HardFeatureFreeze
> >>>
> >>>  HardFeatureFreeze.md | 8 
> >>>  SoftFeatureFreeze.md | 8 
> >>>  2 files changed, 16 insertions(+)
> >>>
> >>> diff --git a/HardFeatureFreeze.md
> b/HardFeatureFreeze.md
> >>> index 01288dd03f71..e08f4c047e8d 100644
> >>> --- a/HardFeatureFreeze.md
> >>> +++ b/HardFeatureFreeze.md
> >>> @@ -4,3 +4,11 @@ tag](EDK-II#stable-tags).
> >>>
> >>>  (This definition is modeled after QEMU's [hard
> feature
> >>>
> freeze](https://wiki.qemu.org/Planning/HardFeatureFreez
> e)).
> >>> +
> >>> +# Announcing the hard feature freeze
> >>> +
> >>> +The proposed schedule for the active development
> cycle is shown in the [EDK II
> >>> +Release Planning](EDK-II-Release-Planning)
> article. Shortly before the hard
> >>> +feature freeze, an announcement email is sent to
> the
> >>> +[edk2-
> devel](https://lists.01.org/mailman/listinfo/edk2-
> devel) mailing list; by
> >>> +default by [Liming
> Gao](https://github.com/lgao4/).
> >>> diff --git a/SoftFeatureFreeze.md
> b/SoftFeatureFreeze.md
> >>> index 9dc7d9c19369..e33dd80ccbee 100644
> >>> --- a/SoftFeatureFreeze.md
> >>> +++ b/SoftFeatureFreeze.md
> >>> @@ -40,3 +40,11 @@ communicate with the maintainer
> about their intentions. It also helps if you:
> >>>
> >>>  (This definition is modeled after QEMU's [soft
> feature
> >>>
> freeze](https://wiki.qemu.org/Planning/SoftFeatureFreez
> e).)
> >>> +
> >>> +# Announcing the soft feature freeze
> >>> +
> >>> +The proposed schedule for the active development
> cycle is shown in the [EDK II
> >>> +Release Planning](EDK-II-Release-Planning)
> article. Shortly before the soft
> >>> +feature freeze, an announcement email is sent to
> the
> >>> +[edk2-
> devel](https://lists.01.org/mailman/listinfo/edk2-
> devel) mailing list; by
> >>> +default by [Liming
> Gao](https://github.com/lgao4/).
> >>> --
> >>> 2.19.1.3.g30247aa5d201
> >>>

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