date:20170410

Re: [edk2] [patch] BaseTools/ECC: Change check rule for Ifndef statement

2017-04-10 Thread Wu, Hao A

Reviewed-by: Hao Wu 

Also tested upon codes in MdePkg\Library\BaseLib, the reported issues for
'#ifndef DISABLE_NEW_DEPRECATED_INTERFACES' used in file
MdePkg\Library\BaseLib\String.c now go away.


Best Regards,
Hao Wu


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> hesschen
> Sent: Monday, April 10, 2017 10:57 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [patch] BaseTools/ECC: Change check rule for Ifndef statement
> 
> Remove the check of Ifndef statement on .c files, only check on .h
> files.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: hesschen 
> ---
>  BaseTools/Source/Python/Ecc/Check.py | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/Ecc/Check.py
> b/BaseTools/Source/Python/Ecc/Check.py
> index a22da3d..062120c 100644
> --- a/BaseTools/Source/Python/Ecc/Check.py
> +++ b/BaseTools/Source/Python/Ecc/Check.py
> @@ -1,7 +1,7 @@
>  ## @file
>  # This file is used to define checkpoints used by ECC tool
>  #
> -# Copyright (c) 2008 - 2016, Intel Corporation. All rights reserved.
> +# Copyright (c) 2008 - 2017, Intel Corporation. All rights reserved.
>  # This program and the accompanying materials
>  # are licensed and made available under the terms and conditions of the BSD
> License
>  # which accompanies this distribution.  The full text of the license may be
> found at
> @@ -941,7 +941,7 @@ class Check(object):
> 
>  # Check Guid Format in module INF
>  def MetaDataFileCheckModuleFileGuidFormat(self):
> -if EccGlobalData.gConfig.MetaDataFileCheckModuleFileGuidFormat or
> EccGlobalData.gConfig.MetaDataFileCheckAll == '1' or
> EccGlobalData.gConfig.CheckAll == '1':
> +if EccGlobalData.gConfig.MetaDataFileCheckModuleFileGuidFormat ==
> '1' or EccGlobalData.gConfig.MetaDataFileCheckAll == '1' or
> EccGlobalData.gConfig.CheckAll == '1':
>  EdkLogger.quiet("Check Guid Format in module INF ...")
>  Table = EccGlobalData.gDb.TblInf
>  SqlCommand = """
> @@ -984,7 +984,7 @@ class Check(object):
> 
>  # Check Protocol Format in module INF
>  def MetaDataFileCheckModuleFileProtocolFormat(self):
> -if EccGlobalData.gConfig.MetaDataFileCheckModuleFileProtocolFormat
> or EccGlobalData.gConfig.MetaDataFileCheckAll == '1' or
> EccGlobalData.gConfig.CheckAll == '1':
> +if EccGlobalData.gConfig.MetaDataFileCheckModuleFileProtocolFormat
> == '1' or EccGlobalData.gConfig.MetaDataFileCheckAll == '1' or
> EccGlobalData.gConfig.CheckAll == '1':
>  EdkLogger.quiet("Check Protocol Format in module INF ...")
>  Table = EccGlobalData.gDb.TblInf
>  SqlCommand = """
> @@ -1015,7 +1015,7 @@ class Check(object):
> 
>  # Check Ppi Format in module INF
>  def MetaDataFileCheckModuleFilePpiFormat(self):
> -if EccGlobalData.gConfig.MetaDataFileCheckModuleFilePpiFormat or
> EccGlobalData.gConfig.MetaDataFileCheckAll == '1' or
> EccGlobalData.gConfig.CheckAll == '1':
> +if EccGlobalData.gConfig.MetaDataFileCheckModuleFilePpiFormat == '1'
> or EccGlobalData.gConfig.MetaDataFileCheckAll == '1' or
> EccGlobalData.gConfig.CheckAll == '1':
>  EdkLogger.quiet("Check Ppi Format in module INF ...")
>  Table = EccGlobalData.gDb.TblInf
>  SqlCommand = """
> @@ -1043,7 +1043,7 @@ class Check(object):
> 
>  # Check Pcd Format in module INF
>  def MetaDataFileCheckModuleFilePcdFormat(self):
> -if EccGlobalData.gConfig.MetaDataFileCheckModuleFilePcdFormat or
> EccGlobalData.gConfig.MetaDataFileCheckAll == '1' or
> EccGlobalData.gConfig.CheckAll == '1':
> +if EccGlobalData.gConfig.MetaDataFileCheckModuleFilePcdFormat == '1'
> or EccGlobalData.gConfig.MetaDataFileCheckAll == '1' or
> EccGlobalData.gConfig.CheckAll == '1':
>  EdkLogger.quiet("Check Pcd Format in module INF ...")
>  Table = EccGlobalData.gDb.TblInf
>  SqlCommand = """
> @@ -1139,9 +1139,10 @@ class Check(object):
>  FileTable = 'Identifier' + str(Id)
>  self.NamingConventionCheckDefineStatement(FileTable)
>  self.NamingConventionCheckTypedefStatement(FileTable)
> -self.NamingConventionCheckIfndefStatement(FileTable)
>  self.NamingConventionCheckVariableName(FileTable)
>  
> self.NamingConventionCheckSingleCharacterVariable(FileTable)
> +if os.path.splitext(F)[1] in ('.h'):
> +
> self.NamingConventionCheckIfndefStatement(FileTable)
> 
>  self.NamingConventionCheckPathName()
>  self.NamingConventionCheckFunctionName()
> @@ -1183,7 +1184,7 @@ class Check(object):
> 
>  # Check whether the #ifndef at the start of an include file uses both

[edk2] 答复: [ScsiDiskDxe] Implict type conversion bug

2017-04-10 Thread Guoheyi

Thanks for your quick fix :)

-邮件原件-
发件人: Zeng, Star [mailto:star.z...@intel.com] 
发送时间: 2017年4月10日 17:48
收件人: Guoheyi; edk2-devel@lists.01.org
抄送: Tian, Feng; Zeng, Star
主题: RE: [edk2] [ScsiDiskDxe] Implict type conversion bug

Hao has sent patch for this issue.
You can search emails with title "[edk2] [PATCH] MdeModulePkg/ScsiDiskDxe: Fix 
potential implicit sign extension".

Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Guoheyi
Sent: Monday, April 10, 2017 5:40 PM
To: edk2-devel@lists.01.org
Cc: Tian, Feng 
Subject: [edk2] [ScsiDiskDxe] Implict type conversion bug

Hi folks,

In MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c, Line 2757, we have the code as 
below:

ScsiDiskDevice->BlkIo.Media->LastBlock =  (Capacity10->LastLba3 << 24) |
  (Capacity10->LastLba2 << 16) |
  (Capacity10->LastLba1 << 8)  |
   Capacity10->LastLba0;

However, we tested on VS2008 and found that the intermediate result would be 
convert to INT32 then INT64 implicitly, so the result will be sign extended and 
LastBlock may not be assigned with what is expected. We can simply test 
LastLba3 >= 0x80 to see what will happen.

Please let me know your comments.

Thanks and regards,

Gary (Heyi Guo)
___
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] SUT hangs after performing a warm boot.

2017-04-10 Thread Wu, Jiaxin

Ok, I didn't loop in another email discussion. I just reviewed the patch from 
Lubo, and I think it may be related to this issue since both of them are 
triggered  by Ip6NdFasterTimerTicking.

Thanks,
Jiaxin

> -Original Message-
> From: Santhapur Naveen [mailto:nave...@amiindia.co.in]
> Sent: Tuesday, April 11, 2017 10:20 AM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Subject: RE: SUT hangs after performing a warm boot.
> 
> Hi Jiaxin,
> 
>   I think this patch is for another fix which causes ASSERT. But anyways
> I'll give it a try and update you.
> 
> Thanks,
> Naveen
> 
> -Original Message-
> From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> Sent: Tuesday, April 11, 2017 7:05 AM
> To: Santhapur Naveen; edk2-devel@lists.01.org
> Subject: RE: SUT hangs after performing a warm boot.
> 
> Hi Naveen,
> 
> Can you help to verify whether the attached patch can resolve your issue?
> 
> Thanks,
> Jiaxin
> 
> > -Original Message-
> > From: Santhapur Naveen [mailto:nave...@amiindia.co.in]
> > Sent: Monday, April 10, 2017 7:31 PM
> > To: Wu, Jiaxin ; edk2-devel@lists.01.org
> > Subject: RE: SUT hangs after performing a warm boot.
> >
> > Hi Jiaxin,
> >
> > Below are the simple reproduction steps:
> >
> > BIOS UEFI Class3
> > (1)   Connect LAN cable (Realtek)
> > (2)   Do cold boot or warm boot stress (Windows 10)
> >
> > Please let me know for any additional information you may need.
> >
> > Thanks,
> > Naveen
> >
> > -Original Message-
> > From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> > Sent: Monday, April 10, 2017 6:00 AM
> > To: Santhapur Naveen; edk2-devel@lists.01.org
> > Subject: RE: SUT hangs after performing a warm boot.
> >
> > Hi Naveen,
> >
> > As the description of Ip6NdFasterTimerTicking(), it's the time routine
> > of ND module for IPv6.
> >
> > Can you provide the detailed reproduce steps?
> >
> > Thanks,
> > Jiaxin
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> > > Of Santhapur Naveen
> > > Sent: Friday, April 7, 2017 8:20 PM
> > > To: edk2-devel@lists.01.org
> > > Subject: [edk2] SUT hangs after performing a warm boot.
> > >
> > > Hi all,
> > >
> > >   Under NetworkPkg, in Ip6Dxe driver, what purpose does this
> > > function
> > > Ip6NdFasterTimerTicking() serve?
> > >   Sometimes, the SUT hangs in this function (at
> > > bootmgfw.Entry) when booting to Windows after performing a warm
> boot.
> > >
> > > Thanks,
> > > Naveen
> > > ___
> > > 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] MdeModulePkg/BootManagerMenu: Add assertion to indicate no DIV by 0

2017-04-10 Thread Wu, Hao A

Reviewed-by: Hao Wu 


Best Regards,
Hao Wu


> -Original Message-
> From: Ni, Ruiyu
> Sent: Tuesday, April 11, 2017 10:22 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A
> Subject: [PATCH] MdeModulePkg/BootManagerMenu: Add assertion to indicate
> no DIV by 0
> 
> BootMenuSelectItem() contains code to DIV BootMenuData->ItemCount.
> When BootMenuData->ItemCount can be 0, the DIV operation may
> trigger CPU exception.
> But in logic, this case won't happen. So add assertion to indicate
> it.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni 
> Cc: Hao A Wu 
> ---
>  MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenu.c | 3
> ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git
> a/MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenu.c
> b/MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenu.c
> index 6d493e1..a25f2ca 100644
> --- a/MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenu.c
> +++
> b/MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenu.c
> @@ -1,7 +1,7 @@
>  /** @file
>The application to show the Boot Manager Menu.
> 
> -Copyright (c) 2011 - 2016, Intel Corporation. All rights reserved.
> +Copyright (c) 2011 - 2017, Intel Corporation. All rights reserved.
>  This program and the accompanying materials
>  are licensed and made available under the terms and conditions of the BSD
> License
>  which accompanies this distribution.  The full text of the license may be 
> found
> at
> @@ -374,6 +374,7 @@ BootMenuSelectItem (
>if (BootMenuData == NULL || WantSelectItem >= BootMenuData->ItemCount)
> {
>  return EFI_INVALID_PARAMETER;
>}
> +  ASSERT (BootMenuData->ItemCount != 0);
>SavedAttribute = gST->ConOut->Mode->Attribute;
>RePaintItems = FALSE;
>StartCol = BootMenuData->MenuScreen.StartCol;
> --
> 2.9.0.windows.1

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

[edk2] [PATCH] MdeModulePkg/BootManagerMenu: Add assertion to indicate no DIV by 0

2017-04-10 Thread Ruiyu Ni

BootMenuSelectItem() contains code to DIV BootMenuData->ItemCount.
When BootMenuData->ItemCount can be 0, the DIV operation may
trigger CPU exception.
But in logic, this case won't happen. So add assertion to indicate
it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Hao A Wu 
---
 MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenu.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenu.c 
b/MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenu.c
index 6d493e1..a25f2ca 100644
--- a/MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenu.c
+++ b/MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenu.c
@@ -1,7 +1,7 @@
 /** @file
   The application to show the Boot Manager Menu.
 
-Copyright (c) 2011 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2011 - 2017, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -374,6 +374,7 @@ BootMenuSelectItem (
   if (BootMenuData == NULL || WantSelectItem >= BootMenuData->ItemCount) {
 return EFI_INVALID_PARAMETER;
   }
+  ASSERT (BootMenuData->ItemCount != 0);
   SavedAttribute = gST->ConOut->Mode->Attribute;
   RePaintItems = FALSE;
   StartCol = BootMenuData->MenuScreen.StartCol;
-- 
2.9.0.windows.1

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

Re: [edk2] SUT hangs after performing a warm boot.

2017-04-10 Thread Santhapur Naveen

Hi Jiaxin,

I think this patch is for another fix which causes ASSERT. But anyways 
I'll give it a try and update you.

Thanks,
Naveen

-Original Message-
From: Wu, Jiaxin [mailto:jiaxin...@intel.com] 
Sent: Tuesday, April 11, 2017 7:05 AM
To: Santhapur Naveen; edk2-devel@lists.01.org
Subject: RE: SUT hangs after performing a warm boot.

Hi Naveen,

Can you help to verify whether the attached patch can resolve your issue?

Thanks,
Jiaxin

> -Original Message-
> From: Santhapur Naveen [mailto:nave...@amiindia.co.in]
> Sent: Monday, April 10, 2017 7:31 PM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Subject: RE: SUT hangs after performing a warm boot.
> 
> Hi Jiaxin,
> 
>   Below are the simple reproduction steps:
> 
>   BIOS UEFI Class3
>   (1)   Connect LAN cable (Realtek)
>   (2)   Do cold boot or warm boot stress (Windows 10)
> 
>   Please let me know for any additional information you may need.
> 
> Thanks,
> Naveen
> 
> -Original Message-
> From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> Sent: Monday, April 10, 2017 6:00 AM
> To: Santhapur Naveen; edk2-devel@lists.01.org
> Subject: RE: SUT hangs after performing a warm boot.
> 
> Hi Naveen,
> 
> As the description of Ip6NdFasterTimerTicking(), it's the time routine 
> of ND module for IPv6.
> 
> Can you provide the detailed reproduce steps?
> 
> Thanks,
> Jiaxin
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
> > Of Santhapur Naveen
> > Sent: Friday, April 7, 2017 8:20 PM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] SUT hangs after performing a warm boot.
> >
> > Hi all,
> >
> >   Under NetworkPkg, in Ip6Dxe driver, what purpose does this 
> > function
> > Ip6NdFasterTimerTicking() serve?
> >   Sometimes, the SUT hangs in this function (at
> > bootmgfw.Entry) when booting to Windows after performing a warm boot.
> >
> > Thanks,
> > Naveen
> > ___
> > 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 2/2] IntelFrameworkPkg/UefiLib: Avoid mis-calculate of graphic console size

2017-04-10 Thread Hao Wu

The commit adds check in function InternalPrintGraphic() to ensure that
the expression:

Blt->Width * Blt->Height * sizeof (EFI_GRAPHICS_OUTPUT_BLT_PIXEL)

will not overflow in the UINTN range.

The commit also adds an explicit UINT32 type cast for 'Blt->Width' to
avoid possible overflow in the int range for:

Blt->Width * Blt->Height

Since both Blt->Width and Blt->Height are of type UINT16. They will be
promoted to int (signed) first, and then perform the multiplication
operation. If the result of multiplication between Blt->Width and
Blt->Height exceeds the range of type int, a potential incorrect size will
be passed into funciton AllocateZeroPool().

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLibPrint.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLibPrint.c 
b/IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLibPrint.c
index f0dcf9fb25..6f06efbe05 100644
--- a/IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLibPrint.c
+++ b/IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLibPrint.c
@@ -2,7 +2,7 @@
   Mde UEFI library API implementation.
   Print to StdErr or ConOut defined in EFI_SYSTEM_TABLE
 
-  Copyright (c) 2007 - 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2007 - 2017, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -474,7 +474,14 @@ InternalPrintGraphic (
   } else if (FeaturePcdGet (PcdUgaConsumeSupport)) {
 ASSERT (UgaDraw!= NULL);
 
-Blt->Image.Bitmap = AllocateZeroPool (Blt->Width * Blt->Height * sizeof 
(EFI_GRAPHICS_OUTPUT_BLT_PIXEL));
+//
+// Ensure Width * Height * sizeof (EFI_GRAPHICS_OUTPUT_BLT_PIXEL) doesn't 
overflow.
+//
+if (Blt->Width > DivU64x32 (MAX_UINTN, Blt->Height * sizeof 
(EFI_GRAPHICS_OUTPUT_BLT_PIXEL))) {
+  goto Error;
+}
+
+Blt->Image.Bitmap = AllocateZeroPool ((UINT32) Blt->Width * Blt->Height * 
sizeof (EFI_GRAPHICS_OUTPUT_BLT_PIXEL));
 ASSERT (Blt->Image.Bitmap != NULL);
 
 //
-- 
2.12.0.windows.1

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

[edk2] [PATCH 0/2] UefiLib: Avoid mis-calculate of graphic console size

2017-04-10 Thread Hao Wu

The series add checks to avoid potential mis-calculate of graphic console
size in MdePkg(IntelFrameworkPkg)/UefiLib.

Hao Wu (2):
  MdePkg/UefiLib: Avoid mis-calculate of graphic console size
  IntelFrameworkPkg/UefiLib: Avoid mis-calculate of graphic console size

 IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLibPrint.c | 11 +--
 MdePkg/Library/UefiLib/UefiLibPrint.c | 11 +--
 2 files changed, 18 insertions(+), 4 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 1/2] MdePkg/UefiLib: Avoid mis-calculate of graphic console size

2017-04-10 Thread Hao Wu

The commit adds check in function InternalPrintGraphic() to ensure that
the expression:

Blt->Width * Blt->Height * sizeof (EFI_GRAPHICS_OUTPUT_BLT_PIXEL)

will not overflow in the UINTN range.

The commit also adds an explicit UINT32 type cast for 'Blt->Width' to
avoid possible overflow in the int range for:

Blt->Width * Blt->Height

Since both Blt->Width and Blt->Height are of type UINT16. They will be
promoted to int (signed) first, and then perform the multiplication
operation. If the result of multiplication between Blt->Width and
Blt->Height exceeds the range of type int, a potential incorrect size will
be passed into funciton AllocateZeroPool().

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdePkg/Library/UefiLib/UefiLibPrint.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/MdePkg/Library/UefiLib/UefiLibPrint.c 
b/MdePkg/Library/UefiLib/UefiLibPrint.c
index 9f52e7d0ce..5527f8e7a8 100644
--- a/MdePkg/Library/UefiLib/UefiLibPrint.c
+++ b/MdePkg/Library/UefiLib/UefiLibPrint.c
@@ -2,7 +2,7 @@
   Mde UEFI library API implementation.
   Print to StdErr or ConOut defined in EFI_SYSTEM_TABLE
 
-  Copyright (c) 2007 - 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2007 - 2017, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -474,7 +474,14 @@ InternalPrintGraphic (
   } else if (FeaturePcdGet (PcdUgaConsumeSupport)) {
 ASSERT (UgaDraw!= NULL);
 
-Blt->Image.Bitmap = AllocateZeroPool (Blt->Width * Blt->Height * sizeof 
(EFI_GRAPHICS_OUTPUT_BLT_PIXEL));
+//
+// Ensure Width * Height * sizeof (EFI_GRAPHICS_OUTPUT_BLT_PIXEL) doesn't 
overflow.
+//
+if (Blt->Width > DivU64x32 (MAX_UINTN, Blt->Height * sizeof 
(EFI_GRAPHICS_OUTPUT_BLT_PIXEL))) {
+  goto Error;
+}
+
+Blt->Image.Bitmap = AllocateZeroPool ((UINT32) Blt->Width * Blt->Height * 
sizeof (EFI_GRAPHICS_OUTPUT_BLT_PIXEL));
 ASSERT (Blt->Image.Bitmap != NULL);
 
 //
-- 
2.12.0.windows.1

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

[edk2] [PATCH] MdeModulePkg/Dxe/Image: Restore mCurrentImage on all paths

2017-04-10 Thread Hao Wu

This commit makes sure that in function CoreStartImage(), module
variable 'mCurrentImage' is restored to the current start image context
on all code paths.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Core/Dxe/Image/Image.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/MdeModulePkg/Core/Dxe/Image/Image.c 
b/MdeModulePkg/Core/Dxe/Image/Image.c
index 93720c85cb..03e979a604 100644
--- a/MdeModulePkg/Core/Dxe/Image/Image.c
+++ b/MdeModulePkg/Core/Dxe/Image/Image.c
@@ -1647,6 +1647,12 @@ CoreStartImage (
 //
 PERF_START (NULL, "StartImage:", NULL, Tick);
 PERF_END (NULL, "StartImage:", NULL, 0);
+
+//
+// Pop the current start image context
+//
+mCurrentImage = LastImage;
+
 return EFI_OUT_OF_RESOURCES;
   }
   Image->JumpContext = ALIGN_POINTER (Image->JumpBuffer, 
BASE_LIBRARY_JUMP_BUFFER_ALIGNMENT);
-- 
2.12.0.windows.1

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

Re: [edk2] Using USB-Ethernet adapter in UEFI on an arm64 platform

2017-04-10 Thread Tian, Feng

Ax88772b driver's quality is better than Ax88772. But all of them aren't 
handled no-data case without latency. So if possible, I would suggest you to 
not use Ax88772x device. Realtek usb2lan is a good choice but the disadvantage 
of it is there looks like has no corresponding open-source UEFI driver for use.

Thanks
Feng

-Original Message-
From: Vladimir Olovyannikov [mailto:vladimir.olovyanni...@broadcom.com] 
Sent: Tuesday, April 11, 2017 12:14 AM
To: Tian, Feng ; edk2-devel@lists.01.org
Subject: RE: [edk2] Using USB-Ethernet adapter in UEFI on an arm64 platform

Hi Feng,

Thank you for your explanation.
I have Cisco 300M AX88772A-based adapter, so AX88772 (with no "b") driver was 
picked up.
I had to modify it with circular buffer to get ping and tftp going. Also I had 
to receive packets in GetStatus rather than in SN_Receive (otherwise I could 
never get into the Shell).
This way I have ping with response time of approx. 200ms, and tftp working, 
albeit it is slow.
So do you suggest me to use Ax88772b driver for AX88772A/AX88772 usb-ethernet 
adapter?
Also maybe you know if there are UEFI drivers for other USB-ethernet adapters 
(maybe 1G?) available somewhere?

Thank you,
Vladimir
-Original Message-
From: Tian, Feng [mailto:feng.t...@intel.com]
Sent: April-09-17 9:49 PM
To: Vladimir Olovyannikov; edk2-devel@lists.01.org
Cc: Tian, Feng
Subject: RE: [edk2] Using USB-Ethernet adapter in UEFI on an arm64 platform

Hi, Vladimir,

Which usb2lan driver you are using for AX88772 adpater? The one in 
OptionRomPkg\Bus\Usb\UsbNetworking has bug on the polling performance. The one 
in OptionRomPkg\Bus\Usb\UsbNetworking\Ax88772b is better but if there is no 
data received, the polling operation still wastes some time.

The root cause about the low performance of polling is because USB spec doesn't 
clearly define which value should be returned if user requests Bulk Read 
operation but there is no data. Some data-streaming usb devices, such as 
Realtek usb2lan, return success with data length setting to 0, but others, such 
as AX88772, just keep active and wait for data always. From BIOS view, we have 
to return EFI_TIMEOUT for latter case to avoid system hang. That's why you see 
the low performance for polling operation in no-data case.

Thanks
Feng

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Vladimir 
Olovyannikov
Sent: Saturday, April 8, 2017 3:06 AM
To: edk2-devel@lists.01.org
Subject: [edk2] Using USB-Ethernet adapter in UEFI on an arm64 platform

Hi,

I would like to enable Ethernet using USB-Ethernet AX88772 adapter in the UEFI 
on an armv8 arm64 platform.
Ethernet polling is done by MnpPoll() periodically. This creates a burden on 
the system so that UEFI boots in 1 minute to the Shell due to receive polling.
The USB operation is very resource expensive which causes UEFI to choke up.
There is DisableBackgroundPolling option in the EFI_MANAGED_NETWORK_CONFIG_DATA 
structure, but it is turned off by all other drivers (DNSDxe, Ip4Dxe, 
ArpDxe...).
Can anybody advise what I could do?
Mass storage/keyboard/etc. all work fine...

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

Re: [edk2] [edk2-FdfSpecification Patch] FILE RAW Multiple binaries and FmpPayload extensions

2017-04-10 Thread Zhu, Yonghong

Reviewed-by: Yonghong Zhu  

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael 
Kinney
Sent: Wednesday, April 5, 2017 3:54 PM
To: edk2-devel@lists.01.org
Cc: Gao, Liming 
Subject: [edk2] [edk2-FdfSpecification Patch] FILE RAW Multiple binaries and 
FmpPayload extensions

* Changed the FDF_SPECIFICATION value from 0x0001001A to
  0x0001001B or 1.27
* Extended the FV and Capsule, FILE RAW statement formats to
  support multiple binary files.
* Changed section 3.8 [FmpPayload] to add definitions for
  MONOTONIC_COUNT and CERTIFICATE_GUID, plus some notes about
  how these are used.

The document changes in this patch are in Gitbook format and are equivalent to 
the changes in the EDK II FDF File Spec v1.27 DRAFT for Review that was posted 
as a PDF with change bars on the tianocore site in September 2016.

https://github.com/tianocore-docs/Docs/raw/master/Specifications/FDF_Spec_1_27_Review_Draft.pdf

These same document changes are also availabe in the following GIT branch:

  https://github.com/mdkinney/edk2-FdfSpecification/tree/FileRawMultipleBinary

The content difference between the latest DRAFT and this change can be viewed 
at the following link.  The ?w=1 performs a word diff and ignores white space 
changes.

https://github.com/tianocore-docs/edk2-FdfSpecification/compare/master...mdkinney:FileRawMultipleBinary?w=1

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 

Michael Kinney (1):
  FILE RAW Multiple binaries and FmpPayload extensions

 2_fdf_design_discussion/README.md|  8 
 3_edk_ii_fdf_file_format/34_[defines]_section.md | 17 +
 3_edk_ii_fdf_file_format/36_[fv]_sections.md | 16 ++--
 3_edk_ii_fdf_file_format/37_[capsule]_sections.md|  5 +++--
 3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md | 10 ++
 README.md|  5 -
 6 files changed, 44 insertions(+), 17 deletions(-)

--
2.6.3.windows.1

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

Re: [edk2] [PATCH v2] MdeModulePkg/ScsiDiskDxe: Fix undefined behavior in signed left shift

2017-04-10 Thread Tian, Feng

Reviewed-by: Feng Tian 

Thanks
Feng

-Original Message-
From: Wu, Hao A 
Sent: Tuesday, April 11, 2017 9:30 AM
To: edk2-devel@lists.01.org; ler...@redhat.com; guoh...@huawei.com
Cc: Wu, Hao A ; Tian, Feng 
Subject: [PATCH v2] MdeModulePkg/ScsiDiskDxe: Fix undefined behavior in signed 
left shift

In function GetMediaInfo(), the following expression:
ScsiDiskDevice->BlkIo.Media->LastBlock =  (Capacity10->LastLba3 << 24) |
  (Capacity10->LastLba2 << 16) |
  (Capacity10->LastLba1 << 8)  |
   Capacity10->LastLba0; will involve 
undefined behavior in signed left shift operations.

Since Capacity10->LastLbaX is of type UINT8, and
ScsiDiskDevice->BlkIo.Media->LastBlock is of type UINT64. Therefore,
Capacity10->LastLbaX will be promoted to int (32 bits, signed) first,
and then perform the left shift operation.

According to the C11 spec, Section 6.5.7:
4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated
  bits are filled with zeros. If E1 has an unsigned type, the value
  of the result is E1 * 2^E2 , reduced modulo one more than the
  maximum value representable in the result type. If E1 has a signed
  type and nonnegative value, and E1 * 2^E2 is representable in the
  result type, then that is the resulting value; otherwise, the
  behavior is undefined.

So if bit 7 of Capacity10->LastLba3 is 1, (Capacity10->LastLba3 << 24) will be 
out of the range within int type. The undefined behavior of the signed left 
shift will lead to a potential of setting the high 32 bits of 
ScsiDiskDevice->BlkIo.Media->LastBlock to 1 during the cast from type int to 
type UINT64.

This commit will add an explicit UINT32 type cast for
Capacity10->LastLba3 to resolve this issue.

Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c 
b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
index b5eff25b9b..2289f20152 100644
--- a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
+++ b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
@@ -1,7 +1,7 @@
 /** @file
   SCSI disk driver that layers on every SCSI IO protocol in the system.

-Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at @@ -2754,7 +2754,7 
@@ GetMediaInfo (
   UINT8   *Ptr;

   if (!ScsiDiskDevice->Cdb16Byte) {
-ScsiDiskDevice->BlkIo.Media->LastBlock =  (Capacity10->LastLba3 << 24) |
+ScsiDiskDevice->BlkIo.Media->LastBlock =  ((UINT32) 
+ Capacity10->LastLba3 << 24) |
   (Capacity10->LastLba2 << 16) |
   (Capacity10->LastLba1 << 8)  |
Capacity10->LastLba0;
--
2.12.0.windows.1

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

Re: [edk2] SUT hangs after performing a warm boot.

2017-04-10 Thread Wu, Jiaxin

Hi Naveen,

Can you help to verify whether the attached patch can resolve your issue?

Thanks,
Jiaxin

> -Original Message-
> From: Santhapur Naveen [mailto:nave...@amiindia.co.in]
> Sent: Monday, April 10, 2017 7:31 PM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Subject: RE: SUT hangs after performing a warm boot.
> 
> Hi Jiaxin,
> 
>   Below are the simple reproduction steps:
> 
>   BIOS UEFI Class3
>   (1)   Connect LAN cable (Realtek)
>   (2)   Do cold boot or warm boot stress (Windows 10)
> 
>   Please let me know for any additional information you may need.
> 
> Thanks,
> Naveen
> 
> -Original Message-
> From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> Sent: Monday, April 10, 2017 6:00 AM
> To: Santhapur Naveen; edk2-devel@lists.01.org
> Subject: RE: SUT hangs after performing a warm boot.
> 
> Hi Naveen,
> 
> As the description of Ip6NdFasterTimerTicking(), it's the time routine of ND
> module for IPv6.
> 
> Can you provide the detailed reproduce steps?
> 
> Thanks,
> Jiaxin
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Santhapur Naveen
> > Sent: Friday, April 7, 2017 8:20 PM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] SUT hangs after performing a warm boot.
> >
> > Hi all,
> >
> >   Under NetworkPkg, in Ip6Dxe driver, what purpose does this
> > function
> > Ip6NdFasterTimerTicking() serve?
> >   Sometimes, the SUT hangs in this function (at
> > bootmgfw.Entry) when booting to Windows after performing a warm boot.
> >
> > Thanks,
> > Naveen
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
--- Begin Message ---
If we set PXEv6 as the first boot option and reboot immediately
after the first successful boot, it will assert. the root cause is
when we set the policy from manual to automatic in PXE driver,
the ip6 Configure item size is already set to zero and other
structures are also released, So it is not needed to perform DAD call
back function which is invoked by Ip6ConfigSetMaunualAddress.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
Cc: Wu Jiaxin 
Cc: Ye Ting 
Cc: Fu Siyuan 
---
 NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c 
b/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c
index bde5982..7575b79 100644
--- a/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c
+++ b/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c
@@ -782,10 +782,14 @@ Ip6ManualAddrDadCallback (
   Instance   = (IP6_CONFIG_INSTANCE *) Context;
   NET_CHECK_SIGNATURE (Instance, IP6_CONFIG_INSTANCE_SIGNATURE);
   Item   = >DataItem[Ip6ConfigDataTypeManualAddress];
   ManualAddr = NULL;

+  if (Item->DataSize == 0) {
+return;
+  }
+
   for (Index = 0; Index < Item->DataSize / sizeof 
(EFI_IP6_CONFIG_MANUAL_ADDRESS); Index++) {
 //
 // Find the original tag used to place into the NET_MAP.
 //
 ManualAddr = Item->Data.ManualAddress + Index;
--
1.9.5.msysgit.1

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

Re: [edk2] [edk2-FdfSpecification PATCH 0/2] Allow macros in !include file paths

2017-04-10 Thread Zhu, Yonghong

The patches are good to me.

Reviewed-by: Yonghong Zhu  

Best Regards,
Zhu Yonghong


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael 
Kinney
Sent: Saturday, April 08, 2017 10:45 AM
To: edk2-devel@lists.01.org
Subject: [edk2] [edk2-FdfSpecification PATCH 0/2] Allow macros in !include file 
paths

* Use macros in !include file paths
  https://bugzilla.tianocore.org/show_bug.cgi?id=350
* Remove illegal white space in FDF file examples

GitHub branch for review:

  
https://github.com/mdkinney/edk2-FdfSpecification/tree/Bugzilla_350_MacrosInIncludes
  
GitHub branch compare against latest DRAFT for review:

  
https://github.com/tianocore-docs/edk2-FdfSpecification/compare/master...mdkinney:Bugzilla_350_MacrosInIncludes


Michael Kinney (2):
  Use macros in !include file paths
  Remove illegal white space in FDF file examples

 .../22_flash_description_file_format.md| 21 +
 2_fdf_design_discussion/25_[fv]_sections.md| 12 +-
 3_edk_ii_fdf_file_format/32_fdf_definition.md  | 26 +-
 appendix_a_nt32pkg_flash_description_file.md   | 14 ++--
 4 files changed, 39 insertions(+), 34 deletions(-)

-- 
2.6.3.windows.1

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

[edk2] [PATCH v2] MdeModulePkg/ScsiDiskDxe: Fix undefined behavior in signed left shift

2017-04-10 Thread Hao Wu

In function GetMediaInfo(), the following expression:
ScsiDiskDevice->BlkIo.Media->LastBlock =  (Capacity10->LastLba3 << 24) |
  (Capacity10->LastLba2 << 16) |
  (Capacity10->LastLba1 << 8)  |
   Capacity10->LastLba0;
will involve undefined behavior in signed left shift operations.

Since Capacity10->LastLbaX is of type UINT8, and
ScsiDiskDevice->BlkIo.Media->LastBlock is of type UINT64. Therefore,
Capacity10->LastLbaX will be promoted to int (32 bits, signed) first,
and then perform the left shift operation.

According to the C11 spec, Section 6.5.7:
4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated
  bits are filled with zeros. If E1 has an unsigned type, the value
  of the result is E1 * 2^E2 , reduced modulo one more than the
  maximum value representable in the result type. If E1 has a signed
  type and nonnegative value, and E1 * 2^E2 is representable in the
  result type, then that is the resulting value; otherwise, the
  behavior is undefined.

So if bit 7 of Capacity10->LastLba3 is 1, (Capacity10->LastLba3 << 24)
will be out of the range within int type. The undefined behavior of the
signed left shift will lead to a potential of setting the high 32 bits
of ScsiDiskDevice->BlkIo.Media->LastBlock to 1 during the cast from type
int to type UINT64.

This commit will add an explicit UINT32 type cast for
Capacity10->LastLba3 to resolve this issue.

Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c 
b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
index b5eff25b9b..2289f20152 100644
--- a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
+++ b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
@@ -1,7 +1,7 @@
 /** @file
   SCSI disk driver that layers on every SCSI IO protocol in the system.
 
-Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -2754,7 +2754,7 @@ GetMediaInfo (
   UINT8   *Ptr;
 
   if (!ScsiDiskDevice->Cdb16Byte) {
-ScsiDiskDevice->BlkIo.Media->LastBlock =  (Capacity10->LastLba3 << 24) |
+ScsiDiskDevice->BlkIo.Media->LastBlock =  ((UINT32) Capacity10->LastLba3 
<< 24) |
   (Capacity10->LastLba2 << 16) |
   (Capacity10->LastLba1 << 8)  |
Capacity10->LastLba0;
-- 
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] MdeModulePkg/ScsiDiskDxe: Fix potential implicit sign extension

2017-04-10 Thread Wu, Hao A

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, April 10, 2017 11:47 PM
> To: Wu, Hao A; edk2-devel@lists.01.org
> Cc: Tian, Feng; guoh...@huawei.com
> Subject: Re: [edk2] [PATCH] MdeModulePkg/ScsiDiskDxe: Fix potential implicit
> sign extension
> 
> (Gary, is your Linaro email still alive?)
> 
> On 04/10/17 09:43, Hao Wu wrote:
> > In function GetMediaInfo(), the following expression:
> > ScsiDiskDevice->BlkIo.Media->LastBlock =  (Capacity10->LastLba3 << 24) |
> >   (Capacity10->LastLba2 << 16) |
> >   (Capacity10->LastLba1 << 8)  |
> >Capacity10->LastLba0;
> > will involve implicit sign extension.
> >
> > Since Capacity10->LastLbaX is of type UINT8, and
> > ScsiDiskDevice->BlkIo.Media->LastBlock is of type UINT64. Therefore,
> > Capacity10->LastLbaX will be promoted to int (32 bits, signed) first,
> > perform the bit shift and or. Then the result will be sign-extended to
> > type UINT64.
> >
> > If bit 7 of Capacity10->LastLba3 is 1, then the high 32 bits of
> > ScsiDiskDevice->BlkIo.Media->LastBlock will all be set to 1.
> >
> > This commit will add an explicit UINT32 type cast for
> > Capacity10->LastLba3 to resolve this issue.
> >
> > Cc: Feng Tian 
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Hao Wu 
> > ---
> >  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
> b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
> > index b5eff25b9b..2289f20152 100644
> > --- a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
> > +++ b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
> > @@ -1,7 +1,7 @@
> >  /** @file
> >SCSI disk driver that layers on every SCSI IO protocol in the system.
> >
> > -Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
> > +Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
> >  This program and the accompanying materials
> >  are licensed and made available under the terms and conditions of the BSD
> License
> >  which accompanies this distribution.  The full text of the license may be
> found at
> > @@ -2754,7 +2754,7 @@ GetMediaInfo (
> >UINT8   *Ptr;
> >
> >if (!ScsiDiskDevice->Cdb16Byte) {
> > -ScsiDiskDevice->BlkIo.Media->LastBlock =  (Capacity10->LastLba3 << 24) 
> > |
> > +ScsiDiskDevice->BlkIo.Media->LastBlock =  ((UINT32) Capacity10-
> >LastLba3 << 24) |
> >(Capacity10->LastLba2 << 16) 
> > |
> >(Capacity10->LastLba1 << 8)  
> > |
> > Capacity10->LastLba0;
> >
> 
> The patch looks okay to me, but I would like to comment on the commit
> message. The commit message says "sign extension", which is an assembly
> language / processor level concept; the C language doesn't know about
> "sign extension".
> 
> Instead, what we have here is undefined behavior.
> 
> 6.5.7 Bitwise shift operators
> 
>   3 The integer promotions are performed on each of the operands. The
> type of the result is that of the promoted left operand. If the
> value of the right operand is negative or is greater than or equal
> to the width of the promoted left operand, the behavior is
> undefined.
> 
>   4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated
> bits are filled with zeros. If E1 has an unsigned type, the value
> of the result is E1 × 2^E2 , reduced modulo one more than the
> maximum value representable in the result type. If E1 has a signed
> type and nonnegative value, and E1 × 2^E2 is representable in the
> result type, then that is the resulting value; otherwise, the
> behavior is undefined.
> 
> So, we have a left operand here that is promoted to "int". It means that
> "E1" has signed type. Its value is nonnegative. However, E1 × 2^E2 is
> not representable in the result type, hence the behavior is undefined.
> 
> The fact that this undefined shift *happens* to result in the sign bit
> being set (resulting in a negative "int" value), which in turn is
> converted to a 64-bit unsigned value as proscribed by the usual
> arithmetic conversions (*), is just an implementation detail. The root
> cause is that the signed left shift invokes undefined behavior.
> 
> (
> 
> (*)
> 
> 6.3.1.8 Usual arithmetic conversions
> 
>   1 [...] Otherwise, if the operand that has unsigned integer type has
> rank greater or equal to the rank of the type of the other operand,
> then the operand with signed integer type is converted to the type
> of the operand with unsigned integer type.
> 
> 6.3.1.3 Signed and unsigned integers
> 
>   2 Otherwise, if the new type is unsigned, the value is converted by
>

Re: [edk2] MemoryProfile at UDK2015

2017-04-10 Thread Rafael Machado

Perfect.

Thanks for the answer Brian!

Em seg, 10 de abr de 2017 às 16:26, Richardson, Brian <
brian.richard...@intel.com> escreveu:

> UDL2015 is a stable snapshot of EDK II modules validated on Intel
> architecture platforms. This module isn't validated as part of that
> snapshot, hence the omission. You can still use this module with UDK2015,
> as long as you pull from the git hash or SVN revision from the UDK2015
> release notes.
>
> Thanks ... br
> ---
> Brian Richardson, Senior Technical Marketing Engineer, Intel Software
> brian.richard...@intel.com -- @intel_Brian (Twitter & WeChat)
>
> https://software.intel.com/en-us/meet-the-developers/evangelists/team/brian-richardson
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Rafael Machado
> Sent: Monday, April 10, 2017 3:15 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] MemoryProfile at UDK2015
>
> Hi everyone.
>
> I was taking a look on how to detect a memory leak, and found this page:
>
> https://github.com/tianocore/tianocore.github.io/wiki/Memory-leak-detection-with-memory-profile-feature
>
> When trying to follow these steps, I noticed that we don't have the
> MemoryProfileLib available at the UDK2015 branch, but it's available at the
> master branch, at edk2 /MdeModulePkg
> /Include
>  >/Library
> <
> https://github.com/tianocore/edk2/tree/master/MdeModulePkg/Include/Library
> >
> /MemoryProfileLib.h
>
> Is there any incompatibility or something like this that limits the use of
> this lib at the UDK2015?
>
> Thanks
> Rafael Machado
> ___
> 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] MemoryProfile at UDK2015

2017-04-10 Thread Richardson, Brian

UDL2015 is a stable snapshot of EDK II modules validated on Intel architecture 
platforms. This module isn't validated as part of that snapshot, hence the 
omission. You can still use this module with UDK2015, as long as you pull from 
the git hash or SVN revision from the UDK2015 release notes.

Thanks ... br
---
Brian Richardson, Senior Technical Marketing Engineer, Intel Software
brian.richard...@intel.com -- @intel_Brian (Twitter & WeChat)
https://software.intel.com/en-us/meet-the-developers/evangelists/team/brian-richardson
 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Rafael 
Machado
Sent: Monday, April 10, 2017 3:15 PM
To: edk2-devel@lists.01.org
Subject: [edk2] MemoryProfile at UDK2015

Hi everyone.

I was taking a look on how to detect a memory leak, and found this page:
https://github.com/tianocore/tianocore.github.io/wiki/Memory-leak-detection-with-memory-profile-feature

When trying to follow these steps, I noticed that we don't have the 
MemoryProfileLib available at the UDK2015 branch, but it's available at the 
master branch, at edk2 /MdeModulePkg
/Include
/Library

/MemoryProfileLib.h

Is there any incompatibility or something like this that limits the use of this 
lib at the UDK2015?

Thanks
Rafael Machado
___
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] MemoryProfile at UDK2015

2017-04-10 Thread Rafael Machado

Hi everyone.

I was taking a look on how to detect a memory leak, and found this page:
https://github.com/tianocore/tianocore.github.io/wiki/Memory-leak-detection-with-memory-profile-feature

When trying to follow these steps, I noticed that we don't have the
MemoryProfileLib available at the UDK2015 branch, but it's available at the
master branch, at edk2 /MdeModulePkg
/Include
/Library

/MemoryProfileLib.h

Is there any incompatibility or something like this that limits the use of
this lib at the UDK2015?

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

[edk2] [RFT PATCH] EmbeddedPkg/AndroidFastbootApp: remove dependency on deprecated BdsLib

2017-04-10 Thread Ard Biesheuvel

One of the last remaining modules with a dependency on the deprecated
BdsLib implementation from ArmPkg is the Android fastboot application.

Its only dependency on BdsLib is BdsStartEfiApplication(), which is
used in the most peculiar way: the fastboot app loads the kernel image
into memory, and creates a MemoryMapped() device path for it. It then
proceeds and calls BdsStartEfiApplication(), which explicitly loads the
contents of the devicepath into memory, creating a second in-memory copy
of the kernel image, after which it invokes gBS->LoadImage() with a
buffer address and size (while it is perfectly capable of loading from
a devicepath directly)

Since we know the device path is fully qualified and connected, and does
not require any of the additional processing that BdsStartEfiApplication()
does when dereferencing a device path, we should be able to pass this
devicepath into LoadImage() directly.

So create a simplified local clone of BdsStartEfiApplication(), and drop
the dependency on BdsLib.

Signed-off-by: Ard Biesheuvel 
---
 EmbeddedPkg/Application/AndroidFastboot/AndroidFastbootApp.inf   |  2 +-
 EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c | 57 
+++-
 2 files changed, 57 insertions(+), 2 deletions(-)

diff --git a/EmbeddedPkg/Application/AndroidFastboot/AndroidFastbootApp.inf 
b/EmbeddedPkg/Application/AndroidFastboot/AndroidFastbootApp.inf
index 3e115171ce01..8d2b23c6f8b8 100644
--- a/EmbeddedPkg/Application/AndroidFastboot/AndroidFastbootApp.inf
+++ b/EmbeddedPkg/Application/AndroidFastboot/AndroidFastbootApp.inf
@@ -30,7 +30,6 @@ [Sources.ARM, Sources.AARCH64]
 [LibraryClasses]
   BaseLib
   BaseMemoryLib
-  BdsLib
   DebugLib
   DevicePathLib
   DxeServicesTableLib
@@ -45,6 +44,7 @@ [LibraryClasses]
 [Protocols]
   gAndroidFastbootTransportProtocolGuid
   gAndroidFastbootPlatformProtocolGuid
+  gEfiLoadedImageProtocolGuid
   gEfiSimpleTextOutProtocolGuid
   gEfiSimpleTextInProtocolGuid
 
diff --git a/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c 
b/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
index 46a7ceb3a41c..f446cce2855a 100644
--- a/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
+++ b/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
@@ -15,6 +15,7 @@
 #include "AndroidFastbootApp.h"
 
 #include 
+#include 
 
 #include 
 #include 
@@ -50,6 +51,60 @@ STATIC CONST MEMORY_DEVICE_PATH MemoryDevicePathTemplate =
   } // End
 };
 
+
+/**
+  Start an EFI Application from a Device Path
+
+  @param  ParentImageHandle Handle of the calling image
+  @param  DevicePathLocation of the EFI Application
+
+  @retval EFI_SUCCESS   All drivers have been connected
+  @retval EFI_NOT_FOUND The Linux kernel Device Path has not been found
+  @retval EFI_OUT_OF_RESOURCES  There is not enough resource memory to store 
the matching results.
+
+**/
+STATIC
+EFI_STATUS
+StartEfiApplication (
+  IN EFI_HANDLE  ParentImageHandle,
+  IN EFI_DEVICE_PATH_PROTOCOL*DevicePath,
+  IN UINTN   LoadOptionsSize,
+  IN VOID*   LoadOptions
+  )
+{
+  EFI_STATUS   Status;
+  EFI_HANDLE   ImageHandle;
+  EFI_LOADED_IMAGE_PROTOCOL*   LoadedImage;
+
+  // Load the image from the device path with Boot Services function
+  Status = gBS->LoadImage (TRUE, ParentImageHandle, DevicePath, NULL, 0,
+  );
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+
+  // Passed LoadOptions to the EFI Application
+  if (LoadOptionsSize != 0) {
+Status = gBS->HandleProtocol (ImageHandle, ,
+(VOID **) );
+if (EFI_ERROR (Status)) {
+  return Status;
+}
+
+LoadedImage->LoadOptionsSize  = LoadOptionsSize;
+LoadedImage->LoadOptions  = LoadOptions;
+  }
+
+  // Before calling the image, enable the Watchdog Timer for  the 5 Minute 
period
+  gBS->SetWatchdogTimer (5 * 60, 0x, 0x00, NULL);
+  // Start the image
+  Status = gBS->StartImage (ImageHandle, NULL, NULL);
+  // Clear the Watchdog Timer after the image returns
+  gBS->SetWatchdogTimer (0x, 0x, 0x, NULL);
+
+  return Status;
+}
+
 EFI_STATUS
 BootAndroidBootImg (
   IN UINTNBufferSize,
@@ -100,7 +155,7 @@ BootAndroidBootImg (
 LoadOptions = NewLoadOptions;
   }
 
-  Status = BdsStartEfiApplication (gImageHandle,
+  Status = StartEfiApplication (gImageHandle,
  (EFI_DEVICE_PATH_PROTOCOL *) ,
  StrSize (LoadOptions),
  LoadOptions);
-- 
2.9.3

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

Re: [edk2] [PATCH v3 0/3] ArmPlatformPkg: FVP spring cleaning -- EDK2 edition

2017-04-10 Thread Leif Lindholm

On Mon, Apr 10, 2017 at 05:21:49PM +0100, Ard Biesheuvel wrote:
> This v3 of the ArmPlatformPkg now only contains FVP changes. TC2 and Juno
> will receive a similar treatment once we have sorted out how the loading of
> the DTB image from the NOR flash will be implemented.
> 
> So what remains here is two somewhat unrelated cleanup patches, and the
> meat in #3 which removes the functionality that interoperates with the
> FdtPlatformDxe that we are trying to get rid of.
> 

For the series:
Reviewed-by: Leif Lindholm 

> Ard Biesheuvel (3):
>   ArmPlatformPkg/ArmVExpressDxe: remove ARM support
>   ArmPlatformPkg/ArmVExpressDxe: remove unused cruft from ArmHwDxe
>   ArmPlatformPkg/ArmVExpressDxe: remove FDT handling from ArmFvpDxe
> 
>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/AArch64/ArmFvpDxeAArch64.c | 
> 113 
>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/Arm/ArmFvpDxeArm.c |  
> 84 
>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmFvpDxe.c| 
> 137 +---
>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmFvpDxe.inf  |  
> 42 --
>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmHwDxe.c |  
> 43 +-
>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmHwDxe.inf   |   
> 3 -
>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmVExpressCommon.c|  
> 48 ---
>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmVExpressInternal.h  |  
> 99 --
>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpressPkg.dec|  
> 28 
>  9 files changed, 6 insertions(+), 591 deletions(-)
>  delete mode 100644 
> ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/AArch64/ArmFvpDxeAArch64.c
>  delete mode 100644 
> ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/Arm/ArmFvpDxeArm.c
>  delete mode 100644 
> ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmVExpressCommon.c
>  delete mode 100644 
> ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmVExpressInternal.h
> 
> -- 
> 2.9.3
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v3 2/3] ArmPlatformPkg/ArmVExpressDxe: remove unused cruft from ArmHwDxe

2017-04-10 Thread Ard Biesheuvel

Remove unused cruft from ArmHwDxe -- the only thing that remains is
installation of the 'runaxf' shell command.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmHwDxe.c   | 43 
+---
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmHwDxe.inf |  3 --
 2 files changed, 1 insertion(+), 45 deletions(-)

diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmHwDxe.c 
b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmHwDxe.c
index 351c73312dc4..19efa3c23dea 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmHwDxe.c
+++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmHwDxe.c
@@ -12,49 +12,8 @@
 
 **/
 
-#include "ArmVExpressInternal.h"
 #include 
-
-CONST EFI_GUID ArmHwA9x4Guid = { 0x2fd21cf6, 0xe6e8, 0x4ff2, { 0xa9, 0xca, 
0x3b, 0x9f, 0x00, 0xe9, 0x28, 0x89 } };
-CONST EFI_GUID ArmHwA15x2A7x3Guid = { 0xd5e606eb, 0x83df, 0x4e90, { 0x81, 
0xe8, 0xc3, 0xdb, 0x2f, 0x77, 0x17, 0x9a } };
-CONST EFI_GUID ArmHwA15Guid = { 0x6b8947c2, 0x4287, 0x4d91, { 0x8f, 0xe0, 
0xa3, 0x81, 0xea, 0x5b, 0x56, 0x8f } };
-CONST EFI_GUID ArmHwA5Guid = { 0xa2cc7663, 0x4d7c, 0x448a, { 0xaa, 0xb5, 0x4c, 
0x03, 0x4b, 0x6f, 0xda, 0xb7 } };
-CONST EFI_GUID NullGuid = { 0x0, 0x0, 0x0, { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0 } };
-
-//
-// Description of the four hardware platforms :
-// just the platform id for the time being.
-// Platform ids are defined in ArmVExpressInternal.h for
-// all "ArmVExpress-like" platforms (AARCH64 or ARM architecture,
-// model or hardware platforms).
-//
-//Note: File extensions are stripped with the VExpress NOR Flash FileSystem
-CONST ARM_VEXPRESS_PLATFORM ArmVExpressPlatforms[] = {
-  { ARM_HW_A9x4, , L"ca9" },
-  { ARM_HW_A15x2_A7x3, , L"ca15a7" },
-  { ARM_HW_A15, , L"ca15a7" },
-  { ARM_HW_A5, , L"ca5s" },
-  { ARM_FVP_VEXPRESS_UNKNOWN, , NULL }
-};
-
-/**
-  Get information about the VExpress platform the firmware is running on.
-
-  @param[out]  Platform   Address where the pointer to the platform information
-  (type ARM_VEXPRESS_PLATFORM*) should be stored.
-  The returned pointer does not point to an allocated
-  memory area. Not used here.
-
-  @retval  EFI_NOT_FOUND  The platform was not recognised.
-
-**/
-EFI_STATUS
-ArmVExpressGetPlatform (
-  OUT CONST ARM_VEXPRESS_PLATFORM** Platform
-  )
-{
-  return EFI_NOT_FOUND;
-}
+#include 
 
 /**
  * Generic UEFI Entrypoint for 'ArmHwDxe' driver
diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmHwDxe.inf 
b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmHwDxe.inf
index 1a007627ad3f..1ecdbb0b231e 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmHwDxe.inf
+++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmHwDxe.inf
@@ -22,12 +22,9 @@ [Defines]
 
 [Sources.common]
   ArmHwDxe.c
-  ArmVExpressCommon.c
 
 [Packages]
-  ArmPkg/ArmPkg.dec
   ArmPlatformPkg/ArmPlatformPkg.dec
-  EmbeddedPkg/EmbeddedPkg.dec
   MdePkg/MdePkg.dec
 
 [LibraryClasses]
-- 
2.9.3

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

[edk2] [PATCH v3 3/3] ArmPlatformPkg/ArmVExpressDxe: remove FDT handling from ArmFvpDxe

2017-04-10 Thread Ard Biesheuvel

Replace the elaborate but awkward handling of FDT images using device
paths and string PCDs initialized to 128 spaces with a simple scheme
involving a set of builtin DTBs and a bit of runtime logic to select
between them.

This is sufficient for ordinary use, which makes it more suitable as
reference code. Note that overriding the DTB presented to the OS can
easily be done with a UEFI application that simply installs a new DTB
image under the existing FDT configuration table GUID.

For this module, this simply involves removing all code that is involved
in deciding which platform we are running on, and for reasoning about
FDT device paths.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/AArch64/ArmFvpDxeAArch64.c | 113 

 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmFvpDxe.c| 137 
+---
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmFvpDxe.inf  |  33 
-
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmVExpressCommon.c|  48 
---
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmVExpressInternal.h  |  99 
--
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressPkg.dec|  18 
---
 6 files changed, 5 insertions(+), 443 deletions(-)

diff --git 
a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/AArch64/ArmFvpDxeAArch64.c 
b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/AArch64/ArmFvpDxeAArch64.c
deleted file mode 100644
index c368957dcd3d..
--- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/AArch64/ArmFvpDxeAArch64.c
+++ /dev/null
@@ -1,113 +0,0 @@
-/** @file
-
-  Copyright (c) 2014-2015, ARM Ltd. All rights reserved.
-
-  This program and the accompanying materials are licensed and made available
-  under the terms and conditions of the BSD License which accompanies this
-  distribution.  The full text of the license may be found at
-  http://opensource.org/licenses/bsd-license.php
-
-  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
-  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-
-**/
-
-#include "ArmVExpressInternal.h"
-#include 
-
-//
-// Description of the AARCH64 model platforms :
-// Platform ids are defined in ArmVExpressInternal.h for
-// all "ArmVExpress-like" platforms (AARCH64 or ARM architecture,
-// model or hardware platforms).
-//
-CONST ARM_VEXPRESS_PLATFORM ArmVExpressPlatforms[] = {
-  { ARM_FVP_VEXPRESS_AEMv8x4,  FixedPcdGetPtr 
(PcdFdtFvpVExpressAEMv8x4),L"rtsm_ve-aemv8a.dtb"  },
-  { ARM_FVP_BASE_AEMv8x4_AEMv8x4_GICV2,FixedPcdGetPtr 
(PcdFdtFvpBaseAEMv8x4GicV2),   L"fvp-base-gicv2-psci.dtb" },
-  { ARM_FVP_BASE_AEMv8x4_AEMv8x4_GICV2_LEGACY, FixedPcdGetPtr 
(PcdFdtFvpBaseAEMv8x4GicV2Legacy), L"fvp-base-gicv2legacy-psci.dtb"   },
-  { ARM_FVP_BASE_AEMv8x4_AEMv8x4_GICV3,FixedPcdGetPtr 
(PcdFdtFvpBaseAEMv8x4GicV3),   L"fvp-base-gicv3-psci.dtb" },
-  { ARM_FVP_FOUNDATION_GICV2,  FixedPcdGetPtr 
(PcdFdtFvpFoundationGicV2),L"fvp-foundation-gicv2-psci.dtb"   },
-  { ARM_FVP_FOUNDATION_GICV2_LEGACY,   FixedPcdGetPtr 
(PcdFdtFvpFoundationGicV2Legacy),  L"fvp-foundation-gicv2legacy-psci.dtb" },
-  { ARM_FVP_FOUNDATION_GICV3,  FixedPcdGetPtr 
(PcdFdtFvpFoundationGicV3),L"fvp-foundation-gicv3-psci.dtb"   },
-  { ARM_FVP_VEXPRESS_UNKNOWN }
-};
-
-/**
-  Get information about the VExpress platform the firmware is running on.
-
-  @param[out]  Platform   Address where the pointer to the platform information
-  (type ARM_VEXPRESS_PLATFORM*) should be stored.
-  The returned pointer does not point to an allocated
-  memory area.
-
-  @retval  EFI_SUCCESSThe platform information was returned.
-  @retval  EFI_NOT_FOUND  The platform was not recognised.
-
-**/
-EFI_STATUS
-ArmVExpressGetPlatform (
-  OUT CONST ARM_VEXPRESS_PLATFORM** Platform
-  )
-{
-  EFI_STATUSStatus;
-  UINT32SysId;
-  UINT32FvpSysId;
-  UINT32VariantSysId;
-  ARM_GIC_ARCH_REVISION GicRevision;
-
-  ASSERT (Platform != NULL);
-
-  Status = EFI_NOT_FOUND;
-
-  SysId = MmioRead32 (ARM_VE_SYS_ID_REG);
-  if (SysId != ARM_RTSM_SYS_ID) {
-// Remove the GIC variant to identify if we are running on the FVP Base or
-// Foundation models
-FvpSysId = SysId & (ARM_FVP_SYS_ID_HBI_MASK |
-ARM_FVP_SYS_ID_PLAT_MASK );
-// Extract the variant from the SysId
-VariantSysId = SysId & ARM_FVP_SYS_ID_VARIANT_MASK;
-
-if (FvpSysId == ARM_FVP_BASE_BOARD_SYS_ID) {
-  if (VariantSysId == ARM_FVP_GIC_VE_MMAP) {
-// FVP Base Model with legacy GIC memory map
-Status = ArmVExpressGetPlatformFromId

[edk2] [PATCH v3 1/3] ArmPlatformPkg/ArmVExpressDxe: remove ARM support

2017-04-10 Thread Ard Biesheuvel

The 32-bit ARM support in this driver is unused, and thus untested.
So let's just remove it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/Arm/ArmFvpDxeArm.c | 84 

 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmFvpDxe.inf  |  9 ---
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressPkg.dec| 10 ---
 3 files changed, 103 deletions(-)

diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/Arm/ArmFvpDxeArm.c 
b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/Arm/ArmFvpDxeArm.c
deleted file mode 100644
index 2057c6e2156a..
--- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/Arm/ArmFvpDxeArm.c
+++ /dev/null
@@ -1,84 +0,0 @@
-/** @file
-
-  Copyright (c) 2014, ARM Ltd. All rights reserved.
-
-  This program and the accompanying materials are licensed and made available
-  under the terms and conditions of the BSD License which accompanies this
-  distribution.  The full text of the license may be found at
-  http://opensource.org/licenses/bsd-license.php
-
-  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
-  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-
-**/
-
-#include "ArmVExpressInternal.h"
-#include   // To get Core Count
-
-//
-// Description of the four ARM model platforms :
-// Platform ids are defined in ArmVExpressInternal.h for
-// all "ArmVExpress-like" platforms (AARCH64 or ARM architecture,
-// model or hardware platforms).
-//
-CONST ARM_VEXPRESS_PLATFORM ArmVExpressPlatforms[] = {
-  { ARM_FVP_VEXPRESS_A9x4,  FixedPcdGetPtr (PcdFdtVExpressFvpA9x4),  
L"rtsm_ve-cortex_a9x4.dtb"  },
-  { ARM_FVP_VEXPRESS_A15x1, FixedPcdGetPtr (PcdFdtVExpressFvpA15x1), 
L"rtsm_ve-cortex_a15x1.dtb" },
-  { ARM_FVP_VEXPRESS_A15x2, FixedPcdGetPtr (PcdFdtVExpressFvpA15x2), 
L"rtsm_ve-cortex_a15x2.dtb" },
-  { ARM_FVP_VEXPRESS_A15x4, FixedPcdGetPtr (PcdFdtVExpressFvpA15x4), 
L"rtsm_ve-cortex_a15x4.dtb" },
-  { ARM_FVP_VEXPRESS_UNKNOWN, }
-};
-
-/**
-  Get information about the VExpress platform the firmware is running on.
-
-  @param[out]  Platform   Address where the pointer to the platform information
-  (type ARM_VEXPRESS_PLATFORM*) should be stored.
-  The returned pointer does not point to an allocated
-  memory area.
-
-  @retval  EFI_SUCCESSThe platform information was returned.
-  @retval  EFI_NOT_FOUND  The platform was not recognised.
-
-**/
-EFI_STATUS
-ArmVExpressGetPlatform (
-  OUT CONST ARM_VEXPRESS_PLATFORM** Platform
-  )
-{
-  UINT32SysId;
-  UINTN CpuType;
-  EFI_STATUSStatus;
-  UINTN CoreCount;
-
-  ASSERT (Platform != NULL);
-
-  CpuType   = 0;
-  Status= EFI_NOT_FOUND;
-  *Platform = NULL;
-
-  SysId = MmioRead32 (ARM_VE_SYS_ID_REG);
-  if (SysId == ARM_RTSM_SYS_ID) {
-// Get the Cortex-A version
-CpuType = (ArmReadMidr () >> 4) & ARM_CPU_TYPE_MASK;
-if (CpuType == ARM_CPU_TYPE_A9) {
-  Status = ArmVExpressGetPlatformFromId (ARM_FVP_VEXPRESS_A9x4, Platform);
-} else if (CpuType == ARM_CPU_TYPE_A15) {
-  CoreCount = ArmGetCpuCountPerCluster ();
-  if (CoreCount == 1) {
-Status = ArmVExpressGetPlatformFromId (ARM_FVP_VEXPRESS_A15x1, 
Platform);
-  } else if (CoreCount == 2) {
-Status = ArmVExpressGetPlatformFromId (ARM_FVP_VEXPRESS_A15x2, 
Platform);
-  } else if (CoreCount == 4) {
-Status = ArmVExpressGetPlatformFromId (ARM_FVP_VEXPRESS_A15x4, 
Platform);
-  }
-}
-  }
-
-  if (EFI_ERROR (Status)) {
-DEBUG ((EFI_D_ERROR, "Unsupported platform (SysId:0x%X, CpuType:0x%X)\n", 
SysId, CpuType));
-ASSERT_EFI_ERROR (Status);
-  }
-
-  return Status;
-}
diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmFvpDxe.inf 
b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmFvpDxe.inf
index 327c5101ddb5..2a8c8388a3b2 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmFvpDxe.inf
+++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmFvpDxe.inf
@@ -24,9 +24,6 @@ [Sources.common]
   ArmFvpDxe.c
   ArmVExpressCommon.c
 
-[Sources.ARM]
-  Arm/ArmFvpDxeArm.c
-
 [Sources.AARCH64]
   AArch64/ArmFvpDxeAArch64.c
 
@@ -61,12 +58,6 @@ [Protocols]
 [FixedPcd]
   gArmVExpressTokenSpaceGuid.PcdFvpFdtDevicePathsBase
 
-[FixedPcd.ARM]
-  gArmVExpressTokenSpaceGuid.PcdFdtVExpressFvpA9x4
-  gArmVExpressTokenSpaceGuid.PcdFdtVExpressFvpA15x1
-  gArmVExpressTokenSpaceGuid.PcdFdtVExpressFvpA15x2
-  gArmVExpressTokenSpaceGuid.PcdFdtVExpressFvpA15x4
-
 [FixedPcd.AARCH64]
   gArmVExpressTokenSpaceGuid.PcdFdtFvpVExpressAEMv8x4
   gArmVExpressTokenSpaceGuid.PcdFdtFvpBaseAEMv8x4GicV2
diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpressPkg.dec 
b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpressPkg.dec
index c774d97541e1..39f046541502 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpressPkg.dec
+++

[edk2] [PATCH v3 0/3] ArmPlatformPkg: FVP spring cleaning -- EDK2 edition

2017-04-10 Thread Ard Biesheuvel

This v3 of the ArmPlatformPkg now only contains FVP changes. TC2 and Juno
will receive a similar treatment once we have sorted out how the loading of
the DTB image from the NOR flash will be implemented.

So what remains here is two somewhat unrelated cleanup patches, and the
meat in #3 which removes the functionality that interoperates with the
FdtPlatformDxe that we are trying to get rid of.

Ard Biesheuvel (3):
  ArmPlatformPkg/ArmVExpressDxe: remove ARM support
  ArmPlatformPkg/ArmVExpressDxe: remove unused cruft from ArmHwDxe
  ArmPlatformPkg/ArmVExpressDxe: remove FDT handling from ArmFvpDxe

 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/AArch64/ArmFvpDxeAArch64.c | 113 

 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/Arm/ArmFvpDxeArm.c |  84 

 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmFvpDxe.c| 137 
+---
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmFvpDxe.inf  |  42 
--
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmHwDxe.c |  43 
+-
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmHwDxe.inf   |   3 -
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmVExpressCommon.c|  48 
---
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmVExpressInternal.h  |  99 
--
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressPkg.dec|  28 

 9 files changed, 6 insertions(+), 591 deletions(-)
 delete mode 100644 
ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/AArch64/ArmFvpDxeAArch64.c
 delete mode 100644 
ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/Arm/ArmFvpDxeArm.c
 delete mode 100644 
ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmVExpressCommon.c
 delete mode 100644 
ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmVExpressInternal.h

-- 
2.9.3

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

Re: [edk2] Using USB-Ethernet adapter in UEFI on an arm64 platform

2017-04-10 Thread Vladimir Olovyannikov

Hi Feng,

Thank you for your explanation.
I have Cisco 300M AX88772A-based adapter, so AX88772 (with no "b") driver
was picked up.
I had to modify it with circular buffer to get ping and tftp going. Also I
had to receive packets in GetStatus rather than in SN_Receive (otherwise I
could never get into the Shell).
This way I have ping with response time of approx. 200ms, and tftp
working, albeit it is slow.
So do you suggest me to use Ax88772b driver for AX88772A/AX88772
usb-ethernet adapter?
Also maybe you know if there are UEFI drivers for other USB-ethernet
adapters (maybe 1G?) available somewhere?

Thank you,
Vladimir
-Original Message-
From: Tian, Feng [mailto:feng.t...@intel.com]
Sent: April-09-17 9:49 PM
To: Vladimir Olovyannikov; edk2-devel@lists.01.org
Cc: Tian, Feng
Subject: RE: [edk2] Using USB-Ethernet adapter in UEFI on an arm64
platform

Hi, Vladimir,

Which usb2lan driver you are using for AX88772 adpater? The one in
OptionRomPkg\Bus\Usb\UsbNetworking has bug on the polling performance. The
one in OptionRomPkg\Bus\Usb\UsbNetworking\Ax88772b is better but if there
is no data received, the polling operation still wastes some time.

The root cause about the low performance of polling is because USB spec
doesn't clearly define which value should be returned if user requests
Bulk Read operation but there is no data. Some data-streaming usb devices,
such as Realtek usb2lan, return success with data length setting to 0, but
others, such as AX88772, just keep active and wait for data always. From
BIOS view, we have to return EFI_TIMEOUT for latter case to avoid system
hang. That's why you see the low performance for polling operation in
no-data case.

Thanks
Feng

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
Vladimir Olovyannikov
Sent: Saturday, April 8, 2017 3:06 AM
To: edk2-devel@lists.01.org
Subject: [edk2] Using USB-Ethernet adapter in UEFI on an arm64 platform

Hi,

I would like to enable Ethernet using USB-Ethernet AX88772 adapter in the
UEFI on an armv8 arm64 platform.
Ethernet polling is done by MnpPoll() periodically. This creates a burden
on the system so that UEFI boots in 1 minute to the Shell due to receive
polling.
The USB operation is very resource expensive which causes UEFI to choke
up.
There is DisableBackgroundPolling option in the
EFI_MANAGED_NETWORK_CONFIG_DATA structure, but it is turned off by all
other drivers (DNSDxe, Ip4Dxe, ArpDxe...).
Can anybody advise what I could do?
Mass storage/keyboard/etc. all work fine...

Thank you,
Vladimir
___
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] Running pieces of PEI from binary UEFI images

2017-04-10 Thread Andrew Fish

> On Apr 10, 2017, at 12:48 AM, Stefano Cristalli  
> wrote:
> 
> Hello everyone,
> 
> I'm interested in experimenting with the PEI phase using EmulatorPkg,
> OVMF and other EDKII parts that could be useful.
> In particular, I'm interested in the possibility of integrating parts
> of an existing pre-built binary UEFI image with such environments. If
> the image was developed based on EDKII, would I expect things to work?
> I'm not looking for complete emulation, I just think it would be
> interesting to be able to single-step code inside PEIMs or even the
> PeiCore from random images, leveraging the already existing EDKII
> infrastructures (rather than switching to other debugging/emulation
> projects).
> 
> I thought that the task might be feasible, since the layout of the
> memory at the beginning of PEI and even the arguments passed to the
> PeiCore are standardized... I should at least be able to begin
> execution.
> 
> What do you think? Am I missing something?
> 
> Additionally, I would ask for technical help, as it's not clear to me
> how exactly I would be able
> to load such modules. I saw that there is
> the possibility of loading binaries inside an EDKII image build (cfr.
> INF_Spec_1_25 section 2.7), but I don't understand how would I do this
> for PEI binaries and if I could expect things to work (as in with only
> the pointer to the image, without any additional information
> specified).
> 

Stefano,

PEI and DXE are designed to support your usage model. The FD (Flash Device) 
layout is a simple file system (usually read only, but does not have to be) 
called an FV (Firmware Volume). The FV contains files that are named by 
EFI_GUID (UUID), and does not support directories. Each file in an FV consists 
of a set of sections and sections can encapsulate other sections (that is how 
compression works). Two (PEI and DXE) of the section types are for depex 
(Dependency Expressions). The PEI depex grammar is simpler than DXE but they 
both support TRUE, and ANDing together PPI/Protocol GUIDs. When the depex is 
true  the PEI/DXE Driver is queued for dispatch. So PPI_A AND PPI_B means 
dispatch this PEIM when both PPI_A and PPI_B are installed in the system. The 
PEI and DXE Cores both contain dispatchers that make all this happen. This is 
all described in great detail in the UEFI Platform Initialization (PI) 
Specification that you can download from here: 
http://www.uefi.org/specifications

The edk2 uses FDF files to layout the FD and build FVs. Here is an example of a 
binary DXE driver that will dispatch after gPlatformGOPPolicyGuid is installed. 

https://github.com/tianocore/edk2/blob/master/Vlv2TbltDevicePkg/PlatformPkg.fdf#L577

 FILE DRIVER = FF0C8745-3270-4439-B74F-3E45F8C77064 {
  SECTION DXE_DEPEX_EXP = {gPlatformGOPPolicyGuid}
  SECTION PE32 = 
Vlv2MiscBinariesPkg/GOP/7.2.1011/RELEASE_VS2008x86/$(DXE_ARCHITECTURE)/IntelGopDriver.efi
  SECTION UI = "IntelGopDriver"
}

The depex type would be different for PEI  but you get the idea. The FDF spec 
lives here: 
https://github.com/tianocore/tianocore.github.io/wiki/EDK%20II%20Specifications

In PEI it is common that the image type may be TE vs. PE/COFF. TE (Tiano 
Executable) is just a hack to make the PE/COFF header smaller, as in PE/COFF 
(unlike other image formats) the header is part of the executable image. In 
general TE makes the most sense when an image is executed from FLASH. You can 
tell if an image is TE if you hexdump it  you will see a VZ signature, and 
PE/COFF has a PE/0/0 header and can also start with a DOS header that has an MZ 
signature.

The PEI Core  will use the FV to find the PE/COFF image, and from the PE/COFF 
header it can find the offset to the entry point. Thus the PEI Core can call 
into the PE/COFF image and run it from FLASH, or it can shadow it into memory, 
relocate the image, and call the entry point. 

Thanks,

Andrew Fish

PS MZ is for Mark Zbikowski one of the developers of MS-DOS. VZ is for Vincent 
Zimmer as he wrote that part of the Tiano Spec that ended up in the PI Spec. 
Vincent also made the uninitialized memory value 0xAF as a joke about my 
initials. 

> I'd really appreciate if someone could give me some explanations to
> clear my ideas about this. Some pointers to documentation would be
> just fine, for it's quite complicated to figure out completely as an
> EDKII beginner. "Dude, it's completely unfeasible" is also fine and
> helpful as a response, if that's the case for some reason.
> 
> Thanks in advance.
> Best regards.
> 
> Stefano Cristalli
> ___
> edk2-devel mailing
> list
> edk2-devel@lists.01.org
> https://angler.apple.com:443/proxy?url=ChY71XmEIaglKYTvqPpJ7AsI5LDpggaDTaabgJPkJxd8IubgWIh3iPGbZH%2BpoQgRuP3YvQVwjIVArds4ikYRj%2BSF45Qc%2FowwxUMxCowjAQA%3D=true=https%3A%2F%2Flists.01.org%2Fmailman%2Flistinfo%2Fedk2-devel

___
edk2-devel mailing list

Re: [edk2] [PATCH] MdeModulePkg/ScsiDiskDxe: Fix potential implicit sign extension

2017-04-10 Thread Laszlo Ersek

(Gary, is your Linaro email still alive?)

On 04/10/17 09:43, Hao Wu wrote:
> In function GetMediaInfo(), the following expression:
> ScsiDiskDevice->BlkIo.Media->LastBlock =  (Capacity10->LastLba3 << 24) |
>   (Capacity10->LastLba2 << 16) |
>   (Capacity10->LastLba1 << 8)  |
>Capacity10->LastLba0;
> will involve implicit sign extension.
> 
> Since Capacity10->LastLbaX is of type UINT8, and
> ScsiDiskDevice->BlkIo.Media->LastBlock is of type UINT64. Therefore,
> Capacity10->LastLbaX will be promoted to int (32 bits, signed) first,
> perform the bit shift and or. Then the result will be sign-extended to
> type UINT64.
> 
> If bit 7 of Capacity10->LastLba3 is 1, then the high 32 bits of
> ScsiDiskDevice->BlkIo.Media->LastBlock will all be set to 1.
> 
> This commit will add an explicit UINT32 type cast for
> Capacity10->LastLba3 to resolve this issue.
> 
> Cc: Feng Tian 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Hao Wu 
> ---
>  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c 
> b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
> index b5eff25b9b..2289f20152 100644
> --- a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
> +++ b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
> @@ -1,7 +1,7 @@
>  /** @file
>SCSI disk driver that layers on every SCSI IO protocol in the system.
>  
> -Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
>  This program and the accompanying materials
>  are licensed and made available under the terms and conditions of the BSD 
> License
>  which accompanies this distribution.  The full text of the license may be 
> found at
> @@ -2754,7 +2754,7 @@ GetMediaInfo (
>UINT8   *Ptr;
>  
>if (!ScsiDiskDevice->Cdb16Byte) {
> -ScsiDiskDevice->BlkIo.Media->LastBlock =  (Capacity10->LastLba3 << 24) |
> +ScsiDiskDevice->BlkIo.Media->LastBlock =  ((UINT32) Capacity10->LastLba3 
> << 24) |
>(Capacity10->LastLba2 << 16) |
>(Capacity10->LastLba1 << 8)  |
> Capacity10->LastLba0;
> 

The patch looks okay to me, but I would like to comment on the commit
message. The commit message says "sign extension", which is an assembly
language / processor level concept; the C language doesn't know about
"sign extension".

Instead, what we have here is undefined behavior.

6.5.7 Bitwise shift operators

  3 The integer promotions are performed on each of the operands. The
type of the result is that of the promoted left operand. If the
value of the right operand is negative or is greater than or equal
to the width of the promoted left operand, the behavior is
undefined.

  4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated
bits are filled with zeros. If E1 has an unsigned type, the value
of the result is E1 × 2^E2 , reduced modulo one more than the
maximum value representable in the result type. If E1 has a signed
type and nonnegative value, and E1 × 2^E2 is representable in the
result type, then that is the resulting value; otherwise, the
behavior is undefined.

So, we have a left operand here that is promoted to "int". It means that
"E1" has signed type. Its value is nonnegative. However, E1 × 2^E2 is
not representable in the result type, hence the behavior is undefined.

The fact that this undefined shift *happens* to result in the sign bit
being set (resulting in a negative "int" value), which in turn is
converted to a 64-bit unsigned value as proscribed by the usual
arithmetic conversions (*), is just an implementation detail. The root
cause is that the signed left shift invokes undefined behavior.

(

(*)

6.3.1.8 Usual arithmetic conversions

  1 [...] Otherwise, if the operand that has unsigned integer type has
rank greater or equal to the rank of the type of the other operand,
then the operand with signed integer type is converted to the type
of the operand with unsigned integer type.

6.3.1.3 Signed and unsigned integers

  2 Otherwise, if the new type is unsigned, the value is converted by
repeatedly adding or subtracting one more than the maximum value
that can be represented in the new type until the value is in the
range of the new type.

)

So I suggest to reformulate the subject line and the commit message to
say something like:

  MdeModulePkg/ScsiDiskDxe: fix undefined behavior in signed left shift

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

Re: [edk2] SUT hangs after performing a warm boot.

2017-04-10 Thread Santhapur Naveen

Hi Jiaxin,

Below are the simple reproduction steps:

BIOS UEFI Class3
(1)   Connect LAN cable (Realtek)
(2)   Do cold boot or warm boot stress (Windows 10)

Please let me know for any additional information you may need.

Thanks,
Naveen

-Original Message-
From: Wu, Jiaxin [mailto:jiaxin...@intel.com] 
Sent: Monday, April 10, 2017 6:00 AM
To: Santhapur Naveen; edk2-devel@lists.01.org
Subject: RE: SUT hangs after performing a warm boot.

Hi Naveen,

As the description of Ip6NdFasterTimerTicking(), it's the time routine of ND 
module for IPv6.

Can you provide the detailed reproduce steps?

Thanks,
Jiaxin

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Santhapur Naveen
> Sent: Friday, April 7, 2017 8:20 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] SUT hangs after performing a warm boot.
> 
> Hi all,
> 
>   Under NetworkPkg, in Ip6Dxe driver, what purpose does this 
> function
> Ip6NdFasterTimerTicking() serve?
>   Sometimes, the SUT hangs in this function (at 
> bootmgfw.Entry) when booting to Windows after performing a warm boot.
> 
> Thanks,
> Naveen
> ___
> 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: Add option in CLANG38 to disable warning unknown-warning-option

2017-04-10 Thread Zhu, Yonghong

Reviewed-by: Yonghong Zhu 

Best Regards,
Zhu Yonghong

-Original Message-
From: Gao, Liming 
Sent: Monday, April 10, 2017 1:28 PM
To: edk2-devel@lists.01.org
Cc: Zhu, Yonghong 
Subject: [Patch] BaseTools: Add option in CLANG38 to disable warning 
unknown-warning-option

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

Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
---
 BaseTools/Conf/tools_def.template | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 14ecfed..427ef1b 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -5512,7 +5512,7 @@ DEFINE CLANG38_X64_PREFIX   = ENV(CLANG38_BIN)
 DEFINE CLANG38_IA32_TARGET  = -target i686-pc-linux-gnu
 DEFINE CLANG38_X64_TARGET   = -target x86_64-pc-linux-gnu
 
-DEFINE CLANG38_ALL_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS) -Wno-empty-body 
-fno-stack-protector -mms-bitfields -Wno-address -Wno-shift-negative-value 
-Wno-parentheses-equality -Wno-unknown-pragmas 
-Wno-tautological-constant-out-of-range-compare 
-Wno-incompatible-library-redeclaration -fno-asynchronous-unwind-tables 
-mno-sse -mno-mmx -msoft-float -mno-implicit-float  
-ftrap-function=undefined_behavior_has_been_optimized_away_by_clang 
-funsigned-char -fno-ms-extensions -Wno-null-dereference 
-Wno-tautological-compare
+DEFINE CLANG38_ALL_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS) -Wno-empty-body 
-fno-stack-protector -mms-bitfields -Wno-address -Wno-shift-negative-value 
-Wno-parentheses-equality -Wno-unknown-pragmas 
-Wno-tautological-constant-out-of-range-compare 
-Wno-incompatible-library-redeclaration -fno-asynchronous-unwind-tables 
-mno-sse -mno-mmx -msoft-float -mno-implicit-float  
-ftrap-function=undefined_behavior_has_been_optimized_away_by_clang 
-funsigned-char -fno-ms-extensions -Wno-null-dereference 
-Wno-tautological-compare -Wno-unknown-warning-option
 
 ###
 # CLANG38 IA32 definitions
-- 
2.8.0.windows.1

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

Re: [edk2] [ScsiDiskDxe] Implict type conversion bug

2017-04-10 Thread Zeng, Star

Hao has sent patch for this issue.
You can search emails with title "[edk2] [PATCH] MdeModulePkg/ScsiDiskDxe: Fix 
potential implicit sign extension".

Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Guoheyi
Sent: Monday, April 10, 2017 5:40 PM
To: edk2-devel@lists.01.org
Cc: Tian, Feng 
Subject: [edk2] [ScsiDiskDxe] Implict type conversion bug

Hi folks,

In MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c, Line 2757, we have the code as 
below:

ScsiDiskDevice->BlkIo.Media->LastBlock =  (Capacity10->LastLba3 << 24) |
  (Capacity10->LastLba2 << 16) |
  (Capacity10->LastLba1 << 8)  |
   Capacity10->LastLba0;

However, we tested on VS2008 and found that the intermediate result would be 
convert to INT32 then INT64 implicitly, so the result will be sign extended and 
LastBlock may not be assigned with what is expected. We can simply test 
LastLba3 >= 0x80 to see what will happen.

Please let me know your comments.

Thanks and regards,

Gary (Heyi Guo)
___
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] [ScsiDiskDxe] Implict type conversion bug

2017-04-10 Thread Guoheyi

Hi folks,

In MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c, Line 2757, we have the code as 
below:

ScsiDiskDevice->BlkIo.Media->LastBlock =  (Capacity10->LastLba3 << 24) |
  (Capacity10->LastLba2 << 16) |
  (Capacity10->LastLba1 << 8)  |
   Capacity10->LastLba0;

However, we tested on VS2008 and found that the intermediate result would be 
convert to INT32 then INT64 implicitly, so the result will be sign extended and 
LastBlock may not be assigned with what is expected. We can simply test 
LastLba3 >= 0x80 to see what will happen.

Please let me know your comments.

Thanks and regards,

Gary (Heyi Guo)
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Running pieces of PEI from binary UEFI images

2017-04-10 Thread Stefano Cristalli

Hello everyone,

I'm interested in experimenting with the PEI phase using EmulatorPkg,
OVMF and other EDKII parts that could be useful.
In particular, I'm interested in the possibility of integrating parts
of an existing pre-built binary UEFI image with such environments. If
the image was developed based on EDKII, would I expect things to work?
I'm not looking for complete emulation, I just think it would be
interesting to be able to single-step code inside PEIMs or even the
PeiCore from random images, leveraging the already existing EDKII
infrastructures (rather than switching to other debugging/emulation
projects).

I thought that the task might be feasible, since the layout of the
memory at the beginning of PEI and even the arguments passed to the
PeiCore are standardized... I should at least be able to begin
execution.

What do you think? Am I missing something?

Additionally, I would ask for technical help, as it's not clear to me
how exactly I would be able to load such modules. I saw that there is
the possibility of loading binaries inside an EDKII image build (cfr.
INF_Spec_1_25 section 2.7), but I don't understand how would I do this
for PEI binaries and if I could expect things to work (as in with only
the pointer to the image, without any additional information
specified).

I'd really appreciate if someone could give me some explanations to
clear my ideas about this. Some pointers to documentation would be
just fine, for it's quite complicated to figure out completely as an
EDKII beginner. "Dude, it's completely unfeasible" is also fine and
helpful as a response, if that's the case for some reason.

Thanks in advance.
Best regards.

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

[edk2] [PATCH] MdeModulePkg/ScsiDiskDxe: Fix potential implicit sign extension

2017-04-10 Thread Hao Wu

In function GetMediaInfo(), the following expression:
ScsiDiskDevice->BlkIo.Media->LastBlock =  (Capacity10->LastLba3 << 24) |
  (Capacity10->LastLba2 << 16) |
  (Capacity10->LastLba1 << 8)  |
   Capacity10->LastLba0;
will involve implicit sign extension.

Since Capacity10->LastLbaX is of type UINT8, and
ScsiDiskDevice->BlkIo.Media->LastBlock is of type UINT64. Therefore,
Capacity10->LastLbaX will be promoted to int (32 bits, signed) first,
perform the bit shift and or. Then the result will be sign-extended to
type UINT64.

If bit 7 of Capacity10->LastLba3 is 1, then the high 32 bits of
ScsiDiskDevice->BlkIo.Media->LastBlock will all be set to 1.

This commit will add an explicit UINT32 type cast for
Capacity10->LastLba3 to resolve this issue.

Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c 
b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
index b5eff25b9b..2289f20152 100644
--- a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
+++ b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
@@ -1,7 +1,7 @@
 /** @file
   SCSI disk driver that layers on every SCSI IO protocol in the system.
 
-Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -2754,7 +2754,7 @@ GetMediaInfo (
   UINT8   *Ptr;
 
   if (!ScsiDiskDevice->Cdb16Byte) {
-ScsiDiskDevice->BlkIo.Media->LastBlock =  (Capacity10->LastLba3 << 24) |
+ScsiDiskDevice->BlkIo.Media->LastBlock =  ((UINT32) Capacity10->LastLba3 
<< 24) |
   (Capacity10->LastLba2 << 16) |
   (Capacity10->LastLba1 << 8)  |
Capacity10->LastLba0;
-- 
2.12.0.windows.1

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

[edk2] [PATCH 1/3] MdeModulePkg: Error Level is not used correctly

2017-04-10 Thread Jeff Fan

Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 .../Universal/Acpi/BootScriptExecutorDxe/ScriptExecute.c   | 10 +-
 .../Universal/Acpi/BootScriptExecutorDxe/X64/SetIdtEntry.c |  4 ++--
 MdeModulePkg/Universal/Acpi/S3SaveStateDxe/AcpiS3ContextSave.c |  2 +-
 MdeModulePkg/Universal/CapsulePei/UefiCapsule.c|  2 +-
 .../Universal/CapsuleRuntimeDxe/X64/SaveLongModeContext.c  |  4 ++--
 MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.c | 10 +-
 .../Universal/PlatformDriOverrideDxe/PlatDriOverrideDxe.c  |  4 ++--
 7 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/ScriptExecute.c 
b/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/ScriptExecute.c
index 5147e66..4545d6e 100644
--- a/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/ScriptExecute.c
+++ b/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/ScriptExecute.c
@@ -103,7 +103,7 @@ S3BootScriptExecutorEntryFunction (
   //
   // X64 S3 Resume
   //
-  DEBUG ((EFI_D_ERROR, "Call AsmDisablePaging64() to return to S3 Resume 
in PEI Phase\n"));
+  DEBUG ((DEBUG_INFO, "Call AsmDisablePaging64() to return to S3 Resume in 
PEI Phase\n"));
   PeiS3ResumeState->AsmTransferControl = 
(EFI_PHYSICAL_ADDRESS)(UINTN)AsmTransferControl32;
 
   if ((Facs != NULL) &&
@@ -128,7 +128,7 @@ S3BootScriptExecutorEntryFunction (
   //
   // IA32 S3 Resume
   //
-  DEBUG ((EFI_D_ERROR, "Call SwitchStack() to return to S3 Resume in PEI 
Phase\n"));
+  DEBUG ((DEBUG_INFO, "Call SwitchStack() to return to S3 Resume in PEI 
Phase\n"));
   PeiS3ResumeState->AsmTransferControl = 
(EFI_PHYSICAL_ADDRESS)(UINTN)AsmTransferControl;
 
   SwitchStack (
@@ -160,7 +160,7 @@ S3BootScriptExecutorEntryFunction (
   //
   // X64 long mode waking vector
   //
-  DEBUG (( EFI_D_ERROR, "Transfer to 64bit OS waking vector - %x\r\n", 
(UINTN)Facs->XFirmwareWakingVector));
+  DEBUG ((DEBUG_INFO, "Transfer to 64bit OS waking vector - %x\r\n", 
(UINTN)Facs->XFirmwareWakingVector));
   if (FeaturePcdGet (PcdDxeIplSwitchToLongMode)) {
 SwitchStack (
   (SWITCH_STACK_ENTRY_POINT)(UINTN)Facs->XFirmwareWakingVector,
@@ -177,7 +177,7 @@ S3BootScriptExecutorEntryFunction (
   //
   // IA32 protected mode waking vector (Page disabled)
   //
-  DEBUG (( EFI_D_ERROR, "Transfer to 32bit OS waking vector - %x\r\n", 
(UINTN)Facs->XFirmwareWakingVector));
+  DEBUG ((DEBUG_INFO, "Transfer to 32bit OS waking vector - %x\r\n", 
(UINTN)Facs->XFirmwareWakingVector));
   if (FeaturePcdGet (PcdDxeIplSwitchToLongMode)) {
 AsmDisablePaging64 (
   0x10,
@@ -199,7 +199,7 @@ S3BootScriptExecutorEntryFunction (
 //
 // 16bit Realmode waking vector
 //
-DEBUG (( EFI_D_ERROR, "Transfer to 16bit OS waking vector - %x\r\n", 
(UINTN)Facs->FirmwareWakingVector));
+DEBUG ((DEBUG_INFO, "Transfer to 16bit OS waking vector - %x\r\n", 
(UINTN)Facs->FirmwareWakingVector));
 AsmTransferControl (Facs->FirmwareWakingVector, 0x0);
   }
 
diff --git 
a/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/SetIdtEntry.c 
b/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/SetIdtEntry.c
index d433cf1..70eecf5 100644
--- a/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/SetIdtEntry.c
+++ b/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/SetIdtEntry.c
@@ -3,7 +3,7 @@
 
   Set a IDT entry for interrupt vector 3 for debug purpose for x64 platform
 
-Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
 Copyright (c) 2017, AMD Incorporated. All rights reserved.
 
 
@@ -234,7 +234,7 @@ PageFaultHandler (
   UINTN  PTIndex;
 
   PFAddress = AsmReadCr2 ();
-  DEBUG ((EFI_D_ERROR, "BootScript - PageFaultHandler: Cr2 - %lx\n", 
PFAddress));
+  DEBUG ((DEBUG_INFO, "BootScript - PageFaultHandler: Cr2 - %lx\n", 
PFAddress));
 
   if (PFAddress >= mPhyMask + SIZE_4KB) {
 return FALSE;
diff --git a/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/AcpiS3ContextSave.c 
b/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/AcpiS3ContextSave.c
index dcfd61c..3c05558 100644
--- a/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/AcpiS3ContextSave.c
+++ b/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/AcpiS3ContextSave.c
@@ -407,7 +407,7 @@ S3AllocatePageTablesBuffer (
 }
 
 TotalPageTableSize += ExtraPageTablePages;
-DEBUG ((EFI_D_ERROR, "AcpiS3ContextSave TotalPageTableSize - 0x%x 
pages\n", TotalPageTableSize));
+DEBUG ((DEBUG_INFO, "AcpiS3ContextSave TotalPageTableSize - 0x%x pages\n", 
TotalPageTableSize));
 
 //
 // By architecture only one PageMapLevel4 exists - so lets allocate 
storage for it.
diff --git a/MdeModulePkg/Universal/CapsulePei/UefiCapsule.c

[edk2] [PATCH 0/3] Error Level is not used correctly

2017-04-10 Thread Jeff Fan

Some modules mis-used error level when outputting debug message.

Jeff Fan (3):
  MdeModulePkg: Error Level is not used correctly
  SecurityPkg: Error Level is not used correctly
  UefiCpuPkg: Error Level is not used correctly

 .../Acpi/BootScriptExecutorDxe/ScriptExecute.c | 10 ++--
 .../Acpi/BootScriptExecutorDxe/X64/SetIdtEntry.c   |  4 +-
 .../Acpi/S3SaveStateDxe/AcpiS3ContextSave.c|  2 +-
 MdeModulePkg/Universal/CapsulePei/UefiCapsule.c|  2 +-
 .../CapsuleRuntimeDxe/X64/SaveLongModeContext.c|  4 +-
 .../Universal/LockBox/SmmLockBox/SmmLockBox.c  | 10 ++--
 .../PlatformDriOverrideDxe/PlatDriOverrideDxe.c|  4 +-
 .../Tpm2DeviceLibRouter/Tpm2DeviceLibRouterDxe.c   |  4 +-
 .../Tpm2DeviceLibRouter/Tpm2DeviceLibRouterPei.c   |  4 +-
 SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c  |  2 +-
 SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c  |  4 +-
 SecurityPkg/Tcg/TrEEDxe/TrEEDxe.c  |  4 +-
 SecurityPkg/Tcg/TrEEPei/TrEEPei.c  |  4 +-
 UefiCpuPkg/CpuDxe/CpuPageTable.c   |  2 +-
 UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c  | 68 +++---
 15 files changed, 64 insertions(+), 64 deletions(-)

-- 
2.9.3.windows.2

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

[edk2] [PATCH 2/3] SecurityPkg: Error Level is not used correctly

2017-04-10 Thread Jeff Fan

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterDxe.c | 4 ++--
 SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterPei.c | 4 ++--
 SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c| 2 +-
 SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c| 4 ++--
 SecurityPkg/Tcg/TrEEDxe/TrEEDxe.c| 4 ++--
 SecurityPkg/Tcg/TrEEPei/TrEEPei.c| 4 ++--
 6 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterDxe.c 
b/SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterDxe.c
index 1e8c354..eedc439 100644
--- a/SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterDxe.c
+++ b/SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterDxe.c
@@ -3,7 +3,7 @@
   via PcdTpmInstanceGuid. Platform need make choice that which one will be 
final one.
   At most one TPM2 instance can be finally registered, and other will return 
unsupported.
 
-Copyright (c) 2013 - 2016, Intel Corporation. All rights reserved. 
+Copyright (c) 2013 - 2017, Intel Corporation. All rights reserved. 
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -89,7 +89,7 @@ Tpm2RegisterTpm2DeviceLib (
   )
 {
   if (!CompareGuid (PcdGetPtr(PcdTpmInstanceGuid), >ProviderGuid)){
-DEBUG ((EFI_D_ERROR, "WARNING: Tpm2RegisterTpm2DeviceLib - does not 
support %g registration\n", >ProviderGuid));
+DEBUG ((DEBUG_WARN, "WARNING: Tpm2RegisterTpm2DeviceLib - does not support 
%g registration\n", >ProviderGuid));
 return EFI_UNSUPPORTED;
   }
 
diff --git a/SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterPei.c 
b/SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterPei.c
index 0211399..7470fe3 100644
--- a/SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterPei.c
+++ b/SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterPei.c
@@ -3,7 +3,7 @@
   via PcdTpmInstanceGuid. Platform need make choice that which one will be 
final one.
   At most one TPM2 instance can be finally registered, and other will return 
unsupported.
 
-Copyright (c) 2013 - 2016, Intel Corporation. All rights reserved. 
+Copyright (c) 2013 - 2017, Intel Corporation. All rights reserved. 
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -120,7 +120,7 @@ Tpm2RegisterTpm2DeviceLib (
   TPM2_DEVICE_INTERFACE *Tpm2DeviceInterface;
 
   if (!CompareGuid (PcdGetPtr(PcdTpmInstanceGuid), >ProviderGuid)){
-DEBUG ((EFI_D_ERROR, "WARNING: Tpm2RegisterTpm2DeviceLib - does not 
support %g registration\n", >ProviderGuid));
+DEBUG ((DEBUG_WARN, "WARNING: Tpm2RegisterTpm2DeviceLib - does not support 
%g registration\n", >ProviderGuid));
 return EFI_UNSUPPORTED;
   }
 
diff --git a/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c 
b/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c
index 53de666..c2c52e3 100644
--- a/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c
+++ b/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c
@@ -2466,7 +2466,7 @@ DriverEntry (
 
   if (CompareGuid (PcdGetPtr(PcdTpmInstanceGuid), 
) ||
   CompareGuid (PcdGetPtr(PcdTpmInstanceGuid), 
)){
-DEBUG ((EFI_D_ERROR, "No TPM2 instance required!\n"));
+DEBUG ((DEBUG_INFO, "No TPM2 instance required!\n"));
 return EFI_UNSUPPORTED;
   }
 
diff --git a/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c 
b/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c
index 209d843..69adad4 100644
--- a/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c
+++ b/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c
@@ -1,7 +1,7 @@
 /** @file
   Initialize TPM2 device and measure FVs before handing off control to DXE.
 
-Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2017, Intel Corporation. All rights reserved.
 This program and the accompanying materials 
 are licensed and made available under the terms and conditions of the BSD 
License 
 which accompanies this distribution.  The full text of the license may be 
found at 
@@ -736,7 +736,7 @@ PeimEntryMA (
 
   if (CompareGuid (PcdGetPtr(PcdTpmInstanceGuid), 
) ||
   CompareGuid (PcdGetPtr(PcdTpmInstanceGuid), 
)){
-DEBUG ((EFI_D_ERROR, "No TPM2 instance required!\n"));
+DEBUG ((DEBUG_INFO, "No TPM2 instance required!\n"));
 return EFI_UNSUPPORTED;
   }
 
diff --git a/SecurityPkg/Tcg/TrEEDxe/TrEEDxe.c 
b/SecurityPkg/Tcg/TrEEDxe/TrEEDxe.c
index fb69fa1..95e9d74 100644
--- a/SecurityPkg/Tcg/TrEEDxe/TrEEDxe.c
+++ b/SecurityPkg/Tcg/TrEEDxe/TrEEDxe.c
@@ -1,7 +1,7 @@
 /** @file
   This module implements TrEE Protocol.
   
-Copyright (c) 2013 - 2016, Intel Corporation. All rights

[edk2] [PATCH 3/3] UefiCpuPkg: Error Level is not used correctly

2017-04-10 Thread Jeff Fan

Cc: Feng Tian 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/CpuDxe/CpuPageTable.c  |  2 +-
 UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c | 68 +++
 2 files changed, 35 insertions(+), 35 deletions(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c b/UefiCpuPkg/CpuDxe/CpuPageTable.c
index ab664b4..2c61e75 100644
--- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
+++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
@@ -634,10 +634,10 @@ ConvertMemoryPageAttributes (
   switch(CurrentPagingContext.MachineType) {
   case IMAGE_FILE_MACHINE_I386:
 if (CurrentPagingContext.ContextData.Ia32.PageTableBase == 0) {
-  DEBUG ((DEBUG_ERROR, "PageTable is 0!\n"));
   if (Attributes == 0) {
 return EFI_SUCCESS;
   } else {
+DEBUG ((DEBUG_ERROR, "PageTable is 0!\n"));
 return EFI_UNSUPPORTED;
   }
 }
diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c 
b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
index a9d1042..e53ed21 100644
--- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
+++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
@@ -4,7 +4,7 @@
   This module will execute the boot script saved during last boot and after 
that,
   control is passed to OS waking up handler.
 
-  Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
   Copyright (c) 2017, AMD Incorporated. All rights reserved.
 
   This program and the accompanying materials
@@ -531,7 +531,7 @@ S3ResumeBootOs (
   //
   // X64 long mode waking vector
   //
-  DEBUG (( EFI_D_ERROR, "Transfer to 64bit OS waking vector - %x\r\n", 
(UINTN)Facs->XFirmwareWakingVector));
+  DEBUG ((DEBUG_INFO, "Transfer to 64bit OS waking vector - %x\r\n", 
(UINTN)Facs->XFirmwareWakingVector));
   if (FeaturePcdGet (PcdDxeIplSwitchToLongMode)) {
 AsmEnablePaging64 (
   0x38,
@@ -557,7 +557,7 @@ S3ResumeBootOs (
   //
   // IA32 protected mode waking vector (Page disabled)
   //
-  DEBUG (( EFI_D_ERROR, "Transfer to 32bit OS waking vector - %x\r\n", 
(UINTN)Facs->XFirmwareWakingVector));
+  DEBUG ((DEBUG_INFO, "Transfer to 32bit OS waking vector - %x\r\n", 
(UINTN)Facs->XFirmwareWakingVector));
   SwitchStack (
 (SWITCH_STACK_ENTRY_POINT) (UINTN) Facs->XFirmwareWakingVector,
 NULL,
@@ -569,7 +569,7 @@ S3ResumeBootOs (
 //
 // 16bit Realmode waking vector
 //
-DEBUG (( EFI_D_ERROR, "Transfer to 16bit OS waking vector - %x\r\n", 
(UINTN)Facs->FirmwareWakingVector));
+DEBUG ((DEBUG_INFO, "Transfer to 16bit OS waking vector - %x\r\n", 
(UINTN)Facs->FirmwareWakingVector));
 AsmTransferControl (Facs->FirmwareWakingVector, 0x0);
   }
 
@@ -630,7 +630,7 @@ RestoreS3PageTables (
 //
 // The assumption is : whole page table is allocated in CONTINUOUS memory 
and CR3 points to TOP page.
 //
-DEBUG ((EFI_D_ERROR, "S3NvsPageTableAddress - %x (%x)\n", 
(UINTN)S3NvsPageTableAddress, (UINTN)Build4GPageTableOnly));
+DEBUG ((DEBUG_INFO, "S3NvsPageTableAddress - %x (%x)\n", 
(UINTN)S3NvsPageTableAddress, (UINTN)Build4GPageTableOnly));
 
 //
 // By architecture only one PageMapLevel4 exists - so lets allocate 
storage for it.
@@ -783,7 +783,7 @@ S3ResumeExecuteBootScript (
   PEI_S3_RESUME_STATE*PeiS3ResumeState;
   BOOLEANInterruptStatus;
 
-  DEBUG ((EFI_D_ERROR, "S3ResumeExecuteBootScript()\n"));
+  DEBUG ((DEBUG_INFO, "S3ResumeExecuteBootScript()\n"));
 
   //
   // Attempt to use content from SMRAM first
@@ -810,13 +810,13 @@ S3ResumeExecuteBootScript (
   (VOID **) 
   );
 if (!EFI_ERROR (Status)) {
-  DEBUG ((EFI_D_ERROR, "Close all SMRAM regions before executing boot 
script\n"));
+  DEBUG ((DEBUG_INFO, "Close all SMRAM regions before executing boot 
script\n"));
   
   for (Index = 0, Status = EFI_SUCCESS; !EFI_ERROR (Status); Index++) {
 Status = SmmAccess->Close ((EFI_PEI_SERVICES 
**)GetPeiServicesTablePointer (), SmmAccess, Index);
   }
 
-  DEBUG ((EFI_D_ERROR, "Lock all SMRAM regions before executing boot 
script\n"));
+  DEBUG ((DEBUG_INFO, "Lock all SMRAM regions before executing boot 
script\n"));
   
   for (Index = 0, Status = EFI_SUCCESS; !EFI_ERROR (Status); Index++) {
 Status = SmmAccess->Lock ((EFI_PEI_SERVICES 
**)GetPeiServicesTablePointer (), SmmAccess, Index);
@@ -881,7 +881,7 @@ S3ResumeExecuteBootScript (
   );
 ASSERT (FALSE);
   }
-  DEBUG (( EFI_D_ERROR, "PeiS3ResumeState - %x\r\n", PeiS3ResumeState));
+  DEBUG ((DEBUG_INFO, "PeiS3ResumeState - %x\r\n", PeiS3ResumeState));
   PeiS3ResumeState->ReturnCs   = 0x10;
   PeiS3ResumeState->ReturnEntryPoint   = 
(EFI_PHYSICAL_ADDRESS)(UINTN)S3ResumeBootOs;

[edk2] [PATCH] MdeModulePkg/DxeCore: Add ASSERT to ensure no subtract underflow

2017-04-10 Thread Hao Wu

For function SplitRecord() in file PropertiesTable.c, there is a
potential subtract underflow case for line:

  return TotalNewRecordCount - 1;

However, such case will not happen since the logic in function
SplitTable() ensure that when calling SplitRecord(), the variable
'TotalNewRecordCount' will not be zero when performing the subtraction.
It will be handled in the previous if statement:

  if (MaxSplitRecordCount == 0) {
CopyMem (NewRecord, OldRecord, DescriptorSize);
return 0;
  }

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c 
b/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
index e7c4a95712..6cf5edcbe5 100644
--- a/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
+++ b/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
@@ -576,6 +576,11 @@ SplitRecord (
 TempRecord.NumberOfPages = EfiSizeToPages (PhysicalEnd - PhysicalStart);
   } while ((ImageRecord != NULL) && (PhysicalStart < PhysicalEnd));
 
+  //
+  // The logic in function SplitTable() ensures that TotalNewRecordCount will 
not be zero if the
+  // code reaches here.
+  //
+  ASSERT (TotalNewRecordCount != 0);
   return TotalNewRecordCount - 1;
 }
 
-- 
2.12.0.windows.1

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

40 matches

Mail list logo