date:20190225

[edk2] [PATCH v2 0/2] MdeModulePkg: Resolve buffer cross boundary access in Ramdisk

2019-02-25 Thread Hao Wu

V2 changes:

Correct CC list information.


V1 history:

The series will resolve a buffer cross boundary access issue during the
use of RAM disks. It is the mitigation for issue CVE-2018-12180.

Cc: Jian J Wang 
Cc: Ray Ni 
Cc: Star Zeng 

Hao Wu (2):
  MdeModulePkg/PartitionDxe: Ensure blocksize can hold MBR (CVE FIX)
  MdeModulePkg/RamDiskDxe: Ramdisk size be multiple of BlkSize (CVE FIX)

 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.h |  6 +++---
 MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c   |  9 -
 MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c   |  9 -
 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c  | 20 
++--
 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskProtocol.c |  5 +++--
 5 files changed, 36 insertions(+), 13 deletions(-)

-- 
2.12.0.windows.1

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

[edk2] [PATCH v2 1/2] MdeModulePkg/PartitionDxe: Ensure blocksize can hold MBR (CVE FIX)

2019-02-25 Thread Hao Wu

Fix CVE-2018-12180
https://bugzilla.tianocore.org/show_bug.cgi?id=1134

The commit adds checks for detecting GPT and MBR partitions.

These checks will ensure that the device block size is big enough to hold
an MBR (512 bytes).

Cc: Jian J Wang 
Cc: Ray Ni 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c | 9 -
 MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c | 9 -
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c 
b/MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c
index fe87761bde..d679cc208b 100644
--- a/MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c
+++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c
@@ -14,7 +14,7 @@
   partition content and validate the GPT table and GPT entry.
 
 Copyright (c) 2018 Qualcomm Datacenter Technologies, Inc.
-Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2019, 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
@@ -237,6 +237,13 @@ PartitionInstallGptChildHandles (
   GptValidStatus = EFI_NOT_FOUND;
 
   //
+  // Ensure the block size can hold the MBR
+  //
+  if (BlockSize < sizeof (MASTER_BOOT_RECORD)) {
+return EFI_NOT_FOUND;
+  }
+
+  //
   // Allocate a buffer for the Protective MBR
   //
   ProtectiveMbr = AllocatePool (BlockSize);
diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c 
b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c
index b1a99ee85b..419f8a17a7 100644
--- a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c
+++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c
@@ -13,7 +13,7 @@
 
 Copyright (c) 2018 Qualcomm Datacenter Technologies, Inc.
 Copyright (c) 2014, Hewlett-Packard Development Company, L.P.
-Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2019, 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
@@ -150,6 +150,13 @@ PartitionInstallMbrChildHandles (
   MediaId   = BlockIo->Media->MediaId;
   LastBlock = BlockIo->Media->LastBlock;
 
+  //
+  // Ensure the block size can hold the MBR
+  //
+  if (BlockSize < sizeof (MASTER_BOOT_RECORD)) {
+return EFI_NOT_FOUND;
+  }
+
   Mbr = AllocatePool (BlockSize);
   if (Mbr == NULL) {
 return Found;
-- 
2.12.0.windows.1

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

[edk2] [PATCH v2 2/2] MdeModulePkg/RamDiskDxe: Ramdisk size be multiple of BlkSize (CVE FIX)

2019-02-25 Thread Hao Wu

Fix CVE-2018-12180
https://bugzilla.tianocore.org/show_bug.cgi?id=1134

Originally, the block size of created Ram disks is hard-coded to 512
bytes. However, if the total size of the Ram disk is not a multiple of 512
bytes, there will be potential memory access issues when dealing with the
last block of the Ram disk.

This commit will adjust the block size of the Ram disks to ensure that the
total size is a multiple of the block size.

Cc: Jian J Wang 
Cc: Ray Ni 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.h |  6 +++---
 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c  | 20 
++--
 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskProtocol.c |  5 +++--
 3 files changed, 20 insertions(+), 11 deletions(-)

diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.h 
b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.h
index 08a8ca94c9..72f2bfe179 100644
--- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.h
+++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.h
@@ -1,7 +1,7 @@
 /** @file
   The header file of RamDiskDxe driver.
 
-  Copyright (c) 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2016 - 2019, 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
@@ -49,9 +49,9 @@
 ///
 
 //
-// Block size for RAM disk
+// Default block size for RAM disk
 //
-#define RAM_DISK_BLOCK_SIZE 512
+#define RAM_DISK_DEFAULT_BLOCK_SIZE 512
 
 //
 // Iterate through the double linked list. NOT delete safe
diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c 
b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c
index 4f74b5ef15..8926ad7d2f 100644
--- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c
+++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c
@@ -1,7 +1,7 @@
 /** @file
   Produce EFI_BLOCK_IO_PROTOCOL on a RAM disk device.
 
-  Copyright (c) 2016 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2016 - 2019, 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
@@ -54,6 +54,7 @@ RamDiskInitBlockIo (
   EFI_BLOCK_IO_PROTOCOL   *BlockIo;
   EFI_BLOCK_IO2_PROTOCOL  *BlockIo2;
   EFI_BLOCK_IO_MEDIA  *Media;
+  UINT32  Remainder;
 
   BlockIo  = >BlockIo;
   BlockIo2 = >BlockIo2;
@@ -69,11 +70,18 @@ RamDiskInitBlockIo (
   Media->LogicalPartition = FALSE;
   Media->ReadOnly = FALSE;
   Media->WriteCaching = FALSE;
-  Media->BlockSize= RAM_DISK_BLOCK_SIZE;
-  Media->LastBlock= DivU64x32 (
-  PrivateData->Size + RAM_DISK_BLOCK_SIZE - 1,
-  RAM_DISK_BLOCK_SIZE
-  ) - 1;
+
+  for (Media->BlockSize = RAM_DISK_DEFAULT_BLOCK_SIZE;
+   Media->BlockSize >= 1;
+   Media->BlockSize = Media->BlockSize >> 1) {
+Media->LastBlock = DivU64x32Remainder (PrivateData->Size, 
Media->BlockSize, ) - 1;
+if (Remainder == 0) {
+  break;
+}
+  }
+  ASSERT (Media->BlockSize != 0);
+
+  return;
 }
 
 
diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskProtocol.c 
b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskProtocol.c
index 6784e2b2f1..e8250d5c1b 100644
--- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskProtocol.c
+++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskProtocol.c
@@ -1,7 +1,7 @@
 /** @file
   The realization of EFI_RAM_DISK_PROTOCOL.
 
-  Copyright (c) 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2016 - 2019, Intel Corporation. All rights reserved.
   (C) Copyright 2016 Hewlett Packard Enterprise Development LP
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -613,7 +613,8 @@ RamDiskRegister (
   //
   // Add check to prevent data read across the memory boundary
   //
-  if (RamDiskBase + RamDiskSize > ((UINTN) -1) - RAM_DISK_BLOCK_SIZE + 1) {
+  if ((RamDiskSize > MAX_UINTN) ||
+  (RamDiskBase > MAX_UINTN - RamDiskSize + 1)) {
 return EFI_INVALID_PARAMETER;
   }
 
-- 
2.12.0.windows.1

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

Re: [edk2] [PATCH v1 1/1] ArmPkg: Fix writes to GICv3 GICD_IROUTER reg

2019-02-25 Thread Ard Biesheuvel

On Fri, 22 Feb 2019 at 20:43, Sami Mujawar  wrote:
>
> According to ARM Generic Interrupt Controller Architecture
> Specification, GIC architecture version 3.0 and version 4.0,
> GICD_IROUTER is a 64-bit register.
>
> Fixed code to use 64 bit MMIO write operations so that the
> Aff3 value (bits [39:32]) is written to GICD_IROUTER.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Sami Mujawar 
> Reported-by: Carl van Schaik 

Thanks Sami

Reviewed-by: Ard Biesheuvel 

Pushed as 1342d7679e10..1bb76029eff4


> ---
>
> The changes can be seen at 
> https://github.com/samimujawar/edk2/tree/352_fix_gicv3_GICD_IROUTERn_v1
>
>
>  ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c 
> b/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
> index 
> 1558db31713a828f324a807583076b21dd3302d0..67c74f79654586f8b6e47795d3c7400b88172d6e
>  100644
> --- a/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
> +++ b/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
> @@ -1,6 +1,6 @@
>  /** @file
>  *
> -*  Copyright (c) 2011-2017, ARM Limited. All rights reserved.
> +*  Copyright (c) 2011-2018, ARM Limited. All rights reserved.
>  *
>  *  This program and the accompanying materials
>  *  are licensed and made available under the terms and conditions of the BSD 
> License
> @@ -467,7 +467,7 @@ GicV3DxeInitialize (
>
>  // Route the SPIs to the primary CPU. SPIs start at the INTID 32
>  for (Index = 0; Index < (mGicNumInterrupts - 32); Index++) {
> -  MmioWrite32 (
> +  MmioWrite64 (
>  mGicDistributorBase + ARM_GICD_IROUTER + (Index * 8),
>  CpuTarget
>  );
> --
> 'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v1 1/2] MdeModulePkg/PartitionDxe: Ensure blocksize can hold MBR (CVE FIX)

2019-02-25 Thread Hao Wu

Fix CVE-2018-12180
https://bugzilla.tianocore.org/show_bug.cgi?id=1134

The commit adds checks for detecting GPT and MBR partitions.

These checks will ensure that the device block size is big enough to hold
an MBR (512 bytes).

Cc: Jian J Wang 
Cc: Ruiyu Ni 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c | 9 -
 MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c | 9 -
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c 
b/MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c
index fe87761bde..d679cc208b 100644
--- a/MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c
+++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c
@@ -14,7 +14,7 @@
   partition content and validate the GPT table and GPT entry.
 
 Copyright (c) 2018 Qualcomm Datacenter Technologies, Inc.
-Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2019, 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
@@ -237,6 +237,13 @@ PartitionInstallGptChildHandles (
   GptValidStatus = EFI_NOT_FOUND;
 
   //
+  // Ensure the block size can hold the MBR
+  //
+  if (BlockSize < sizeof (MASTER_BOOT_RECORD)) {
+return EFI_NOT_FOUND;
+  }
+
+  //
   // Allocate a buffer for the Protective MBR
   //
   ProtectiveMbr = AllocatePool (BlockSize);
diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c 
b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c
index b1a99ee85b..419f8a17a7 100644
--- a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c
+++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c
@@ -13,7 +13,7 @@
 
 Copyright (c) 2018 Qualcomm Datacenter Technologies, Inc.
 Copyright (c) 2014, Hewlett-Packard Development Company, L.P.
-Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2019, 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
@@ -150,6 +150,13 @@ PartitionInstallMbrChildHandles (
   MediaId   = BlockIo->Media->MediaId;
   LastBlock = BlockIo->Media->LastBlock;
 
+  //
+  // Ensure the block size can hold the MBR
+  //
+  if (BlockSize < sizeof (MASTER_BOOT_RECORD)) {
+return EFI_NOT_FOUND;
+  }
+
   Mbr = AllocatePool (BlockSize);
   if (Mbr == NULL) {
 return Found;
-- 
2.12.0.windows.1

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

[edk2] [PATCH v1 0/2] MdeModulePkg: Resolve buffer cross boundary access in Ramdisk

2019-02-25 Thread Hao Wu

The series will resolve a buffer cross boundary access issue during the
use of RAM disks. It is the mitigation for issue CVE-2018-12180.

Cc: Jian J Wang 
Cc: Ruiyu Ni 
Cc: Star Zeng 

Hao Wu (2):
  MdeModulePkg/PartitionDxe: Ensure blocksize can hold MBR (CVE FIX)
  MdeModulePkg/RamDiskDxe: Ramdisk size be multiple of BlkSize (CVE FIX)

 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.h |  6 +++---
 MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c   |  9 -
 MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c   |  9 -
 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c  | 20 
++--
 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskProtocol.c |  5 +++--
 5 files changed, 36 insertions(+), 13 deletions(-)

-- 
2.12.0.windows.1

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

[edk2] [PATCH v1 2/2] MdeModulePkg/RamDiskDxe: Ramdisk size be multiple of BlkSize (CVE FIX)

2019-02-25 Thread Hao Wu

Fix CVE-2018-12180
https://bugzilla.tianocore.org/show_bug.cgi?id=1134

Originally, the block size of created Ram disks is hard-coded to 512
bytes. However, if the total size of the Ram disk is not a multiple of 512
bytes, there will be potential memory access issues when dealing with the
last block of the Ram disk.

This commit will adjust the block size of the Ram disks to ensure that the
total size is a multiple of the block size.

Cc: Jian J Wang 
Cc: Ruiyu Ni 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.h |  6 +++---
 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c  | 20 
++--
 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskProtocol.c |  5 +++--
 3 files changed, 20 insertions(+), 11 deletions(-)

diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.h 
b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.h
index 08a8ca94c9..72f2bfe179 100644
--- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.h
+++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.h
@@ -1,7 +1,7 @@
 /** @file
   The header file of RamDiskDxe driver.
 
-  Copyright (c) 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2016 - 2019, 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
@@ -49,9 +49,9 @@
 ///
 
 //
-// Block size for RAM disk
+// Default block size for RAM disk
 //
-#define RAM_DISK_BLOCK_SIZE 512
+#define RAM_DISK_DEFAULT_BLOCK_SIZE 512
 
 //
 // Iterate through the double linked list. NOT delete safe
diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c 
b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c
index 4f74b5ef15..8926ad7d2f 100644
--- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c
+++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c
@@ -1,7 +1,7 @@
 /** @file
   Produce EFI_BLOCK_IO_PROTOCOL on a RAM disk device.
 
-  Copyright (c) 2016 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2016 - 2019, 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
@@ -54,6 +54,7 @@ RamDiskInitBlockIo (
   EFI_BLOCK_IO_PROTOCOL   *BlockIo;
   EFI_BLOCK_IO2_PROTOCOL  *BlockIo2;
   EFI_BLOCK_IO_MEDIA  *Media;
+  UINT32  Remainder;
 
   BlockIo  = >BlockIo;
   BlockIo2 = >BlockIo2;
@@ -69,11 +70,18 @@ RamDiskInitBlockIo (
   Media->LogicalPartition = FALSE;
   Media->ReadOnly = FALSE;
   Media->WriteCaching = FALSE;
-  Media->BlockSize= RAM_DISK_BLOCK_SIZE;
-  Media->LastBlock= DivU64x32 (
-  PrivateData->Size + RAM_DISK_BLOCK_SIZE - 1,
-  RAM_DISK_BLOCK_SIZE
-  ) - 1;
+
+  for (Media->BlockSize = RAM_DISK_DEFAULT_BLOCK_SIZE;
+   Media->BlockSize >= 1;
+   Media->BlockSize = Media->BlockSize >> 1) {
+Media->LastBlock = DivU64x32Remainder (PrivateData->Size, 
Media->BlockSize, ) - 1;
+if (Remainder == 0) {
+  break;
+}
+  }
+  ASSERT (Media->BlockSize != 0);
+
+  return;
 }
 
 
diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskProtocol.c 
b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskProtocol.c
index 6784e2b2f1..e8250d5c1b 100644
--- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskProtocol.c
+++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskProtocol.c
@@ -1,7 +1,7 @@
 /** @file
   The realization of EFI_RAM_DISK_PROTOCOL.
 
-  Copyright (c) 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2016 - 2019, Intel Corporation. All rights reserved.
   (C) Copyright 2016 Hewlett Packard Enterprise Development LP
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -613,7 +613,8 @@ RamDiskRegister (
   //
   // Add check to prevent data read across the memory boundary
   //
-  if (RamDiskBase + RamDiskSize > ((UINTN) -1) - RAM_DISK_BLOCK_SIZE + 1) {
+  if ((RamDiskSize > MAX_UINTN) ||
+  (RamDiskBase > MAX_UINTN - RamDiskSize + 1)) {
 return EFI_INVALID_PARAMETER;
   }
 
-- 
2.12.0.windows.1

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

Re: [edk2] [PATCH 1/1] EmbeddedPkg: Fix multiple Virtual RTC issues

2019-02-25 Thread Ard Biesheuvel

On Tue, 26 Feb 2019 at 00:52, Pete Batard  wrote:
>
> LibGetTime():
> - Two variables were used for the epoch, where only one should have been.
> - Also harmonize variable name to match the one used in LibSetTime.
> LiBSetTime():
> - Address possible underflows if time is set to start of epoch.
> - Ensure that time being read does actually match time that was manually
>   set (plus the time elapsed since), by subtracting number of seconds
>   since reset.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Pete Batard 

Thanks Pete

Reviewed-by: Ard Biesheuvel 

Pushed as 9ab4ec518882..1342d7679e10
> ---
>  EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c | 34 
> ++--
>  1 file changed, 25 insertions(+), 9 deletions(-)
>
> diff --git 
> a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c 
> b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
> index 4c354730d02b..5559106b696f 100644
> --- a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
> +++ b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
> @@ -54,13 +54,12 @@ LibGetTime (
>)
>  {
>EFI_STATUS  Status;
> -  UINT32  EpochSeconds;
>INT16   TimeZone;
>UINT8   Daylight;
>UINT64  Freq;
>UINT64  Counter;
>UINT64  Remainder;
> -  UINTN   ElapsedSeconds;
> +  UINTN   EpochSeconds;
>UINTN   Size;
>
>if (Time == NULL) {
> @@ -75,13 +74,13 @@ LibGetTime (
>
>// Get the epoch time from non-volatile storage
>Size = sizeof (UINTN);
> -  ElapsedSeconds = 0;
> +  EpochSeconds = 0;
>Status = EfiGetVariable (
>   (CHAR16 *)mEpochVariableName,
>   ,
>   NULL,
>   ,
> - (VOID *)
> + (VOID *)
>   );
>// Fall back to compilation-time epoch if not set
>if (EFI_ERROR (Status)) {
> @@ -93,7 +92,7 @@ LibGetTime (
>  // If you are attempting to use this library on such an environment, 
> please
>  // contact the edk2 mailing list, so we can try to add support for it.
>  //
> -ElapsedSeconds = BUILD_EPOCH;
> +EpochSeconds = BUILD_EPOCH;
>  DEBUG ((
>DEBUG_INFO,
>"LibGetTime: %s non volatile variable was not found - Using 
> compilation time epoch.\n",
> @@ -101,7 +100,7 @@ LibGetTime (
>));
>}
>Counter = GetPerformanceCounter ();
> -  ElapsedSeconds += DivU64x64Remainder (Counter, Freq, );
> +  EpochSeconds += DivU64x64Remainder (Counter, Freq, );
>
>// Get the current time zone information from non-volatile storage
>Size = sizeof (TimeZone);
> @@ -204,7 +203,7 @@ LibGetTime (
>  }
>}
>
> -  EpochToEfiTime (ElapsedSeconds, Time);
> +  EpochToEfiTime (EpochSeconds, Time);
>
>// Because we use the performance counter, we can fill the Nanosecond 
> attribute
>// provided that the remainder doesn't overflow 64-bit during 
> multiplication.
> @@ -240,6 +239,9 @@ LibSetTime (
>)
>  {
>EFI_STATUS  Status;
> +  UINT64  Freq;
> +  UINT64  Counter;
> +  UINT64  Remainder;
>UINTN   EpochSeconds;
>
>if (!IsTimeValid (Time)) {
> @@ -249,16 +251,30 @@ LibSetTime (
>EpochSeconds = EfiTimeToEpoch (Time);
>
>// Adjust for the correct time zone, i.e. convert to UTC time zone
> -  if (Time->TimeZone != EFI_UNSPECIFIED_TIMEZONE) {
> +  if ((Time->TimeZone != EFI_UNSPECIFIED_TIMEZONE)
> +  && (EpochSeconds > Time->TimeZone * SEC_PER_MIN)) {
>  EpochSeconds -= Time->TimeZone * SEC_PER_MIN;
>}
>
>// Adjust for the correct period
> -  if ((Time->Daylight & EFI_TIME_IN_DAYLIGHT) == EFI_TIME_IN_DAYLIGHT) {
> +  if (((Time->Daylight & EFI_TIME_IN_DAYLIGHT) == EFI_TIME_IN_DAYLIGHT)
> +  && (EpochSeconds > SEC_PER_HOUR)) {
>  // Convert to un-adjusted time, i.e. fall back one hour
>  EpochSeconds -= SEC_PER_HOUR;
>}
>
> +  // Use the performance counter to substract the number of seconds
> +  // since platform reset. Without this, setting time from the shell
> +  // and immediately reading it back would result in a forward time
> +  // offset, of the duration during which the platform has been up.
> +  Freq = GetPerformanceCounterProperties (NULL, NULL);
> +  if (Freq != 0) {
> +Counter = GetPerformanceCounter ();
> +if (EpochSeconds > DivU64x64Remainder (Counter, Freq, )) {
> +  EpochSeconds -= DivU64x64Remainder (Counter, Freq, );
> +}
> +  }
> +
>// Save the current time zone information into non-volatile storage
>Status = EfiSetVariable (
>   (CHAR16 *)mTimeZoneVariableName,
> --
> 2.17.0.windows.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] BaseTools:The BOM character is processed when python reads a file

2019-02-25 Thread Fan, ZhijuX

When python3 reads an XML file it will parse the file in error
if the file has a BOM

Cc: Bob Feng 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhiju.Fan 
---
 BaseTools/Source/Python/Ecc/Xml/XmlRoutines.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/Ecc/Xml/XmlRoutines.py 
b/BaseTools/Source/Python/Ecc/Xml/XmlRoutines.py
index 4294016ae3..00cbc4e55e 100644
--- a/BaseTools/Source/Python/Ecc/Xml/XmlRoutines.py
+++ b/BaseTools/Source/Python/Ecc/Xml/XmlRoutines.py
@@ -17,6 +17,7 @@
 #
 from __future__ import print_function
 import xml.dom.minidom
+import codecs
 from Common.LongFilePathSupport import OpenLongFilePath as open
 
 ## Create a element of XML
@@ -211,7 +212,7 @@ def XmlNodeName(Dom):
 #
 def XmlParseFile(FileName):
 try:
-XmlFile = open(FileName)
+XmlFile = codecs.open(FileName,encoding='utf_8_sig')
 Dom = xml.dom.minidom.parse(XmlFile)
 XmlFile.close()
 return Dom
-- 
2.14.1.windows.1

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

Re: [edk2] [PATCH] Convert PosixLike scripts to sh, reduce duplication and fix some bugs

2019-02-25 Thread Rebecca Cran via edk2-devel

Thanks for the review. I have a macOS system, so I'll verify future 
changes work there too.


The problem I'm trying to solve is to make it easier to get started 
building EDK2 under FreeBSD. Currently it needs symlinks in 
BaseTools/Bin/FreeBSD-amd64 for gcc, ld, make, objcopy and python, and 
obviously needs bash installed. Since there seems to be relatively 
little shell code in the repo, I was thinking that avoiding the 
dependency on bash might be a relatively easy way to reduce the steps 
needed to get things working.



I'll try and remember about PatchCheck.py too.


--

Rebecca


On 2/25/19 8:11 PM, Feng, Bob C wrote:

Hi Rebecca,

I like the change of moving duplicated code into common files and the bug fix 
looks good.

I tested this patch on our CI system, it break the build on MacOS. There is no 
realpath command on MacOs shell.

For the patch itself, it need to pass the check of 
BaseTools/Scripts/PatchCheck.py.

Is there actual problem that need to be resolved by using sh instead of bash?

Thanks,
Bob

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Rebecca 
Cran via edk2-devel
Sent: Friday, February 22, 2019 1:13 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [PATCH] Convert PosixLike scripts to sh, reduce duplication and 
fix some bugs

Since the scripts in the PosixLike directory are very simple, convert them to 
use /bin/sh, and move duplicated code into common files (one for python 
scripts, one for C binaries).

Fix some bugs in edksetup.sh and BuildEnv: `test` uses single equals instead of 
double equals, and should have a space before the ending bracket. Fix some 
indentation, and if the user runs edksetup.sh with --help etc., quit after 
displaying the help message.
---
  BaseTools/BinWrappers/PosixLike/BPDG  | 15 ++
  BaseTools/BinWrappers/PosixLike/Brotli| 30 ++-
  .../BinWrappers/PosixLike/BrotliCompress  | 12 
  BaseTools/BinWrappers/PosixLike/DevicePath| 30 ++-
  BaseTools/BinWrappers/PosixLike/Ecc   | 15 ++
  BaseTools/BinWrappers/PosixLike/EfiRom| 30 ++-
  BaseTools/BinWrappers/PosixLike/GenCrc32  | 30 ++-
  BaseTools/BinWrappers/PosixLike/GenDepex  | 15 ++
  BaseTools/BinWrappers/PosixLike/GenFds| 15 ++
  BaseTools/BinWrappers/PosixLike/GenFfs| 30 ++-
  BaseTools/BinWrappers/PosixLike/GenFv | 30 ++-
  BaseTools/BinWrappers/PosixLike/GenFw | 30 ++-
  .../BinWrappers/PosixLike/GenPatchPcdTable| 15 ++
  BaseTools/BinWrappers/PosixLike/GenSec| 30 ++-
  .../BinWrappers/PosixLike/GenerateCapsule | 15 ++
  BaseTools/BinWrappers/PosixLike/LzmaCompress  | 30 ++-
  .../BinWrappers/PosixLike/LzmaF86Compress |  2 +-
  BaseTools/BinWrappers/PosixLike/PatchPcdValue | 15 ++
  BaseTools/BinWrappers/PosixLike/Pkcs7Sign | 15 ++
  .../PosixLike/Rsa2048Sha256GenerateKeys   | 15 ++
  .../BinWrappers/PosixLike/Rsa2048Sha256Sign   | 15 ++
  BaseTools/BinWrappers/PosixLike/Split | 30 ++-
  BaseTools/BinWrappers/PosixLike/TargetTool| 15 ++
  BaseTools/BinWrappers/PosixLike/TianoCompress | 30 ++-
  BaseTools/BinWrappers/PosixLike/Trim  | 15 ++
  BaseTools/BinWrappers/PosixLike/UPT   | 15 ++
  BaseTools/BinWrappers/PosixLike/VfrCompile| 30 ++-
  BaseTools/BinWrappers/PosixLike/VolInfo   | 30 ++-
  BaseTools/BinWrappers/PosixLike/build | 15 ++
  BaseTools/BinWrappers/PosixLike/common.sh | 12 
  BaseTools/BinWrappers/PosixLike/commonbin.sh  | 28 +
  BaseTools/BuildEnv|  3 +-
  edksetup.sh   | 12 
  33 files changed, 110 insertions(+), 559 deletions(-)  create mode 100644 
BaseTools/BinWrappers/PosixLike/common.sh
  create mode 100644 BaseTools/BinWrappers/PosixLike/commonbin.sh

diff --git a/BaseTools/BinWrappers/PosixLike/BPDG 
b/BaseTools/BinWrappers/PosixLike/BPDG
index c894384908..a9da3afb4b 100755
--- a/BaseTools/BinWrappers/PosixLike/BPDG
+++ b/BaseTools/BinWrappers/PosixLike/BPDG
@@ -1,14 +1,3 @@
-#!/usr/bin/env bash
-#python `dirname $0`/RunToolFromSource.py `basename $0` $*
+#!/bin/sh
  
-# If a ${PYTHON_COMMAND} command is available, use it in preference to python -if command -v ${PYTHON_COMMAND} >/dev/null 2>&1; then

-python_exe=${PYTHON_COMMAND}
-fi
-
-full_cmd=${BASH_SOURCE:-$0} # see http://mywiki.wooledge.org/BashFAQ/028 for a 
discussion of why $0 is not a good choice here -dir=$(dirname "$full_cmd") 
-cmd=${full_cmd##*/}
-
-export PYTHONPATH="$dir/../../Source/Python${PYTHONPATH:+:"$PYTHONPATH"}"
-exec "${python_exe:-python}" -m $cmd.$cmd "$@"
+. "$(dirname

Re: [edk2] [edk2-announce] Soft Feature Freeze starts today for edk2-stable201903

2019-02-25 Thread Gao, Liming

Hi, all
  Two features (Add SMM CET support and Add WiFi Connection Manager) get 
Acked-By or Reviewed-by near the soft feature freeze date. CET is X86 specific 
feature. WiFi connection manager is the standalone feature. Their impact should 
be small. So, I suggest to include them in this stable tag edk2-stable201903. 
If you have different opinion, please raise. If no objection, I will push them 
late this week. 

Add SMM CET support 
https://lists.01.org/pipermail/edk2-devel/2019-February/037128.html
NetworkPkg: Add WiFi Connection Manager to NetworkPkg 
https://lists.01.org/pipermail/edk2-devel/2019-February/037137.html

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao, 
> Liming
> Sent: Friday, February 22, 2019 10:26 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [edk2-announce] Soft Feature Freeze starts today for 
> edk2-stable201903
> 
> Hi, all
>   
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning 
> lists edk2-stable201903 tag planning. Now, we enter
> into Soft Feature Freeze phase. In this phase, the feature without 
> Reviewed-by or Acked-by tags will be delayed after the upcoming stable
> tag. The patch review can continue without break. Below is edk2-stable201903 
> tag planning.
> 
> 2019-03-08 Beginning of development
> 2019-02-22 Soft Feature Freeze
> 2019-03-01 Hard Feature Freeze
> 2019-03-08 Release
> 
> Thanks
> Liming
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] Convert PosixLike scripts to sh, reduce duplication and fix some bugs

2019-02-25 Thread Feng, Bob C

Hi Rebecca,

I like the change of moving duplicated code into common files and the bug fix 
looks good.

I tested this patch on our CI system, it break the build on MacOS. There is no 
realpath command on MacOs shell.

For the patch itself, it need to pass the check of 
BaseTools/Scripts/PatchCheck.py.

Is there actual problem that need to be resolved by using sh instead of bash?

Thanks,
Bob

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Rebecca 
Cran via edk2-devel
Sent: Friday, February 22, 2019 1:13 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [PATCH] Convert PosixLike scripts to sh, reduce duplication and 
fix some bugs

Since the scripts in the PosixLike directory are very simple, convert them to 
use /bin/sh, and move duplicated code into common files (one for python 
scripts, one for C binaries).

Fix some bugs in edksetup.sh and BuildEnv: `test` uses single equals instead of 
double equals, and should have a space before the ending bracket. Fix some 
indentation, and if the user runs edksetup.sh with --help etc., quit after 
displaying the help message.
---
 BaseTools/BinWrappers/PosixLike/BPDG  | 15 ++
 BaseTools/BinWrappers/PosixLike/Brotli| 30 ++-
 .../BinWrappers/PosixLike/BrotliCompress  | 12 
 BaseTools/BinWrappers/PosixLike/DevicePath| 30 ++-
 BaseTools/BinWrappers/PosixLike/Ecc   | 15 ++
 BaseTools/BinWrappers/PosixLike/EfiRom| 30 ++-
 BaseTools/BinWrappers/PosixLike/GenCrc32  | 30 ++-
 BaseTools/BinWrappers/PosixLike/GenDepex  | 15 ++
 BaseTools/BinWrappers/PosixLike/GenFds| 15 ++
 BaseTools/BinWrappers/PosixLike/GenFfs| 30 ++-
 BaseTools/BinWrappers/PosixLike/GenFv | 30 ++-
 BaseTools/BinWrappers/PosixLike/GenFw | 30 ++-
 .../BinWrappers/PosixLike/GenPatchPcdTable| 15 ++
 BaseTools/BinWrappers/PosixLike/GenSec| 30 ++-
 .../BinWrappers/PosixLike/GenerateCapsule | 15 ++
 BaseTools/BinWrappers/PosixLike/LzmaCompress  | 30 ++-
 .../BinWrappers/PosixLike/LzmaF86Compress |  2 +-
 BaseTools/BinWrappers/PosixLike/PatchPcdValue | 15 ++
 BaseTools/BinWrappers/PosixLike/Pkcs7Sign | 15 ++
 .../PosixLike/Rsa2048Sha256GenerateKeys   | 15 ++
 .../BinWrappers/PosixLike/Rsa2048Sha256Sign   | 15 ++
 BaseTools/BinWrappers/PosixLike/Split | 30 ++-
 BaseTools/BinWrappers/PosixLike/TargetTool| 15 ++
 BaseTools/BinWrappers/PosixLike/TianoCompress | 30 ++-
 BaseTools/BinWrappers/PosixLike/Trim  | 15 ++
 BaseTools/BinWrappers/PosixLike/UPT   | 15 ++
 BaseTools/BinWrappers/PosixLike/VfrCompile| 30 ++-
 BaseTools/BinWrappers/PosixLike/VolInfo   | 30 ++-
 BaseTools/BinWrappers/PosixLike/build | 15 ++
 BaseTools/BinWrappers/PosixLike/common.sh | 12 
 BaseTools/BinWrappers/PosixLike/commonbin.sh  | 28 +
 BaseTools/BuildEnv|  3 +-
 edksetup.sh   | 12 
 33 files changed, 110 insertions(+), 559 deletions(-)  create mode 100644 
BaseTools/BinWrappers/PosixLike/common.sh
 create mode 100644 BaseTools/BinWrappers/PosixLike/commonbin.sh

diff --git a/BaseTools/BinWrappers/PosixLike/BPDG 
b/BaseTools/BinWrappers/PosixLike/BPDG
index c894384908..a9da3afb4b 100755
--- a/BaseTools/BinWrappers/PosixLike/BPDG
+++ b/BaseTools/BinWrappers/PosixLike/BPDG
@@ -1,14 +1,3 @@
-#!/usr/bin/env bash
-#python `dirname $0`/RunToolFromSource.py `basename $0` $*
+#!/bin/sh
 
-# If a ${PYTHON_COMMAND} command is available, use it in preference to python 
-if command -v ${PYTHON_COMMAND} >/dev/null 2>&1; then
-python_exe=${PYTHON_COMMAND}
-fi
-
-full_cmd=${BASH_SOURCE:-$0} # see http://mywiki.wooledge.org/BashFAQ/028 for a 
discussion of why $0 is not a good choice here -dir=$(dirname "$full_cmd") 
-cmd=${full_cmd##*/}
-
-export PYTHONPATH="$dir/../../Source/Python${PYTHONPATH:+:"$PYTHONPATH"}"
-exec "${python_exe:-python}" -m $cmd.$cmd "$@"
+. "$(dirname "$(realpath "$0")")/common.sh"
diff --git a/BaseTools/BinWrappers/PosixLike/Brotli 
b/BaseTools/BinWrappers/PosixLike/Brotli
index 0945d86d92..3dfa26e517 100755
--- a/BaseTools/BinWrappers/PosixLike/Brotli
+++ b/BaseTools/BinWrappers/PosixLike/Brotli
@@ -1,29 +1,3 @@
-#!/usr/bin/env bash
-
-full_cmd=${BASH_SOURCE:-$0} # see http://mywiki.wooledge.org/BashFAQ/028 for a 
discussion of why $0 is not a good choice here -dir=$(dirname "$full_cmd") 
-cmd=${full_cmd##*/}
-
-if [ -n "$WORKSPACE" ] && [ -e "$WORKSPACE/Conf/BaseToolsCBinaries" ] -then
-  exec "$WORKSPACE/Conf/BaseToolsCBinaries/$cmd"
-elif [ -n "$WORKSPACE" ] && [ -e "$EDK_TOOLS_PATH/Source/C" ] -then
-  if [ ! -e

Re: [edk2] [PATCH] ShellPkg: Correct a parameter's name

2019-02-25 Thread Zhang, Shenglei

Hi Jaben,

Do you have any opinion on "fs-path" rename to "file-full-path-name"?

Thanks,
Shenglei

From: krishnaLee [mailto:sssky...@163.com]
Sent: Thursday, February 21, 2019 10:00 AM
To: Zhang, Shenglei 
Cc: edk2-devel@lists.01.org
Subject: Re:[edk2] [PATCH] ShellPkg: Correct a parameter's name


Hi Shenglei,
I am confused some times,see UEFI_Shell_specification_2_2,chapter-3.7:

3.7 File Names
The UEFI Shell supports file names and paths with the following format:
fs-path := [fs-map-name] [fs-divider][fs-dirs][fs-name]

May be if the define name "fs-path" rename to "file-full-path-name" is more 
clear,:)

thanks,
krishna.



At 2019-02-21 09:28:07, "Shenglei Zhang" 
mailto:shenglei.zh...@intel.com>> wrote:

>The parameter FilePath of ShellOpenFileByName defined in

>ShellLib.h is incorrect. It should be FileName.

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

>

>Cc: Jaben Carsey mailto:jaben.car...@intel.com>>

>Cc: Ruiyu Ni mailto:ruiyu...@intel.com>>

>Contributed-under: TianoCore Contribution Agreement 1.1

>Signed-off-by: shenglei 
>mailto:shenglei.zh...@intel.com>>

>---

> ShellPkg/Include/Library/ShellLib.h | 4 ++--

> 1 file changed, 2 insertions(+), 2 deletions(-)

>

>diff --git a/ShellPkg/Include/Library/ShellLib.h 
>b/ShellPkg/Include/Library/ShellLib.h

>index 2ecc5ee006..78bdcc8c53 100644

>--- a/ShellPkg/Include/Library/ShellLib.h

>+++ b/ShellPkg/Include/Library/ShellLib.h

>@@ -161,7 +161,7 @@ ShellOpenFileByDevicePath(

>   otherwise, the Filehandle is NULL. Attributes is valid only for

>   EFI_FILE_MODE_CREATE.

>

>-  @param[in] FilePath   The pointer to file name.

>+  @param[in] FileName   The pointer to file name.

>   @param[out] FileHandleThe pointer to the file handle.

>   @param[in] OpenMode   The mode to open the file with.

>   @param[in] Attributes The file's file attributes.

>@@ -186,7 +186,7 @@ ShellOpenFileByDevicePath(

> EFI_STATUS

> EFIAPI

> ShellOpenFileByName(

>-  IN CONST CHAR16   *FilePath,

>+  IN CONST CHAR16   *FileName,

>   OUT SHELL_FILE_HANDLE *FileHandle,

>   IN UINT64 OpenMode,

>   IN UINT64 Attributes

>--

>2.18.0.windows.1

>

>___

>edk2-devel mailing list

>edk2-devel@lists.01.org

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

Re: [edk2] [PATCH] BaseTools:PackageDocumentTools import lib error occurs.

2019-02-25 Thread Feng, Bob C

Reviewed-by: Bob Feng  

-Original Message-
From: Fan, ZhijuX 
Sent: Friday, February 22, 2019 2:14 PM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Feng, Bob C 
Subject: [edk2][PATCH] BaseTools:PackageDocumentTools import lib error occurs.

Steps:
 1. Download edk2 tree
 2. Build BaseTools
 3. Go to edk2\BaseTools\Scripts\PackageDocumentTools
to run packagedoc_cli.py

An error occurs if relative imports are used when running a file alone

Cc: Bob Feng 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhiju.Fan 
---
 BaseTools/Scripts/PackageDocumentTools/packagedoc_cli.py   |  4 ++--
 .../plugins/EdkPlugins/edk2/model/baseobject.py| 10 +-
 .../PackageDocumentTools/plugins/EdkPlugins/edk2/model/dec.py  |  4 ++--
 .../plugins/EdkPlugins/edk2/model/doxygengen.py|  8 
 .../plugins/EdkPlugins/edk2/model/doxygengen_spec.py   |  8 
 .../PackageDocumentTools/plugins/EdkPlugins/edk2/model/dsc.py  |  4 ++--  
.../PackageDocumentTools/plugins/EdkPlugins/edk2/model/inf.py  |  4 ++--
 7 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/BaseTools/Scripts/PackageDocumentTools/packagedoc_cli.py 
b/BaseTools/Scripts/PackageDocumentTools/packagedoc_cli.py
index e404a07cd7..5c65842a72 100644
--- a/BaseTools/Scripts/PackageDocumentTools/packagedoc_cli.py
+++ b/BaseTools/Scripts/PackageDocumentTools/packagedoc_cli.py
@@ -16,8 +16,8 @@ from __future__ import print_function  import os, sys, 
logging, traceback, subprocess  from optparse import OptionParser
 
-from .plugins.EdkPlugins.edk2.model import baseobject -from 
.plugins.EdkPlugins.edk2.model import doxygengen
+from plugins.EdkPlugins.edk2.model import baseobject from 
+plugins.EdkPlugins.edk2.model import doxygengen
 
 gArchMarcoDict = {'ALL'  : 'MDE_CPU_IA32 MDE_CPU_X64 MDE_CPU_EBC 
MDE_CPU_IPF _MSC_EXTENSIONS __GNUC__ __INTEL_COMPILER',
   'IA32_MSFT': 'MDE_CPU_IA32 _MSC_EXTENSIONS', diff --git 
a/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/baseobject.py
 
b/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/baseobject.py
index 0159bd5269..de15efd3f8 100644
--- 
a/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/baseobject.py
+++ b/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/mod
+++ el/baseobject.py
@@ -10,12 +10,12 @@
 # THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,  # 
WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 
-from ...basemodel import ini
-from ...edk2.model import dsc
-from ...edk2.model import inf
-from ...edk2.model import dec
+from plugins.EdkPlugins.basemodel import ini from 
+plugins.EdkPlugins.edk2.model import dsc from 
+plugins.EdkPlugins.edk2.model import inf from 
+plugins.EdkPlugins.edk2.model import dec
 import os
-from ...basemodel.message import *
+from plugins.EdkPlugins.basemodel.message import *
 
 class SurfaceObject(object):
 _objs = {}
diff --git 
a/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/dec.py 
b/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/dec.py
index 3d210f72ac..568076547b 100644
--- 
a/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/dec.py
+++ b/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/mod
+++ el/dec.py
@@ -11,9 +11,9 @@
 # WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 #
 
-from ...basemodel import ini
+from plugins.EdkPlugins.basemodel import ini
 import re, os
-from ...basemodel.message import *
+from plugins.EdkPlugins.basemodel.message import *
 
 class DECFile(ini.BaseINIFile):
 
diff --git 
a/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/doxygengen.py
 
b/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/doxygengen.py
index 9c299fbfc5..e31df262bc 100644
--- 
a/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/doxygengen.py
+++ b/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/mod
+++ el/doxygengen.py
@@ -16,7 +16,7 @@
 """This file produce action class to generate doxygen document for edk2 
codebase.
The action classes are shared by GUI and command line tools.
 """
-from ...basemodel import doxygen
+from plugins.EdkPlugins.basemodel import doxygen
 import os
 try:
 import wx
@@ -24,9 +24,9 @@ try:
 except:
 gInGui = False
 import re
-from ...edk2.model import inf
-from ...edk2.model import dec
-from ...basemodel.message import *
+from plugins.EdkPlugins.edk2.model import inf from 
+plugins.EdkPlugins.edk2.model import dec from 
+plugins.EdkPlugins.basemodel.message import *
 
 _ignore_dir = ['.svn', '_svn', 'cvs']
 _inf_key_description_mapping_table = {
diff --git 
a/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/doxygengen_spec.py

[edk2] [Patch] BaseTools: Add python3-distutils Ubuntu package checking

2019-02-25 Thread Feng, Bob C

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

Add python3-distutils Ubuntu package checking.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng 
Cc: Liming Gao 
---
 BaseTools/Tests/RunTests.py | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/BaseTools/Tests/RunTests.py b/BaseTools/Tests/RunTests.py
index 0dd65632d0..64778db981 100644
--- a/BaseTools/Tests/RunTests.py
+++ b/BaseTools/Tests/RunTests.py
@@ -17,10 +17,24 @@
 #
 import os
 import sys
 import unittest
 
+distutils_exist = True
+try:
+import distutils.util
+except:
+distutils_exist = False
+
+if not distutils_exist:
+print("""
+python3-distutil packages is missing. Please install it with the following 
command:
+
+bash$ sudo apt-get install python3-distutil
+""")
+sys.exit(-1)
+
 import TestTools
 
 def GetCTestSuite():
 import CToolsTests
 return CToolsTests.TheTestSuite()
-- 
2.20.1.windows.1

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

[edk2] Hang when calling ExitBootServices on IA32 firmware v1.0 on MinnowBoard Turbot

2019-02-25 Thread Rebecca Cran via edk2-devel

I've been trying to test a boot loader on my MinnowBoard Turbot board. 
It's running the latest 1.0 firmware from firmware.intel.com, and I'm 
seeing a hang at the point when gBS->ExitBootServices is called.


The last debug output is:

ConfigSccBootableDevicesAtExitBootService() End
SetUefiImageMemoryAttributes - 0x787EB000 - 0x4000 
(0x0008)
SetUefiImageMemoryAttributes - 0x787E8000 - 0x3000 
(0x0008)
SetUefiImageMemoryAttributes - 0x787E5000 - 0x3000 
(0x0008)
SetUefiImageMemoryAttributes - 0x787E1000 - 0x4000 
(0x0008)
SetUefiImageMemoryAttributes - 0x787DB000 - 0x6000 
(0x0008)
SetUefiImageMemoryAttributes - 0x787D5000 - 0x6000 
(0x0008)
SetUefiImageMemoryAttributes - 0x787CC000 - 0x9000 
(0x0008)
SetUefiImageMemoryAttributes - 0x787C6000 - 0x6000 
(0x0008)
SetUefiImageMemoryAttributes - 0x787C3000 - 0x3000 
(0x0008)
SetUefiImageMemoryAttributes - 0x787BD000 - 0x6000 
(0x0008)
SetUefiImageMemoryAttributes - 0x787B8000 - 0x5000 
(0x0008)
SetUefiImageMemoryAttributes - 0x787B2000 - 0x6000 
(0x0008)
SetUefiImageMemoryAttributes - 0x787AC000 - 0x6000 
(0x0008)
SetUefiImageMemoryAttributes - 0x787A9000 - 0x3000 
(0x0008)
SetUefiImageMemoryAttributes - 0x787A5000 - 0x4000 
(0x0008)
SetUefiImageMemoryAttributes - 0x787A2000 - 0x3000 
(0x0008)
SetUefiImageMemoryAttributes - 0x7879F000 - 0x3000 
(0x0008)



The X64 firmware works fine: the boot loader finishes and the kernel 
starts running.


I looked to see where ConfigSccBootableDevicesAtExitBootService might 
be, and unfortunately it seems it's in one of the binary modules.


The code for the boot loader is in 
https://svnweb.freebsd.org/base/head/stand/efi/loader/bootinfo.c?revision=338022=markup 
.



--
Rebecca Cran

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

Re: [edk2] [PATCH] Fix links in Maintainers.txt and remove slow, outdated sourceforge git mirror

2019-02-25 Thread Gao, Liming

Yes. This is a bug fix. I agree to push it for Q1 release. 

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Laszlo Ersek
>Sent: Tuesday, February 26, 2019 3:36 AM
>To: Gao, Liming ; Rebecca Cran
>; edk2-devel@lists.01.org
>Cc: Kinney, Michael D 
>Subject: Re: [edk2] [PATCH] Fix links in Maintainers.txt and remove slow,
>outdated sourceforge git mirror
>
>On 02/25/19 14:36, Gao, Liming wrote:
>> I can't clone edk2 code from http://git.code.sf.net/p/tianocore/edk2.
>Seemly, it doesn't work. So, I agree to remove it.
>>
>> Reviewed-by: Liming Gao 
>
>Do we consider this a bugfix, suitable to be pushed during the soft
>feature freeze?
>
>I suggest that we do.
>
>Thanks,
>Laszlo
>
>
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Laszlo Ersek
>>> Sent: Monday, February 25, 2019 6:07 PM
>>> To: Rebecca Cran ; edk2-devel@lists.01.org
>>> Cc: Kinney, Michael D 
>>> Subject: Re: [edk2] [PATCH] Fix links in Maintainers.txt and remove slow,
>outdated sourceforge git mirror
>>>
>>> On 02/23/19 06:18, Rebecca Cran via edk2-devel wrote:
 ---
  Maintainers.txt | 7 +++
  1 file changed, 3 insertions(+), 4 deletions(-)

 diff --git a/Maintainers.txt b/Maintainers.txt
 index 7f1061d6c1..d9d3d840c5 100644
 --- a/Maintainers.txt
 +++ b/Maintainers.txt
 @@ -31,11 +31,10 @@ Descriptions of section entries:

  EDK II
  --
 -W: http://www.tianocore.org/edk2/
 -L: https://lists.sourceforge.net/lists/listinfo/edk2-devel
 +W: https://github.com/tianocore/tianocore.github.io/wiki/EDK-II
 +L: https://lists.01.org/mailman/listinfo/edk2-devel
  T: git - https://github.com/tianocore/edk2.git
  T: git (mirror) - https://bitbucket.org/tianocore/edk2.git
 -T: git (mirror) - http://git.code.sf.net/p/tianocore/edk2
  T: svn (read-only, deprecated) -
>https://svn.code.sf.net/p/edk2/code/trunk/edk2

  Tianocore Stewards
 @@ -203,7 +202,7 @@ W:
>https://github.com/tianocore/tianocore.github.io/wiki/OptionRomPkg
  M: Ruiyu Ni 

  OvmfPkg
 -W: http://www.tianocore.org/ovmf/
 +W: https://github.com/tianocore/tianocore.github.io/wiki/OVMF
  M: Jordan Justen 
  M: Laszlo Ersek 
  M: Ard Biesheuvel 

>>>
>>> Reviewed-by: Laszlo Ersek 
>>>
>>> I can help push this change, but first let's wait for more feedback. I
>>> think the only point that might see a bit of discussion is dropping
>>>  (as you highlight in your followup).
>>>
>>> Thanks!
>>> Laszlo
>
>
>___
>edk2-devel mailing list
>edk2-devel@lists.01.org
>https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 1/1] EmbeddedPkg: Fix multiple Virtual RTC issues

2019-02-25 Thread Pete Batard

LibGetTime():
- Two variables were used for the epoch, where only one should have been.
- Also harmonize variable name to match the one used in LibSetTime.
LiBSetTime():
- Address possible underflows if time is set to start of epoch.
- Ensure that time being read does actually match time that was manually
  set (plus the time elapsed since), by subtracting number of seconds
  since reset.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 
---
 EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c | 34 
++--
 1 file changed, 25 insertions(+), 9 deletions(-)

diff --git 
a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c 
b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
index 4c354730d02b..5559106b696f 100644
--- a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
+++ b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
@@ -54,13 +54,12 @@ LibGetTime (
   )
 {
   EFI_STATUS  Status;
-  UINT32  EpochSeconds;
   INT16   TimeZone;
   UINT8   Daylight;
   UINT64  Freq;
   UINT64  Counter;
   UINT64  Remainder;
-  UINTN   ElapsedSeconds;
+  UINTN   EpochSeconds;
   UINTN   Size;
 
   if (Time == NULL) {
@@ -75,13 +74,13 @@ LibGetTime (
 
   // Get the epoch time from non-volatile storage
   Size = sizeof (UINTN);
-  ElapsedSeconds = 0;
+  EpochSeconds = 0;
   Status = EfiGetVariable (
  (CHAR16 *)mEpochVariableName,
  ,
  NULL,
  ,
- (VOID *)
+ (VOID *)
  );
   // Fall back to compilation-time epoch if not set
   if (EFI_ERROR (Status)) {
@@ -93,7 +92,7 @@ LibGetTime (
 // If you are attempting to use this library on such an environment, please
 // contact the edk2 mailing list, so we can try to add support for it.
 //
-ElapsedSeconds = BUILD_EPOCH;
+EpochSeconds = BUILD_EPOCH;
 DEBUG ((
   DEBUG_INFO,
   "LibGetTime: %s non volatile variable was not found - Using compilation 
time epoch.\n",
@@ -101,7 +100,7 @@ LibGetTime (
   ));
   }
   Counter = GetPerformanceCounter ();
-  ElapsedSeconds += DivU64x64Remainder (Counter, Freq, );
+  EpochSeconds += DivU64x64Remainder (Counter, Freq, );
 
   // Get the current time zone information from non-volatile storage
   Size = sizeof (TimeZone);
@@ -204,7 +203,7 @@ LibGetTime (
 }
   }
 
-  EpochToEfiTime (ElapsedSeconds, Time);
+  EpochToEfiTime (EpochSeconds, Time);
 
   // Because we use the performance counter, we can fill the Nanosecond 
attribute
   // provided that the remainder doesn't overflow 64-bit during multiplication.
@@ -240,6 +239,9 @@ LibSetTime (
   )
 {
   EFI_STATUS  Status;
+  UINT64  Freq;
+  UINT64  Counter;
+  UINT64  Remainder;
   UINTN   EpochSeconds;
 
   if (!IsTimeValid (Time)) {
@@ -249,16 +251,30 @@ LibSetTime (
   EpochSeconds = EfiTimeToEpoch (Time);
 
   // Adjust for the correct time zone, i.e. convert to UTC time zone
-  if (Time->TimeZone != EFI_UNSPECIFIED_TIMEZONE) {
+  if ((Time->TimeZone != EFI_UNSPECIFIED_TIMEZONE)
+  && (EpochSeconds > Time->TimeZone * SEC_PER_MIN)) {
 EpochSeconds -= Time->TimeZone * SEC_PER_MIN;
   }
 
   // Adjust for the correct period
-  if ((Time->Daylight & EFI_TIME_IN_DAYLIGHT) == EFI_TIME_IN_DAYLIGHT) {
+  if (((Time->Daylight & EFI_TIME_IN_DAYLIGHT) == EFI_TIME_IN_DAYLIGHT)
+  && (EpochSeconds > SEC_PER_HOUR)) {
 // Convert to un-adjusted time, i.e. fall back one hour
 EpochSeconds -= SEC_PER_HOUR;
   }
 
+  // Use the performance counter to substract the number of seconds
+  // since platform reset. Without this, setting time from the shell
+  // and immediately reading it back would result in a forward time
+  // offset, of the duration during which the platform has been up.
+  Freq = GetPerformanceCounterProperties (NULL, NULL);
+  if (Freq != 0) {
+Counter = GetPerformanceCounter ();
+if (EpochSeconds > DivU64x64Remainder (Counter, Freq, )) {
+  EpochSeconds -= DivU64x64Remainder (Counter, Freq, );
+}
+  }
+
   // Save the current time zone information into non-volatile storage
   Status = EfiSetVariable (
  (CHAR16 *)mTimeZoneVariableName,
-- 
2.17.0.windows.1

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

[edk2] [PATCH 0/1] EmbeddedPkg: Fix multiple Virtual RTC issues

2019-02-25 Thread Pete Batard

This patch fixes multiple issues in VirtualRealTimeClockLib.c:

1. Use of two separate variables (ElapsedSeconds and EpochSeconds) in
   LibGetTime(), where only a single one should have been used.

2. Possible underflow while sustracting TZ/DST offsets in LibSetTime()
   if the user sets a date that is very close to start of epoch.

3. Non substraction of elpased seconds since reset, which would lead to
   the following behaviour in UEFI shell (assuming for this example that
   exactly 5 minutes have elapsed since platform reset):

 Shell> time 12:00:00
 Shell> time
 12:05:01 (LOCAL)

   In other words, setting and immediately reading back the time would
   result in the returned value being offset by the time since reset.

   This last behaviour has been observed (and confirmed fixed) using an
   RPi3 platform.

Regards,

/Pete

Pete Batard (1):
  EmbeddedPkg: Fix multiple Virtual RTC issues

 .../VirtualRealTimeClockLib.c | 34 ++-
 1 file changed, 25 insertions(+), 9 deletions(-)

-- 
2.17.0.windows.1

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

Re: [edk2] [PATCH] StdLib: Update resolv.conf to use Google's public DNS servers

2019-02-25 Thread Carsey, Jaben

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, February 25, 2019 11:41 AM
> To: Rebecca Cran ; edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Daryl McDaniel  li...@mc2research.org>
> Subject: Re: [edk2] [PATCH] StdLib: Update resolv.conf to use Google's public
> DNS servers
> Importance: High
> 
> On 02/25/19 19:36, Rebecca Cran via edk2-devel wrote:
> > The current servers listed appear to be unusable. I suspect most
> > people will get correct DNS servers via DHCP, but the defaults
> > should work for anyone.
> >
> > Change the entries to be Google's public DNS servers.
> > Also, change the domain name to be example.com, to be more applicable
> > to consumers outside Intel.
> > ---
> >  StdLib/Efi/StdLib/etc/resolv.conf | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/StdLib/Efi/StdLib/etc/resolv.conf
> b/StdLib/Efi/StdLib/etc/resolv.conf
> > index 3ac16ac230..724e6297b2 100644
> > --- a/StdLib/Efi/StdLib/etc/resolv.conf
> > +++ b/StdLib/Efi/StdLib/etc/resolv.conf
> > @@ -1,13 +1,13 @@
> >  #
> >  #   Domain name
> >  #
> > -domain  intel.com
> > +domain  example.com
> >
> >  ;
> >  ;   Name Servers
> >  ;
> > -nameserver  206.63.63.61
> > -nameserver  216.251.100.1
> > +nameserver  8.8.8.8
> > +nameserver  8.8.4.4
> >
> >  ; nameserver  10.248.2.1
> >  ; nameserver  10.22.224.204
> >
> 
> Reviewed-by: Laszlo Ersek 
> 
> I'm quite undecided, but I vaguely feel that this should be pushed only
> after we tag "edk2-stable201903". The domain name change doesn't look
> like a pure bugfix, especially for Intel associates. Opinions?

Reviewed-by: Jaben Carsey 

I have no strong opinion on timing.

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

Re: [edk2] [PATCH] StdLib: Update resolv.conf to use Google's public DNS servers

2019-02-25 Thread Laszlo Ersek

On 02/25/19 19:36, Rebecca Cran via edk2-devel wrote:
> The current servers listed appear to be unusable. I suspect most
> people will get correct DNS servers via DHCP, but the defaults
> should work for anyone.
> 
> Change the entries to be Google's public DNS servers.
> Also, change the domain name to be example.com, to be more applicable
> to consumers outside Intel.
> ---
>  StdLib/Efi/StdLib/etc/resolv.conf | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/StdLib/Efi/StdLib/etc/resolv.conf 
> b/StdLib/Efi/StdLib/etc/resolv.conf
> index 3ac16ac230..724e6297b2 100644
> --- a/StdLib/Efi/StdLib/etc/resolv.conf
> +++ b/StdLib/Efi/StdLib/etc/resolv.conf
> @@ -1,13 +1,13 @@
>  #
>  #   Domain name
>  #
> -domain  intel.com
> +domain  example.com
>  
>  ;
>  ;   Name Servers
>  ;
> -nameserver  206.63.63.61
> -nameserver  216.251.100.1
> +nameserver  8.8.8.8
> +nameserver  8.8.4.4
>  
>  ; nameserver  10.248.2.1
>  ; nameserver  10.22.224.204
> 

Reviewed-by: Laszlo Ersek 

I'm quite undecided, but I vaguely feel that this should be pushed only
after we tag "edk2-stable201903". The domain name change doesn't look
like a pure bugfix, especially for Intel associates. Opinions?

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

Re: [edk2] [PATCH] Fix links in Maintainers.txt and remove slow, outdated sourceforge git mirror

2019-02-25 Thread Laszlo Ersek

On 02/25/19 14:36, Gao, Liming wrote:
> I can't clone edk2 code from http://git.code.sf.net/p/tianocore/edk2. Seemly, 
> it doesn't work. So, I agree to remove it. 
> 
> Reviewed-by: Liming Gao 

Do we consider this a bugfix, suitable to be pushed during the soft
feature freeze?

I suggest that we do.

Thanks,
Laszlo


>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>> Laszlo Ersek
>> Sent: Monday, February 25, 2019 6:07 PM
>> To: Rebecca Cran ; edk2-devel@lists.01.org
>> Cc: Kinney, Michael D 
>> Subject: Re: [edk2] [PATCH] Fix links in Maintainers.txt and remove slow, 
>> outdated sourceforge git mirror
>>
>> On 02/23/19 06:18, Rebecca Cran via edk2-devel wrote:
>>> ---
>>>  Maintainers.txt | 7 +++
>>>  1 file changed, 3 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/Maintainers.txt b/Maintainers.txt
>>> index 7f1061d6c1..d9d3d840c5 100644
>>> --- a/Maintainers.txt
>>> +++ b/Maintainers.txt
>>> @@ -31,11 +31,10 @@ Descriptions of section entries:
>>>
>>>  EDK II
>>>  --
>>> -W: http://www.tianocore.org/edk2/
>>> -L: https://lists.sourceforge.net/lists/listinfo/edk2-devel
>>> +W: https://github.com/tianocore/tianocore.github.io/wiki/EDK-II
>>> +L: https://lists.01.org/mailman/listinfo/edk2-devel
>>>  T: git - https://github.com/tianocore/edk2.git
>>>  T: git (mirror) - https://bitbucket.org/tianocore/edk2.git
>>> -T: git (mirror) - http://git.code.sf.net/p/tianocore/edk2
>>>  T: svn (read-only, deprecated) - 
>>> https://svn.code.sf.net/p/edk2/code/trunk/edk2
>>>
>>>  Tianocore Stewards
>>> @@ -203,7 +202,7 @@ W: 
>>> https://github.com/tianocore/tianocore.github.io/wiki/OptionRomPkg
>>>  M: Ruiyu Ni 
>>>
>>>  OvmfPkg
>>> -W: http://www.tianocore.org/ovmf/
>>> +W: https://github.com/tianocore/tianocore.github.io/wiki/OVMF
>>>  M: Jordan Justen 
>>>  M: Laszlo Ersek 
>>>  M: Ard Biesheuvel 
>>>
>>
>> Reviewed-by: Laszlo Ersek 
>>
>> I can help push this change, but first let's wait for more feedback. I
>> think the only point that might see a bit of discussion is dropping
>>  (as you highlight in your followup).
>>
>> Thanks!
>> Laszlo


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

Re: [edk2] [PATCH 0/2] DynamicTablesPkg Updates

2019-02-25 Thread Laszlo Ersek

On 02/21/19 19:38, Ashish Singhal wrote:
> DynamicTablesPkg/DynamicTableManagerDxe: Update DEPEX
> 
> This patch adds appropriate dependencies to DynamicTableManagerDxe.
> The initialization function fails if gEdkiiDynamicTableFactoryProtocolGuid
> and gEdkiiConfigurationManagerProtocolGuid are not present already. Since
> we are not relying on a callback but locating these in initialization, we
> should add these dependencies. Towards the end of initialization function
> where we build and install ACPI tables, we locate gEfiAcpiTableProtocolGuid
> and return a failure is not present. We need to add approriate dependency
> for this as well. Adding these proper dependencies would make the code not
> rely on drivers forcefully dispatched in a particular order
> 
> DynamicTablesPkg/AcpiSpcrLibArm: Support 16550 UART.
> 
> This patch adds support for 16550 UART in ACPI SPCR table. HLOS support for
> this type of UART is already present.
> 
> Both the patches have been verified to work on hardware.
> 
> Ashish Singhal (2):
>   DynamicTablesPkg/DynamicTableManagerDxe: Update DEPEX
>   DynamicTablesPkg/AcpiSpcrLibArm: Support 16550 UART.
> 
>  .../Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.inf | 4 
> +++-
>  DynamicTablesPkg/Library/Acpi/Arm/AcpiSpcrLibArm/SpcrGenerator.c  | 2 ++
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 

I think the first patch in this series could be considered a bugfix, but
the second one can't. Therefore minimally commit 0692ef87594f
("DynamicTablesPkg/AcpiSpcrLibArm: Support 16550 UART.", 2019-02-25)
should be reverted.

Please see the explanation at
.
The patches were posted on the 21st, but only reviewed today (on the 25th).

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

Re: [edk2] [PATCH v1 0/6] DynamicTablesPkg: Framework updates and fixes

2019-02-25 Thread Laszlo Ersek

On 02/21/19 19:14, Sami Mujawar wrote:
> This patch series updates the Dynamic Tables Framework to
> incorporate the following changes:
>   * Fix DEPEX to load modules in correct order.
>   * Add options for OEMs to provide OEM Table ID and revision.
>   * Update DBG2_DEBUG_PORT_DDI macro to remove unused parameter.
>   * Remove GIC Distributor ID field.
>   * Minor updates to comments and typo fixes.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Sami Mujawar 
> 
> The changes can be seen at:
> https://github.com/samimujawar/edk2/tree/473_dynamic_tables_framework_v1
> 
> The corresponding edk2-platform code changes can be seen at:
> https://github.com/samimujawar/edk2-platforms/tree/473_dynamic_tables_framework_v1
> 
> Sami Mujawar (6):
>   DynamicTablesPkg: Fix depex and protocol section
>   DynamicTablesPkg: Rename enum used for ID Mapping
>   DynamicTablesPkg: Add OEM Info
>   DynamicTablesPkg: DGB2: Update DBG2_DEBUG_PORT_DDI
>   DynamicTablesPkg: Remove GIC Distributor Id field
>   DynamicTablesPkg: Minor updates and fix typos
> 
>  DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/DynamicTableFactoryDxe.inf | 
>  7 +-
>  DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.inf | 
> 11 +--
>  DynamicTablesPkg/Include/ArmNameSpaceObjects.h | 
> 73 +++-
>  DynamicTablesPkg/Include/Library/TableHelperLib.h  | 
>  4 +-
>  DynamicTablesPkg/Include/StandardNameSpaceObjects.h| 
> 18 +
>  DynamicTablesPkg/Library/Acpi/Arm/AcpiDbg2LibArm/Dbg2Generator.c   | 
>  7 +-
>  DynamicTablesPkg/Library/Acpi/Arm/AcpiFadtLibArm/FadtGenerator.c   | 
>  2 +-
>  DynamicTablesPkg/Library/Acpi/Arm/AcpiGtdtLibArm/GtdtGenerator.c   | 
>  2 +-
>  DynamicTablesPkg/Library/Acpi/Arm/AcpiIortLibArm/IortGenerator.c   | 
>  8 +--
>  DynamicTablesPkg/Library/Acpi/Arm/AcpiMadtLibArm/MadtGenerator.c   | 
>  6 +-
>  DynamicTablesPkg/Library/Acpi/Arm/AcpiMcfgLibArm/McfgGenerator.c   | 
>  2 +-
>  DynamicTablesPkg/Library/Acpi/Arm/AcpiSpcrLibArm/SpcrGenerator.c   | 
>  2 +-
>  DynamicTablesPkg/Library/Common/TableHelperLib/TableHelper.c   | 
> 26 +--
>  13 files changed, 119 insertions(+), 49 deletions(-)
> 

This patch series (0692ef87594f..07f4e26eb6fe) should be reverted, in my
opinion. In particular, patch #3 ("DynamicTablesPkg: Add OEM Info")
looks very much like a feature addition. We entered the soft feature
freeze on 2019-Feb-22.

https://lists.01.org/pipermail/edk2-devel/2019-February/037169.html

The patch was posted on 2019-Feb-21 alright, but Alexei's review
appeared on 2019-Feb-25 only (today).

The definition at
 says that the
necessary reviews too must not cross over into the soft feature freeze.

Please revert this set, and reapply it after the next stable tag is applied.

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

Re: [edk2] [PATCH] MdePkg/UefiLib: Simplify protocol un/installation abstraction

2019-02-25 Thread Ashish Singhal

Mike,

Do you have any update on this change yet?

Thanks
Ashish

-Original Message-
From: Kinney, Michael D  
Sent: Tuesday, February 19, 2019 12:56 PM
To: Ashish Singhal ; edk2-devel@lists.01.org; Kinney, 
Michael D 
Cc: Gao, Liming 
Subject: RE: [PATCH] MdePkg/UefiLib: Simplify protocol un/installation 
abstraction

Ashish,

Thanks for looking at simplifying this logic again.

I have not had a chance to run the size analysis yet.

I will get back to you in a couple of days.

Thanks,

Mike

> -Original Message-
> From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> Sent: Tuesday, February 19, 2019 8:19 AM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ;
> Gao, Liming 
> Subject: RE: [PATCH] MdePkg/UefiLib: Simplify protocol
> un/installation abstraction
> 
> Hello Mike/Lao,
> 
> Were you able to have a look at this?
> 
> Thanks
> Ashish
> 
> -Original Message-
> From: Ashish Singhal 
> Sent: Monday, February 4, 2019 1:16 PM
> To: edk2-devel@lists.01.org
> Cc: michael.d.kin...@intel.com; liming@intel.com;
> Ashish Singhal 
> Subject: [PATCH] MdePkg/UefiLib: Simplify protocol
> un/installation abstraction
> 
> Add helper functions to operate upon protocol
> installation and
> uninstallation instead of every function doing it by
> itself.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ashish Singhal 
> ---
>  MdePkg/Library/UefiLib/UefiDriverModel.c | 2040 +-
> 
>  1 file changed, 342 insertions(+), 1698 deletions(-)
> 
> diff --git a/MdePkg/Library/UefiLib/UefiDriverModel.c
> b/MdePkg/Library/UefiLib/UefiDriverModel.c
> index 262d8bc..268edf7 100644
> --- a/MdePkg/Library/UefiLib/UefiDriverModel.c
> +++ b/MdePkg/Library/UefiLib/UefiDriverModel.c
> @@ -17,6 +17,290 @@
> 
>  #include "UefiLibInternal.h"
> 
> +
> +#define MAX_SUPPORTED_PROTOCOLS 7
> +typedef struct {
> +  EFI_GUID *Guid;
> +  VOID *Interface;
> +} EFI_PROCESS_PROTOCOL;
> +
> +
> +static
> +EFI_STATUS
> +EFIAPI
> +EfiLibProcessProtocols (
> +  IN CONST EFI_HANDLE
> ImageHandle,
> +  IN EFI_DRIVER_BINDING_PROTOCOL
> *DriverBinding,
> +  IN EFI_HANDLE
> DriverBindingHandle,
> +  IN BOOLEAN  Install,
> +  IN CONST EFI_PROCESS_PROTOCOL
> *ProtocolArray
> +  )
> +{
> +  ASSERT (DriverBinding != NULL);
> +  ASSERT (ProtocolArray != NULL);
> +
> +  if (Install) {
> +//
> +// Update the ImageHandle and DriverBindingHandle
> fields of the Driver Binding Protocol
> +//
> +DriverBinding->ImageHandle = ImageHandle;
> +DriverBinding->DriverBindingHandle =
> DriverBindingHandle;
> +
> +return gBS->InstallMultipleProtocolInterfaces (
> +  >DriverBindingHandle,
> +  ProtocolArray[0].Guid,
> ProtocolArray[0].Interface,
> +  ProtocolArray[1].Guid,
> ProtocolArray[1].Interface,
> +  ProtocolArray[2].Guid,
> ProtocolArray[2].Interface,
> +  ProtocolArray[3].Guid,
> ProtocolArray[3].Interface,
> +  ProtocolArray[4].Guid,
> ProtocolArray[4].Interface,
> +  ProtocolArray[5].Guid,
> ProtocolArray[5].Interface,
> +  ProtocolArray[6].Guid,
> ProtocolArray[6].Interface,
> +  NULL
> +  );
> +  } else {
> +return gBS->UninstallMultipleProtocolInterfaces (
> +  DriverBinding->DriverBindingHandle,
> +  ProtocolArray[0].Guid,
> ProtocolArray[0].Interface,
> +  ProtocolArray[1].Guid,
> ProtocolArray[1].Interface,
> +  ProtocolArray[2].Guid,
> ProtocolArray[2].Interface,
> +  ProtocolArray[3].Guid,
> ProtocolArray[3].Interface,
> +  ProtocolArray[4].Guid,
> ProtocolArray[4].Interface,
> +  ProtocolArray[5].Guid,
> ProtocolArray[5].Interface,
> +  ProtocolArray[6].Guid,
> ProtocolArray[6].Interface,
> +  NULL
> +  );
> +  }
> +}
> +
> +
> +
> +static
> +EFI_STATUS
> +EFIAPI
> +EfiLibProcessAllDriverProtocols (
> +  IN CONST EFI_HANDLE
> ImageHandle,
> +  IN EFI_DRIVER_BINDING_PROTOCOL
> *DriverBinding,
> +  IN EFI_HANDLE
> DriverBindingHandle,
> +  IN BOOLEAN  Install,
> +  IN CONST EFI_COMPONENT_NAME_PROTOCOL
> *ComponentName,
> +  IN CONST EFI_DRIVER_CONFIGURATION_PROTOCOL
> *DriverConfiguration,
> +  IN CONST EFI_DRIVER_DIAGNOSTICS_PROTOCOL
> *DriverDiagnostics
> +  )
> +{
> +  EFI_STATUS   Status;
> +  EFI_PROCESS_PROTOCOL
> ProtocolArray[MAX_SUPPORTED_PROTOCOLS];
> +  UINT8ProtocolCount;
> +
> +  ASSERT (DriverBinding != NULL);
> +
> +  //
> +  // ZI the ProtocolArray structure. Both
> InstallMultipleProtocolInterfaces
> +  // and UninstallMultipleProtocolInterfaces would
> stop processing ProtocolArray
> +  // elements as soon as they encounter a NULL.
> +  //
> +  ZeroMem(ProtocolArray, sizeof(ProtocolArray));
> +  ProtocolCount = 0;
>

[edk2] [PATCH] StdLib: Update resolv.conf to use Google's public DNS servers

2019-02-25 Thread Rebecca Cran via edk2-devel

The current servers listed appear to be unusable. I suspect most
people will get correct DNS servers via DHCP, but the defaults
should work for anyone.

Change the entries to be Google's public DNS servers.
Also, change the domain name to be example.com, to be more applicable
to consumers outside Intel.
---
 StdLib/Efi/StdLib/etc/resolv.conf | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/StdLib/Efi/StdLib/etc/resolv.conf 
b/StdLib/Efi/StdLib/etc/resolv.conf
index 3ac16ac230..724e6297b2 100644
--- a/StdLib/Efi/StdLib/etc/resolv.conf
+++ b/StdLib/Efi/StdLib/etc/resolv.conf
@@ -1,13 +1,13 @@
 #
 #   Domain name
 #
-domain  intel.com
+domain  example.com
 
 ;
 ;   Name Servers
 ;
-nameserver  206.63.63.61
-nameserver  216.251.100.1
+nameserver  8.8.8.8
+nameserver  8.8.4.4
 
 ; nameserver  10.248.2.1
 ; nameserver  10.22.224.204
-- 
2.20.1

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

Re: [edk2] [PATCH edk2-platforms v1 0/4] Platform/ARM: Updates corresponding to Dynamic Tables Framework changes

2019-02-25 Thread Sami Mujawar

Hi Leif, Ard,

I have pushed the Dynamic Tables Framework changes to tianocore\edk2.

You should now be able to build the edk2-platform patches for dynamic tables 
with latest edk2 master.

Regards,

Sami Mujawar

-Original Message-
From: Sami Mujawar  
Sent: 21 February 2019 06:15 PM
To: edk2-devel@lists.01.org
Cc: Sami Mujawar ; ard.biesheu...@linaro.org; 
leif.lindh...@linaro.org; michael.d.kin...@intel.com; Alexei Fedorov 
; Matteo Carlini ; Stephanie 
Hughes-Fitt ; nd 
Subject: [PATCH edk2-platforms v1 0/4] Platform/ARM: Updates corresponding to 
Dynamic Tables Framework changes

The Dynamic tables framework has been updated to incorporated a series of 
updates namely:
  * Resolving DEPEX order for modules.
  * Removing GIC Distributor ID

This patch series implement the corresponding changes required in the platform 
Configuration Manager.

Note: This patch series is dependent on the patch series:
https://lists.01.org/pipermail/edk2-devel/2019-January/035611.html

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar 

The changes can be seen at:
https://github.com/samimujawar/edk2-platforms/tree/473_dynamic_tables_framework_v1

The corresponding edk2 code changes can be seen at:
https://github.com/samimujawar/edk2/tree/473_dynamic_tables_framework_v1

Sami Mujawar (4):
  Platform/ARM: Juno: Configuration Manager depex
  Platform/ARM: FVP: Configuration Manager depex
  Platform/ARM: FVP: Config Mgr remove GICD ID
  Platform/ARM: Juno: Config Mgr remove GICD ID

 
Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
  | 1 -
 
Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManagerDxe.inf
 | 4 ++--
 
Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
  | 1 -
 
Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManagerDxe.inf
 | 4 ++--
 4 files changed, 4 insertions(+), 6 deletions(-)

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


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

Re: [edk2] [PATCH] StdLib: Update resolv.conf to use Google's DNS servers.

2019-02-25 Thread Carsey, Jaben

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, February 25, 2019 2:11 AM
> To: Rebecca Cran ; edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Daryl McDaniel  li...@mc2research.org>
> Subject: Re: [edk2] [PATCH] StdLib: Update resolv.conf to use Google's DNS
> servers.
> Importance: High
> 
> On 02/23/19 04:41, Rebecca Cran via edk2-devel wrote:
> > Sorry, I've fixed the subject line and added maintainers to the Cc list.
> >
> > This patch also changes the domain from intel.com to example.com, to be
> > more applicable to consumers outside Intel.
> >
> >
> > --
> >
> > Rebecca Cran
> >
> >
> > On 2/22/19 8:38 PM, Rebecca Cran wrote:
> >> The current servers listed appear to be unusable. I suspect most
> >> people will get correct DNS servers via DHCP, but the defaults
> >> should work for anyone.
> >> ---
> >>   StdLib/Efi/StdLib/etc/resolv.conf | 6 +++---
> >>   1 file changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/StdLib/Efi/StdLib/etc/resolv.conf
> >> b/StdLib/Efi/StdLib/etc/resolv.conf
> >> index 3ac16ac230..724e6297b2 100644
> >> --- a/StdLib/Efi/StdLib/etc/resolv.conf
> >> +++ b/StdLib/Efi/StdLib/etc/resolv.conf
> >> @@ -1,13 +1,13 @@
> >>   #
> >>   #   Domain name
> >>   #
> >> -domain  intel.com
> >> +domain  example.com
> >>     ;
> >>   ;   Name Servers
> >>   ;
> >> -nameserver  206.63.63.61
> >> -nameserver  216.251.100.1
> >> +nameserver  8.8.8.8
> >> +nameserver  8.8.4.4
> >>     ; nameserver  10.248.2.1
> >>   ; nameserver  10.22.224.204
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> 
> Can you please repost the patch with an updated subject line / commit
> message? That way we can apply it with git-am without tweaking on the
> maintainer side.
> 
> In v2, you can include:
> 
> Reviewed-by: Laszlo Ersek 
> 
> (If reposting is too much burden, I can do the changes manually once the
> ShellPkg maintainers okay the patch; it's just that the less a
> maintainer has to update a patch, the safer / more robust the process is.)
> 
> Thanks
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] StdLib: Update resolv.conf to use Google's DNS servers.

2019-02-25 Thread Rebecca Cran via edk2-devel



On February 25, 2019 at 3:11:16 AM, Laszlo Ersek 
(ler...@redhat.com(mailto:ler...@redhat.com)) wrote: 

> 
> Can you please repost the patch with an updated subject line / commit
> message? That way we can apply it with git-am without tweaking on the
> maintainer side. 





Sure!






Rebecca





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

Re: [edk2] [PATCH v1 0/6] DynamicTablesPkg: Framework updates and fixes

2019-02-25 Thread Alexei Fedorov

Reviewed-by:Alexei Fedorov 


Alexei



From: Sami Mujawar 
Sent: 21 February 2019 18:14
To: edk2-devel@lists.01.org
Cc: Alexei Fedorov; leif.lindh...@linaro.org; Matteo Carlini; Stephanie 
Hughes-Fitt; nd
Subject: [PATCH v1 0/6] DynamicTablesPkg: Framework updates and fixes

This patch series updates the Dynamic Tables Framework to
incorporate the following changes:
  * Fix DEPEX to load modules in correct order.
  * Add options for OEMs to provide OEM Table ID and revision.
  * Update DBG2_DEBUG_PORT_DDI macro to remove unused parameter.
  * Remove GIC Distributor ID field.
  * Minor updates to comments and typo fixes.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar 

The changes can be seen at:
https://github.com/samimujawar/edk2/tree/473_dynamic_tables_framework_v1

The corresponding edk2-platform code changes can be seen at:
https://github.com/samimujawar/edk2-platforms/tree/473_dynamic_tables_framework_v1

Sami Mujawar (6):
  DynamicTablesPkg: Fix depex and protocol section
  DynamicTablesPkg: Rename enum used for ID Mapping
  DynamicTablesPkg: Add OEM Info
  DynamicTablesPkg: DGB2: Update DBG2_DEBUG_PORT_DDI
  DynamicTablesPkg: Remove GIC Distributor Id field
  DynamicTablesPkg: Minor updates and fix typos

 DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/DynamicTableFactoryDxe.inf |  
7 +-
 DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.inf | 
11 +--
 DynamicTablesPkg/Include/ArmNameSpaceObjects.h | 
73 +++-
 DynamicTablesPkg/Include/Library/TableHelperLib.h  |  
4 +-
 DynamicTablesPkg/Include/StandardNameSpaceObjects.h| 
18 +
 DynamicTablesPkg/Library/Acpi/Arm/AcpiDbg2LibArm/Dbg2Generator.c   |  
7 +-
 DynamicTablesPkg/Library/Acpi/Arm/AcpiFadtLibArm/FadtGenerator.c   |  
2 +-
 DynamicTablesPkg/Library/Acpi/Arm/AcpiGtdtLibArm/GtdtGenerator.c   |  
2 +-
 DynamicTablesPkg/Library/Acpi/Arm/AcpiIortLibArm/IortGenerator.c   |  
8 +--
 DynamicTablesPkg/Library/Acpi/Arm/AcpiMadtLibArm/MadtGenerator.c   |  
6 +-
 DynamicTablesPkg/Library/Acpi/Arm/AcpiMcfgLibArm/McfgGenerator.c   |  
2 +-
 DynamicTablesPkg/Library/Acpi/Arm/AcpiSpcrLibArm/SpcrGenerator.c   |  
2 +-
 DynamicTablesPkg/Library/Common/TableHelperLib/TableHelper.c   | 
26 +--
 13 files changed, 119 insertions(+), 49 deletions(-)

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


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

Re: [edk2] [PATCH 0/2] DynamicTablesPkg Updates

2019-02-25 Thread Alexei Fedorov

Reviewed-by: Alexei Fedorov 

Alexei

From: Sami Mujawar
Sent: 25 February 2019 13:38:17
To: Ashish Singhal; edk2-devel@lists.01.org
Cc: Alexei Fedorov; nd
Subject: RE: [PATCH 0/2] DynamicTablesPkg Updates

Reviewed-by: Sami Mujawar 

-Original Message-
From: Ashish Singhal 
Sent: 21 February 2019 06:39 PM
To: edk2-devel@lists.01.org
Cc: Sami Mujawar ; Alexei Fedorov 
; Ashish Singhal 
Subject: [PATCH 0/2] DynamicTablesPkg Updates

DynamicTablesPkg/DynamicTableManagerDxe: Update DEPEX

This patch adds appropriate dependencies to DynamicTableManagerDxe.
The initialization function fails if gEdkiiDynamicTableFactoryProtocolGuid
and gEdkiiConfigurationManagerProtocolGuid are not present already. Since we 
are not relying on a callback but locating these in initialization, we should 
add these dependencies. Towards the end of initialization function where we 
build and install ACPI tables, we locate gEfiAcpiTableProtocolGuid and return a 
failure is not present. We need to add approriate dependency for this as well. 
Adding these proper dependencies would make the code not rely on drivers 
forcefully dispatched in a particular order

DynamicTablesPkg/AcpiSpcrLibArm: Support 16550 UART.

This patch adds support for 16550 UART in ACPI SPCR table. HLOS support for 
this type of UART is already present.

Both the patches have been verified to work on hardware.

Ashish Singhal (2):
  DynamicTablesPkg/DynamicTableManagerDxe: Update DEPEX
  DynamicTablesPkg/AcpiSpcrLibArm: Support 16550 UART.

 .../Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.inf | 4 +++-
 DynamicTablesPkg/Library/Acpi/Arm/AcpiSpcrLibArm/SpcrGenerator.c  | 2 ++
 2 files changed, 5 insertions(+), 1 deletion(-)

--
2.7.4

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

Re: [edk2] [PATCH] Fix links in Maintainers.txt and remove slow, outdated sourceforge git mirror

2019-02-25 Thread Gao, Liming

I can't clone edk2 code from http://git.code.sf.net/p/tianocore/edk2. Seemly, 
it doesn't work. So, I agree to remove it. 

Reviewed-by: Liming Gao 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
> Ersek
> Sent: Monday, February 25, 2019 6:07 PM
> To: Rebecca Cran ; edk2-devel@lists.01.org
> Cc: Kinney, Michael D 
> Subject: Re: [edk2] [PATCH] Fix links in Maintainers.txt and remove slow, 
> outdated sourceforge git mirror
> 
> On 02/23/19 06:18, Rebecca Cran via edk2-devel wrote:
> > ---
> >  Maintainers.txt | 7 +++
> >  1 file changed, 3 insertions(+), 4 deletions(-)
> >
> > diff --git a/Maintainers.txt b/Maintainers.txt
> > index 7f1061d6c1..d9d3d840c5 100644
> > --- a/Maintainers.txt
> > +++ b/Maintainers.txt
> > @@ -31,11 +31,10 @@ Descriptions of section entries:
> >
> >  EDK II
> >  --
> > -W: http://www.tianocore.org/edk2/
> > -L: https://lists.sourceforge.net/lists/listinfo/edk2-devel
> > +W: https://github.com/tianocore/tianocore.github.io/wiki/EDK-II
> > +L: https://lists.01.org/mailman/listinfo/edk2-devel
> >  T: git - https://github.com/tianocore/edk2.git
> >  T: git (mirror) - https://bitbucket.org/tianocore/edk2.git
> > -T: git (mirror) - http://git.code.sf.net/p/tianocore/edk2
> >  T: svn (read-only, deprecated) - 
> > https://svn.code.sf.net/p/edk2/code/trunk/edk2
> >
> >  Tianocore Stewards
> > @@ -203,7 +202,7 @@ W: 
> > https://github.com/tianocore/tianocore.github.io/wiki/OptionRomPkg
> >  M: Ruiyu Ni 
> >
> >  OvmfPkg
> > -W: http://www.tianocore.org/ovmf/
> > +W: https://github.com/tianocore/tianocore.github.io/wiki/OVMF
> >  M: Jordan Justen 
> >  M: Laszlo Ersek 
> >  M: Ard Biesheuvel 
> >
> 
> Reviewed-by: Laszlo Ersek 
> 
> I can help push this change, but first let's wait for more feedback. I
> think the only point that might see a bit of discussion is dropping
>  (as you highlight in your followup).
> 
> Thanks!
> Laszlo
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/2] DynamicTablesPkg Updates

2019-02-25 Thread Sami Mujawar

Reviewed-by: Sami Mujawar 

-Original Message-
From: Ashish Singhal  
Sent: 21 February 2019 06:39 PM
To: edk2-devel@lists.01.org
Cc: Sami Mujawar ; Alexei Fedorov 
; Ashish Singhal 
Subject: [PATCH 0/2] DynamicTablesPkg Updates

DynamicTablesPkg/DynamicTableManagerDxe: Update DEPEX

This patch adds appropriate dependencies to DynamicTableManagerDxe.
The initialization function fails if gEdkiiDynamicTableFactoryProtocolGuid
and gEdkiiConfigurationManagerProtocolGuid are not present already. Since we 
are not relying on a callback but locating these in initialization, we should 
add these dependencies. Towards the end of initialization function where we 
build and install ACPI tables, we locate gEfiAcpiTableProtocolGuid and return a 
failure is not present. We need to add approriate dependency for this as well. 
Adding these proper dependencies would make the code not rely on drivers 
forcefully dispatched in a particular order

DynamicTablesPkg/AcpiSpcrLibArm: Support 16550 UART.

This patch adds support for 16550 UART in ACPI SPCR table. HLOS support for 
this type of UART is already present.

Both the patches have been verified to work on hardware.

Ashish Singhal (2):
  DynamicTablesPkg/DynamicTableManagerDxe: Update DEPEX
  DynamicTablesPkg/AcpiSpcrLibArm: Support 16550 UART.

 .../Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.inf | 4 +++-
 DynamicTablesPkg/Library/Acpi/Arm/AcpiSpcrLibArm/SpcrGenerator.c  | 2 ++
 2 files changed, 5 insertions(+), 1 deletion(-)

--
2.7.4

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

Re: [edk2] [Patch 2/2] BaseTools: Fix a Eot issue.

2019-02-25 Thread Gao, Liming

Reviewed-by: Liming Gao 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Feng, 
> Bob C
> Sent: Monday, February 25, 2019 5:23 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming 
> Subject: [edk2] [Patch 2/2] BaseTools: Fix a Eot issue.
> 
> FirmwareVolume.UnDispatchedFfsDict is mutated during iteration,
> convert the FirmwareVolume.UnDispatchedFfsDict.keys() to a new list
>  to resolve this problem.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Bob Feng 
> Cc: Liming Gao 
> ---
>  BaseTools/Source/Python/Eot/EotMain.py | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/Eot/EotMain.py 
> b/BaseTools/Source/Python/Eot/EotMain.py
> index 3020f6525e..4802aea8b1 100644
> --- a/BaseTools/Source/Python/Eot/EotMain.py
> +++ b/BaseTools/Source/Python/Eot/EotMain.py
> @@ -389,11 +389,11 @@ class FirmwareVolume(Image):
>  FfsSecCoreGuid = None
>  FfsPeiCoreGuid = None
>  FfsDxeCoreGuid = None
>  FfsPeiPrioriGuid = None
>  FfsDxePrioriGuid = None
> -for FfsID in self.UnDispatchedFfsDict.keys():
> +for FfsID in list(self.UnDispatchedFfsDict.keys()):
>  Ffs = self.UnDispatchedFfsDict[FfsID]
>  if Ffs.Type == 0x03:
>  FfsSecCoreGuid = FfsID
>  continue
>  if Ffs.Type == 0x04:
> @@ -495,11 +495,11 @@ class FirmwareVolume(Image):
>  EotGlobalData.gPpiList[Record[0].lower()] = ModuleGuid
> 
>  def DisPatchDxe(self, Db):
>  IsInstalled = False
>  ScheduleList = sdict()
> -for FfsID in self.UnDispatchedFfsDict.keys():
> +for FfsID in list(self.UnDispatchedFfsDict.keys()):
>  CouldBeLoaded = False
>  DepexString = ''
>  FileDepex = None
>  Ffs = self.UnDispatchedFfsDict[FfsID]
>  if Ffs.Type == 0x07:
> @@ -560,11 +560,11 @@ class FirmwareVolume(Image):
>  if IsInstalled:
>  self.DisPatchDxe(Db)
> 
>  def DisPatchPei(self, Db):
>  IsInstalled = False
> -for FfsID in self.UnDispatchedFfsDict.keys():
> +for FfsID in list(self.UnDispatchedFfsDict.keys()):
>  CouldBeLoaded = True
>  DepexString = ''
>  FileDepex = None
>  Ffs = self.UnDispatchedFfsDict[FfsID]
>  if Ffs.Type == 0x06 or Ffs.Type == 0x08:
> --
> 2.20.1.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 1/2] BaseTools: Eot failed when enable python3

2019-02-25 Thread Gao, Liming

Reviewed-by: Liming Gao 

> -Original Message-
> From: Feng, Bob C
> Sent: Monday, February 25, 2019 5:22 PM
> To: edk2-devel@lists.01.org
> Cc: Feng, Bob C ; Gao, Liming 
> Subject: [Patch 1/2] BaseTools: Eot failed when enable python3
> 
> The Eot will report error when python3 enabled.
> We replaced sdict with collections.OrderedDict in python3
> patch set, but the sdict implement "append" method which is not
> implemented in collections.OrderedDict.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Bob Feng 
> Cc: Liming Gao 
> ---
>  BaseTools/Source/Python/Eot/EotMain.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/BaseTools/Source/Python/Eot/EotMain.py 
> b/BaseTools/Source/Python/Eot/EotMain.py
> index 56aa48d2a1..3020f6525e 100644
> --- a/BaseTools/Source/Python/Eot/EotMain.py
> +++ b/BaseTools/Source/Python/Eot/EotMain.py
> @@ -1103,11 +1103,11 @@ class MultipleFv(FirmwareVolume):
> 
>  Fv = FirmwareVolume(FvName)
>  Fv.frombuffer(Buf, 0, len(Buf))
> 
>  self.BasicInfo.append([Fv.Name, Fv.FileSystemGuid, Fv.Size])
> -self.FfsDict.append(Fv.FfsDict)
> +self.FfsDict.update(Fv.FfsDict)
> 
>  ## Class Eot
>  #
>  # This class is used to define Eot main entrance
>  #
> --
> 2.20.1.windows.1

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

[edk2] [PATCH 2/2] Vlv2TbltDevicePkg: Fix build failure issue after ECP cleanup

2019-02-25 Thread Zailiang Sun

Moved stuff in the three old packages IA32FamilyCpuPkg, Vlv2BinaryPkg and
Vlv2MiscBinariesPkg into a new package Vlv2SocBinPkg. Updated the build scripts
and added build instructions in Readme.md.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: David Wei 
Cc: Zailiang Sun 
Cc: Yi Qian 
Cc: Michael Kinney 
---
 .../FirmwareUpdate/FirmwareUpdate.inf | 177 ++--
 Vlv2TbltDevicePkg/Build_IFWI.bat  |  35 ++-
 .../MultiPlatformLib/MultiPlatformLib.inf | 166 +--
 .../MonoStatusCode/MonoStatusCode.inf | 156 +-
 .../PlatformCpuInfoDxe/PlatformCpuInfoDxe.inf | 122 
 .../PlatformInitPei/PlatformInitPei.inf   | 246 
 Vlv2TbltDevicePkg/PlatformPei/PlatformPei.inf | 270 +-
 Vlv2TbltDevicePkg/PlatformPkg.fdf |   8 +-
 Vlv2TbltDevicePkg/PlatformPkgIA32.dsc |   4 +-
 Vlv2TbltDevicePkg/PlatformPkgX64.dsc  |   4 +-
 Vlv2TbltDevicePkg/PpmPolicy/PpmPolicy.inf |   2 +-
 Vlv2TbltDevicePkg/Readme.md   |  75 +
 Vlv2TbltDevicePkg/Stitch/IFWIStitch.bat   |   4 +-
 Vlv2TbltDevicePkg/bld_vlv.bat | 110 +++
 14 files changed, 727 insertions(+), 652 deletions(-)
 create mode 100644 Vlv2TbltDevicePkg/Readme.md

diff --git a/Vlv2TbltDevicePkg/Application/FirmwareUpdate/FirmwareUpdate.inf 
b/Vlv2TbltDevicePkg/Application/FirmwareUpdate/FirmwareUpdate.inf
index 4e2ec32ac6..8ca7a663cd 100644
--- a/Vlv2TbltDevicePkg/Application/FirmwareUpdate/FirmwareUpdate.inf
+++ b/Vlv2TbltDevicePkg/Application/FirmwareUpdate/FirmwareUpdate.inf
@@ -1,90 +1,89 @@
-## @file
-# Implements a Tunnel Mountain specific flash update program.  This will allow
-# users to update all regions of the flash as needed in a given update.
-#
-# Copyright (c) 2006  - 2014, Intel Corporation. All rights reserved.
-#  


-# This program and the accompanying materials are licensed and made available 
under

-# the terms and conditions of the BSD License that accompanies this 
distribution.  

-# The full text of the license may be found at 


-# http://opensource.org/licenses/bsd-license.php.  


-#  


-# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,


-# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.

-#  


-#
-#
-##
-
-[Defines]
-  INF_VERSION= 0x00010005
-  BASE_NAME  = FirmwareUpdate
-  FILE_GUID  = AEFAF26C-FB6D-4fef-AF7A-9D78FF201FCA
-  MODULE_TYPE= UEFI_APPLICATION
-  VERSION_STRING = 1.0
-  ENTRY_POINT= ShellCEntryLib
-
-#
-# The following information is for reference only and not required by the 
build tools.
-#
-#  VALID_ARCHITECTURES   = X64
-#
-
-[Sources]
-  FirmwareUpdateStrings.uni
-  FirmwareUpdate.c
-  FirmwareUpdate.h
-
-[Packages]
-  MdeModulePkg/MdeModulePkg.dec
-  MdePkg/MdePkg.dec
-  IA32FamilyCpuPkg/IA32FamilyCpuPkg.dec
-  Vlv2TbltDevicePkg/PlatformPkg.dec
-  Vlv2DeviceRefCodePkg/Vlv2DeviceRefCodePkg.dec
-  ShellPkg/ShellPkg.dec
-
-[LibraryClasses]
-  BaseLib
-  BaseMemoryLib
-  CacheMaintenanceLib
-  DebugLib
-  FileHandleLib
-  #FlashDeviceLib
-  #SpiFlashCommonLib
-  MemoryAllocationLib
-  PcdLib
-  ShellCEntryLib
-  ShellLib
-  UefiApplicationEntryPoint
-  UefiBootServicesTableLib
-  UefiLib
-  UefiRuntimeServicesTableLib
-
-[Protocols]
-  gEfiLoadedImageProtocolGuid   # PROTOCOL ALWAYS_CONSUMED
-  gEfiFirmwareVolumeBlockProtocolGuid   # PROTOCOL ALWAYS_CONSUMED
-  gEfiSpiProtocolGuid
-
-[Pcd]
-  gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize   ## CONSUMES
-
-[FixedPcd]
-#  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize
-#  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase
-#  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
-#  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase
-#  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
-#  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase
-
-  gPlatformModuleTokenSpaceGuid.PcdFlashChipBase
-  gPlatformModuleTokenSpaceGuid.PcdFlashChipSize
-  gPlatformModuleTokenSpaceGuid.PcdFlashDescriptorBase
-  gPlatformModuleTokenSpaceGuid.PcdFlashDescriptorSize
-  gPlatformModuleTokenSpaceGuid.PcdTxeRomBase
-  gPlatformModuleTokenSpaceGuid.PcdTxeRomSize
-  gPlatformModuleTokenSpaceGuid.PcdBiosRomBase
-  gPlatformModuleTokenSpaceGuid.PcdBiosRomSize
-
-[BuildOptions]
-  MSFT:*_*_X64_CC_FLAGS   = /Od 
+## @file
+# Implements a Tunnel Mountain specific flash update program.  This will allow
+# users to update all regions of

[edk2] [PATCH 1/2] Vlv2TbltDevicePkg: ECP Cleanup.

2019-02-25 Thread Zailiang Sun

From: zwei4 

Remove modules of EdkCompatibilityPkg from DSC/FDF of Vlv2TbltDevicePkg to make 
this platform ECP free.

Test: Boot to 64-bit Windows 10.

Cc: Zailiang Sun 
Cc: Yi Qian 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: David Wei 
---
 Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c |  8 +-
 .../AcpiPlatform/AcpiPlatform.inf |  4 +-
 Vlv2TbltDevicePkg/PciPlatform/PciPlatform.c   |  8 +-
 Vlv2TbltDevicePkg/PciPlatform/PciPlatform.inf |  4 +-
 Vlv2TbltDevicePkg/PlatformPei/BootMode.c  | 56 +---
 Vlv2TbltDevicePkg/PlatformPei/PlatformPei.inf |  4 +-
 Vlv2TbltDevicePkg/PlatformPkg.fdf | 11 +--
 Vlv2TbltDevicePkg/PlatformPkgGcc.fdf  | 10 --
 Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc   | 87 --
 Vlv2TbltDevicePkg/PlatformPkgIA32.dsc | 91 +--
 Vlv2TbltDevicePkg/PlatformPkgX64.dsc  | 87 --
 Vlv2TbltDevicePkg/PlatformSmm/PlatformSmm.inf |  6 +-
 .../VlvPlatformInitDxe/IgdOpRegion.c  | 10 +-
 .../VlvPlatformInitDxe/VlvPlatformInitDxe.inf |  6 +-
 14 files changed, 30 insertions(+), 362 deletions(-)

diff --git a/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c 
b/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c
index 4a913eb723..d575533319 100644
--- a/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c
+++ b/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2004  - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2004  - 2018, Intel Corporation. All rights reserved.
 
 
   This program and the accompanying materials are licensed and made available 
under
@@ -35,7 +35,7 @@ Abstract:
 
 #include 
 #include 
-#include 
+#include 
 #include "AcpiPlatform.h"
 #include "AcpiPlatformHooks.h"
 #include "AcpiPlatformHooksLib.h"
@@ -785,7 +785,7 @@ AcpiPlatformEntryPoint (
   EFI_STATUSStatus;
   EFI_STATUSAcpiStatus;
   EFI_ACPI_SUPPORT_PROTOCOL *AcpiSupport;
-  EFI_FIRMWARE_VOLUME_PROTOCOL  *FwVol;
+  EFI_FIRMWARE_VOLUME2_PROTOCOL  *FwVol;
   INTN  Instance;
   EFI_ACPI_COMMON_HEADER*CurrentTable;
   UINTN TableHandle;
@@ -856,7 +856,7 @@ AcpiPlatformEntryPoint (
   //
   // Locate the firmware volume protocol.
   //
-  Status = LocateSupportProtocol (, (VOID **) 
, 1);
+  Status = LocateSupportProtocol (, (VOID **) 
, 1);
   ASSERT_EFI_ERROR (Status);
 
   //
diff --git a/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.inf 
b/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.inf
index 24fa913b33..74a531369d 100644
--- a/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.inf
+++ b/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.inf
@@ -1,6 +1,6 @@
 #
 #
-# Copyright (c)  1999  - 2014, Intel Corporation. All rights reserved
+# Copyright (c)  1999  - 2018, Intel Corporation. All rights reserved
 #  


 # This program and the accompanying materials are licensed and made available 
under

 # the terms and conditions of the BSD License that accompanies this 
distribution.  

@@ -77,7 +77,7 @@
   gEfiMpServiceProtocolGuid
   gEfiGlobalNvsAreaProtocolGuid
   gEfiTcgProtocolGuid
-  gEfiFirmwareVolumeProtocolGuid
+  gEfiFirmwareVolume2ProtocolGuid
   gIgdOpRegionProtocolGuid
 
 [Pcd]
diff --git a/Vlv2TbltDevicePkg/PciPlatform/PciPlatform.c 
b/Vlv2TbltDevicePkg/PciPlatform/PciPlatform.c
index 08f5df2a25..27ae9de7a0 100644
--- a/Vlv2TbltDevicePkg/PciPlatform/PciPlatform.c
+++ b/Vlv2TbltDevicePkg/PciPlatform/PciPlatform.c
@@ -36,7 +36,7 @@ Abstract:
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
@@ -66,12 +66,12 @@ GetRawImage (
   EFI_HANDLE*HandleBuffer;
   UINTN HandleCount;
   UINTN Index;
-  EFI_FIRMWARE_VOLUME_PROTOCOL  *Fv;
+  EFI_FIRMWARE_VOLUME2_PROTOCOL  *Fv;
   UINT32AuthenticationStatus;
 
   Status = gBS->LocateHandleBuffer (
   ByProtocol,
-  ,
+  ,
   NULL,
   ,
   
@@ -86,7 +86,7 @@ GetRawImage (
   for (Index = 0; Index < HandleCount; Index++) {
 Status = gBS->HandleProtocol(
 HandleBuffer[Index],
-,
+,
 (VOID **) 
 );
 
diff --git a/Vlv2TbltDevicePkg/PciPlatform/PciPlatform.inf 
b/Vlv2TbltDevicePkg/PciPlatform/PciPlatform.inf
index a296c24b75..ce3140f830 100644
--- a/Vlv2TbltDevicePkg/PciPlatform/PciPlatform.inf
+++ b/Vlv2TbltDevicePkg/PciPlatform/PciPlatform.inf
@@ -1,6 +1,6 @@
 #/*++
 #
-# Copyright (c)  2003  - 2014, Intel Corporation. All rights reserved
+# Copyright (c)  2003  - 2018, Intel Corporation. All rights reserved
 #  


 # This program

Re: [edk2] [edk2-announce] Soft Feature Freeze starts today for edk2-stable201903

2019-02-25 Thread Laszlo Ersek

On 02/23/19 15:46, Gao, Liming wrote:
> Lazlo:
>   I agree. I don't think there is the rule break for the patch set of boot 
> progress reporting. I also prefer to push them early next week. 

Thank you, I just pushed the series.

https://lists.01.org/pipermail/edk2-devel/2019-February/037212.html

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

Re: [edk2] [PATCH v3 0/5] MdeModulePkg, OvmfPkg, ArmVirtPkg: more visible boot progress reporting

2019-02-25 Thread Laszlo Ersek

On 02/21/19 11:41, Laszlo Ersek wrote:
> Repo:   https://github.com/lersek/edk2.git
> Branch: boot_diags_v3
> 
> Addressing feedback for v2, which was posted at:
> 
>   https://lists.01.org/pipermail/edk2-devel/2019-February/036965.html
>   20190220081644.8238-1-lersek@redhat.com">http://mid.mail-archive.com/20190220081644.8238-1-lersek@redhat.com
> 
> Changes are noted per patch.
> 
> Cc: Anthony Perard 
> Cc: Ard Biesheuvel 
> Cc: Dandan Bi 
> Cc: Hao Wu 
> Cc: Jian J Wang 
> Cc: Jordan Justen 
> Cc: Julien Grall 
> Cc: Ray Ni 
> Cc: Sean Brogan 
> Cc: Star Zeng 
> 
> Thanks!
> Laszlo
> 
> Laszlo Ersek (5):
>   MdeModulePkg/UefiBootManagerLib: fix LoadImage/StartImage status code
> rep.
>   OvmfPkg: add library to track boot option loading/starting on the
> console
>   OvmfPkg/PlatformBootManagerLib: display boot option loading/starting
>   ArmVirtPkg/ArmVirtQemu*: enable minimal Status Code Routing in DXE
>   ArmVirtPkg/PlatformBootManagerLib: display boot option
> loading/starting
> 
>  ArmVirtPkg/ArmVirtQemu.dsc   |  11 +
>  ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc |   5 +
>  ArmVirtPkg/ArmVirtQemuKernel.dsc |  11 +
>  ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c   |   3 +
>  ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf |   1 +
>  MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c |  65 
> ++--
>  MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h |   1 +
>  OvmfPkg/Include/Library/PlatformBmPrintScLib.h   |  41 
> +++
>  OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf|  66 
> +
>  OvmfPkg/Library/PlatformBmPrintScLib/StatusCodeHandler.c | 310 
> 
>  OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c |   3 +
>  OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf|   1 +
>  OvmfPkg/OvmfPkg.dec  |   5 +
>  OvmfPkg/OvmfPkgIa32.dsc  |   1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc   |   1 +
>  OvmfPkg/OvmfPkgX64.dsc   |   1 +
>  16 files changed, 508 insertions(+), 18 deletions(-)
>  create mode 100644 OvmfPkg/Include/Library/PlatformBmPrintScLib.h
>  create mode 100644 
> OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf
>  create mode 100644 OvmfPkg/Library/PlatformBmPrintScLib/StatusCodeHandler.c
> 

Series pushed as commit range 2df879827442..1797f32e0a19.

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

Re: [edk2] [PATCH v3 1/5] MdeModulePkg/UefiBootManagerLib: fix LoadImage/StartImage status code rep.

2019-02-25 Thread Laszlo Ersek

On 02/25/19 09:27, Ni, Ray wrote:
> On 2/23/2019 1:16 AM, Laszlo Ersek wrote:
>> Yes, I was fully aware of that.
>>
>> However:
>>
>> The issue is that, in the BmReportLoadFailure() function, we do some
>> work*before*  we call REPORT_STATUS_CODE_EX(). We have an ASSERT(), a
>> ZeroMem(), and a field assignment.
>>
>> If status code reporting is disabled for EFI_ERROR_CODE in the platform,
>> then said work will be wasted. We can optimize this by checking for
>> ReportErrorCodeEnabled() up-front, because we know for sure that later
>> on we will report the status code with EFI_ERROR_CODE type.
>>
>> In other words, this approach is similar to DEBUG_CODE(). In some cases,
>> logging a piece of information with DEBUG() takes non-trivial
>> computation. And it would be a waste, for example in RELEASE builds, to
>> perform the computation, and then throw away only the result (the log
>> message). Therefore the DEBUG_CODE macro is used, and the whole work is
>> eliminated in RELEASE builds.
>>
>> The idea is the same here. If the compiler can statically deduce that
>> ReportErrorCodeEnabled() will always return FALSE -- for example because
>> the ReportStatusCodeLib instance in question looks at
>> "PcdReportStatusCodePropertyMask", and the PCD is Fixed-at-Build, and
>> the corresponding bit is clear --, then the compiler can eliminate the
>> entire BmReportLoadFailure() function. This is good for both flash usage
>> and for performance.
>>
>> I'm fine either way, but first, please confirm again that you really
>> want me to remove the ReportErrorCodeEnabled() check, before pushing.
>>
>> Thanks!
>> Laszlo
> 
> Thanks for the explanation. I am fine with both.
> Reviewed-by: Ray Ni 
> 

Thank you, Ray. I opted for pushing v3 as-is.

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

Re: [edk2] [PATCH] StdLib: Update resolv.conf to use Google's DNS servers.

2019-02-25 Thread Laszlo Ersek

On 02/23/19 04:41, Rebecca Cran via edk2-devel wrote:
> Sorry, I've fixed the subject line and added maintainers to the Cc list.
> 
> This patch also changes the domain from intel.com to example.com, to be
> more applicable to consumers outside Intel.
> 
> 
> -- 
> 
> Rebecca Cran
> 
> 
> On 2/22/19 8:38 PM, Rebecca Cran wrote:
>> The current servers listed appear to be unusable. I suspect most
>> people will get correct DNS servers via DHCP, but the defaults
>> should work for anyone.
>> ---
>>   StdLib/Efi/StdLib/etc/resolv.conf | 6 +++---
>>   1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/StdLib/Efi/StdLib/etc/resolv.conf
>> b/StdLib/Efi/StdLib/etc/resolv.conf
>> index 3ac16ac230..724e6297b2 100644
>> --- a/StdLib/Efi/StdLib/etc/resolv.conf
>> +++ b/StdLib/Efi/StdLib/etc/resolv.conf
>> @@ -1,13 +1,13 @@
>>   #
>>   #   Domain name
>>   #
>> -domain  intel.com
>> +domain  example.com
>>     ;
>>   ;   Name Servers
>>   ;
>> -nameserver  206.63.63.61
>> -nameserver  216.251.100.1
>> +nameserver  8.8.8.8
>> +nameserver  8.8.4.4
>>     ; nameserver  10.248.2.1
>>   ; nameserver  10.22.224.204
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

Can you please repost the patch with an updated subject line / commit
message? That way we can apply it with git-am without tweaking on the
maintainer side.

In v2, you can include:

Reviewed-by: Laszlo Ersek 

(If reposting is too much burden, I can do the changes manually once the
ShellPkg maintainers okay the patch; it's just that the less a
maintainer has to update a patch, the safer / more robust the process is.)

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

Re: [edk2] [PATCH] Fix links in Maintainers.txt and remove slow, outdated sourceforge git mirror

2019-02-25 Thread Laszlo Ersek

On 02/23/19 06:18, Rebecca Cran via edk2-devel wrote:
> ---
>  Maintainers.txt | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 7f1061d6c1..d9d3d840c5 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -31,11 +31,10 @@ Descriptions of section entries:
>  
>  EDK II
>  --
> -W: http://www.tianocore.org/edk2/
> -L: https://lists.sourceforge.net/lists/listinfo/edk2-devel
> +W: https://github.com/tianocore/tianocore.github.io/wiki/EDK-II
> +L: https://lists.01.org/mailman/listinfo/edk2-devel
>  T: git - https://github.com/tianocore/edk2.git
>  T: git (mirror) - https://bitbucket.org/tianocore/edk2.git
> -T: git (mirror) - http://git.code.sf.net/p/tianocore/edk2
>  T: svn (read-only, deprecated) - 
> https://svn.code.sf.net/p/edk2/code/trunk/edk2
>  
>  Tianocore Stewards
> @@ -203,7 +202,7 @@ W: 
> https://github.com/tianocore/tianocore.github.io/wiki/OptionRomPkg
>  M: Ruiyu Ni 
>  
>  OvmfPkg
> -W: http://www.tianocore.org/ovmf/
> +W: https://github.com/tianocore/tianocore.github.io/wiki/OVMF
>  M: Jordan Justen 
>  M: Laszlo Ersek 
>  M: Ard Biesheuvel 
> 

Reviewed-by: Laszlo Ersek 

I can help push this change, but first let's wait for more feedback. I
think the only point that might see a bit of discussion is dropping
 (as you highlight in your followup).

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

[edk2] [Patch 2/2] BaseTools: Fix a Eot issue.

2019-02-25 Thread Feng, Bob C

FirmwareVolume.UnDispatchedFfsDict is mutated during iteration,
convert the FirmwareVolume.UnDispatchedFfsDict.keys() to a new list
 to resolve this problem.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng 
Cc: Liming Gao 
---
 BaseTools/Source/Python/Eot/EotMain.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/BaseTools/Source/Python/Eot/EotMain.py 
b/BaseTools/Source/Python/Eot/EotMain.py
index 3020f6525e..4802aea8b1 100644
--- a/BaseTools/Source/Python/Eot/EotMain.py
+++ b/BaseTools/Source/Python/Eot/EotMain.py
@@ -389,11 +389,11 @@ class FirmwareVolume(Image):
 FfsSecCoreGuid = None
 FfsPeiCoreGuid = None
 FfsDxeCoreGuid = None
 FfsPeiPrioriGuid = None
 FfsDxePrioriGuid = None
-for FfsID in self.UnDispatchedFfsDict.keys():
+for FfsID in list(self.UnDispatchedFfsDict.keys()):
 Ffs = self.UnDispatchedFfsDict[FfsID]
 if Ffs.Type == 0x03:
 FfsSecCoreGuid = FfsID
 continue
 if Ffs.Type == 0x04:
@@ -495,11 +495,11 @@ class FirmwareVolume(Image):
 EotGlobalData.gPpiList[Record[0].lower()] = ModuleGuid
 
 def DisPatchDxe(self, Db):
 IsInstalled = False
 ScheduleList = sdict()
-for FfsID in self.UnDispatchedFfsDict.keys():
+for FfsID in list(self.UnDispatchedFfsDict.keys()):
 CouldBeLoaded = False
 DepexString = ''
 FileDepex = None
 Ffs = self.UnDispatchedFfsDict[FfsID]
 if Ffs.Type == 0x07:
@@ -560,11 +560,11 @@ class FirmwareVolume(Image):
 if IsInstalled:
 self.DisPatchDxe(Db)
 
 def DisPatchPei(self, Db):
 IsInstalled = False
-for FfsID in self.UnDispatchedFfsDict.keys():
+for FfsID in list(self.UnDispatchedFfsDict.keys()):
 CouldBeLoaded = True
 DepexString = ''
 FileDepex = None
 Ffs = self.UnDispatchedFfsDict[FfsID]
 if Ffs.Type == 0x06 or Ffs.Type == 0x08:
-- 
2.20.1.windows.1

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

[edk2] [Patch 1/2] BaseTools: Eot failed when enable python3

2019-02-25 Thread Feng, Bob C

The Eot will report error when python3 enabled.
We replaced sdict with collections.OrderedDict in python3
patch set, but the sdict implement "append" method which is not
implemented in collections.OrderedDict.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng 
Cc: Liming Gao 
---
 BaseTools/Source/Python/Eot/EotMain.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/Eot/EotMain.py 
b/BaseTools/Source/Python/Eot/EotMain.py
index 56aa48d2a1..3020f6525e 100644
--- a/BaseTools/Source/Python/Eot/EotMain.py
+++ b/BaseTools/Source/Python/Eot/EotMain.py
@@ -1103,11 +1103,11 @@ class MultipleFv(FirmwareVolume):
 
 Fv = FirmwareVolume(FvName)
 Fv.frombuffer(Buf, 0, len(Buf))
 
 self.BasicInfo.append([Fv.Name, Fv.FileSystemGuid, Fv.Size])
-self.FfsDict.append(Fv.FfsDict)
+self.FfsDict.update(Fv.FfsDict)
 
 ## Class Eot
 #
 # This class is used to define Eot main entrance
 #
-- 
2.20.1.windows.1

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

[edk2] [MdeModulePkg/Library v1 0/1] Fix exception issue while UsbMass block io uninstalled

2019-02-25 Thread Ming Huang

Another exception issue while UsbMass block io uninstalled when boot to grub:
The system environment: virtual-CDROM(USB interface) via BMC, insert a
iso file to virtual-CDROM, like ubuntu-18.04.1-server-arm64.iso, change
virtaul-CDROM to first boot option.

Disconnecting virtual-CDROM when boot to grub menu
"Install Ubuntu Server"
then select "Install Ubuntu Server", system will also get exception.

The root cause is the EFI_BLOCK_IO_PROTOCOL for USBMass will be uninstalled
in this situation after print some transfer error(see blow), but grub will
still use the block io which had initialized by grub_efidisk_init() in 
efidisk.c.
When run m->io_align in grub_efidisk_open ():
  if (m->io_align & (m->io_align - 1))
grub will get exception for the EFI_BLOCK_IO_PROTOCOL had uninstalled and
the memory had set to 0xAF by PcdDebugClearMemoryValue.

This exception look like the matching problem grub and uefi. Is it need to
do something in uefi side or grub side?

The open source grub grub_efidisk_open function chunk:
  m = d->block_io->media;
  /* FIXME: Probably it is better to store the block size in the disk,
 and total sectors should be replaced with total blocks.  */
  grub_dprintf ("efidisk",
"m = %p, last block = %llx, block size = %x, io align = %x\n",
m, (unsigned long long) m->last_block, m->block_size,
m->io_align);

  /* Ensure required buffer alignment is a power of two (or is zero). */
  if (m->io_align & (m->io_align - 1))

USB transfer error log:
UsbBootExecCmd: Device Error to Exec 0x0 Cmd (Result = 1)
EhcExecTransfer: transfer failed with 40
EhcBulkTransfer: error - Device Error, transfer - 40
UsbBotExecCommand: UsbBotSendCommand (Device Error)
UsbBootRequestSense: (Device Error) CmdResult=0x1
UsbBootDetectMedia: UsbBootIsUnitReady (Device Error)
---

Ming Huang (1):
  MdeModulePkg/UefiBootManangerLib: Fix exception issue

 MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

-- 
2.9.5

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

[edk2] [MdeModulePkg/Library v1 1/1] MdeModulePkg/UefiBootManangerLib: Fix exception issue

2019-02-25 Thread Ming Huang

The system environment: virtual-CDROM(USB interface) via BMC, insert a
iso file to CDROM, like ubuntu-18.04.1-server-arm64.iso, change CDROM
to first boot option.
With release version bios, disconnecting CDROM when boot to
"1 seconds left, Press Esc or F2 to enter Setup"
then system will get a exception.

The root cause is the EFI_BLOCK_IO_PROTOCOL for UsbMass will be uninstalled
in this situation after print some transfer error. The status will be
invalid parameter. This line will get a exception for BlockIo not point
to right address:
AllocatePool (BlockIo->Media->BlockSize)
So, here need to judge the status not using ASSERT_EFI_ERROR.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ming Huang 
---
 MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
index d5957db610d9..c2f1c651b02f 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
@@ -1068,7 +1068,9 @@ BmExpandMediaDevicePath (
   // Block IO read/write will success.
   //
   Status = gBS->HandleProtocol (Handle, , (VOID **) 
);
-  ASSERT_EFI_ERROR (Status);
+  if (EFI_ERROR (Status)) {
+return NULL;
+  }
   Buffer = AllocatePool (BlockIo->Media->BlockSize);
   if (Buffer != NULL) {
 BlockIo->ReadBlocks (
-- 
2.9.5

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

Re: [edk2] [PATCH v3 1/5] MdeModulePkg/UefiBootManagerLib: fix LoadImage/StartImage status code rep.

2019-02-25 Thread Ni, Ray


On 2/23/2019 1:16 AM, Laszlo Ersek wrote:

Yes, I was fully aware of that.

However:

The issue is that, in the BmReportLoadFailure() function, we do some
work*before*  we call REPORT_STATUS_CODE_EX(). We have an ASSERT(), a
ZeroMem(), and a field assignment.

If status code reporting is disabled for EFI_ERROR_CODE in the platform,
then said work will be wasted. We can optimize this by checking for
ReportErrorCodeEnabled() up-front, because we know for sure that later
on we will report the status code with EFI_ERROR_CODE type.

In other words, this approach is similar to DEBUG_CODE(). In some cases,
logging a piece of information with DEBUG() takes non-trivial
computation. And it would be a waste, for example in RELEASE builds, to
perform the computation, and then throw away only the result (the log
message). Therefore the DEBUG_CODE macro is used, and the whole work is
eliminated in RELEASE builds.

The idea is the same here. If the compiler can statically deduce that
ReportErrorCodeEnabled() will always return FALSE -- for example because
the ReportStatusCodeLib instance in question looks at
"PcdReportStatusCodePropertyMask", and the PCD is Fixed-at-Build, and
the corresponding bit is clear --, then the compiler can eliminate the
entire BmReportLoadFailure() function. This is good for both flash usage
and for performance.

I'm fine either way, but first, please confirm again that you really
want me to remove the ReportErrorCodeEnabled() check, before pushing.

Thanks!
Laszlo


Thanks for the explanation. I am fine with both.
Reviewed-by: Ray Ni 

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

Re: [edk2] [PATCH] MdeModulePkg/VariableSmmRuntimeDxe: Refactor locating Variable Arch Protocol

2019-02-25 Thread Jagadeesh Ujja

Hi Ard/Star

On Thu, Feb 21, 2019 at 3:15 PM Ard Biesheuvel
 wrote:
>
> On Thu, 21 Feb 2019 at 10:33, Zeng, Star  wrote:
> >
> > On 2019/2/21 17:11, Ard Biesheuvel wrote:
> > > On Thu, 21 Feb 2019 at 10:04, Laszlo Ersek  wrote:
> > >>
> > >> On 02/20/19 13:23, Ard Biesheuvel wrote:
> > >>> On Wed, 20 Feb 2019 at 06:53, Jagadeesh Ujja  
> > >>> wrote:
> > 
> >  hi Ard,
> >  On Tue, Feb 19, 2019 at 6:55 PM Ard Biesheuvel
> >   wrote:
> > >
> > > Hello Jagadeesh,
> > >
> > > On Tue, 19 Feb 2019 at 11:47, Jagadeesh Ujja  
> > > wrote:
> > >>
> > >> In preparation for providing a standalone MM based non-secure 
> > >> variable
> > >> runtime driver, factor out some portions that are specific to the
> > >> traditional driver, mainly related to locating variable arch protocol
> > >> and variable write arch protocol, which are not required to be 
> > >> located
> > >> when using standalone MM based secure variable implementation.
> > >>
> > >
> > > While i think this change is correct from a technical perspective, I
> > > don't think this is the right approach.
> > >
> >  these changes are mandatory, this is one of the possible solution.
> > 
> > > It was a deliberate decision to expose the MM services in a way that
> > > only the producer of the communication protocol is aware of the
> > > implementation details, i.e., whether it is backed by tradtional MM or
> > > standalone MM.
> > >
> >  can you please provide more details on how "exposing the MM services"
> >  will help to resolve the issue here. if this helps, definitely i will 
> >  use that.
> > 
> > >>>
> > >>> Let me rephrase this for the benefit of the MdeModulePkg maintainers,
> > >>> and ask them their opinion.
> > >>>
> > >>> Currently, the DXE runtime driver that produces the architectural
> > >>> varstore protocols that are based on communication with MM components
> > >>> living elsewhere, rely on the EFI protocol database for sequencing.
> > >>> I.e., after dispatch, they wait for certain protocols to be installed
> > >>> into the DXE protocol database by the SMM drivers before proceeding to
> > >>> install the variable arch protocols.
> > >>>
> > >>> This does not work for standalone MM, since it has no access to the
> > >>> DXE protocol database, nor is it needed, since it may be assumed that
> > >>> the MM execution context is fully configured by the time the DXE phase
> > >>> starts.
> > >>>
> > >>> Jagadeesh's proposal is to factor this out, and create two different
> > >>> .INFs to build the same DXE runtime driver in two different ways. This
> > >>> defeats the purpose of having an abstract MM communication protocol,
> > >>> so it is something I would like to avoid. On the other hand, is it not
> > >>> obvious how to parameterize this requirement in another way.
> > >>>
> > >>> For the moment, I could live with putting this into a library, and
> > >>> leave it up to the platform to ensure the combination of the library
> > >>> resolution with the driver that produces the MM communicate protocol
> > >>> is a sane one.
> > >>>
> > >>> Any thoughts?
> > >>
> > >> I think I'm missing the gist of the library approach; still, would it be
> > >> possible for affected platforms (i.e. those that depend on standalone
> > >> MM) to procude the necessary DXE protocols (for unblocking the variable
> > >> runtime driver) in a platform DXE driver?
> > >>
> > >
> > > Yes, that is the other option: we could create a library that
> > > unconditionally produces those protocols and hook it into the MM
> > > communication driver via NULL library class resolution.
> > >
> >
> > I am not familiar with standalone MM, either ARM. So may have no much
> > valuable opinion.
> >
> > For this case, standalone MM could not install DXE protocols into DXE
> > protocol database to notify the wrapper (VariableSmmRuntimeDxe), so need
> > another way to install the DXE protocols, right?
>
> Yes
>
> > Could standalone MM assume the MM handler for variable is ready when MM
> > communication driver runs?
>
> Yes
>
> > If yes, a NULL library instance should work (as a stub to install the
> > DXE protocols in its constructor). :)
> >
>
> Yes, that was my suggestion.
>
> So Jagadeesh, could you please take this approach instead?
>
thanks for the inputs.
Sorry i was on leave, will do the necessary changes and  Soon will
submit the patches for review.

> - Create a library in StandaloneMmPkg with LIBRARY_CLASS = NULL and a
> constructor that installs the two protocols.
> - Update your platform so that the MM communication driver is included as
>
> ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf {
>   
> NULL|StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.inf
> }
>
> I don't think this will violate any ordering constraints, given that
> the drivers that have a dependency on these protocols also have a
> dependency on the MM

Re: [edk2] [PATCH v1] MdeModulePkg/UfsBlockIoPei: Correct use of 'DeviceIndex' in BlkIO PPI

2019-02-25 Thread Ni, Ray

Reviewed-by: Ray Ni 

> -Original Message-
> From: edk2-devel  On Behalf Of Hao Wu
> Sent: Friday, February 15, 2019 10:55 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A 
> Subject: [edk2] [PATCH v1] MdeModulePkg/UfsBlockIoPei: Correct use of
> 'DeviceIndex' in BlkIO PPI
> 
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1474
> 
> Within UfsBlockIoPei, the current implementation of the Block IO(2)
> services:
> 
> UfsBlockIoPeimGetMediaInfo
> UfsBlockIoPeimReadBlocks
> UfsBlockIoPeimGetMediaInfo2
> UfsBlockIoPeimReadBlocks2
> 
> does not handle the input parameter 'DeviceIndex' properly.
> 
> According to both of the PI spec and the function description comments:
> 
> > DeviceIndexSpecifies the block device to which the function wants
> >to talk. ... This index is a number from one to
> >NumberBlockDevices.
> 
> But current codes incorrectly treat the valid range of 'DeviceIndex' as 0 to
> (NumberBlockDevices - 1).
> 
> This commit is to address this issue.
> 
> Cc: Jian J Wang 
> Cc: Ray Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsBlockIoPei.c | 56 +++-
> 
>  1 file changed, 31 insertions(+), 25 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsBlockIoPei.c
> b/MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsBlockIoPei.c
> index 204e456413..c969ab45f5 100644
> --- a/MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsBlockIoPei.c
> +++ b/MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsBlockIoPei.c
> @@ -1,6 +1,6 @@
>  /** @file
> 
> -  Copyright (c) 2014 - 2018, Intel Corporation. All rights reserved.
> +  Copyright (c) 2014 - 2019, 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 @@ -587,15 +587,17 @@ UfsBlockIoPeimGetMediaInfo (
>EFI_SCSI_DISK_CAPACITY_DATA16  Capacity16;
>UINTN  DataLength;
>BOOLEANNeedRetry;
> +  UINTN  Lun;
> 
>Private   = GET_UFS_PEIM_HC_PRIVATE_DATA_FROM_THIS (This);
>NeedRetry = TRUE;
> 
> -  if (DeviceIndex >= UFS_PEIM_MAX_LUNS) {
> +  if ((DeviceIndex == 0) || (DeviceIndex > UFS_PEIM_MAX_LUNS)) {
>  return EFI_INVALID_PARAMETER;
>}
> 
> -  if ((Private->Luns.BitMask & (BIT0 << DeviceIndex)) == 0) {
> +  Lun = DeviceIndex - 1;
> +  if ((Private->Luns.BitMask & (BIT0 << Lun)) == 0) {
>  return EFI_ACCESS_DENIED;
>}
> 
> @@ -609,7 +611,7 @@ UfsBlockIoPeimGetMediaInfo (
>do {
>  Status = UfsPeimTestUnitReady (
> Private,
> -   DeviceIndex,
> +   Lun,
> ,
> 
> );
> @@ -621,7 +623,7 @@ UfsBlockIoPeimGetMediaInfo (
>continue;
>  }
> 
> -Status = UfsPeimParsingSenseKeys (&(Private->Media[DeviceIndex]),
> , );
> +Status = UfsPeimParsingSenseKeys (&(Private->Media[Lun]),
> + , );
>  if (EFI_ERROR (Status)) {
>return EFI_DEVICE_ERROR;
>  }
> @@ -630,7 +632,7 @@ UfsBlockIoPeimGetMediaInfo (
> 
>DataLength  = sizeof (EFI_SCSI_DISK_CAPACITY_DATA);
>SenseDataLength = 0;
> -  Status = UfsPeimReadCapacity (Private, DeviceIndex, , (UINT32
> *), NULL, );
> +  Status = UfsPeimReadCapacity (Private, Lun, , (UINT32
> + *), NULL, );
>if (EFI_ERROR (Status)) {
>  return EFI_DEVICE_ERROR;
>}
> @@ -639,22 +641,22 @@ UfsBlockIoPeimGetMediaInfo (
>(Capacity.LastLba1 == 0xff) && (Capacity.LastLba0 == 0xff)) {
>  DataLength  = sizeof (EFI_SCSI_DISK_CAPACITY_DATA16);
>  SenseDataLength = 0;
> -Status = UfsPeimReadCapacity16 (Private, DeviceIndex, ,
> (UINT32 *), NULL, );
> +Status = UfsPeimReadCapacity16 (Private, Lun, , (UINT32
> + *), NULL, );
>  if (EFI_ERROR (Status)) {
>return EFI_DEVICE_ERROR;
>  }
> -Private->Media[DeviceIndex].LastBlock  = ((UINT32)Capacity16.LastLba3
> << 24) | (Capacity16.LastLba2 << 16) | (Capacity16.LastLba1 << 8) |
> Capacity16.LastLba0;
> -Private->Media[DeviceIndex].LastBlock |= LShiftU64
> ((UINT64)Capacity16.LastLba7, 56) | LShiftU64((UINT64)Capacity16.LastLba6,
> 48) | LShiftU64 ((UINT64)Capacity16.LastLba5, 40) | LShiftU64
> ((UINT64)Capacity16.LastLba4, 32);
> -Private->Media[DeviceIndex].BlockSize  = (Capacity16.BlockSize3 << 24) |
> (Capacity16.BlockSize2 << 16) | (Capacity16.BlockSize1 << 8) |
> Capacity16.BlockSize0;
> +Private->Media[Lun].LastBlock  = ((UINT32)Capacity16.LastLba3 << 24) |
> (Capacity16.LastLba2 << 16) | (Capacity16.LastLba1 << 8) |
> Capacity16.LastLba0;
> +Private->Media[Lun].LastBlock |= LShiftU64 ((UINT64)Capacity16.LastLba7,
> 56) | LShiftU64((UINT64)Capacity16.LastLba6, 48) | LShiftU64
> ((UINT64)Capacity16.LastLba5, 40) | LShiftU64

49 matches

Mail list logo