date:20160511

Re: [edk2] [PATCH] OvmfPkg/PlatformBootManagerLib: Postpone the shell registration

2016-05-11 Thread Ni, Ruiyu



Reviewed-by: Ruiyu Ni 



Regards,
Ray

>-Original Message-
>From: Laszlo Ersek [mailto:ler...@redhat.com]
>Sent: Wednesday, May 11, 2016 6:28 PM
>To: Gary Lin ; edk2-de...@ml01.01.org
>Cc: Justen, Jordan L ; Ni, Ruiyu 
>
>Subject: Re: [PATCH] OvmfPkg/PlatformBootManagerLib: Postpone the shell 
>registration
>
>On 05/11/16 10:40, Gary Lin wrote:
>> We currently register the shell before creating the boot options for
>> the block devices and the network devices, so the boot manager boots
>> into the internal shell if the user doesn't specify the boot order.
>> However, Xen doesn't support fw_cfg, so there is no way to change the
>> boot order with the external command, and the firmware will always
>> boot into the internal shell if the user doesn't interfere the boot
>> process.
>>
>> This patch postpones the shell registration after MdeModulePkg/BDS
>> creates all the boot options for the block and network devices, so
>> that firmware will try to boot the block/network devices first.
>>
>> Cc: Laszlo Ersek 
>> Cc: Jordan Justen 
>> Cc: Ruiyu Ni 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Gary Lin 
>> ---
>>  OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 13 +++--
>>  1 file changed, 7 insertions(+), 6 deletions(-)
>>
>> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
>b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
>> index cf774a1..a16453d 100644
>> --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
>> +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
>> @@ -184,12 +184,6 @@ PlatformRegisterOptionsAndKeys (
>>   NULL, (UINT16) BootOption.OptionNumber, 0, , NULL
>>   );
>>ASSERT (Status == EFI_SUCCESS || Status == EFI_ALREADY_STARTED);
>> -  //
>> -  // Register UEFI Shell
>> -  //
>> -  PlatformRegisterFvBootOption (
>> -PcdGetPtr (PcdShellFile), L"EFI Internal Shell", LOAD_OPTION_ACTIVE
>> -);
>>  }
>>
>>  EFI_STATUS
>> @@ -1304,6 +1298,13 @@ Routine Description:
>>
>>EfiBootManagerRefreshAllBootOption ();
>>
>> +  //
>> +  // Register UEFI Shell
>> +  //
>> +  PlatformRegisterFvBootOption (
>> +PcdGetPtr (PcdShellFile), L"EFI Internal Shell", LOAD_OPTION_ACTIVE
>> +);
>> +
>>SetBootOrderFromQemu (NULL);
>>  }
>>
>>
>
>Looks good to me:
>
>Reviewed-by: Laszlo Ersek 
>
>I'd also like to get an R-b from Ray, before committing the patch.
>
>Thanks!
>Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] BaseTools: Add HII definitions from UEFI 2.6

2016-05-11 Thread Bi, Dandan

A minor comment:
There are some whitespace in the line " typedef struct _EFI_HII_IIBT_PNG_BLOCK 
{  " and the line below " (C) Copyright 2016 Hewlett Packard Enterprise 
Development LP ".
Please remove them when commit the patch. You can use the patch check tool 
(BaseTools\Scripts\PatchCheck.py) to check the patch.

Others are good to me.
Reviewed-by: Dandan Bi 

Thanks,
Dandan

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Samer 
El-Haj-Mahmoud
Sent: Thursday, May 12, 2016 4:29 AM
To: edk2-devel@lists.01.org
Cc: Samer El-Haj-Mahmoud ; Gao, Liming 
Subject: [edk2] [PATCH] BaseTools: Add HII definitions from UEFI 2.6

Add HII definitions from UEFI 2.6 for HII Image Variability and PNG Blocks

Cc: Yonghong Zhu 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
---
 .../Common/UefiInternalFormRepresentation.h| 24 ++
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/BaseTools/Source/C/Include/Common/UefiInternalFormRepresentation.h 
b/BaseTools/Source/C/Include/Common/UefiInternalFormRepresentation.h
index 8c2edf2..4b585fd 100644
--- a/BaseTools/Source/C/Include/Common/UefiInternalFormRepresentation.h
+++ b/BaseTools/Source/C/Include/Common/UefiInternalFormRepresentation.h
@@ -3,11 +3,9 @@
   IFR is primarily consumed by the EFI presentation engine, and produced by EFI
   internal application and drivers as well as all add-in card option-ROM 
drivers
 
-  @par Revision Reference:
-  These definitions are from UEFI2.1.
-
   Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
-
+ (C) Copyright 2016 Hewlett Packard Enterprise Development LP
+ 
   This program and the accompanying materials are licensed and made available
   under the terms and conditions of the BSD License which accompanies this
   distribution.  The full text of the license may be found at @@ -16,6 +14,9 @@
   THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
   WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 
+  @par Revision Reference:
+  These definitions are from UEFI 2.6
+
 **/
 
 #ifndef __UEFI_INTERNAL_FORMREPRESENTATION_H__
@@ -167,6 +168,7 @@ typedef struct _EFI_HII_FONT_PACKAGE_HDR {
 #define EFI_HII_GIBT_GLYPHS   0x11
 #define EFI_HII_GIBT_GLYPH_DEFAULT0x12
 #define EFI_HII_GIBT_GLYPHS_DEFAULT   0x13
+#define EFI_HII_GIBT_GLYPH_VARIABILITY0x14
 #define EFI_HII_GIBT_DUPLICATE0x20
 #define EFI_HII_GIBT_SKIP20x21
 #define EFI_HII_GIBT_SKIP10x22
@@ -235,6 +237,13 @@ typedef struct _EFI_HII_GIBT_GLYPHS_DEFAULT_BLOCK {
   UINT8  BitmapData[1]; // the number of bytes per bitmap can 
be calculated by ((Global.Cell.Width+7)/8)*Global.Cell.Height
 } EFI_HII_GIBT_GLYPHS_DEFAULT_BLOCK;
 
+typedef struct _EFI_HII_GIBT_VARIABILITY_BLOCK {
+  EFI_HII_GLYPH_BLOCKHeader;
+  EFI_HII_GLYPH_INFO Cell;
+  UINT8  GlyphPackInBits;
+  UINT8  BitmapData [1];
+} EFI_HII_GIBT_VARIABILITY_BLOCK;
+
 typedef struct _EFI_HII_GIBT_SKIP1_BLOCK {
   EFI_HII_GLYPH_BLOCKHeader;
   UINT8  SkipCount;
@@ -416,6 +425,7 @@ typedef struct _EFI_HII_IMAGE_BLOCK {
 #define EFI_HII_IIBT_IMAGE_24BIT   0x16
 #define EFI_HII_IIBT_IMAGE_24BIT_TRANS 0x17
 #define EFI_HII_IIBT_IMAGE_JPEG0x18
+#define EFI_HII_IIBT_IMAGE_PNG 0x19
 #define EFI_HII_IIBT_DUPLICATE 0x20
 #define EFI_HII_IIBT_SKIP2 0x21
 #define EFI_HII_IIBT_SKIP1 0x22
@@ -532,6 +542,12 @@ typedef struct _EFI_HII_IIBT_JPEG_BLOCK {
   UINT8Data[1];
 } EFI_HII_IIBT_JPEG_BLOCK;
 
+typedef struct _EFI_HII_IIBT_PNG_BLOCK {
+  EFI_HII_IMAGE_BLOCK  Header;
+  UINT32   Size;
+  UINT8Data[1];
+} EFI_HII_IIBT_PNG_BLOCK;
+
 typedef struct _EFI_HII_IIBT_SKIP1_BLOCK {
   EFI_HII_IMAGE_BLOCK  Header;
   UINT8SkipCount;
--
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] MdePkg: Add HII definitions from UEFI 2.6

2016-05-11 Thread Gao, Liming

Reviewed-by: Liming Gao 

> -Original Message-
> From: Bi, Dandan
> Sent: Thursday, May 12, 2016 10:50 AM
> To: Samer El-Haj-Mahmoud ; edk2-
> de...@lists.01.org
> Cc: Kinney, Michael D ; Samer El-Haj-
> Mahmoud ; Gao, Liming 
> Subject: RE: [edk2] [PATCH] MdePkg: Add HII definitions from UEFI 2.6
> 
> Reviewed-by: Dandan Bi 
> 
> Thanks,
> Dandan
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Samer El-Haj-Mahmoud
> Sent: Thursday, May 12, 2016 4:31 AM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Samer El-Haj-
> Mahmoud ; Gao, Liming 
> Subject: [edk2] [PATCH] MdePkg: Add HII definitions from UEFI 2.6
> 
> Add HII definitions from UEFI 2.6 for HII Image Variability and PNG Blocks
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Samer El-Haj-Mahmoud 
> ---
>  MdePkg/Include/Uefi/UefiInternalFormRepresentation.h | 16
> 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
> b/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
> index 1a77ea7..4ac 100644
> --- a/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
> +++ b/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
> @@ -4,6 +4,7 @@
>internal application and drivers as well as all add-in card option-ROM 
> drivers
> 
>  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
> +(C) Copyright 2016 Hewlett Packard Enterprise Development LP
>  This program and the accompanying materials are licensed and made
> available under  the terms and conditions of the BSD License that
> accompanies this distribution.
>  The full text of the license may be found at @@ -209,6 +210,7 @@ typedef
> struct _EFI_HII_FONT_PACKAGE_HDR {
>  #define EFI_HII_GIBT_GLYPHS   0x11
>  #define EFI_HII_GIBT_GLYPH_DEFAULT0x12
>  #define EFI_HII_GIBT_GLYPHS_DEFAULT   0x13
> +#define EFI_HII_GIBT_GLYPH_VARIABILITY0x14
>  #define EFI_HII_GIBT_DUPLICATE0x20
>  #define EFI_HII_GIBT_SKIP20x21
>  #define EFI_HII_GIBT_SKIP10x22
> @@ -281,6 +283,13 @@ typedef struct
> _EFI_HII_GIBT_GLYPHS_DEFAULT_BLOCK {
>UINT8  BitmapData[1];
>  } EFI_HII_GIBT_GLYPHS_DEFAULT_BLOCK;
> 
> +typedef struct _EFI_HII_GIBT_VARIABILITY_BLOCK {
> +  EFI_HII_GLYPH_BLOCKHeader;
> +  EFI_HII_GLYPH_INFO Cell;
> +  UINT8  GlyphPackInBits;
> +  UINT8  BitmapData [1];
> +} EFI_HII_GIBT_VARIABILITY_BLOCK;
> +
>  typedef struct _EFI_HII_GIBT_SKIP1_BLOCK {
>EFI_HII_GLYPH_BLOCKHeader;
>UINT8  SkipCount;
> @@ -489,6 +498,7 @@ typedef struct _EFI_HII_IMAGE_BLOCK {
>  #define EFI_HII_IIBT_IMAGE_24BIT   0x16
>  #define EFI_HII_IIBT_IMAGE_24BIT_TRANS 0x17
>  #define EFI_HII_IIBT_IMAGE_JPEG0x18
> +#define EFI_HII_IIBT_IMAGE_PNG 0x19
>  #define EFI_HII_IIBT_DUPLICATE 0x20
>  #define EFI_HII_IIBT_SKIP2 0x21
>  #define EFI_HII_IIBT_SKIP1 0x22
> @@ -609,6 +619,12 @@ typedef struct _EFI_HII_IIBT_JPEG_BLOCK {
>UINT8Data[1];
>  } EFI_HII_IIBT_JPEG_BLOCK;
> 
> +typedef struct _EFI_HII_IIBT_PNG_BLOCK {
> +  EFI_HII_IMAGE_BLOCK  Header;
> +  UINT32   Size;
> +  UINT8Data[1];
> +} EFI_HII_IIBT_PNG_BLOCK;
> +
>  typedef struct _EFI_HII_IIBT_SKIP1_BLOCK {
>EFI_HII_IMAGE_BLOCK  Header;
>UINT8SkipCount;
> --
> 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] MdePkg: Add HII definitions from UEFI 2.6

2016-05-11 Thread Bi, Dandan

Reviewed-by: Dandan Bi 

Thanks,
Dandan
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Samer 
El-Haj-Mahmoud
Sent: Thursday, May 12, 2016 4:31 AM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D ; Samer El-Haj-Mahmoud 
; Gao, Liming 
Subject: [edk2] [PATCH] MdePkg: Add HII definitions from UEFI 2.6

Add HII definitions from UEFI 2.6 for HII Image Variability and PNG Blocks

Cc: Michael D Kinney 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
---
 MdePkg/Include/Uefi/UefiInternalFormRepresentation.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h 
b/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
index 1a77ea7..4ac 100644
--- a/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
+++ b/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
@@ -4,6 +4,7 @@
   internal application and drivers as well as all add-in card option-ROM 
drivers
 
 Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
+(C) Copyright 2016 Hewlett Packard Enterprise Development LP
 This program and the accompanying materials are licensed and made available 
under  the terms and conditions of the BSD License that accompanies this 
distribution.  
 The full text of the license may be found at @@ -209,6 +210,7 @@ typedef 
struct _EFI_HII_FONT_PACKAGE_HDR {
 #define EFI_HII_GIBT_GLYPHS   0x11
 #define EFI_HII_GIBT_GLYPH_DEFAULT0x12
 #define EFI_HII_GIBT_GLYPHS_DEFAULT   0x13
+#define EFI_HII_GIBT_GLYPH_VARIABILITY0x14
 #define EFI_HII_GIBT_DUPLICATE0x20
 #define EFI_HII_GIBT_SKIP20x21
 #define EFI_HII_GIBT_SKIP10x22
@@ -281,6 +283,13 @@ typedef struct _EFI_HII_GIBT_GLYPHS_DEFAULT_BLOCK {
   UINT8  BitmapData[1];
 } EFI_HII_GIBT_GLYPHS_DEFAULT_BLOCK;
 
+typedef struct _EFI_HII_GIBT_VARIABILITY_BLOCK {
+  EFI_HII_GLYPH_BLOCKHeader;
+  EFI_HII_GLYPH_INFO Cell;
+  UINT8  GlyphPackInBits;
+  UINT8  BitmapData [1];
+} EFI_HII_GIBT_VARIABILITY_BLOCK;
+
 typedef struct _EFI_HII_GIBT_SKIP1_BLOCK {
   EFI_HII_GLYPH_BLOCKHeader;
   UINT8  SkipCount;
@@ -489,6 +498,7 @@ typedef struct _EFI_HII_IMAGE_BLOCK {
 #define EFI_HII_IIBT_IMAGE_24BIT   0x16
 #define EFI_HII_IIBT_IMAGE_24BIT_TRANS 0x17
 #define EFI_HII_IIBT_IMAGE_JPEG0x18
+#define EFI_HII_IIBT_IMAGE_PNG 0x19
 #define EFI_HII_IIBT_DUPLICATE 0x20
 #define EFI_HII_IIBT_SKIP2 0x21
 #define EFI_HII_IIBT_SKIP1 0x22
@@ -609,6 +619,12 @@ typedef struct _EFI_HII_IIBT_JPEG_BLOCK {
   UINT8Data[1];
 } EFI_HII_IIBT_JPEG_BLOCK;
 
+typedef struct _EFI_HII_IIBT_PNG_BLOCK {
+  EFI_HII_IMAGE_BLOCK  Header;
+  UINT32   Size;
+  UINT8Data[1];
+} EFI_HII_IIBT_PNG_BLOCK;
+
 typedef struct _EFI_HII_IIBT_SKIP1_BLOCK {
   EFI_HII_IMAGE_BLOCK  Header;
   UINT8SkipCount;
--
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 0/6] ATA PassThru & SATA device path PortMultiplier update

2016-05-11 Thread Tian, Feng

Looks good to me

Reviewed-by: Feng Tian 

Thanks
Feng

-Original Message-
From: Wu, Hao A 
Sent: Tuesday, May 10, 2016 10:25 AM
To: edk2-devel@lists.01.org; Tian, Feng 
Cc: Wu, Hao A 
Subject: [PATCH v2 0/6] ATA PassThru & SATA device path PortMultiplier update

Changes compared with V1:
1. Update the commit log messages to reflect the correct UEFI spec version
   that the 'PortMultiplier' semantic change is introduced.

2. Update two OVMF library instances to adapt to the 'PortMultiplier'
   semantic change.

The UEFI 2.5 & 2.5 Errata spec updated the description of the port multiplier 
port number parameter in SATA Device Path Node and ATA Pass-Through Protocol.

Now, this parameter should be set to 0x instead of 0 to indicate that an 
ATA device is directly attached on the controller port.

Hao Wu (4):
  MdePkg Protocol/DevicePath.h: Update SATA Device Path comments
  MdePkg Protocol/AtaPassThru.h: Update PortMultiplierPort related
comments
  MdeModulePkg Ata: Use the new (incompatible) PortMultiplierPort
semantics
  MdeModulePkg AtaAtapiPassThru: Fix incorrect parameter description
comment

Laszlo Ersek (2):
  OvmfPkg/QemuNewBootOrderLib: adapt Q35 SATA PMPN to UEFI spec Mantis
1353
  OvmfPkg/QemuBootOrderLib: adapt Q35 SATA PMPN to UEFI spec Mantis 1353

 MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c   | 14 ++--
 .../Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c| 75 +-
 .../Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h| 12 ++--
 MdePkg/Include/Protocol/AtaPassThru.h  |  8 +--
 MdePkg/Include/Protocol/DevicePath.h   |  4 +-
 .../Library/QemuBootOrderLib/QemuBootOrderLib.c| 10 +--
 .../Library/QemuNewBootOrderLib/QemuBootOrderLib.c | 10 +--
 7 files changed, 88 insertions(+), 45 deletions(-)

--
1.9.5.msysgit.0

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

Re: [edk2] [PATCH 0/3] * Add Nvme.h and NvmExpressLib *

2016-05-11 Thread Tian, Feng

Hi, Darbin

As you know, we take extra caution on interface changes. We expect it's stable 
enough.

So I have the below questions:
1. I only see the NVME_ADMIN cmds are added, could you add NVME_IO cmds to 
Nvme.h as well?
2. Shall we be compliance with NVMe 1.2 spec to add missing cmds?
3. what's the role to introduce such NvmExpressLib library class? For example, 
why only Get Log/ Identify/ firmware download and activate APIs are added? Do 
we need add other cmd's wrapper to this new library? Do we need put it in 
MdeModulePkg or MdePkg?

Thanks
Feng

-Original Message-
From: darbin.emm.re...@hpe.com [mailto:darbin.emm.re...@hpe.com] 
Sent: Thursday, May 12, 2016 6:59 AM
To: edk2-devel@lists.01.org
Cc: Tian, Feng ; Zeng, Star ; Kinney, 
Michael D ; Gao, Liming ; 
samer.el-haj-mahm...@hpe.com; Darbin Reyes 
Subject: [PATCH 0/3] *** Add Nvme.h and NvmExpressLib ***

From: Darbin Reyes 

*** Add Nvme.h and NvmExpressLib ***

Darbin Reyes (3):
  MdePkg: Add a header for NVMe v1.1 spec. definitions.
  MdeModulePkg: Move/Replace NvmExpressHci.h definitions to Nvme.h.
  MdeModulePkg: Add NvmExpressLib.

 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h|   2 +
 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.h | 389 +
 MdeModulePkg/Include/Library/NvmExpressLib.h   | 279 +
 .../Library/DxeNvmExpressLib/DxeNvmExpressLib.c| 637 +
 .../Library/DxeNvmExpressLib/DxeNvmExpressLib.inf  |  41 ++
 MdeModulePkg/MdeModulePkg.dec  |   4 +
 MdePkg/Include/IndustryStandard/Nvme.h | 603 +++
 7 files changed, 1568 insertions(+), 387 deletions(-)  create mode 100644 
MdeModulePkg/Include/Library/NvmExpressLib.h
 create mode 100644 MdeModulePkg/Library/DxeNvmExpressLib/DxeNvmExpressLib.c
 create mode 100644 MdeModulePkg/Library/DxeNvmExpressLib/DxeNvmExpressLib.inf
 create mode 100644 MdePkg/Include/IndustryStandard/Nvme.h

--
1.7.11.msysgit.1

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

Re: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Handle HTTPS indefinite poll case

2016-05-11 Thread Ye, Ting

Looks good to me.
Reviewed-by: Ye Ting  

-Original Message-
From: Wu, Jiaxin 
Sent: Thursday, May 12, 2016 8:19 AM
To: samer.el-haj-mahm...@hpe.com; edk2-devel@lists.01.org
Cc: Ye, Ting ; Fu, Siyuan ; Long, Qin 

Subject: RE: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Handle HTTPS 
indefinite poll case

Hi all,

Any comments for this patch?

Thanks.
Jiaxin

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Jiaxin Wu
> Sent: Wednesday, May 4, 2016 3:08 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; 
> Long, Qin 
> Subject: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Handle HTTPS 
> indefinite poll case
> 
> This patch is used to handle handle HTTPS indefinite poll case.
> 
> Cc: El-Haj-Mahmoud Samer 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Cc: Long Qin 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiaxin Wu 
> ---
>  NetworkPkg/HttpDxe/HttpImpl.c  | 55 
> ++
>  NetworkPkg/HttpDxe/HttpProto.c | 68
> ++
>  2 files changed, 93 insertions(+), 30 deletions(-)
> 
> diff --git a/NetworkPkg/HttpDxe/HttpImpl.c 
> b/NetworkPkg/HttpDxe/HttpImpl.c index cf58b13..cd8fe05 100644
> --- a/NetworkPkg/HttpDxe/HttpImpl.c
> +++ b/NetworkPkg/HttpDxe/HttpImpl.c
> @@ -1179,47 +1179,50 @@ HttpResponseWorker (
>  }
>}
> 
>ASSERT (HttpInstance->MsgParser != NULL);
> 
> -  //
> -  // We still need receive more data when there is no cache data and 
> MsgParser is not NULL;
> -  //
> -  if (!HttpInstance->UseHttps) {
> -if (HttpInstance->TimeoutEvent == NULL) {
> -  //
> -  // Create TimeoutEvent for response
> -  //
> -  Status = gBS->CreateEvent (
> -  EVT_TIMER,
> -  TPL_CALLBACK,
> -  NULL,
> -  NULL,
> -  >TimeoutEvent
> -  );
> -  if (EFI_ERROR (Status)) {
> -goto Error;
> -  }
> -}
> -
> +  if (HttpInstance->TimeoutEvent == NULL) {
>  //
> -// Start the timer, and wait Timeout seconds to receive the body packet.
> +// Create TimeoutEvent for response
>  //
> -Status = gBS->SetTimer (HttpInstance->TimeoutEvent, TimerRelative,
> HTTP_RESPONSE_TIMEOUT * TICKS_PER_SECOND);
> +Status = gBS->CreateEvent (
> +EVT_TIMER,
> +TPL_CALLBACK,
> +NULL,
> +NULL,
> +>TimeoutEvent
> +);
>  if (EFI_ERROR (Status)) {
>goto Error;
>  }
> -
> +  }
> +
> +  //
> +  // Start the timer, and wait Timeout seconds to receive the body packet.
> +  //
> +  Status = gBS->SetTimer (HttpInstance->TimeoutEvent, TimerRelative, 
> + HTTP_RESPONSE_TIMEOUT * TICKS_PER_SECOND);  if (EFI_ERROR (Status))
> {
> +goto Error;
> +  }
> +
> +  //
> +  // We still need receive more data when there is no cache data and 
> + MsgParser is not NULL;  //  if (!HttpInstance->UseHttps) {
>  Status = HttpTcpReceiveBody (Wrap, HttpMsg, HttpInstance-
> >TimeoutEvent);
> 
>  gBS->SetTimer (HttpInstance->TimeoutEvent, TimerCancel, 0);
> 
>  if (EFI_ERROR (Status)) {
>goto Error;
>  }
>} else {
> -Status = HttpsReceive (HttpInstance, , NULL);
> +Status = HttpsReceive (HttpInstance, ,
> + HttpInstance->TimeoutEvent);
> +
> +gBS->SetTimer (HttpInstance->TimeoutEvent, TimerCancel, 0);
> +
>  if (EFI_ERROR (Status)) {
>goto Error;
>  }
> 
>  //
> @@ -1315,11 +1318,13 @@ Exit:
> 
>  Error2:
>NetMapInsertHead (>TxTokens, ValueInItem->HttpToken, 
> ValueInItem);
> 
>  Error:
> -  HttpTcpTokenCleanup (Wrap);
> +  if (!HttpInstance->UseHttps) {
> +HttpTcpTokenCleanup (Wrap);
> +  }
> 
>if (HttpHeaders != NULL) {
>  FreePool (HttpHeaders);
>  HttpHeaders = NULL;
>}
> diff --git a/NetworkPkg/HttpDxe/HttpProto.c 
> b/NetworkPkg/HttpDxe/HttpProto.c index 965a49f..ebb9dd9 100644
> --- a/NetworkPkg/HttpDxe/HttpProto.c
> +++ b/NetworkPkg/HttpDxe/HttpProto.c
> @@ -1230,11 +1230,40 @@ HttpConnectTcp4 (
> 
>//
>// Tls session connection.
>//
>if (HttpInstance->UseHttps) {
> -Status = TlsConnectSession (HttpInstance, NULL);
> +if (HttpInstance->TimeoutEvent == NULL) {
> +  //
> +  // Create TimeoutEvent for TLS connection.
> +  //
> +  Status = gBS->CreateEvent (
> +  EVT_TIMER,
> +  TPL_CALLBACK,
> +  NULL,
> +  NULL,
> +  >TimeoutEvent
> +  );
> +  if (EFI_ERROR (Status)) {
> +TlsCloseTxRxEvent

Re: [edk2] [patch] NetworkPkg: Bug fix of iSCSI to support MPIO

2016-05-11 Thread Wu, Jiaxin

Reviewed-By: Wu Jiaxin 


> -Original Message-
> From: Zhang, Lubo
> Sent: Wednesday, May 11, 2016 9:38 AM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; Wu,
> Jiaxin 
> Subject: [patch] NetworkPkg: Bug fix of iSCSI to support MPIO
> 
> If two attempts added on different NIC and enable MPIO attribute, then
> change the attempts order. If both two attempts succeed to connect the
> target,it should abort the later one in the order and uninstall
> ExtScsiPassThruProtocol Interface, But now it unistall it twice.
> 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Cc: Wu Jiaxin 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Zhang Lubo 
> ---
>  NetworkPkg/IScsiDxe/IScsiDriver.c | 18 +++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/NetworkPkg/IScsiDxe/IScsiDriver.c
> b/NetworkPkg/IScsiDxe/IScsiDriver.c
> index 12095cb..5a121ce 100644
> --- a/NetworkPkg/IScsiDxe/IScsiDriver.c
> +++ b/NetworkPkg/IScsiDxe/IScsiDriver.c
> @@ -863,14 +863,26 @@ IScsiStart (
>  IScsiRemoveNic (ExistPrivate->Controller);
>  if (ExistPrivate->Session != NULL) {
>IScsiSessionAbort (ExistPrivate->Session);
>  }
> 
> -Status = IScsiCleanDriverData (ExistPrivate);
> -if (EFI_ERROR (Status)) {
> -  goto ON_ERROR;
> +if (ExistPrivate->DevicePath != NULL) {
> +  Status = gBS->UninstallProtocolInterface (
> +  ExistPrivate->ExtScsiPassThruHandle,
> +  ,
> +  ExistPrivate->DevicePath
> +  );
> +  if (EFI_ERROR (Status)) {
> +goto ON_ERROR;
> +  }
> +
> +  FreePool (ExistPrivate->DevicePath);
>  }
> +
> +gBS->CloseEvent (ExistPrivate->ExitBootServiceEvent);
> +FreePool (ExistPrivate);
> +
>}
>  } else {
>//
>// Use the attempt in earlier order as boot selected in single path 
> mode.
>//
> --
> 1.9.5.msysgit.1

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

Re: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Handle HTTPS indefinite poll case

2016-05-11 Thread Fu, Siyuan

The patch is good to me.

Reviewed-by: Fu Siyuan 

From: Wu, Jiaxin
Sent: Thursday, May 12, 2016 8:19 AM
To: samer.el-haj-mahm...@hpe.com; edk2-devel@lists.01.org
Cc: Ye, Ting ; Fu, Siyuan ; Long, Qin 

Subject: RE: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Handle HTTPS 
indefinite poll case

Hi all,

Any comments for this patch?

Thanks.
Jiaxin

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jiaxin Wu
> Sent: Wednesday, May 4, 2016 3:08 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting >; Fu, Siyuan 
> >; Long,
> Qin >
> Subject: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Handle HTTPS
> indefinite poll case
>
> This patch is used to handle handle HTTPS indefinite poll case.
>
> Cc: El-Haj-Mahmoud Samer 
> >
> Cc: Ye Ting >
> Cc: Fu Siyuan >
> Cc: Long Qin >
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiaxin Wu >
> ---
>  NetworkPkg/HttpDxe/HttpImpl.c  | 55 ++
>  NetworkPkg/HttpDxe/HttpProto.c | 68
> ++
>  2 files changed, 93 insertions(+), 30 deletions(-)
>
> diff --git a/NetworkPkg/HttpDxe/HttpImpl.c
> b/NetworkPkg/HttpDxe/HttpImpl.c index cf58b13..cd8fe05 100644
> --- a/NetworkPkg/HttpDxe/HttpImpl.c
> +++ b/NetworkPkg/HttpDxe/HttpImpl.c
> @@ -1179,47 +1179,50 @@ HttpResponseWorker (
>  }
>}
>
>ASSERT (HttpInstance->MsgParser != NULL);
>
> -  //
> -  // We still need receive more data when there is no cache data and
> MsgParser is not NULL;
> -  //
> -  if (!HttpInstance->UseHttps) {
> -if (HttpInstance->TimeoutEvent == NULL) {
> -  //
> -  // Create TimeoutEvent for response
> -  //
> -  Status = gBS->CreateEvent (
> -  EVT_TIMER,
> -  TPL_CALLBACK,
> -  NULL,
> -  NULL,
> -  >TimeoutEvent
> -  );
> -  if (EFI_ERROR (Status)) {
> -goto Error;
> -  }
> -}
> -
> +  if (HttpInstance->TimeoutEvent == NULL) {
>  //
> -// Start the timer, and wait Timeout seconds to receive the body packet.
> +// Create TimeoutEvent for response
>  //
> -Status = gBS->SetTimer (HttpInstance->TimeoutEvent, TimerRelative,
> HTTP_RESPONSE_TIMEOUT * TICKS_PER_SECOND);
> +Status = gBS->CreateEvent (
> +EVT_TIMER,
> +TPL_CALLBACK,
> +NULL,
> +NULL,
> +>TimeoutEvent
> +);
>  if (EFI_ERROR (Status)) {
>goto Error;
>  }
> -
> +  }
> +
> +  //
> +  // Start the timer, and wait Timeout seconds to receive the body packet.
> +  //
> +  Status = gBS->SetTimer (HttpInstance->TimeoutEvent, TimerRelative,
> + HTTP_RESPONSE_TIMEOUT * TICKS_PER_SECOND);  if (EFI_ERROR (Status))
> {
> +goto Error;
> +  }
> +
> +  //
> +  // We still need receive more data when there is no cache data and
> + MsgParser is not NULL;  //  if (!HttpInstance->UseHttps) {
>  Status = HttpTcpReceiveBody (Wrap, HttpMsg, HttpInstance-
> >TimeoutEvent);
>
>  gBS->SetTimer (HttpInstance->TimeoutEvent, TimerCancel, 0);
>
>  if (EFI_ERROR (Status)) {
>goto Error;
>  }
>} else {
> -Status = HttpsReceive (HttpInstance, , NULL);
> +Status = HttpsReceive (HttpInstance, ,
> + HttpInstance->TimeoutEvent);
> +
> +gBS->SetTimer (HttpInstance->TimeoutEvent, TimerCancel, 0);
> +
>  if (EFI_ERROR (Status)) {
>goto Error;
>  }
>
>  //
> @@ -1315,11 +1318,13 @@ Exit:
>
>  Error2:
>NetMapInsertHead (>TxTokens, ValueInItem->HttpToken,
> ValueInItem);
>
>  Error:
> -  HttpTcpTokenCleanup (Wrap);
> +  if (!HttpInstance->UseHttps) {
> +HttpTcpTokenCleanup (Wrap);
> +  }
>
>if (HttpHeaders != NULL) {
>  FreePool (HttpHeaders);
>  HttpHeaders = NULL;
>}
> diff --git a/NetworkPkg/HttpDxe/HttpProto.c
> b/NetworkPkg/HttpDxe/HttpProto.c index 965a49f..ebb9dd9 100644
> --- a/NetworkPkg/HttpDxe/HttpProto.c
> +++ b/NetworkPkg/HttpDxe/HttpProto.c
> @@ -1230,11 +1230,40 @@ HttpConnectTcp4 (
>
>//
>// Tls session connection.
>//
>if (HttpInstance->UseHttps) {
> -Status = TlsConnectSession (HttpInstance, NULL);
> +if (HttpInstance->TimeoutEvent == NULL) {
> +  //
> +  // Create TimeoutEvent for TLS connection.
> +  //
> +  Status = gBS->CreateEvent (
> +  EVT_TIMER,
> +

Re: [edk2] [PATCH 0/3] * Add Nvme.h and NvmExpressLib *

2016-05-11 Thread El-Haj-Mahmoud, Samer

Series Reviewed-By : Samer El-Haj-Mahmoud 



-Original Message-
From: Reyes, Darbin [darbin.emm.re...@hpe.com]
Received: Wednesday, 11 May 2016, 6:07PM
To: edk2-devel@lists.01.org [edk2-devel@lists.01.org]
CC: feng.t...@intel.com [feng.t...@intel.com]; star.z...@intel.com 
[star.z...@intel.com]; michael.d.kin...@intel.com [michael.d.kin...@intel.com]; 
liming@intel.com [liming@intel.com]; El-Haj-Mahmoud, Samer 
[samer.el-haj-mahm...@hpe.com]; Reyes, Darbin [darbin.emm.re...@hpe.com]
Subject: [PATCH 0/3] *** Add Nvme.h and NvmExpressLib ***

From: Darbin Reyes 

*** Add Nvme.h and NvmExpressLib ***

Darbin Reyes (3):
  MdePkg: Add a header for NVMe v1.1 spec. definitions.
  MdeModulePkg: Move/Replace NvmExpressHci.h definitions to Nvme.h.
  MdeModulePkg: Add NvmExpressLib.

 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h|   2 +
 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.h | 389 +
 MdeModulePkg/Include/Library/NvmExpressLib.h   | 279 +
 .../Library/DxeNvmExpressLib/DxeNvmExpressLib.c| 637 +
 .../Library/DxeNvmExpressLib/DxeNvmExpressLib.inf  |  41 ++
 MdeModulePkg/MdeModulePkg.dec  |   4 +
 MdePkg/Include/IndustryStandard/Nvme.h | 603 +++
 7 files changed, 1568 insertions(+), 387 deletions(-)
 create mode 100644 MdeModulePkg/Include/Library/NvmExpressLib.h
 create mode 100644 MdeModulePkg/Library/DxeNvmExpressLib/DxeNvmExpressLib.c
 create mode 100644 MdeModulePkg/Library/DxeNvmExpressLib/DxeNvmExpressLib.inf
 create mode 100644 MdePkg/Include/IndustryStandard/Nvme.h

--
1.7.11.msysgit.1

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

Re: [edk2] [PATCH] SecurityPkg: Remove non-ASCII character from TPM warning strings

2016-05-11 Thread Zhang, Chao B

Reviewed-by: Chao Zhang 





Thanks & Best regards
Chao Zhang

-Original Message-
From: Samer El-Haj-Mahmoud [mailto:samer.el-haj-mahm...@hpe.com] 
Sent: Thursday, May 12, 2016 4:58 AM
To: edk2-devel@lists.01.org
Cc: samer.el-haj-mahm...@hpe.com; Zhang, Chao B; Samer El-Haj-Mahmoud
Subject: [PATCH] SecurityPkg: Remove non-ASCII character from TPM warning 
strings

Remove a non-ASCII apostrophe character from TPM_WARNING_MAINTAIN
message

Cc: Chao Zhang 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
---
 .../Library/DxeTcgPhysicalPresenceLib/PhysicalPresenceStrings.uni  | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git 
a/SecurityPkg/Library/DxeTcgPhysicalPresenceLib/PhysicalPresenceStrings.uni 
b/SecurityPkg/Library/DxeTcgPhysicalPresenceLib/PhysicalPresenceStrings.uni
index 00a09c1..065cd63 100644
--- a/SecurityPkg/Library/DxeTcgPhysicalPresenceLib/PhysicalPresenceStrings.uni
+++ b/SecurityPkg/Library/DxeTcgPhysicalPresenceLib/PhysicalPresenceStrings.uni
@@ -2,6 +2,7 @@
   String definitions for TPM 1.2 physical presence confirm text.
 
 Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.
+(C) Copyright 2016 Hewlett Packard Enterprise Development LP
 This program and the accompanying materials 
 are licensed and made available under the terms and conditions of the BSD 
License 
 which accompanies this distribution.  The full text of the license may be 
found at 
@@ -42,7 +43,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #string TPM_NO_PPI_MAINTAIN   #language en-US"maintain"
 #string TPM_NO_PPI_INFO   #language en-US"to approve future 
Operating System requests "
 
-#string TPM_WARNING_MAINTAIN  #language en-US"WARNING: Allowing 
changes to the TPM’s firmware may affect the operation of the TPM and may erase 
information stored on the TPM.\nYou may lose all created keys and access to 
data encrypted by these keys.\n\n"
+#string TPM_WARNING_MAINTAIN  #language en-US"WARNING: Allowing 
changes to the TPM's firmware may affect the operation of the TPM and may erase 
information stored on the TPM.\nYou may lose all created keys and access to 
data encrypted by these keys.\n\n"
 #string TPM_WARNING   #language en-US"WARNING: Doing so 
might prevent security applications that rely on the TPM from functioning as 
expected\n\n"
 #string TPM_WARNING_CLEAR #language en-US"WARNING: Clearing 
erases information stored on the TPM. You will lose all created keys and access 
to data encrypted by these keys. "
 #string TPM_WARNING_CLEAR_CONT#language en-US"Take ownership as 
soon as possible after this step.\n\n"
-- 
2.6.3.windows.1

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

Re: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Handle HTTPS indefinite poll case

2016-05-11 Thread Wu, Jiaxin

Thanks Samer. /Jiaxin

From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hpe.com]
Sent: Thursday, May 12, 2016 8:21 AM
To: edk2-devel@lists.01.org; Wu, Jiaxin 
Cc: Ye, Ting ; Fu, Siyuan ; Long, Qin 

Subject: RE: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Handle HTTPS 
indefinite poll case

Sorry for the delay Jiaxin. I don't see issues with this. I did pull it into 
our build and didn't find any regression.

Reviewed-by : Samer El-Haj-Mahmoud >




-Original Message-
From: Wu, Jiaxin [jiaxin...@intel.com]
Received: Wednesday, 11 May 2016, 7:18PM
To: El-Haj-Mahmoud, Samer [samer.el-haj-mahm...@hpe.com]; 
edk2-devel@lists.01.org 
[edk2-devel@lists.01.org]
CC: Ye, Ting [ting...@intel.com]; Fu, Siyuan [siyuan...@intel.com]; Long, Qin 
[qin.l...@intel.com]
Subject: RE: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Handle HTTPS 
indefinite poll case
Hi all,

Any comments for this patch?

Thanks.
Jiaxin

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jiaxin Wu
> Sent: Wednesday, May 4, 2016 3:08 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting >; Fu, Siyuan 
> >; Long,
> Qin >
> Subject: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Handle HTTPS
> indefinite poll case
>
> This patch is used to handle handle HTTPS indefinite poll case.
>
> Cc: El-Haj-Mahmoud Samer 
> >
> Cc: Ye Ting >
> Cc: Fu Siyuan >
> Cc: Long Qin >
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiaxin Wu >
> ---
>  NetworkPkg/HttpDxe/HttpImpl.c  | 55 ++
>  NetworkPkg/HttpDxe/HttpProto.c | 68
> ++
>  2 files changed, 93 insertions(+), 30 deletions(-)
>
> diff --git a/NetworkPkg/HttpDxe/HttpImpl.c
> b/NetworkPkg/HttpDxe/HttpImpl.c index cf58b13..cd8fe05 100644
> --- a/NetworkPkg/HttpDxe/HttpImpl.c
> +++ b/NetworkPkg/HttpDxe/HttpImpl.c
> @@ -1179,47 +1179,50 @@ HttpResponseWorker (
>  }
>}
>
>ASSERT (HttpInstance->MsgParser != NULL);
>
> -  //
> -  // We still need receive more data when there is no cache data and
> MsgParser is not NULL;
> -  //
> -  if (!HttpInstance->UseHttps) {
> -if (HttpInstance->TimeoutEvent == NULL) {
> -  //
> -  // Create TimeoutEvent for response
> -  //
> -  Status = gBS->CreateEvent (
> -  EVT_TIMER,
> -  TPL_CALLBACK,
> -  NULL,
> -  NULL,
> -  >TimeoutEvent
> -  );
> -  if (EFI_ERROR (Status)) {
> -goto Error;
> -  }
> -}
> -
> +  if (HttpInstance->TimeoutEvent == NULL) {
>  //
> -// Start the timer, and wait Timeout seconds to receive the body packet.
> +// Create TimeoutEvent for response
>  //
> -Status = gBS->SetTimer (HttpInstance->TimeoutEvent, TimerRelative,
> HTTP_RESPONSE_TIMEOUT * TICKS_PER_SECOND);
> +Status = gBS->CreateEvent (
> +EVT_TIMER,
> +TPL_CALLBACK,
> +NULL,
> +NULL,
> +>TimeoutEvent
> +);
>  if (EFI_ERROR (Status)) {
>goto Error;
>  }
> -
> +  }
> +
> +  //
> +  // Start the timer, and wait Timeout seconds to receive the body packet.
> +  //
> +  Status = gBS->SetTimer (HttpInstance->TimeoutEvent, TimerRelative,
> + HTTP_RESPONSE_TIMEOUT * TICKS_PER_SECOND);  if (EFI_ERROR (Status))
> {
> +goto Error;
> +  }
> +
> +  //
> +  // We still need receive more data when there is no cache data and
> + MsgParser is not NULL;  //  if (!HttpInstance->UseHttps) {
>  Status = HttpTcpReceiveBody (Wrap, HttpMsg, HttpInstance-
> >TimeoutEvent);
>
>  gBS->SetTimer (HttpInstance->TimeoutEvent, TimerCancel, 0);
>
>  if (EFI_ERROR (Status)) {
>goto Error;
>  }
>} else {
> -Status = HttpsReceive (HttpInstance, , NULL);
> +Status = HttpsReceive (HttpInstance, ,
> + HttpInstance->TimeoutEvent);
> +
> +gBS->SetTimer (HttpInstance->TimeoutEvent, TimerCancel, 0);
> +
>  if (EFI_ERROR (Status)) {
>goto Error;
>  }
>
>  //
> @@ -1315,11 +1318,13 @@ Exit:
>
>  Error2:
>NetMapInsertHead (>TxTokens, ValueInItem->HttpToken,
> ValueInItem);
>
>  Error:
> -  HttpTcpTokenCleanup (Wrap);
> +  if (!HttpInstance->UseHttps) {
> +HttpTcpTokenCleanup (Wrap);
> +  }
>
>if (HttpHeaders != NULL) {
>

Re: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Handle HTTPS indefinite poll case

2016-05-11 Thread El-Haj-Mahmoud, Samer

Sorry for the delay Jiaxin. I don't see issues with this. I did pull it into 
our build and didn't find any regression.

Reviewed-by : Samer El-Haj-Mahmoud 




-Original Message-
From: Wu, Jiaxin [jiaxin...@intel.com]
Received: Wednesday, 11 May 2016, 7:18PM
To: El-Haj-Mahmoud, Samer [samer.el-haj-mahm...@hpe.com]; 
edk2-devel@lists.01.org [edk2-devel@lists.01.org]
CC: Ye, Ting [ting...@intel.com]; Fu, Siyuan [siyuan...@intel.com]; Long, Qin 
[qin.l...@intel.com]
Subject: RE: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Handle HTTPS 
indefinite poll case

Hi all,

Any comments for this patch?

Thanks.
Jiaxin

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jiaxin Wu
> Sent: Wednesday, May 4, 2016 3:08 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; Long,
> Qin 
> Subject: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Handle HTTPS
> indefinite poll case
>
> This patch is used to handle handle HTTPS indefinite poll case.
>
> Cc: El-Haj-Mahmoud Samer 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Cc: Long Qin 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiaxin Wu 
> ---
>  NetworkPkg/HttpDxe/HttpImpl.c  | 55 ++
>  NetworkPkg/HttpDxe/HttpProto.c | 68
> ++
>  2 files changed, 93 insertions(+), 30 deletions(-)
>
> diff --git a/NetworkPkg/HttpDxe/HttpImpl.c
> b/NetworkPkg/HttpDxe/HttpImpl.c index cf58b13..cd8fe05 100644
> --- a/NetworkPkg/HttpDxe/HttpImpl.c
> +++ b/NetworkPkg/HttpDxe/HttpImpl.c
> @@ -1179,47 +1179,50 @@ HttpResponseWorker (
>  }
>}
>
>ASSERT (HttpInstance->MsgParser != NULL);
>
> -  //
> -  // We still need receive more data when there is no cache data and
> MsgParser is not NULL;
> -  //
> -  if (!HttpInstance->UseHttps) {
> -if (HttpInstance->TimeoutEvent == NULL) {
> -  //
> -  // Create TimeoutEvent for response
> -  //
> -  Status = gBS->CreateEvent (
> -  EVT_TIMER,
> -  TPL_CALLBACK,
> -  NULL,
> -  NULL,
> -  >TimeoutEvent
> -  );
> -  if (EFI_ERROR (Status)) {
> -goto Error;
> -  }
> -}
> -
> +  if (HttpInstance->TimeoutEvent == NULL) {
>  //
> -// Start the timer, and wait Timeout seconds to receive the body packet.
> +// Create TimeoutEvent for response
>  //
> -Status = gBS->SetTimer (HttpInstance->TimeoutEvent, TimerRelative,
> HTTP_RESPONSE_TIMEOUT * TICKS_PER_SECOND);
> +Status = gBS->CreateEvent (
> +EVT_TIMER,
> +TPL_CALLBACK,
> +NULL,
> +NULL,
> +>TimeoutEvent
> +);
>  if (EFI_ERROR (Status)) {
>goto Error;
>  }
> -
> +  }
> +
> +  //
> +  // Start the timer, and wait Timeout seconds to receive the body packet.
> +  //
> +  Status = gBS->SetTimer (HttpInstance->TimeoutEvent, TimerRelative,
> + HTTP_RESPONSE_TIMEOUT * TICKS_PER_SECOND);  if (EFI_ERROR (Status))
> {
> +goto Error;
> +  }
> +
> +  //
> +  // We still need receive more data when there is no cache data and
> + MsgParser is not NULL;  //  if (!HttpInstance->UseHttps) {
>  Status = HttpTcpReceiveBody (Wrap, HttpMsg, HttpInstance-
> >TimeoutEvent);
>
>  gBS->SetTimer (HttpInstance->TimeoutEvent, TimerCancel, 0);
>
>  if (EFI_ERROR (Status)) {
>goto Error;
>  }
>} else {
> -Status = HttpsReceive (HttpInstance, , NULL);
> +Status = HttpsReceive (HttpInstance, ,
> + HttpInstance->TimeoutEvent);
> +
> +gBS->SetTimer (HttpInstance->TimeoutEvent, TimerCancel, 0);
> +
>  if (EFI_ERROR (Status)) {
>goto Error;
>  }
>
>  //
> @@ -1315,11 +1318,13 @@ Exit:
>
>  Error2:
>NetMapInsertHead (>TxTokens, ValueInItem->HttpToken,
> ValueInItem);
>
>  Error:
> -  HttpTcpTokenCleanup (Wrap);
> +  if (!HttpInstance->UseHttps) {
> +HttpTcpTokenCleanup (Wrap);
> +  }
>
>if (HttpHeaders != NULL) {
>  FreePool (HttpHeaders);
>  HttpHeaders = NULL;
>}
> diff --git a/NetworkPkg/HttpDxe/HttpProto.c
> b/NetworkPkg/HttpDxe/HttpProto.c index 965a49f..ebb9dd9 100644
> --- a/NetworkPkg/HttpDxe/HttpProto.c
> +++ b/NetworkPkg/HttpDxe/HttpProto.c
> @@ -1230,11 +1230,40 @@ HttpConnectTcp4 (
>
>//
>// Tls session connection.
>//
>if (HttpInstance->UseHttps) {
> -Status = TlsConnectSession (HttpInstance, NULL);
> +if (HttpInstance->TimeoutEvent == NULL) {
> +  //
> +  // Create TimeoutEvent for TLS connection.
> +  //
> +  Status = gBS->CreateEvent (
> +  EVT_TIMER,
> +  TPL_CALLBACK,
> +  NULL,

Re: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Handle HTTPS indefinite poll case

2016-05-11 Thread Wu, Jiaxin

Hi all,

Any comments for this patch?

Thanks.
Jiaxin

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jiaxin Wu
> Sent: Wednesday, May 4, 2016 3:08 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; Long,
> Qin 
> Subject: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Handle HTTPS
> indefinite poll case
> 
> This patch is used to handle handle HTTPS indefinite poll case.
> 
> Cc: El-Haj-Mahmoud Samer 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Cc: Long Qin 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiaxin Wu 
> ---
>  NetworkPkg/HttpDxe/HttpImpl.c  | 55 ++
>  NetworkPkg/HttpDxe/HttpProto.c | 68
> ++
>  2 files changed, 93 insertions(+), 30 deletions(-)
> 
> diff --git a/NetworkPkg/HttpDxe/HttpImpl.c
> b/NetworkPkg/HttpDxe/HttpImpl.c index cf58b13..cd8fe05 100644
> --- a/NetworkPkg/HttpDxe/HttpImpl.c
> +++ b/NetworkPkg/HttpDxe/HttpImpl.c
> @@ -1179,47 +1179,50 @@ HttpResponseWorker (
>  }
>}
> 
>ASSERT (HttpInstance->MsgParser != NULL);
> 
> -  //
> -  // We still need receive more data when there is no cache data and
> MsgParser is not NULL;
> -  //
> -  if (!HttpInstance->UseHttps) {
> -if (HttpInstance->TimeoutEvent == NULL) {
> -  //
> -  // Create TimeoutEvent for response
> -  //
> -  Status = gBS->CreateEvent (
> -  EVT_TIMER,
> -  TPL_CALLBACK,
> -  NULL,
> -  NULL,
> -  >TimeoutEvent
> -  );
> -  if (EFI_ERROR (Status)) {
> -goto Error;
> -  }
> -}
> -
> +  if (HttpInstance->TimeoutEvent == NULL) {
>  //
> -// Start the timer, and wait Timeout seconds to receive the body packet.
> +// Create TimeoutEvent for response
>  //
> -Status = gBS->SetTimer (HttpInstance->TimeoutEvent, TimerRelative,
> HTTP_RESPONSE_TIMEOUT * TICKS_PER_SECOND);
> +Status = gBS->CreateEvent (
> +EVT_TIMER,
> +TPL_CALLBACK,
> +NULL,
> +NULL,
> +>TimeoutEvent
> +);
>  if (EFI_ERROR (Status)) {
>goto Error;
>  }
> -
> +  }
> +
> +  //
> +  // Start the timer, and wait Timeout seconds to receive the body packet.
> +  //
> +  Status = gBS->SetTimer (HttpInstance->TimeoutEvent, TimerRelative,
> + HTTP_RESPONSE_TIMEOUT * TICKS_PER_SECOND);  if (EFI_ERROR (Status))
> {
> +goto Error;
> +  }
> +
> +  //
> +  // We still need receive more data when there is no cache data and
> + MsgParser is not NULL;  //  if (!HttpInstance->UseHttps) {
>  Status = HttpTcpReceiveBody (Wrap, HttpMsg, HttpInstance-
> >TimeoutEvent);
> 
>  gBS->SetTimer (HttpInstance->TimeoutEvent, TimerCancel, 0);
> 
>  if (EFI_ERROR (Status)) {
>goto Error;
>  }
>} else {
> -Status = HttpsReceive (HttpInstance, , NULL);
> +Status = HttpsReceive (HttpInstance, ,
> + HttpInstance->TimeoutEvent);
> +
> +gBS->SetTimer (HttpInstance->TimeoutEvent, TimerCancel, 0);
> +
>  if (EFI_ERROR (Status)) {
>goto Error;
>  }
> 
>  //
> @@ -1315,11 +1318,13 @@ Exit:
> 
>  Error2:
>NetMapInsertHead (>TxTokens, ValueInItem->HttpToken,
> ValueInItem);
> 
>  Error:
> -  HttpTcpTokenCleanup (Wrap);
> +  if (!HttpInstance->UseHttps) {
> +HttpTcpTokenCleanup (Wrap);
> +  }
> 
>if (HttpHeaders != NULL) {
>  FreePool (HttpHeaders);
>  HttpHeaders = NULL;
>}
> diff --git a/NetworkPkg/HttpDxe/HttpProto.c
> b/NetworkPkg/HttpDxe/HttpProto.c index 965a49f..ebb9dd9 100644
> --- a/NetworkPkg/HttpDxe/HttpProto.c
> +++ b/NetworkPkg/HttpDxe/HttpProto.c
> @@ -1230,11 +1230,40 @@ HttpConnectTcp4 (
> 
>//
>// Tls session connection.
>//
>if (HttpInstance->UseHttps) {
> -Status = TlsConnectSession (HttpInstance, NULL);
> +if (HttpInstance->TimeoutEvent == NULL) {
> +  //
> +  // Create TimeoutEvent for TLS connection.
> +  //
> +  Status = gBS->CreateEvent (
> +  EVT_TIMER,
> +  TPL_CALLBACK,
> +  NULL,
> +  NULL,
> +  >TimeoutEvent
> +  );
> +  if (EFI_ERROR (Status)) {
> +TlsCloseTxRxEvent (HttpInstance);
> +return Status;
> +  }
> +}
> +
> +//
> +// Start the timer, and wait Timeout seconds for connection.
> +//
> +Status = gBS->SetTimer (HttpInstance->TimeoutEvent, TimerRelative,
> HTTP_CONNECTION_TIMEOUT * TICKS_PER_SECOND);
> +if (EFI_ERROR (Status)) {
> +  TlsCloseTxRxEvent (HttpInstance);
> +  return Status;
> +}
> +
> +Status =

[edk2] [PATCH 2/3] QuarkPlatformPkg: Fix variable set but not used build errors

2016-05-11 Thread Lee Leahy

Fix variable set but not used errors detected by GCC 4.8.

Change-Id: I83634f88cfa89ea8afdfebbd0c7487f04e440693
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Lee Leahy 
---
 QuarkPlatformPkg/Acpi/DxeSmm/SmmPowerManagement/Ppm.c  | 14 +-
 .../Library/PlatformHelperLib/PlatformHelperPei.c  |  2 --
 QuarkPlatformPkg/Platform/SpiFvbServices/FwBlockService.c  |  5 -
 3 files changed, 1 insertion(+), 20 deletions(-)

diff --git a/QuarkPlatformPkg/Acpi/DxeSmm/SmmPowerManagement/Ppm.c 
b/QuarkPlatformPkg/Acpi/DxeSmm/SmmPowerManagement/Ppm.c
index 8f5e6a3..a73b4c9 100644
--- a/QuarkPlatformPkg/Acpi/DxeSmm/SmmPowerManagement/Ppm.c
+++ b/QuarkPlatformPkg/Acpi/DxeSmm/SmmPowerManagement/Ppm.c
@@ -79,7 +79,6 @@ PpmPatchFadtTable (
   EFI_ACPI_TABLE_VERSIONVersion;
   UINTN Index;
   UINTN Handle;
-  EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE  *FadtPointer;
 
   //
   // Scan all the acpi tables to find FADT 2.0
@@ -106,9 +105,7 @@ PpmPatchFadtTable (
   ASSERT (Table != NULL);
   CopyMem (Table, CurrentTable, CurrentTable->Length);
 
-  FadtPointer = (EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE*) Table;
-
-//
+  //
   // Update the ACPI table and recalculate checksum
   //
   Status = mAcpiTable->UninstallAcpiTable (mAcpiTable, Handle);
@@ -322,7 +319,6 @@ PpmLoadAndPatchPMTables (
   UINTN TableHandle;
   UINT32FvStatus;
   UINTN Size;
-   EFI_ACPI_TABLE_VERSION   Version;
 
 Status = LocateSupportProtocol (, 
(VOID**), 1);
 if (EFI_ERROR (Status)) {
@@ -348,14 +344,6 @@ PpmLoadAndPatchPMTables (
   );
 
 if (!EFI_ERROR(Status)) {
-Version = EFI_ACPI_TABLE_VERSION_1_0B | EFI_ACPI_TABLE_VERSION_2_0 | 
EFI_ACPI_TABLE_VERSION_3_0;
-
-  if(((EFI_ACPI_DESCRIPTION_HEADER*) CurrentTable)->OemTableId == 
SIGNATURE_64 ('C', 'p', 'u', '0', 'I', 's', 't', 0)) {
-  Version = EFI_ACPI_TABLE_VERSION_NONE;
-  } else if(((EFI_ACPI_DESCRIPTION_HEADER*) CurrentTable)->OemTableId == 
SIGNATURE_64 ('C', 'p', 'u', '1', 'I', 's', 't', 0)) {
-  Version = EFI_ACPI_TABLE_VERSION_NONE;
-  }
-
   SsdtTableUpdate ((EFI_ACPI_DESCRIPTION_HEADER *) CurrentTable);
 
   //
diff --git a/QuarkPlatformPkg/Library/PlatformHelperLib/PlatformHelperPei.c 
b/QuarkPlatformPkg/Library/PlatformHelperLib/PlatformHelperPei.c
index 50a0e42..9976862 100644
--- a/QuarkPlatformPkg/Library/PlatformHelperLib/PlatformHelperPei.c
+++ b/QuarkPlatformPkg/Library/PlatformHelperLib/PlatformHelperPei.c
@@ -63,7 +63,6 @@ PlatformFindFvFileRawDataSection (
   EFI_SECTION_TYPE  SearchType;
   EFI_FV_INFO   VolumeInfo;
   EFI_FV_FILE_INFO  FileInfo;
-  CONST EFI_PEI_SERVICES**PeiServices;
 
   if (FileNameGuid == NULL || SectionData == NULL || SectionDataSize == NULL) {
 return EFI_INVALID_PARAMETER;
@@ -71,7 +70,6 @@ PlatformFindFvFileRawDataSection (
   *SectionData = NULL;
   *SectionDataSize = 0;
 
-  PeiServices = GetPeiServicesTablePointer ();
   SearchType = EFI_SECTION_RAW;
   for (Instance = 0; !EFI_ERROR((PeiServicesFfsFindNextVolume (Instance, 
))); Instance++) {
 if (FvNameGuid != NULL) {
diff --git a/QuarkPlatformPkg/Platform/SpiFvbServices/FwBlockService.c 
b/QuarkPlatformPkg/Platform/SpiFvbServices/FwBlockService.c
index 6cfe710..2185014 100644
--- a/QuarkPlatformPkg/Platform/SpiFvbServices/FwBlockService.c
+++ b/QuarkPlatformPkg/Platform/SpiFvbServices/FwBlockService.c
@@ -590,9 +590,6 @@ Returns:
 --*/
 {
   EFI_STATUS  Status;
-  UINTN   NumBytes;
-
-  NumBytes = LbaLength;
 
   WriteAddress -= (PcdGet32 (PcdFlashAreaBaseAddress));
   if (mInSmmMode == 0 ) { // !(EfiInManagementInterrupt ())) {
@@ -1638,7 +1635,6 @@ Returns:
   VOID*FirmwareVolumeHobList;
   UINT32  BufferSize;
   EFI_FV_BLOCK_MAP_ENTRY  *PtrBlockMapEntry;
-  UINTN   LbaAddress;
   BOOLEAN WriteEnabled;
   BOOLEAN WriteLocked;
   EFI_HANDLE  FwbHandle;
@@ -1882,7 +1878,6 @@ Returns:
 FwhInstance->WriteEnabled = WriteEnabled;
 EfiInitializeLock (&(FwhInstance->FvbDevLock), TPL_HIGH_LEVEL);
 
-LbaAddress  = (UINTN) FwhInstance->FvWriteBase[0];
 NumOfBlocks = 0;
 WriteLocked = FALSE;
 
-- 
1.9.1

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

[edk2] [PATCH 3/3] QuarkSocPkg/SDControllerDxe: Add EFIAPI to SetHighSpeedMode

2016-05-11 Thread Lee Leahy

Fix 64-bit build error detected with GCC4.8 due to inconsistent routine
declaration and implementation.  Add EFIAPI to fix the build error.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Lee Leahy 
---
 QuarkSocPkg/QuarkSouthCluster/Sdio/Dxe/SDControllerDxe/SDController.c | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/QuarkSocPkg/QuarkSouthCluster/Sdio/Dxe/SDControllerDxe/SDController.c 
b/QuarkSocPkg/QuarkSouthCluster/Sdio/Dxe/SDControllerDxe/SDController.c
index 18e85c8..2b5dbe6 100644
--- a/QuarkSocPkg/QuarkSouthCluster/Sdio/Dxe/SDControllerDxe/SDController.c
+++ b/QuarkSocPkg/QuarkSouthCluster/Sdio/Dxe/SDControllerDxe/SDController.c
@@ -244,6 +244,7 @@ GetErrorReason (
   @return EFI_SUCCESS
 **/
 EFI_STATUS
+EFIAPI
 SetHighSpeedMode (
   IN  EFI_SD_HOST_IO_PROTOCOL*This,
   IN  BOOLEANEnable
-- 
1.9.1

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

[edk2] [PATCH 1/3] QuarkPlatformPkg: Fix build errors

2016-05-11 Thread Lee Leahy

Fix build errors detected with GCC 4.8.4: local variable set but not
used!

Change-Id: I5e3cfb46b367a72bd333fd762c22968fbac4e6f9
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Lee Leahy 
---
 QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPciUpdate.c  | 2 --
 QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.c   | 4 
 .../Dxe/SmbiosMiscDxe/MiscNumberOfInstallableLanguagesFunction.c| 4 +---
 QuarkPlatformPkg/Platform/Dxe/SmbiosMiscDxe/MiscOemStringFunction.c | 3 ---
 .../Platform/Dxe/SmbiosMiscDxe/MiscSystemOptionStringFunction.c | 3 ---
 QuarkPlatformPkg/Platform/Pei/PlatformInit/Generic/Recovery.c   | 6 --
 QuarkPlatformPkg/Platform/Pei/PlatformInit/MrcWrapper.c | 5 +
 7 files changed, 2 insertions(+), 25 deletions(-)

diff --git a/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPciUpdate.c 
b/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPciUpdate.c
index b0f0b44..653df45 100644
--- a/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPciUpdate.c
+++ b/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPciUpdate.c
@@ -261,9 +261,7 @@ SdtGetNameStringSize (
 {
   UINTN SegCount;
   UINTN Length;
-  UINT8 *Name;
 
-  Name = Buffer;
   Length = 0;
 
   //
diff --git a/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.c 
b/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.c
index aa18cae..f085753 100644
--- a/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.c
+++ b/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.c
@@ -255,7 +255,6 @@ ApicTableUpdate (
   UINT8  CurrProcessor;
   UINTN  NumberOfCPUs;
   UINTN  NumberOfEnabledCPUs;
-  UINTN  BufferSize;
   EFI_PROCESSOR_INFORMATION  MpContext;
   ACPI_APIC_STRUCTURE_PTR*ApicPtr;
 
@@ -298,7 +297,6 @@ ApicTableUpdate (
 switch (ApicPtr->AcpiApicCommon.Type) {
 
   case EFI_ACPI_1_0_PROCESSOR_LOCAL_APIC:
-BufferSize = sizeof (EFI_PROCESSOR_INFORMATION);
 ApicPtr->AcpiLocalApic.Flags = 0;
 ApicPtr->AcpiLocalApic.ApicId = 0;
 Status = MpService->GetProcessorInfo (
@@ -562,7 +560,6 @@ AcpiPlatformEntryPoint (
   UINT32FvStatus;
   UINTN Size;
   EFI_ACPI_TABLE_VERSIONVersion;
-  QNC_DEVICE_ENABLESQNCDeviceEnables;
   EFI_HANDLEHandle;
   UINTN Index;
   PCI_DEVICE_INFO   *PciDeviceInfo;
@@ -577,7 +574,6 @@ AcpiPlatformEntryPoint (
   TableHandle = 0;
   CurrentTable = NULL;
   mConfigData  = NULL;
-  QNCDeviceEnables.Uint32 = PcdGet32 (PcdDeviceEnables);
 
   //
   // Initialize the EFI Driver Library
diff --git 
a/QuarkPlatformPkg/Platform/Dxe/SmbiosMiscDxe/MiscNumberOfInstallableLanguagesFunction.c
 
b/QuarkPlatformPkg/Platform/Dxe/SmbiosMiscDxe/MiscNumberOfInstallableLanguagesFunction.c
index d17f5ea..48c2d53 100644
--- 
a/QuarkPlatformPkg/Platform/Dxe/SmbiosMiscDxe/MiscNumberOfInstallableLanguagesFunction.c
+++ 
b/QuarkPlatformPkg/Platform/Dxe/SmbiosMiscDxe/MiscNumberOfInstallableLanguagesFunction.c
@@ -190,7 +190,6 @@ MISC_SMBIOS_TABLE_FUNCTION(NumberOfInstallableLanguages)
   CHAR8 
CurrentLang[SMBIOS_STRING_MAX_LENGTH + 1];
   CHAR8 *OptionalStrStart;
   UINT16Offset;
-  BOOLEAN   LangMatch;
   EFI_STATUSStatus;
   EFI_SMBIOS_HANDLE SmbiosHandle;
   SMBIOS_TABLE_TYPE13   *SmbiosRecord;
@@ -210,9 +209,8 @@ MISC_SMBIOS_TABLE_FUNCTION(NumberOfInstallableLanguages)
   //
   // Try to check if current langcode matches with the langcodes in installed 
languages
   //
-  LangMatch = FALSE;
   ZeroMem(CurrentLang, SMBIOS_STRING_MAX_LENGTH + 1);
-  LangMatch = CurrentLanguageMatch (mHiiHandle, , CurrentLang);
+  CurrentLanguageMatch (mHiiHandle, , CurrentLang);
   LangStrLen = AsciiStrLen(CurrentLang);
 
   //
diff --git 
a/QuarkPlatformPkg/Platform/Dxe/SmbiosMiscDxe/MiscOemStringFunction.c 
b/QuarkPlatformPkg/Platform/Dxe/SmbiosMiscDxe/MiscOemStringFunction.c
index e352000..af6df02 100644
--- a/QuarkPlatformPkg/Platform/Dxe/SmbiosMiscDxe/MiscOemStringFunction.c
+++ b/QuarkPlatformPkg/Platform/Dxe/SmbiosMiscDxe/MiscOemStringFunction.c
@@ -38,9 +38,6 @@ MISC_SMBIOS_TABLE_FUNCTION(MiscOemString)
   STRING_REF   TokenToGet;
   EFI_SMBIOS_HANDLESmbiosHandle;
   SMBIOS_TABLE_TYPE11  *SmbiosRecord;
-  EFI_MISC_OEM_STRING  *ForType11InputData;
-
-  ForType11InputData = (EFI_MISC_OEM_STRING *)RecordData;
 
   //
   // First check for invalid parameters.
diff --git 
a/QuarkPlatformPkg/Platform/Dxe/SmbiosMiscDxe/MiscSystemOptionStringFunction.c 
b/QuarkPlatformPkg/Platform/Dxe/SmbiosMiscDxe/MiscSystemOptionStringFunction.c
index 44cc684..52021d8 100644

[edk2] [PATCH 1/1] EmbeddedPkg/Lan9118Dxe: Do not return uninitialised TxBuff

2016-05-11 Thread Michael Brown

Conform to the specification for GetStatus(), which states that "if
there are no transmit buffers to recycle and TxBuf is not NULL, *TxBuf
will be set to NULL".

Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Brown 
---
 EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.c 
b/EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.c
index 8af23df..aabaf60 100644
--- a/EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.c
+++ b/EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.c
@@ -1055,6 +1055,8 @@ SnpGetStatus (
   LanDriver->Stats.TxTotalFrames += 1;
   *TxBuff = LanDriver->TxRing[PacketTag % LAN9118_TX_RING_NUM_ENTRIES];
 }
+  } else if (TxBuff != NULL) {
+*TxBuff = NULL;
   }
 
   // Check for a TX Error interrupt
-- 
2.3.8

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

Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl.

2016-05-11 Thread Andrew Fish

> On May 9, 2016, at 11:24 AM, Mangefeste, Tony  
> wrote:
> 
> Yao has the best idea, which is for Abner to package this into a RiscV*.pkg, 
> and perhaps into a platform branch or staging branch (depending on a number 
> of factors).
> 
> Abner, run this through the PIWG as you stated, that's external to our 
> Tianocore community.  He can at least stage the code somewhere, so that the 
> community can use the code, play with it, and give him feedback.
> 

Abner,

I started a conversation with Mike Kinney and Leif Lindholm about how we should 
handle RISC-V. A staging branch (you are adding an new CPU binding) or a 
platform branch (you need one to test the new CPU) is a good place to start. If 
having the RISC-V port in the branch becomes an issue we can discuss promoting 
it to master. It is a given we will push the RISC-V port to master when the 
binding shows up in a UEFI spec, but we don't want UEFI Spec getting published 
to block progress on other open source projects so we are willing to try and do 
the right thing for the broader open source community if needed.

One of the main reasons for the UEFI spec writing black out period is to 
prevent vendors form rushing to market with incompatible implementations. Given 
this it would be useful for any code in your branch that touches current edk2 
components to have comments documenting the experimental processor binding 
(fell free to chose better terminology).  After the binding gets added to the 
UEFI Spec the comments can be updated to reference the UEFI spec version they 
conform to. 

I was also thinking it would be a good idea for all the current RISC-V 
implementations to publish a protocol that documents the version of the 
implementation. An OS for example could figure out this is the pre UEFI spec 
version of RISC-V based on knowing the protocol exists. I assume the versions 
in this protocol could be RISC-V spec versions, and/or other versions that make 
sense for the RISC-V EFI project. The goal is to make it discoverable by 
software that this is a pre-UEFI Spec RISC-V UEFI system. 

Thanks,

Andrew Fish

> Good discussion.
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Jordan Justen
>> Sent: Monday, May 9, 2016 10:46 AM
>> To: Yao, Jiewen ; Chang, Abner (HPS SW/FW
>> Technologist) ; edk2-devel@lists.01.org
>> Cc: Kinney, Michael D ; Gao, Liming
>> 
>> Subject: Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch
>> DxeIpl.
>> 
>> On 2016-05-09 08:53:12, Yao, Jiewen wrote:
>>> Jordan
>>> Do you know why we have ArmPkg and ArmPlatformPkg?
>>> 
>> 
>> One reason is because we don't have a DriversPkg. Another reason is
>> probably because the effort wasn't made to put them into common
>> packages.
>> 
>>> If you take a look at that, you will find many Arm specific driver
>>> there, including CpuDxe/CpuPei/BaseMemoryLib/
>>> PeiServicesTablePointerLib/etc...
>>> 
>> 
>> Should we create a package for IA32 and X64 to do the same? I think instead
>> we put the IA32/X64 modules in other locations, and I think that made sense.
>> If it made sense for IA32 and X64, then it should make sense for other
>> architectures as well.
>> 
>>> I do not think it is bad idea to have RiscVPkg, when we are not clear
>>> on where to put it.
>>> 
>> 
>> So this is the place to dump things that we don't know where else to put
>> them? That doesn't inspire too much confidence. :)
>> 
>> I agree that it might be needed, but can we try to minimize it?
>> 
>> -Jordan
>> 
>>> 
 -Original Message-
 From: Justen, Jordan L
 Sent: Monday, May 9, 2016 11:46 PM
 To: Yao, Jiewen ; Chang, Abner (HPS SW/FW
 Technologist) ; edk2-devel@lists.01.org
 Cc: Gao, Liming 
 Subject: RE: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch
>> DxeIpl.

 On 2016-05-09 08:12:20, Yao, Jiewen wrote:
> Thank Abner.
> For RiscVPkg, my personally feeling is that it should stick to
> RiscV architecture, like ArmPkg.
> 

 I don't agree. Why don't we have an X64Pkg? I think it is because
 we've defined good locations already for most modules, and many of
 those modules already support multiple architectures.

 Can't the first try be to see if we can get by without adding new
 architecture specific packages?

> Below module seems to be software concept only. They are
> independent to RISV-V architecture, right?
> I am not sure if it is proper to put to RiscVPkg.
> 
>> RiscVPkg/Universal/Logo/Logo.uni   | Bin 0 ->
 1948 bytes
>> RiscVPkg/Universal/Logo/LogoExtra.uni  | Bin 0 ->
 1342 bytes
>> RiscVPkg/Universal/Logo/RiscvUefiLogo.bmp  | Bin 0 ->
 12446 bytes
>>

Re: [edk2] [PATCH 2/7] CorebootPayloadPkg: Assume no PCI serial devices

2016-05-11 Thread Ma, Maurice

OK.
Reviewed-by: Maurice Ma 

-Original Message-
From: Leahy, Leroy P 
Sent: Wednesday, May 11, 2016 1:36 PM
To: Ma, Maurice; edk2-devel@lists.01.org; Agyeman, Prince
Subject: RE: [PATCH 2/7] CorebootPayloadPkg: Assume no PCI serial devices

Hi Maurice,

This is the intent.  The entire PCD needs to be present.  If coreboot uses a 
PCI device for its console then this PCD is written with the necessary values.  
The first two bytes are set to the vendor and device ID values of the PCI 
device that coreboot is using.

Lee Leahy
(425) 881-4919
Intel Corporation
Suite 125
2700 - 156th Ave NE
Bellevue, WA 98007-6554

-Original Message-
From: Ma, Maurice
Sent: Wednesday, May 11, 2016 11:16 AM
To: Leahy, Leroy P ; edk2-devel@lists.01.org; Agyeman, 
Prince 
Subject: RE: [PATCH 2/7] CorebootPayloadPkg: Assume no PCI serial devices

Hi, Leah,

Is this list really consumed?   
I saw the 0x terminator at the very beginning of the list.   So it 
indicates an empty list.Is this the intention?

Thanks
Maurice
-Original Message-
From: Leahy, Leroy P
Sent: Tuesday, May 10, 2016 3:34 PM
To: edk2-devel@lists.01.org; Leahy, Leroy P; Agyeman, Prince; Ma, Maurice
Subject: [PATCH 2/7] CorebootPayloadPkg: Assume no PCI serial devices

Set the vendor to 0x which indicates the end of the list.

Change-Id: If6475e04d3675f0a932571a85d1dd3f301416b6a
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Lee Leahy 
---
 CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc| 4 ++--
 CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc 
b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
index 907e952..cc88502 100644
--- a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
+++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
@@ -67,10 +67,10 @@
   #UINT8   Reserved[2];
   #  } PCI_SERIAL_PARAMETER;
   #
-  # Vendor  Device  Prog Interface 1, BAR #0, Offset 0, Stride = 1, 
Clock 1843200 (0x1c2000)
+  # Vendor  Device  Prog Interface 1, BAR #0, Offset 0, Stride 
+ = 1, Clock 1843200 (0x1c2000)
   #
   #   [Vendor]   [Device]  
[ClockRate---]  [Offset---] [Bar] [Stride] [RxFifo] 
[TxFifo]   [Rsvd]   [Vendor]
-  DEFINE PCI_SERIAL_PARAMETERS= {0x00,0x00, 0x00,0x00, 
0x0,0x20,0x1c,0x00, 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0, 0x00,0x01, 0x0,0x0, 
0x0,0x0, 0x0,0x0, 0xff,0xff}
+  DEFINE PCI_SERIAL_PARAMETERS= {0xff,0xff, 0x00,0x00, 
0x0,0x20,0x1c,0x00, 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0, 0x00,0x01, 0x0,0x0, 
0x0,0x0, 0x0,0x0, 0xff,0xff}
 
   #
   # Shell options: [BUILD_SHELL, FULL_BIN, MIN_BIN, NONE, UEFI] diff --git 
a/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc 
b/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
index 90a484d..77a33a9 100644
--- a/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
+++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
@@ -67,10 +67,10 @@
   #UINT8   Reserved[2];
   #  } PCI_SERIAL_PARAMETER;
   #
-  # Vendor  Device  Prog Interface 1, BAR #0, Offset 0, Stride = 1, 
Clock 1843200 (0x1c2000)
+  # Vendor  Device  Prog Interface 1, BAR #0, Offset 0, Stride 
+ = 1, Clock 1843200 (0x1c2000)
   #
   #   [Vendor]   [Device]  
[ClockRate---]  [Offset---] [Bar] [Stride] [RxFifo] 
[TxFifo]   [Rsvd]   [Vendor]
-  DEFINE PCI_SERIAL_PARAMETERS= {0x00,0x00, 0x00,0x00, 
0x0,0x20,0x1c,0x00, 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0, 0x00,0x01, 0x0,0x0, 
0x0,0x0, 0x0,0x0, 0xff,0xff}
+  DEFINE PCI_SERIAL_PARAMETERS= {0xff,0xff, 0x00,0x00, 
0x0,0x20,0x1c,0x00, 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0, 0x00,0x01, 0x0,0x0, 
0x0,0x0, 0x0,0x0, 0xff,0xff}
 
   #
   # Shell options: [BUILD_SHELL, FULL_BIN, MIN_BIN, NONE, UEFI]
--
1.9.1

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

Re: [edk2] [PATCH 3/7] CorebootPayloadPkg: Use correct BaseSerialPortLib16550

2016-05-11 Thread Ma, Maurice

OK, that is fine.

Reviewed-by: Maurice Ma 

-Original Message-
From: Leahy, Leroy P 
Sent: Wednesday, May 11, 2016 1:38 PM
To: Ma, Maurice; edk2-devel@lists.01.org; Agyeman, Prince
Subject: RE: [PATCH 3/7] CorebootPayloadPkg: Use correct BaseSerialPortLib16550

As we had discussed on the phone last week.  I am going to make these changes 
first in CorebootModulePkg and then post the patches to MdeModulePkg.  When the 
patches get merged into MdeModulePkg then I will be able to remove the 
corresponding components from CorebootModulePkg.

Lee Leahy
(425) 881-4919
Intel Corporation
Suite 125
2700 - 156th Ave NE
Bellevue, WA 98007-6554


-Original Message-
From: Ma, Maurice 
Sent: Wednesday, May 11, 2016 11:24 AM
To: Leahy, Leroy P ; edk2-devel@lists.01.org; Agyeman, 
Prince 
Subject: RE: [PATCH 3/7] CorebootPayloadPkg: Use correct BaseSerialPortLib16550

Hi, Leah,

Is this flow control specific to coreboot?   If not, why not suggest the change 
in MdeModulePkg instead ?

Thanks
Maurice

-Original Message-
From: Leahy, Leroy P 
Sent: Tuesday, May 10, 2016 3:34 PM
To: edk2-devel@lists.01.org; Leahy, Leroy P; Agyeman, Prince; Ma, Maurice
Subject: [PATCH 3/7] CorebootPayloadPkg: Use correct BaseSerialPortLib16550

Use the BaseSerialPortLib16550 which sets RTS and DTR during initialization.  
This fixes the mis-matched flow control issue when the flow control signals are 
connected between the host and target and the host has flow control enabled.

Change-Id: I3505e129b2de3c5c17fff23c62553f15cd892dca
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Lee Leahy 
---
 CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc| 2 +-
 CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc 
b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
index cc88502..9be96e3 100644
--- a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
+++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
@@ -160,7 +160,7 @@
   #
   TimerLib|CorebootPayloadPkg/Library/AcpiTimerLib/AcpiTimerLib.inf
   ResetSystemLib|CorebootPayloadPkg/Library/ResetSystemLib/ResetSystemLib.inf
-  
SerialPortLib|MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf
+  
+ SerialPortLib|CorebootModulePkg/Library/BaseSerialPortLib16550/BaseSer
+ ialPortLib16550.inf
   
PlatformHookLib|CorebootPayloadPkg/Library/PlatformHookLib/PlatformHookLib.inf
   PlatformBdsLib|CorebootPayloadPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
 
diff --git a/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc 
b/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
index 77a33a9..561c0c9 100644
--- a/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
+++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
@@ -162,7 +162,7 @@
   #
   TimerLib|CorebootPayloadPkg/Library/AcpiTimerLib/AcpiTimerLib.inf
   ResetSystemLib|CorebootPayloadPkg/Library/ResetSystemLib/ResetSystemLib.inf
-  
SerialPortLib|MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf
+  
+ SerialPortLib|CorebootModulePkg/Library/BaseSerialPortLib16550/BaseSer
+ ialPortLib16550.inf
   
PlatformHookLib|CorebootPayloadPkg/Library/PlatformHookLib/PlatformHookLib.inf
   PlatformBdsLib|CorebootPayloadPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
 
--
1.9.1

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

[edk2] [PATCH] SecurityPkg: Remove non-ASCII character from TPM warning strings

2016-05-11 Thread Samer El-Haj-Mahmoud

Remove a non-ASCII apostrophe character from TPM_WARNING_MAINTAIN
message

Cc: Chao Zhang 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
---
 .../Library/DxeTcgPhysicalPresenceLib/PhysicalPresenceStrings.uni  | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git 
a/SecurityPkg/Library/DxeTcgPhysicalPresenceLib/PhysicalPresenceStrings.uni 
b/SecurityPkg/Library/DxeTcgPhysicalPresenceLib/PhysicalPresenceStrings.uni
index 00a09c1..065cd63 100644
--- a/SecurityPkg/Library/DxeTcgPhysicalPresenceLib/PhysicalPresenceStrings.uni
+++ b/SecurityPkg/Library/DxeTcgPhysicalPresenceLib/PhysicalPresenceStrings.uni
@@ -2,6 +2,7 @@
   String definitions for TPM 1.2 physical presence confirm text.
 
 Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.
+(C) Copyright 2016 Hewlett Packard Enterprise Development LP
 This program and the accompanying materials 
 are licensed and made available under the terms and conditions of the BSD 
License 
 which accompanies this distribution.  The full text of the license may be 
found at 
@@ -42,7 +43,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #string TPM_NO_PPI_MAINTAIN   #language en-US"maintain"
 #string TPM_NO_PPI_INFO   #language en-US"to approve future 
Operating System requests "
 
-#string TPM_WARNING_MAINTAIN  #language en-US"WARNING: Allowing 
changes to the TPM’s firmware may affect the operation of the TPM and may erase 
information stored on the TPM.\nYou may lose all created keys and access to 
data encrypted by these keys.\n\n"
+#string TPM_WARNING_MAINTAIN  #language en-US"WARNING: Allowing 
changes to the TPM's firmware may affect the operation of the TPM and may erase 
information stored on the TPM.\nYou may lose all created keys and access to 
data encrypted by these keys.\n\n"
 #string TPM_WARNING   #language en-US"WARNING: Doing so 
might prevent security applications that rely on the TPM from functioning as 
expected\n\n"
 #string TPM_WARNING_CLEAR #language en-US"WARNING: Clearing 
erases information stored on the TPM. You will lose all created keys and access 
to data encrypted by these keys. "
 #string TPM_WARNING_CLEAR_CONT#language en-US"Take ownership as 
soon as possible after this step.\n\n"
-- 
2.6.3.windows.1

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

[edk2] [PATCH] MdePkg: Add NFIT definition from ACPI 6.1

2016-05-11 Thread Samer El-Haj-Mahmoud

Add NFIT definition from ACPI 6.1 for the NVDIMM Control Region
Structure Valid Fields for Manufacturing Location and Manufacturing Date

Cc: Michael D Kinney 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
---
 MdePkg/Include/IndustryStandard/Acpi61.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/MdePkg/Include/IndustryStandard/Acpi61.h 
b/MdePkg/Include/IndustryStandard/Acpi61.h
index 1cedcc9..dc3153b 100644
--- a/MdePkg/Include/IndustryStandard/Acpi61.h
+++ b/MdePkg/Include/IndustryStandard/Acpi61.h
@@ -2,6 +2,7 @@
   ACPI 6.1 definitions from the ACPI Specification Revision 6.1 January, 2016.
 
   Copyright (c) 2016, Intel Corporation. All rights reserved.
+ (C) Copyright 2016 Hewlett Packard Enterprise Development LP
   This program and the accompanying materials  
   are licensed and made available under the terms and conditions of the BSD 
License 
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -1475,6 +1476,8 @@ typedef struct {
 //
 // Definition for NVDIMM Control Region Structure
 //
+#define EFI_ACPI_6_1_NFIT_NVDIMM_CONTROL_REGION_VALID_FIELDS_MANUFACTURING 
  BIT0
+
 #define 
EFI_ACPI_6_1_NFIT_NVDIMM_CONTROL_REGION_FLAGS_BLOCK_DATA_WINDOWS_BUFFERED
BIT0
 typedef struct {
   UINT16  Type;
-- 
2.6.3.windows.1

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

Re: [edk2] [PATCH 3/7] CorebootPayloadPkg: Use correct BaseSerialPortLib16550

2016-05-11 Thread Leahy, Leroy P

As we had discussed on the phone last week.  I am going to make these changes 
first in CorebootModulePkg and then post the patches to MdeModulePkg.  When the 
patches get merged into MdeModulePkg then I will be able to remove the 
corresponding components from CorebootModulePkg.

Lee Leahy
(425) 881-4919
Intel Corporation
Suite 125
2700 - 156th Ave NE
Bellevue, WA 98007-6554


-Original Message-
From: Ma, Maurice 
Sent: Wednesday, May 11, 2016 11:24 AM
To: Leahy, Leroy P ; edk2-devel@lists.01.org; Agyeman, 
Prince 
Subject: RE: [PATCH 3/7] CorebootPayloadPkg: Use correct BaseSerialPortLib16550

Hi, Leah,

Is this flow control specific to coreboot?   If not, why not suggest the change 
in MdeModulePkg instead ?

Thanks
Maurice

-Original Message-
From: Leahy, Leroy P 
Sent: Tuesday, May 10, 2016 3:34 PM
To: edk2-devel@lists.01.org; Leahy, Leroy P; Agyeman, Prince; Ma, Maurice
Subject: [PATCH 3/7] CorebootPayloadPkg: Use correct BaseSerialPortLib16550

Use the BaseSerialPortLib16550 which sets RTS and DTR during initialization.  
This fixes the mis-matched flow control issue when the flow control signals are 
connected between the host and target and the host has flow control enabled.

Change-Id: I3505e129b2de3c5c17fff23c62553f15cd892dca
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Lee Leahy 
---
 CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc| 2 +-
 CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc 
b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
index cc88502..9be96e3 100644
--- a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
+++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
@@ -160,7 +160,7 @@
   #
   TimerLib|CorebootPayloadPkg/Library/AcpiTimerLib/AcpiTimerLib.inf
   ResetSystemLib|CorebootPayloadPkg/Library/ResetSystemLib/ResetSystemLib.inf
-  
SerialPortLib|MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf
+  
+ SerialPortLib|CorebootModulePkg/Library/BaseSerialPortLib16550/BaseSer
+ ialPortLib16550.inf
   
PlatformHookLib|CorebootPayloadPkg/Library/PlatformHookLib/PlatformHookLib.inf
   PlatformBdsLib|CorebootPayloadPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
 
diff --git a/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc 
b/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
index 77a33a9..561c0c9 100644
--- a/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
+++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
@@ -162,7 +162,7 @@
   #
   TimerLib|CorebootPayloadPkg/Library/AcpiTimerLib/AcpiTimerLib.inf
   ResetSystemLib|CorebootPayloadPkg/Library/ResetSystemLib/ResetSystemLib.inf
-  
SerialPortLib|MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf
+  
+ SerialPortLib|CorebootModulePkg/Library/BaseSerialPortLib16550/BaseSer
+ ialPortLib16550.inf
   
PlatformHookLib|CorebootPayloadPkg/Library/PlatformHookLib/PlatformHookLib.inf
   PlatformBdsLib|CorebootPayloadPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
 
--
1.9.1

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

Re: [edk2] [PATCH 2/7] CorebootPayloadPkg: Assume no PCI serial devices

2016-05-11 Thread Leahy, Leroy P

Hi Maurice,

This is the intent.  The entire PCD needs to be present.  If coreboot uses a 
PCI device for its console then this PCD is written with the necessary values.  
The first two bytes are set to the vendor and device ID values of the PCI 
device that coreboot is using.

Lee Leahy
(425) 881-4919
Intel Corporation
Suite 125
2700 - 156th Ave NE
Bellevue, WA 98007-6554

-Original Message-
From: Ma, Maurice 
Sent: Wednesday, May 11, 2016 11:16 AM
To: Leahy, Leroy P ; edk2-devel@lists.01.org; Agyeman, 
Prince 
Subject: RE: [PATCH 2/7] CorebootPayloadPkg: Assume no PCI serial devices

Hi, Leah,

Is this list really consumed?   
I saw the 0x terminator at the very beginning of the list.   So it 
indicates an empty list.Is this the intention?

Thanks
Maurice
-Original Message-
From: Leahy, Leroy P
Sent: Tuesday, May 10, 2016 3:34 PM
To: edk2-devel@lists.01.org; Leahy, Leroy P; Agyeman, Prince; Ma, Maurice
Subject: [PATCH 2/7] CorebootPayloadPkg: Assume no PCI serial devices

Set the vendor to 0x which indicates the end of the list.

Change-Id: If6475e04d3675f0a932571a85d1dd3f301416b6a
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Lee Leahy 
---
 CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc| 4 ++--
 CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc 
b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
index 907e952..cc88502 100644
--- a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
+++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
@@ -67,10 +67,10 @@
   #UINT8   Reserved[2];
   #  } PCI_SERIAL_PARAMETER;
   #
-  # Vendor  Device  Prog Interface 1, BAR #0, Offset 0, Stride = 1, 
Clock 1843200 (0x1c2000)
+  # Vendor  Device  Prog Interface 1, BAR #0, Offset 0, Stride 
+ = 1, Clock 1843200 (0x1c2000)
   #
   #   [Vendor]   [Device]  
[ClockRate---]  [Offset---] [Bar] [Stride] [RxFifo] 
[TxFifo]   [Rsvd]   [Vendor]
-  DEFINE PCI_SERIAL_PARAMETERS= {0x00,0x00, 0x00,0x00, 
0x0,0x20,0x1c,0x00, 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0, 0x00,0x01, 0x0,0x0, 
0x0,0x0, 0x0,0x0, 0xff,0xff}
+  DEFINE PCI_SERIAL_PARAMETERS= {0xff,0xff, 0x00,0x00, 
0x0,0x20,0x1c,0x00, 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0, 0x00,0x01, 0x0,0x0, 
0x0,0x0, 0x0,0x0, 0xff,0xff}
 
   #
   # Shell options: [BUILD_SHELL, FULL_BIN, MIN_BIN, NONE, UEFI] diff --git 
a/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc 
b/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
index 90a484d..77a33a9 100644
--- a/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
+++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
@@ -67,10 +67,10 @@
   #UINT8   Reserved[2];
   #  } PCI_SERIAL_PARAMETER;
   #
-  # Vendor  Device  Prog Interface 1, BAR #0, Offset 0, Stride = 1, 
Clock 1843200 (0x1c2000)
+  # Vendor  Device  Prog Interface 1, BAR #0, Offset 0, Stride 
+ = 1, Clock 1843200 (0x1c2000)
   #
   #   [Vendor]   [Device]  
[ClockRate---]  [Offset---] [Bar] [Stride] [RxFifo] 
[TxFifo]   [Rsvd]   [Vendor]
-  DEFINE PCI_SERIAL_PARAMETERS= {0x00,0x00, 0x00,0x00, 
0x0,0x20,0x1c,0x00, 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0, 0x00,0x01, 0x0,0x0, 
0x0,0x0, 0x0,0x0, 0xff,0xff}
+  DEFINE PCI_SERIAL_PARAMETERS= {0xff,0xff, 0x00,0x00, 
0x0,0x20,0x1c,0x00, 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0, 0x00,0x01, 0x0,0x0, 
0x0,0x0, 0x0,0x0, 0xff,0xff}
 
   #
   # Shell options: [BUILD_SHELL, FULL_BIN, MIN_BIN, NONE, UEFI]
--
1.9.1

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

[edk2] [PATCH] MdePkg: Add HII definitions from UEFI 2.6

2016-05-11 Thread Samer El-Haj-Mahmoud

Add HII definitions from UEFI 2.6 for HII Image Variability and PNG
Blocks

Cc: Michael D Kinney 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
---
 MdePkg/Include/Uefi/UefiInternalFormRepresentation.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h 
b/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
index 1a77ea7..4ac 100644
--- a/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
+++ b/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
@@ -4,6 +4,7 @@
   internal application and drivers as well as all add-in card option-ROM 
drivers
 
 Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
+(C) Copyright 2016 Hewlett Packard Enterprise Development LP
 This program and the accompanying materials are licensed and made available 
under 
 the terms and conditions of the BSD License that accompanies this 
distribution.  
 The full text of the license may be found at
@@ -209,6 +210,7 @@ typedef struct _EFI_HII_FONT_PACKAGE_HDR {
 #define EFI_HII_GIBT_GLYPHS   0x11
 #define EFI_HII_GIBT_GLYPH_DEFAULT0x12
 #define EFI_HII_GIBT_GLYPHS_DEFAULT   0x13
+#define EFI_HII_GIBT_GLYPH_VARIABILITY0x14
 #define EFI_HII_GIBT_DUPLICATE0x20
 #define EFI_HII_GIBT_SKIP20x21
 #define EFI_HII_GIBT_SKIP10x22
@@ -281,6 +283,13 @@ typedef struct _EFI_HII_GIBT_GLYPHS_DEFAULT_BLOCK {
   UINT8  BitmapData[1];
 } EFI_HII_GIBT_GLYPHS_DEFAULT_BLOCK;
 
+typedef struct _EFI_HII_GIBT_VARIABILITY_BLOCK {
+  EFI_HII_GLYPH_BLOCKHeader;
+  EFI_HII_GLYPH_INFO Cell;
+  UINT8  GlyphPackInBits;
+  UINT8  BitmapData [1];
+} EFI_HII_GIBT_VARIABILITY_BLOCK;
+
 typedef struct _EFI_HII_GIBT_SKIP1_BLOCK {
   EFI_HII_GLYPH_BLOCKHeader;
   UINT8  SkipCount;
@@ -489,6 +498,7 @@ typedef struct _EFI_HII_IMAGE_BLOCK {
 #define EFI_HII_IIBT_IMAGE_24BIT   0x16
 #define EFI_HII_IIBT_IMAGE_24BIT_TRANS 0x17
 #define EFI_HII_IIBT_IMAGE_JPEG0x18
+#define EFI_HII_IIBT_IMAGE_PNG 0x19
 #define EFI_HII_IIBT_DUPLICATE 0x20
 #define EFI_HII_IIBT_SKIP2 0x21
 #define EFI_HII_IIBT_SKIP1 0x22
@@ -609,6 +619,12 @@ typedef struct _EFI_HII_IIBT_JPEG_BLOCK {
   UINT8Data[1];
 } EFI_HII_IIBT_JPEG_BLOCK;
 
+typedef struct _EFI_HII_IIBT_PNG_BLOCK {
+  EFI_HII_IMAGE_BLOCK  Header;
+  UINT32   Size;
+  UINT8Data[1];
+} EFI_HII_IIBT_PNG_BLOCK;
+
 typedef struct _EFI_HII_IIBT_SKIP1_BLOCK {
   EFI_HII_IMAGE_BLOCK  Header;
   UINT8SkipCount;
-- 
2.6.3.windows.1

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

[edk2] [PATCH] BaseTools: Add HII definitions from UEFI 2.6

2016-05-11 Thread Samer El-Haj-Mahmoud

Add HII definitions from UEFI 2.6 for HII Image Variability and PNG
Blocks

Cc: Yonghong Zhu 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
---
 .../Common/UefiInternalFormRepresentation.h| 24 ++
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/BaseTools/Source/C/Include/Common/UefiInternalFormRepresentation.h 
b/BaseTools/Source/C/Include/Common/UefiInternalFormRepresentation.h
index 8c2edf2..4b585fd 100644
--- a/BaseTools/Source/C/Include/Common/UefiInternalFormRepresentation.h
+++ b/BaseTools/Source/C/Include/Common/UefiInternalFormRepresentation.h
@@ -3,11 +3,9 @@
   IFR is primarily consumed by the EFI presentation engine, and produced by EFI
   internal application and drivers as well as all add-in card option-ROM 
drivers
 
-  @par Revision Reference:
-  These definitions are from UEFI2.1.
-
   Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
-
+ (C) Copyright 2016 Hewlett Packard Enterprise Development LP
+ 
   This program and the accompanying materials are licensed and made available
   under the terms and conditions of the BSD License which accompanies this
   distribution.  The full text of the license may be found at
@@ -16,6 +14,9 @@
   THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
   WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 
+  @par Revision Reference:
+  These definitions are from UEFI 2.6
+
 **/
 
 #ifndef __UEFI_INTERNAL_FORMREPRESENTATION_H__
@@ -167,6 +168,7 @@ typedef struct _EFI_HII_FONT_PACKAGE_HDR {
 #define EFI_HII_GIBT_GLYPHS   0x11
 #define EFI_HII_GIBT_GLYPH_DEFAULT0x12
 #define EFI_HII_GIBT_GLYPHS_DEFAULT   0x13
+#define EFI_HII_GIBT_GLYPH_VARIABILITY0x14
 #define EFI_HII_GIBT_DUPLICATE0x20
 #define EFI_HII_GIBT_SKIP20x21
 #define EFI_HII_GIBT_SKIP10x22
@@ -235,6 +237,13 @@ typedef struct _EFI_HII_GIBT_GLYPHS_DEFAULT_BLOCK {
   UINT8  BitmapData[1]; // the number of bytes per bitmap can 
be calculated by ((Global.Cell.Width+7)/8)*Global.Cell.Height
 } EFI_HII_GIBT_GLYPHS_DEFAULT_BLOCK;
 
+typedef struct _EFI_HII_GIBT_VARIABILITY_BLOCK {
+  EFI_HII_GLYPH_BLOCKHeader;
+  EFI_HII_GLYPH_INFO Cell;
+  UINT8  GlyphPackInBits;
+  UINT8  BitmapData [1];
+} EFI_HII_GIBT_VARIABILITY_BLOCK;
+
 typedef struct _EFI_HII_GIBT_SKIP1_BLOCK {
   EFI_HII_GLYPH_BLOCKHeader;
   UINT8  SkipCount;
@@ -416,6 +425,7 @@ typedef struct _EFI_HII_IMAGE_BLOCK {
 #define EFI_HII_IIBT_IMAGE_24BIT   0x16
 #define EFI_HII_IIBT_IMAGE_24BIT_TRANS 0x17
 #define EFI_HII_IIBT_IMAGE_JPEG0x18
+#define EFI_HII_IIBT_IMAGE_PNG 0x19
 #define EFI_HII_IIBT_DUPLICATE 0x20
 #define EFI_HII_IIBT_SKIP2 0x21
 #define EFI_HII_IIBT_SKIP1 0x22
@@ -532,6 +542,12 @@ typedef struct _EFI_HII_IIBT_JPEG_BLOCK {
   UINT8Data[1];
 } EFI_HII_IIBT_JPEG_BLOCK;
 
+typedef struct _EFI_HII_IIBT_PNG_BLOCK {
+  EFI_HII_IMAGE_BLOCK  Header;
+  UINT32   Size;
+  UINT8Data[1];
+} EFI_HII_IIBT_PNG_BLOCK;
+
 typedef struct _EFI_HII_IIBT_SKIP1_BLOCK {
   EFI_HII_IMAGE_BLOCK  Header;
   UINT8SkipCount;
-- 
2.6.3.windows.1

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

Re: [edk2] [PATCH 1/7] CorebootPayloadPkg: Use DOS line endings

2016-05-11 Thread Ma, Maurice

I think we probably should to conform to the EDK2 Coding standards.

Maurice
From: Michael Zimmermann [mailto:sigmaepsilo...@gmail.com]
Sent: Wednesday, May 11, 2016 11:01 AM
To: Ma, Maurice
Cc: Leahy, Leroy P; edk2-devel@lists.01.org; Agyeman, Prince
Subject: Re: [edk2] [PATCH 1/7] CorebootPayloadPkg: Use DOS line endings

I regularly see these commits, shouldn't we convert all files to DOS line 
endings recursively?
there currently are 627 files with unix line endings.

Michael

On Wed, May 11, 2016 at 7:55 PM, Ma, Maurice 
> wrote:
Looks fine.

Reviewed-by: Maurice Ma >

-Original Message-
From: Leahy, Leroy P
Sent: Tuesday, May 10, 2016 3:34 PM
To: edk2-devel@lists.01.org; Leahy, Leroy P; 
Agyeman, Prince; Ma, Maurice
Subject: [PATCH 1/7] CorebootPayloadPkg: Use DOS line endings

Convert to using DOS line endings.

Change-Id: Ie2f148867d9b2b386d556583afb6716ec21399e9
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Lee Leahy 
>
---
 CorebootPayloadPkg/CorebootPayloadPkg.fdf|  84 ++---
 CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc| 412 +++---
 CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc | 419 +++
 3 files changed, 455 insertions(+), 460 deletions(-)

diff --git a/CorebootPayloadPkg/CorebootPayloadPkg.fdf 
b/CorebootPayloadPkg/CorebootPayloadPkg.fdf
index 85748a6..7b52f40 100644
--- a/CorebootPayloadPkg/CorebootPayloadPkg.fdf
+++ b/CorebootPayloadPkg/CorebootPayloadPkg.fdf
@@ -1,16 +1,16 @@
 ## @file
 # Coreboot Payload Package
 #
-# Provides drivers and definitions to create uefi payload for coreboot.
+# Provides drivers and definitions to create uefi payload for coreboot.
 #
-# Copyright (c) 2014 - 2016, Intel Corporation. All rights reserved.
-# This program and the accompanying materials are licensed and made available 
under
-# the terms and conditions of the BSD License that accompanies this 
distribution.
+# Copyright (c) 2014 - 2016, Intel Corporation. All rights reserved.
+# This program and the accompanying materials are licensed and made available 
under
+# the terms and conditions of the BSD License that accompanies this 
distribution.
 # The full text of the license may be found at
-# http://opensource.org/licenses/bsd-license.php.
-#
-# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+# 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.
 #
 ##

@@ -93,31 +93,31 @@ INF 
MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
 INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
 INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
 INF 
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
-INF MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
-INF PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
+INF MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
+INF PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
 INF MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntimeDxe.inf

 INF UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
 INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
 INF MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
-INF PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
+INF PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
 INF MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
-INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
+INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
 INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
-INF CorebootModulePkg/CbSupportDxe/CbSupportDxe.inf
+INF CorebootModulePkg/CbSupportDxe/CbSupportDxe.inf

 INF MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf
 #
 # PCI Support
 #
-INF 
CorebootModulePkg/PciRootBridgeNoEnumerationDxe/PciRootBridgeNoEnumeration.inf
-INF CorebootModulePkg/PciBusNoEnumerationDxe/PciBusNoEnumeration.inf
-INF CorebootModulePkg/PciSioSerialDxe/PciSioSerialDxe.inf
+INF 
CorebootModulePkg/PciRootBridgeNoEnumerationDxe/PciRootBridgeNoEnumeration.inf
+INF CorebootModulePkg/PciBusNoEnumerationDxe/PciBusNoEnumeration.inf
+INF CorebootModulePkg/PciSioSerialDxe/PciSioSerialDxe.inf

 #
 # ISA Support
 #
-INF CorebootModulePkg/SerialDxe/SerialDxe.inf
+INF CorebootModulePkg/SerialDxe/SerialDxe.inf

 #
 # Console Support
@@ -133,13 +133,13 @@ INF 
MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
 INF MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
 INF

Re: [edk2] edk2 llvm branch

2016-05-11 Thread Andrew Fish


> On May 11, 2016, at 9:38 AM, Shi, Steven  wrote:
> 
> Hi Andrew,
> 
> Attachment and below are my build map files and code size for your suggested 
> two modules with CLANGLTO38 and VS2013x86. Maybe I should use latest 
> VS2015x86 for the comparing next time.
> 

Steven,

Thanks for the data.

> 
> 
> * CLANGLTO38:
> 
>> build -a IA32 -t CLANGLTO38 -p OvmfPkg/OvmfPkgIa32.dsc -n 5 -m 
>> IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei.inf -b RELEASE
> 
> 1,184
> 
>> build -a IA32 -t CLANGLTO38 -p OvmfPkg/OvmfPkgIa32.dsc -n 5 -m 
>> IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei.inf -b DEBUG 
>> -DDEBUG_ON_SERIAL_PORT
> 
> 7,648
> 
>> build -a X64 -t CLANGLTO38 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -m 
>> PcAtChipsetPkg/8254TimerDxe/8254Timer.inf -b RELEASE
> 
> 1,600
> 
>> build -a X64 -t CLANGLTO38 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -m 
>> PcAtChipsetPkg/8254TimerDxe/8254Timer.inf -b DEBUG -DDEBUG_ON_SERIAL_PORT
> 
> 11,712 (with -fno-lto to disable lto in 
> MdePkg\Library\BasePrintLib\BasePrintLib.inf, which is to work around CPU 
> exception in PrintLib during boot time)
> 
> 8,736 (with lto enalbed in BasePrintLib.inf)
> 
> 
> 
> * VS2013x86:
> 
>> build -a IA32 -t VS2013x86 -p OvmfPkg/OvmfPkgIa32.dsc -n 5 -m 
>> IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei.inf -b RELEASE
> 
> 1,280
> 
>> build -a IA32 -t VS2013x86 -p OvmfPkg/OvmfPkgIa32.dsc -n 5 -m 
>> IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei.inf -b DEBUG 
>> -DDEBUG_ON_SERIAL_PORT
> 
> 8,576
> 
>> build -a X64 -t VS2013x86 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -m 
>> PcAtChipsetPkg/8254TimerDxe/8254Timer.inf -b RELEASE
> 
> 1,760
> 
>> build -a X64 -t VS2013x86 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -m 
>> PcAtChipsetPkg/8254TimerDxe/8254Timer.inf -b DEBUG -DDEBUG_ON_SERIAL_PORT
> 
> 9,760
> 
> 
> 
> I believe the clang3.8 with LTO enabled is good enough on code size. My 
> current biggest trouble is the Clang3.8 LTO not stable on GNU ld when 
> generate X64 code, and worse on gold (even cannot finish build). I've 
> reported two bugs about LTO against GNU ld and gold in below, FYI.
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=20062
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=20070
> 
> 

Are those the linker command line failures? What about the code generation 
issues? 

On the code gen issues I would guess they have to do with 
__attribute__((ms_abi)) (call x86_64_win64cc in bit code)and var args. You 
might try building some simple examples at the command line and see if you can 
find an error. So for example you could write a simple Unix command line app to 
test calling a __attribute__((ms_abi)) var arg function that prints out 
information. 

What I usually do is try to make the simplest EFI case possible and then I 
locally define the EFI types. That makes it really easy to reproduce the issue 
for the compiler team. 

~/work/Compiler>cat ms_abi.c
#include 

typedef __builtin_va_list VA_LIST;
typedef unsigned long long  UINTN;

#define VA_START(Marker, Parameter)  __builtin_va_start (Marker, Parameter)

#define VA_ARG(Marker, TYPE) ((sizeof (TYPE) < sizeof (UINTN)) ? 
(TYPE)(__builtin_va_arg (Marker, UINTN)) : (TYPE)(__builtin_va_arg (Marker, 
TYPE)))

#define VA_END(Marker)   __builtin_va_end (Marker)

#define VA_COPY(Dest, Start) __builtin_va_copy (Dest, Start)

__attribute__((ms_abi)) int EFI_printf(const int len, ...)
{
  VA_LIST Marker;
  int i;

  VA_START (Marker, len);
  for (i=0; i < len; i++) {
printf ("%d - %d\n", i, VA_ARG(Marker, int));
  }

  VA_END(Marker);
  return len;
}

int
main ()
{
  EFI_printf (8, 10, 11, 12, 12, 14, 15, 16, 17);
  return 0;
}~/work/Compiler>clang -Os -flto ms_abi.c
~/work/Compiler>./a.out
0 - 10
1 - 11
2 - 12
3 - 12
4 - 14
5 - 15
6 - 10
7 - 11
~/work/Compiler>

Yikes I think I just reproduced your bug in the Xcode clang. Can you try this 
example on your toolchain and report the issue if you see it. 

> 
> BTW, does XCODE linker have linux version? If yes, I'd like to try it to 
> co-work with clang 3.8 as CC compiler.
> 
> 

No it is Mac only, and only supports Mach-O not ELF. It is my understanding 
that the Xcode  linker just links the bit code like normal (pulls in the 
symbols that are needed).  Then this linked bit code blob is sent to an LLVM 
dynamic library to do the code gen. Maybe different version of LLVM are used by 
the different linkers in your case, or maybe the LLVM stuff is compiled in? 



Thanks,

Andrew Fish

> 
> 
> 
> Steven Shi
> 
> Intel\SSG\STO\UEFI Firmware
> 
> 
> 
> Tel: +86 021-61166522
> 
> iNet: 821-6522
> 
> 
> 
>> -Original Message-
> 
>> From: af...@apple.com [mailto:af...@apple.com]
> 
>> Sent: Wednesday, May 11, 2016 11:09 PM
> 
>> To: Shi, Steven 
> 
>> Cc: edk2-devel@lists.01.org
> 
>> Subject: Re: [edk2] edk2 llvm branch
> 
>> 
> 
>> 
> 
>>> On May 11, 2016, at 5:08 AM, Shi, Steven 
>>>

Re: [edk2] [PATCH 3/7] CorebootPayloadPkg: Use correct BaseSerialPortLib16550

2016-05-11 Thread Ma, Maurice

Hi, Leah,

Is this flow control specific to coreboot?   If not, why not suggest the change 
in MdeModulePkg instead ?

Thanks
Maurice

-Original Message-
From: Leahy, Leroy P 
Sent: Tuesday, May 10, 2016 3:34 PM
To: edk2-devel@lists.01.org; Leahy, Leroy P; Agyeman, Prince; Ma, Maurice
Subject: [PATCH 3/7] CorebootPayloadPkg: Use correct BaseSerialPortLib16550

Use the BaseSerialPortLib16550 which sets RTS and DTR during initialization.  
This fixes the mis-matched flow control issue when the flow control signals are 
connected between the host and target and the host has flow control enabled.

Change-Id: I3505e129b2de3c5c17fff23c62553f15cd892dca
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Lee Leahy 
---
 CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc| 2 +-
 CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc 
b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
index cc88502..9be96e3 100644
--- a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
+++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
@@ -160,7 +160,7 @@
   #
   TimerLib|CorebootPayloadPkg/Library/AcpiTimerLib/AcpiTimerLib.inf
   ResetSystemLib|CorebootPayloadPkg/Library/ResetSystemLib/ResetSystemLib.inf
-  
SerialPortLib|MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf
+  
+ SerialPortLib|CorebootModulePkg/Library/BaseSerialPortLib16550/BaseSer
+ ialPortLib16550.inf
   
PlatformHookLib|CorebootPayloadPkg/Library/PlatformHookLib/PlatformHookLib.inf
   PlatformBdsLib|CorebootPayloadPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
 
diff --git a/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc 
b/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
index 77a33a9..561c0c9 100644
--- a/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
+++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
@@ -162,7 +162,7 @@
   #
   TimerLib|CorebootPayloadPkg/Library/AcpiTimerLib/AcpiTimerLib.inf
   ResetSystemLib|CorebootPayloadPkg/Library/ResetSystemLib/ResetSystemLib.inf
-  
SerialPortLib|MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf
+  
+ SerialPortLib|CorebootModulePkg/Library/BaseSerialPortLib16550/BaseSer
+ ialPortLib16550.inf
   
PlatformHookLib|CorebootPayloadPkg/Library/PlatformHookLib/PlatformHookLib.inf
   PlatformBdsLib|CorebootPayloadPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
 
--
1.9.1

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

Re: [edk2] [PATCH 2/7] CorebootPayloadPkg: Assume no PCI serial devices

2016-05-11 Thread Ma, Maurice

Hi, Leah,

Is this list really consumed?   
I saw the 0x terminator at the very beginning of the list.   So it 
indicates an empty list.Is this the intention?

Thanks
Maurice
-Original Message-
From: Leahy, Leroy P 
Sent: Tuesday, May 10, 2016 3:34 PM
To: edk2-devel@lists.01.org; Leahy, Leroy P; Agyeman, Prince; Ma, Maurice
Subject: [PATCH 2/7] CorebootPayloadPkg: Assume no PCI serial devices

Set the vendor to 0x which indicates the end of the list.

Change-Id: If6475e04d3675f0a932571a85d1dd3f301416b6a
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Lee Leahy 
---
 CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc| 4 ++--
 CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc 
b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
index 907e952..cc88502 100644
--- a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
+++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
@@ -67,10 +67,10 @@
   #UINT8   Reserved[2];
   #  } PCI_SERIAL_PARAMETER;
   #
-  # Vendor  Device  Prog Interface 1, BAR #0, Offset 0, Stride = 1, 
Clock 1843200 (0x1c2000)
+  # Vendor  Device  Prog Interface 1, BAR #0, Offset 0, Stride 
+ = 1, Clock 1843200 (0x1c2000)
   #
   #   [Vendor]   [Device]  
[ClockRate---]  [Offset---] [Bar] [Stride] [RxFifo] 
[TxFifo]   [Rsvd]   [Vendor]
-  DEFINE PCI_SERIAL_PARAMETERS= {0x00,0x00, 0x00,0x00, 
0x0,0x20,0x1c,0x00, 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0, 0x00,0x01, 0x0,0x0, 
0x0,0x0, 0x0,0x0, 0xff,0xff}
+  DEFINE PCI_SERIAL_PARAMETERS= {0xff,0xff, 0x00,0x00, 
0x0,0x20,0x1c,0x00, 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0, 0x00,0x01, 0x0,0x0, 
0x0,0x0, 0x0,0x0, 0xff,0xff}
 
   #
   # Shell options: [BUILD_SHELL, FULL_BIN, MIN_BIN, NONE, UEFI] diff --git 
a/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc 
b/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
index 90a484d..77a33a9 100644
--- a/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
+++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
@@ -67,10 +67,10 @@
   #UINT8   Reserved[2];
   #  } PCI_SERIAL_PARAMETER;
   #
-  # Vendor  Device  Prog Interface 1, BAR #0, Offset 0, Stride = 1, 
Clock 1843200 (0x1c2000)
+  # Vendor  Device  Prog Interface 1, BAR #0, Offset 0, Stride 
+ = 1, Clock 1843200 (0x1c2000)
   #
   #   [Vendor]   [Device]  
[ClockRate---]  [Offset---] [Bar] [Stride] [RxFifo] 
[TxFifo]   [Rsvd]   [Vendor]
-  DEFINE PCI_SERIAL_PARAMETERS= {0x00,0x00, 0x00,0x00, 
0x0,0x20,0x1c,0x00, 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0, 0x00,0x01, 0x0,0x0, 
0x0,0x0, 0x0,0x0, 0xff,0xff}
+  DEFINE PCI_SERIAL_PARAMETERS= {0xff,0xff, 0x00,0x00, 
0x0,0x20,0x1c,0x00, 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0, 0x00,0x01, 0x0,0x0, 
0x0,0x0, 0x0,0x0, 0xff,0xff}
 
   #
   # Shell options: [BUILD_SHELL, FULL_BIN, MIN_BIN, NONE, UEFI]
--
1.9.1

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

Re: [edk2] [PATCH 4/7] CorebootPayloadPkg: Set the proper Shell file GUID

2016-05-11 Thread Ma, Maurice

Looks fine to me.
Reviewed-by: Maurice Ma 

-Original Message-
From: Leahy, Leroy P 
Sent: Tuesday, May 10, 2016 3:35 PM
To: edk2-devel@lists.01.org; Leahy, Leroy P; Agyeman, Prince; Ma, Maurice
Subject: [PATCH 4/7] CorebootPayloadPkg: Set the proper Shell file GUID

Set the proper Shell file GUID so that the BDS transfers control to the Shell.

Change-Id: I816636a340bbe2f76ac1973b9cb685084c4f88a0
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Lee Leahy 
---
 CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc| 11 +++
 CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc | 11 +++
 2 files changed, 22 insertions(+)

diff --git a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc 
b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
index 9be96e3..72b69f2 100644
--- a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
+++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
@@ -288,6 +288,17 @@
 
   
gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber|$(MAX_LOGICAL_PROCESSORS)
 
+  #
+  # Set the proper Shell file GUID
+  #
+  !if $(SHELL_TYPE) == FULL_BIN
+  # c57ad6b7-0515-40a8-9d21-551652854e37
+  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0xB7, 0xD6, 
+ 0x7A, 0xC5, 0x15, 0x05, 0xA8, 0x40, 0x9D, 0x21, 0x55, 0x16, 0x52, 
+ 0x85, 0x4E, 0x37 }  !else  # 7C04A583-9E3E-4f1c-AD65-E05268D0B4D1
+  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 
+ 0x04, 0x7C, 0x3E, 0x9E, 0x1c, 0x4f, 0xAD, 0x65, 0xE0, 0x52, 0x68, 
+ 0xD0, 0xB4, 0xD1 }  !endif
+
 

 #
 # Pcd Dynamic Section - list of all EDK II PCD Entries defined by this 
Platform diff --git a/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc 
b/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
index 561c0c9..21e2548 100644
--- a/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
+++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
@@ -292,6 +292,17 @@
 
   
gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber|$(MAX_LOGICAL_PROCESSORS)
 
+  #
+  # Set the proper Shell file GUID
+  #
+  !if $(SHELL_TYPE) == FULL_BIN
+  # c57ad6b7-0515-40a8-9d21-551652854e37
+  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0xB7, 0xD6, 
+ 0x7A, 0xC5, 0x15, 0x05, 0xA8, 0x40, 0x9D, 0x21, 0x55, 0x16, 0x52, 
+ 0x85, 0x4E, 0x37 }  !else  # 7C04A583-9E3E-4f1c-AD65-E05268D0B4D1
+  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 
+ 0x04, 0x7C, 0x3E, 0x9E, 0x1c, 0x4f, 0xAD, 0x65, 0xE0, 0x52, 0x68, 
+ 0xD0, 0xB4, 0xD1 }  !endif
+
 

 #
 # Pcd Dynamic Section - list of all EDK II PCD Entries defined by this Platform
--
1.9.1

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

Re: [edk2] [PATCH 7/7] CorebootPayloadPkg: Add BdsDxe support

2016-05-11 Thread Ma, Maurice

Any reason that we have to support both?
I think we can just use MdeModulePkg/Universal/BdsDxe and remove 
IntelFrameworkModulePkg/Universal/BdsDxe reference from DSC/FDF.

Thanks
Maurice
-Original Message-
From: Leahy, Leroy P 
Sent: Tuesday, May 10, 2016 3:35 PM
To: edk2-devel@lists.01.org; Leahy, Leroy P; Agyeman, Prince; Ma, Maurice
Subject: [PATCH 7/7] CorebootPayloadPkg: Add BdsDxe support

Add define to select the MdeModulePkg/Universal/BdsDxe instead of 
IntelFrameworkModulePkg/Universal/BdsDxe.

Change-Id: I0930b375e46fd72a199567efc422df5bb535798c
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Lee Leahy 
---
 CorebootPayloadPkg/CorebootPayloadPkg.fdf  |  14 +-
 CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc  |  22 +-
 CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc   |  22 +-
 .../PlatformBootManagerLib/PlatformBootManager.c   | 339 +
 .../PlatformBootManagerLib/PlatformBootManager.h   |  50 +++
 .../PlatformBootManagerLib.inf |  73 +
 .../Library/PlatformBootManagerLib/PlatformData.c  | 281 +
 7 files changed, 794 insertions(+), 7 deletions(-)  create mode 100644 
CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManager.c
 create mode 100644 
CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManager.h
 create mode 100644 
CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
 create mode 100644 
CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformData.c

diff --git a/CorebootPayloadPkg/CorebootPayloadPkg.fdf 
b/CorebootPayloadPkg/CorebootPayloadPkg.fdf
index 432155f..df771ef 100644
--- a/CorebootPayloadPkg/CorebootPayloadPkg.fdf
+++ b/CorebootPayloadPkg/CorebootPayloadPkg.fdf
@@ -86,7 +86,11 @@ INF 
IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe
 
 INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
 INF UefiCpuPkg/CpuDxe/CpuDxe.inf
+!if $(BDS_TYPE) == IntelFrameworkModulePkg
 INF IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
+!else
+INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
+!endif
 INF PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
 INF MdeModulePkg/Universal/Metronome/Metronome.inf
 INF MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
@@ -112,12 +116,16 @@ INF MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf
 #
 INF 
CorebootModulePkg/PciRootBridgeNoEnumerationDxe/PciRootBridgeNoEnumeration.inf
 INF CorebootModulePkg/PciBusNoEnumerationDxe/PciBusNoEnumeration.inf
-INF CorebootModulePkg/PciSioSerialDxe/PciSioSerialDxe.inf
 
 #
-# ISA Support
+# Serial Support
 #
-INF CorebootModulePkg/SerialDxe/SerialDxe.inf
+!if $(BDS_TYPE) == IntelFrameworkModulePkg
+
+  INF CorebootModulePkg/SerialDxe/SerialDxe.inf
+!else
+  INF CorebootModulePkg/PciSioSerialDxe/PciSioSerialDxe.inf
+!endif
 
 #
 # Console Support
diff --git a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc 
b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
index a9e78a5..57c2dce 100644
--- a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
+++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
@@ -34,6 +34,11 @@
   DEFINE SOURCE_DEBUG_ENABLE = FALSE
 
   #
+  # BDS Options: [IntelFrameworkModulePkg, MdeModulePkg]  #
+  DEFINE BDS_TYPE= IntelFrameworkModulePkg
+
+  #
   # CPU options
   #
   DEFINE MAX_LOGICAL_PROCESSORS  = 64
@@ -162,7 +167,13 @@
   ResetSystemLib|CorebootPayloadPkg/Library/ResetSystemLib/ResetSystemLib.inf
   
SerialPortLib|CorebootModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf
   
PlatformHookLib|CorebootPayloadPkg/Library/PlatformHookLib/PlatformHookLib.inf
+!if $(BDS_TYPE) == IntelFrameworkModulePkg
   PlatformBdsLib|CorebootPayloadPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
+!else
+  
+PlatformBootManagerLib|CorebootPayloadPkg/Library/PlatformBootManagerLi
+b/PlatformBootManagerLib.inf
+  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
+  
+UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootMana
+gerLib.inf
+!endif
 
   #
   # Misc
@@ -353,7 +364,11 @@
   #
   MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
   UefiCpuPkg/CpuDxe/CpuDxe.inf
+!if $(BDS_TYPE) == IntelFrameworkModulePkg
   IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
+!else
+  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
+!endif
   PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
   MdeModulePkg/Universal/Metronome/Metronome.inf
   MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
@@ -398,7 +413,6 @@
   #
   
CorebootModulePkg/PciRootBridgeNoEnumerationDxe/PciRootBridgeNoEnumeration.inf
   CorebootModulePkg/PciBusNoEnumerationDxe/PciBusNoEnumeration.inf
-  CorebootModulePkg/PciSioSerialDxe/PciSioSerialDxe.inf
 
   #
   # SCSI/ATA/IDE/DISK Support
@@ -436,9 +450,13 @@
   CorebootModulePkg/OhciDxe/OhciDxe.inf
 
   #
-  # ISA Support
+  # Serial Support
   #
+!if $(BDS_TYPE) == IntelFrameworkModulePkg
   CorebootModulePkg/SerialDxe/SerialDxe.inf
+!else
+

Re: [edk2] [PATCH 5/7] CorebootPayloadPkg: Add SD/eMMC support

2016-05-11 Thread Ma, Maurice

Looks fine to me.
Reviewed-by: Maurice Ma 

-Original Message-
From: Leahy, Leroy P 
Sent: Tuesday, May 10, 2016 3:35 PM
To: edk2-devel@lists.01.org; Leahy, Leroy P; Agyeman, Prince; Ma, Maurice
Subject: [PATCH 5/7] CorebootPayloadPkg: Add SD/eMMC support

Add SD and eMMC DXE driver support to CorebootPayloadPkg.

Change-Id: Ibfd3a2cc32a653ce51e38d9157ea3c6da25a5474
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Lee Leahy 
---
 CorebootPayloadPkg/CorebootPayloadPkg.fdf| 7 +++
 CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc| 7 +++
 CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc | 7 +++
 3 files changed, 21 insertions(+)

diff --git a/CorebootPayloadPkg/CorebootPayloadPkg.fdf 
b/CorebootPayloadPkg/CorebootPayloadPkg.fdf
index 7b52f40..cb18828 100644
--- a/CorebootPayloadPkg/CorebootPayloadPkg.fdf
+++ b/CorebootPayloadPkg/CorebootPayloadPkg.fdf
@@ -142,6 +142,13 @@ INF MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
 INF FatPkg/EnhancedFatDxe/Fat.inf
 
 #
+# SD/eMMC Support
+#
+INF MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf
+INF MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.inf
+INF MdeModulePkg/Bus/Sd/SdDxe/SdDxe.inf
+
+#
 # Usb Support
 #
 INF MdeModulePkg/Bus/Pci/UhciDxe/UhciDxe.inf
diff --git a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc 
b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
index 72b69f2..73af2dd 100644
--- a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
+++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
@@ -414,6 +414,13 @@
   MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
 
   #
+  # SD/eMMC Support
+  #
+  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf
+  MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.inf
+  MdeModulePkg/Bus/Sd/SdDxe/SdDxe.inf
+
+  #
   # Usb Support
   #
   MdeModulePkg/Bus/Pci/UhciDxe/UhciDxe.inf
diff --git a/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc 
b/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
index 21e2548..95ec8ce 100644
--- a/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
+++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
@@ -418,6 +418,13 @@
   MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
 
   #
+  # SD/eMMC Support
+  #
+  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf
+  MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.inf
+  MdeModulePkg/Bus/Sd/SdDxe/SdDxe.inf
+
+  #
   # Usb Support
   #
   MdeModulePkg/Bus/Pci/UhciDxe/UhciDxe.inf
-- 
1.9.1

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

Re: [edk2] [PATCH 1/7] CorebootPayloadPkg: Use DOS line endings

2016-05-11 Thread Michael Zimmermann

I regularly see these commits, shouldn't we convert all files to DOS line
endings recursively?
there currently are 627 files with unix line endings.

Michael

On Wed, May 11, 2016 at 7:55 PM, Ma, Maurice  wrote:

> Looks fine.
>
> Reviewed-by: Maurice Ma 
>
> -Original Message-
> From: Leahy, Leroy P
> Sent: Tuesday, May 10, 2016 3:34 PM
> To: edk2-devel@lists.01.org; Leahy, Leroy P; Agyeman, Prince; Ma, Maurice
> Subject: [PATCH 1/7] CorebootPayloadPkg: Use DOS line endings
>
> Convert to using DOS line endings.
>
> Change-Id: Ie2f148867d9b2b386d556583afb6716ec21399e9
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Lee Leahy 
> ---
>  CorebootPayloadPkg/CorebootPayloadPkg.fdf|  84 ++---
>  CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc| 412
> +++---
>  CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc | 419
> +++
>  3 files changed, 455 insertions(+), 460 deletions(-)
>
> diff --git a/CorebootPayloadPkg/CorebootPayloadPkg.fdf
> b/CorebootPayloadPkg/CorebootPayloadPkg.fdf
> index 85748a6..7b52f40 100644
> --- a/CorebootPayloadPkg/CorebootPayloadPkg.fdf
> +++ b/CorebootPayloadPkg/CorebootPayloadPkg.fdf
> @@ -1,16 +1,16 @@
>  ## @file
>  # Coreboot Payload Package
>  #
> -# Provides drivers and definitions to create uefi payload for coreboot.
> +# Provides drivers and definitions to create uefi payload for coreboot.
>  #
> -# Copyright (c) 2014 - 2016, Intel Corporation. All rights reserved.
> -# This program and the accompanying materials are licensed and made
> available under
> -# the terms and conditions of the BSD License that accompanies this
> distribution.
> +# Copyright (c) 2014 - 2016, Intel Corporation. All rights reserved.
> +# This program and the accompanying materials are licensed and made
> available under
> +# the terms and conditions of the BSD License that accompanies this
> distribution.
>  # The full text of the license may be found at
> -# http://opensource.org/licenses/bsd-license.php.
> -#
> -# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> -# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
> IMPLIED.
> +# 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.
>  #
>  ##
>
> @@ -93,31 +93,31 @@ INF
> MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
>  INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
>  INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
>  INF
> MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
> -INF MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
> -INF
> PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
> +INF MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
> +INF
> PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
>  INF
> MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntimeDxe.inf
>
>  INF UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>  INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
>  INF
> MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
> -INF PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
> +INF PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
>  INF MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
> -INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> +INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
>  INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
> -INF CorebootModulePkg/CbSupportDxe/CbSupportDxe.inf
> +INF CorebootModulePkg/CbSupportDxe/CbSupportDxe.inf
>
>  INF MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf
>  #
>  # PCI Support
>  #
> -INF
> CorebootModulePkg/PciRootBridgeNoEnumerationDxe/PciRootBridgeNoEnumeration.inf
> -INF CorebootModulePkg/PciBusNoEnumerationDxe/PciBusNoEnumeration.inf
> -INF CorebootModulePkg/PciSioSerialDxe/PciSioSerialDxe.inf
> +INF
> CorebootModulePkg/PciRootBridgeNoEnumerationDxe/PciRootBridgeNoEnumeration.inf
> +INF CorebootModulePkg/PciBusNoEnumerationDxe/PciBusNoEnumeration.inf
> +INF CorebootModulePkg/PciSioSerialDxe/PciSioSerialDxe.inf
>
>  #
>  # ISA Support
>  #
> -INF CorebootModulePkg/SerialDxe/SerialDxe.inf
> +INF CorebootModulePkg/SerialDxe/SerialDxe.inf
>
>  #
>  # Console Support
> @@ -133,13 +133,13 @@ INF
> MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
>  INF MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
>  INF MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
>  INF MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
> -INF CorebootModulePkg/SataControllerDxe/SataControllerDxe.inf
> +INF CorebootModulePkg/SataControllerDxe/SataControllerDxe.inf
>  INF

Re: [edk2] [PATCH 1/7] CorebootPayloadPkg: Use DOS line endings

2016-05-11 Thread Ma, Maurice

Looks fine.

Reviewed-by: Maurice Ma 

-Original Message-
From: Leahy, Leroy P 
Sent: Tuesday, May 10, 2016 3:34 PM
To: edk2-devel@lists.01.org; Leahy, Leroy P; Agyeman, Prince; Ma, Maurice
Subject: [PATCH 1/7] CorebootPayloadPkg: Use DOS line endings

Convert to using DOS line endings.

Change-Id: Ie2f148867d9b2b386d556583afb6716ec21399e9
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Lee Leahy 
---
 CorebootPayloadPkg/CorebootPayloadPkg.fdf|  84 ++---
 CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc| 412 +++---
 CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc | 419 +++
 3 files changed, 455 insertions(+), 460 deletions(-)

diff --git a/CorebootPayloadPkg/CorebootPayloadPkg.fdf 
b/CorebootPayloadPkg/CorebootPayloadPkg.fdf
index 85748a6..7b52f40 100644
--- a/CorebootPayloadPkg/CorebootPayloadPkg.fdf
+++ b/CorebootPayloadPkg/CorebootPayloadPkg.fdf
@@ -1,16 +1,16 @@
 ## @file
 # Coreboot Payload Package
 #
-# Provides drivers and definitions to create uefi payload for coreboot.
+# Provides drivers and definitions to create uefi payload for coreboot.
 #
-# Copyright (c) 2014 - 2016, Intel Corporation. All rights reserved.
-# This program and the accompanying materials are licensed and made available 
under
-# the terms and conditions of the BSD License that accompanies this 
distribution.
+# Copyright (c) 2014 - 2016, Intel Corporation. All rights reserved.
+# This program and the accompanying materials are licensed and made available 
under
+# the terms and conditions of the BSD License that accompanies this 
distribution.
 # The full text of the license may be found at
-# http://opensource.org/licenses/bsd-license.php.
-#
-# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+# 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.
 #
 ##
 
@@ -93,31 +93,31 @@ INF 
MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
 INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
 INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
 INF 
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
-INF MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
-INF PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
+INF MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
+INF PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
 INF MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntimeDxe.inf
 
 INF UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
 INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
 INF MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
-INF PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
+INF PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
 INF MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
-INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
+INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
 INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
-INF CorebootModulePkg/CbSupportDxe/CbSupportDxe.inf
+INF CorebootModulePkg/CbSupportDxe/CbSupportDxe.inf
 
 INF MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf
 #
 # PCI Support
 #
-INF 
CorebootModulePkg/PciRootBridgeNoEnumerationDxe/PciRootBridgeNoEnumeration.inf
-INF CorebootModulePkg/PciBusNoEnumerationDxe/PciBusNoEnumeration.inf
-INF CorebootModulePkg/PciSioSerialDxe/PciSioSerialDxe.inf
+INF 
CorebootModulePkg/PciRootBridgeNoEnumerationDxe/PciRootBridgeNoEnumeration.inf
+INF CorebootModulePkg/PciBusNoEnumerationDxe/PciBusNoEnumeration.inf
+INF CorebootModulePkg/PciSioSerialDxe/PciSioSerialDxe.inf
 
 #
 # ISA Support
 #
-INF CorebootModulePkg/SerialDxe/SerialDxe.inf
+INF CorebootModulePkg/SerialDxe/SerialDxe.inf
 
 #
 # Console Support
@@ -133,13 +133,13 @@ INF 
MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
 INF MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
 INF MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
 INF MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
-INF CorebootModulePkg/SataControllerDxe/SataControllerDxe.inf
+INF CorebootModulePkg/SataControllerDxe/SataControllerDxe.inf
 INF MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
 INF MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
 INF MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
 INF MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
 
-INF FatPkg/EnhancedFatDxe/Fat.inf
+INF FatPkg/EnhancedFatDxe/Fat.inf
 
 #
 # Usb Support
@@ -154,40 +154,40 @@ INF 
MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
 #
 # Shell
 #
-!if $(SHELL_TYPE) == BUILD_SHELL
-INF

Re: [edk2] edk2 llvm branch

2016-05-11 Thread Shi, Steven

Hi Andrew,

Attachment and below are my build map files and code size for your suggested 
two modules with CLANGLTO38 and VS2013x86. Maybe I should use latest VS2015x86 
for the comparing next time.



* CLANGLTO38:

> build -a IA32 -t CLANGLTO38 -p OvmfPkg/OvmfPkgIa32.dsc -n 5 -m 
> IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei.inf -b RELEASE

1,184

> build -a IA32 -t CLANGLTO38 -p OvmfPkg/OvmfPkgIa32.dsc -n 5 -m 
> IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei.inf -b DEBUG 
> -DDEBUG_ON_SERIAL_PORT

7,648

> build -a X64 -t CLANGLTO38 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -m 
> PcAtChipsetPkg/8254TimerDxe/8254Timer.inf -b RELEASE

1,600

> build -a X64 -t CLANGLTO38 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -m 
> PcAtChipsetPkg/8254TimerDxe/8254Timer.inf -b DEBUG -DDEBUG_ON_SERIAL_PORT

11,712 (with -fno-lto to disable lto in 
MdePkg\Library\BasePrintLib\BasePrintLib.inf, which is to work around CPU 
exception in PrintLib during boot time)

8,736 (with lto enalbed in BasePrintLib.inf)



* VS2013x86:

> build -a IA32 -t VS2013x86 -p OvmfPkg/OvmfPkgIa32.dsc -n 5 -m 
> IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei.inf -b RELEASE

1,280

> build -a IA32 -t VS2013x86 -p OvmfPkg/OvmfPkgIa32.dsc -n 5 -m 
> IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei.inf -b DEBUG 
> -DDEBUG_ON_SERIAL_PORT

8,576

> build -a X64 -t VS2013x86 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -m 
> PcAtChipsetPkg/8254TimerDxe/8254Timer.inf -b RELEASE

1,760

> build -a X64 -t VS2013x86 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -m 
> PcAtChipsetPkg/8254TimerDxe/8254Timer.inf -b DEBUG -DDEBUG_ON_SERIAL_PORT

9,760



I believe the clang3.8 with LTO enabled is good enough on code size. My current 
biggest trouble is the Clang3.8 LTO not stable on GNU ld when generate X64 
code, and worse on gold (even cannot finish build). I've reported two bugs 
about LTO against GNU ld and gold in below, FYI.

https://sourceware.org/bugzilla/show_bug.cgi?id=20062

https://sourceware.org/bugzilla/show_bug.cgi?id=20070



BTW, does XCODE linker have linux version? If yes, I'd like to try it to 
co-work with clang 3.8 as CC compiler.





Steven Shi

Intel\SSG\STO\UEFI Firmware



Tel: +86 021-61166522

iNet: 821-6522



> -Original Message-

> From: af...@apple.com [mailto:af...@apple.com]

> Sent: Wednesday, May 11, 2016 11:09 PM

> To: Shi, Steven 

> Cc: edk2-devel@lists.01.org

> Subject: Re: [edk2] edk2 llvm branch

>

>

> > On May 11, 2016, at 5:08 AM, Shi, Steven 
> > > wrote:

> >

> > Hi Andrew,

> > From your data, it looks the XCode LTO is not enabled correctly for IA32,

> but correct for X64. Attachment has my build map files, and below are my

> build commands. FYI.

> >

>

> Sorry had a typo in the tools_def.txt, here are the numbers with -flto

> correctly added to the CC_FLAGS:

>

> > build -a IA32 -t XCODE5 -p OvmfPkg/OvmfPkgIa32.dsc -n 5 -m

> MdeModulePkg/Core/Pei/PeiMain.inf -b RELEASE

> 25K

> > build -a IA32 -t XCODE5 -p OvmfPkg/OvmfPkgIa32.dsc -n 5 -m

> MdeModulePkg/Core/Pei/PeiMain.inf -b DEBUG -

> DDEBUG_ON_SERIAL_PORT

> 45K

> > build -a X64 -t XCODE5 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -m

> MdeModulePkg/Core/Dxe/DxeMain.inf -b RELEASE

> 103K

> > build -a X64  -t XCODE5 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -m

> MdeModulePkg/Core/Dxe/DxeMain.inf -b DEBUG -

> DDEBUG_ON_SERIAL_PORT

> 133K

>

> When doing size optimizations it is often easier to start with smaller 
> drivers.

> Can you send the sizes/map files for:

> > build -a IA32 -t XCODE5 -p OvmfPkg/OvmfPkgIa32.dsc -n 5 -m

> IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei.inf -b

> RELEASE

> 1220

> > build -a IA32 -t XCODE5 -p OvmfPkg/OvmfPkgIa32.dsc -n 5 -m

> IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei.inf -b

> DEBUG -DDEBUG_ON_SERIAL_PORT

> 8228

> > build -a X64 -t XCODE5 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -m

> PcAtChipsetPkg/8254TimerDxe/8254Timer.inf -b RELEASE

> 2464

> > build -a X64 -t XCODE5 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -m

> PcAtChipsetPkg/8254TimerDxe/8254Timer.inf -b DEBUG -

> DDEBUG_ON_SERIAL_PORT

> 9088

>

>

>

> I forgot to mention that X64 XCODE5/clang has a 5 byte overhead per

> function vs.VS2013x86 due to supporting stack unwind. The upside is the

> unexpected exception handler can print out a stack trace. VS2013x86

> requires the debugger with symbols to unwind the stack.

>

> ~/work/Compiler>cat call.c

> int main ()

> {

> return 0;

> }

> ~/work/Compiler>clang -Os call.c

> ~/work/Compiler>lldb a.out

> (lldb) target create "a.out"

> Current executable set to 'a.out' (x86_64).

> (lldb) dis -m -b -n main

> a.out`main

> a.out`main:

> a.out[0x10f98] <+0>: 55pushq  %rbp

> a.out[0x10f99] <+1>: 48 89 e5  movq   %rsp, %rbp

> a.out[0x10f9c] <+4>: 31 c0 xorl   %eax, %eax

> a.out[0x10f9e] <+6>: 5dpopq   %rbp

> a.out[0x10f9f] <+7>: c3

Re: [edk2] edk2 llvm branch

2016-05-11 Thread Andrew Fish


> On May 11, 2016, at 5:08 AM, Shi, Steven  wrote:
> 
> Hi Andrew,
> From your data, it looks the XCode LTO is not enabled correctly for IA32, but 
> correct for X64. Attachment has my build map files, and below are my build 
> commands. FYI.
> 

Sorry had a typo in the tools_def.txt, here are the numbers with -flto 
correctly added to the CC_FLAGS:

> build -a IA32 -t XCODE5 -p OvmfPkg/OvmfPkgIa32.dsc -n 5 -m 
> MdeModulePkg/Core/Pei/PeiMain.inf -b RELEASE
25K
> build -a IA32 -t XCODE5 -p OvmfPkg/OvmfPkgIa32.dsc -n 5 -m 
> MdeModulePkg/Core/Pei/PeiMain.inf -b DEBUG -DDEBUG_ON_SERIAL_PORT
45K
> build -a X64 -t XCODE5 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -m 
> MdeModulePkg/Core/Dxe/DxeMain.inf -b RELEASE
103K
> build -a X64  -t XCODE5 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -m 
> MdeModulePkg/Core/Dxe/DxeMain.inf -b DEBUG -DDEBUG_ON_SERIAL_PORT
133K

When doing size optimizations it is often easier to start with smaller drivers. 
 Can you send the sizes/map files for:
> build -a IA32 -t XCODE5 -p OvmfPkg/OvmfPkgIa32.dsc -n 5 -m 
> IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei.inf -b RELEASE
1220
> build -a IA32 -t XCODE5 -p OvmfPkg/OvmfPkgIa32.dsc -n 5 -m 
> IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei.inf -b DEBUG 
> -DDEBUG_ON_SERIAL_PORT
8228
> build -a X64 -t XCODE5 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -m 
> PcAtChipsetPkg/8254TimerDxe/8254Timer.inf -b RELEASE
2464
> build -a X64 -t XCODE5 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -m 
> PcAtChipsetPkg/8254TimerDxe/8254Timer.inf -b DEBUG -DDEBUG_ON_SERIAL_PORT
9088



I forgot to mention that X64 XCODE5/clang has a 5 byte overhead per function 
vs.VS2013x86 due to supporting stack unwind. The upside is the unexpected 
exception handler can print out a stack trace. VS2013x86 requires the debugger 
with symbols to unwind the stack. 

~/work/Compiler>cat call.c
int main ()
{
return 0;
}
~/work/Compiler>clang -Os call.c
~/work/Compiler>lldb a.out
(lldb) target create "a.out"
Current executable set to 'a.out' (x86_64).
(lldb) dis -m -b -n main
a.out`main
a.out`main:
a.out[0x10f98] <+0>: 55pushq  %rbp
a.out[0x10f99] <+1>: 48 89 e5  movq   %rsp, %rbp
a.out[0x10f9c] <+4>: 31 c0 xorl   %eax, %eax
a.out[0x10f9e] <+6>: 5dpopq   %rbp
a.out[0x10f9f] <+7>: c3retq   

Thanks,

Andrew Fish

> VS2013x86:
> build -a IA32 -t VS2013x86 -p OvmfPkg\OvmfPkgIa32.dsc -n 5 -m 
> MdeModulePkg\Core\Pei\PeiMain.inf -b RELEASE
> build -a IA32 -t VS2013x86 -p OvmfPkg\OvmfPkgIa32.dsc -n 5 -m 
> MdeModulePkg\Core\Pei\PeiMain.inf -b DEBUG -DDEBUG_ON_SERIAL_PORT
> build -a X64 -t VS2013x86 -p OvmfPkg\OvmfPkgX64.dsc -n 5 -m 
> MdeModulePkg\Core\Dxe\DxeMain.inf  -b RELEASE
> build -a X64 -t VS2013x86 -p OvmfPkg\OvmfPkgX64.dsc -n 5 -m 
> MdeModulePkg\Core\Dxe\DxeMain.inf  -b DEBUG -DDEBUG_ON_SERIAL_PORT
> 
> CLANGLTO38:
> build -a IA32 -t CLANGLTO38 -p OvmfPkg/OvmfPkgIa32.dsc -n 5 -m 
> MdeModulePkg/Core/Pei/PeiMain.inf  -b RELEASE
> build -a IA32 -t CLANGLTO38 -p OvmfPkg/OvmfPkgIa32.dsc -n 5 -m 
> MdeModulePkg/Core/Pei/PeiMain.inf  -b DEBUG -DDEBUG_ON_SERIAL_PORT
> build -a X64 -t CLANGLTO38 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -m 
> MdeModulePkg/Core/Dxe/DxeMain.inf  -b RELEASE
> build -a X64 -t CLANGLTO38 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -m 
> MdeModulePkg/Core/Dxe/DxeMain.inf  -b DEBUG -DDEBUG_ON_SERIAL_PORT
> 
> 
> 
> Steven Shi
> Intel\SSG\STO\UEFI Firmware
> 
> Tel: +86 021-61166522
> iNet: 821-6522
> 
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Wednesday, May 11, 2016 2:03 AM
> To: Shi, Steven 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] edk2 llvm branch
> 
> 
> On May 10, 2016, at 8:05 AM, Shi, Steven 
> > wrote:
> 
> Hi Andrew,
> Thank you for the suggestion. I will try your suggestion and response other 
> questions in your email later. I don't have XCODE5 environment, but could do 
> me a favor and  let me know what current XCODE5 code size for PeiCore.efi and 
> DxeCore.efi in your side? In my side, as below data show, I see the LTO can 
> bring big code size improvement which is quite important for firmware in many 
> scenarios.
> 
> I forgot to mention. LTO or not it is good to check to make sure the assembly 
> files are getting dead stripped. For example check to make sure you are not 
> getting all the assembly functions in the BaseLib included in your 
> executable.  Some of the assembly is .S and some is .nasm so you may see 
> different behavior depending on which assembler was used.
> 
> It is also useful to start looking at the smallest PEIM/DXE drivers 1st as it 
> may be easier to spot what is different.
> 
> 
> Maybe it is also a good idea to enable LTO in XCODE.
> 
> For Xcode you add -object_path_lto $(DEST_DIR_DEBUG)/$(BASE_NAME).lto to   
> *_XCODE5_*_DLINK_FLAGS. This places the intermediate link code gen in the 
> Build/ director vs. a temp director and is important for source level 
> debugging. To

Re: [edk2] [PATCH 1/2] ArmPlatformPkg/PL031RealTimeClockLib: don't clobber gRT table

2016-05-11 Thread Leif Lindholm

On Wed, May 11, 2016 at 04:21:35PM +0200, Ard Biesheuvel wrote:
> On 13 April 2016 at 10:10, Ard Biesheuvel  wrote:
> > PL031RealTimeClockLib is a base library that could potentially (although
> > unlikely) be incorporated into other modules than the DXE_RUNTIME_DRIVER
> > module that it was intended to complement.
> >
> > This means the library has no business whatsoever setting the Runtime
> > Service table pointers directly (since we have no way of knowing which
> > instance will 'win', and the pointers may end up referring to a module
> > that is not a DXE_RUNTIME_DRIVER). So remove the assignment altogether.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Ard Biesheuvel 
> > ---
> >  ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c | 6 
> > --
> >  1 file changed, 6 deletions(-)
> >
> > diff --git 
> > a/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c 
> > b/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c
> > index 52ba48992b83..516b45675c69 100644
> > --- a/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c
> > +++ b/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c
> > @@ -650,12 +650,6 @@ LibRtcInitialize (
> >  return Status;
> >}
> >
> > -  // Setup the setters and getters
> > -  gRT->GetTime   = LibGetTime;
> > -  gRT->SetTime   = LibSetTime;
> > -  gRT->GetWakeupTime = LibGetWakeupTime;
> > -  gRT->SetWakeupTime = LibSetWakeupTime;
> > -
> >mRT = gRT;
> >
> >// Install the protocol
> > --
> > 2.5.0
> >
> 
> Ping? (also for the next one)

For the series:
Reviewed-by: Leif Lindholm 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/2] ArmPlatformPkg/PL031RealTimeClockLib: don't clobber gRT table

2016-05-11 Thread Ard Biesheuvel

On 13 April 2016 at 10:10, Ard Biesheuvel  wrote:
> PL031RealTimeClockLib is a base library that could potentially (although
> unlikely) be incorporated into other modules than the DXE_RUNTIME_DRIVER
> module that it was intended to complement.
>
> This means the library has no business whatsoever setting the Runtime
> Service table pointers directly (since we have no way of knowing which
> instance will 'win', and the pointers may end up referring to a module
> that is not a DXE_RUNTIME_DRIVER). So remove the assignment altogether.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c | 6 
> --
>  1 file changed, 6 deletions(-)
>
> diff --git 
> a/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c 
> b/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c
> index 52ba48992b83..516b45675c69 100644
> --- a/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c
> +++ b/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c
> @@ -650,12 +650,6 @@ LibRtcInitialize (
>  return Status;
>}
>
> -  // Setup the setters and getters
> -  gRT->GetTime   = LibGetTime;
> -  gRT->SetTime   = LibSetTime;
> -  gRT->GetWakeupTime = LibGetWakeupTime;
> -  gRT->SetWakeupTime = LibSetWakeupTime;
> -
>mRT = gRT;
>
>// Install the protocol
> --
> 2.5.0
>

Ping? (also for the next one)
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmPkg/PlatformBootManagerLib: implement new generic version

2016-05-11 Thread Ard Biesheuvel

On 11 May 2016 at 14:54, Laszlo Ersek  wrote:
> On 05/11/16 14:47, Ard Biesheuvel wrote:
>> This implements the platform glue for the new generic BDS implementation.
>> It is based on the ArmVirtQemu version, with the QEMU references removed.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c   | 562 
>> 
>>  ArmPkg/Library/PlatformBootManagerLib/PlatformBm.h   |  59 ++
>>  ArmPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf |  86 +++
>>  ArmPkg/Library/PlatformBootManagerLib/QuietBoot.c| 680 
>> 
>>  4 files changed, 1387 insertions(+)
>
>> +  //~ Status = gRT->GetVariable (L"Timeout",
>> +  //~ ,
>> +  //~ NULL,
>> +  //~ sizeof (Timeout),
>> +  //~ );
>> +  //~ if (!EFI_ERROR (Status)) {
>> +//~ PcdSet16 (PcdPlatformBootTimeOut, Timeout);
>> +  //~ }
>
> Forgotten or intentional?
>

Forgotten.

I discovered that this

[PcdsDynamicExHii.common.DEFAULT]
  
gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|5

does the trick nicely.

Thanks for spotting that.

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

Re: [edk2] [PATCH] ArmPkg/PlatformBootManagerLib: implement new generic version

2016-05-11 Thread Laszlo Ersek

On 05/11/16 14:47, Ard Biesheuvel wrote:
> This implements the platform glue for the new generic BDS implementation.
> It is based on the ArmVirtQemu version, with the QEMU references removed.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c   | 562 
> 
>  ArmPkg/Library/PlatformBootManagerLib/PlatformBm.h   |  59 ++
>  ArmPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf |  86 +++
>  ArmPkg/Library/PlatformBootManagerLib/QuietBoot.c| 680 
> 
>  4 files changed, 1387 insertions(+)

> +  //~ Status = gRT->GetVariable (L"Timeout",
> +  //~ ,
> +  //~ NULL,
> +  //~ sizeof (Timeout),
> +  //~ );
> +  //~ if (!EFI_ERROR (Status)) {
> +//~ PcdSet16 (PcdPlatformBootTimeOut, Timeout);
> +  //~ }

Forgotten or intentional?

Thanks
Laszlo

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

[edk2] [PATCH] ArmPkg/PlatformBootManagerLib: implement new generic version

2016-05-11 Thread Ard Biesheuvel

This implements the platform glue for the new generic BDS implementation.
It is based on the ArmVirtQemu version, with the QEMU references removed.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c   | 562 

 ArmPkg/Library/PlatformBootManagerLib/PlatformBm.h   |  59 ++
 ArmPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf |  86 +++
 ArmPkg/Library/PlatformBootManagerLib/QuietBoot.c| 680 

 4 files changed, 1387 insertions(+)

diff --git a/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c 
b/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
new file mode 100644
index ..175220122b5e
--- /dev/null
+++ b/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
@@ -0,0 +1,562 @@
+/** @file
+  Implementation for PlatformBootManagerLib library class interfaces.
+
+  Copyright (C) 2015-2016, Red Hat, Inc.
+  Copyright (c) 2014, ARM Ltd. All rights reserved.
+  Copyright (c) 2004 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2016, Linaro Ltd. All rights reserved.
+
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License which accompanies this
+  distribution. The full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
+  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "PlatformBm.h"
+
+#define DP_NODE_LEN(Type) { (UINT8)sizeof (Type), (UINT8)(sizeof (Type) >> 8) }
+
+
+#pragma pack (1)
+typedef struct {
+  VENDOR_DEVICE_PATH SerialDxe;
+  UART_DEVICE_PATH   Uart;
+  VENDOR_DEFINED_DEVICE_PATH TermType;
+  EFI_DEVICE_PATH_PROTOCOL   End;
+} PLATFORM_SERIAL_CONSOLE;
+#pragma pack ()
+
+#define SERIAL_DXE_FILE_GUID { \
+  0xD3987D4B, 0x971A, 0x435F, \
+  { 0x8C, 0xAF, 0x49, 0x67, 0xEB, 0x62, 0x72, 0x41 } \
+  }
+
+STATIC PLATFORM_SERIAL_CONSOLE mSerialConsole = {
+  //
+  // VENDOR_DEVICE_PATH SerialDxe
+  //
+  {
+{ HARDWARE_DEVICE_PATH, HW_VENDOR_DP, DP_NODE_LEN (VENDOR_DEVICE_PATH) },
+SERIAL_DXE_FILE_GUID
+  },
+
+  //
+  // UART_DEVICE_PATH Uart
+  //
+  {
+{ MESSAGING_DEVICE_PATH, MSG_UART_DP, DP_NODE_LEN (UART_DEVICE_PATH) },
+0,  // Reserved
+FixedPcdGet64 (PcdUartDefaultBaudRate), // BaudRate
+FixedPcdGet8 (PcdUartDefaultDataBits),  // DataBits
+FixedPcdGet8 (PcdUartDefaultParity),// Parity
+FixedPcdGet8 (PcdUartDefaultStopBits)   // StopBits
+  },
+
+  //
+  // VENDOR_DEFINED_DEVICE_PATH TermType
+  //
+  {
+{
+  MESSAGING_DEVICE_PATH, MSG_VENDOR_DP,
+  DP_NODE_LEN (VENDOR_DEFINED_DEVICE_PATH)
+}
+//
+// Guid to be filled in dynamically
+//
+  },
+
+  //
+  // EFI_DEVICE_PATH_PROTOCOL End
+  //
+  {
+END_DEVICE_PATH_TYPE, END_ENTIRE_DEVICE_PATH_SUBTYPE,
+DP_NODE_LEN (EFI_DEVICE_PATH_PROTOCOL)
+  }
+};
+
+
+#pragma pack (1)
+typedef struct {
+  USB_CLASS_DEVICE_PATHKeyboard;
+  EFI_DEVICE_PATH_PROTOCOL End;
+} PLATFORM_USB_KEYBOARD;
+#pragma pack ()
+
+STATIC PLATFORM_USB_KEYBOARD mUsbKeyboard = {
+  //
+  // USB_CLASS_DEVICE_PATH Keyboard
+  //
+  {
+{
+  MESSAGING_DEVICE_PATH, MSG_USB_CLASS_DP,
+  DP_NODE_LEN (USB_CLASS_DEVICE_PATH)
+},
+0x, // VendorId: any
+0x, // ProductId: any
+3,  // DeviceClass: HID
+1,  // DeviceSubClass: boot
+1   // DeviceProtocol: keyboard
+  },
+
+  //
+  // EFI_DEVICE_PATH_PROTOCOL End
+  //
+  {
+END_DEVICE_PATH_TYPE, END_ENTIRE_DEVICE_PATH_SUBTYPE,
+DP_NODE_LEN (EFI_DEVICE_PATH_PROTOCOL)
+  }
+};
+
+
+/**
+  Check if the handle satisfies a particular condition.
+
+  @param[in] Handle  The handle to check.
+  @param[in] ReportText  A caller-allocated string passed in for reporting
+ purposes. It must never be NULL.
+
+  @retval TRUE   The condition is satisfied.
+  @retval FALSE  Otherwise. This includes the case when the condition could not
+ be fully evaluated due to an error.
+**/
+typedef
+BOOLEAN
+(EFIAPI *FILTER_FUNCTION) (
+  IN EFI_HANDLE   Handle,
+  IN CONST CHAR16 *ReportText
+  );
+
+
+/**
+  Process a handle.
+
+  @param[in] Handle  The handle to process.
+  @param[in] ReportText  A caller-allocated string passed in for reporting
+ purposes. It must never be NULL.
+**/
+typedef
+VOID
+(EFIAPI *CALLBACK_FUNCTION)  (
+  IN EFI_HANDLE   Handle,
+  IN CONST CHAR16 *ReportText
+  );
+
+/**
+  Locate all handles that carry the specified protocol, filter them with a
+  callback function, and

Re: [edk2] edk2 llvm branch

2016-05-11 Thread Shi, Steven

Hi Andrew,
>From your data, it looks the XCode LTO is not enabled correctly for IA32, but 
>correct for X64. Attachment has my build map files, and below are my build 
>commands. FYI.

VS2013x86:
build -a IA32 -t VS2013x86 -p OvmfPkg\OvmfPkgIa32.dsc -n 5 -m 
MdeModulePkg\Core\Pei\PeiMain.inf -b RELEASE
build -a IA32 -t VS2013x86 -p OvmfPkg\OvmfPkgIa32.dsc -n 5 -m 
MdeModulePkg\Core\Pei\PeiMain.inf -b DEBUG -DDEBUG_ON_SERIAL_PORT
build -a X64 -t VS2013x86 -p OvmfPkg\OvmfPkgX64.dsc -n 5 -m 
MdeModulePkg\Core\Dxe\DxeMain.inf  -b RELEASE
build -a X64 -t VS2013x86 -p OvmfPkg\OvmfPkgX64.dsc -n 5 -m 
MdeModulePkg\Core\Dxe\DxeMain.inf  -b DEBUG -DDEBUG_ON_SERIAL_PORT

CLANGLTO38:
build -a IA32 -t CLANGLTO38 -p OvmfPkg/OvmfPkgIa32.dsc -n 5 -m 
MdeModulePkg/Core/Pei/PeiMain.inf  -b RELEASE
build -a IA32 -t CLANGLTO38 -p OvmfPkg/OvmfPkgIa32.dsc -n 5 -m 
MdeModulePkg/Core/Pei/PeiMain.inf  -b DEBUG -DDEBUG_ON_SERIAL_PORT
build -a X64 -t CLANGLTO38 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -m 
MdeModulePkg/Core/Dxe/DxeMain.inf  -b RELEASE
build -a X64 -t CLANGLTO38 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -m 
MdeModulePkg/Core/Dxe/DxeMain.inf  -b DEBUG -DDEBUG_ON_SERIAL_PORT

Steven Shi
Intel\SSG\STO\UEFI Firmware

Tel: +86 021-61166522
iNet: 821-6522

From: af...@apple.com [mailto:af...@apple.com]
Sent: Wednesday, May 11, 2016 2:03 AM
To: Shi, Steven 
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] edk2 llvm branch

On May 10, 2016, at 8:05 AM, Shi, Steven 
> wrote:

Hi Andrew,
Thank you for the suggestion. I will try your suggestion and response other 
questions in your email later. I don't have XCODE5 environment, but could do me 
a favor and  let me know what current XCODE5 code size for PeiCore.efi and 
DxeCore.efi in your side? In my side, as below data show, I see the LTO can 
bring big code size improvement which is quite important for firmware in many 
scenarios.

I forgot to mention. LTO or not it is good to check to make sure the assembly 
files are getting dead stripped. For example check to make sure you are not 
getting all the assembly functions in the BaseLib included in your executable.  
Some of the assembly is .S and some is .nasm so you may see different behavior 
depending on which assembler was used.

It is also useful to start looking at the smallest PEIM/DXE drivers 1st as it 
may be easier to spot what is different.

Maybe it is also a good idea to enable LTO in XCODE.

For Xcode you add -object_path_lto $(DEST_DIR_DEBUG)/$(BASE_NAME).lto to   
*_XCODE5_*_DLINK_FLAGS. This places the intermediate link code gen in the 
Build/ director vs. a temp director and is important for source level 
debugging. To turn LTO on and off you add -flto to *_XCODE5_*_CC_FLAGS .

We ended up making LTO a configurable build option, so we control it in the DSC 
file. git

[BuildOptions]
!if $(PEI_LTO_ENABLE)
  XCODE:*_*_IA32_PLATFORM_FLAGS = -flto
!endif

!if $(DXE_LTO_ENABLE)
  XCODE:*_*_X64_PLATFORM_FLAGS = -flto
!endif

I included the Xcode 6.3.2 Numbers:

IA32 DEBUG PeiCore.efi on Ovmf build code size example:
ToolChainName  PeiCore.efi file size
VS2013x86: 40KB
CLANGLTO38:42KB
Xcode  61K

GCCLTO53:  44KB
GCC49:  55KB
CLANG38:60KB

IA32 RELEASE PeiCore.efi on Ovmf build code size example:
ToolChainName  PeiCore.efi file size
VS2013x86: 20KB
GCCLTO53:  23KB
CLANGLTO38:24KB
Xcode31K

GCC49:27KB
Clang38:   29KB

X64 DEBUG DxeCore.efi on Ovmf build code size example:
ToolChainName  .efi file size  LZMA 
Compressed size
VS2013x86:  137KB   
 57KB
CLANGLTO38:145KB61KB
Xcode157K  68K

GCCLTO53:  161KB
63KB
GCC49:273KB69KB
CLANG38:205KB   
 72KB

X64 RELEASE DxeCore.efi on Ovmf build code size example:
ToolChainName  .efi file size  LZMA 
Compressed size
VS2013x86: 95KB 
 44KB
GCCLTO53:  101KB
46KB
CLANGLTO38:107KB48KB
Xcode104K

Re: [edk2] [PATCH v2 3/3] IntelFrameworkModulePkg/BdsDxe: Show boot timeout message

2016-05-11 Thread Ryan Harkin

On 5 May 2016 at 06:09, Ni, Ruiyu  wrote:
>
>
> Regards,
> Ray
>
>>-Original Message-
>>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Daniil 
>>Egranov
>>Sent: Thursday, May 5, 2016 8:07 AM
>>To: Ni, Ruiyu ; edk2-devel@lists.01.org
>>Cc: Fan, Jeff 
>>Subject: Re: [edk2] [PATCH v2 3/3] IntelFrameworkModulePkg/BdsDxe: Show boot 
>>timeout message
>>
>>Hi Ray,
>>
>>Thanks for the review. My answers below.
>>
>>Thanks,
>>Daniil
>>
>>On 05/04/2016 12:07 AM, Ni, Ruiyu wrote:
>>> 2 comments below.
>>>
>>> Regards,
>>> Ray
>>>
 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
 Daniil Egranov
 Sent: Wednesday, May 4, 2016 9:34 AM
 To: edk2-devel@lists.01.org
 Cc: Fan, Jeff 
 Subject: [edk2] [PATCH v2 3/3] IntelFrameworkModulePkg/BdsDxe: Show boot 
 timeout message

 The PlatformBdsShowProgress() supports graphics mode only, which is not
 applicable for RS-232 serial console. Show the progress message as a 
 console
 text message in case PlatformBdsShowProgress() fails.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Daniil Egranov 
 ---
 IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

 diff --git a/IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c
 b/IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c
 index 6958979..d1a5c05 100644
 --- a/IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c
 +++ b/IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c
 @@ -925,7 +925,7 @@ ShowProgress (
  // Show progress
  //
  if (TmpStr != NULL) {
 -  PlatformBdsShowProgress (
 +  Status = PlatformBdsShowProgress (
  Foreground,
  Background,
  TmpStr,
 @@ -933,12 +933,19 @@ ShowProgress (
  ((TimeoutDefault - TimeoutRemain) * 100 / TimeoutDefault),
  0
  );
 +  if (EFI_ERROR(Status)) {
 +//if graphics mode is not supported (serial console) show 
 text progress message
 +AsciiPrint ("\rPress any key to enter Boot Menu in %d seconds 
 ", TimeoutRemain);

When I was testing this patch, I noticed that if I press "enter", it
immediately continues to boot the configured boot entry.  If I press
any other key (in reality I only tried a few like 'x' and ESC) then it
goes to the Boot Menu.

I didn't see another revision yet in response to Ruiyu's comments, so
I figured I was in time for a quick mod.

I was thinking the message could get very complex, but thought
something like this might be better:

"Press ENTER to boot now or any other key to show the Boot Menu in %d
seconds "

 +  }
>>> 1. Why use AsciiPrint but not Print(L"")?
>>> I agree they are the same but normally we use Print().
>>>
>>
>>I was not sure which one to use. I'll correct it.
>>
> Thanks!
>
>
  }
}
  }

  if (TmpStr != NULL) {
gBS->FreePool (TmpStr);
 +if (EFI_ERROR(Status)) {
 +  AsciiPrint ("\n");
 +}
>>> 2. What's the purpose of the EOL here?
>>>
>>
>>The AsciiPrint above uses cartridge return without a new line so this
>>EOL preserves last message from being erased by other console outputs.
>>
> I see. Thanks! I agree!
>
  }

  //
 --
 2.7.4

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

Re: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split FspInitPei to FspmWrapperPeim and FspsWrapperPeim.

2016-05-11 Thread Yao, Jiewen

I fork a new code base and push IntelFsp2Pkg and IntelFsp2WrapperPkg to 
g...@github.com:jyao1/edk2.git for review.

The old IntelFspPkg and IntelFspWrapperPkg are kept.

Thank you
Yao Jiewen

> -Original Message-
> From: Yao, Jiewen
> Sent: Wednesday, May 11, 2016 11:14 AM
> To: 'Tim Lewis' ; Kinney, Michael D
> ; Mudusuru, Giri P
> ; edk2-devel@lists.01.org
> Cc: Mudusuru, Giri P ; Zimmer, Vincent
> ; Rangarajan, Ravi P
> 
> Subject: RE: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split
> FspInitPei to FspmWrapperPeim and FspsWrapperPeim.
> 
> Good. I will send out IntelFsp2Pkg update soon.
> 
> > -Original Message-
> > From: Tim Lewis [mailto:tim.le...@insyde.com]
> > Sent: Wednesday, May 11, 2016 8:07 AM
> > To: Yao, Jiewen ; Kinney, Michael D
> > ; Mudusuru, Giri P
> > ; edk2-devel@lists.01.org
> > Cc: Mudusuru, Giri P ; Zimmer, Vincent
> > ; Rangarajan, Ravi P
> > 
> > Subject: RE: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split
> > FspInitPei to FspmWrapperPeim and FspsWrapperPeim.
> >
> > Yes.
> >
> > Tim
> >
> > -Original Message-
> > From: Yao, Jiewen [mailto:jiewen@intel.com]
> > Sent: Monday, May 09, 2016 6:42 PM
> > To: Kinney, Michael D ; Tim Lewis
> > ; Mudusuru, Giri P ;
> > edk2-devel@lists.01.org
> > Cc: Mudusuru, Giri P ; Zimmer, Vincent
> > ; Rangarajan, Ravi P
> > 
> > Subject: RE: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split
> > FspInitPei to FspmWrapperPeim and FspsWrapperPeim.
> >
> > Good discussion on PACKAGES_PATH usage.
> >
> > For this specific case (FSP2 without FSP1.1 support), do we need change to
> > IntelFsp2Pkg?
> >
> > Thank you
> > Yao Jiewen
> >
> > > -Original Message-
> > > From: Kinney, Michael D
> > > Sent: Friday, May 6, 2016 10:07 AM
> > > To: Tim Lewis ; Mudusuru, Giri P
> > > ; Yao, Jiewen ;
> > > edk2-devel@lists.01.org; Kinney, Michael D
> 
> > > Cc: Mudusuru, Giri P ; Zimmer, Vincent
> > > ; Rangarajan, Ravi P
> > > 
> > > Subject: RE: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split
> > > FspInitPei to FspmWrapperPeim and FspsWrapperPeim.
> > >
> > > Tim,
> > >
> > > I agree multiple repos in a WORKSPACE can potentially be confusing.
> > > Especially if the
> > > same package dir exists in more than of the repos.  To alleviate this
> issue,
> > a
> > > repo can
> > > be pruned and the .gitignore feature can be used for git to ignore the
> > > packages that
> > > have been pruned.
> > >
> > > The reason I am asking these questions is not related to FSP.
> > >
> > > There have been prior discussions on edk2-devel to organize the
> packages
> > in
> > > edk2
> > > into subdirectories, and I am working on a proposal for that.  However,
> > > moving
> > > packages into subdirectories would require the use of the
> PACKAGES_PATH
> > > feature.
> > >
> > > Is PACKAGES_PATH something you could add support for in your tools?
> > >
> > > Thanks,
> > >
> > > Mike
> > >
> > > > -Original Message-
> > > > From: Tim Lewis [mailto:tim.le...@insyde.com]
> > > > Sent: Thursday, May 5, 2016 6:53 PM
> > > > To: Kinney, Michael D ; Mudusuru, Giri P
> > > > ; Yao, Jiewen ;
> > edk2-
> > > > de...@lists.01.org
> > > > Cc: Mudusuru, Giri P ; Zimmer, Vincent
> > > > ; Rangarajan, Ravi P
> > > 
> > > > Subject: RE: [edk2] [PATCH 17/19] IntelFspWrapperPkg/FspInit: Split
> > > FspInitPei to
> > > > FspmWrapperPeim and FspsWrapperPeim.
> > > >
> > > > Mike --
> > > >
> > > > At this time, no. Our internal tools do not recognize it, and would fail
> > > during tree
> > > > analysis.
> > > >
> > > > Likewise, our policy does not allow it because we find our customers
> are
> > > confused by
> > > > multiple roots. It makes it hard for the engineers looking at a
> > downstream
> > > file to
> > > > predict where the final file resides. That leads to bad bug reports, 
> > > > etc.
> > > >
> > > > Tim
> > > >
> > > > -Original Message-
> > > > From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> > > > Sent: Thursday, May 05, 2016 6:14 PM
> > > > To: Tim Lewis ; Mudusuru, Giri P
> > > ;
> > > > Yao, Jiewen ;

Re: [edk2] OVMF boot order and efivars persistence questions

2016-05-11 Thread Laszlo Ersek

On 05/11/16 10:59, Thomas Lamprecht wrote:

> I changed out the QEMU-pure-efi.fd with the QEMU_CODE-pure-efi.fd and

Argh. I completely missed that. Sorry -- that was another problem (the
main one). I couldn't immediately remember what file did what in Gerd's
RPMs. Clearly, if you use two pflash chips, then you must not use the
unified file (that is mapped r/o) for the first one! That will shift
down the second one, which will not be accessed at all.

> got it working, this is the primary error from my side, without this the
> VARS file never got written as I used the firmware intended to be used
> without an separate VAR store.

Yes.

> One thing is a little strange for me: For getting the Boot order to work
> I have to first add an Boot entry with QEMU-disk:\EFI\BOOT\BOOTX64.EFI
> only after that the bootindex parameter from the QEMU command works,
> else a "Misc Device" is present in the boot list which also boots my OS,
> so I guess that it is pointed at BOOTX64.EFI located on the QEMU disk.
> So if I understand correctly the disk gets recognized but does not gets
> connected with the bootindex settings (=the FwCfg) but if I add manually
> an entry this "connection" works.

So this behavior follows from the "expressiveness" of the OpenFirmware
device paths that QEMU exports in the "bootorder" fw_cfg file, and that
OVMF translates to UEFI device path *prefixes*. QEMU can only identify
different devices; it cannot tell apart various files on the same device
for booting. Whereas UEFI can.

So, if you have two Boot options in your BootOrder that are on the
same device (i.e., share a UEFI device path prefix up to and excluding
the FilePath node), then the prefix that results from the translation
will be able to match both. In such cases, OVMF simply picks the first
match. (Side remark: if a UEFI boot option in question is short-form,
then the above applies after OVMF expands the boot option to full-form,
for matching.)

This is usually not a problem, because when you install your guest OS,
it will run "efibootmgr", which places the OS's boot option right at the
top of the list. Any "Misc Device" option, for the same drive, will be
added *after it* at the next boot, so when OVMF picks the first match,
it will work fine.

However, if you lose your boot options (or varstore) for whatever
reason, then you will have to re-add the OS bootloader option manually,
and also move it to the top of the list manually.

(I think that a fallback / recovery option would do this automatically,
if your OS installs one.)

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

Re: [edk2] OVMF boot order and efivars persistence questions

2016-05-11 Thread Laszlo Ersek

On 05/11/16 06:53, Gary Lin wrote:
> On Tue, May 10, 2016 at 05:29:33PM +0200, Laszlo Ersek wrote:
>> On 05/10/16 06:34, Gary Lin wrote:
>>> On Mon, May 09, 2016 at 02:58:00PM +0200, Laszlo Ersek wrote:
 On 05/09/16 13:39, Thomas Lamprecht wrote:
> [snip]
>>> Speaking of the boot order, I would like to propose to postpone the
>>> registration of the internal shell after 
>>> EfiBootManagerRefreshAllBootOption()
>>> in PlatformBootManagerAfterConsole(). The reason is to align to the
>>> behavior of the old BDS. Besides, Xen doesn't support fw_cfg and pflash,
>>> so it is really a headache to change the boot order in Xen :(
>>> With the current order, the Xen HVM always ran into the shell instead of
>>> DVD or the hard disk if there was no one to interfere. Lowering the
>>> priority of shell gives the block devices the chance to boot at least.
>>> I know the best solution is to make Xen support both fw_cfg and pflash,
>>> but it seems not going to happen in the short term.
>>
>> I think this makes sense.
>>
>> However, in this case it's not just the UEFI shell, but also the memory
>> mapped UiApp application (practically the setup UI). If you move one to
>> the end, you should probably move the other one as well.
>>
> We don't have to move UiApp. The attribute of UiApp has is 
> "LOAD_OPTION_CATEGORY_APP | LOAD_OPTION_ACTIVE | LOAD_OPTION_HIDDEN"
> and BootBootOptions will just ignore UiApp. It only will be triggered by
> the hotkeys or OsIndications.

Nice. Thanks for tracking this down.

> 
>> Gary, can you please submit a patch that works for you, CC'ing Ray in
>> addition to the OvmfPkg maintainers? The new BDS is, well, pretty new in
>> OvmfPkg, so for now I'd like some help from Ray in reviewing such changes.
>>
> Ok, I am working on it and will submit a patch later.
> 
>> ... The problem I see here is that PlatformBootManagerBeforeConsole()
>> *should* be exited with those boot options (and their hotkeys!)
>> existing. Namely, right after PlatformBootManagerBeforeConsole() returns
>> to BdsEntry(), you can see a call to EfiBootManagerStartHotkeyService().
>> I think by that time the hotkeys (and their boot options) must be in
>> place already.
>>
>> So, I believe the right to do is *not* to postpone the registration
>> until AfterConsole. Instead, how about de-registering those two options
>> right before EfiBootManagerRefreshAllBootOption(), and re-adding them
>> right after EfiBootManagerRefreshAllBootOption()?
>>
>> Also, since this may have a performance impact, I would prefer if this
>> de-register / re-register logic was restricted to Xen only. More
>> precisely, call QemuFwCfgIsAvailable() -- it's not about Xen
>> specifically; we want to know if SetBootOrderFromQemu() will have a
>> chance to do anything.
>>
> Since the order of UiApp doesn't matter, we don't have to worry about
> the hotkeys. Do you have any other concern about the delayed registration
> of the shell?

No, it's fine; I've just R-b'd your patch (and would like to see Ray
okay it too).

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

Re: [edk2] [PATCH] ArmPkg/ArmLib: don't invalidate entire I-cache on range operation

2016-05-11 Thread Mark Rutland

On Wed, May 11, 2016 at 12:23:58PM +0200, Ard Biesheuvel wrote:
> On 11 May 2016 at 12:22, Mark Rutland  wrote:
> > On Wed, May 11, 2016 at 12:07:51PM +0200, Ard Biesheuvel wrote:
> >> On 11 May 2016 at 11:35, Achin Gupta  wrote:
> >> >> diff --git 
> >> >> a/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c 
> >> >> b/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
> >> >> index 1045f9068f4d..cc7555061428 100644
> >> >> --- a/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
> >> >> +++ b/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
> >> >> @@ -65,7 +65,8 @@ InvalidateInstructionCacheRange (
> >> >>)
> >> >>  {
> >> >>CacheRangeOperation (Address, Length, 
> >> >> ArmCleanDataCacheEntryToPoUByMVA);
> >> >> -  ArmInvalidateInstructionCache ();
> >> >> +  CacheRangeOperation (Address, Length,
> >> >> +ArmInvalidateInstructionCacheEntryToPoUByMVA);
> >> >
> >> > Afaics, CacheRangeOperation() uses the data cache line length by 
> >> > default. This
> >> > will match the I$ line length in most cases. But, it would be better to 
> >> > use the
> >> > ArmInstructionCacheLineLength() function instead. I suggest that we add 
> >> > a cache
> >> > line length parameter to CacheRangeOperation() to allow the distinction.
> >> >
> >>
> >> Good point.
> >>
> >> > Also, from my reading of the ARMv8 ARM B2.6.5 & E2.6.5, we need an ISB 
> >> > at the
> >> > end of all the operations.
> >> >
> >>
> >> I would assume that a single call to
> >> ArmInstructionSynchronizationBarrier() at the end of
> >> InvalidateInstructionCacheRange () should suffice?
> >
> > Almost. You also need DSBs to complete the maintenance ops. e.g. a
> > sequence:
> >
> > d-cache maintenance ops
> > DSB
> > i-cache maintenance ops
> > DSB
> > ISB
> >
> 
> Yes, but the DSB is already performed by CacheRangeOperation (). So
> adding the ISB in InvalidateInstructionCacheRange () results in
> exactly the above.

Ah, sorry, I managed to miss that when scanning the source code.

I guess I'm just saying "yes" then. :)

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

Re: [edk2] [PATCH] OvmfPkg/PlatformBootManagerLib: Postpone the shell registration

2016-05-11 Thread Laszlo Ersek

On 05/11/16 10:40, Gary Lin wrote:
> We currently register the shell before creating the boot options for
> the block devices and the network devices, so the boot manager boots
> into the internal shell if the user doesn't specify the boot order.
> However, Xen doesn't support fw_cfg, so there is no way to change the
> boot order with the external command, and the firmware will always
> boot into the internal shell if the user doesn't interfere the boot
> process.
> 
> This patch postpones the shell registration after MdeModulePkg/BDS
> creates all the boot options for the block and network devices, so
> that firmware will try to boot the block/network devices first.
> 
> Cc: Laszlo Ersek 
> Cc: Jordan Justen 
> Cc: Ruiyu Ni 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Gary Lin 
> ---
>  OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c 
> b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> index cf774a1..a16453d 100644
> --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> @@ -184,12 +184,6 @@ PlatformRegisterOptionsAndKeys (
>   NULL, (UINT16) BootOption.OptionNumber, 0, , NULL
>   );
>ASSERT (Status == EFI_SUCCESS || Status == EFI_ALREADY_STARTED);
> -  //
> -  // Register UEFI Shell
> -  //
> -  PlatformRegisterFvBootOption (
> -PcdGetPtr (PcdShellFile), L"EFI Internal Shell", LOAD_OPTION_ACTIVE
> -);
>  }
>  
>  EFI_STATUS
> @@ -1304,6 +1298,13 @@ Routine Description:
>  
>EfiBootManagerRefreshAllBootOption ();
>  
> +  //
> +  // Register UEFI Shell
> +  //
> +  PlatformRegisterFvBootOption (
> +PcdGetPtr (PcdShellFile), L"EFI Internal Shell", LOAD_OPTION_ACTIVE
> +);
> +
>SetBootOrderFromQemu (NULL);
>  }
>  
> 

Looks good to me:

Reviewed-by: Laszlo Ersek 

I'd also like to get an R-b from Ray, before committing the patch.

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

Re: [edk2] [PATCH] ArmPkg/ArmLib: don't invalidate entire I-cache on range operation

2016-05-11 Thread Ard Biesheuvel

On 11 May 2016 at 12:22, Mark Rutland  wrote:
> On Wed, May 11, 2016 at 12:07:51PM +0200, Ard Biesheuvel wrote:
>> On 11 May 2016 at 11:35, Achin Gupta  wrote:
>> >> diff --git 
>> >> a/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c 
>> >> b/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
>> >> index 1045f9068f4d..cc7555061428 100644
>> >> --- a/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
>> >> +++ b/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
>> >> @@ -65,7 +65,8 @@ InvalidateInstructionCacheRange (
>> >>)
>> >>  {
>> >>CacheRangeOperation (Address, Length, 
>> >> ArmCleanDataCacheEntryToPoUByMVA);
>> >> -  ArmInvalidateInstructionCache ();
>> >> +  CacheRangeOperation (Address, Length,
>> >> +ArmInvalidateInstructionCacheEntryToPoUByMVA);
>> >
>> > Afaics, CacheRangeOperation() uses the data cache line length by default. 
>> > This
>> > will match the I$ line length in most cases. But, it would be better to 
>> > use the
>> > ArmInstructionCacheLineLength() function instead. I suggest that we add a 
>> > cache
>> > line length parameter to CacheRangeOperation() to allow the distinction.
>> >
>>
>> Good point.
>>
>> > Also, from my reading of the ARMv8 ARM B2.6.5 & E2.6.5, we need an ISB at 
>> > the
>> > end of all the operations.
>> >
>>
>> I would assume that a single call to
>> ArmInstructionSynchronizationBarrier() at the end of
>> InvalidateInstructionCacheRange () should suffice?
>
> Almost. You also need DSBs to complete the maintenance ops. e.g. a
> sequence:
>
> d-cache maintenance ops
> DSB
> i-cache maintenance ops
> DSB
> ISB
>

Yes, but the DSB is already performed by CacheRangeOperation (). So
adding the ISB in InvalidateInstructionCacheRange () results in
exactly the above.

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

Re: [edk2] [PATCH] ArmPkg/ArmLib: don't invalidate entire I-cache on range operation

2016-05-11 Thread Mark Rutland

On Wed, May 11, 2016 at 12:07:51PM +0200, Ard Biesheuvel wrote:
> On 11 May 2016 at 11:35, Achin Gupta  wrote:
> >> diff --git 
> >> a/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c 
> >> b/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
> >> index 1045f9068f4d..cc7555061428 100644
> >> --- a/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
> >> +++ b/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
> >> @@ -65,7 +65,8 @@ InvalidateInstructionCacheRange (
> >>)
> >>  {
> >>CacheRangeOperation (Address, Length, ArmCleanDataCacheEntryToPoUByMVA);
> >> -  ArmInvalidateInstructionCache ();
> >> +  CacheRangeOperation (Address, Length,
> >> +ArmInvalidateInstructionCacheEntryToPoUByMVA);
> >
> > Afaics, CacheRangeOperation() uses the data cache line length by default. 
> > This
> > will match the I$ line length in most cases. But, it would be better to use 
> > the
> > ArmInstructionCacheLineLength() function instead. I suggest that we add a 
> > cache
> > line length parameter to CacheRangeOperation() to allow the distinction.
> >
> 
> Good point.
> 
> > Also, from my reading of the ARMv8 ARM B2.6.5 & E2.6.5, we need an ISB at 
> > the
> > end of all the operations.
> >
> 
> I would assume that a single call to
> ArmInstructionSynchronizationBarrier() at the end of
> InvalidateInstructionCacheRange () should suffice?

Almost. You also need DSBs to complete the maintenance ops. e.g. a
sequence:

d-cache maintenance ops
DSB
i-cache maintenance ops
DSB
ISB

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

Re: [edk2] [PATCH] ArmPkg/ArmLib: don't invalidate entire I-cache on range operation

2016-05-11 Thread Achin Gupta

On Wed, May 11, 2016 at 12:07:51PM +0200, Ard Biesheuvel wrote:
> On 11 May 2016 at 11:35, Achin Gupta  wrote:
> > Hi Ard,
> >
> > Some comments inline!
> >
> > On Wed, May 11, 2016 at 10:41:57AM +0200, Ard Biesheuvel wrote:
> >> Instead of cleaning the data cache to the PoU by virtual address and
> >> subsequently invalidating the entire I-cache, invalidate only the
> >> range that we just cleaned. This way, we don't invalidate other
> >> cachelines unnecessarily.
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.0
> >> Signed-off-by: Ard Biesheuvel 
> >> ---
> >>  ArmPkg/Include/Library/ArmLib.h| 10 
> >> --
> >>  ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c |  3 ++-
> >>  ArmPkg/Library/ArmLib/AArch64/AArch64Support.S |  5 +
> >>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S |  5 +
> >>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.asm   |  6 ++
> >>  5 files changed, 26 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/ArmPkg/Include/Library/ArmLib.h 
> >> b/ArmPkg/Include/Library/ArmLib.h
> >> index 1689f0072db6..4608b0cc 100644
> >> --- a/ArmPkg/Include/Library/ArmLib.h
> >> +++ b/ArmPkg/Include/Library/ArmLib.h
> >> @@ -183,13 +183,19 @@ ArmInvalidateDataCacheEntryByMVA (
> >>
> >>  VOID
> >>  EFIAPI
> >> -ArmCleanDataCacheEntryToPoUByMVA(
> >> +ArmCleanDataCacheEntryToPoUByMVA (
> >>IN  UINTN   Address
> >>);
> >>
> >>  VOID
> >>  EFIAPI
> >> -ArmCleanDataCacheEntryByMVA(
> >> +ArmInvalidateInstructionCacheEntryToPoUByMVA (
> >> +  IN  UINTN   Address
> >> +  );
> >> +
> >> +VOID
> >> +EFIAPI
> >> +ArmCleanDataCacheEntryByMVA (
> >>  IN  UINTN   Address
> >>  );
> >>
> >> diff --git 
> >> a/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c 
> >> b/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
> >> index 1045f9068f4d..cc7555061428 100644
> >> --- a/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
> >> +++ b/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
> >> @@ -65,7 +65,8 @@ InvalidateInstructionCacheRange (
> >>)
> >>  {
> >>CacheRangeOperation (Address, Length, ArmCleanDataCacheEntryToPoUByMVA);
> >> -  ArmInvalidateInstructionCache ();
> >> +  CacheRangeOperation (Address, Length,
> >> +ArmInvalidateInstructionCacheEntryToPoUByMVA);
> >
> > Afaics, CacheRangeOperation() uses the data cache line length by default. 
> > This
> > will match the I$ line length in most cases. But, it would be better to use 
> > the
> > ArmInstructionCacheLineLength() function instead. I suggest that we add a 
> > cache
> > line length parameter to CacheRangeOperation() to allow the distinction.
> >
>
> Good point.
>
> > Also, from my reading of the ARMv8 ARM B2.6.5 & E2.6.5, we need an ISB at 
> > the
> > end of all the operations.
> >
>
> I would assume that a single call to
> ArmInstructionSynchronizationBarrier() at the end of
> InvalidateInstructionCacheRange () should suffice?

Agree. This is what I am doing locally:

@@ -64,8 +64,9 @@ InvalidateInstructionCacheRange (
   IN  UINTN Length
   )
 {
-  CacheRangeOperation (Address, Length, ArmCleanDataCacheEntryToPoUByMVA);
-  ArmInvalidateInstructionCache ();
+  CacheRangeOperation (Address, Length, ArmDataCacheLineLength(), 
ArmCleanDataCacheEntryToPoUByMVA);
+  CacheRangeOperation (Address, Length, ArmInstructionCacheLineLength(), 
ArmInvalidateInstructionCacheEntryToPoUByMVA);
+  ArmInstructionSynchronizationBarrier();
   return Address;
 }

>
> >>return Address;
> >>  }
> >>
> >> diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S 
> >> b/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
> >> index 43f7a795acec..9441f47e30ba 100644
> >> --- a/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
> >> +++ b/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
> >> @@ -23,6 +23,7 @@ GCC_ASM_EXPORT (ArmInvalidateInstructionCache)
> >>  GCC_ASM_EXPORT (ArmInvalidateDataCacheEntryByMVA)
> >>  GCC_ASM_EXPORT (ArmCleanDataCacheEntryByMVA)
> >>  GCC_ASM_EXPORT (ArmCleanDataCacheEntryToPoUByMVA)
> >> +GCC_ASM_EXPORT (ArmInvalidateInstructionCacheEntryToPoUByMVA)
> >>  GCC_ASM_EXPORT (ArmCleanInvalidateDataCacheEntryByMVA)
> >>  GCC_ASM_EXPORT (ArmInvalidateDataCacheEntryBySetWay)
> >>  GCC_ASM_EXPORT (ArmCleanDataCacheEntryBySetWay)
> >> @@ -80,6 +81,10 @@ ASM_PFX(ArmCleanDataCacheEntryToPoUByMVA):
> >>dc  cvau, x0// Clean single data cache line to PoU
> >>ret
> >>
> >> +ASM_PFX(ArmInvalidateInstructionCacheEntryToPoUByMVA):
> >> +  ic  ivau, x0// Invalidate single instruction cache line to PoU
> >> +  ret
> >> +
> >>
> >>  ASM_PFX(ArmCleanInvalidateDataCacheEntryByMVA):
> >>dc  civac, x0   // Clean and invalidate single data cache line
> >> diff --git a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S 
> >> b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S
> >> index

[edk2] [PATCH v2] ArmPkg/ArmLib: don't invalidate entire I-cache on range operation

2016-05-11 Thread Ard Biesheuvel

Instead of cleaning the data cache to the PoU by virtual address and
subsequently invalidating the entire I-cache, invalidate only the
range that we just cleaned. This way, we don't invalidate other
cachelines unnecessarily.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
v2:
- use correct stride for Icache maintenance by VA
- issue an ISB after completing the Icache maintenance

 ArmPkg/Include/Library/ArmLib.h| 10 +++--
 ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c | 23 
+++-
 ArmPkg/Library/ArmLib/AArch64/AArch64Support.S |  5 +
 ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S |  5 +
 ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.asm   |  6 +
 5 files changed, 41 insertions(+), 8 deletions(-)

diff --git a/ArmPkg/Include/Library/ArmLib.h b/ArmPkg/Include/Library/ArmLib.h
index 1689f0072db6..4608b0cc 100644
--- a/ArmPkg/Include/Library/ArmLib.h
+++ b/ArmPkg/Include/Library/ArmLib.h
@@ -183,13 +183,19 @@ ArmInvalidateDataCacheEntryByMVA (
 
 VOID
 EFIAPI
-ArmCleanDataCacheEntryToPoUByMVA(
+ArmCleanDataCacheEntryToPoUByMVA (
   IN  UINTN   Address
   );
 
 VOID
 EFIAPI
-ArmCleanDataCacheEntryByMVA(
+ArmInvalidateInstructionCacheEntryToPoUByMVA (
+  IN  UINTN   Address
+  );
+
+VOID
+EFIAPI
+ArmCleanDataCacheEntryByMVA (
 IN  UINTN   Address
 );
 
diff --git a/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c 
b/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
index 1045f9068f4d..f7667b8552d2 100644
--- a/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
+++ b/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
@@ -17,11 +17,13 @@
 #include 
 #include 
 
+STATIC
 VOID
 CacheRangeOperation (
   IN  VOID*Start,
   IN  UINTN   Length,
-  IN  LINE_OPERATION  LineOperation
+  IN  LINE_OPERATION  LineOperation,
+  IN  UINTN   LineLength
   )
 {
   UINTN ArmCacheLineLength = ArmDataCacheLineLength();
@@ -64,8 +66,14 @@ InvalidateInstructionCacheRange (
   IN  UINTN Length
   )
 {
-  CacheRangeOperation (Address, Length, ArmCleanDataCacheEntryToPoUByMVA);
-  ArmInvalidateInstructionCache ();
+  CacheRangeOperation (Address, Length, ArmCleanDataCacheEntryToPoUByMVA,
+ArmDataCacheLineLength ());
+  CacheRangeOperation (Address, Length,
+ArmInvalidateInstructionCacheEntryToPoUByMVA,
+ArmInstructionCacheLineLength ());
+
+  ArmInstructionSynchronizationBarrier ();
+
   return Address;
 }
 
@@ -85,7 +93,8 @@ WriteBackInvalidateDataCacheRange (
   IN  UINTN Length
   )
 {
-  CacheRangeOperation(Address, Length, ArmCleanInvalidateDataCacheEntryByMVA);
+  CacheRangeOperation(Address, Length, ArmCleanInvalidateDataCacheEntryByMVA,
+ArmDataCacheLineLength ());
   return Address;
 }
 
@@ -105,7 +114,8 @@ WriteBackDataCacheRange (
   IN  UINTN Length
   )
 {
-  CacheRangeOperation(Address, Length, ArmCleanDataCacheEntryByMVA);
+  CacheRangeOperation(Address, Length, ArmCleanDataCacheEntryByMVA,
+ArmDataCacheLineLength ());
   return Address;
 }
 
@@ -116,6 +126,7 @@ InvalidateDataCacheRange (
   IN  UINTN Length
   )
 {
-  CacheRangeOperation(Address, Length, ArmInvalidateDataCacheEntryByMVA);
+  CacheRangeOperation(Address, Length, ArmInvalidateDataCacheEntryByMVA,
+ArmDataCacheLineLength ());
   return Address;
 }
diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S 
b/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
index 43f7a795acec..9441f47e30ba 100644
--- a/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
+++ b/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
@@ -23,6 +23,7 @@ GCC_ASM_EXPORT (ArmInvalidateInstructionCache)
 GCC_ASM_EXPORT (ArmInvalidateDataCacheEntryByMVA)
 GCC_ASM_EXPORT (ArmCleanDataCacheEntryByMVA)
 GCC_ASM_EXPORT (ArmCleanDataCacheEntryToPoUByMVA)
+GCC_ASM_EXPORT (ArmInvalidateInstructionCacheEntryToPoUByMVA)
 GCC_ASM_EXPORT (ArmCleanInvalidateDataCacheEntryByMVA)
 GCC_ASM_EXPORT (ArmInvalidateDataCacheEntryBySetWay)
 GCC_ASM_EXPORT (ArmCleanDataCacheEntryBySetWay)
@@ -80,6 +81,10 @@ ASM_PFX(ArmCleanDataCacheEntryToPoUByMVA):
   dc  cvau, x0// Clean single data cache line to PoU
   ret
 
+ASM_PFX(ArmInvalidateInstructionCacheEntryToPoUByMVA):
+  ic  ivau, x0// Invalidate single instruction cache line to PoU
+  ret
+
 
 ASM_PFX(ArmCleanInvalidateDataCacheEntryByMVA):
   dc  civac, x0   // Clean and invalidate single data cache line
diff --git a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S 
b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S
index 50c760f335de..c765032c9e4d 100644
--- a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S
+++ b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S
@@ -18,6 +18,7 @@
 
 GCC_ASM_EXPORT (ArmInvalidateInstructionCache)
 GCC_ASM_EXPORT

Re: [edk2] [PATCH] ArmPkg/ArmLib: don't invalidate entire I-cache on range operation

2016-05-11 Thread Ard Biesheuvel

On 11 May 2016 at 11:35, Achin Gupta  wrote:
> Hi Ard,
>
> Some comments inline!
>
> On Wed, May 11, 2016 at 10:41:57AM +0200, Ard Biesheuvel wrote:
>> Instead of cleaning the data cache to the PoU by virtual address and
>> subsequently invalidating the entire I-cache, invalidate only the
>> range that we just cleaned. This way, we don't invalidate other
>> cachelines unnecessarily.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  ArmPkg/Include/Library/ArmLib.h| 10 
>> --
>>  ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c |  3 ++-
>>  ArmPkg/Library/ArmLib/AArch64/AArch64Support.S |  5 +
>>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S |  5 +
>>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.asm   |  6 ++
>>  5 files changed, 26 insertions(+), 3 deletions(-)
>>
>> diff --git a/ArmPkg/Include/Library/ArmLib.h 
>> b/ArmPkg/Include/Library/ArmLib.h
>> index 1689f0072db6..4608b0cc 100644
>> --- a/ArmPkg/Include/Library/ArmLib.h
>> +++ b/ArmPkg/Include/Library/ArmLib.h
>> @@ -183,13 +183,19 @@ ArmInvalidateDataCacheEntryByMVA (
>>
>>  VOID
>>  EFIAPI
>> -ArmCleanDataCacheEntryToPoUByMVA(
>> +ArmCleanDataCacheEntryToPoUByMVA (
>>IN  UINTN   Address
>>);
>>
>>  VOID
>>  EFIAPI
>> -ArmCleanDataCacheEntryByMVA(
>> +ArmInvalidateInstructionCacheEntryToPoUByMVA (
>> +  IN  UINTN   Address
>> +  );
>> +
>> +VOID
>> +EFIAPI
>> +ArmCleanDataCacheEntryByMVA (
>>  IN  UINTN   Address
>>  );
>>
>> diff --git a/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c 
>> b/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
>> index 1045f9068f4d..cc7555061428 100644
>> --- a/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
>> +++ b/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
>> @@ -65,7 +65,8 @@ InvalidateInstructionCacheRange (
>>)
>>  {
>>CacheRangeOperation (Address, Length, ArmCleanDataCacheEntryToPoUByMVA);
>> -  ArmInvalidateInstructionCache ();
>> +  CacheRangeOperation (Address, Length,
>> +ArmInvalidateInstructionCacheEntryToPoUByMVA);
>
> Afaics, CacheRangeOperation() uses the data cache line length by default. This
> will match the I$ line length in most cases. But, it would be better to use 
> the
> ArmInstructionCacheLineLength() function instead. I suggest that we add a 
> cache
> line length parameter to CacheRangeOperation() to allow the distinction.
>

Good point.

> Also, from my reading of the ARMv8 ARM B2.6.5 & E2.6.5, we need an ISB at the
> end of all the operations.
>

I would assume that a single call to
ArmInstructionSynchronizationBarrier() at the end of
InvalidateInstructionCacheRange () should suffice?

>>return Address;
>>  }
>>
>> diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S 
>> b/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
>> index 43f7a795acec..9441f47e30ba 100644
>> --- a/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
>> +++ b/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
>> @@ -23,6 +23,7 @@ GCC_ASM_EXPORT (ArmInvalidateInstructionCache)
>>  GCC_ASM_EXPORT (ArmInvalidateDataCacheEntryByMVA)
>>  GCC_ASM_EXPORT (ArmCleanDataCacheEntryByMVA)
>>  GCC_ASM_EXPORT (ArmCleanDataCacheEntryToPoUByMVA)
>> +GCC_ASM_EXPORT (ArmInvalidateInstructionCacheEntryToPoUByMVA)
>>  GCC_ASM_EXPORT (ArmCleanInvalidateDataCacheEntryByMVA)
>>  GCC_ASM_EXPORT (ArmInvalidateDataCacheEntryBySetWay)
>>  GCC_ASM_EXPORT (ArmCleanDataCacheEntryBySetWay)
>> @@ -80,6 +81,10 @@ ASM_PFX(ArmCleanDataCacheEntryToPoUByMVA):
>>dc  cvau, x0// Clean single data cache line to PoU
>>ret
>>
>> +ASM_PFX(ArmInvalidateInstructionCacheEntryToPoUByMVA):
>> +  ic  ivau, x0// Invalidate single instruction cache line to PoU
>> +  ret
>> +
>>
>>  ASM_PFX(ArmCleanInvalidateDataCacheEntryByMVA):
>>dc  civac, x0   // Clean and invalidate single data cache line
>> diff --git a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S 
>> b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S
>> index 50c760f335de..c765032c9e4d 100644
>> --- a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S
>> +++ b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S
>> @@ -18,6 +18,7 @@
>>
>>  GCC_ASM_EXPORT (ArmInvalidateInstructionCache)
>>  GCC_ASM_EXPORT (ArmInvalidateDataCacheEntryByMVA)
>> +GCC_ASM_EXPORT (ArmInvalidateInstructionCacheEntryToPoUByMVA)
>>  GCC_ASM_EXPORT (ArmCleanDataCacheEntryByMVA)
>>  GCC_ASM_EXPORT (ArmCleanDataCacheEntryToPoUByMVA)
>>  GCC_ASM_EXPORT (ArmCleanInvalidateDataCacheEntryByMVA)
>> @@ -74,6 +75,10 @@ ASM_PFX(ArmCleanDataCacheEntryToPoUByMVA):
>>mcr p15, 0, r0, c7, c11, 1  @clean single data cache line to PoU
>>bx  lr
>>
>> +ASM_PFX(ArmInvalidateInstructionCacheEntryToPoUByMVA):
>> +  mcr p15, 0, r0, c7, c5, 1  @Invalidate single instruction cache line 
>> to PoU
>> +  mcr p15, 0, r0, c7, c5, 7

Re: [edk2] [PATCH] ArmPkg/ArmLib: don't invalidate entire I-cache on range operation

2016-05-11 Thread Achin Gupta

Hi Ard,

Some comments inline!

On Wed, May 11, 2016 at 10:41:57AM +0200, Ard Biesheuvel wrote:
> Instead of cleaning the data cache to the PoU by virtual address and
> subsequently invalidating the entire I-cache, invalidate only the
> range that we just cleaned. This way, we don't invalidate other
> cachelines unnecessarily.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/Include/Library/ArmLib.h| 10 
> --
>  ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c |  3 ++-
>  ArmPkg/Library/ArmLib/AArch64/AArch64Support.S |  5 +
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S |  5 +
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.asm   |  6 ++
>  5 files changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/ArmPkg/Include/Library/ArmLib.h b/ArmPkg/Include/Library/ArmLib.h
> index 1689f0072db6..4608b0cc 100644
> --- a/ArmPkg/Include/Library/ArmLib.h
> +++ b/ArmPkg/Include/Library/ArmLib.h
> @@ -183,13 +183,19 @@ ArmInvalidateDataCacheEntryByMVA (
>
>  VOID
>  EFIAPI
> -ArmCleanDataCacheEntryToPoUByMVA(
> +ArmCleanDataCacheEntryToPoUByMVA (
>IN  UINTN   Address
>);
>
>  VOID
>  EFIAPI
> -ArmCleanDataCacheEntryByMVA(
> +ArmInvalidateInstructionCacheEntryToPoUByMVA (
> +  IN  UINTN   Address
> +  );
> +
> +VOID
> +EFIAPI
> +ArmCleanDataCacheEntryByMVA (
>  IN  UINTN   Address
>  );
>
> diff --git a/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c 
> b/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
> index 1045f9068f4d..cc7555061428 100644
> --- a/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
> +++ b/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
> @@ -65,7 +65,8 @@ InvalidateInstructionCacheRange (
>)
>  {
>CacheRangeOperation (Address, Length, ArmCleanDataCacheEntryToPoUByMVA);
> -  ArmInvalidateInstructionCache ();
> +  CacheRangeOperation (Address, Length,
> +ArmInvalidateInstructionCacheEntryToPoUByMVA);

Afaics, CacheRangeOperation() uses the data cache line length by default. This
will match the I$ line length in most cases. But, it would be better to use the
ArmInstructionCacheLineLength() function instead. I suggest that we add a cache
line length parameter to CacheRangeOperation() to allow the distinction.

Also, from my reading of the ARMv8 ARM B2.6.5 & E2.6.5, we need an ISB at the
end of all the operations.

>return Address;
>  }
>
> diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S 
> b/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
> index 43f7a795acec..9441f47e30ba 100644
> --- a/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
> +++ b/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
> @@ -23,6 +23,7 @@ GCC_ASM_EXPORT (ArmInvalidateInstructionCache)
>  GCC_ASM_EXPORT (ArmInvalidateDataCacheEntryByMVA)
>  GCC_ASM_EXPORT (ArmCleanDataCacheEntryByMVA)
>  GCC_ASM_EXPORT (ArmCleanDataCacheEntryToPoUByMVA)
> +GCC_ASM_EXPORT (ArmInvalidateInstructionCacheEntryToPoUByMVA)
>  GCC_ASM_EXPORT (ArmCleanInvalidateDataCacheEntryByMVA)
>  GCC_ASM_EXPORT (ArmInvalidateDataCacheEntryBySetWay)
>  GCC_ASM_EXPORT (ArmCleanDataCacheEntryBySetWay)
> @@ -80,6 +81,10 @@ ASM_PFX(ArmCleanDataCacheEntryToPoUByMVA):
>dc  cvau, x0// Clean single data cache line to PoU
>ret
>
> +ASM_PFX(ArmInvalidateInstructionCacheEntryToPoUByMVA):
> +  ic  ivau, x0// Invalidate single instruction cache line to PoU
> +  ret
> +
>
>  ASM_PFX(ArmCleanInvalidateDataCacheEntryByMVA):
>dc  civac, x0   // Clean and invalidate single data cache line
> diff --git a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S 
> b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S
> index 50c760f335de..c765032c9e4d 100644
> --- a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S
> +++ b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S
> @@ -18,6 +18,7 @@
>
>  GCC_ASM_EXPORT (ArmInvalidateInstructionCache)
>  GCC_ASM_EXPORT (ArmInvalidateDataCacheEntryByMVA)
> +GCC_ASM_EXPORT (ArmInvalidateInstructionCacheEntryToPoUByMVA)
>  GCC_ASM_EXPORT (ArmCleanDataCacheEntryByMVA)
>  GCC_ASM_EXPORT (ArmCleanDataCacheEntryToPoUByMVA)
>  GCC_ASM_EXPORT (ArmCleanInvalidateDataCacheEntryByMVA)
> @@ -74,6 +75,10 @@ ASM_PFX(ArmCleanDataCacheEntryToPoUByMVA):
>mcr p15, 0, r0, c7, c11, 1  @clean single data cache line to PoU
>bx  lr
>
> +ASM_PFX(ArmInvalidateInstructionCacheEntryToPoUByMVA):
> +  mcr p15, 0, r0, c7, c5, 1  @Invalidate single instruction cache line 
> to PoU
> +  mcr p15, 0, r0, c7, c5, 7  @Invalidate branch predictor

Is it reasonable to assume that for every Icache invalidation by MVA, the BP
will have to be invalidated for that MVA as well? I guess so!

cheers,
Achin

> +  bx  lr
>
>  ASM_PFX(ArmCleanInvalidateDataCacheEntryByMVA):
>mcr p15, 0, r0, c7, c14, 1  @clean and invalidate single data cache 
> line
> diff --git

[edk2] [Patch] BaseTools/GenFds: enhance INF built arch filter

2016-05-11 Thread Yonghong Zhu

The bug is use FILE_GUID override to build the same module more than
once, GenFds report warning "xxx NOT found in DSC file; Is it really
a binary module?". The root cause is the module path with FILE_GUID
overridden has the file name FILE_GUIDmodule.inf, then
PlatformDataBase.Modules use FILE_GUIDmodule.inf as key which cause
__GetPlatformArchList__ return empty.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/GenFds/FfsInfStatement.py | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/BaseTools/Source/Python/GenFds/FfsInfStatement.py 
b/BaseTools/Source/Python/GenFds/FfsInfStatement.py
index bba42c7..b0b22d1 100644
--- a/BaseTools/Source/Python/GenFds/FfsInfStatement.py
+++ b/BaseTools/Source/Python/GenFds/FfsInfStatement.py
@@ -568,10 +568,20 @@ class FfsInfStatement(FfsInfStatementClassObject):
 for Arch in GenFdsGlobalVariable.ArchList :
 PlatformDataBase = 
GenFdsGlobalVariable.WorkSpace.BuildObject[GenFdsGlobalVariable.ActivePlatform, 
Arch, GenFdsGlobalVariable.TargetName, GenFdsGlobalVariable.ToolChainTag]
 if  PlatformDataBase != None:
 if InfFileKey in PlatformDataBase.Modules:
 DscArchList.append (Arch)
+else:
+#
+# BaseTools support build same module more than once, the 
module path with FILE_GUID overridden has
+# the file name FILE_GUIDmodule.inf, then 
PlatformDataBase.Modules use FILE_GUIDmodule.inf as key,
+# but the path (self.MetaFile.Path) is the real path
+#
+for key in PlatformDataBase.Modules.keys():
+if InfFileKey == 
str((PlatformDataBase.Modules[key]).MetaFile.Path):
+DscArchList.append (Arch)
+break
 
 return DscArchList
 
 ## GetCurrentArch() method
 #
-- 
2.6.1.windows.1

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

[edk2] [Patch] BaseTools: Fix bug to not mix comment into Asbuilt inf Depex section

2016-05-11 Thread Yonghong Zhu

in the generated Asbuilt inf would include the driver's complete
dependency expression, and it would be wrote as comment format. Original
bug is mix the depex expression with real comment in the depex section.
this patch is ignore the real comment, and list the depex expression.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/AutoGen/AutoGen.py | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py 
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index ae0f8a6..0664101 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -2810,21 +2810,22 @@ class ModuleAutoGen(AutoGen):
 InfObj = InfSectionParser.InfSectionParser(Filename)
 DepexExpresionList = InfObj.GetDepexExpresionList()
 for DepexExpresion in DepexExpresionList:
 for key in DepexExpresion.keys():
 Arch, ModuleType = key
+DepexExpr = [x for x in DepexExpresion[key] if not 
str(x).startswith('#')]
 # the type of build module is USER_DEFINED.
 # All different DEPEX section tags would be copied into 
the As Built INF file
 # and there would be separate DEPEX section tags
 if self.ModuleType.upper() == SUP_MODULE_USER_DEFINED:
 if (Arch.upper() == self.Arch.upper()) and 
(ModuleType.upper() != TAB_ARCH_COMMON):
-DepexList.append({(Arch, ModuleType): 
DepexExpresion[key][:]})
+DepexList.append({(Arch, ModuleType): DepexExpr})
 else:
 if Arch.upper() == TAB_ARCH_COMMON or \
   (Arch.upper() == self.Arch.upper() and \
   ModuleType.upper() in [TAB_ARCH_COMMON, 
self.ModuleType.upper()]):
-DepexList.append({(Arch, ModuleType): 
DepexExpresion[key][:]})
+DepexList.append({(Arch, ModuleType): DepexExpr})
 
 #the type of build module is USER_DEFINED.
 if self.ModuleType.upper() == SUP_MODULE_USER_DEFINED:
 for Depex in DepexList:
 for key in Depex.keys():
-- 
2.6.1.windows.1

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

Re: [edk2] OVMF boot order and efivars persistence questions

2016-05-11 Thread Thomas Lamprecht


On 05/09/2016 06:06 PM, Laszlo Ersek wrote:
> On 05/09/16 17:36, Thomas Lamprecht wrote:
>
> [snip]
>
>> Ok, the OS did sets this up but when I start qemu without disk it starts
>> the UEFI shell nonetheless, if I pass a disk to the VM it will always
>> boot from this disk, still won't keep the changes which I'm making in
>> the UEFI UI.
>>
>> In the shell I see the BOOTX64.EFI:
>> ls fs0:\EFI\BOOT\BOOTX64.EFI
>>
>> and can add it with
>> bcfg boot add fs0:\EFI\BOOT\BOOTX64.EFI "Test Entry"
>>
>> But it does not survives a reboot.
>>
>> So for reference, I do now the following:
>>
>> * VM powered down
>>
>> * start it with the adapted command, this time the full command without
>> snipping in case I falsely removed some important information:
>>
>>> /usr/bin/systemd-run
>>> --scope
>>> --slice qemu
>>> --unit 7003
>>> -p KillMode=none
>>> -p CPUShares=1000 /usr/bin/kvm
>>> -id 7003
>>> -chardev socket,id=qmp,path=/var/run/qemu-server/7003.qmp,server,nowait
>>> -mon chardev=qmp,mode=control
>>> -pidfile /var/run/qemu-server/7003.pid
>>> -daemonize
>>> -smbios type=1,uuid=e2e058bc-740e-4737-8430-a73959a6188b
>>> -drive
>>> if=pflash,format=raw,unit=0,readonly,file=/usr/share/kvm/OVMF-pure-efi.fd
>>> -drive
>>> if=pflash,format=raw,unit=1,file=/var/lib/vz/images/7003/vm-7003-efi.raw
>>> -name disposable-3
>>> -smp 4,sockets=1,cores=4,maxcpus=4
>>> -nodefaults
>>> -boot menu=on
>>> -vga qxl
>>> -vnc unix:/var/run/qemu-server/7003.vnc,x509,password
>>> -cpu host,+kvm_pv_unhalt,+kvm_pv_eoi
>>> -m 6196
>>> -k de
>>> -device pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f
>>> -device pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e
>>> -device piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2
>>> -chardev socket,path=/var/run/qemu-server/7003.qga,server,nowait,id=qga0
>>> -device virtio-serial,id=qga0,bus=pci.0,addr=0x8
>>> -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0
>>> -spice
>>> tls-port=61001,addr=localhost,tls-ciphers=DES-CBC3-SHA,seamless-migration=on
>>> -device virtio-serial,id=spice,bus=pci.0,addr=0x9
>>> -chardev spicevmc,id=vdagent,name=vdagent
>>> -device virtserialport,chardev=vdagent,name=com.redhat.spice.0
>>> -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3
>>> -iscsi initiator-name=iqn.1993-08.org.debian:01:468faae9322b
>>> -drive if=none,id=drive-ide2,media=cdrom,aio=threads
>>> -device ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=200
>>> -drive
>>> file=/var/lib/vz/images/7003/vm-7003-disk-1.qcow2,if=none,id=drive-virtio0,format=qcow2,cache=none,aio=native,detect-zeroes=on
>>> -device
>>> virtio-blk-pci,drive=drive-virtio0,id=virtio0,bus=pci.0,addr=0xa,bootindex=100
>>> -netdev
>>> type=tap,id=net0,ifname=tap7003i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on
>>> -device
>>> virtio-net-pci,mac=62:33:37:36:38:63,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300
> This looks fine to me.
>
>> * install the OS (a debian based one)
> So this implies your IDE CD-ROM gets booted, right?
>
> (This works as expected -- the virtio-block disk is attempted first, but
> that is not yet bootable, so we continue to the IDE CD-ROM. Good.)
Yes, it always got booted, as it was in front of the boot order list.
>> * reboot
>>
>> * the VM boots the CD ISO again (bootindex says otherwise)
> Indeed. I have experience with Fedora and RHEL guests; and following the
> steps above, at this point I would reboot the guest from within the
> LiveCD (or the installer would automatically reboot the guest), and at
> next boot, the installed OS would come up.
>
>> * changing the boot order via UEFI UI does not persist (also setting
>> resolution, for example)
> Wow, that's bad. The resolution change is a pretty good test. It should
> Just Work (TM); it is even testable without any disk or CD-ROM images.
>
> ... I can see your QEMU binary is called "/usr/bin/kvm" -- if I recall
> correctly, that is the name under which Debian (and maybe Ubuntu?) hosts
> provide QEMU.

Yes, exactly I'm on a Debian based system and the KVM is self build as
we have our own repos and want newer versions of KVM/QEMU.

>
> Can you try the same, with upstream QEMU, from the command line (not
> systemd)?
>
> You could also save and paste the OVMF debug log somewhere (please
> search the OVMF README for "debugcon"). Note however that for me the
> debug log is most useful if you set PcdDebugPrintErrorLevel to
> 0x8040004F in the DSC files (= enable the DEBUG_VERBOSE bit), and then
> rebuild OVMF.
>
> I think it would be best if you could split up and name the log files
> according to which boot they describe (installation, first boot after
> installation etc).

Ok, I'll try that also, but I got it working for now (have to retest
everything from scratch another time but it looks promising).

I changed out the QEMU-pure-efi.fd with the QEMU_CODE-pure-efi.fd and
got it working, this is the primary error from my side, without this the
VARS file never got

59 matches

Mail list logo