Re: [edk2-devel] [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency

[Wu, Hao A]

> -Original Message-
> From: David Woodhouse [mailto:dw...@infradead.org]
> Sent: Wednesday, June 12, 2019 8:08 PM
> To: devel@edk2.groups.io; ler...@redhat.com; Wu, Hao A; Ni, Ray; Justen,
> Jordan L
> Cc: Ard Biesheuvel; Phillips, D Scott
> Subject: Re: [edk2-devel] [PATCH v2 0/6] Ovmf: Drop
> IntelFramework[Module]Pkg dependency
> 
> On Wed, 2019-06-12 at 13:52 +0200, Laszlo Ersek wrote:
> >
> > I don't think it's on Hao to determine an (edk2 base commit, SeaBIOS
> > base commit) pair from the past at which the CSM functionality worked
> > "flawlessly".
> 
> Absolutely!
> 
> I was only suggesting that Hao should make sure it doesn't get worse.

The test I performed is to verify booting legacy Windows 7 on a real
platform consuming the CSM components under IntelFrameworkModulePkg.

But I do not have much idea on what should I do to verify the duplicated
components under OvmfPkg when proposing this series. Is there any
suggestion here? I tried (but not with great effort) on building a SeaBIOS
binary, but failed to do so due to limited document on how to get it done.
(Maybe an update to OvmfPkg/Csm/Csm16/ReadMe.txt?)

Best Regards,
Hao Wu

> 
> When I first did it, I had various versions of Windows and Linux and
> *BSD working correctly. I'm still working when time allows on working
> out how to get back to that state.
> 
> But right now it does at least show that it's getting correctly into
> SeaBIOS and handling a bunch of requests before it crashes. As long as
> it still gets that far after Hao's patches, that's fine.


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

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

Re: [edk2-devel] [PATCH v3 1/1] BaseTools/Capsule: Tool to Generate Windows Firmware Update Driver

[Liming Gao]

Eric:
  Can you help post link for Windows Firmware Update Drivers?

Thanks
Liming
>-Original Message-
>From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Eric
>Jin
>Sent: Tuesday, June 11, 2019 2:23 PM
>To: devel@edk2.groups.io
>Cc: Feng, Bob C ; Gao, Liming
>; Kinney, Michael D 
>Subject: [edk2-devel] [PATCH v3 1/1] BaseTools/Capsule: Tool to Generate
>Windows Firmware Update Driver
>
>https://bugzilla.tianocore.org/show_bug.cgi?id=1837
>
>The tool is designed to generate Windows Firmware Update Drivers, the
>input is one drivername.cap with related parameters, the output Windows
>Driver package are composed by drivername.cap, drivername.inf and
>drivername.cat to update the single payload in device.
>
>usage:
>GenerateWindowsDriver [-h] [--output-folder OUTPUTFOLDER]
>  [--product-fmp-guid PRODUCTFMPGUID]
>  [--capsuleversion-dotstring CAPSULEVERSION_DOTSTRING]
>  [--capsuleversion-hexstring CAPSULEVERSION_HEXSTRING]
>  [--product-fw-provider PRODUCTFWPROVIDER]
>  [--product-fw-mfg-name PRODUCTFWMFGNAME]
>  [--product-fw-desc PRODUCTFWDESC]
>  [--capsule-file-name CAPSULEFILENAME]
>  [--pfx-file PFXFILE] [--arch ARCH]
>  [--operating-system-string OPERATINGSYSTEMSTRING]
>
>Cc: Bob Feng 
>Cc: Liming Gao 
>Cc: Kinney Michael D 
>Signed-off-by: Eric Jin 
>---
> BaseTools/Source/Python/Capsule/CatGenerator.py| 159
>+++
>+++
>+
> BaseTools/Source/Python/Capsule/GenerateWindowsDriver.py   | 114
>+++
>+++
> BaseTools/Source/Python/Capsule/InfGenerator.py| 210
>+++
>+++
>+++
>+
> BaseTools/Source/Python/Capsule/WindowsCapsuleSupportHelper.py | 102
>+++
>+++
> 4 files changed, 585 insertions(+)
>
>diff --git a/BaseTools/Source/Python/Capsule/CatGenerator.py
>b/BaseTools/Source/Python/Capsule/CatGenerator.py
>new file mode 100644
>index 00..5f7fefa788
>--- /dev/null
>+++ b/BaseTools/Source/Python/Capsule/CatGenerator.py
>@@ -0,0 +1,159 @@
>+## @file
>+ # Script to generate Cat files for capsule update based on supplied inf file
>+ #
>+ # Copyright (c) 2019, Microsoft Corporation
>+ # Copyright (c) 2019, Intel Corporation. All rights reserved.
>+ # SPDX-License-Identifier: BSD-2-Clause-Patent
>+ #
>+ ##
>+
>+import os
>+import logging
>+import datetime
>+import subprocess
>+import threading
>+
>+class PropagatingThread(threading.Thread):
>+def run(self):
>+self.exc = None
>+try:
>+if hasattr(self, '_Thread__target'):
>+# Thread uses name mangling prior to Python 3.
>+self.ret = self._Thread__target(*self._Thread__args,
>**self._Thread__kwargs)
>+else:
>+self.ret = self._target(*self._args, **self._kwargs)
>+except BaseException as e:
>+self.exc = e
>+def join(self, timeout=None):
>+super(PropagatingThread, self).join()
>+if self.exc:
>+ raise self.exc
>+return self.ret
>+def reader(filepath, outstream, stream):
>+if filepath:
>+try:
>+with open(filepath, "w") as f:
>+print("The file is" + filepath)
>+except FileNotFoundError:
>+print("Sorry, the file" + filepath + "does not exist.")
>+
>+while True:
>+s = stream.readline().decode()
>+if not s:
>+stream.close()
>+break
>+# write to file if caller provideds file
>+if filepath:
>+try:
>+with open(filepath, "a") as f:
>+f.write(s)
>+except FileNotFoundError:
>+print("Sorry, the file" + filepath + "does not exist.")
>+if(outstream is not None):
>+# write to stream object if caller provided object
>+outstream.write(s)
>+logging.info(s.rstrip())
>+
>+def RunCmd(cmd, parameters, capture=True, workingdir=None,
>outfile=None, outstream=None, environ=None):
>+cmd = cmd.strip('"\'')
>+if " " in cmd:
>+cmd = '"' + cmd + '"'
>+if parameters is not None:
>+parameters = parameters.strip()
>+cmd += " " + parameters
>+starttime = datetime.datetime.now()
>+logging.info("Cmd to run is: " + cmd)
>+logging.info("")
>+  

[edk2-devel] [PATCH v4 1/2] MdePkg: Implement SCSI commands for Security Protocol In/Out

[Zurcher, Christopher J]

This patch implements the Security Protocol In and Security Protocol Out
commands in UefiScsiLib to prepare support for the Storage Security
Command Protocol.

Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Liming Gao 
Signed-off-by: Christopher J Zurcher 
---
 MdePkg/Include/IndustryStandard/Scsi.h   |  48 +++--
 MdePkg/Include/Library/UefiScsiLib.h | 126 +++-
 MdePkg/Include/Protocol/ScsiIo.h |   9 +-
 MdePkg/Library/UefiScsiLib/UefiScsiLib.c | 205 +++-
 4 files changed, 366 insertions(+), 22 deletions(-)

diff --git a/MdePkg/Include/IndustryStandard/Scsi.h 
b/MdePkg/Include/IndustryStandard/Scsi.h
index cbe5709fe5..10d7b49ba7 100644
--- a/MdePkg/Include/IndustryStandard/Scsi.h
+++ b/MdePkg/Include/IndustryStandard/Scsi.h
@@ -1,7 +1,7 @@
 /** @file
   Support for SCSI-2 standard
 
-  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -163,6 +163,12 @@
 #define EFI_SCSI_OP_SEND_MESSAGE10  0x2a
 #define EFI_SCSI_OP_SEND_MESSAGE12  0xaa
 
+//
+// Additional commands for Secure Transactions
+//
+#define EFI_SCSI_OP_SECURITY_PROTOCOL_IN  0xa2
+#define EFI_SCSI_OP_SECURITY_PROTOCOL_OUT 0xb5
+
 //
 // SCSI Data Transfer Direction
 //
@@ -172,22 +178,30 @@
 //
 // Peripheral Device Type Definitions
 //
-#define EFI_SCSI_TYPE_DISK  0x00  ///< Direct-access device (e.g. 
magnetic disk)
-#define EFI_SCSI_TYPE_TAPE  0x01  ///< Sequential-access device (e.g. 
magnetic tape)
-#define EFI_SCSI_TYPE_PRINTER   0x02  ///< Printer device
-#define EFI_SCSI_TYPE_PROCESSOR 0x03  ///< Processor device
-#define EFI_SCSI_TYPE_WORM  0x04  ///< Write-once device (e.g. some 
optical disks)
-#define EFI_SCSI_TYPE_CDROM 0x05  ///< CD-ROM device
-#define EFI_SCSI_TYPE_SCANNER   0x06  ///< Scanner device
-#define EFI_SCSI_TYPE_OPTICAL   0x07  ///< Optical memory device (e.g. 
some optical disks)
-#define EFI_SCSI_TYPE_MEDIUMCHANGER 0x08  ///< Medium changer device (e.g. 
jukeboxes)
-#define EFI_SCSI_TYPE_COMMUNICATION 0x09  ///< Communications device
-#define EFI_SCSI_TYPE_ASCIT8_1  0x0A  ///< Defined by ASC IT8 (Graphic 
arts pre-press devices)
-#define EFI_SCSI_TYPE_ASCIT8_2  0x0B  ///< Defined by ASC IT8 (Graphic 
arts pre-press devices)
-//
-// 0Ch - 1Eh are reserved
-//
-#define EFI_SCSI_TYPE_UNKNOWN   0x1F  ///< Unknown or no device type
+#define EFI_SCSI_TYPE_DISK0x00  ///< Direct-access device (e.g. 
magnetic disk)
+#define EFI_SCSI_TYPE_TAPE0x01  ///< Sequential-access device 
(e.g. magnetic tape)
+#define EFI_SCSI_TYPE_PRINTER 0x02  ///< Printer device
+#define EFI_SCSI_TYPE_PROCESSOR   0x03  ///< Processor device
+#define EFI_SCSI_TYPE_WORM0x04  ///< Write-once device (e.g. some 
optical disks)
+#define EFI_SCSI_TYPE_CDROM   0x05  ///< CD/DVD device
+#define EFI_SCSI_TYPE_SCANNER 0x06  ///< Scanner device (obsolete)
+#define EFI_SCSI_TYPE_OPTICAL 0x07  ///< Optical memory device (e.g. 
some optical disks)
+#define EFI_SCSI_TYPE_MEDIUMCHANGER   0x08  ///< Medium changer device (e.g. 
jukeboxes)
+#define EFI_SCSI_TYPE_COMMUNICATION   0x09  ///< Communications device 
(obsolete)
+#define EFI_SCSI_TYPE_A   0x0A  ///< Obsolete
+#define EFI_SCSI_TYPE_B   0x0B  ///< Obsolete
+#define EFI_SCSI_TYPE_RAID0x0C  ///< Storage array controller 
device (e.g., RAID)
+#define EFI_SCSI_TYPE_SES 0x0D  ///< Enclosure services device
+#define EFI_SCSI_TYPE_RBC 0x0E  ///< Simplified direct-access 
device (e.g., magnetic disk)
+#define EFI_SCSI_TYPE_OCRW0x0F  ///< Optical card reader/writer 
device
+#define EFI_SCSI_TYPE_BRIDGE  0x10  ///< Bridge Controller Commands
+#define EFI_SCSI_TYPE_OSD 0x11  ///< Object-based Storage Device
+#define EFI_SCSI_TYPE_AUTOMATION  0x12  ///< Automation/Drive Interface
+#define EFI_SCSI_TYPE_SECURITYMANAGER 0x13  ///< Security manager device
+#define EFI_SCSI_TYPE_RESERVED_LOW0x14  ///< Reserved (low)
+#define EFI_SCSI_TYPE_RESERVED_HIGH   0x1D  ///< Reserved (high)
+#define EFI_SCSI_TYPE_WLUN0x1E  ///< Well known logical unit
+#define EFI_SCSI_TYPE_UNKNOWN 0x1F  ///< Unknown or no device type
 
 //
 // Page Codes for INQUIRY command
diff --git a/MdePkg/Include/Library/UefiScsiLib.h 
b/MdePkg/Include/Library/UefiScsiLib.h
index 10dd81902b..a0d99e703a 100644
--- a/MdePkg/Include/Library/UefiScsiLib.h
+++ b/MdePkg/Include/Library/UefiScsiLib.h
@@ -5,7 +5,7 @@
   for hard drive, CD and DVD devices that are the most common SCSI boot 
targets used by UEFI platforms.
   This library class depends on SCSI I/O Protocol defined in UEFI 
Specification and SCSI-2 industry standard.
 
-Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2019, Intel Corporation. All rights 

[edk2-devel] [PATCH v4 2/2] MdeModulePkg/ScsiDiskDxe: Support Storage Security Command Protocol

[Zurcher, Christopher J]

This patch implements the EFI_STORAGE_SECURITY_COMMAND_PROTOCOL in the
ScsiDiskDxe driver.

Support is currently limited to the RPMB Well-known LUN for UFS devices.

Cc: Michael D Kinney 
Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Liming Gao 
Signed-off-by: Christopher J Zurcher 
---
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf |   3 +-
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h  | 171 ++-
 MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c|   5 +-
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c  | 522 +++-
 MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c |  19 +-
 5 files changed, 698 insertions(+), 22 deletions(-)

diff --git a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf 
b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
index 5500d828e9..40818e669b 100644
--- a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
+++ b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
@@ -3,7 +3,7 @@
 #  It detects the SCSI disk media and installs Block I/O and Block I/O2 
Protocol on
 #  the device handle.
 #
-#  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+#  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
 ##
@@ -52,6 +52,7 @@
   gEfiBlockIoProtocolGuid   ## BY_START
   gEfiBlockIo2ProtocolGuid  ## BY_START
   gEfiEraseBlockProtocolGuid## BY_START
+  gEfiStorageSecurityCommandProtocolGuid## BY_START
   gEfiScsiIoProtocolGuid## TO_START
   gEfiScsiPassThruProtocolGuid  ## TO_START
   gEfiExtScsiPassThruProtocolGuid   ## TO_START
diff --git a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h 
b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h
index 42c095..2d8679ec6f 100644
--- a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h
+++ b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h
@@ -1,7 +1,7 @@
 /** @file
   Header file for SCSI Disk Driver.
 
-Copyright (c) 2004 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2004 - 2019, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -22,6 +22,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #include 
 #include 
 #include 
+#include 
 
 
 #include 
@@ -38,6 +39,10 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 
 #define IS_DEVICE_FIXED(a)(a)->FixedDevice ? 1 : 0
 
+#define IS_ALIGNED(addr, size)(((UINTN) (addr) & (size - 1)) == 0)
+
+#define UFS_WLUN_RPMB 0xC4
+
 typedef struct {
   UINT32MaxLbaCnt;
   UINT32MaxBlkDespCnt;
@@ -51,6 +56,8 @@ typedef struct {
 
   EFI_HANDLEHandle;
 
+  EFI_STORAGE_SECURITY_COMMAND_PROTOCOL   StorageSecurity;
+
   EFI_BLOCK_IO_PROTOCOL BlkIo;
   EFI_BLOCK_IO2_PROTOCOLBlkIo2;
   EFI_BLOCK_IO_MEDIABlkIoMedia;
@@ -95,6 +102,7 @@ typedef struct {
 #define SCSI_DISK_DEV_FROM_BLKIO(a)  CR (a, SCSI_DISK_DEV, BlkIo, 
SCSI_DISK_DEV_SIGNATURE)
 #define SCSI_DISK_DEV_FROM_BLKIO2(a)  CR (a, SCSI_DISK_DEV, BlkIo2, 
SCSI_DISK_DEV_SIGNATURE)
 #define SCSI_DISK_DEV_FROM_ERASEBLK(a)  CR (a, SCSI_DISK_DEV, EraseBlock, 
SCSI_DISK_DEV_SIGNATURE)
+#define SCSI_DISK_DEV_FROM_STORSEC(a)  CR (a, SCSI_DISK_DEV, StorageSecurity, 
SCSI_DISK_DEV_SIGNATURE)
 
 #define SCSI_DISK_DEV_FROM_DISKINFO(a) CR (a, SCSI_DISK_DEV, DiskInfo, 
SCSI_DISK_DEV_SIGNATURE)
 
@@ -638,6 +646,151 @@ ScsiDiskEraseBlocks (
   );
 
 
+/**
+  Send a security protocol command to a device that receives data and/or the 
result
+  of one or more commands sent by SendData.
+
+  The ReceiveData function sends a security protocol command to the given 
MediaId.
+  The security protocol command sent is defined by SecurityProtocolId and 
contains
+  the security protocol specific data SecurityProtocolSpecificData. The 
function
+  returns the data from the security protocol command in PayloadBuffer.
+
+  For devices supporting the SCSI command set, the security protocol command 
is sent
+  using the SECURITY PROTOCOL IN command defined in SPC-4.
+
+  If PayloadBufferSize is too small to store the available data from the 
security
+  protocol command, the function shall copy PayloadBufferSize bytes into the
+  PayloadBuffer and return EFI_WARN_BUFFER_TOO_SMALL.
+
+  If PayloadBuffer or PayloadTransferSize is NULL and PayloadBufferSize is 
non-zero,
+  the function shall return EFI_INVALID_PARAMETER.
+
+  If the given MediaId does not support security protocol commands, the 
function shall
+  return EFI_UNSUPPORTED. If there is no media in the device, the function 
returns
+  EFI_NO_MEDIA. If the MediaId is not the ID for the current media in the 
device,
+  the function returns EFI_MEDIA_CHANGED.
+
+  If the security protocol fails to complete within the Timeout period, the 
function
+  shall return EFI_TIMEOUT.
+
+  If the security protocol command completes without an error, the function 
shall
+  return EFI_SUCCESS. If the 

[edk2-devel] [PATCH v4 0/2] Add SCSI Support for Storage Security Command Protocol

[Zurcher, Christopher J]

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

V4 changes:
Add SSC Protocol in addition to BlockIo instead of in place of BlockIo.
Add error handling for (BlockSize == 0) in Read and WriteBlocks commands
to handle partitions that do not support ReadCapacity().

V3 changes:
Initialize AlignedBuffer variable in ScsiDiskReceiveData and
ScsiDiskSendData functions. Remove redundant input validation and debug
message in ScsiDiskSendData.

V2 changes:
Split the patch into separate commits for separate packages.

To support RPMB access on UFS devices, support must be added to
the ScsiDiskDxe driver for the Storage Security Command Protocol.

Cc: Michael D Kinney 
Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Liming Gao 

Christopher J Zurcher (2):
  MdePkg: Implement SCSI commands for Security Protocol In/Out
  MdeModulePkg/ScsiDiskDxe: Support Storage Security Command Protocol

 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf |   3 +-
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h  | 171 ++-
 MdePkg/Include/IndustryStandard/Scsi.h|  48 +-
 MdePkg/Include/Library/UefiScsiLib.h  | 126 -
 MdePkg/Include/Protocol/ScsiIo.h  |   9 +-
 MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c|   5 +-
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c  | 522 +++-
 MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c |  19 +-
 MdePkg/Library/UefiScsiLib/UefiScsiLib.c  | 205 +++-
 9 files changed, 1064 insertions(+), 44 deletions(-)

-- 
2.16.2.windows.1


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

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

Re: [edk2-devel] [PATCH v2 1/1] ShellPkg: acpiview: ACPI 6.3 update for MADT parser

[Gao, Zhichao]

Thanks for the interpret. Seems I read the old version spec. Now it is clear 
for me.

Reviewed-by: Zhichao Gao 

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Krzysztof Koch
> Sent: Wednesday, June 12, 2019 6:44 PM
> To: Gao, Zhichao ; devel@edk2.groups.io
> Cc: Sami Mujawar ; Carsey, Jaben
> ; Ni, Ray ; nd 
> Subject: Re: [edk2-devel] [PATCH v2 1/1] ShellPkg: acpiview: ACPI 6.3 update
> for MADT parser
> 
> Hi Zhichao,
> 
> Please find my comments inline below. They are marked with [Krzysztof]
> 
> Kind regards,
> 
> Krzysztof
> 
> -Original Message-
> From: Gao, Zhichao 
> Sent: Monday, June 10, 2019 2:08
> To: Krzysztof Koch ; devel@edk2.groups.io
> Cc: Sami Mujawar ; Carsey, Jaben
> ; Ni, Ray ; Matteo Carlini
> ; Stephanie Hughes-Fitt  f...@arm.com>; nd 
> Subject: RE: [PATCH v2 1/1] ShellPkg: acpiview: ACPI 6.3 update for MADT
> parser
> 
> Sorry for late update.
> 
> > -Original Message-
> > From: Krzysztof Koch [mailto:krzysztof.k...@arm.com]
> > Sent: Friday, June 7, 2019 4:48 PM
> > To: devel@edk2.groups.io
> > Cc: sami.muja...@arm.com; Carsey, Jaben ; Ni,
> > Ray ; Gao, Zhichao ;
> > matteo.carl...@arm.com; stephanie.hughes-f...@arm.com; n...@arm.com
> > Subject: [PATCH v2 1/1] ShellPkg: acpiview: ACPI 6.3 update for MADT
> > parser
> >
> > The ACPI 6.3 specification introduces a 'SPE overflow Interrupt' field
> > as part of the GICC structure.
> >
> > Update the MADT parser to decode this field and validate the interrupt
> > ID used.
> >
> > References:
> > - ACPI 6.3 Specification - January 2019
> > - Arm Generic Interrupt Controller Architecture Specification,
> >   GIC architecture version 3 and version 4, issue E
> > - Arm Server Base System Architecture 5.0
> >
> > Signed-off-by: Krzysztof Koch 
> > ---
> >
> > Changes can be seen at:
> > https://github.com/KrzysztofKoch1/edk2/tree/477_acpiview_spe_v2
> >
> > Notes:
> > v2:
> > - Add include sandwich in MadtParser.h [Zhichao]
> > - Add references to specifications in commit message [Zhichao]
> >
> > v1:
> > - Decode and validate SPE Overflow Interrupt field [Krzysztof]
> >
> >
> >
> ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtParser.
> > c | 86 ++--
> >
> ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtParser.
> > h | 40 +
> >  2 files changed, 118 insertions(+), 8 deletions(-)
> >
> > diff --git
> >
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtPars
> > er.c
> >
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtPars
> > er.c
> > index
> >
> a1bf86ade5313f954a77b325c13394cfce133939..59c3df0cc8a080497b517baf36f
> > c63f1e4ab866f 100644
> > ---
> >
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtPars
> > er.c
> > +++
> >
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtPars
> > +++ er.c
> > @@ -1,17 +1,21 @@
> >  /** @file
> >MADT table parser
> >
> > -  Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
> > +  Copyright (c) 2016 - 2019, ARM Limited. All rights reserved.
> >SPDX-License-Identifier: BSD-2-Clause-Patent
> >
> >@par Reference(s):
> > -- ACPI 6.2 Specification - Errata A, September 2017
> > +- ACPI 6.3 Specification - January 2019
> > +- Arm Generic Interrupt Controller Architecture Specification,
> > +  GIC architecture version 3 and version 4, issue E
> > +- Arm Server Base System Architecture 5.0
> >  **/
> >
> >  #include 
> >  #include 
> >  #include "AcpiParser.h"
> >  #include "AcpiTableParser.h"
> > +#include "MadtParser.h"
> >
> >  // Local Variables
> >  STATIC CONST UINT8* MadtInterruptControllerType; @@ -33,6 +37,21
> @@
> > ValidateGICDSystemVectorBase (
> >IN VOID*  Context
> >);
> >
> > +/**
> > +  This function validates the SPE Overflow Interrupt in the GICC.
> > +
> > +  @param [in] Ptr Pointer to the start of the field data.
> > +  @param [in] Context Pointer to context specific information e.g. this
> > +  could be a pointer to the ACPI table header.
> > +**/
> > +STATIC
> > +VOID
> > +EFIAPI
> > +ValidateSpeOverflowInterrupt (
> > +  IN UINT8* Ptr,
> > +  IN VOID*  Context
> > +  );
> > +
> >  /**
> >An ACPI_PARSER array describing the GICC Interrupt Controller Structure.
> >  **/
> > @@ -56,7 +75,9 @@ STATIC CONST ACPI_PARSER GicCParser[] = {
> >{L"MPIDR", 8, 68, L"0x%lx", NULL, NULL, NULL, NULL},
> >{L"Processor Power Efficiency Class", 1, 76, L"0x%x", NULL, NULL, NULL,
> > NULL},
> > -  {L"Reserved", 3, 77, L"%x %x %x", Dump3Chars, NULL, NULL, NULL}
> > +  {L"Reserved", 1, 77, L"0x%x", NULL, NULL, NULL, NULL},  {L"SPE
> > + overflow Interrupt", 2, 78, L"0x%x", NULL, NULL,
> > +ValidateSpeOverflowInterrupt, NULL}
> >  };
> >
> >  /**
> > @@ -160,6 +181,55 @@ ValidateGICDSystemVectorBase (
> >}
> >  }
> >
> > +/**
> > +  This function validates the SPE Overflow Interrupt in the GICC.
> > +
> > 

Re: [edk2-devel] [PATCH] MdeModulePkg/PeiMain: Substantial change for PeiAllocatePool

[Gao, Zhichao]

Thanks for the comments.
Your example makes the purpose clear. I would update the subject like that.

Thanks,
Zhichao

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Laszlo Ersek
> Sent: Wednesday, June 12, 2019 4:34 PM
> To: devel@edk2.groups.io; Gao, Zhichao 
> Cc: Bret Barkelew ; Wang, Jian J
> ; Wu, Hao A ; Ni, Ray
> ; Zeng, Star ; Gao, Liming
> ; Sean Brogan ;
> Michael Turner 
> Subject: Re: [edk2-devel] [PATCH] MdeModulePkg/PeiMain: Substantial
> change for PeiAllocatePool
> 
> Hi Zhichao,
> 
> On 06/12/19 06:50, Gao, Zhichao wrote:
> > From: Bret Barkelew 
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1901
> >
> > The original logic is ASSERT if fail to create HOB. But that doesn't
> > make sense for release version. So it is required to set the Buffer to
> > null to indicate the failure.
> 
> this patch may or may not be worthwhile; that's for the PEI Core maintainers
> to evaluate.
> 
> Either way, the subject line is completely useless. "Substantial change"
> means nothing at all. Please write a subject line that reflects what this 
> patch
> *actually does*.
> 
> For example:
> 
> MdeModulePkg/PeiMain: PeiAllocatePool: output NULL if HOB creation fails
> 
> (72 characters).
> 
> Thanks
> Laszlo
> 
> > Cc: Jian J Wang 
> > Cc: Hao Wu 
> > Cc: Ray Ni 
> > Cc: Star Zeng 
> > Cc: Liming Gao 
> > Cc: Sean Brogan 
> > Cc: Michael Turner 
> > Cc: Bret Barkelew 
> > Signed-off-by: Zhichao Gao 
> > ---
> >  MdeModulePkg/Core/Pei/Memory/MemoryServices.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/MdeModulePkg/Core/Pei/Memory/MemoryServices.c
> > b/MdeModulePkg/Core/Pei/Memory/MemoryServices.c
> > index 42f79ab076..37b0cfa3cf 100644
> > --- a/MdeModulePkg/Core/Pei/Memory/MemoryServices.c
> > +++ b/MdeModulePkg/Core/Pei/Memory/MemoryServices.c
> > @@ -802,7 +802,12 @@ PeiAllocatePool (
> >   (VOID **)
> >   );
> >ASSERT_EFI_ERROR (Status);
> > -  *Buffer = Hob+1;
> > +
> > +  if (EFI_ERROR (Status)) {
> > +*Buffer = NULL;
> > +  } else {
> > +*Buffer = Hob+1;
> > +  }
> >
> >return Status;
> >  }
> >
> 
> 
> 


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

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

Re: [edk2-devel] [PATCH] CryptoPkg: Add lacking instances for build only

[Gao, Zhichao]

I would fix the typo and replace the word 'lacking' with 'missing' in both BZ 
and the subject.

Thanks,
Zhichao

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Laszlo Ersek
> Sent: Wednesday, June 12, 2019 4:38 PM
> To: devel@edk2.groups.io; Gao, Zhichao 
> Cc: Bret Barkelew ; Wang, Jian J
> ; Ye, Ting ; Gao, Liming
> ; Sean Brogan ;
> Michael Turner 
> Subject: Re: [edk2-devel] [PATCH] CryptoPkg: Add lacking instances for build
> only
> 
> On 06/12/19 04:39, Gao, Zhichao wrote:
> > From: Bret Barkelew 
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1900
> >
> > Add the lacking instance to [Componnets] of dsc file for build only.
> >
> > Cc: Jian Wang 
> > Cc: Ting Ye 
> > Cc: Liming Gao 
> > Cc: Sean Brogan 
> > Cc: Michael Turner 
> > Cc: Bret Barkelew 
> > Signed-off-by: Zhichao Gao 
> > ---
> >  CryptoPkg/CryptoPkg.dsc | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/CryptoPkg/CryptoPkg.dsc b/CryptoPkg/CryptoPkg.dsc index
> > 9dfa349f6d..c90e76c721 100644
> > --- a/CryptoPkg/CryptoPkg.dsc
> > +++ b/CryptoPkg/CryptoPkg.dsc
> > @@ -116,6 +116,7 @@
> >CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
> >CryptoPkg/Library/TlsLib/TlsLib.inf
> >CryptoPkg/Library/OpensslLib/OpensslLib.inf
> > +  CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
> >
> >  [Components.IA32, Components.X64]
> >CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
> >
> 
> I'd like to suggest wording / spelling improvements:
> 
> - [Componnets] should be [Components]
> 
> - While I'm not a native English speaker, I believe "missing" would be more
> precise than "lacking". To me, "lacking" implies that the library instances in
> question have shortcomings. However, that's not what we mean here --
> those library instances are just fine, they are just missing from the DSC 
> files.
> Hence my suggestion to say "missing" (in both the subject line and the
> commit message).
> 
> Thank you
> Laszlo
> 
> 


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

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

[edk2-devel] [PATCH 11/10] OvmfPkg/Csm/LegacyBiosDxe: Correct Legacy16GetTableAddress call for E820 data

[David Woodhouse]

The DX register is supposed to contain the required alignment for the
allocation. It was zero, and SeaBIOS doesn't (well, didn't) cope well
with that. Set it appropriately, and set BX to indicate the regions
it's OK to allocate in too. That was already OK but let's make sure
it's initialised properly and not just working by chance.

Also actually return an error if the allocation fails. Instead of going
all the way through into the CSM and just letting it have a bogus
pointer to the E82o data.

Signed-off-by: David Woodhouse 
---
I made SeaBIOS cope with the zero too:
https://mail.coreboot.org/hyperkitty/list/seab...@seabios.org/thread/4PHW3O3Y3HJFENODFV5INBGDLZMXA5KE/

 OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
b/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
index 211750c012..e7766eb2b1 100644
--- a/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
+++ b/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
@@ -928,7 +928,9 @@ GenericLegacyBoot (
   if (CopySize > Private->Legacy16Table->E820Length) {
 ZeroMem (, sizeof (EFI_IA32_REGISTER_SET));
 Regs.X.AX = Legacy16GetTableAddress;
+Regs.X.BX = (UINT16) 0x3; // Region
 Regs.X.CX = (UINT16) CopySize;
+Regs.X.DX = (UINT16) 0x4; // Alignment
 Private->LegacyBios.FarCall86 (
   >LegacyBios,
   Private->Legacy16Table->Compatibility16CallSegment,
@@ -942,6 +944,7 @@ GenericLegacyBoot (
 Private->Legacy16Table->E820Length  = (UINT32) CopySize;
 if (Regs.X.AX != 0) {
   DEBUG ((EFI_D_ERROR, "Legacy16 E820 length insufficient\n"));
+  return EFI_OUT_OF_RESOURCES;
 } else {
   CopyMem (
 (VOID *)(UINTN) Private->Legacy16Table->E820Pointer,


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

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



smime.p7s
Description: S/MIME cryptographic signature

Re: [edk2-devel] [PATCH v2 00/10] Duplicate required CSM components for OVMF

[David Woodhouse]

On Mon, 2019-05-27 at 11:03 +0800, Hao A Wu wrote:
> '''
> Please note that this series will be hold until the edk2-stable201905 is
> created.
> '''
> 
> The series is also available at:
> https://github.com/hwu25/edk2/tree/ovmf_csm_v2
> 
> V2 changes:
> 
> Discussion with David Woodhouse for him to take the reviewer role for the
> duplicated CSM components under OvmfPkg:
> https://edk2.groups.io/g/devel/topic/31682287#40996
> 
> The (new) first patch will update the Maintainers.txt to reflect such
> role.
> 
> 
> V1 history:
> 
> The series will duplicate the CSM components used by the OVMF package from
> IntelFrameworkModulePkg & IntelFrameworkPkg.
> 
> Verification done for the series:
> * Build pass with/without build command option '-D CSM_ENABLE';
> * Boot shell pass with the built images.
> 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> 
> Hao A Wu (10):
>   Maintainers.txt: Add maintainer for CSM components in OvmfPkg
>   OvmfPkg: Copy the required CSM components from framework packages
>   OvmfPkg/OvmfPkg.dec: Add definitions for CSM-related Guid & Protocol
>   OvmfPkg/OvmfPkg.dec: Add the new include folder for CSM header files
>   OvmfPkg/OvmfPkg.dec: Add PCD definitions used by copied CSM modules
>   OvmfPkg/Csm/VideoDxe: Update to make it build for OVMF
>   OvmfPkg/Csm/LegacyBiosDxe: Update to make it build for OVMF
>   OvmfPkg/Csm/LegacyBootMaintUiLib: Update to make it build for OVMF
>   OvmfPkg/Csm/LegacyBootManagerLib: Update to make it build for OVMF
>   OvmfPkg: Update DSC/FDF files to consume CSM components in OvmfPkg

I'll submit a [PATCH 11/10] in a moment which makes it actually work
again. With that included, the first ten in the series are

Reviewed-by: David Woodhouse 

Thanks.



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

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



smime.p7s
Description: S/MIME cryptographic signature

Re: [edk2-devel] [PATCH v1 2/2] ShellPkg: acpiview: Update SRAT parser to ACPI 6.3

[Sami Mujawar]

Reviewed-by: Sami Mujawar 

-Original Message-
From: Krzysztof Koch  
Sent: 12 June 2019 03:11 PM
To: devel@edk2.groups.io
Cc: jaben.car...@intel.com; ray...@intel.com; zhichao@intel.com; 
michael.d.kin...@intel.com; liming@intel.com; Sami Mujawar 
; Matteo Carlini ; Stephanie 
Hughes-Fitt ; nd 
Subject: [PATCH v1 2/2] ShellPkg: acpiview: Update SRAT parser to ACPI 6.3

Add support for parsing revision 3 of System Resource Affinity Table (SRAT).

Decode and dump the new Generic Initiator Affinity Structure.

Validate the Device Handle Type field inside the Generic Initiator Affinity 
Structure.

Signed-off-by: Krzysztof Koch 
---

Changes can be seen at: 
https://github.com/KrzysztofKoch1/edk2/tree/582_acpiview_6_3_srat_v1

Notes:
v1:
- dump and validate the Generic Initiator Affinity Struct [Krzysztof]

 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c  |  35 
++-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h  |  16 ++
 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c | 256 
+++-
 3 files changed, 299 insertions(+), 8 deletions(-)

diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
index 
b5965507b498b9fa9bc4d3124b2285f509004c4f..60523936732f901317ee93d03fe06df1403f3695
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
@@ -1,7 +1,7 @@
 /** @file
   ACPI parser
 
-  Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
+  Copyright (c) 2016 - 2019, ARM Limited. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent  **/
 
@@ -401,6 +401,39 @@ Dump8Chars (
 );
 }
 
+/**
+  This function traces 12 characters which can be optionally
+  formated using the format string if specified.
+
+  If no format string is specified the Format must be NULL.
+
+  @param [in] Format  Optional format string for tracing the data.
+  @param [in] Ptr Pointer to the start of the buffer.
+**/
+VOID
+EFIAPI
+Dump12Chars (
+  IN CONST CHAR16* Format OPTIONAL,
+  IN   UINT8*  Ptr
+  )
+{
+  Print (
+(Format != NULL) ? Format : L"%c%c%c%c%c%c%c%c%c%c%c%c",
+Ptr[0],
+Ptr[1],
+Ptr[2],
+Ptr[3],
+Ptr[4],
+Ptr[5],
+Ptr[6],
+Ptr[7],
+Ptr[8],
+Ptr[9],
+Ptr[10],
+Ptr[11]
+);
+}
+
 /**
   This function indents and prints the ACPI table Field Name.
 
diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
index 
7657892d9fd2e2e14c6578611ff0cf1b6f6cd750..5b23ab6fa9bd2f87e0347287872685a2f74622f3
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
@@ -184,6 +184,22 @@ Dump8Chars (
   IN UINT8*Ptr
   );
 
+/**
+  This function traces 12 characters which can be optionally
+  formated using the format string if specified.
+
+  If no format string is specified the Format must be NULL.
+
+  @param [in] Format  Optional format string for tracing the data.
+  @param [in] Ptr Pointer to the start of the buffer.
+**/
+VOID
+EFIAPI
+Dump12Chars (
+  IN CONST CHAR16* Format OPTIONAL,
+  IN   UINT8*  Ptr
+  );
+
 /**
   This function indents and prints the ACPI table Field Name.
 
diff --git 
a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c
index 
075ff2a141a82b522e8aaedb7ad79249aaf5eaac..8c268a11454d13c9e278691d619a580c4c14c08e
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratPars
+++ er.c
@@ -1,11 +1,11 @@
 /** @file
   SRAT table parser
 
-  Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
+  Copyright (c) 2016 - 2019, ARM Limited. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
   @par Reference(s):
-- ACPI 6.2 Specification - Errata A, September 2017
+- ACPI 6.3 Specification - January 2019
 **/
 
 #include 
@@ -17,6 +17,7 @@
 // Local Variables
 STATIC CONST UINT8* SratRAType;
 STATIC CONST UINT8* SratRALength;
+STATIC CONST UINT8* SratDeviceHandleType;
 STATIC ACPI_DESCRIPTION_HEADER_INFO AcpiHdrInfo;
 
 /**
@@ -34,6 +35,51 @@ ValidateSratReserved (
   IN VOID*  Context
   );
 
+/**
+  This function validates the Device Handle Type field in the Generic 
+Initiator
+  Affinity Structure.
+
+  @param [in] Ptr Pointer to the start of the field data.
+  @param [in] Context Pointer to context specific information e.g. this
+  could be a pointer to the ACPI table header.
+**/
+STATIC
+VOID
+EFIAPI
+ValidateSratDeviceHandleType (
+  IN UINT8* Ptr,
+  IN VOID*  Context
+  );
+
+/**
+  This function traces the Device Handle field inside Generic Initiator
+  Affinity 

Re: [edk2-devel] [PATCH v1 1/2] MdePkg: Add Generic Initiator Affinity Structure definitions to SRAT

[Sami Mujawar]

Reviewed-by: Sami Mujawar 

-Original Message-
From: Krzysztof Koch  
Sent: 12 June 2019 03:11 PM
To: devel@edk2.groups.io
Cc: jaben.car...@intel.com; ray...@intel.com; zhichao@intel.com; 
michael.d.kin...@intel.com; liming@intel.com; Sami Mujawar 
; Matteo Carlini ; Stephanie 
Hughes-Fitt ; nd 
Subject: [PATCH v1 1/2] MdePkg: Add Generic Initiator Affinity Structure 
definitions to SRAT

Add Generic Initiator Affinity Structure to the list of recognised System 
Resource Affinity Table (SRAT) structure types.

Add definitions for Device Handle Types inside the Generic Initiator Affinity 
Structure.

References:
- ACPI 6.3 January 2019, Table 5-78

Signed-off-by: Krzysztof Koch 
---

Changes can be seen at: 
https://github.com/KrzysztofKoch1/edk2/tree/582_acpiview_6_3_srat_v1

Notes:
v1:
- define the SRAT Generic Initiator Affinity Struct type [Krzysztof]
- define the SRAT Device Handle Types [Krzysztof]

 MdePkg/Include/IndustryStandard/Acpi63.h | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/IndustryStandard/Acpi63.h 
b/MdePkg/Include/IndustryStandard/Acpi63.h
index 
a8e011579ffcf070ecdfd2c6726a16d1afd65891..eca1f9357b70f10887e680ff13c97c0beab3600b
 100644
--- a/MdePkg/Include/IndustryStandard/Acpi63.h
+++ b/MdePkg/Include/IndustryStandard/Acpi63.h
@@ -639,7 +639,7 @@ typedef struct {
 
 //
 // SRAT structure types.
-// All other values between 0x05 an 0xFF are reserved and
+// All other values between 0x06 an 0xFF are reserved and
 // will be ignored by OSPM.
 //
 #define EFI_ACPI_6_3_PROCESSOR_LOCAL_APIC_SAPIC_AFFINITY  0x00 @@ -647,6 
+647,7 @@ typedef struct {
 #define EFI_ACPI_6_3_PROCESSOR_LOCAL_X2APIC_AFFINITY  0x02
 #define EFI_ACPI_6_3_GICC_AFFINITY0x03
 #define EFI_ACPI_6_3_GIC_ITS_AFFINITY 0x04
+#define EFI_ACPI_6_3_GENERIC_INITIATOR_AFFINITY   0x05
 
 ///
 /// Processor Local APIC/SAPIC Affinity Structure Definition @@ -733,6 +734,14 
@@ typedef struct {
   UINT32  ItsId;
 } EFI_ACPI_6_3_GIC_ITS_AFFINITY_STRUCTURE;
 
+//
+// Generic Initiator Affinity Structure Device Handle Types // All 
+other values between 0x02 an 0xFF are reserved and // will be ignored 
+by OSPM.
+//
+#define EFI_ACPI_6_3_ACPI_DEVICE_HANDLE 0x00
+#define EFI_ACPI_6_3_PCI_DEVICE_HANDLE  0x01
+
 ///
 /// Device Handle - ACPI
 ///
--
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'



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

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

Re: [edk2-devel] [PATCH v2 1/1] ShellPkg: acpiview: ACPI 6.3 update for MADT parser

[Sami Mujawar]

Reviewed-by: Sami Mujawar 

-Original Message-
From: Krzysztof Koch  
Sent: 12 June 2019 11:44 AM
To: Gao, Zhichao ; devel@edk2.groups.io
Cc: Sami Mujawar ; Carsey, Jaben 
; Ni, Ray ; nd 
Subject: RE: [PATCH v2 1/1] ShellPkg: acpiview: ACPI 6.3 update for MADT parser

Hi Zhichao,

Please find my comments inline below. They are marked with [Krzysztof]

Kind regards,

Krzysztof

-Original Message-
From: Gao, Zhichao 
Sent: Monday, June 10, 2019 2:08
To: Krzysztof Koch ; devel@edk2.groups.io
Cc: Sami Mujawar ; Carsey, Jaben 
; Ni, Ray ; Matteo Carlini 
; Stephanie Hughes-Fitt 
; nd 
Subject: RE: [PATCH v2 1/1] ShellPkg: acpiview: ACPI 6.3 update for MADT parser

Sorry for late update.

> -Original Message-
> From: Krzysztof Koch [mailto:krzysztof.k...@arm.com]
> Sent: Friday, June 7, 2019 4:48 PM
> To: devel@edk2.groups.io
> Cc: sami.muja...@arm.com; Carsey, Jaben ; Ni, 
> Ray ; Gao, Zhichao ; 
> matteo.carl...@arm.com; stephanie.hughes-f...@arm.com; n...@arm.com
> Subject: [PATCH v2 1/1] ShellPkg: acpiview: ACPI 6.3 update for MADT 
> parser
> 
> The ACPI 6.3 specification introduces a 'SPE overflow Interrupt' field 
> as part of the GICC structure.
> 
> Update the MADT parser to decode this field and validate the interrupt 
> ID used.
> 
> References:
> - ACPI 6.3 Specification - January 2019
> - Arm Generic Interrupt Controller Architecture Specification,
>   GIC architecture version 3 and version 4, issue E
> - Arm Server Base System Architecture 5.0
> 
> Signed-off-by: Krzysztof Koch 
> ---
> 
> Changes can be seen at:
> https://github.com/KrzysztofKoch1/edk2/tree/477_acpiview_spe_v2
> 
> Notes:
> v2:
> - Add include sandwich in MadtParser.h [Zhichao]
> - Add references to specifications in commit message [Zhichao]
> 
> v1:
> - Decode and validate SPE Overflow Interrupt field [Krzysztof]
> 
> 
> ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtParser.
> c | 86 ++--
> ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtParser.
> h | 40 +
>  2 files changed, 118 insertions(+), 8 deletions(-)
> 
> diff --git
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtPars
> er.c
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtPars
> er.c
> index
> a1bf86ade5313f954a77b325c13394cfce133939..59c3df0cc8a080497b517baf36f
> c63f1e4ab866f 100644
> ---
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtPars
> er.c
> +++
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtPars
> +++ er.c
> @@ -1,17 +1,21 @@
>  /** @file
>MADT table parser
> 
> -  Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
> +  Copyright (c) 2016 - 2019, ARM Limited. All rights reserved.
>SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>@par Reference(s):
> -- ACPI 6.2 Specification - Errata A, September 2017
> +- ACPI 6.3 Specification - January 2019
> +- Arm Generic Interrupt Controller Architecture Specification,
> +  GIC architecture version 3 and version 4, issue E
> +- Arm Server Base System Architecture 5.0
>  **/
> 
>  #include 
>  #include 
>  #include "AcpiParser.h"
>  #include "AcpiTableParser.h"
> +#include "MadtParser.h"
> 
>  // Local Variables
>  STATIC CONST UINT8* MadtInterruptControllerType; @@ -33,6 +37,21 @@ 
> ValidateGICDSystemVectorBase (
>IN VOID*  Context
>);
> 
> +/**
> +  This function validates the SPE Overflow Interrupt in the GICC.
> +
> +  @param [in] Ptr Pointer to the start of the field data.
> +  @param [in] Context Pointer to context specific information e.g. this
> +  could be a pointer to the ACPI table header.
> +**/
> +STATIC
> +VOID
> +EFIAPI
> +ValidateSpeOverflowInterrupt (
> +  IN UINT8* Ptr,
> +  IN VOID*  Context
> +  );
> +
>  /**
>An ACPI_PARSER array describing the GICC Interrupt Controller Structure.
>  **/
> @@ -56,7 +75,9 @@ STATIC CONST ACPI_PARSER GicCParser[] = {
>{L"MPIDR", 8, 68, L"0x%lx", NULL, NULL, NULL, NULL},
>{L"Processor Power Efficiency Class", 1, 76, L"0x%x", NULL, NULL, NULL,
> NULL},
> -  {L"Reserved", 3, 77, L"%x %x %x", Dump3Chars, NULL, NULL, NULL}
> +  {L"Reserved", 1, 77, L"0x%x", NULL, NULL, NULL, NULL},  {L"SPE 
> + overflow Interrupt", 2, 78, L"0x%x", NULL, NULL,
> +ValidateSpeOverflowInterrupt, NULL}
>  };
> 
>  /**
> @@ -160,6 +181,55 @@ ValidateGICDSystemVectorBase (
>}
>  }
> 
> +/**
> +  This function validates the SPE Overflow Interrupt in the GICC.
> +
> +  @param [in] Ptr Pointer to the start of the field data.
> +  @param [in] Context Pointer to context specific information e.g. this
> +  could be a pointer to the ACPI table header.
> +**/
> +STATIC
> +VOID
> +EFIAPI
> +ValidateSpeOverflowInterrupt (
> +  IN UINT8* Ptr,
> +  IN VOID*  Context
> +  )
> +{
> +  UINT16 SpeOverflowInterrupt;
> +
> +  SpeOverflowInterrupt = *(UINT16*)Ptr;
> +
> +  // SPE not supported by this processor  if 

Re: [edk2-devel] [PATCH v1 2/2] ShellPkg: acpiview: Update SRAT parser to ACPI 6.3

[Carsey, Jaben]

Reviewed-by: Jaben Carsey 

I don't have access to a platform with ACPI 6.3 to do a test.  Can someone do a 
test and respond with tested-by if possible?

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Krzysztof Koch
> Sent: Wednesday, June 12, 2019 7:11 AM
> To: devel@edk2.groups.io
> Cc: Carsey, Jaben ; Ni, Ray ;
> Gao, Zhichao ; Kinney, Michael D
> ; Gao, Liming ;
> sami.muja...@arm.com; matteo.carl...@arm.com; Stephanie.Hughes-
> f...@arm.com; n...@arm.com
> Subject: [edk2-devel] [PATCH v1 2/2] ShellPkg: acpiview: Update SRAT parser
> to ACPI 6.3
> Importance: High
> 
> Add support for parsing revision 3 of System Resource Affinity Table
> (SRAT).
> 
> Decode and dump the new Generic Initiator Affinity Structure.
> 
> Validate the Device Handle Type field inside the Generic Initiator
> Affinity Structure.
> 
> Signed-off-by: Krzysztof Koch 
> ---
> 
> Changes can be seen at:
> https://github.com/KrzysztofKoch1/edk2/tree/582_acpiview_6_3_srat_v1
> 
> Notes:
> v1:
> - dump and validate the Generic Initiator Affinity Struct [Krzysztof]
> 
>  ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c  |  35
> ++-
>  ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h  |  16 
> ++
>  ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c |
> 256 +++-
>  3 files changed, 299 insertions(+), 8 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
> index
> b5965507b498b9fa9bc4d3124b2285f509004c4f..60523936732f901317ee93d03f
> e06df1403f3695 100644
> --- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
> +++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
> @@ -1,7 +1,7 @@
>  /** @file
>ACPI parser
> 
> -  Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
> +  Copyright (c) 2016 - 2019, ARM Limited. All rights reserved.
>SPDX-License-Identifier: BSD-2-Clause-Patent
>  **/
> 
> @@ -401,6 +401,39 @@ Dump8Chars (
>  );
>  }
> 
> +/**
> +  This function traces 12 characters which can be optionally
> +  formated using the format string if specified.
> +
> +  If no format string is specified the Format must be NULL.
> +
> +  @param [in] Format  Optional format string for tracing the data.
> +  @param [in] Ptr Pointer to the start of the buffer.
> +**/
> +VOID
> +EFIAPI
> +Dump12Chars (
> +  IN CONST CHAR16* Format OPTIONAL,
> +  IN   UINT8*  Ptr
> +  )
> +{
> +  Print (
> +(Format != NULL) ? Format : L"%c%c%c%c%c%c%c%c%c%c%c%c",
> +Ptr[0],
> +Ptr[1],
> +Ptr[2],
> +Ptr[3],
> +Ptr[4],
> +Ptr[5],
> +Ptr[6],
> +Ptr[7],
> +Ptr[8],
> +Ptr[9],
> +Ptr[10],
> +Ptr[11]
> +);
> +}
> +
>  /**
>This function indents and prints the ACPI table Field Name.
> 
> diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
> index
> 7657892d9fd2e2e14c6578611ff0cf1b6f6cd750..5b23ab6fa9bd2f87e034728787
> 2685a2f74622f3 100644
> --- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
> +++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
> @@ -184,6 +184,22 @@ Dump8Chars (
>IN UINT8*Ptr
>);
> 
> +/**
> +  This function traces 12 characters which can be optionally
> +  formated using the format string if specified.
> +
> +  If no format string is specified the Format must be NULL.
> +
> +  @param [in] Format  Optional format string for tracing the data.
> +  @param [in] Ptr Pointer to the start of the buffer.
> +**/
> +VOID
> +EFIAPI
> +Dump12Chars (
> +  IN CONST CHAR16* Format OPTIONAL,
> +  IN   UINT8*  Ptr
> +  );
> +
>  /**
>This function indents and prints the ACPI table Field Name.
> 
> diff --git
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c
> index
> 075ff2a141a82b522e8aaedb7ad79249aaf5eaac..8c268a11454d13c9e278691d6
> 19a580c4c14c08e 100644
> ---
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c
> +++
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c
> @@ -1,11 +1,11 @@
>  /** @file
>SRAT table parser
> 
> -  Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
> +  Copyright (c) 2016 - 2019, ARM Limited. All rights reserved.
>SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>@par Reference(s):
> -- ACPI 6.2 Specification - Errata A, September 2017
> +- ACPI 6.3 Specification - January 2019
>  **/
> 
>  #include 
> @@ -17,6 +17,7 @@
>  // Local Variables
>  STATIC CONST UINT8* SratRAType;
>  STATIC CONST UINT8* SratRALength;
> +STATIC CONST UINT8* SratDeviceHandleType;
>  STATIC ACPI_DESCRIPTION_HEADER_INFO AcpiHdrInfo;
> 
>  /**
> @@ -34,6 +35,51 @@ ValidateSratReserved (
>IN VOID*  Context
>);

[edk2-devel] [edk2-test][PATCH v1 4/5] SctLib: Remove Ipf source files

[Supreeth Venkatesh]

Remove all files required for building Ipf Sct library as edk2
(edk2-stable201905) has removed IPF support.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Supreeth Venkatesh 
---
 uefi-sct/SctPkg/Library/SctLib/Ipf/PalApi.h   | 138 
 uefi-sct/SctPkg/Library/SctLib/Ipf/SalApi.h   | 728 --
 .../SctPkg/Library/SctLib/Ipf/SctLibPlat.h|  32 -
 uefi-sct/SctPkg/Library/SctLib/Ipf/initplat.c |  37 -
 .../SctPkg/Library/SctLib/Ipf/libsalpal.h |  87 ---
 uefi-sct/SctPkg/Library/SctLib/Ipf/salpal.c   | 297 ---
 6 files changed, 1319 deletions(-)
 delete mode 100644 uefi-sct/SctPkg/Library/SctLib/Ipf/PalApi.h
 delete mode 100644 uefi-sct/SctPkg/Library/SctLib/Ipf/SalApi.h
 delete mode 100644 uefi-sct/SctPkg/Library/SctLib/Ipf/SctLibPlat.h
 delete mode 100644 uefi-sct/SctPkg/Library/SctLib/Ipf/initplat.c
 delete mode 100644 uefi-sct/SctPkg/Library/SctLib/Ipf/libsalpal.h
 delete mode 100644 uefi-sct/SctPkg/Library/SctLib/Ipf/salpal.c

diff --git a/uefi-sct/SctPkg/Library/SctLib/Ipf/PalApi.h 
b/uefi-sct/SctPkg/Library/SctLib/Ipf/PalApi.h
deleted file mode 100644
index 4b21ffb7..
--- a/uefi-sct/SctPkg/Library/SctLib/Ipf/PalApi.h
+++ /dev/null
@@ -1,138 +0,0 @@
-/** @file
-
-  Copyright 2006 - 2010 Unified EFI, Inc.
-  Copyright (c) 2010, Intel Corporation. All rights reserved.
-
-  This program and the accompanying materials
-  are licensed and made available under the terms and conditions of the BSD 
License
-  which accompanies this distribution.  The full text of the license may be 
found at 
-  http://opensource.org/licenses/bsd-license.php
- 
-  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
- 
-**/
-/*++
-
-Module Name:
-
-  PalApi.h
-
-Abstract:
-
-  Main PAL API's defined in PAL specification. 
-
-
-Revision History:
-
---*/
-
-#ifndef _PALPROC_H
-#define _PALPROC_H
-
-//#include "Tiano.h"
-
-#define PAL_CACHE_FLUSH   0x0001
-#define PAL_CACHE_INFO0x0002
-#define PAL_CACHE_INIT0x0003
-#define PAL_CACHE_SUMMARY 0x0004
-#define PAL_MEM_ATTRIB0x0005
-#define PAL_PTCE_INFO 0x0006
-#define PAL_VM_INFO   0x0007
-#define PAL_VM_SUMMARY0x0008
-#define PAL_BUS_GET_FEATURES  0x0009
-#define PAL_BUS_SET_FEATURES  0x000a
-#define PAL_DEBUG_INFO0x000b
-#define PAL_FIXED_ADDR0x000c
-#define PAL_FREQ_BASE 0x000d
-#define PAL_FREQ_RATIOS   0x000e
-#define PAL_PERF_MON_INFO 0x000f
-#define PAL_PLATFORM_ADDR 0x0010
-#define PAL_PROC_GET_FEATURES 0x0011
-#define PAL_PROC_SET_FEATURES 0x0012
-#define PAL_RSE_INFO  0x0013
-#define PAL_VERSION   0x0014
-
-#define PAL_MC_CLEAR_LOG  0x0015
-#define PAL_MC_DRAIN  0x0016
-#define PAL_MC_EXPECTED   0x0017
-#define PAL_MC_DYNAMIC_STATE  0x0018
-#define PAL_MC_ERROR_INFO 0x0019
-#define PAL_MC_RESUME 0x001a
-#define PAL_MC_REGISTER_MEM   0x001b
-#define PAL_HALT  0x001c
-#define PAL_HALT_LIGHT0x001d
-#define PAL_COPY_INFO 0x001e
-#define PAL_SHUTDOWN  0x002c
-#define PAL_AUTH  0x0209
-#define PAL_SINGL_DISPERSAL   0x0226  // dec. 550
-#define PAL_HALT_INFO 0x0101
-#define PAL_CACHE_LINE_INIT   0x001f
-#define PAL_PMI_ENTRYPOINT0x0020
-#define PAL_ENTER_IA_32_ENV   0x0021
-#define PAL_VM_PAGE_SIZE  0x0022
-#define PAL_MEM_FOR_TEST  0x0025
-#define PAL_CACHE_PROT_INFO   0x0026
-
-#define PAL_COPY_PAL  0x0100
-#define PAL_CACHE_READ0x0103
-#define PAL_CACHE_WRITE   0x0104
-#define PAL_TEST_PROC 0x0102
-
-#define PAL_DEBUG_FEATURE 0x0063  // vp1
-typedef UINT64  EFI_PAL_STATUS;
-
-//
-//  Return values from PAL
-//
-typedef struct {
-  EFI_PAL_STATUS  Status; // register r8
-  UINT64  r9;
-  UINT64  r10;
-  UINT64  r11;
-} PAL_RETURN_REGS;
-
-//
-// PAL equates for other parameters.
-//
-#define PAL_SUCCESS 0x0
-#define PAL_CALL_ERROR  0xfffd
-#define PAL_CALL_UNIMPLEMENTED  0x
-#define PAL_CACHE_TYPE_I0x1
-#define PAL_CACHE_TYPE_D0x2
-#define PAL_CACHE_TYPE_I_AND_D  0x3
-#define PAL_CACHE_NO_INT0x0
-#define PAL_CACHE_INT   0x2
-//
-// #define PAL_CACHE_PLAT_ACK  0x4
-//
-#define PAL_CACHE_NO_PLAT_ACK   0x0
-#define PAL_CACHE_INVALIDATE0x1
-#define PAL_CACHE_NO_INVALIDATE 0x0
-#define PAL_CACHE_ALL_LEVELS- 0x1
-
-#define PAL_FEATURE_ENABLE  0x1
-#define PAL_ENABLE_BERR_BIT 63
-#define PAL_ENABLE_MCA_BINIT_BIT61
-#define PAL_ENABLE_CMCI_MCA_BIT 60
-#define PAL_CACHE_DISABLE_BIT   59
-#define PAL_DISABLE_COHERENCY_BIT   58
-
-#define PAL_DIS_BUS_DATA_ERR_CHECK_BIT  63
-#define PAL_DIS_BUS_ADDR_ERR_CHECK_BIT  61
-#define 

[edk2-devel] [edk2-test][PATCH v1 5/5] EasLib: Remove files required for building Ipf

[Supreeth Venkatesh]

Remove all files required for building Ipf Eas library as edk2
(edk2-stable201905) has removed IPF support.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Supreeth Venkatesh 
---
 .../Framework/ENTS/EasLib/Ipf/EntsLibPlat.h   |  55 --
 .../SCT/Framework/ENTS/EasLib/Ipf/InitPlat.c  |  54 --
 .../SCT/Framework/ENTS/EasLib/Ipf/LibSalPal.h | 182 -
 .../SCT/Framework/ENTS/EasLib/Ipf/PalApi.h| 137 
 .../SCT/Framework/ENTS/EasLib/Ipf/SalApi.h| 728 --
 .../SCT/Framework/ENTS/EasLib/Ipf/SalPal.c| 369 -
 6 files changed, 1525 deletions(-)
 delete mode 100644 
uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Ipf/EntsLibPlat.h
 delete mode 100644 
uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Ipf/InitPlat.c
 delete mode 100644 
uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Ipf/LibSalPal.h
 delete mode 100644 
uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Ipf/PalApi.h
 delete mode 100644 
uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Ipf/SalApi.h
 delete mode 100644 
uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Ipf/SalPal.c

diff --git 
a/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Ipf/EntsLibPlat.h
 
b/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Ipf/EntsLibPlat.h
deleted file mode 100644
index f0060614..
--- 
a/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Ipf/EntsLibPlat.h
+++ /dev/null
@@ -1,55 +0,0 @@
-/** @file
-
-  Copyright 2006 - 2010 Unified EFI, Inc.
-  Copyright (c) 2010, Intel Corporation. All rights reserved.
-
-  This program and the accompanying materials
-  are licensed and made available under the terms and conditions of the BSD 
License
-  which accompanies this distribution.  The full text of the license may be 
found at 
-  http://opensource.org/licenses/bsd-license.php
- 
-  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
- 
-**/
-/*++
-
-Module Name:
-
-  EntsLibPlat.h
-
-Abstract:
-
-  IPF specific defines
-
---*/
-
-#ifndef _EFI_LIB_PLAT_H
-#define _EFI_LIB_PLAT_H
-
-#define MIN_ALIGNMENT_SIZE  8
-
-VOID
-EntsInitializeLibPlatform (
-  IN EFI_HANDLE   ImageHandle,
-  IN EFI_SYSTEM_TABLE *SystemTable
-  )
-/*++
-
-Routine Description:
-
-  Initialize platform.
-
-Arguments:
-
-  ImageHandle   - The image handle.
-  SystemTable   - The system table.
-
-Returns:
-
-  None.
-
---*/
-;
-
-#endif
diff --git 
a/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Ipf/InitPlat.c 
b/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Ipf/InitPlat.c
deleted file mode 100644
index fd62..
--- 
a/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Ipf/InitPlat.c
+++ /dev/null
@@ -1,54 +0,0 @@
-/** @file
-
-  Copyright 2006 - 2010 Unified EFI, Inc.
-  Copyright (c) 2010, Intel Corporation. All rights reserved.
-
-  This program and the accompanying materials
-  are licensed and made available under the terms and conditions of the BSD 
License
-  which accompanies this distribution.  The full text of the license may be 
found at 
-  http://opensource.org/licenses/bsd-license.php
- 
-  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
- 
-**/
-/*++
-
-Module Name:
-
-  InitPlat.c
-
-Abstract:
-
-  Functions to make SAL and PAL proc calls
-
---*/
-
-#include "Efi.h"
-#include "EntsLibPlat.h"
-#include "LibSalPal.h"
-
-VOID
-EntsInitializeLibPlatform (
-  IN EFI_HANDLE   ImageHandle,
-  IN EFI_SYSTEM_TABLE *SystemTable
-  )
-/*++
-
-Routine Description:
-
-  Initialize platform.
-
-Arguments:
-
-  ImageHandle   - The image handle.
-  SystemTable   - The system table.
-
-Returns:
-
-  None.
-
---*/
-{
-  LibInitSalAndPalProc ();
-}
diff --git 
a/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Ipf/LibSalPal.h 
b/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Ipf/LibSalPal.h
deleted file mode 100644
index 78d96d59..
--- 
a/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Ipf/LibSalPal.h
+++ /dev/null
@@ -1,182 +0,0 @@
-/** @file
-
-  Copyright 2006 - 2010 Unified EFI, Inc.
-  Copyright (c) 2010, Intel Corporation. All rights reserved.
-
-  This program and the accompanying materials
-  are licensed and made available under the terms and conditions of the BSD 
License
-  which accompanies this distribution.  The full text of the license may be 
found at 
-  http://opensource.org/licenses/bsd-license.php
- 
-  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
- 
-**/
-/*++
-
-Module Name:
-
-  LibSalPal.h
-
-Abstract:
-
-  Function prototype definitions.
-
---*/
-

[edk2-devel] [edk2-test][PATCH v1 3/5] Framework/EntsLib: Remove Ipf source files from inf file

[Supreeth Venkatesh]

Remove source and header files required for building Ipf library from
inf file as edk2 (edk2-stable201905) has removed IPF support.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Supreeth Venkatesh 
---
 .../SCT/Framework/ENTS/EasLib/EntsLib.inf  | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/EntsLib.inf 
b/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/EntsLib.inf
index c38c620a..23f12d1a 100644
--- a/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/EntsLib.inf
+++ b/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/EntsLib.inf
@@ -2,6 +2,7 @@
 #
 #  Copyright 2006 - 2012 Unified EFI, Inc.
 #  Copyright (c) 2010 - 2012, Intel Corporation. All rights reserved.
+#  Copyright (c) 2019, ARM Ltd. All rights reserved.
 #
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
@@ -49,12 +50,6 @@
   Ia32/EntsLibPlat.h
   Ia32/InitPlat.c
 
-[sources.ipf]
-  Ipf/EntsLibPlat.h
-  Ipf/InitPlat.c
-  Ipf/SalPal.c
-  Ipf/LibSalPal.h
-
 [sources.ebc]
   Ebc/EntsLibPlat.h
   Ebc/EfiLibPlat.c
-- 
2.17.1


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

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

[edk2-devel] [edk2-test][PATCH v1 1/5] Library/EntsLib: Remove references to SalSystemTable

[Supreeth Venkatesh]

Remove references to SalSystemTable and gtEfiSalSystemTableGuid as edk2
(edk2-stable201905) has removed IPF support.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Supreeth Venkatesh 
---
 uefi-sct/SctPkg/Include/Library/EntsLib.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/uefi-sct/SctPkg/Include/Library/EntsLib.h 
b/uefi-sct/SctPkg/Include/Library/EntsLib.h
index f7c03cf5..f29779c0 100644
--- a/uefi-sct/SctPkg/Include/Library/EntsLib.h
+++ b/uefi-sct/SctPkg/Include/Library/EntsLib.h
@@ -2,6 +2,7 @@
 
   Copyright 2006 - 2013 Unified EFI, Inc.
   Copyright (c) 2010 - 2013, Intel Corporation. All rights reserved.
+  Copyright (c) 2019, ARM Ltd. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -69,7 +70,6 @@ Abstract:
 #include EFI_GUID_DEFINITION (Mps)
 #include EFI_GUID_DEFINITION (Acpi)
 #include EFI_GUID_DEFINITION (SmBios)
-#include EFI_GUID_DEFINITION (SalSystemTable)
 
 extern EFI_GUID gtEfiDevicePathProtocolGuid;
 extern EFI_GUID gtEfiLoadedImageProtocolGuid;
@@ -109,7 +109,6 @@ extern EFI_GUID gtEfiMpsTableGuid;
 extern EFI_GUID gtEfiAcpiTableGuid;
 extern EFI_GUID gtEfiAcpi20TableGuid;
 extern EFI_GUID gtEfiSMBIOSTableGuid;
-extern EFI_GUID gtEfiSalSystemTableGuid;
 
 //
 // Public read-only data in the EFI library
-- 
2.17.1


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

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

[edk2-devel] [edk2-test][PATCH v1 2/5] Framework/ENTS: Remove reference to gtEfiSalSystemTableGuid

[Supreeth Venkatesh]

Remove references to gtEfiSalSystemTableGuid as edk2 (edk2-stable201905)
has removed IPF support.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Supreeth Venkatesh 
---
 .../TestInfrastructure/SCT/Framework/ENTS/EasLib/EntsLib.c  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/EntsLib.c 
b/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/EntsLib.c
index 8c6c8c1d..63ca38f8 100644
--- a/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/EntsLib.c
+++ b/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/EntsLib.c
@@ -2,6 +2,7 @@
 
   Copyright 2006 - 2015 Unified EFI, Inc.
   Copyright (c) 2010 - 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2019, ARM Ltd. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -118,7 +119,6 @@ EFI_GUIDgtEfiMpsTableGuid   = 
EFI_MPS_TABLE_GUID;
 EFI_GUIDgtEfiAcpiTableGuid  = EFI_ACPI_TABLE_GUID;
 EFI_GUIDgtEfiAcpi20TableGuid= 
EFI_ACPI_20_TABLE_GUID;
 EFI_GUIDgtEfiSMBIOSTableGuid= 
EFI_SMBIOS_TABLE_GUID;
-EFI_GUIDgtEfiSalSystemTableGuid = 
EFI_SAL_SYSTEM_TABLE_GUID;
 
 EFI_HANDLE  mImageHandle= NULL;
 EFI_DEVICE_PATH_PROTOCOL*gntDevicePath  = NULL;
-- 
2.17.1


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

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

Re: [edk2-devel] [BIKESHEDDING-TARGET] BaseTools: add GetMaintainer.py helper script

[Leif Lindholm]

On Wed, Jun 12, 2019 at 03:27:15PM +0200, Laszlo Ersek wrote:
> On 06/12/19 13:19, Leif Lindholm wrote:
> > This is work-in-progress, but I figured it would be a good time to start
> > having a conversation about how we want it to work.
> > 
> > The script currently does nothing clever whatsoever with regards to
> > looking at historical contributors to the modified code - it only
> > performs a lookup in Maintainers.txt.
> 
> I think that's good enough.
> 
> > Known shortcomings:
> > - Does not provide any metainformation about why certain people
> >   or mailing lists were picked.
> > - Does not reason about precedence of sections - all maintainers
> >   for all sections that match a wildcard are returned.
> > - Does not substantially update Maintainers.txt.
> > - Does not implement the X: tag, to explicitly exclude subpaths.
> >   (But scans for it.)
> 
> All of the above should be fine, for a start.
> 
> > - The splitting of Maintainers.txt into sections is based on
> >   directly adjacent lines starting with a valid tag (so I expect
> >   Star is left out from MdeModulePkg hits, and OvmfPkg loses most
> >   of its Reviewers. (My feeling is this is valid, and Maintainers.txt
> >   should change - certainly all the problematic lines would become
> >   redundant with this format change.)
> 
> I agree -- but then, Maintainers.txt should be updated in the same
> *series* (not patch) just enough to preserve all those R: roles.

Yes. I just didn't want to juggle a series before I even get to RFC.

> > Supported wildcards are '*' and '?' - there is no special treatment of
> > trailing '/' at this point.
> 
> That should be fine. QEMU supports:
> 
> F: Files and directories with wildcard patterns.
>A trailing slash includes all files and subdirectory files.
>F:   drivers/net/all files in and below drivers/net
>F:   drivers/net/*   all files in drivers/net, but not below
>F:   */net/* all files in "any top level directory"/net
>One pattern per line.  Multiple F: lines acceptable.
> 
> and I don't think we *need* to distinguish the first two cases from
> each other (I don't see much use for "but not below" ATM).
> 
> However, that distinction might work out of the box, due to another
> comment I'd like to make below.
> 
> > 
> > Oh, and like 'SetupGit.py', it requires the gitpython module.
> > 
> > Laszlo: if you could provide some english language description of how
> > the path (F:) format is supposed to work, and how you think section
> > precedence should happen, I can implement that.
> 
> Section precedence would be a much later feature (if we cared at all).

Right. After your explanation below, I'm starting to suspect that the
reason I couldn't figure out where QEMU's get_maintainer.pl did that
is that it doesn't. I had misunderstood the format. This simplifies
the remaining work.

> English language description for "F:" -- I can only quote QEMU's description.
> 
> > The qemu MAINTAINERS file does not contain this information, and my
> > perl knowledge is rustier than my python knowledge is incomplete.
> > 
> > Signed-off-by: Leif Lindholm 
> > ---
> >  BaseTools/Scripts/GetMaintainer.py | 131 
> > +
> >  Maintainers.txt|  38 +++
> >  2 files changed, 169 insertions(+)
> >  create mode 100644 BaseTools/Scripts/GetMaintainer.py
> > 
> > diff --git a/BaseTools/Scripts/GetMaintainer.py 
> > b/BaseTools/Scripts/GetMaintainer.py
> > new file mode 100644
> > index 00..939930b052
> > --- /dev/null
> > +++ b/BaseTools/Scripts/GetMaintainer.py
> > @@ -0,0 +1,131 @@
> > +## @file
> > +#  Retrieves the people to request review from on submission of a commit.
> > +#
> > +#  Copyright (c) 2019, Linaro Ltd. All rights reserved.
> > +#
> > +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> > +#
> > +
> > +from __future__ import print_function
> > +from collections import defaultdict
> > +from collections import OrderedDict
> > +import argparse
> > +import os
> > +import re
> > +import SetupGit
> > +
> > +EXPRESSIONS = {
> > +'exclude':re.compile(r'^X:\s*(?P.*?)\r*$'),
> > +'file':   re.compile(r'^F:\s*(?P.*?)\r*$'),
> > +'list':   re.compile(r'^L:\s*(?P.*?)\r*$'),
> > +'maintainer': re.compile(r'^M:\s*(?P.*<.*?>)\r*$'),
> > +'reviewer':   re.compile(r'^R:\s*(?P.*?)\r*$'),
> > +'status': re.compile(r'^S:\s*(?P.*?)\r*$'),
> > +'tree':   re.compile(r'^T:\s*(?P.*?)\r*$'),
> > +'webpage':re.compile(r'^W:\s*(?P.*?)\r*$')
> > +}
> > +
> > +def printsection(section):
> > +"""Prints out the dictionary describing a Maintainers.txt section."""
> > +print('===')
> > +for key in section.keys():
> > +print("Key: %s" % key)
> > +for item in section[key]:
> > +print('  %s' % item)
> > +
> > +def pattern_to_regex(pattern):
> > +"""Takes a string containing regular UNIX path wildcards
> > + 

Re: [edk2-devel] [edk2-test] [tianocore/edk2-test] Add Firmware Management Protocol and HII Config Access Protocol into IHVSCT. (#3)

[Supreeth Venkatesh]

Hello Shrishail,

Pull requests is no longer the way to get your change request into the new 
edk2-test repo.
Please send in “git format-patch” style patches to the 
devel@edk2.groups.io with the subject line 
containing [edk2-test].

Thanks,
Supreeth


From: shrishailp 
Sent: Sunday, May 26, 2019 11:05 PM
To: tianocore/edk2-test 
Cc: Subscribed 
Subject: [tianocore/edk2-test] Add Firmware Management Protocol and HII Config 
Access Protocol into IHVSCT. (#3)


Add Firmware Management Protocol and HII Config Access Protocol into IHVSCT.

Change-Id:
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Shrishail B Patil 
shrishail.pa...@microchip.com
Reviewed-by:


You can view, comment on, or merge this pull request online at:

  https://github.com/tianocore/edk2-test/pull/3

Commit Summary

  *   Adding FMP and HII Config Access protocol into IHVSCT

File Changes

  *   M 
uefi-sct/SctPkg/CommonGenFramework.bat
 (3)
  *   M 
uefi-sct/SctPkg/CommonGenFramework.sh
 (3)
  *   A 
uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/FirmwareManagement/BlackBoxTest/FirmwareManagementBBTestConformance.c
 (3632)
  *   A 
uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/FirmwareManagement/BlackBoxTest/FirmwareManagementBBTestFunction.c
 (891)
  *   A 
uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/FirmwareManagement/BlackBoxTest/FirmwareManagementBBTestMain.c
 (228)
  *   A 
uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/FirmwareManagement/BlackBoxTest/FirmwareManagementBBTestMain.h
 (223)
  *   A 
uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/FirmwareManagement/BlackBoxTest/Guid.c
 (63)
  *   A 
uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/FirmwareManagement/BlackBoxTest/Guid.h
 (153)
  *   A 
uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/FirmwareManagement/BlackBoxTest/IhvFirmwareManagementBBTest.inf
 (52)
  *   A 
uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/HIIConfigAccess/BlackBoxTest/Guid.c
 (46)
  *   A 
uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/HIIConfigAccess/BlackBoxTest/Guid.h
 (109)
  *   A 
uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/HIIConfigAccess/BlackBoxTest/HIIConfigAccessBBTestConformance.c
 (908)
  *   A 
uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/HIIConfigAccess/BlackBoxTest/HIIConfigAccessBBTestFunction.c
 (606)
  *   A 
uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/HIIConfigAccess/BlackBoxTest/HIIConfigAccessBBTestMain.c
 (655)
  *   A 
uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/HIIConfigAccess/BlackBoxTest/HIIConfigAccessBBTestMain.h
 (168)
  *   A 
uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/HIIConfigAccess/BlackBoxTest/IhvHIIConfigAccessBBTest.inf
 (55)
  *   M 
uefi-sct/SctPkg/UEFI/IHV_SCT.dsc
 (2)

Patch Links:

  *   https://github.com/tianocore/edk2-test/pull/3.patch
  *   https://github.com/tianocore/edk2-test/pull/3.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on 
GitHub,
 or mute the 
thread.

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.

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

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

[edk2-devel] [PATCH v1 0/2] Update the SRAT Acpiview parser to ACPI 6.3

[Krzysztof Koch]

This patch adds a number of definitions to the ACPI 6.3 header file for
the purpose of parsing Revision 3 of the System Resource Affinity Table
(SRAT) in the Acpiview UEFI shell tool.

By defining the Generic Initiator Affinity Structure's Type ID and the
allowed Device Handle Types for the structure, it is possible to dump
and validate the contents of the latest version of the SRAT table in
acpiview.

References:
- ACPI 6.3 January 2019, Section 5.2.16.6

Changes can be seen at: 
https://github.com/KrzysztofKoch1/edk2/tree/582_acpiview_6_3_srat_v1

Krzysztof Koch (2):
  MdePkg: Add Generic Initiator Affinity Structure definitions to SRAT
  ShellPkg: acpiview: Update SRAT parser to ACPI 6.3

 MdePkg/Include/IndustryStandard/Acpi63.h   |  11 +-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c  |  35 
++-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h  |  16 ++
 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c | 256 
+++-
 4 files changed, 309 insertions(+), 9 deletions(-)

--
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'



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

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

Re: [edk2-devel] [PATCH] CryptoPkg: Add lacking instances for build only

[Wang, Jian J]

With the wording/spelling addressed (see Laszlo's comment,
https://edk2.groups.io/g/devel/message/42273),

Reviewed-by: Jian J Wang 

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Gao,
> Zhichao
> Sent: Wednesday, June 12, 2019 10:40 AM
> To: devel@edk2.groups.io
> Cc: Bret Barkelew ; Wang, Jian J
> ; Ye, Ting ; Gao, Liming
> ; Sean Brogan ; Michael
> Turner 
> Subject: [edk2-devel] [PATCH] CryptoPkg: Add lacking instances for build only
> 
> From: Bret Barkelew 
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1900
> 
> Add the lacking instance to [Componnets] of dsc file
> for build only.
> 
> Cc: Jian Wang 
> Cc: Ting Ye 
> Cc: Liming Gao 
> Cc: Sean Brogan 
> Cc: Michael Turner 
> Cc: Bret Barkelew 
> Signed-off-by: Zhichao Gao 
> ---
>  CryptoPkg/CryptoPkg.dsc | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/CryptoPkg/CryptoPkg.dsc b/CryptoPkg/CryptoPkg.dsc
> index 9dfa349f6d..c90e76c721 100644
> --- a/CryptoPkg/CryptoPkg.dsc
> +++ b/CryptoPkg/CryptoPkg.dsc
> @@ -116,6 +116,7 @@
>CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
>CryptoPkg/Library/TlsLib/TlsLib.inf
>CryptoPkg/Library/OpensslLib/OpensslLib.inf
> +  CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
> 
>  [Components.IA32, Components.X64]
>CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
> --
> 2.21.0.windows.1
> 
> 
> 


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

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

Re: [edk2-devel] EDK II Stable Tag release edk2-stable201905 completed

[Leif Lindholm]

Hi Liming,

On Wed, Jun 12, 2019 at 01:30:23PM +, Gao, Liming wrote:
> > > What I am saying is:
> > > - We should have a policy (i.e., a section in toplevel Readme.md)
> > >   regarding submodules.
> > >   - That policy *should* include the requirement to not permit
> > > submodules requiring submodules for our purposes.
> > >   - That policy should include the steps required to get the edk2
> > > repository to a buildable state.
> > >   - Nothing related to submodules should be documented anywhere else
> > > in the tree. Sure, OpenSSL-HOWTO.txt can still be there, but
> > > the section "HOW to Install OpenSSL for UEFI Building" should go.
> > 
> > Got it now. Good idea.
> 
> Can you submit one BZ for it? I think CryptoPkg maintain should list
> the clear usage of openssl.

I have raised https://bugzilla.tianocore.org/show_bug.cgi?id=1910.

Regards,

Leif

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

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

[edk2-devel] [PATCH v1 2/2] ShellPkg: acpiview: Update SRAT parser to ACPI 6.3

[Krzysztof Koch]

Add support for parsing revision 3 of System Resource Affinity Table
(SRAT).

Decode and dump the new Generic Initiator Affinity Structure.

Validate the Device Handle Type field inside the Generic Initiator
Affinity Structure.

Signed-off-by: Krzysztof Koch 
---

Changes can be seen at: 
https://github.com/KrzysztofKoch1/edk2/tree/582_acpiview_6_3_srat_v1

Notes:
v1:
- dump and validate the Generic Initiator Affinity Struct [Krzysztof]

 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c  |  35 
++-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h  |  16 ++
 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c | 256 
+++-
 3 files changed, 299 insertions(+), 8 deletions(-)

diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
index 
b5965507b498b9fa9bc4d3124b2285f509004c4f..60523936732f901317ee93d03fe06df1403f3695
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
@@ -1,7 +1,7 @@
 /** @file
   ACPI parser
 
-  Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
+  Copyright (c) 2016 - 2019, ARM Limited. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 **/
 
@@ -401,6 +401,39 @@ Dump8Chars (
 );
 }
 
+/**
+  This function traces 12 characters which can be optionally
+  formated using the format string if specified.
+
+  If no format string is specified the Format must be NULL.
+
+  @param [in] Format  Optional format string for tracing the data.
+  @param [in] Ptr Pointer to the start of the buffer.
+**/
+VOID
+EFIAPI
+Dump12Chars (
+  IN CONST CHAR16* Format OPTIONAL,
+  IN   UINT8*  Ptr
+  )
+{
+  Print (
+(Format != NULL) ? Format : L"%c%c%c%c%c%c%c%c%c%c%c%c",
+Ptr[0],
+Ptr[1],
+Ptr[2],
+Ptr[3],
+Ptr[4],
+Ptr[5],
+Ptr[6],
+Ptr[7],
+Ptr[8],
+Ptr[9],
+Ptr[10],
+Ptr[11]
+);
+}
+
 /**
   This function indents and prints the ACPI table Field Name.
 
diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
index 
7657892d9fd2e2e14c6578611ff0cf1b6f6cd750..5b23ab6fa9bd2f87e0347287872685a2f74622f3
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
@@ -184,6 +184,22 @@ Dump8Chars (
   IN UINT8*Ptr
   );
 
+/**
+  This function traces 12 characters which can be optionally
+  formated using the format string if specified.
+
+  If no format string is specified the Format must be NULL.
+
+  @param [in] Format  Optional format string for tracing the data.
+  @param [in] Ptr Pointer to the start of the buffer.
+**/
+VOID
+EFIAPI
+Dump12Chars (
+  IN CONST CHAR16* Format OPTIONAL,
+  IN   UINT8*  Ptr
+  );
+
 /**
   This function indents and prints the ACPI table Field Name.
 
diff --git 
a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c
index 
075ff2a141a82b522e8aaedb7ad79249aaf5eaac..8c268a11454d13c9e278691d619a580c4c14c08e
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c
@@ -1,11 +1,11 @@
 /** @file
   SRAT table parser
 
-  Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
+  Copyright (c) 2016 - 2019, ARM Limited. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
   @par Reference(s):
-- ACPI 6.2 Specification - Errata A, September 2017
+- ACPI 6.3 Specification - January 2019
 **/
 
 #include 
@@ -17,6 +17,7 @@
 // Local Variables
 STATIC CONST UINT8* SratRAType;
 STATIC CONST UINT8* SratRALength;
+STATIC CONST UINT8* SratDeviceHandleType;
 STATIC ACPI_DESCRIPTION_HEADER_INFO AcpiHdrInfo;
 
 /**
@@ -34,6 +35,51 @@ ValidateSratReserved (
   IN VOID*  Context
   );
 
+/**
+  This function validates the Device Handle Type field in the Generic Initiator
+  Affinity Structure.
+
+  @param [in] Ptr Pointer to the start of the field data.
+  @param [in] Context Pointer to context specific information e.g. this
+  could be a pointer to the ACPI table header.
+**/
+STATIC
+VOID
+EFIAPI
+ValidateSratDeviceHandleType (
+  IN UINT8* Ptr,
+  IN VOID*  Context
+  );
+
+/**
+  This function traces the Device Handle field inside Generic Initiator
+  Affinity Structure.
+
+  @param [in] Format  Format string for tracing the data.
+  @param [in] Ptr Pointer to the start of the buffer.
+**/
+STATIC
+VOID
+EFIAPI
+DumpSratDeviceHandle (
+  IN CONST CHAR16* Format,
+  IN   UINT8*  Ptr
+  );
+
+/**
+  This function traces the PCI BDF Number field inside Device Handle - PCI
+
+  @param [in] Format  Format string for tracing the data.
+  @param 

[edk2-devel] [PATCH v1 0/2] Update the SRAT Acpiview parser to ACPI 6.3

[Krzysztof Koch]

This patch adds a number of definitions to the ACPI 6.3 header file for
the purpose of parsing Revision 3 of the System Resource Affinity Table
(SRAT) in the Acpiview UEFI shell tool.

By defining the Generic Initiator Affinity Structure's Type ID and the
allowed Device Handle Types for the structure, it is possible to dump
and validate the contents of the latest version of the SRAT table in
acpiview.

References:
- ACPI 6.3 January 2019, Section 5.2.16.6

Changes can be seen at: 
https://github.com/KrzysztofKoch1/edk2/tree/582_acpiview_6_3_srat_v1

Krzysztof Koch (2):
  MdePkg: Add Generic Initiator Affinity Structure definitions to SRAT
  ShellPkg: acpiview: Update SRAT parser to ACPI 6.3

 MdePkg/Include/IndustryStandard/Acpi63.h   |  11 +-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c  |  35 
++-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h  |  16 ++
 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c | 256 
+++-
 4 files changed, 309 insertions(+), 9 deletions(-)

--
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'



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

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

Re: [edk2-devel] UEFI SCT Build Broken

[Ashish Singhal]

Hi Eric,

That's right. I meant the latest tag in my email. Thanks for updating this in 
the bug I filed as well.

Thanks
Ashish

From: Jin, Eric 
Sent: Wednesday, June 12, 2019 3:18 AM
To: Ashish Singhal; Supreeth Venkatesh; devel@edk2.groups.io
Cc: Jin, Eric
Subject: RE: UEFI SCT Build Broken


Hi Ashish,



Thank for raising this issue.

UEFI SCT build pass with edk2-stable201903, and fail on edk2-stable201905, 
because edk2 drop the IPF support (4e1daa60f5372c22a11503961061ffa569eaf873).

UEFI SCT can remove IPF support too. I can follow it tomorrow. Thanks.





Best Regards

Eric



From: Ashish Singhal 
Sent: Wednesday, June 12, 2019 4:26 AM
To: Supreeth Venkatesh ; Jin, Eric 
; devel@edk2.groups.io
Subject: Re: UEFI SCT Build Broken



Supreeth,



It is broken against both edk2 tip as well as latest edk2 tag edk2-stable201903.



I have filed a bugzilla 
bug for the same.



Thanks

Ashish



From: Supreeth Venkatesh 
mailto:supreeth.venkat...@arm.com>>
Sent: Tuesday, June 11, 2019 1:36 PM
To: Ashish Singhal; Eric Jin; devel@edk2.groups.io
Subject: RE: UEFI SCT Build Broken



Ashish,



We are working towards fixing the issue for the next SCT tag corresponding to 
edk2 tag.

Can you please let us know whether you are referring to edk2 tip or which edk2 
tag (edk2-stable201903)?



If possible, could you log a bug entry in bugzillafor edk2-test/SCT component?



Thanks,

Supreeth



From: Ashish Singhal mailto:ashishsin...@nvidia.com>>
Sent: Tuesday, June 11, 2019 12:18 PM
To: Supreeth Venkatesh 
mailto:supreeth.venkat...@arm.com>>; Eric Jin 
mailto:eric@intel.com>>; 
devel@edk2.groups.io
Subject: UEFI SCT Build Broken



Hello Eric/Supreeth,



With the latest edk2 tag, UEFI SCT tip build is broken. Seems like it needs 
Guid/SalSystemTable.h header file which is not in edk2 tree any more. Is a fix 
for this already being looked at?



Thanks

Ashish



This email message is for the sole use of the intended recipient(s) and may 
contain confidential information.  Any unauthorized review, use, disclosure or 
distribution is prohibited.  If you are not the intended recipient, please 
contact the sender by reply email and destroy all copies of the original 
message.



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.

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

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

[edk2-devel] [PATCH v1 2/2] ShellPkg: acpiview: Update SRAT parser to ACPI 6.3

[Krzysztof Koch]

Add support for parsing revision 3 of System Resource Affinity Table
(SRAT).

Decode and dump the new Generic Initiator Affinity Structure.

Validate the Device Handle Type field inside the Generic Initiator
Affinity Structure.

Signed-off-by: Krzysztof Koch 
---

Changes can be seen at: 
https://github.com/KrzysztofKoch1/edk2/tree/582_acpiview_6_3_srat_v1

Notes:
v1:
- dump and validate the Generic Initiator Affinity Struct [Krzysztof]

 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c  |  35 
++-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h  |  16 ++
 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c | 256 
+++-
 3 files changed, 299 insertions(+), 8 deletions(-)

diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
index 
b5965507b498b9fa9bc4d3124b2285f509004c4f..60523936732f901317ee93d03fe06df1403f3695
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
@@ -1,7 +1,7 @@
 /** @file
   ACPI parser
 
-  Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
+  Copyright (c) 2016 - 2019, ARM Limited. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 **/
 
@@ -401,6 +401,39 @@ Dump8Chars (
 );
 }
 
+/**
+  This function traces 12 characters which can be optionally
+  formated using the format string if specified.
+
+  If no format string is specified the Format must be NULL.
+
+  @param [in] Format  Optional format string for tracing the data.
+  @param [in] Ptr Pointer to the start of the buffer.
+**/
+VOID
+EFIAPI
+Dump12Chars (
+  IN CONST CHAR16* Format OPTIONAL,
+  IN   UINT8*  Ptr
+  )
+{
+  Print (
+(Format != NULL) ? Format : L"%c%c%c%c%c%c%c%c%c%c%c%c",
+Ptr[0],
+Ptr[1],
+Ptr[2],
+Ptr[3],
+Ptr[4],
+Ptr[5],
+Ptr[6],
+Ptr[7],
+Ptr[8],
+Ptr[9],
+Ptr[10],
+Ptr[11]
+);
+}
+
 /**
   This function indents and prints the ACPI table Field Name.
 
diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
index 
7657892d9fd2e2e14c6578611ff0cf1b6f6cd750..5b23ab6fa9bd2f87e0347287872685a2f74622f3
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
@@ -184,6 +184,22 @@ Dump8Chars (
   IN UINT8*Ptr
   );
 
+/**
+  This function traces 12 characters which can be optionally
+  formated using the format string if specified.
+
+  If no format string is specified the Format must be NULL.
+
+  @param [in] Format  Optional format string for tracing the data.
+  @param [in] Ptr Pointer to the start of the buffer.
+**/
+VOID
+EFIAPI
+Dump12Chars (
+  IN CONST CHAR16* Format OPTIONAL,
+  IN   UINT8*  Ptr
+  );
+
 /**
   This function indents and prints the ACPI table Field Name.
 
diff --git 
a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c
index 
075ff2a141a82b522e8aaedb7ad79249aaf5eaac..8c268a11454d13c9e278691d619a580c4c14c08e
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c
@@ -1,11 +1,11 @@
 /** @file
   SRAT table parser
 
-  Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
+  Copyright (c) 2016 - 2019, ARM Limited. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
   @par Reference(s):
-- ACPI 6.2 Specification - Errata A, September 2017
+- ACPI 6.3 Specification - January 2019
 **/
 
 #include 
@@ -17,6 +17,7 @@
 // Local Variables
 STATIC CONST UINT8* SratRAType;
 STATIC CONST UINT8* SratRALength;
+STATIC CONST UINT8* SratDeviceHandleType;
 STATIC ACPI_DESCRIPTION_HEADER_INFO AcpiHdrInfo;
 
 /**
@@ -34,6 +35,51 @@ ValidateSratReserved (
   IN VOID*  Context
   );
 
+/**
+  This function validates the Device Handle Type field in the Generic Initiator
+  Affinity Structure.
+
+  @param [in] Ptr Pointer to the start of the field data.
+  @param [in] Context Pointer to context specific information e.g. this
+  could be a pointer to the ACPI table header.
+**/
+STATIC
+VOID
+EFIAPI
+ValidateSratDeviceHandleType (
+  IN UINT8* Ptr,
+  IN VOID*  Context
+  );
+
+/**
+  This function traces the Device Handle field inside Generic Initiator
+  Affinity Structure.
+
+  @param [in] Format  Format string for tracing the data.
+  @param [in] Ptr Pointer to the start of the buffer.
+**/
+STATIC
+VOID
+EFIAPI
+DumpSratDeviceHandle (
+  IN CONST CHAR16* Format,
+  IN   UINT8*  Ptr
+  );
+
+/**
+  This function traces the PCI BDF Number field inside Device Handle - PCI
+
+  @param [in] Format  Format string for tracing the data.
+  @param 

[edk2-devel] [PATCH v1 0/2] Update the SRAT Acpiview parser to ACPI 6.3

[Krzysztof Koch]

This patch adds a number of definitions to the ACPI 6.3 header file for
the purpose of parsing Revision 3 of the System Resource Affinity Table
(SRAT) in the Acpiview UEFI shell tool.

By defining the Generic Initiator Affinity Structure's Type ID and the
allowed Device Handle Types for the structure, it is possible to dump
and validate the contents of the latest version of the SRAT table in
acpiview.

References:
- ACPI 6.3 January 2019, Section 5.2.16.6

Changes can be seen at: 
https://github.com/KrzysztofKoch1/edk2/tree/582_acpiview_6_3_srat_v1

Krzysztof Koch (2):
  MdePkg: Add Generic Initiator Affinity Structure definitions to SRAT
  ShellPkg: acpiview: Update SRAT parser to ACPI 6.3

 MdePkg/Include/IndustryStandard/Acpi63.h   |  11 +-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c  |  35 
++-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h  |  16 ++
 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c | 256 
+++-
 4 files changed, 309 insertions(+), 9 deletions(-)

--
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'



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

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

[edk2-devel] [PATCH v1 1/2] MdePkg: Add Generic Initiator Affinity Structure definitions to SRAT

[Krzysztof Koch]

Add Generic Initiator Affinity Structure to the list of recognised
System Resource Affinity Table (SRAT) structure types.

Add definitions for Device Handle Types inside the Generic Initiator
Affinity Structure.

References:
- ACPI 6.3 January 2019, Table 5-78

Signed-off-by: Krzysztof Koch 
---

Changes can be seen at: 
https://github.com/KrzysztofKoch1/edk2/tree/582_acpiview_6_3_srat_v1

Notes:
v1:
- define the SRAT Generic Initiator Affinity Struct type [Krzysztof]
- define the SRAT Device Handle Types [Krzysztof]

 MdePkg/Include/IndustryStandard/Acpi63.h | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/IndustryStandard/Acpi63.h 
b/MdePkg/Include/IndustryStandard/Acpi63.h
index 
a8e011579ffcf070ecdfd2c6726a16d1afd65891..eca1f9357b70f10887e680ff13c97c0beab3600b
 100644
--- a/MdePkg/Include/IndustryStandard/Acpi63.h
+++ b/MdePkg/Include/IndustryStandard/Acpi63.h
@@ -639,7 +639,7 @@ typedef struct {
 
 //
 // SRAT structure types.
-// All other values between 0x05 an 0xFF are reserved and
+// All other values between 0x06 an 0xFF are reserved and
 // will be ignored by OSPM.
 //
 #define EFI_ACPI_6_3_PROCESSOR_LOCAL_APIC_SAPIC_AFFINITY  0x00
@@ -647,6 +647,7 @@ typedef struct {
 #define EFI_ACPI_6_3_PROCESSOR_LOCAL_X2APIC_AFFINITY  0x02
 #define EFI_ACPI_6_3_GICC_AFFINITY0x03
 #define EFI_ACPI_6_3_GIC_ITS_AFFINITY 0x04
+#define EFI_ACPI_6_3_GENERIC_INITIATOR_AFFINITY   0x05
 
 ///
 /// Processor Local APIC/SAPIC Affinity Structure Definition
@@ -733,6 +734,14 @@ typedef struct {
   UINT32  ItsId;
 } EFI_ACPI_6_3_GIC_ITS_AFFINITY_STRUCTURE;
 
+//
+// Generic Initiator Affinity Structure Device Handle Types
+// All other values between 0x02 an 0xFF are reserved and
+// will be ignored by OSPM.
+//
+#define EFI_ACPI_6_3_ACPI_DEVICE_HANDLE 0x00
+#define EFI_ACPI_6_3_PCI_DEVICE_HANDLE  0x01
+
 ///
 /// Device Handle - ACPI
 ///
--
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'



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

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

Re: [edk2-devel] [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency

[Laszlo Ersek]

On 06/12/19 17:15, David Woodhouse wrote:
> On Wed, 2019-06-12 at 13:52 +0200, Laszlo Ersek wrote:
>> (2c) SeaBIOS is built *twice*, once for the CSM, and another time for
>> the Cirrus VGABIOS.
> 
> We shouldn't need to rebuild the VGA BIOS, should we? Any Legacy VGA
> BIOS should work — and indeed UEFI should be able to use the Legacy VGA
> BIOS even if it doesn't have native support for the video hardware.
> 
> ISTR Windows 2008 even called legacy INT10 as part of the boot process
> and was part of my testing at the time?

Agreed on both counts. But, given that both the CSM binary and the
vgabios come from the same project (SeaBIOS), and that all software has
bugs :) , I thought it prudent to build all SeaBIOS artifacts in sync,
at any given SeaBIOS commit. I was preparing for a SeaBIOS bisection too
(expecting a regression), and I wanted to cover all SeaBIOS code with
that bisection.

Thanks
Laszlo

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

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

Re: [edk2-devel] [patch] ShellPkg/Debug1CommandsLib: Fix bugs in func DisplaySysEventLogData

[Carsey, Jaben]

Pushed.

> -Original Message-
> From: Bi, Dandan
> Sent: Monday, June 10, 2019 5:52 PM
> To: devel@edk2.groups.io; oleks...@ami.com; Ni, Ray ;
> Carsey, Jaben 
> Cc: Gao, Zhichao 
> Subject: RE: [patch] ShellPkg/Debug1CommandsLib: Fix bugs in func
> DisplaySysEventLogData
> Importance: High
> 
> Hi Ray and Jaben,
> 
> Do you have any comments for this patch?
> If no, could you give the R-B and then help push the patch?
> 
> 
> Thanks,
> Dandan
> 
> > -Original Message-
> > From: Gao, Zhichao
> > Sent: Wednesday, May 29, 2019 8:32 AM
> > To: Bi, Dandan ; devel@edk2.groups.io;
> > oleks...@ami.com
> > Cc: Carsey, Jaben ; Ni, Ray 
> > Subject: RE: [patch] ShellPkg/Debug1CommandsLib: Fix bugs in func
> > DisplaySysEventLogData
> >
> > Reviewed-by: Zhichao Gao 
> >
> > > -Original Message-
> > > From: Bi, Dandan
> > > Sent: Tuesday, May 28, 2019 10:25 AM
> > > To: devel@edk2.groups.io; oleks...@ami.com
> > > Cc: Carsey, Jaben ; Ni, Ray
> > > ; Gao, Zhichao 
> > > Subject: [patch] ShellPkg/Debug1CommandsLib: Fix bugs in func
> > > DisplaySysEventLogData
> > >
> > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1498
> > >
> > > This patch fix following bugs in func DisplaySysEventLogData:
> > > 1. Log increment (Log = (LOG_RECORD_FORMAT *) (LogData + Offset);)
> > > should happened in the end of while loop, not in the very beginning.
> > > 2. DisplaySELTypes function should be used in while loop instead of
> > > DisplaySELVarDataFormatType.
> > >
> > > Cc: Jaben Carsey 
> > > Cc: Ray Ni 
> > > Cc: Zhichao Gao 
> > > Signed-off-by: Dandan Bi 
> > > ---
> > >  .../SmbiosView/EventLogInfo.c | 20 +--
> > >  1 file changed, 14 insertions(+), 6 deletions(-)
> > >
> > > diff --git
> > >
> >
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/EventLogInf
> > > o.c
> > >
> >
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/EventLogInf
> > > o.c
> > > index b8adf438d3..984c178890 100644
> > > ---
> > >
> >
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/EventLogInf
> > > o.c
> > > +++
> > >
> >
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/EventLogInf
> > > +++ o.c
> > > @@ -1,9 +1,9 @@
> > >  /** @file
> > >Module for clarifying the content of the smbios structure element info.
> > >
> > > -  Copyright (c) 2005 - 2011, Intel Corporation. All rights reserved.
> > > 
> > > +  Copyright (c) 2005 - 2019, Intel Corporation. All rights reserved.
> > > + 
> > >SPDX-License-Identifier: BSD-2-Clause-Patent
> > >
> > >  **/
> > >
> > >  #include "UefiShellDebug1CommandsLib.h"
> > > @@ -345,20 +345,16 @@ DisplaySysEventLogData (
> > >// Print Log info
> > >//
> > >Offset  = 0;
> > >Log = (LOG_RECORD_FORMAT *) LogData;
> > >while (Log != NULL && Log->Type != END_OF_LOG && Offset <
> > > LogAreaLength) {
> > > -//
> > > -// Get a Event Log Record
> > > -//
> > > -Log = (LOG_RECORD_FORMAT *) (LogData + Offset);
> > >
> > >  if (Log != NULL) {
> > >//
> > >// Display Event Log Record Information
> > >//
> > > -  DisplaySELVarDataFormatType (Log->Type, SHOW_DETAIL);
> > > +  DisplaySELTypes (Log->Type, SHOW_DETAIL);
> > >DisplaySELLogHeaderLen (Log->Length, SHOW_DETAIL);
> > >
> > >Offset += Log->Length;
> > >//
> > >// Display Log Header Date/Time Fields @@ -371,10 +367,14 @@
> > > DisplaySysEventLogData (
> > >  Print (L"19");
> > >} else if (Log != NULL && Log->Year <= 79) {
> > >  Print (L"20");
> > >} else {
> > >  ShellPrintHiiEx(-1,-1,NULL,STRING_TOKEN
> > > (STR_SMBIOSVIEW_EVENTLOGINFO_ERROR), gShellDebug1HiiHandle);
> > > +//
> > > +// Get a Event Log Record
> > > +//
> > > +Log = (LOG_RECORD_FORMAT *) (LogData + Offset);
> > >  continue;
> > >}
> > >
> > >ShellPrintHiiEx(-1,-1,NULL,
> > >  STRING_TOKEN
> > (STR_SMBIOSVIEW_EVENTLOGINFO_TIME_SIX_VARS),
> > > @@ -389,13 +389,21 @@ DisplaySysEventLogData (
> > >
> > >//
> > >// Display Variable Data Format
> > >//
> > >if (Log->Length <= (sizeof (LOG_RECORD_FORMAT) - 1)) {
> > > +//
> > > +// Get a Event Log Record
> > > +//
> > > +Log = (LOG_RECORD_FORMAT *) (LogData + Offset);
> > >  continue;
> > >}
> > >
> > >ElVdfType = Log->LogVariableData[0];
> > >DisplayElVdfInfo (ElVdfType, Log->LogVariableData);
> > > +  //
> > > +  // Get a Event Log Record
> > > +  //
> > > +  Log = (LOG_RECORD_FORMAT *) (LogData + Offset);
> > >  }
> > >}
> > >  }
> > > --
> > > 2.18.0.windows.1


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

View/Reply Online (#42293): https://edk2.groups.io/g/devel/message/42293
Mute This Topic: https://groups.io/mt/31816865/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 

Re: [edk2-devel] [PATCH 0/2] EdkRepo - The Multi-Repository Tool for EDK II

[Nate DeSimone]

Hi Laszlo,

I wasn't 100% sure on what to do with it myself. I took the existing 
Maintainers.txt and did the minimal modification necessary to describe EdkRepo. 
I'm completely flexible with whatever Maintainers.txt format the stewards 
prefer. If a change is needed let me know and I'll submit a V2 patch series.

Thanks,
Nate 

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Laszlo Ersek
Sent: Wednesday, June 12, 2019 12:54 AM
To: Desimone, Nathaniel L ; devel@edk2.groups.io
Cc: Andrew Fish ; Leif Lindholm ; 
Kinney, Michael D 
Subject: Re: [edk2-devel] [PATCH 0/2] EdkRepo - The Multi-Repository Tool for 
EDK II

Hi Nate,

On 06/12/19 02:04, Nate DeSimone wrote:
> This patch series is raised to add the EdkRepo and EdkRepo-Manifest 
> branches to the Edk2-Staging repository. These branches are added to 
> host EdkRepo, the multi-repository tool for EDK II firmware development to 
> TianoCore.
> 
> For more details on EdkRepo, please see my RFC.
> 
> Nate DeSimone (2):
>   Add EdkRepo - The Multi-Repo Tool
>   Add EdkRepo manifest XML
> 

the Maintainers.txt files added in both patches contain sections called "EDK 
II" and "EDK II Packages". Is that intended? (I'm not familiar with branches in 
the staging repo.)

No comments from me otherwise, I'll defer to the other stewards on this.

Thanks!
Laszlo




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

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

Re: [edk2-devel] [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency

[David Woodhouse]

On Wed, 2019-06-12 at 13:52 +0200, Laszlo Ersek wrote:
> (2c) SeaBIOS is built *twice*, once for the CSM, and another time for
> the Cirrus VGABIOS.

We shouldn't need to rebuild the VGA BIOS, should we? Any Legacy VGA
BIOS should work — and indeed UEFI should be able to use the Legacy VGA
BIOS even if it doesn't have native support for the video hardware.

ISTR Windows 2008 even called legacy INT10 as part of the boot process
and was part of my testing at the time?

> (3b) The following out-of-tree patch is applied on top of (3a):
> 
> > diff --git a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBootSupport.c 
> > b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> > index 211750c0123b..119b5c9b6fe8 100644
> > --- a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> > +++ b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> > @@ -1231,8 +1231,8 @@ GenericLegacyBoot (
> >//
> >Private->LegacyRegion->Lock (
> > Private->LegacyRegion,
> > -   0xc,
> > -   0x4,
> > +   0xe,
> > +   0x1,
> > 
> > );
> > 

I didn't need this part.


> With these, grub is booted successfully from the RHEL5 installer ISO
> (which does not support UEFI at all). Unfortunately, after grub loads
> vmlinuz + initrd, it fails with "Not enough memory to load specified
> image", and returns to the grub prompt. (If I double the argument to
> QEMU's "-m" option, to 2048, that makes no difference.)
> 
> This is at least a graceful failure.

It's because the E820 table isn't being passed through to the CSM.


Start of legacy boot
E820[ 0]: 0x - 0x0009F000, Type = 1
E820[ 1]: 0x0009F000 - 0x000A, Type = 2
E820[ 2]: 0x000E - 0x0010, Type = 2
E820[ 3]: 0x0010 - 0x0080, Type = 1
E820[ 4]: 0x0080 - 0x00808000, Type = 4
E820[ 5]: 0x00808000 - 0x0081, Type = 1
E820[ 6]: 0x0081 - 0x0090, Type = 4
E820[ 7]: 0x0090 - 0x7E874000, Type = 1
E820[ 8]: 0x7E874000 - 0x7E88C000, Type = 4
E820[ 9]: 0x7E88C000 - 0x7E8B, Type = 2
E820[10]: 0x7E8B - 0x7FBEF000, Type = 1
E820[11]: 0x7FBEF000 - 0x7FBF3000, Type = 2
E820[12]: 0x7FBF3000 - 0x7FBFB000, Type = 3
E820[13]: 0x7FBFB000 - 0x7FBFF000, Type = 4
E820[14]: 0x7FBFF000 - 0x7FF78000, Type = 1
E820[15]: 0x7FF78000 - 0x8000, Type = 4
E820[16]: 0x8000 - 0xFC00, Type = 2
E820[17]: 0xFEC0 - 0xFEC01000, Type = 2
E820[18]: 0xFED0 - 0xFED00400, Type = 2
E820[19]: 0xFEE0 - 0xFEF0, Type = 2
handle_hwpic1 irq=1
handle_csm regs 0x0005ffd4 AX=0006
Legacy16GetTableAddress size 190 align 0 region 3
ebda moved from 9f000 to fc00
Legacy16GetTableAddress size 190 align 0 region 3 yields 0x
handle_csm returning AX=0001
enter handle_15:
   a=2401  b=  c=0190  d=0003 ds= es= ss=5000
  si= di= bp= sp=ffc6 cs=5f00 ip=0030  f=3002
Legacy16 E820 length insufficient
...
handle_csm regs 0x0005ffd4 AX=0002
PrepareToBoot table 580a:0008
Add to e820 map: f000ff53f000ff53 f000ff53f000e2c3 -268370093
Add to e820 map: f000ff53f000ff54 f000ce45f000ff53 -268382651
Add to e820 map: f000ce45f000ce45 f000ce45f000ce45 -268382651
Add to e820 map: c0005212f000ce45 f000f841f000f84d -268377090
Add to e820 map: f000f859f000e739 f000efd2f000e82e -268382614
Add to e820 map: f000fe6ef000e6f2 f000ff53f000ff53 -268370093
Add to e820 map: c0009200f000ff53 f000ff53f000ff53 -268370093
Add to e820 map: f000ff53f000ff53 f000ff53f000ff53 -268370093
Add to e820 map: f000ff53f000ff53 f000ff53f000ff53 -268370093
Add to e820 map: f000ff53f000ff53 f000ff53f000ff53 -268370093
Add to e820 map: f000ff53f000ff53 f000ff53f000ff53 -268370093
Add to e820 map: f000ff53f000ff53 f000ff53f000ff53 -268370093
Add to e820 map: f000ff53f000ff53 f000ff53f000ff53 -268374951
Add to e820 map: f000ff53f000ff53 f000ff53c0007000 -268370093
Add to e820 map: f000ff53f000ff53 f000ff53f000ff53 -268370093
Add to e820 map: f000ff53f000ff53 f000ff53f000ff53 -268370093
Add to e820 map: f000ff53f000ff53 f000ff53f000ff53 -268370093
Add to e820 map: f000ff53f000ff53 f000ff53f000ff53 -268370093
Add to e820 map: f000ff53f000ff53 f000ff53f000ff53 -268370093
Add to e820 map: f000ff53  0
Add to e820 map: 007c 0004 2
CSM PIRQ table at 0x000f6340
CSM ACPI RSDP at 0x000f6440


Completely bogus E820 information tends to lead to confusing out-of-
memory errors. Film at 11 :)

This fixes it:

diff --git a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBootSupport.c 

Re: [edk2-devel] [PATCH] BaseTools: Cannot store library cache of different arch together

[Christian Rodriguez]

Hi Steven,

This looks good, thank you.

Thanks,
Christian

From: Shi, Steven
Sent: Tuesday, June 11, 2019 8:30 PM
To: Rodriguez, Christian ; devel@edk2.groups.io
Cc: Gao, Liming ; Feng, Bob C 
Subject: RE: [PATCH] BaseTools: Cannot store library cache of different arch 
together

Sorry, the CopyFileOnChange() will ensure only once IO store/restore writing 
for each library. The extra IO read is ok.


Thanks

Steven Shi
Intel\SSG\FID\Firmware Infrastructure

From: Shi, Steven
Sent: Wednesday, June 12, 2019 11:24 AM
To: Rodriguez, Christian 
mailto:christian.rodrig...@intel.com>>; 
devel@edk2.groups.io
Cc: Gao, Liming mailto:liming@intel.com>>; Feng, Bob 
C mailto:bob.c.f...@intel.com>>
Subject: RE: [PATCH] BaseTools: Cannot store library cache of different arch 
together


Hi Christian,

For the extra IO accesses for duplicated library, I plan to introduce the 
CopyFileOnChange() function to solve it. Below is the CopyFileOnChange() BZ, 
and I haven't sent its patch yet. The CopyFileOnChange() will ensure only once 
IO store/restore access for each library. To avoid duplicated library access is 
critical not only for the performance, but also for the writing data race in 
multi-threads.





Basetool need CopyFileOnChange function to avoid cache file writing race in 
multi-thread build

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





Thanks



Steven Shi

Intel\SSG\FID\Firmware Infrastructure



> -Original Message-

> From: Rodriguez, Christian

> Sent: Tuesday, June 11, 2019 11:41 PM

> To: Shi, Steven mailto:steven@intel.com>>; 
> devel@edk2.groups.io

> Cc: Gao, Liming mailto:liming@intel.com>>; Feng, 
> Bob C mailto:bob.c.f...@intel.com>>

> Subject: RE: [PATCH] BaseTools: Cannot store library cache of different arch

> together

>

> The change looks good overall, but I'm concerned about the performance if

> there are multiple of the same library used by different modules. In this case

> the library will be copied once per arch per module. I'm not sure if it would

> make a giant impact, but just something to think about because you would be

> doing extra IO accesses for each duplicate library autogen.

>

> Possible suggestion:

> Is it possible to change the hash to include the arch? Or you can store a

> unique tuple pair like (lib.arch, lib) in the set to reduce the libraries 
> being

> copied to a unique subset.

>

> Thanks,

> Christian

>

> >-Original Message-

> >From: Shi, Steven

> >Sent: Monday, June 10, 2019 10:53 PM

> >To: devel@edk2.groups.io

> >Cc: Gao, Liming mailto:liming@intel.com>>; Feng, 
> >Bob C

> >mailto:bob.c.f...@intel.com>>; Rodriguez, Christian

> >mailto:christian.rodrig...@intel.com>>

> >Subject: [PATCH] BaseTools: Cannot store library cache of different arch

> >together

> >

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

> >

> >Build cache cannot store cache for the same library modules in different arch

> >together. E.g. Both the below IA32 and X64 arch BaseLib caches should exist

> >after build Ovmf3264, but now only the one in X64 arch exist.

> >The reason is the current Basetool use a set() to same all library AutoGen

> >objects, but the different arch lib AutoGen objects have same __hash_ value

> >which comes from the lib MetaFile(The path of module file):

> >def __hash__(self):

> >return hash(self.MetaFile)

> >

> >So the different arch lib AutoGen objects are duplicated one to the set() and

> >only one can exist. This is why the Basetool can only store one arch cache 
> >for

> >library.

> >This patch avoid to use the set() as the container to save the library and

> >module objects because the objects might have same __hash__ value.

> >

> >Cc: Liming Gao mailto:liming@intel.com>>

> >Cc: Bob Feng mailto:bob.c.f...@intel.com>>

> >Cc: Christian Rodriguez 
> >mailto:christian.rodrig...@intel.com>>

> >Signed-off-by: Steven Shi mailto:steven@intel.com>>

> >---

> > BaseTools/Source/Python/build/build.py | 13 +++--

> > 1 file changed, 3 insertions(+), 10 deletions(-)

> >

> >diff --git a/BaseTools/Source/Python/build/build.py

> >b/BaseTools/Source/Python/build/build.py

> >index 0855d4561c..f7a79cbbab 100644

> >--- a/BaseTools/Source/Python/build/build.py

> >+++ b/BaseTools/Source/Python/build/build.py

> >@@ -2203,21 +2203,14 @@ class Build():

> > RemoveDirectory(os.path.dirname(GlobalData.gDatabasePath), True)

> >

> > def CreateAsBuiltInf(self):

> >-all_lib_set = set()

> >-all_mod_set = set()

> > for Module in self.BuildModules:

> > Module.CreateAsBuiltInf()

> >-all_mod_set.add(Module)

> >+for lib in Module.LibraryAutoGenList:

> >+lib.CreateAsBuiltInf(True)

> > for Module in self.HashSkipModules:

> > Module.CreateAsBuiltInf(True)

> >-

Re: [edk2-devel] [edk2-platform patch 0/2] Import IntelSiliconPkg from edk2 repo master

[Liming Gao]

Thanks! Push 
@f87b5c8a6b4b8401a490f4f100f412425b295e5a..bb556a89c69bd6f8a6ee0aa9d43550a47fc808cb

> -Original Message-
> From: Chaganty, Rangasai V
> Sent: Tuesday, June 11, 2019 4:47 PM
> To: Gao, Liming ; devel@edk2.groups.io
> Cc: Kinney, Michael D ; Ni, Ray 
> Subject: RE: [edk2-platform patch 0/2] Import IntelSiliconPkg from edk2 repo 
> master
> 
> Reviewed-by: Sai Chaganty 
> 
> -Original Message-
> From: Gao, Liming
> Sent: Monday, June 10, 2019 8:36 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Ni, Ray 
> ; Chaganty, Rangasai V 
> Subject: [edk2-platform patch 0/2] Import IntelSiliconPkg from edk2 repo 
> master
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1890
> IntelSiliconPkg is moved into Silicon/Intel directory.
> 
> Cc: Michael D Kinney 
> Cc: Ray Ni 
> Cc: Rangasai V Chaganty 
> Signed-off-by: Liming Gao 
> 
> Liming Gao (2):
>   Silicon/Intel: Import IntelSiliconPkg from edk2 repo master
>   Maintainers.txt: Add Maintainers for new added IntelSiliconPkg
> 
>  .../MicrocodeFlashAccessLibNull.c  |   36 +
>  .../Capsule/MicrocodeUpdateDxe/MicrocodeFmp.c  |  979 +++
>  .../Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.c   | 1326 
> 
>  .../Feature/VTd/IntelVTdDxe/BmDma.c|  538 
>  .../Feature/VTd/IntelVTdDxe/DmaProtection.c|  683 ++
>  .../Feature/VTd/IntelVTdDxe/DmarAcpiTable.c|  890 +
>  .../Feature/VTd/IntelVTdDxe/IntelVTdDxe.c  |  400 ++
>  .../Feature/VTd/IntelVTdDxe/PciInfo.c  |  373 ++
>  .../Feature/VTd/IntelVTdDxe/TranslationTable.c | 1026 +++
>  .../Feature/VTd/IntelVTdDxe/TranslationTableEx.c   |  152 +++
>  .../Feature/VTd/IntelVTdDxe/VtdReg.c   |  561 +
>  .../Feature/VTd/IntelVTdPmrPei/DmarTable.c |  578 +
>  .../Feature/VTd/IntelVTdPmrPei/IntelVTdPmr.c   |  420 +++
>  .../Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.c|  810 
>  .../Feature/VTd/IntelVTdPmrPei/VtdReg.c|  287 +
>  .../PlatformVTdInfoSamplePei.c |  361 ++
>  .../PlatformVTdSampleDxe/PlatformVTdSampleDxe.c|  407 ++
>  .../DxeSmbiosDataHobLib/DxeSmbiosDataHobLib.c  |   81 ++
>  Maintainers.txt|4 +
>  .../MicrocodeFlashAccessLibNull.inf|   34 +
>  .../MicrocodeFlashAccessLibNull.uni|   16 +
>  .../MicrocodeCapsulePdb/MicrocodeCapsulePdb.dsc|   27 +
>  .../MicrocodeCapsulePdb/MicrocodeCapsulePdb.fdf|   26 +
>  .../Feature/Capsule/MicrocodeCapsulePdb/Readme.md  |   20 +
>  .../MicrocodeCapsuleTxt/Microcode/Microcode.inf|   21 +
>  .../MicrocodeCapsuleTxt/MicrocodeCapsuleTxt.dsc|   33 +
>  .../MicrocodeCapsuleTxt/MicrocodeCapsuleTxt.fdf|   26 +
>  .../Feature/Capsule/MicrocodeCapsuleTxt/Readme.md  |   33 +
>  .../Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.h   |  499 
>  .../MicrocodeUpdateDxe/MicrocodeUpdateDxe.inf  |   67 +
>  .../MicrocodeUpdateDxe/MicrocodeUpdateDxe.uni  |   15 +
>  .../MicrocodeUpdateDxe/MicrocodeUpdateDxeExtra.uni |   14 +
>  .../Feature/VTd/IntelVTdDxe/DmaProtection.h|  632 ++
>  .../Feature/VTd/IntelVTdDxe/IntelVTdDxe.inf|   83 ++
>  .../Feature/VTd/IntelVTdDxe/IntelVTdDxe.uni|   14 +
>  .../Feature/VTd/IntelVTdDxe/IntelVTdDxeExtra.uni   |   14 +
>  .../Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.h|  159 +++
>  .../Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.inf  |   60 +
>  .../Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.uni  |   14 +
>  .../VTd/IntelVTdPmrPei/IntelVTdPmrPeiExtra.uni |   14 +
>  .../PlatformVTdInfoSamplePei.inf   |   48 +
>  .../PlatformVTdInfoSamplePei.uni   |   14 +
>  .../PlatformVTdInfoSamplePeiExtra.uni  |   14 +
>  .../PlatformVTdSampleDxe/PlatformVTdSampleDxe.inf  |   56 +
>  .../PlatformVTdSampleDxe/PlatformVTdSampleDxe.uni  |   14 +
>  .../PlatformVTdSampleDxeExtra.uni  |   14 +
>  .../IntelSiliconPkg/Include/Guid/MicrocodeFmp.h|   15 +
>  .../IndustryStandard/FirmwareInterfaceTable.h  |   69 +
>  .../Include/IndustryStandard/FirmwareVersionInfo.h |   54 +
>  .../Include/IndustryStandard/IgdOpRegion.h |  149 +++
>  .../IntelSiliconPkg/Include/IndustryStandard/Vtd.h |  355 ++
>  .../Include/Library/MicrocodeFlashAccessLib.h  |   33 +
>  .../Intel/IntelSiliconPkg/Include/Ppi/VtdInfo.h|   37 +
>  .../Include/Protocol/PlatformVtdPolicy.h   |  143 +++
>  Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec  |   80 ++
>  Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc  |   86 ++
>  .../DxeSmbiosDataHobLib/DxeSmbiosDataHobLib.inf|   38 +
>  57 files changed, 12952 insertions(+)
>  create mode 100644 
> Silicon/Intel/IntelSiliconPkg/Feature/Capsule/Library/MicrocodeFlashAccessLibNull/MicrocodeFlashAccessLibNull.c
>  create mode 100644 
> 

Re: [edk2-devel] EDK II Stable Tag release edk2-stable201905 completed

[Liming Gao]

Leif:

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Laszlo 
> Ersek
> Sent: Wednesday, June 12, 2019 5:38 PM
> To: Leif Lindholm 
> Cc: devel@edk2.groups.io; Gao, Liming ; Kinney, Michael 
> D ; af...@apple.com
> Subject: Re: [edk2-devel] EDK II Stable Tag release edk2-stable201905 
> completed
> 
> On 06/12/19 11:21, Leif Lindholm wrote:
> > On Wed, Jun 12, 2019 at 10:18:24AM +0200, Laszlo Ersek wrote:
> >>> In this instance, we explicitly don't care about the submodule for
> >>> that other project (and I really hope this is the norm) - so we
> >>> shouldn't be documenting steps that rely on that additional
> >>> submodule existing.
> >>
> >> Yes; this is why I suggested dropping "--recursive" from the
> >> instructions. As far as I remember, it was meant as a convenience for
> >> users cloning the edk2 repo from zero.
> >
> > But we've never actually relied on that behaviour, so it's not so much
> > convenience as cargo culting.
> >
> >>> This is why I am referring to anything other than a central definition
> >>> of the relationship between edk2 and its submodules as a workaround. I
> >>> am not suggesting any shortcomings in the technical aspect.
> >>
> >> Can you provide an example definition then? I'm having trouble imagining
> >> one.
> >
> > Laszlo, I think you've misunderstood me somewhere.
> 
> That's for certain. :)
> 
> > What I am saying is:
> > - We should have a policy (i.e., a section in toplevel Readme.md)
> >   regarding submodules.
> >   - That policy *should* include the requirement to not permit
> > submodules requiring submodules for our purposes.
> >   - That policy should include the steps required to get the edk2
> > repository to a buildable state.
> >   - Nothing related to submodules should be documented anywhere else
> > in the tree. Sure, OpenSSL-HOWTO.txt can still be there, but
> > the section "HOW to Install OpenSSL for UEFI Building" should go.
> 
> Got it now. Good idea.

Can you submit one BZ for it? I think CryptoPkg maintain should list the clear 
usage of openssl.

> 
> Thanks!
> Laszlo
> 
> 


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

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

Re: [edk2-devel] [BIKESHEDDING-TARGET] BaseTools: add GetMaintainer.py helper script

[Laszlo Ersek]

On 06/12/19 13:19, Leif Lindholm wrote:
> This is work-in-progress, but I figured it would be a good time to start
> having a conversation about how we want it to work.
> 
> The script currently does nothing clever whatsoever with regards to
> looking at historical contributors to the modified code - it only
> performs a lookup in Maintainers.txt.

I think that's good enough.

> Known shortcomings:
> - Does not provide any metainformation about why certain people
>   or mailing lists were picked.
> - Does not reason about precedence of sections - all maintainers
>   for all sections that match a wildcard are returned.
> - Does not substantially update Maintainers.txt.
> - Does not implement the X: tag, to explicitly exclude subpaths.
>   (But scans for it.)

All of the above should be fine, for a start.

> - The splitting of Maintainers.txt into sections is based on
>   directly adjacent lines starting with a valid tag (so I expect
>   Star is left out from MdeModulePkg hits, and OvmfPkg loses most
>   of its Reviewers. (My feeling is this is valid, and Maintainers.txt
>   should change - certainly all the problematic lines would become
>   redundant with this format change.)

I agree -- but then, Maintainers.txt should be updated in the same *series* 
(not patch) just enough to preserve all those R: roles.

> Supported wildcards are '*' and '?' - there is no special treatment of
> trailing '/' at this point.

That should be fine. QEMU supports:

F: Files and directories with wildcard patterns.
   A trailing slash includes all files and subdirectory files.
   F:   drivers/net/all files in and below drivers/net
   F:   drivers/net/*   all files in drivers/net, but not below
   F:   */net/* all files in "any top level directory"/net
   One pattern per line.  Multiple F: lines acceptable.

and I don't think we *need* to distinguish the first two cases from each other 
(I don't see much use for "but not below" ATM).

However, that distinction might work out of the box, due to another comment I'd 
like to make below.

> 
> Oh, and like 'SetupGit.py', it requires the gitpython module.
> 
> Laszlo: if you could provide some english language description of how
> the path (F:) format is supposed to work, and how you think section
> precedence should happen, I can implement that.

Section precedence would be a much later feature (if we cared at all).

English language description for "F:" -- I can only quote QEMU's description.

> The qemu MAINTAINERS file does not contain this information, and my
> perl knowledge is rustier than my python knowledge is incomplete.
> 
> Signed-off-by: Leif Lindholm 
> ---
>  BaseTools/Scripts/GetMaintainer.py | 131 
> +
>  Maintainers.txt|  38 +++
>  2 files changed, 169 insertions(+)
>  create mode 100644 BaseTools/Scripts/GetMaintainer.py
> 
> diff --git a/BaseTools/Scripts/GetMaintainer.py 
> b/BaseTools/Scripts/GetMaintainer.py
> new file mode 100644
> index 00..939930b052
> --- /dev/null
> +++ b/BaseTools/Scripts/GetMaintainer.py
> @@ -0,0 +1,131 @@
> +## @file
> +#  Retrieves the people to request review from on submission of a commit.
> +#
> +#  Copyright (c) 2019, Linaro Ltd. All rights reserved.
> +#
> +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +
> +from __future__ import print_function
> +from collections import defaultdict
> +from collections import OrderedDict
> +import argparse
> +import os
> +import re
> +import SetupGit
> +
> +EXPRESSIONS = {
> +'exclude':re.compile(r'^X:\s*(?P.*?)\r*$'),
> +'file':   re.compile(r'^F:\s*(?P.*?)\r*$'),
> +'list':   re.compile(r'^L:\s*(?P.*?)\r*$'),
> +'maintainer': re.compile(r'^M:\s*(?P.*<.*?>)\r*$'),
> +'reviewer':   re.compile(r'^R:\s*(?P.*?)\r*$'),
> +'status': re.compile(r'^S:\s*(?P.*?)\r*$'),
> +'tree':   re.compile(r'^T:\s*(?P.*?)\r*$'),
> +'webpage':re.compile(r'^W:\s*(?P.*?)\r*$')
> +}
> +
> +def printsection(section):
> +"""Prints out the dictionary describing a Maintainers.txt section."""
> +print('===')
> +for key in section.keys():
> +print("Key: %s" % key)
> +for item in section[key]:
> +print('  %s' % item)
> +
> +def pattern_to_regex(pattern):
> +"""Takes a string containing regular UNIX path wildcards
> +   and returns a string suitable for matching with regex."""
> +pattern = pattern.replace('.', r'\.')
> +pattern = pattern.replace('*', r'.*')
> +pattern = pattern.replace('?', r'.')
> +
> +return pattern

So, this is what I disagree with, at first sight anyway. For example, this 
seems to cause a bare "*" to match all pathnames (with multiple pathname 
components, that is) -- normally we don't expect "*" to cross pathname 
separators.

Consider the pattern you added under "Tianocore Stewards" -- the intent is to 
CC them on patches that touch the project 

Re: [edk2-devel] [RFC][edk2-platform][Add new packages in Platform\Intel directory]

[Liming Gao]

Isaac and Eric:
  Here is the proposal for new packages in Platform\Intel directory.

BoardModulePkg: This package includes the libraries shared between the 
different board packages. Those libraries are linked by the drivers in the 
board packages.
DebugFeaturePkg: This package provides the debug features, such as debug 
library, debug method.
ManageabilityFeaturePkg: This package provides the system management driver, 
such as Ipmi, Smbios.
DeviceFeaturePkg: This package provides the different device support, such as 
SIO controller, Network.
UserInterfaceFeaturePkg: This package provides UI related modules, such as 
Logo, Setup page.

Thanks
Liming
From: Oram, Isaac W
Sent: Tuesday, June 4, 2019 4:25 PM
To: Yao, Jiewen ; Dong, Eric ; 
devel@edk2.groups.io; Gao, Liming ; Kinney, Michael D 

Subject: RE: [RFC][edk2-platform][Add new packages in Platform\Intel directory]

Eric,

I have envisioned less granular packages for advanced features.  One of the 
goals for MinPlatform is to improve usability during porting.  The idea is that 
you would do basic board porting with minimal effort to get your system 
functional.  Then you would enable additional features by adding collections of 
features to your baseline.  Then as a last step optimize out unnecessary 
things.  This is something like a functionality oriented porting approach.  Get 
all the functionality you need by building up, then optimize out.  I would 
characterize Intel's traditional reference platforms as having everything and 
then adding and removing from a starting point that was very feature rich.  The 
challenge we seemed to face was that it was hard to remove things with the 
feature rich starting point.

As an example of functionality oriented porting, say that I set up my basic 
server port by starting with the Purley open board package.  I port it to my 
motherboard, then I check out my baseline functionality.  Then I add 
manageability features by including DSC/FDF from the ManageabilityFeaturePkg 
that add FV to my MinPlatform port.  And I repeat for other sets of features 
until I get all of the features that I need.  Then I optimize: for size, speed, 
to reduce complexity, and so on.  It would be best if this optimization were 
tool assisted to a great degree, e.g a more sophisticated FMMT that lets one 
cut out extra components.

My concern is that if we allow very specific feature packages, like the 
UserAuthenticationPkg, we are very much like today.  Yes, you can select any 
drivers you need and add to your DSC/FDF.  But that is very quickly 
overwhelming.  There are hundreds of drivers and what they require is often 
complex to determine.  Thus we tend to copy something else and customize it.  
This tends to lead to lots of technical debt and complexity.

I am thinking that we should target something like 10-20 advanced feature 
packages that produce one or two (if features have pre-memory components) FV 
with a set of features and simpler dependencies.  We are just in the early 
stages of defining what this would look like, and our thinking is evolving.  We 
have identified Manageability and Debug as feature collections.  I think that 
there is one for adding USB, network, Bluetooth and such peripheral support.  I 
think setup browser and UI stuff will go somewhere.  We can mine a few 
reference platforms for data.

Let's discuss this in person and make a proposal for organization for feature 
packages and the rules for what goes where.  We can add this proposal to your 
RFC and I think that will help guide the future development of the 
Platform\Intel contents.

Regards,
Isaac


From: Yao, Jiewen
Sent: Monday, June 3, 2019 9:03 AM
To: Dong, Eric mailto:eric.d...@intel.com>>; 
devel@edk2.groups.io; Gao, Liming 
mailto:liming@intel.com>>; Kubacki, Michael A 
mailto:michael.a.kuba...@intel.com>>; Oram, Isaac 
W mailto:isaac.w.o...@intel.com>>; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Subject: RE: [RFC][edk2-platform][Add new packages in Platform\Intel directory]

Since there is no other module, I think we can use this specific package name 
to tell people what it is.
It is also good for feature isolation.

Thank you
Yao Jiewen

From: Dong, Eric
Sent: Monday, June 3, 2019 8:53 AM
To: Yao, Jiewen mailto:jiewen@intel.com>>; 
devel@edk2.groups.io; Gao, Liming 
mailto:liming@intel.com>>; Kubacki, Michael A 
mailto:michael.a.kuba...@intel.com>>; Oram, Isaac 
W mailto:isaac.w.o...@intel.com>>; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Subject: RE: [RFC][edk2-platform][Add new packages in Platform\Intel directory]

Hi Jiewen,

So far, I don't have other modules which need to move to this package.

I think UserAuthenticationPkg is too specific, but if others also agree with 
this name, I'm ok too.


Hi liming, Isaac & Mike,

Any comments about the new package name?

Thanks,
Eric
From: Yao, Jiewen
Sent: Monday, June 3, 2019 8:35 AM
To: Dong, 

Re: [edk2-devel] [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency

[David Woodhouse]

On Wed, 2019-06-12 at 13:52 +0200, Laszlo Ersek wrote:
> 
> I don't think it's on Hao to determine an (edk2 base commit, SeaBIOS
> base commit) pair from the past at which the CSM functionality worked
> "flawlessly".

Absolutely!

I was only suggesting that Hao should make sure it doesn't get worse.

When I first did it, I had various versions of Windows and Linux and
*BSD working correctly. I'm still working when time allows on working
out how to get back to that state.

But right now it does at least show that it's getting correctly into
SeaBIOS and handling a bunch of requests before it crashes. As long as
it still gets that far after Hao's patches, that's fine.


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

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



smime.p7s
Description: S/MIME cryptographic signature

Re: [edk2-devel] [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency

[Laszlo Ersek]

On 06/12/19 10:03, David Woodhouse wrote:
> On Wed, 2019-06-12 at 09:58 +0200, Laszlo Ersek wrote:
>> Ray,
>>
>> On 06/12/19 04:13, Wu, Hao A wrote:
 -Original Message-
 From: Ni, Ray
 Sent: Wednesday, June 12, 2019 10:04 AM
 To: Wu, Hao A; David Woodhouse; Justen, Jordan L;
 devel@edk2.groups.io
 Cc: Laszlo Ersek; Ard Biesheuvel; Phillips, D Scott
 Subject: RE: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg
 dependency

 Hao,
 Will the CSM duplication cause any code change that may impact CSM
 functionality?
>>>
>>> Hello Ray,
>>>
>>> I think there should be no functional impact for the duplication.
>>> There is no change to the .C/.H files.
>>>
>>> Best Regards,
>>> Hao Wu
>>>
 If no, how about firstly duplicate them first?

 David,
 Will this approach work for you?
>>
>> It will not work for me.
>>
>> Here's the problem:
>>
>> - I'm not comfortable approving the duplication (or move) under
>> OvmfPkg, until David ACKs the patch -- the first patch in the series
>> -- that spells out his reviewership for the CSM modules,
>
> I'll certainly ack that.
>
>> - I believe David is not comfortable ACKing that patch until he can
>> get the CSM build to work again.
>
> I'm OK with it as long as the submitter has done their own testing and
> confirms that it works at least as well as it did before.

Is that testing burden really on Hao though?

You write "it works at least as well as it did before", and I generally
agree with that -- but I doubt that Hao has *ever* built the SeaBIOS CSM
(in itself first, and then into the OVMF binary second).

IOW I consider Hao doing OvmfPkg users a favor by submitting these code
movement patch sets. When some modules become unmaintained / orphaned
and are about to be deleted, the minimum we can expect from the earlier
module maintainers is to cleanly remove all in-tree platform references.
But code movement under OvmfPkg is more than that minimum; it's a
courtesy. I don't think we should expect Hao to do this before-after
testing.


> It does get quite a long way into 16-bit code and then does somewhere
> in the CSM itself, after a few legacy BIOS calls.

FWIW, I'm getting the following results, *without* Hao's patches:


(1) QEMU is built at commit 47fbad45d47a ("Merge remote-tracking branch
'remotes/kevin/tags/for-upstream' into staging", 2019-06-04)


(2a) SeaBIOS is built at commit 85137fb5f2df ("virtio-pci: Use %pP
format in dprintf() calls", 2019-05-23)

(2b) The following out-of-tree patch is applied to SeaBIOS on top of
(2a):

> diff --git a/src/hw/serialio.c b/src/hw/serialio.c
> index 31633443780a..ed918ade9306 100644
> --- a/src/hw/serialio.c
> +++ b/src/hw/serialio.c
> @@ -116,7 +116,7 @@ qemu_debug_preinit(void)
>  void
>  qemu_debug_putc(char c)
>  {
> -if (!CONFIG_DEBUG_IO || !runningOnQEMU())
> +if (!CONFIG_DEBUG_IO)
>  return;
>  u16 port = GET_GLOBAL(DebugOutputPort);
>  if (port)

This is because runningOnQEMU() evaluates to false if SeaBIOS is built
as CSM (IIRC), yet I'd like to get debug output.

(2c) SeaBIOS is built *twice*, once for the CSM, and another time for
the Cirrus VGABIOS. Parts of my build script are:

> make distclean
> cat >.config <<-EOT
>   CONFIG_CSM=y
>   CONFIG_QEMU_HARDWARE=y
>   CONFIG_PERMIT_UNALIGNED_PCIROM=y
>   CONFIG_DEBUG_LEVEL=20
>   CONFIG_ROM_SIZE=192
> EOT
> yes "" | make oldconfig
> make -j2 out/bios.bin

The "bios.bin" file built by this step is copied into the edk2 tree as
"OvmfPkg/Csm/Csm16/Csm16.bin".

> make distclean
> cat >.config <<-EOT
>   CONFIG_QEMU=y
>   CONFIG_BUILD_VGABIOS=y
>   CONFIG_VGA_CIRRUS=y
>   CONFIG_VGA_PCI=y
>   CONFIG_DEBUG_LEVEL=20
> EOT
> yes "" | make oldconfig
> make -j2 out/vgabios.bin

The "vgabios.bin" file built by this step is copied to a different
directory under the name "vgabios-cirrus.csm.bin".


(3a) OVMF is built at edk2 commit e5b4d825afc4 ("MdeModulePkg/PciBusDxe:
catch unimplemented extended config space reads", 2019-06-11).

(3b) The following out-of-tree patch is applied on top of (3a):

> diff --git a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBootSupport.c 
> b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> index 211750c0123b..119b5c9b6fe8 100644
> --- a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> +++ b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> @@ -1231,8 +1231,8 @@ GenericLegacyBoot (
>//
>Private->LegacyRegion->Lock (
> Private->LegacyRegion,
> -   0xc,
> -   0x4,
> +   0xe,
> +   0x1,
> 
> );
>

(3c) "OvmfPkg/Csm/Csm16/Csm16.bin" comes from step (2c).

(3d) The OVMF build command line is:

> build \
>  -a X64 \
>  -b NOOPT \
>  -p OvmfPkg/OvmfPkgX64.dsc \
>  -t GCC48 \
>  

[edk2-devel] [BIKESHEDDING-TARGET] BaseTools: add GetMaintainer.py helper script

[Leif Lindholm]

This is work-in-progress, but I figured it would be a good time to start
having a conversation about how we want it to work.

The script currently does nothing clever whatsoever with regards to
looking at historical contributors to the modified code - it only
performs a lookup in Maintainers.txt.

Known shortcomings:
- Does not provide any metainformation about why certain people
  or mailing lists were picked.
- Does not reason about precedence of sections - all maintainers
  for all sections that match a wildcard are returned.
- Does not substantially update Maintainers.txt.
- Does not implement the X: tag, to explicitly exclude subpaths.
  (But scans for it.)
- The splitting of Maintainers.txt into sections is based on
  directly adjacent lines starting with a valid tag (so I expect
  Star is left out from MdeModulePkg hits, and OvmfPkg loses most
  of its Reviewers. (My feeling is this is valid, and Maintainers.txt
  should change - certainly all the problematic lines would become
  redundant with this format change.)

Supported wildcards are '*' and '?' - there is no special treatment of
trailing '/' at this point.

Oh, and like 'SetupGit.py', it requires the gitpython module.

Laszlo: if you could provide some english language description of how
the path (F:) format is supposed to work, and how you think section
precedence should happen, I can implement that.
The qemu MAINTAINERS file does not contain this information, and my
perl knowledge is rustier than my python knowledge is incomplete.

Signed-off-by: Leif Lindholm 
---
 BaseTools/Scripts/GetMaintainer.py | 131 +
 Maintainers.txt|  38 +++
 2 files changed, 169 insertions(+)
 create mode 100644 BaseTools/Scripts/GetMaintainer.py

diff --git a/BaseTools/Scripts/GetMaintainer.py 
b/BaseTools/Scripts/GetMaintainer.py
new file mode 100644
index 00..939930b052
--- /dev/null
+++ b/BaseTools/Scripts/GetMaintainer.py
@@ -0,0 +1,131 @@
+## @file
+#  Retrieves the people to request review from on submission of a commit.
+#
+#  Copyright (c) 2019, Linaro Ltd. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+
+from __future__ import print_function
+from collections import defaultdict
+from collections import OrderedDict
+import argparse
+import os
+import re
+import SetupGit
+
+EXPRESSIONS = {
+'exclude':re.compile(r'^X:\s*(?P.*?)\r*$'),
+'file':   re.compile(r'^F:\s*(?P.*?)\r*$'),
+'list':   re.compile(r'^L:\s*(?P.*?)\r*$'),
+'maintainer': re.compile(r'^M:\s*(?P.*<.*?>)\r*$'),
+'reviewer':   re.compile(r'^R:\s*(?P.*?)\r*$'),
+'status': re.compile(r'^S:\s*(?P.*?)\r*$'),
+'tree':   re.compile(r'^T:\s*(?P.*?)\r*$'),
+'webpage':re.compile(r'^W:\s*(?P.*?)\r*$')
+}
+
+def printsection(section):
+"""Prints out the dictionary describing a Maintainers.txt section."""
+print('===')
+for key in section.keys():
+print("Key: %s" % key)
+for item in section[key]:
+print('  %s' % item)
+
+def pattern_to_regex(pattern):
+"""Takes a string containing regular UNIX path wildcards
+   and returns a string suitable for matching with regex."""
+pattern = pattern.replace('.', r'\.')
+pattern = pattern.replace('*', r'.*')
+pattern = pattern.replace('?', r'.')
+
+return pattern
+
+def get_section_maintainers(path, section):
+"""Returns a list with email addresses to any M: and R: entries
+   matching the provided path in the provided section."""
+maintainers = []
+
+for pattern in section['file']:
+regex = pattern_to_regex(pattern)
+match = re.match(regex, path)
+if match:
+#print('path: "%s" pattern: "%s" regex: "%s"' % (path, pattern, 
regex))
+for address in section['maintainer'], section['reviewer']:
+maintainers += address
+
+return maintainers
+
+def get_maintainers(path, sections):
+"""For 'path', iterates over all sections, returning maintainers
+   for matching ones."""
+maintainers = []
+for section in sections:
+addresses = get_section_maintainers(path, section)
+if addresses:
+maintainers += addresses
+
+# Remove any duplicates
+return list(OrderedDict.fromkeys(maintainers))
+
+def parse_maintainers_line(line):
+"""Parse one line of Maintainers.txt, returning any match group and its 
key."""
+for key, expression in EXPRESSIONS.items():
+match = expression.match(line)
+if match:
+return key, match.group(key)
+return None, None
+
+def parse_maintainers_file(filename):
+"""Parse the Maintainers.txt from top-level of repo and
+   return a list containing dictionaries of all sections."""
+with open(filename, 'r') as text:
+line = text.readline()
+sectionlist = []
+section = defaultdict(list)
+while line:
+key, value = 

Re: [edk2-devel] [PATCH v2 1/1] ShellPkg: acpiview: ACPI 6.3 update for MADT parser

[Krzysztof Koch]

Hi Zhichao,

Please find my comments inline below. They are marked with [Krzysztof]

Kind regards,

Krzysztof

-Original Message-
From: Gao, Zhichao  
Sent: Monday, June 10, 2019 2:08
To: Krzysztof Koch ; devel@edk2.groups.io
Cc: Sami Mujawar ; Carsey, Jaben 
; Ni, Ray ; Matteo Carlini 
; Stephanie Hughes-Fitt 
; nd 
Subject: RE: [PATCH v2 1/1] ShellPkg: acpiview: ACPI 6.3 update for MADT parser

Sorry for late update.

> -Original Message-
> From: Krzysztof Koch [mailto:krzysztof.k...@arm.com]
> Sent: Friday, June 7, 2019 4:48 PM
> To: devel@edk2.groups.io
> Cc: sami.muja...@arm.com; Carsey, Jaben ; Ni, 
> Ray ; Gao, Zhichao ; 
> matteo.carl...@arm.com; stephanie.hughes-f...@arm.com; n...@arm.com
> Subject: [PATCH v2 1/1] ShellPkg: acpiview: ACPI 6.3 update for MADT 
> parser
> 
> The ACPI 6.3 specification introduces a 'SPE overflow Interrupt' field 
> as part of the GICC structure.
> 
> Update the MADT parser to decode this field and validate the interrupt 
> ID used.
> 
> References:
> - ACPI 6.3 Specification - January 2019
> - Arm Generic Interrupt Controller Architecture Specification,
>   GIC architecture version 3 and version 4, issue E
> - Arm Server Base System Architecture 5.0
> 
> Signed-off-by: Krzysztof Koch 
> ---
> 
> Changes can be seen at:
> https://github.com/KrzysztofKoch1/edk2/tree/477_acpiview_spe_v2
> 
> Notes:
> v2:
> - Add include sandwich in MadtParser.h [Zhichao]
> - Add references to specifications in commit message [Zhichao]
> 
> v1:
> - Decode and validate SPE Overflow Interrupt field [Krzysztof]
> 
> 
> ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtParser.
> c | 86 ++--
> ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtParser.
> h | 40 +
>  2 files changed, 118 insertions(+), 8 deletions(-)
> 
> diff --git
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtPars
> er.c
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtPars
> er.c
> index
> a1bf86ade5313f954a77b325c13394cfce133939..59c3df0cc8a080497b517baf36f
> c63f1e4ab866f 100644
> ---
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtPars
> er.c
> +++
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtPars
> +++ er.c
> @@ -1,17 +1,21 @@
>  /** @file
>MADT table parser
> 
> -  Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
> +  Copyright (c) 2016 - 2019, ARM Limited. All rights reserved.
>SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>@par Reference(s):
> -- ACPI 6.2 Specification - Errata A, September 2017
> +- ACPI 6.3 Specification - January 2019
> +- Arm Generic Interrupt Controller Architecture Specification,
> +  GIC architecture version 3 and version 4, issue E
> +- Arm Server Base System Architecture 5.0
>  **/
> 
>  #include 
>  #include 
>  #include "AcpiParser.h"
>  #include "AcpiTableParser.h"
> +#include "MadtParser.h"
> 
>  // Local Variables
>  STATIC CONST UINT8* MadtInterruptControllerType; @@ -33,6 +37,21 @@ 
> ValidateGICDSystemVectorBase (
>IN VOID*  Context
>);
> 
> +/**
> +  This function validates the SPE Overflow Interrupt in the GICC.
> +
> +  @param [in] Ptr Pointer to the start of the field data.
> +  @param [in] Context Pointer to context specific information e.g. this
> +  could be a pointer to the ACPI table header.
> +**/
> +STATIC
> +VOID
> +EFIAPI
> +ValidateSpeOverflowInterrupt (
> +  IN UINT8* Ptr,
> +  IN VOID*  Context
> +  );
> +
>  /**
>An ACPI_PARSER array describing the GICC Interrupt Controller Structure.
>  **/
> @@ -56,7 +75,9 @@ STATIC CONST ACPI_PARSER GicCParser[] = {
>{L"MPIDR", 8, 68, L"0x%lx", NULL, NULL, NULL, NULL},
>{L"Processor Power Efficiency Class", 1, 76, L"0x%x", NULL, NULL, NULL,
> NULL},
> -  {L"Reserved", 3, 77, L"%x %x %x", Dump3Chars, NULL, NULL, NULL}
> +  {L"Reserved", 1, 77, L"0x%x", NULL, NULL, NULL, NULL},  {L"SPE 
> + overflow Interrupt", 2, 78, L"0x%x", NULL, NULL,
> +ValidateSpeOverflowInterrupt, NULL}
>  };
> 
>  /**
> @@ -160,6 +181,55 @@ ValidateGICDSystemVectorBase (
>}
>  }
> 
> +/**
> +  This function validates the SPE Overflow Interrupt in the GICC.
> +
> +  @param [in] Ptr Pointer to the start of the field data.
> +  @param [in] Context Pointer to context specific information e.g. this
> +  could be a pointer to the ACPI table header.
> +**/
> +STATIC
> +VOID
> +EFIAPI
> +ValidateSpeOverflowInterrupt (
> +  IN UINT8* Ptr,
> +  IN VOID*  Context
> +  )
> +{
> +  UINT16 SpeOverflowInterrupt;
> +
> +  SpeOverflowInterrupt = *(UINT16*)Ptr;
> +
> +  // SPE not supported by this processor  if (SpeOverflowInterrupt ==
> + 0) {
> +return;
> +  }
> +
> +  if ((SpeOverflowInterrupt < ARM_PPI_ID_MIN) ||
> +  ((SpeOverflowInterrupt > ARM_PPI_ID_MAX) &&
> +   (SpeOverflowInterrupt < ARM_PPI_ID_EXTENDED_MIN)) ||
> +  (SpeOverflowInterrupt > ARM_PPI_ID_EXTENDED_MAX)) {

Re: [edk2-devel] [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency

[Ni, Ray]

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Laszlo
> Ersek
> Sent: Wednesday, June 12, 2019 3:58 PM
> To: Wu, Hao A ; Ni, Ray ; David
> Woodhouse ; Justen, Jordan L
> ; devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Phillips, D Scott
> 
> Subject: Re: [edk2-devel] [PATCH v2 0/6] Ovmf: Drop
> IntelFramework[Module]Pkg dependency
> 
> Ray,
> 
> On 06/12/19 04:13, Wu, Hao A wrote:
> >> -Original Message-
> >> From: Ni, Ray
> >> Sent: Wednesday, June 12, 2019 10:04 AM
> >> To: Wu, Hao A; David Woodhouse; Justen, Jordan L;
> >> devel@edk2.groups.io
> >> Cc: Laszlo Ersek; Ard Biesheuvel; Phillips, D Scott
> >> Subject: RE: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg
> >> dependency
> >>
> >> Hao,
> >> Will the CSM duplication cause any code change that may impact CSM
> >> functionality?
> >
> > Hello Ray,
> >
> > I think there should be no functional impact for the duplication.
> > There is no change to the .C/.H files.
> >
> > Best Regards,
> > Hao Wu
> >
> >> If no, how about firstly duplicate them first?
> >>
> >> David,
> >> Will this approach work for you?
> 
> It will not work for me.
> 
> Here's the problem:
> 
> - I'm not comfortable approving the duplication (or move) under OvmfPkg,
> until David ACKs the patch -- the first patch in the series -- that spells 
> out his
> reviewership for the CSM modules,
> 
> - I believe David is not comfortable ACKing that patch until he can get the
> CSM build to work again.

I thought there is a dead lock but maybe not.
I think the below things need to be done in order:
1. David gets the CSM build work again.
2. Hao sends out the patch to duplicate CSM in OvmfPkg.
3. David ACKs the patch
4. Hao pushes the patch.

But when will #1 finish?
I don't expect we stop here for a very long period.
(I cannot remember when we started this conversation, maybe several months ago.)


> 
> Thanks
> Laszlo
> 
> 


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

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

Re: [edk2-devel] EDK II Stable Tag release edk2-stable201905 completed

[Laszlo Ersek]

On 06/12/19 11:21, Leif Lindholm wrote:
> On Wed, Jun 12, 2019 at 10:18:24AM +0200, Laszlo Ersek wrote:
>>> In this instance, we explicitly don't care about the submodule for
>>> that other project (and I really hope this is the norm) - so we
>>> shouldn't be documenting steps that rely on that additional
>>> submodule existing.
>>
>> Yes; this is why I suggested dropping "--recursive" from the
>> instructions. As far as I remember, it was meant as a convenience for
>> users cloning the edk2 repo from zero.
> 
> But we've never actually relied on that behaviour, so it's not so much
> convenience as cargo culting.
> 
>>> This is why I am referring to anything other than a central definition
>>> of the relationship between edk2 and its submodules as a workaround. I
>>> am not suggesting any shortcomings in the technical aspect.
>>
>> Can you provide an example definition then? I'm having trouble imagining
>> one.
> 
> Laszlo, I think you've misunderstood me somewhere.

That's for certain. :)

> What I am saying is:
> - We should have a policy (i.e., a section in toplevel Readme.md)
>   regarding submodules.
>   - That policy *should* include the requirement to not permit
> submodules requiring submodules for our purposes.
>   - That policy should include the steps required to get the edk2
> repository to a buildable state.
>   - Nothing related to submodules should be documented anywhere else
> in the tree. Sure, OpenSSL-HOWTO.txt can still be there, but
> the section "HOW to Install OpenSSL for UEFI Building" should go.

Got it now. Good idea.

Thanks!
Laszlo

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

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

Re: [edk2-devel] [edk2-platforms PATCH v1 1/1 -resend] Platform/ARM/JunoPkg: Add support for PPTT dynamic generation

[Alexei Fedorov]

Reviewed-by: Alexei Fedorov 


Alexei


From: devel@edk2.groups.io  on behalf of Krzysztof Koch 
via Groups.Io 
Sent: 12 June 2019 10:31
To: devel@edk2.groups.io
Cc: Ard Biesheuvel; Leif Lindholm; Michael D Kinney; Sami Mujawar; Matteo 
Carlini; Stephanie Hughes-Fitt; nd
Subject: [edk2-devel] [edk2-platforms PATCH v1 1/1 -resend] 
Platform/ARM/JunoPkg: Add support for PPTT dynamic generation

Update the Platform Respository for the Juno platform
to include support for generation of the Processor Properties
Topology Table (PPTT) using the Dynamic Tables Framework.

The Platform Repository now also describes the cache and
processor topology in Juno (all revisions).

Signed-off-by: Krzysztof Koch 
---

Changes can be seen at: 
https://github.com/KrzysztofKoch1/edk2-platforms/tree/392_dynamic_pptt_juno_v1

Notes:
v1:
- add support for dynamic generation of PPTT [Krzysztof]

 
Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
 | 443 +++-
 
Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.h
 | 136 +-
 2 files changed, 575 insertions(+), 4 deletions(-)

diff --git 
a/Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
 
b/Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
index 
78b906ddb8bbd35c32b4be98b1ee8bd973b6b818..2ef79ba5df750e869d241fcba98fdd44b1f26002
 100644
--- 
a/Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
+++ 
b/Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
@@ -96,7 +96,13 @@ EDKII_PLATFORM_REPOSITORY_INFO ArmJunoPlatformRepositoryInfo 
= {
   CREATE_STD_ACPI_TABLE_GEN_ID (EStdAcpiTableIdSsdt),
   (EFI_ACPI_DESCRIPTION_HEADER*)ssdtuart_aml_code
 },
-
+// PPTT Table
+{
+  EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE_STRUCTURE_SIGNATURE,
+  EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE_REVISION,
+  CREATE_STD_ACPI_TABLE_GEN_ID (EStdAcpiTableIdPptt),
+  NULL
+},
 /* PCI MCFG Table
PCIe is only available on Juno R1 and R2.
Add the PCI table entries at the end of the table so that
@@ -261,6 +267,301 @@ EDKII_PLATFORM_REPOSITORY_INFO 
ArmJunoPlatformRepositoryInfo = {
 127,
 // SPI Base used by this frame.
 224
+  },
+
+  // Processor Hierarchy Nodes
+  {
+// Package
+{
+  // CM_OBJECT_TOKEN  Token
+  REFERENCE_TOKEN (ProcHierarchyInfo[0]),
+  // UINT32  Flags
+  PROC_NODE_FLAGS (
+EFI_ACPI_6_3_PPTT_PACKAGE_PHYSICAL,
+EFI_ACPI_6_3_PPTT_PROCESSOR_ID_INVALID,
+EFI_ACPI_6_3_PPTT_PROCESSOR_IS_NOT_THREAD,
+EFI_ACPI_6_3_PPTT_NODE_IS_NOT_LEAF,
+EFI_ACPI_6_3_PPTT_IMPLEMENTATION_NOT_IDENTICAL
+  ),
+  // CM_OBJECT_TOKEN  ParentToken
+  CM_NULL_TOKEN,
+  // CM_OBJECT_TOKEN  GicCToken
+  CM_NULL_TOKEN,
+  // UINT32  NoOfPrivateResources
+  0,
+  // CM_OBJECT_TOKEN  PrivateResourcesArrayToken
+  CM_NULL_TOKEN
+},
+// 'big' cluster
+{
+  // CM_OBJECT_TOKEN  Token
+  REFERENCE_TOKEN (ProcHierarchyInfo[1]),
+  // UINT32  Flags
+  PROC_NODE_FLAGS (
+EFI_ACPI_6_3_PPTT_PACKAGE_NOT_PHYSICAL,
+EFI_ACPI_6_3_PPTT_PROCESSOR_ID_INVALID,
+EFI_ACPI_6_3_PPTT_PROCESSOR_IS_NOT_THREAD,
+EFI_ACPI_6_3_PPTT_NODE_IS_NOT_LEAF,
+EFI_ACPI_6_3_PPTT_IMPLEMENTATION_IDENTICAL
+  ),
+  // CM_OBJECT_TOKEN  ParentToken
+  REFERENCE_TOKEN (ProcHierarchyInfo[0]), // -> Package
+  // CM_OBJECT_TOKEN  GicCToken
+  CM_NULL_TOKEN,
+  // UINT32  NoOfPrivateResources
+  BIG_CLUSTER_RESOURCE_COUNT,
+  // CM_OBJECT_TOKEN  PrivateResourcesArrayToken
+  REFERENCE_TOKEN (BigClusterResources)
+},
+// 'LITTLE' cluster
+{
+  // CM_OBJECT_TOKEN  Token
+  REFERENCE_TOKEN (ProcHierarchyInfo[2]),
+  // UINT32  Flags
+  PROC_NODE_FLAGS (
+EFI_ACPI_6_3_PPTT_PACKAGE_NOT_PHYSICAL,
+EFI_ACPI_6_3_PPTT_PROCESSOR_ID_INVALID,
+EFI_ACPI_6_3_PPTT_PROCESSOR_IS_NOT_THREAD,
+EFI_ACPI_6_3_PPTT_NODE_IS_NOT_LEAF,
+EFI_ACPI_6_3_PPTT_IMPLEMENTATION_IDENTICAL
+  ),
+  // CM_OBJECT_TOKEN  ParentToken
+  REFERENCE_TOKEN (ProcHierarchyInfo[0]), // -> Package
+  // CM_OBJECT_TOKEN  GicCToken
+  CM_NULL_TOKEN,
+  // UINT32  NoOfPrivateResources
+  LITTLE_CLUSTER_RESOURCE_COUNT,
+  // CM_OBJECT_TOKEN  PrivateResourcesArrayToken
+  REFERENCE_TOKEN (LittleClusterResources)
+},
+// Two 'big' cores
+{
+  // CM_OBJECT_TOKEN  Token
+  REFERENCE_TOKEN (ProcHierarchyInfo[3]),
+  // UINT32  Flags
+  PROC_NODE_FLAGS (
+EFI_ACPI_6_3_PPTT_PACKAGE_NOT_PHYSICAL,
+EFI_ACPI_6_3_PPTT_PROCESSOR_ID_VALID,
+EFI_ACPI_6_3_PPTT_PROCESSOR_IS_NOT_THREAD,
+

[edk2-devel] [edk2-platforms PATCH v1 1/1 -resend] Platform/ARM/JunoPkg: Add support for PPTT dynamic generation

[Krzysztof Koch]

Update the Platform Respository for the Juno platform
to include support for generation of the Processor Properties
Topology Table (PPTT) using the Dynamic Tables Framework.

The Platform Repository now also describes the cache and
processor topology in Juno (all revisions).

Signed-off-by: Krzysztof Koch 
---

Changes can be seen at: 
https://github.com/KrzysztofKoch1/edk2-platforms/tree/392_dynamic_pptt_juno_v1

Notes:
v1:
- add support for dynamic generation of PPTT [Krzysztof]

 
Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
 | 443 +++-
 
Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.h
 | 136 +-
 2 files changed, 575 insertions(+), 4 deletions(-)

diff --git 
a/Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
 
b/Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
index 
78b906ddb8bbd35c32b4be98b1ee8bd973b6b818..2ef79ba5df750e869d241fcba98fdd44b1f26002
 100644
--- 
a/Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
+++ 
b/Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
@@ -96,7 +96,13 @@ EDKII_PLATFORM_REPOSITORY_INFO ArmJunoPlatformRepositoryInfo 
= {
   CREATE_STD_ACPI_TABLE_GEN_ID (EStdAcpiTableIdSsdt),
   (EFI_ACPI_DESCRIPTION_HEADER*)ssdtuart_aml_code
 },
-
+// PPTT Table
+{
+  EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE_STRUCTURE_SIGNATURE,
+  EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE_REVISION,
+  CREATE_STD_ACPI_TABLE_GEN_ID (EStdAcpiTableIdPptt),
+  NULL
+},
 /* PCI MCFG Table
PCIe is only available on Juno R1 and R2.
Add the PCI table entries at the end of the table so that
@@ -261,6 +267,301 @@ EDKII_PLATFORM_REPOSITORY_INFO 
ArmJunoPlatformRepositoryInfo = {
 127,
 // SPI Base used by this frame.
 224
+  },
+
+  // Processor Hierarchy Nodes
+  {
+// Package
+{
+  // CM_OBJECT_TOKEN  Token
+  REFERENCE_TOKEN (ProcHierarchyInfo[0]),
+  // UINT32  Flags
+  PROC_NODE_FLAGS (
+EFI_ACPI_6_3_PPTT_PACKAGE_PHYSICAL,
+EFI_ACPI_6_3_PPTT_PROCESSOR_ID_INVALID,
+EFI_ACPI_6_3_PPTT_PROCESSOR_IS_NOT_THREAD,
+EFI_ACPI_6_3_PPTT_NODE_IS_NOT_LEAF,
+EFI_ACPI_6_3_PPTT_IMPLEMENTATION_NOT_IDENTICAL
+  ),
+  // CM_OBJECT_TOKEN  ParentToken
+  CM_NULL_TOKEN,
+  // CM_OBJECT_TOKEN  GicCToken
+  CM_NULL_TOKEN,
+  // UINT32  NoOfPrivateResources
+  0,
+  // CM_OBJECT_TOKEN  PrivateResourcesArrayToken
+  CM_NULL_TOKEN
+},
+// 'big' cluster
+{
+  // CM_OBJECT_TOKEN  Token
+  REFERENCE_TOKEN (ProcHierarchyInfo[1]),
+  // UINT32  Flags
+  PROC_NODE_FLAGS (
+EFI_ACPI_6_3_PPTT_PACKAGE_NOT_PHYSICAL,
+EFI_ACPI_6_3_PPTT_PROCESSOR_ID_INVALID,
+EFI_ACPI_6_3_PPTT_PROCESSOR_IS_NOT_THREAD,
+EFI_ACPI_6_3_PPTT_NODE_IS_NOT_LEAF,
+EFI_ACPI_6_3_PPTT_IMPLEMENTATION_IDENTICAL
+  ),
+  // CM_OBJECT_TOKEN  ParentToken
+  REFERENCE_TOKEN (ProcHierarchyInfo[0]), // -> Package
+  // CM_OBJECT_TOKEN  GicCToken
+  CM_NULL_TOKEN,
+  // UINT32  NoOfPrivateResources
+  BIG_CLUSTER_RESOURCE_COUNT,
+  // CM_OBJECT_TOKEN  PrivateResourcesArrayToken
+  REFERENCE_TOKEN (BigClusterResources)
+},
+// 'LITTLE' cluster
+{
+  // CM_OBJECT_TOKEN  Token
+  REFERENCE_TOKEN (ProcHierarchyInfo[2]),
+  // UINT32  Flags
+  PROC_NODE_FLAGS (
+EFI_ACPI_6_3_PPTT_PACKAGE_NOT_PHYSICAL,
+EFI_ACPI_6_3_PPTT_PROCESSOR_ID_INVALID,
+EFI_ACPI_6_3_PPTT_PROCESSOR_IS_NOT_THREAD,
+EFI_ACPI_6_3_PPTT_NODE_IS_NOT_LEAF,
+EFI_ACPI_6_3_PPTT_IMPLEMENTATION_IDENTICAL
+  ),
+  // CM_OBJECT_TOKEN  ParentToken
+  REFERENCE_TOKEN (ProcHierarchyInfo[0]), // -> Package
+  // CM_OBJECT_TOKEN  GicCToken
+  CM_NULL_TOKEN,
+  // UINT32  NoOfPrivateResources
+  LITTLE_CLUSTER_RESOURCE_COUNT,
+  // CM_OBJECT_TOKEN  PrivateResourcesArrayToken
+  REFERENCE_TOKEN (LittleClusterResources)
+},
+// Two 'big' cores
+{
+  // CM_OBJECT_TOKEN  Token
+  REFERENCE_TOKEN (ProcHierarchyInfo[3]),
+  // UINT32  Flags
+  PROC_NODE_FLAGS (
+EFI_ACPI_6_3_PPTT_PACKAGE_NOT_PHYSICAL,
+EFI_ACPI_6_3_PPTT_PROCESSOR_ID_VALID,
+EFI_ACPI_6_3_PPTT_PROCESSOR_IS_NOT_THREAD,
+EFI_ACPI_6_3_PPTT_NODE_IS_LEAF,
+EFI_ACPI_6_3_PPTT_IMPLEMENTATION_NOT_IDENTICAL
+  ),
+  // CM_OBJECT_TOKEN  ParentToken
+  REFERENCE_TOKEN (ProcHierarchyInfo[1]), // -> 'big' cluster
+  // CM_OBJECT_TOKEN  GicCToken
+  REFERENCE_TOKEN (GicCInfo[0]),
+  // UINT32  NoOfPrivateResources
+  BIG_CORE_RESOURCE_COUNT,
+  // CM_OBJECT_TOKEN  PrivateResourcesArrayToken
+  REFERENCE_TOKEN (BigCoreResources)
+},
+

Re: [edk2-devel] EDK II Stable Tag release edk2-stable201905 completed

[Leif Lindholm]

On Wed, Jun 12, 2019 at 10:18:24AM +0200, Laszlo Ersek wrote:
> > In this instance, we explicitly don't care about the submodule for
> > that other project (and I really hope this is the norm) - so we
> > shouldn't be documenting steps that rely on that additional
> > submodule existing.
> 
> Yes; this is why I suggested dropping "--recursive" from the
> instructions. As far as I remember, it was meant as a convenience for
> users cloning the edk2 repo from zero.

But we've never actually relied on that behaviour, so it's not so much
convenience as cargo culting.

> > This is why I am referring to anything other than a central definition
> > of the relationship between edk2 and its submodules as a workaround. I
> > am not suggesting any shortcomings in the technical aspect.
> 
> Can you provide an example definition then? I'm having trouble imagining
> one.

Laszlo, I think you've misunderstood me somewhere.

What I am saying is:
- We should have a policy (i.e., a section in toplevel Readme.md)
  regarding submodules.
  - That policy *should* include the requirement to not permit
submodules requiring submodules for our purposes.
  - That policy should include the steps required to get the edk2
repository to a buildable state.
  - Nothing related to submodules should be documented anywhere else
in the tree. Sure, OpenSSL-HOWTO.txt can still be there, but
the section "HOW to Install OpenSSL for UEFI Building" should go.

Regards,

Leif

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

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

Re: [edk2-devel] UEFI SCT Build Broken

[Eric Jin]

Hi Ashish,

Thank for raising this issue.
UEFI SCT build pass with edk2-stable201903, and fail on edk2-stable201905, 
because edk2 drop the IPF support (4e1daa60f5372c22a11503961061ffa569eaf873).
UEFI SCT can remove IPF support too. I can follow it tomorrow. Thanks.


Best Regards
Eric

From: Ashish Singhal 
Sent: Wednesday, June 12, 2019 4:26 AM
To: Supreeth Venkatesh ; Jin, Eric 
; devel@edk2.groups.io
Subject: Re: UEFI SCT Build Broken

Supreeth,

It is broken against both edk2 tip as well as latest edk2 tag edk2-stable201903.

I have filed a bugzilla 
bug for the same.

Thanks
Ashish

From: Supreeth Venkatesh 
mailto:supreeth.venkat...@arm.com>>
Sent: Tuesday, June 11, 2019 1:36 PM
To: Ashish Singhal; Eric Jin; devel@edk2.groups.io
Subject: RE: UEFI SCT Build Broken


Ashish,



We are working towards fixing the issue for the next SCT tag corresponding to 
edk2 tag.

Can you please let us know whether you are referring to edk2 tip or which edk2 
tag (edk2-stable201903)?



If possible, could you log a bug entry in bugzillafor edk2-test/SCT component?



Thanks,

Supreeth



From: Ashish Singhal mailto:ashishsin...@nvidia.com>>
Sent: Tuesday, June 11, 2019 12:18 PM
To: Supreeth Venkatesh 
mailto:supreeth.venkat...@arm.com>>; Eric Jin 
mailto:eric@intel.com>>; 
devel@edk2.groups.io
Subject: UEFI SCT Build Broken



Hello Eric/Supreeth,



With the latest edk2 tag, UEFI SCT tip build is broken. Seems like it needs 
Guid/SalSystemTable.h header file which is not in edk2 tree any more. Is a fix 
for this already being looked at?



Thanks

Ashish



This email message is for the sole use of the intended recipient(s) and may 
contain confidential information.  Any unauthorized review, use, disclosure or 
distribution is prohibited.  If you are not the intended recipient, please 
contact the sender by reply email and destroy all copies of the original 
message.


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.

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

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

Re: [edk2-devel] [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency

[David Woodhouse]

On Wed, 2019-06-12 at 09:58 +0200, Laszlo Ersek wrote:
> Ray,
> 
> On 06/12/19 04:13, Wu, Hao A wrote:
> > > -Original Message-
> > > From: Ni, Ray
> > > Sent: Wednesday, June 12, 2019 10:04 AM
> > > To: Wu, Hao A; David Woodhouse; Justen, Jordan L; devel@edk2.groups.io
> > > Cc: Laszlo Ersek; Ard Biesheuvel; Phillips, D Scott
> > > Subject: RE: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg
> > > dependency
> > > 
> > > Hao,
> > > Will the CSM duplication cause any code change that may impact CSM
> > > functionality?
> > 
> > Hello Ray,
> > 
> > I think there should be no functional impact for the duplication.
> > There is no change to the .C/.H files.
> > 
> > Best Regards,
> > Hao Wu
> > 
> > > If no, how about firstly duplicate them first?
> > > 
> > > David,
> > > Will this approach work for you?
> 
> It will not work for me.
> 
> Here's the problem:
> 
> - I'm not comfortable approving the duplication (or move) under OvmfPkg,
> until David ACKs the patch -- the first patch in the series -- that
> spells out his reviewership for the CSM modules,

I'll certainly ack that.

> - I believe David is not comfortable ACKing that patch until he can get
> the CSM build to work again.

I'm OK with it as long as the submitter has done their own testing and
confirms that it works at least as well as it did before. It does get
quite a long way into 16-bit code and then does somewhere in the CSM
itself, after a few legacy BIOS calls.


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

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



smime.p7s
Description: S/MIME cryptographic signature

Re: [edk2-devel][Patch v2 2/7] MdeModulePkg: Add Capsule On Disk related definition.

[Xu, Wei6]

Hi Hao,

Thanks a lot for the comments. It comes from the feedback of SDL review. 
The PcdCapsuleOnDiskSupport only has type of '[PcdsFixedAtBuild, 
PcdsPatchableInModule]', so that Capsule On Disk feature can be configured by 
platform during build time, to ensure the feature will be permanently removed.

BR,
Wei
-Original Message-
From: Wu, Hao A 
Sent: Wednesday, June 12, 2019 3:48 PM
To: devel@edk2.groups.io; Xu, Wei6 
Cc: Wang, Jian J ; Zhang, Chao B 
Subject: RE: [edk2-devel][Patch v2 2/7] MdeModulePkg: Add Capsule On Disk 
related definition.

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of 
> Xu,
> Wei6
> Sent: Wednesday, June 05, 2019 11:42 PM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J; Wu, Hao A; Zhang, Chao B; Xu, Wei6
> Subject: [edk2-devel][Patch v2 2/7] MdeModulePkg: Add Capsule On Disk 
> related definition.
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1852
> 
> This patch will add Capsule On Disk related definition, including 
> GUID, PPI and PCDs:
> The Capsule On Disk Name GUID indicates the capsule is to store 
> Capsule On Disk file names.
> The Pei Capsule On Disk PPI provides service to retrieve capsules from 
> Capsule On Disk temp relocation file on mass storage devices and 
> create capsule hob for these capsules.
> PcdCapsuleOnDiskSupport is used to enable/disable Capsule On Disk.
> PcdCapsuleInRamSupport is used to enabble/disable Capsule In Ram.

enabble -> enable

May I know the reason that PcdCapsuleOnDiskSupport is listed under section 
'[PcdsFixedAtBuild, PcdsPatchableInModule]' while PcdCapsuleInRamSupport is 
listed under '[PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, 
PcdsDynamicEx]'?

Best Regards,
Hao Wu

> PcdCoDRelocationFileName specifies the Capsule On Disk temp relocation 
> file name.
> PcdCodRelocationDevPath specifies platform specific device to store 
> Capsule On Disk tem relocation file.
> 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Cc: Chao B Zhang 
> Signed-off-by: Wei6 Xu 
> ---
>  MdeModulePkg/Include/Ppi/CapsuleOnDisk.h | 48
> 
>  MdeModulePkg/MdeModulePkg.dec| 43
> 
>  MdeModulePkg/MdeModulePkg.uni| 32 +
>  3 files changed, 123 insertions(+)
>  create mode 100644 MdeModulePkg/Include/Ppi/CapsuleOnDisk.h
> 
> diff --git a/MdeModulePkg/Include/Ppi/CapsuleOnDisk.h
> b/MdeModulePkg/Include/Ppi/CapsuleOnDisk.h
> new file mode 100644
> index 00..28be6e42be
> --- /dev/null
> +++ b/MdeModulePkg/Include/Ppi/CapsuleOnDisk.h
> @@ -0,0 +1,48 @@
> +/** @file
> +  This file declares Capsule On Disk PPI.  This PPI is used to find 
> +and load the
> +  capsule on files that are relocated into a temp file under rootdir.
> +
> +  Copyright (c) 2019, Intel Corporation. All rights reserved.
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#ifndef __PEI_CAPSULE_ON_DISK_PPI_H__ #define 
> +__PEI_CAPSULE_ON_DISK_PPI_H__
> +
> +#define EFI_PEI_CAPSULE_ON_DISK_PPI_GUID \
> +  { \
> +0x71a9ea61, 0x5a35, 0x4a5d, {0xac, 0xef, 0x9c, 0xf8, 0x6d, 0x6d, 
> +0x67,
> 0xe0 } \
> +  }
> +
> +typedef struct _EFI_PEI_CAPSULE_ON_DISK_PPI
> EFI_PEI_CAPSULE_ON_DISK_PPI;
> +
> +/**
> +  Loads a DXE capsule from some media into memory and updates the HOB
> table
> +  with the DXE firmware volume information.
> +
> +  @param  PeiServices   General-purpose services that are available to every
> PEIM.
> +  @param  This  Indicates the EFI_PEI_RECOVERY_MODULE_PPI instance.
> +
> +  @retval EFI_SUCCESSThe capsule was loaded correctly.
> +  @retval EFI_DEVICE_ERROR   A device error occurred.
> +  @retval EFI_NOT_FOUND  A recovery DXE capsule cannot be found.
> +
> +**/
> +typedef
> +EFI_STATUS
> +(EFIAPI *EFI_PEI_LOAD_CAPSULE_ON_DISK)(
> +  IN EFI_PEI_SERVICES **PeiServices,
> +  IN EFI_PEI_CAPSULE_ON_DISK_PPI  *This
> +  );
> +
> +///
> +///  Finds and loads the recovery files.
> +///
> +struct _EFI_PEI_CAPSULE_ON_DISK_PPI {
> +  EFI_PEI_LOAD_CAPSULE_ON_DISK LoadCapsuleOnDisk;  ///< Loads a DXE
> binary capsule into memory.
> +};
> +
> +extern EFI_GUID gEdkiiPeiCapsuleOnDiskPpiGuid;
> +
> +#endif
> diff --git a/MdeModulePkg/MdeModulePkg.dec 
> b/MdeModulePkg/MdeModulePkg.dec index 6cba729982..d80b728313 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -394,10 +394,13 @@
>gEdkiiS3SmmInitDoneGuid = { 0x8f9d4825, 0x797d, 0x48fc, { 0x84, 
> 0x71, 0x84, 0x50, 0x25, 0x79, 0x2e, 0xf6 } }
> 
>## Include/Guid/S3StorageDeviceInitList.h
>gS3StorageDeviceInitListGuid = { 0x310e9b8c, 0xcf90, 0x421e, { 
> 0x8e, 0x9b, 0x9e, 0xef, 0xb6, 0x17, 0xc8, 0xef } }
> 
> +  ## GUID indicates the capsule is to store Capsule On Disk file names.
> +  gEdkiiCapsuleOnDiskNameGuid = { 0x98c80a4f, 0xe16b, 0x4d11, { 0x93,
> 0x9a, 0xab, 0xe5, 0x61, 0x26, 0x3, 0x30 } }
> +
>  [Ppis]
>## Include/Ppi/AtaController.h
>

Re: [edk2-devel] [PATCH] CryptoPkg: Add lacking instances for build only

[Laszlo Ersek]

On 06/12/19 04:39, Gao, Zhichao wrote:
> From: Bret Barkelew 
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1900
> 
> Add the lacking instance to [Componnets] of dsc file
> for build only.
> 
> Cc: Jian Wang 
> Cc: Ting Ye 
> Cc: Liming Gao 
> Cc: Sean Brogan 
> Cc: Michael Turner 
> Cc: Bret Barkelew 
> Signed-off-by: Zhichao Gao 
> ---
>  CryptoPkg/CryptoPkg.dsc | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/CryptoPkg/CryptoPkg.dsc b/CryptoPkg/CryptoPkg.dsc
> index 9dfa349f6d..c90e76c721 100644
> --- a/CryptoPkg/CryptoPkg.dsc
> +++ b/CryptoPkg/CryptoPkg.dsc
> @@ -116,6 +116,7 @@
>CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
>CryptoPkg/Library/TlsLib/TlsLib.inf
>CryptoPkg/Library/OpensslLib/OpensslLib.inf
> +  CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
>  
>  [Components.IA32, Components.X64]
>CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
> 

I'd like to suggest wording / spelling improvements:

- [Componnets] should be [Components]

- While I'm not a native English speaker, I believe "missing" would be
more precise than "lacking". To me, "lacking" implies that the library
instances in question have shortcomings. However, that's not what we
mean here -- those library instances are just fine, they are just
missing from the DSC files. Hence my suggestion to say "missing" (in
both the subject line and the commit message).

Thank you
Laszlo

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

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

Re: [edk2-devel] [PATCH] MdeModulePkg/PeiMain: Substantial change for PeiAllocatePool

[Laszlo Ersek]

Hi Zhichao,

On 06/12/19 06:50, Gao, Zhichao wrote:
> From: Bret Barkelew 
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1901
> 
> The original logic is ASSERT if fail to create HOB. But
> that doesn't make sense for release version. So it is required
> to set the Buffer to null to indicate the failure.

this patch may or may not be worthwhile; that's for the PEI Core
maintainers to evaluate.

Either way, the subject line is completely useless. "Substantial change"
means nothing at all. Please write a subject line that reflects what
this patch *actually does*.

For example:

MdeModulePkg/PeiMain: PeiAllocatePool: output NULL if HOB creation fails

(72 characters).

Thanks
Laszlo

> Cc: Jian J Wang 
> Cc: Hao Wu 
> Cc: Ray Ni 
> Cc: Star Zeng 
> Cc: Liming Gao 
> Cc: Sean Brogan 
> Cc: Michael Turner 
> Cc: Bret Barkelew 
> Signed-off-by: Zhichao Gao 
> ---
>  MdeModulePkg/Core/Pei/Memory/MemoryServices.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Core/Pei/Memory/MemoryServices.c 
> b/MdeModulePkg/Core/Pei/Memory/MemoryServices.c
> index 42f79ab076..37b0cfa3cf 100644
> --- a/MdeModulePkg/Core/Pei/Memory/MemoryServices.c
> +++ b/MdeModulePkg/Core/Pei/Memory/MemoryServices.c
> @@ -802,7 +802,12 @@ PeiAllocatePool (
>   (VOID **)
>   );
>ASSERT_EFI_ERROR (Status);
> -  *Buffer = Hob+1;
> +
> +  if (EFI_ERROR (Status)) {
> +*Buffer = NULL;
> +  } else {
> +*Buffer = Hob+1;
> +  }
>  
>return Status;
>  }
> 


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

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

Re: [edk2-devel][Patch v2 1/7] MdePkg: Add Pei Boot In CapsuleOnDisk Mode Ppi definition.

[Liming Gao]

Wei:

>-Original Message-
>From: Wu, Hao A
>Sent: Wednesday, June 12, 2019 3:48 PM
>To: devel@edk2.groups.io; Xu, Wei6 
>Cc: Kinney, Michael D ; Gao, Liming
>; Zhang, Chao B 
>Subject: RE: [edk2-devel][Patch v2 1/7] MdePkg: Add Pei Boot In
>CapsuleOnDisk Mode Ppi definition.
>
>> -Original Message-
>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>Xu,
>> Wei6
>> Sent: Wednesday, June 05, 2019 11:42 PM
>> To: devel@edk2.groups.io
>> Cc: Kinney, Michael D; Gao, Liming; Zhang, Chao B; Xu, Wei6
>> Subject: [edk2-devel][Patch v2 1/7] MdePkg: Add Pei Boot In CapsuleOnDisk
>> Mode Ppi definition.
>>
>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1852
>>
>> This PPI indicates current boot mode is capsule on disk mode.
>>
>> Cc: Michael D Kinney 
>> Cc: Liming Gao 
>> Cc: Chao B Zhang 
>> Signed-off-by: Wei6 Xu 
>> ---
>>  MdePkg/Include/Ppi/BootInRecoveryMode.h | 9 -
>>  MdePkg/MdePkg.dec   | 3 +++
>>  2 files changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/MdePkg/Include/Ppi/BootInRecoveryMode.h
>> b/MdePkg/Include/Ppi/BootInRecoveryMode.h
>> index ae40744d9b..71b0ca8586 100644
>> --- a/MdePkg/Include/Ppi/BootInRecoveryMode.h
>> +++ b/MdePkg/Include/Ppi/BootInRecoveryMode.h
>> @@ -1,10 +1,10 @@
>>  /** @file
>>This PPI is installed by the platform PEIM to designate that a recovery 
>> boot
>>is in progress.
>>
>> -  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
>> +  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>>SPDX-License-Identifier: BSD-2-Clause-Patent
>>
>>@par Revision Reference:
>>This PPI is introduced in PI Version 1.0.
>>
>> @@ -19,6 +19,13 @@
>>}
>>
>>
>>  extern EFI_GUID gEfiPeiBootInRecoveryModePpiGuid;
>>
>> +#define EFI_PEI_BOOT_IN_CAPSULE_ON_DISK_MODE_PPI \
>> +  { \
>> +0xb08a11e4, 0xe2b7, 0x4b75, { 0xb5, 0x15, 0xaf, 0x61, 0x6, 0x68, 0xbf,
>> 0xd1 } \
>> +  }
>> +
>> +extern EFI_GUID gEfiPeiBootInCapsuleOnDiskModePpiGuid;
>> +
>
>Hello all,
>
>One question, the above PPI will be added in the next PI spec, right?
>Since I cannot find this definition within the PI 1.7 spec.
>

If this is not defined in PI spec, it belongs to edk2 implementation related 
PPI. 
For this feature, I suggest to add It into MdeModulePkg with Edkii prefix. 

>Best Regards,
>Hao Wu
>
>>  #endif
>> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
>> index 6c563375ee..ec02b8c7c7 100644
>> --- a/MdePkg/MdePkg.dec
>> +++ b/MdePkg/MdePkg.dec
>> @@ -790,10 +790,13 @@
>>gEfiPeiMemoryDiscoveredPpiGuid = {0xf894643d, 0xc449, 0x42d1, {0x8e,
>> 0xa8, 0x85, 0xbd, 0xd8, 0xc6, 0x5b, 0xde } }
>>
>>## Include/Ppi/BootInRecoveryMode.h
>>gEfiPeiBootInRecoveryModePpiGuid = { 0x17ee496a, 0xd8e4, 0x4b9a,
>{0x94,
>> 0xd1, 0xce, 0x82, 0x72, 0x30, 0x8, 0x50 } }
>>
>> +  ## Include/Ppi/BootInRecoveryMode.h
>> +  gEfiPeiBootInCapsuleOnDiskModePpiGuid = { 0xb08a11e4, 0xe2b7,
>0x4b75,
>> { 0xb5, 0x15, 0xaf, 0x61, 0x6, 0x68, 0xbf, 0xd1 } }
>> +
>>## Include/Ppi/EndOfPeiPhase.h
>>gEfiEndOfPeiSignalPpiGuid = {0x605EA650, 0xC65C, 0x42e1, {0xBA, 0x80,
>> 0x91, 0xA5, 0x2A, 0xB6, 0x18, 0xC6 } }
>>
>>## Include/Ppi/Reset.h
>>gEfiPeiResetPpiGuid = { 0xef398d58, 0x9dfd, 0x4103, {0xbf, 0x94, 0x78,
>0xc6,
>> 0xf4, 0xfe, 0x71, 0x2f } }
>> --
>> 2.16.2.windows.1
>>
>>
>> 


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

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

Re: [edk2-devel][Patch v2 0/7] Implement Capsule On Disk.

[Zhang, Chao B]

HI Hao:
  I don't have extra comments for the whole patch

From: Wu, Hao A
Sent: Wednesday, June 12, 2019 3:48 PM
To: devel@edk2.groups.io; Xu, Wei6 ; Zhang, Chao B 

Cc: Wang, Jian J ; Kinney, Michael D 
; Gao, Liming 
Subject: RE: [edk2-devel][Patch v2 0/7] Implement Capsule On Disk.

Hello Chao,

Do you have any comment/feedback on this series?

One comment with regard to the series below:

> -Original Message-
> From: devel@edk2.groups.io 
> [mailto:devel@edk2.groups.io] On Behalf Of
> Xu, Wei6
> Sent: Wednesday, June 05, 2019 11:42 PM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J; Wu, Hao A; Kinney, Michael D; Gao, Liming; Zhang, Chao B
> Subject: [edk2-devel][Patch v2 0/7] Implement Capsule On Disk.
>
> V2:
> Fix Ecc check failure.
>
> V1:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1852
>
> This patch set implements Capsule On Disk.
> Depends on whether platform supports Capsule-In-Ram, Capsule On Disk
> feature is composed of 2 solutions:
> Solution A): Load capsules out of TCB, rely on UpdateCapsule() runtime
> service to deliver Capsule-On-Disk.
> Solution B): Relocate capsules into a temp file which will be stored in root
> directory on a platform specific storage device.
> Leverage existing storage stack in PEI to load all capsule on disk images and
> create capsule hobs for the capsules.
> This solution has bigger TCB, but can work without Capsule-In-RAM support.
>
>
> Cc: Jian J Wang mailto:jian.j.w...@intel.com>>
> Cc: Hao A Wu mailto:hao.a...@intel.com>>
> Cc: Michael D Kinney 
> mailto:michael.d.kin...@intel.com>>
> Cc: Liming Gao mailto:liming@intel.com>>
> Cc: Chao B Zhang mailto:chao.b.zh...@intel.com>>
>
> xuwei6 (7):
>   MdePkg: Add Pei Boot In CapsuleOnDisk Mode Ppi definition.
>   MdeModulePkg: Add Capsule On Disk related definition.
>   MdeModulePkg: Add CapsuleOnDiskLoadPei PEIM.
>   MdeModulePkg/BdsDxe: Support Capsule On Disk.
>   MdeModulePkg/CapsuleRuntimeDxe: Introduce PCD to control this feature.
>   MdeModulePkg/DxeIpl: Support Capsule On Disk.
>   MdeModulePkg: Add Capsule On Disk APIs into CapsuleLib.


Please re-order the sequence of the patches.
I found that the below patch:
MdeModulePkg: Add CapsuleOnDiskLoadPei PEIM.

depends on some definitions added in patch (last one):
MdeModulePkg: Add Capsule On Disk APIs into CapsuleLib.

Best Regards,
Hao Wu


>
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.h  |3 +-
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf|   20 +-
>  MdeModulePkg/Core/DxeIplPeim/DxeLoad.c |   37 +-
>  MdeModulePkg/Include/Library/CapsuleLib.h  |   94 +-
>  MdeModulePkg/Include/Ppi/CapsuleOnDisk.h   |   48 +
>  .../Library/DxeCapsuleLibFmp/CapsuleOnDisk.c   | 1983
> 
>  .../Library/DxeCapsuleLibFmp/CapsuleOnDisk.h   |   63 +
>  .../Library/DxeCapsuleLibFmp/DxeCapsuleLib.c   |   56 +-
>  .../Library/DxeCapsuleLibFmp/DxeCapsuleLib.inf |   21 +-
>  .../DxeCapsuleLibFmp/DxeCapsuleProcessLib.c|  121 +-
>  .../Library/DxeCapsuleLibFmp/DxeCapsuleReportLib.c |   67 +-
>  .../DxeCapsuleLibFmp/DxeRuntimeCapsuleLib.inf  |3 +-
>  .../Library/DxeCapsuleLibNull/DxeCapsuleLibNull.c  |   85 +-
>  MdeModulePkg/MdeModulePkg.dec  |   43 +
>  MdeModulePkg/MdeModulePkg.dsc  |4 +
>  MdeModulePkg/MdeModulePkg.uni  |   32 +
>  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf   |3 +-
>  MdeModulePkg/Universal/BdsDxe/BdsEntry.c   |6 +-
>  .../CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.c|  442 +
>  .../CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.inf  |   64 +
>  .../CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.uni  |   15 +
>  .../CapsuleOnDiskLoadPeiExtra.uni  |   14 +
>  .../CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf|1 +
>  .../Universal/CapsuleRuntimeDxe/CapsuleService.c   |   10 +-
>  MdePkg/Include/Ppi/BootInRecoveryMode.h|9 +-
>  MdePkg/MdePkg.dec  |3 +
>  26 files changed, 3205 insertions(+), 42 deletions(-)
>  create mode 100644 MdeModulePkg/Include/Ppi/CapsuleOnDisk.h
>  create mode 100644
> MdeModulePkg/Library/DxeCapsuleLibFmp/CapsuleOnDisk.c
>  create mode 100644
> MdeModulePkg/Library/DxeCapsuleLibFmp/CapsuleOnDisk.h
>  create mode 100644
> MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.c
>  create mode 100644
> MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.i
> nf
>  create mode 100644
> MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.u
> ni
>  create mode 100644
> MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPeiE
> xtra.uni
>
> --
> 2.16.2.windows.1
>
>
> 

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

View/Reply Online (#42269): https://edk2.groups.io/g/devel/message/42269
Mute This Topic: https://groups.io/mt/31938573/21656

Re: [edk2-devel] [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency

[Laszlo Ersek]

Ray,

On 06/12/19 04:13, Wu, Hao A wrote:
>> -Original Message-
>> From: Ni, Ray
>> Sent: Wednesday, June 12, 2019 10:04 AM
>> To: Wu, Hao A; David Woodhouse; Justen, Jordan L; devel@edk2.groups.io
>> Cc: Laszlo Ersek; Ard Biesheuvel; Phillips, D Scott
>> Subject: RE: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg
>> dependency
>>
>> Hao,
>> Will the CSM duplication cause any code change that may impact CSM
>> functionality?
> 
> Hello Ray,
> 
> I think there should be no functional impact for the duplication.
> There is no change to the .C/.H files.
> 
> Best Regards,
> Hao Wu
> 
>> If no, how about firstly duplicate them first?
>>
>> David,
>> Will this approach work for you?

It will not work for me.

Here's the problem:

- I'm not comfortable approving the duplication (or move) under OvmfPkg,
until David ACKs the patch -- the first patch in the series -- that
spells out his reviewership for the CSM modules,

- I believe David is not comfortable ACKing that patch until he can get
the CSM build to work again.

Thanks
Laszlo

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

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

Re: [edk2-devel] ExtScsiPassThru support for Logical SCSI devices

[Wu, Hao A]

Hello Ravi Kumar,

Inline comments below:

From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Ravi 
Kumar Siadri
Sent: Wednesday, June 12, 2019 12:01 PM
To: devel@edk2.groups.io
Subject: Re: [edk2-devel] ExtScsiPassThru support for Logical SCSI devices

Hi,

Can someone help me in clarifying my queries ??

Thanks,
Ravi Kumar

On Mon, Jun 10, 2019 at 3:55 PM Ravi Kumar Siadri 
mailto:siadriravikumaru...@gmail.com>> wrote:
Hi all,

I have couple of queries regarding the 
EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_LOGICAL attribute support in 
EFI_EXT_SCSI_PASS_THRU_PROTOCOL.

1.
The Attributes field of the EFI_EXT_SCSI_PASS_THRU_PROTOCOL interface tells if 
the interface is for physical SCSI devices or logical SCSI devices. Drivers for 
non-RAID SCSI controllers will set both the 
EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_PHYSICAL, and the 
EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_LOGICAL bits.

If the Drivers is for non-RAID SCSI controllers why to set the 
EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_LOGICAL bit. Will there be any case that 
non-RAID SCSI controllers have Logical devices connected to it ??

Per my understanding, every partition on a physical HW device will be treated
as a logical device by the firmware.

So for non-RAID case, both bits will be set for the PassThru protocol produced
for the physical device.


2.
Drivers for RAID controllers that allow access to the physical devices and 
logical devices will produce two EFI_EXT_SCSI_PASS_THRU_PROTOCOL interfaces:
One with the just the EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_PHYSICAL bit set and 
another with just the EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_LOGICAL bit set. One 
interface can be used to access the physical devices attached to the RAID 
controller, and the other can be used to access the logical devices attached to 
the RAID controller for its current configuration.

Any background why EFI_EXT_SCSI_PASS_THRU_PROTOCOL needed 2 instances ? why 
can't we install attributes EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_LOGICAL and 
EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_PHYSICAL on same Instance ??
How User locates the Instance with EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_LOGICAL 
bit set and Instance with EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_PHYSICAL bit set. ??

UEFI spec allows RAID drivers to only produce one PassThru protocol interface
with just the XXX_PASS_THRU_LOGICAL bit set when the RAID controller select to
not allow direct access to the underlying physical devices.


Thanks,
Ravi Kumar



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

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

Re: [edk2-devel] [PATCH 0/2] EdkRepo - The Multi-Repository Tool for EDK II

[Laszlo Ersek]

Hi Nate,

On 06/12/19 02:04, Nate DeSimone wrote:
> This patch series is raised to add the EdkRepo and EdkRepo-Manifest branches
> to the Edk2-Staging repository. These branches are added to host EdkRepo,
> the multi-repository tool for EDK II firmware development to TianoCore.
> 
> For more details on EdkRepo, please see my RFC.
> 
> Nate DeSimone (2):
>   Add EdkRepo - The Multi-Repo Tool
>   Add EdkRepo manifest XML
> 

the Maintainers.txt files added in both patches contain sections called
"EDK II" and "EDK II Packages". Is that intended? (I'm not familiar with
branches in the staging repo.)

No comments from me otherwise, I'll defer to the other stewards on this.

Thanks!
Laszlo

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

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

Re: [edk2-devel][Patch v2 7/7] MdeModulePkg: Add Capsule On Disk APIs into CapsuleLib.

[Wu, Hao A]

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Xu,
> Wei6
> Sent: Wednesday, June 05, 2019 11:42 PM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J; Wu, Hao A; Zhang, Chao B; Xu, Wei6
> Subject: [edk2-devel][Patch v2 7/7] MdeModulePkg: Add Capsule On Disk
> APIs into CapsuleLib.


Not directly related with this patch, I saw many function declarations
within .C file for this library. Could you help to propose another series
to add header files to address this (Maybe like the case in
MdeModulePkg/Universal/Variable/RuntimeDxe to handle multi-phases).


Some general level comments:

I saw some of the new functions whose scope is limited within a single
file have been decorated with keyword 'STATIC'. Could you help to make it
consistent for all the newly added global variables/functions? Also, could
you help to use keyword 'static' (lower case) instead?


> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1852
> 
> CoDCheckCapsuleOnDiskFlag() is to check if CapsuleOnDisk flag in
> "OsIndications" Variable is enabled. It is used to indicate whether
> capsule on disk is provisioned in normal boot path.
> 
> CoDClearCapsuleOnDiskFlag() is to to clear CapsuleOnDisk flags,
> including "OsIndications" and "BootNext" variable.
> 
> CoDRelocateCapsule() is to relocate the capsules from EFI system
> partition. Depends on PcdCapsuleInRamSupport, there are two solutions
> to relocate the capsule on disk images:
> When Capsule In Ram is supported, the Capsule On Disk images are
> relocated into memory, and call UpdateCapsule() service to deliver
> the capsules.
> When Capsule In Ram is not supported, the Capsule On Disk images are
> relocated into a temp file which will be stored in root directory on
> a platform specific storage device. CapsuleOnDiskLoadPei PEIM will
> retrieve the capsules from the relocation temp file and report
> capsule hobs for them.
> 
> CoDRemoveTempFile() is to remove the relocation temp file in the next
> boot after capsules are processed.
> 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Cc: Chao B Zhang 
> Signed-off-by: Wei6 Xu 
> ---
>  MdeModulePkg/Include/Library/CapsuleLib.h  |   94 +-
>  .../Library/DxeCapsuleLibFmp/CapsuleOnDisk.c   | 1983
> 
>  .../Library/DxeCapsuleLibFmp/CapsuleOnDisk.h   |   63 +
>  .../Library/DxeCapsuleLibFmp/DxeCapsuleLib.c   |   56 +-
>  .../Library/DxeCapsuleLibFmp/DxeCapsuleLib.inf |   21 +-
>  .../DxeCapsuleLibFmp/DxeCapsuleProcessLib.c|  121 +-
>  .../Library/DxeCapsuleLibFmp/DxeCapsuleReportLib.c |   67 +-
>  .../DxeCapsuleLibFmp/DxeRuntimeCapsuleLib.inf  |3 +-
>  .../Library/DxeCapsuleLibNull/DxeCapsuleLibNull.c  |   85 +-
>  9 files changed, 2466 insertions(+), 27 deletions(-)
>  create mode 100644
> MdeModulePkg/Library/DxeCapsuleLibFmp/CapsuleOnDisk.c
>  create mode 100644
> MdeModulePkg/Library/DxeCapsuleLibFmp/CapsuleOnDisk.h
> 
> diff --git a/MdeModulePkg/Include/Library/CapsuleLib.h
> b/MdeModulePkg/Include/Library/CapsuleLib.h
> index 1fc2fba3a2..f3cb17cbf9 100644
> --- a/MdeModulePkg/Include/Library/CapsuleLib.h
> +++ b/MdeModulePkg/Include/Library/CapsuleLib.h
> @@ -1,17 +1,37 @@
>  /** @file
> 
>This library class defines a set of interfaces for how to process capsule
> image updates.
> 
> -Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.
>  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> 
>  #ifndef __CAPSULE_LIB_H__
>  #define __CAPSULE_LIB_H__
> 
> +#include 
> +
> +
> +typedef struct {
> +  //
> +  // image address.
> +  //
> +  VOID *ImageAddress;
> +  //
> +  // The file info of the image comes from.
> +  //  if FileInfo == NULL. means image does not come from file
> +  //
> +  EFI_FILE_INFO*FileInfo;
> +} IMAGE_INFO;


Will this 'IMAGE_INFO' structure (FileInfo.h include as well) be used by
the consumer of CapsuleLib? For this series, this one is only used within
DxeCapsuleLibFmp (implementation of CapsuleLib).

If it is only used internally, I suggest to move the definition into
MdeModulePkg\Library\DxeCapsuleLibFmp\CapsuleOnDisk.h.


> +
> +//
> +// BOOLEAN Variable to save the total size of all Capsule On Disk during
> relocation
> +//


The above description comment seems not matching the usage of the variable
perfectly. Looks to me the variable is used to reflect whether the system
is in the capsule on disk state rather than the size information.


> +#define COD_RELOCATION_INFO_VAR_NAME   L"CodRelocationInfo"
> +
>  /**
>The firmware checks whether the capsule image is supported
>by the CapsuleGuid in CapsuleHeader or if there is other specific
> information in
>the capsule image.
> 
> @@ -79,6 +99,78 @@ EFI_STATUS
>  EFIAPI
>  ProcessCapsules (
>VOID
>);
> 
> +/**
> +  This routine is called to check if CapsuleOnDisk flag in OsIndications
> Variable
> +  is enabled.
> +
> +  @retval TRUE 

Re: [edk2-devel][Patch v2 3/7] MdeModulePkg: Add CapsuleOnDiskLoadPei PEIM.

[Wu, Hao A]

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Xu,
> Wei6
> Sent: Wednesday, June 05, 2019 11:42 PM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J; Wu, Hao A; Zhang, Chao B; Xu, Wei6
> Subject: [edk2-devel][Patch v2 3/7] MdeModulePkg: Add
> CapsuleOnDiskLoadPei PEIM.
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1852
> 
> This module provides PPI to load Capsule On Disk temp relocation file
> from Root Directory file system, retrieve the capsules from the temp
> file and create capsule hobs for these capsules.
> 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Cc: Chao B Zhang 
> Signed-off-by: Wei6 Xu 
> ---
>  MdeModulePkg/MdeModulePkg.dsc  |   4 +
>  .../CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.c| 442
> +
>  .../CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.inf  |  64 +++
>  .../CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.uni  |  15 +
>  .../CapsuleOnDiskLoadPeiExtra.uni  |  14 +
>  5 files changed, 539 insertions(+)
>  create mode 100644
> MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.c
>  create mode 100644
> MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.in
> f
>  create mode 100644
> MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.u
> ni
>  create mode 100644
> MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPeiEx
> tra.uni

Since this a new module, could you help to follow the recommendation in
https://edk2.groups.io/g/devel/message/39655?p=,,,20,0,0,0::Created,,UefiDebugLibStdErr,20,2,0,3131

to add/update 'static' (lower case) for global variables/functions whose
scope is limited within a single file?

> 
> diff --git a/MdeModulePkg/MdeModulePkg.dsc
> b/MdeModulePkg/MdeModulePkg.dsc
> index 995fd805e1..615edddbcc 100644
> --- a/MdeModulePkg/MdeModulePkg.dsc
> +++ b/MdeModulePkg/MdeModulePkg.dsc
> @@ -197,10 +197,13 @@
>gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x06
>gEfiMdeModulePkgTokenSpaceGuid.PcdMaxSizeNonPopulateCapsule|0x0
>gEfiMdeModulePkgTokenSpaceGuid.PcdMaxSizePopulateCapsule|0x0
>gEfiMdeModulePkgTokenSpaceGuid.PcdMaxPeiPerformanceLogEntries|28
> 
> +[PcdsDynamicExDefault]
> +
> gEfiMdeModulePkgTokenSpaceGuid.PcdRecoveryFileName|L"FVMAIN.FV"
> +
>  [Components]
>MdeModulePkg/Application/HelloWorld/HelloWorld.inf
>MdeModulePkg/Application/DumpDynPcd/DumpDynPcd.inf
>MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.inf
> 
> @@ -315,10 +318,11 @@
> 
> NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMainte
> nanceManagerUiLib.inf
>}
> 
> MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManager
> Dxe.inf
> 
> MdeModulePkg/Universal/BootManagerPolicyDxe/BootManagerPolicyDxe.i
> nf
>MdeModulePkg/Universal/CapsulePei/CapsulePei.inf
> +
> MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.in
> f
>MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
>MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
>MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
> 
> MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleD
> xe.inf
> 
> MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutputDx
> e.inf
> diff --git
> a/MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.
> c
> b/MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.
> c
> new file mode 100644
> index 00..40d25f3d3b
> --- /dev/null
> +++
> b/MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.
> c
> @@ -0,0 +1,442 @@
> +/** @file
> +  Recovery module.
> +
> +  Caution: This module requires additional review when modified.
> +  This module will have external input - Capsule-on-Disk Temp Relocation
> image.
> +  This external input must be validated carefully to avoid security issue 
> like
> +  buffer overflow, integer overflow.
> +
> +  RetrieveRelocatedCapsule() will receive untrusted input and do basic
> validation.
> +
> +  Copyright (c) 2019, Intel Corporation. All rights reserved.
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +//
> +// The package level header files this module uses
> +//
> +#include 
> +#include 
> +
> +//
> +// The protocols, PPI and GUID defintions for this module
> +//
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +//
> +// The Library classes this module consumes
> +//
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/**
> +  Loads a DXE capsule from some media into memory and updates the HOB
> table
> +  with the DXE firmware volume information.
> +
> +  @param[in]  PeiServices   General-purpose services that are available to
> every PEIM.
> +  @param[in]  This  Indicates the EFI_PEI_RECOVERY_MODULE_PPI
> instance.
> +
> +  @retval EFI_SUCCESSThe capsule was loaded correctly.

Re: [edk2-devel][Patch v2 2/7] MdeModulePkg: Add Capsule On Disk related definition.

[Wu, Hao A]

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Xu,
> Wei6
> Sent: Wednesday, June 05, 2019 11:42 PM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J; Wu, Hao A; Zhang, Chao B; Xu, Wei6
> Subject: [edk2-devel][Patch v2 2/7] MdeModulePkg: Add Capsule On Disk
> related definition.
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1852
> 
> This patch will add Capsule On Disk related definition, including
> GUID, PPI and PCDs:
> The Capsule On Disk Name GUID indicates the capsule is to store
> Capsule On Disk file names.
> The Pei Capsule On Disk PPI provides service to retrieve capsules
> from Capsule On Disk temp relocation file on mass storage devices
> and create capsule hob for these capsules.
> PcdCapsuleOnDiskSupport is used to enable/disable Capsule On Disk.
> PcdCapsuleInRamSupport is used to enabble/disable Capsule In Ram.

enabble -> enable

May I know the reason that PcdCapsuleOnDiskSupport is listed under section
'[PcdsFixedAtBuild, PcdsPatchableInModule]' while PcdCapsuleInRamSupport
is listed under
'[PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]'?

Best Regards,
Hao Wu

> PcdCoDRelocationFileName specifies the Capsule On Disk temp
> relocation file name.
> PcdCodRelocationDevPath specifies platform specific device to store
> Capsule On Disk tem relocation file.
> 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Cc: Chao B Zhang 
> Signed-off-by: Wei6 Xu 
> ---
>  MdeModulePkg/Include/Ppi/CapsuleOnDisk.h | 48
> 
>  MdeModulePkg/MdeModulePkg.dec| 43
> 
>  MdeModulePkg/MdeModulePkg.uni| 32 +
>  3 files changed, 123 insertions(+)
>  create mode 100644 MdeModulePkg/Include/Ppi/CapsuleOnDisk.h
> 
> diff --git a/MdeModulePkg/Include/Ppi/CapsuleOnDisk.h
> b/MdeModulePkg/Include/Ppi/CapsuleOnDisk.h
> new file mode 100644
> index 00..28be6e42be
> --- /dev/null
> +++ b/MdeModulePkg/Include/Ppi/CapsuleOnDisk.h
> @@ -0,0 +1,48 @@
> +/** @file
> +  This file declares Capsule On Disk PPI.  This PPI is used to find and load 
> the
> +  capsule on files that are relocated into a temp file under rootdir.
> +
> +  Copyright (c) 2019, Intel Corporation. All rights reserved.
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#ifndef __PEI_CAPSULE_ON_DISK_PPI_H__
> +#define __PEI_CAPSULE_ON_DISK_PPI_H__
> +
> +#define EFI_PEI_CAPSULE_ON_DISK_PPI_GUID \
> +  { \
> +0x71a9ea61, 0x5a35, 0x4a5d, {0xac, 0xef, 0x9c, 0xf8, 0x6d, 0x6d, 0x67,
> 0xe0 } \
> +  }
> +
> +typedef struct _EFI_PEI_CAPSULE_ON_DISK_PPI
> EFI_PEI_CAPSULE_ON_DISK_PPI;
> +
> +/**
> +  Loads a DXE capsule from some media into memory and updates the HOB
> table
> +  with the DXE firmware volume information.
> +
> +  @param  PeiServices   General-purpose services that are available to every
> PEIM.
> +  @param  This  Indicates the EFI_PEI_RECOVERY_MODULE_PPI instance.
> +
> +  @retval EFI_SUCCESSThe capsule was loaded correctly.
> +  @retval EFI_DEVICE_ERROR   A device error occurred.
> +  @retval EFI_NOT_FOUND  A recovery DXE capsule cannot be found.
> +
> +**/
> +typedef
> +EFI_STATUS
> +(EFIAPI *EFI_PEI_LOAD_CAPSULE_ON_DISK)(
> +  IN EFI_PEI_SERVICES **PeiServices,
> +  IN EFI_PEI_CAPSULE_ON_DISK_PPI  *This
> +  );
> +
> +///
> +///  Finds and loads the recovery files.
> +///
> +struct _EFI_PEI_CAPSULE_ON_DISK_PPI {
> +  EFI_PEI_LOAD_CAPSULE_ON_DISK LoadCapsuleOnDisk;  ///< Loads a DXE
> binary capsule into memory.
> +};
> +
> +extern EFI_GUID gEdkiiPeiCapsuleOnDiskPpiGuid;
> +
> +#endif
> diff --git a/MdeModulePkg/MdeModulePkg.dec
> b/MdeModulePkg/MdeModulePkg.dec
> index 6cba729982..d80b728313 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -394,10 +394,13 @@
>gEdkiiS3SmmInitDoneGuid = { 0x8f9d4825, 0x797d, 0x48fc, { 0x84, 0x71,
> 0x84, 0x50, 0x25, 0x79, 0x2e, 0xf6 } }
> 
>## Include/Guid/S3StorageDeviceInitList.h
>gS3StorageDeviceInitListGuid = { 0x310e9b8c, 0xcf90, 0x421e, { 0x8e, 0x9b,
> 0x9e, 0xef, 0xb6, 0x17, 0xc8, 0xef } }
> 
> +  ## GUID indicates the capsule is to store Capsule On Disk file names.
> +  gEdkiiCapsuleOnDiskNameGuid = { 0x98c80a4f, 0xe16b, 0x4d11, { 0x93,
> 0x9a, 0xab, 0xe5, 0x61, 0x26, 0x3, 0x30 } }
> +
>  [Ppis]
>## Include/Ppi/AtaController.h
>gPeiAtaControllerPpiGuid   = { 0xa45e60d1, 0xc719, 0x44aa, { 0xb0, 
> 0x7a,
> 0xaa, 0x77, 0x7f, 0x85, 0x90, 0x6d }}
> 
>## Include/Ppi/UsbHostController.h
> @@ -464,10 +467,13 @@
>gEdkiiPeiAtaPassThruPpiGuid   = { 0xa16473fd, 0xd474, 0x4c89, 
> { 0xae,
> 0xc7, 0x90, 0xb8, 0x3c, 0x73, 0x86, 0x9  } }
> 
>## Include/Ppi/Debug.h
>gEdkiiDebugPpiGuid= { 0x999e699c, 0xb013, 0x475e, 
> { 0xb1,
> 0x7b, 0xf3, 0xa8, 0xae, 0x5c, 0x48, 0x75 } }
> 
> +  ## Include/Ppi/CapsuleOnDisk.h
> +  gEdkiiPeiCapsuleOnDiskPpiGuid =  {0x71a9ea61, 0x5a35, 

Re: [edk2-devel][Patch v2 5/7] MdeModulePkg/CapsuleRuntimeDxe: Introduce PCD to control this feature.

[Wu, Hao A]

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Xu,
> Wei6
> Sent: Wednesday, June 05, 2019 11:42 PM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J; Wu, Hao A; Zhang, Chao B; Xu, Wei6
> Subject: [edk2-devel][Patch v2 5/7] MdeModulePkg/CapsuleRuntimeDxe:
> Introduce PCD to control this feature.
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1852
> 
> Introduce PcdCapsuleInRamSupport to turn on/off Capsule In Ram feature.
> Platform could choose to drop CapsulePei/CapsuleX64 and not to support
> Capsule In Ram.


For this patch, it only affects UpdateCapsule(). Do we need to update the
behavior for QueryCapsuleCapabilities() as well?

Best Regards,
Hao Wu


> 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Cc: Chao B Zhang 
> Signed-off-by: Wei6 Xu 
> ---
>  MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf |  1
> +
>  MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleService.c  | 10
> +-
>  2 files changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git
> a/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
> b/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
> index 338577e293..9da450722b 100644
> ---
> a/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
> +++
> b/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
> @@ -88,10 +88,11 @@
>gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode  ##
> CONSUMES
> 
>  [Pcd]
>gEfiMdeModulePkgTokenSpaceGuid.PcdMaxSizeNonPopulateCapsule   ##
> SOMETIMES_CONSUMES
>gEfiMdeModulePkgTokenSpaceGuid.PcdMaxSizePopulateCapsule  ##
> SOMETIMES_CONSUMES # Populate Image requires reset support.
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdCapsuleInRamSupport ##
> CONSUMES
> 
>  [Pcd.X64]
>gEfiMdeModulePkgTokenSpaceGuid.PcdCapsulePeiLongModeStackSize
> ## SOMETIMES_CONSUMES
>gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable##
> SOMETIMES_CONSUMES
> 
> diff --git a/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleService.c
> b/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleService.c
> index aaf819c4c6..53a1af44e2 100644
> --- a/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleService.c
> +++ b/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleService.c
> @@ -2,11 +2,11 @@
>Capsule Runtime Driver produces two UEFI capsule runtime services.
>(UpdateCapsule, QueryCapsuleCapabilities)
>It installs the Capsule Architectural Protocol defined in PI1.0a to signify
>the capsule runtime services are ready.
> 
> -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> 
>  #include "CapsuleService.h"
> @@ -69,10 +69,18 @@ UpdateCapsule (
>BOOLEAN   NeedReset;
>BOOLEAN   InitiateReset;
>CHAR16CapsuleVarName[30];
>CHAR16*TempVarName;
> 
> +  //
> +  // Check if platform support Capsule In RAM or not.
> +  // Platform could choose to drop CapsulePei/CapsuleX64 and do not
> support Capsule In RAM.
> +  //
> +  if (!PcdGetBool(PcdCapsuleInRamSupport)) {
> +return EFI_UNSUPPORTED;
> +  }
> +
>//
>// Capsule Count can't be less than one.
>//
>if (CapsuleCount < 1) {
>  return EFI_INVALID_PARAMETER;
> --
> 2.16.2.windows.1
> 
> 
> 


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

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

Re: [edk2-devel][Patch v2 6/7] MdeModulePkg/DxeIpl: Support Capsule On Disk.

[Wu, Hao A]

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Xu,
> Wei6
> Sent: Wednesday, June 05, 2019 11:42 PM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J; Wu, Hao A; Zhang, Chao B; Xu, Wei6
> Subject: [edk2-devel][Patch v2 6/7] MdeModulePkg/DxeIpl: Support Capsule
> On Disk.
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1852
> 
> If Capsule On Disk mode, call Capsule On Disk Load PPI to load
> capsules. When it fails, still goes to Firmware Update boot path.
> BDS will clear corresponding indicator and reboot later on.
> 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Cc: Chao B Zhang 
> Signed-off-by: Wei6 Xu 
> ---
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.h   |  3 ++-
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf | 20 ++
>  MdeModulePkg/Core/DxeIplPeim/DxeLoad.c  | 37
> -
>  3 files changed, 49 insertions(+), 11 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> index 063fefb414..90b5b5b211 100644
> --- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> +++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> @@ -1,10 +1,10 @@
>  /** @file
>Master header file for DxeIpl PEIM. All source files in this module should
>include this file for common definitions.
> 
> -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> 
>  #ifndef __PEI_DXEIPL_H__
> @@ -19,10 +19,11 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> 
>  #include 
>  #include 
>  #include 
> diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> index 62bb3f3077..ff036d8688 100644
> --- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> +++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> @@ -3,11 +3,11 @@
>  #
>  #  This module produces a special PPI named the DXE Initial Program Load
> (IPL)
>  #  PPI to discover and dispatch the DXE Foundation and components that are
>  #  needed to run the DXE Foundation.
>  #
> -#  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>  #  Copyright (c) 2017, AMD Incorporated. All rights reserved.
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
>  ##
> @@ -74,21 +74,23 @@
> 
>  [LibraryClasses.ARM, LibraryClasses.AARCH64]
>ArmMmuLib
> 
>  [Ppis]
> -  gEfiDxeIplPpiGuid ## PRODUCES
> -  gEfiPeiDecompressPpiGuid  ## PRODUCES
> -  gEfiEndOfPeiSignalPpiGuid ## SOMETIMES_PRODUCES # Not produced
> on S3 boot path
> -  gEfiPeiReadOnlyVariable2PpiGuid   ## SOMETIMES_CONSUMES
> -  gEfiPeiLoadFilePpiGuid## SOMETIMES_CONSUMES
> -  gEfiPeiS3Resume2PpiGuid   ## SOMETIMES_CONSUMES # Consumed
> on S3 boot path
> -  gEfiPeiRecoveryModulePpiGuid  ## SOMETIMES_CONSUMES #
> Consumed on recovery boot path
> +  gEfiDxeIplPpiGuid  ## PRODUCES
> +  gEfiPeiDecompressPpiGuid   ## PRODUCES
> +  gEfiEndOfPeiSignalPpiGuid  ## SOMETIMES_PRODUCES # Not
> produced on S3 boot path
> +  gEfiPeiReadOnlyVariable2PpiGuid## SOMETIMES_CONSUMES
> +  gEfiPeiLoadFilePpiGuid ## SOMETIMES_CONSUMES
> +  gEfiPeiS3Resume2PpiGuid## SOMETIMES_CONSUMES #
> Consumed on S3 boot path
> +  gEfiPeiRecoveryModulePpiGuid   ## SOMETIMES_CONSUMES #
> Consumed on recovery boot path
>## SOMETIMES_CONSUMES
>## UNDEFINED # HOB
>gEfiVectorHandoffInfoPpiGuid
> -  gEfiPeiMemoryDiscoveredPpiGuid## SOMETIMES_CONSUMES
> +  gEfiPeiMemoryDiscoveredPpiGuid ## SOMETIMES_CONSUMES
> +  gEfiPeiBootInCapsuleOnDiskModePpiGuid  ## SOMETIMES_CONSUMES
> +  gEdkiiPeiCapsuleOnDiskPpiGuid  ## SOMETIMES_CONSUMES #
> Consumed on firmware update boot path
> 
>  [Guids]
>## SOMETIMES_CONSUMES ## Variable:L"MemoryTypeInformation"
>## SOMETIMES_PRODUCES ## HOB
>gEfiMemoryTypeInformationGuid
> diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeLoad.c
> b/MdeModulePkg/Core/DxeIplPeim/DxeLoad.c
> index c6e5b83309..9dc2d4485f 100644
> --- a/MdeModulePkg/Core/DxeIplPeim/DxeLoad.c
> +++ b/MdeModulePkg/Core/DxeIplPeim/DxeLoad.c
> @@ -1,11 +1,11 @@
>  /** @file
>Last PEIM.
>Responsibility of this module is to load the DXE Core from a Firmware
> Volume.
> 
>  Copyright (c) 2016 HP Development Company, L.P.
> -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> 
>  #include "DxeIpl.h"
> @@ -263,17 +263,38 @@ DxeLoadCore (
>UINTN Instance;
>UINT32AuthenticationState;
>UINTN 

Re: [edk2-devel][Patch v2 0/7] Implement Capsule On Disk.

[Wu, Hao A]

Hello Chao,

Do you have any comment/feedback on this series?

One comment with regard to the series below:

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Xu, Wei6
> Sent: Wednesday, June 05, 2019 11:42 PM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J; Wu, Hao A; Kinney, Michael D; Gao, Liming; Zhang, Chao B
> Subject: [edk2-devel][Patch v2 0/7] Implement Capsule On Disk.
> 
> V2:
> Fix Ecc check failure.
> 
> V1:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1852
> 
> This patch set implements Capsule On Disk.
> Depends on whether platform supports Capsule-In-Ram, Capsule On Disk
> feature is composed of 2 solutions:
> Solution A): Load capsules out of TCB, rely on UpdateCapsule() runtime
> service to deliver Capsule-On-Disk.
> Solution B): Relocate capsules into a temp file which will be stored in root
> directory on a platform specific storage device.
> Leverage existing storage stack in PEI to load all capsule on disk images and
> create capsule hobs for the capsules.
> This solution has bigger TCB, but can work without Capsule-In-RAM support.
> 
> 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Chao B Zhang 
> 
> xuwei6 (7):
>   MdePkg: Add Pei Boot In CapsuleOnDisk Mode Ppi definition.
>   MdeModulePkg: Add Capsule On Disk related definition.
>   MdeModulePkg: Add CapsuleOnDiskLoadPei PEIM.
>   MdeModulePkg/BdsDxe: Support Capsule On Disk.
>   MdeModulePkg/CapsuleRuntimeDxe: Introduce PCD to control this feature.
>   MdeModulePkg/DxeIpl: Support Capsule On Disk.
>   MdeModulePkg: Add Capsule On Disk APIs into CapsuleLib.


Please re-order the sequence of the patches.
I found that the below patch:
MdeModulePkg: Add CapsuleOnDiskLoadPei PEIM.

depends on some definitions added in patch (last one):
MdeModulePkg: Add Capsule On Disk APIs into CapsuleLib.

Best Regards,
Hao Wu


> 
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.h  |3 +-
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf|   20 +-
>  MdeModulePkg/Core/DxeIplPeim/DxeLoad.c |   37 +-
>  MdeModulePkg/Include/Library/CapsuleLib.h  |   94 +-
>  MdeModulePkg/Include/Ppi/CapsuleOnDisk.h   |   48 +
>  .../Library/DxeCapsuleLibFmp/CapsuleOnDisk.c   | 1983
> 
>  .../Library/DxeCapsuleLibFmp/CapsuleOnDisk.h   |   63 +
>  .../Library/DxeCapsuleLibFmp/DxeCapsuleLib.c   |   56 +-
>  .../Library/DxeCapsuleLibFmp/DxeCapsuleLib.inf |   21 +-
>  .../DxeCapsuleLibFmp/DxeCapsuleProcessLib.c|  121 +-
>  .../Library/DxeCapsuleLibFmp/DxeCapsuleReportLib.c |   67 +-
>  .../DxeCapsuleLibFmp/DxeRuntimeCapsuleLib.inf  |3 +-
>  .../Library/DxeCapsuleLibNull/DxeCapsuleLibNull.c  |   85 +-
>  MdeModulePkg/MdeModulePkg.dec  |   43 +
>  MdeModulePkg/MdeModulePkg.dsc  |4 +
>  MdeModulePkg/MdeModulePkg.uni  |   32 +
>  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf   |3 +-
>  MdeModulePkg/Universal/BdsDxe/BdsEntry.c   |6 +-
>  .../CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.c|  442 +
>  .../CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.inf  |   64 +
>  .../CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.uni  |   15 +
>  .../CapsuleOnDiskLoadPeiExtra.uni  |   14 +
>  .../CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf|1 +
>  .../Universal/CapsuleRuntimeDxe/CapsuleService.c   |   10 +-
>  MdePkg/Include/Ppi/BootInRecoveryMode.h|9 +-
>  MdePkg/MdePkg.dec  |3 +
>  26 files changed, 3205 insertions(+), 42 deletions(-)
>  create mode 100644 MdeModulePkg/Include/Ppi/CapsuleOnDisk.h
>  create mode 100644
> MdeModulePkg/Library/DxeCapsuleLibFmp/CapsuleOnDisk.c
>  create mode 100644
> MdeModulePkg/Library/DxeCapsuleLibFmp/CapsuleOnDisk.h
>  create mode 100644
> MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.c
>  create mode 100644
> MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.i
> nf
>  create mode 100644
> MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPei.u
> ni
>  create mode 100644
> MdeModulePkg/Universal/CapsuleOnDiskLoadPei/CapsuleOnDiskLoadPeiE
> xtra.uni
> 
> --
> 2.16.2.windows.1
> 
> 
> 


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

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

Re: [edk2-devel][Patch v2 1/7] MdePkg: Add Pei Boot In CapsuleOnDisk Mode Ppi definition.

[Wu, Hao A]

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Xu,
> Wei6
> Sent: Wednesday, June 05, 2019 11:42 PM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D; Gao, Liming; Zhang, Chao B; Xu, Wei6
> Subject: [edk2-devel][Patch v2 1/7] MdePkg: Add Pei Boot In CapsuleOnDisk
> Mode Ppi definition.
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1852
> 
> This PPI indicates current boot mode is capsule on disk mode.
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Chao B Zhang 
> Signed-off-by: Wei6 Xu 
> ---
>  MdePkg/Include/Ppi/BootInRecoveryMode.h | 9 -
>  MdePkg/MdePkg.dec   | 3 +++
>  2 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/MdePkg/Include/Ppi/BootInRecoveryMode.h
> b/MdePkg/Include/Ppi/BootInRecoveryMode.h
> index ae40744d9b..71b0ca8586 100644
> --- a/MdePkg/Include/Ppi/BootInRecoveryMode.h
> +++ b/MdePkg/Include/Ppi/BootInRecoveryMode.h
> @@ -1,10 +1,10 @@
>  /** @file
>This PPI is installed by the platform PEIM to designate that a recovery 
> boot
>is in progress.
> 
> -  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>@par Revision Reference:
>This PPI is introduced in PI Version 1.0.
> 
> @@ -19,6 +19,13 @@
>}
> 
> 
>  extern EFI_GUID gEfiPeiBootInRecoveryModePpiGuid;
> 
> +#define EFI_PEI_BOOT_IN_CAPSULE_ON_DISK_MODE_PPI \
> +  { \
> +0xb08a11e4, 0xe2b7, 0x4b75, { 0xb5, 0x15, 0xaf, 0x61, 0x6, 0x68, 0xbf,
> 0xd1 } \
> +  }
> +
> +extern EFI_GUID gEfiPeiBootInCapsuleOnDiskModePpiGuid;
> +

Hello all,

One question, the above PPI will be added in the next PI spec, right?
Since I cannot find this definition within the PI 1.7 spec.

Best Regards,
Hao Wu

>  #endif
> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
> index 6c563375ee..ec02b8c7c7 100644
> --- a/MdePkg/MdePkg.dec
> +++ b/MdePkg/MdePkg.dec
> @@ -790,10 +790,13 @@
>gEfiPeiMemoryDiscoveredPpiGuid = {0xf894643d, 0xc449, 0x42d1, {0x8e,
> 0xa8, 0x85, 0xbd, 0xd8, 0xc6, 0x5b, 0xde } }
> 
>## Include/Ppi/BootInRecoveryMode.h
>gEfiPeiBootInRecoveryModePpiGuid = { 0x17ee496a, 0xd8e4, 0x4b9a, {0x94,
> 0xd1, 0xce, 0x82, 0x72, 0x30, 0x8, 0x50 } }
> 
> +  ## Include/Ppi/BootInRecoveryMode.h
> +  gEfiPeiBootInCapsuleOnDiskModePpiGuid = { 0xb08a11e4, 0xe2b7, 0x4b75,
> { 0xb5, 0x15, 0xaf, 0x61, 0x6, 0x68, 0xbf, 0xd1 } }
> +
>## Include/Ppi/EndOfPeiPhase.h
>gEfiEndOfPeiSignalPpiGuid = {0x605EA650, 0xC65C, 0x42e1, {0xBA, 0x80,
> 0x91, 0xA5, 0x2A, 0xB6, 0x18, 0xC6 } }
> 
>## Include/Ppi/Reset.h
>gEfiPeiResetPpiGuid = { 0xef398d58, 0x9dfd, 0x4103, {0xbf, 0x94, 0x78, 
> 0xc6,
> 0xf4, 0xfe, 0x71, 0x2f } }
> --
> 2.16.2.windows.1
> 
> 
> 


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

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

[edk2-devel] [PATCH] ShellPkg/UefiShellLib: Set input pointer parameter to null if failure

[Gao, Zhichao]

From: Bret Barkelew 

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

While failed to allocate memory to save the response,
set the input/output parameter 'Response'(VOID **) to
NULL to indicate the failure not only depend on the
returned status.

Cc: Jaben Carsey 
Cc: Ray Ni 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 
Signed-off-by: Zhichao Gao 
---
 ShellPkg/Library/UefiShellLib/UefiShellLib.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c 
b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
index 430b20e127..5be530092e 100644
--- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
+++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
@@ -3366,6 +3366,9 @@ ShellPromptForResponse (
   if (Type != ShellPromptResponseTypeFreeform) {
 Resp = 
(SHELL_PROMPT_RESPONSE*)AllocateZeroPool(sizeof(SHELL_PROMPT_RESPONSE));
 if (Resp == NULL) {
+  if (Response != NULL) {
+*Response = NULL;
+  }
   return (EFI_OUT_OF_RESOURCES);
 }
   }
@@ -3568,6 +3571,8 @@ ShellPromptForResponse (
   *Response = Resp;
 } else if (Buffer != NULL) {
   *Response = Buffer;
+} else {
+  *Response = NULL;
 }
   } else {
 if (Resp != NULL) {
-- 
2.21.0.windows.1


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

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

Re: [edk2-devel] RFC for Edk2-ToolEnv

[Sean via Groups.Io]

Both of these RFCs listed flake8 because that is what we have today and it 
should be relatively easy to get parity.  I am super happy to have you 
add/propose/provide pr with additional test capability like Pylint.  Thats one 
of the goals of adding this to tianocore.

You can see what we are basing this on here:
https://dev.azure.com/projectmu/mu%20pip/_build?definitionId=10

And you can see how the build works in the Azure DevOps yaml file:
https://dev.azure.com/projectmu/mu%20pip/_apps/hub/ms.vss-build-web.ci-designer-hub?pipelineId=10=BIDKbQdfN9%2BmJevdri5mWw%3D%3D=master
 ( 
https://dev.azure.com/projectmu/mu%20pip/_apps/hub/ms.vss-build-web.ci-designer-hub?pipelineId=10=BIDKbQdfN9%2BmJevdri5mWw%3D%3D=spbrogan=master
 )

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

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