date:20160628

Re: [edk2] [BaseTools] I had an issue with different paths for the same file in DSC vs. FDF files.

2016-06-28 Thread Gao, Liming

Andrew:
  Could you give one example to reproduce it? 

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Andrew Fish
> Sent: Wednesday, June 29, 2016 5:17 AM
> To: edk2-devel 
> Subject: [edk2] [BaseTools] I had an issue with different paths for the same
> file in DSC vs. FDF files.
> 
> I hit an issue with this code.
> 
> https://github.com/tianocore/edk2/blob/master/BaseTools/Source/Python/
> AutoGen/AutoGen.py#L2510
> self.SourceDir = mws.relpath(self.SourceDir, self.WorkspaceDir)
> 
> I had a combination of relative and absolute references in the DSC and FDF
> and the build did not work as the build system got confused about the
> location in the Build directory of items. So X64/MdePkg/ vs
> X64/edk2/MdePkg.
> 
> I fixed by doing this.
> self.SourceDir = os.path.relpath(mws.join(GlobalData.gWorkspace,
> self.SourceDir), self.WorkspaceDir)
> 
> I don't think that covers the case of a Path outside the workspace so an extra
> check should be added and if that check fails then call self.SourceDir =
> mws.relpath(self.SourceDir, self.WorkspaceDir).
> 
> Thanks,
> 
> Andrew Fish
> 
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] Vlv2TbltDevicePkg: Enable PCIE port 2 by default to support dual Ethernet.

2016-06-28 Thread Guo, Mang

Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Guo Mang 
---
 Vlv2TbltDevicePkg/PlatformSetupDxe/SouthClusterConfig.vfi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Vlv2TbltDevicePkg/PlatformSetupDxe/SouthClusterConfig.vfi 
b/Vlv2TbltDevicePkg/PlatformSetupDxe/SouthClusterConfig.vfi
index 258bd6f..f83d083 100644
--- a/Vlv2TbltDevicePkg/PlatformSetupDxe/SouthClusterConfig.vfi
+++ b/Vlv2TbltDevicePkg/PlatformSetupDxe/SouthClusterConfig.vfi
@@ -130,8 +130,8 @@ form formid = PCIE_DEVICE_OPTIONS_FORM_ID,
 oneof varid= Setup.IchPciExp[1],
   prompt   = STRING_TOKEN(STR_ICH_PCIERP2_PROMPT),
   help = STRING_TOKEN(STR_ICH_PCIERP_HELP),
-  option text = STRING_TOKEN(STR_ENABLE), value=1, flags= RESET_REQUIRED;
-  option text = STRING_TOKEN(STR_DISABLE), value=0, flags= DEFAULT | 
MANUFACTURING | RESET_REQUIRED;
+  option text = STRING_TOKEN(STR_ENABLE), value=1, flags= DEFAULT | 
MANUFACTURING | RESET_REQUIRED;
+  option text = STRING_TOKEN(STR_DISABLE), value=0, flags= 0 | 
RESET_REQUIRED;
 endoneof;
   endif;
 
-- 
2.8.1.windows.1

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

Re: [edk2] [PATCH 0/7] Introduce three new toolchains in edk2

2016-06-28 Thread Shi, Steven

Hi Cran,

You know to support X64 Microsoft variable argument (VA) ABI, we need two parts 
work together in edk2:

First is to the define "DEFIAPI=__attribute__((ms_abi)) in CC_FLAGS.

Second is to use below __builtin_ms_va_* builtins as the VA macro.

  __builtin_ms_va_list ap;

  __builtin_ms_va_start (ap, n);

  __builtin_ms_va_end (ap);



Only set -mabi=ms cannot really work. See the GCC example in below link.



As Andrew mentioned, we wish GCC or LLVM can natively support EFI/Windows ABIs, 
and then we don't need use special builtins and macro any longer. This request 
has been raised to GCC for ~5 years, see below link, but we has not convince 
GCC guys to implement it yet...



https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50818







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, June 29, 2016 10:22 AM

> To: Gao, Liming 

> Cc: Bruce Cran ; Shi, Steven ;

> edk2-devel@lists.01.org; Kinney, Michael D 

> Subject: Re: [edk2] [PATCH 0/7] Introduce three new toolchains in edk2

>

>

> > On Jun 28, 2016, at 7:09 PM, Gao, Liming 
> > > wrote:

> >

> > Bruce:

> >  Yes. We add EFIAPI in such function, and define "-

> DEFIAPI=__attribute__((ms_abi))" in GCC CC_FLAGS.

> >

>

> I don't know how the version of clang used was constructed, but clang is

> inherently a cross compiler and it can easily support multiple ABIs (System V

> and X64). It comes down to how it was constructed.

>

> Basically a flag like -arch x86_64 will be the system default ABI, but you can

> build other stuff for the architecture via -target x86_64-pc-win32-macho. So

> for example you might be able to enable -target x86_64-pc-win32-efl. So

> have the native EFI/Windows ABI, but make an ELF with dwarf for the

> debugger.

>

> If you don't want to use the __attribute__((ms_abi)) then you might be able

> to get that support in upstream. There might already be some support for

> cross building Windows Apps on Linux that could be leveraged. You just need

> the correctly ABI, and a source level debugging scheme that works on your

> build target.

>

> Thanks,

>

> Andrew Fish

>

> > Thanks

> > Liming

> >> -Original Message-

> >> From: Bruce Cran [mailto:br...@cran.org.uk]

> >> Sent: Wednesday, June 29, 2016 6:45 AM

> >> To: Shi, Steven >; 
> >> edk2-devel@lists.01.org; Gao,

> >> Liming >

> >> Cc: Kinney, Michael D 
> >> >; 
> >> af...@apple.com

> >> Subject: Re: [edk2] [PATCH 0/7] Introduce three new toolchains in edk2

> >>

> >> On 6/28/16 9:18 AM, Shi, Steven wrote:

> >>> Introduce three new toolchains in edk2. The first two ones support Link

> >> Time Optimization (LTO) for aggressive code size improvement and the

> third

> >> one is for static analysis.

> >>>

> >>> CLANG38: Enable LLVM Link Time Optimization (LTO) and code size

> >> optimization flag (-Os) by default for aggressive code size improvement.

> >>> X64 code is small code model + position independent code (PIE).

> >>

> >> One problem I've run into trying to build with clang is that we have a

> >> set of files which are the same across platforms, and they use varargs.

> >>

> >> With gcc, we can just set -mabi=ms and be done with it, but it appears

> >> clang doesn't have that option.  Do you know of a way to set the default

> >> ABI with clang, or would we need to add an __attribute__((ms_abi))

> >> anywhere we need to use varargs?

> >>

> >> --

> >> Bruce Cran

> > ___

> > 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/IndustryStandard: fix build break due to latest Atapi.h change

2016-06-28 Thread Tian, Feng

All,

I will check in this fix soon as it breaks all build.

Thanks
Feng

-Original Message-
From: Gao, Liming 
Sent: Wednesday, June 29, 2016 11:26 AM
To: Tian, Feng 
Cc: edk2-devel@lists.01.org
Subject: RE: [edk2] [patch] MdePkg/IndustryStandard: fix build break due to 
latest Atapi.h change

Reviewed-by: Liming Gao 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Feng Tian
> Sent: Wednesday, June 29, 2016 11:12 AM
> To: Gao, Liming 
> Cc: edk2-devel@lists.01.org
> Subject: [edk2] [patch] MdePkg/IndustryStandard: fix build break due 
> to latest Atapi.h change
> 
> Update the new introduced ATA_CMD_SEEK to ATA_CMD_ATAPI_SEEK.
> 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Feng Tian 
> ---
>  MdePkg/Include/IndustryStandard/Atapi.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/MdePkg/Include/IndustryStandard/Atapi.h
> b/MdePkg/Include/IndustryStandard/Atapi.h
> index 088e914..0df802e 100644
> --- a/MdePkg/Include/IndustryStandard/Atapi.h
> +++ b/MdePkg/Include/IndustryStandard/Atapi.h
> @@ -2,7 +2,7 @@
>This file contains just some basic definitions that are needed by drivers
>that dealing with ATA/ATAPI interface.
> 
> -Copyright (c) 2007 - 2013, Intel Corporation. All rights 
> reserved.
> +Copyright (c) 2007 - 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 @@ -502,7 +502,7 @@ 
> typedef union {
>  #define ATA_CMD_READ_CAPACITY   0x25   ///< defined 
> in
> ATAPI Removable Rewritable Media Devcies
>  #define ATA_CMD_READ_10 0x28   ///< defined 
> in ATAPI
> Removable Rewritable Media Devcies
>  #define ATA_CMD_WRITE_100x2A   ///< defined 
> in ATAPI
> Removable Rewritable Media Devcies
> -#define ATA_CMD_SEEK0x2B   ///< defined 
> in ATAPI
> Removable Rewritable Media Devcies
> +#define ATA_CMD_ATAPI_SEEK  0x2B   ///< defined 
> in ATAPI
> Removable Rewritable Media Devcies
>  #define ATA_CMD_WRITE_AND_VERIFY0x2E   ///< defined 
> in
> ATAPI Removable Rewritable Media Devcies
>  #define ATA_CMD_VERIFY  0x2F   ///< defined 
> in ATAPI
> Removable Rewritable Media Devcies
>  #define ATA_CMD_READ_12 0xA8   ///< defined 
> in ATAPI
> Removable Rewritable Media Devcies
> --
> 2.7.1.windows.2
> 
> ___
> 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] Segfault in GenFw when building driver with new CLANG38 toolchain

2016-06-28 Thread Andrew Fish


> On Jun 28, 2016, at 9:34 PM, Bruce Cran  wrote:
> 
> 
> On 6/28/2016 10:28 PM, Shi, Steven wrote:
> 
>> OK. How about GCC53?  Can GCC53 build your driver?
> 
> Yes, GCC53 works fine (the"gcc" it runs actually being gcc 6.1.1). Sorry, I 
> know not having access to the driver binary will make it almost impossible to 
> debug!
> 

Do you get the error with LTO disabled? Some times missing memcpy/memset are 
caused by a structure assignment and it depends on optimizer behavior. This 
might not be it because the most common place I see this is setting clang to 
-O0. It seems to catch things that VC++ misses. 

Thanks,

Andrew Fish

> -- 
> Bruce
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel=CwICAg=Hw-EJUFt2_D9PK5csBJ29kRV40HqSDXWTLPyZ6W8u84=4sdzHKz0eU1vXqaUySVmyA=mzGdrQqGG2F1RdpdG80w0iDLQCwme1Od6mU0Ryy9S_4=MVOrEPjWpDmfC667DwrbL5DGii7MATieqcOroPGHFFo=
>  

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

Re: [edk2] Segfault in GenFw when building driver with new CLANG38 toolchain

2016-06-28 Thread Bruce Cran


On 6/28/2016 10:28 PM, Shi, Steven wrote:


OK. How about GCC53?  Can GCC53 build your driver?


Yes, GCC53 works fine (the"gcc" it runs actually being gcc 6.1.1). 
Sorry, I know not having access to the driver binary will make it almost 
impossible to debug!


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

Re: [edk2] [PATCH v2] MdeModulePkg: Skip registering BootManagerMenu if its FFS is not found

2016-06-28 Thread Wang, Sunny (HPS SW)

Just a update. After offline discussing with Ray, I will send patch v3 based on 
some of his comments listed below and some further updates coming from our 
offline discussion.

Regards,
Sunny Wang

-Original Message-
From: Ni, Ruiyu [mailto:ruiyu...@intel.com] 
Sent: Wednesday, June 29, 2016 10:26 AM
To: Wang, Sunny (HPS SW) ; edk2-devel@lists.01.org
Subject: RE: [edk2] [PATCH v2] MdeModulePkg: Skip registering BootManagerMenu 
if its FFS is not found
Importance: High

Sunny,
I have 7 minor comments. Please check below.

Regards,
Ray

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>Sunny Wang
>Sent: Tuesday, June 28, 2016 10:27 AM
>To: edk2-devel@lists.01.org
>Cc: Ni, Ruiyu 
>Subject: [edk2] [PATCH v2] MdeModulePkg: Skip registering 
>BootManagerMenu if its FFS is not found
>
>This is a enhancement to support the case when platform firmware doesn’t 
>support Boot Manager Menu.
>For now, if BootManagerMenu FFS can not be retrieved from FV, BDS core 
>code will still register a boot option for it. Then, this 
>non-functional boot option will still be booted by user's request (like 
>HotKey or Exit from shell) to cause additional boot time and error 
>status code reported. Therefore, it would be good to skip BootManagerMenu boot 
>option registration and then return error status and Invalid BootOption data 
>for this case so that the BootManagerBoot() or other consumers can directly 
>return without doing anything.
>
>Contributed-under: TianoCore Contribution Agreement 1.0
>Signed-off-by: Sunny Wang 
>---
> MdeModulePkg/Include/Library/UefiBootManagerLib.h  |  7 ++--
> MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c   | 39 ++
> MdeModulePkg/Library/UefiBootManagerLib/BmHotkey.c |  9 +++--
> MdeModulePkg/Universal/BdsDxe/BdsEntry.c   | 29 +++-
> 4 files changed, 64 insertions(+), 20 deletions(-)
>
>diff --git a/MdeModulePkg/Include/Library/UefiBootManagerLib.h 
>b/MdeModulePkg/Include/Library/UefiBootManagerLib.h
>index 0fdb23d..649af9a 100644
>--- a/MdeModulePkg/Include/Library/UefiBootManagerLib.h
>+++ b/MdeModulePkg/Include/Library/UefiBootManagerLib.h
>@@ -418,12 +418,13 @@ EfiBootManagerBoot (
>   );
>
> /**
>-  Return the Boot Manager Menu.
>-
>+  Return the boot option corresponding to the Boot Manager Menu.
>+  It may automatically create one if the boot option hasn't been created yet.
>+
>   @param BootOptionReturn the Boot Manager Menu.
>
>   @retval EFI_SUCCESS   The Boot Manager Menu is successfully returned.
>-  @retval EFI_NOT_FOUND The Boot Manager Menu is not found.
>+  @retval StatusReturn status of either gRT->SetVariable () or 
>GetSectionFromFv().
> **/

1. How about we change the return status as following:
  @retval EFI_SUCCESS   The Boot Manager Menu is successfully returned.
  @retval EFI_NOT_FOUND The Boot Manager Menu cannot be found.
  @retval others Return status of gRT->SetVariable (). BootOption still 
points
to the Boot Manager Menu even the Status is not 
EFI_SUCCESS
and EFI_NOT_FOUND.

> EFI_STATUS
> EFIAPI
>diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
>b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
>index d016517..17e416a 100644
>--- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
>+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
>@@ -2,7 +2,7 @@
>   Library functions which relates with booting.
>
> Copyright (c) 2011 - 2016, Intel Corporation. All rights reserved.
>-(C) Copyright 2015 Hewlett Packard Enterprise Development LP
>+(C) Copyright 2015-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 @@ -2159,16 +2159,19 @@ EfiBootManagerRefreshAllBootOption (  
>}
>
> /**
>-  This function is called to create the boot option for the Boot Manager Menu.
>+  This function is called to get or create the boot option for the Boot 
>Manager Menu.
>
>   The Boot Manager Menu is shown after successfully booting a boot option.
>   Assume the BootManagerMenuFile is in the same FV as the module links to 
> this library.
>
>-  @param  BootOptionReturn the boot option of the Boot Manager Menu
>+  @param  BootOptionReturn the boot option of the Boot Manager Menu.
>+If BootManagerMenu fails to be set as a Boot 
>variables, BootOption
>+still points to the Boot Manager Menu.
>+If BootManagerMenu FFS section can not be retrieved, 
>BootOption will
>+be contain invalid data to prevent other function 
>from using it.
>
>   @retval EFI_SUCCESS   Successfully register the Boot Manager Menu.
>-  @retval StatusReturn

Re: [edk2] Segfault in GenFw when building driver with new CLANG38 toolchain

2016-06-28 Thread Shi, Steven

OK. How about GCC53?  Can GCC53 build your driver?


Steven Shi
Intel\SSG\STO\UEFI Firmware

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


> -Original Message-
> From: Bruce Cran [mailto:br...@cran.org.uk]
> Sent: Wednesday, June 29, 2016 12:12 PM
> To: Shi, Steven ; edk2-devel@lists.01.org
> Subject: Re: Segfault in GenFw when building driver with new CLANG38
> toolchain
> 
> On 6/28/2016 9:51 PM, Shi, Steven wrote:
> 
> > Can you build the OVMF with CLANG38 in your side?
> > And if possible, pls send me your driver .dll Elf image and I can try to 
> > debug
> the GenFw convert in my side.
> 
> Yes, both DEBUG and RELEASE X64 builds of OVMF complete fine.
> 
> I wish I could send the driver binaries, but I'd need to get sign-off
> from Legal, and considering the delay and work involved, I'm not sure
> it's worth it. I'll see if I can find some time to play around with
> settings etc. to see if I can see what's going wrong.
> 
> Thanks.
> Bruce
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Segfault in GenFw when building driver with new CLANG38 toolchain

2016-06-28 Thread Bruce Cran


On 6/28/2016 9:51 PM, Shi, Steven wrote:


Can you build the OVMF with CLANG38 in your side?
And if possible, pls send me your driver .dll Elf image and I can try to debug 
the GenFw convert in my side.


Yes, both DEBUG and RELEASE X64 builds of OVMF complete fine.

I wish I could send the driver binaries, but I'd need to get sign-off 
from Legal, and considering the delay and work involved, I'm not sure 
it's worth it. I'll see if I can find some time to play around with 
settings etc. to see if I can see what's going wrong.


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

Re: [edk2] Segfault in GenFw when building driver with new CLANG38 toolchain

2016-06-28 Thread Shi, Steven

Hi Cran,
Can you build the OVMF with CLANG38 in your side? 
And if possible, pls send me your driver .dll Elf image and I can try to debug 
the GenFw convert in my side.


Steven Shi
Intel\SSG\STO\UEFI Firmware

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


> -Original Message-
> From: Bruce Cran [mailto:br...@cran.org.uk]
> Sent: Wednesday, June 29, 2016 11:37 AM
> To: edk2-devel@lists.01.org
> Cc: Shi, Steven 
> Subject: Segfault in GenFw when building driver with new CLANG38 toolchain
> 
> After applying Steven's (cc'd) patch set and building our driver with
> the CLANG38 toolchain, GenFw crashes with a segmentation fault.  Due to
> unresolved memset and memcpy symbols, I've added the flags "-fbuiltin
> -fno-lto".
> 
> #0  0x0040bccf in WriteRelocations64 () at Elf64Convert.c:975
> #1  0x00408219 in ConvertElf (FileBuffer=0x7fffde28,
> FileLength=0x7fffde24) at ElfConvert.c:207
> #2  0x00405189 in main (argc=0, argv=0x7fffe098) at
> GenFw.c:2031
> 
> 
> Elf64Convert.c:975:  VerboseMsg ("Relocation: 0x%08X",
> *(UINT64*)CoffFileGoTPcRelPtr);
> 
> (gdb) p CoffFileGoTPcRelPtr
> 
> $1 = (UINT64 *) 0x776f8160
> 
> (gdb) p *CoffFileGoTPcRelPtr
> 
> Cannot access memory at address 0x776f8160
> 
> 
> --
> Bruce

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

[edk2] Segfault in GenFw when building driver with new CLANG38 toolchain

2016-06-28 Thread Bruce Cran

After applying Steven's (cc'd) patch set and building our driver with 
the CLANG38 toolchain, GenFw crashes with a segmentation fault.  Due to 
unresolved memset and memcpy symbols, I've added the flags "-fbuiltin 
-fno-lto".


#0  0x0040bccf in WriteRelocations64 () at Elf64Convert.c:975
#1  0x00408219 in ConvertElf (FileBuffer=0x7fffde28, 
FileLength=0x7fffde24) at ElfConvert.c:207

#2  0x00405189 in main (argc=0, argv=0x7fffe098) at GenFw.c:2031


Elf64Convert.c:975:  VerboseMsg ("Relocation: 0x%08X", 
*(UINT64*)CoffFileGoTPcRelPtr);


(gdb) p CoffFileGoTPcRelPtr

$1 = (UINT64 *) 0x776f8160

(gdb) p *CoffFileGoTPcRelPtr

Cannot access memory at address 0x776f8160


--
Bruce

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

Re: [edk2] [patch] MdePkg/IndustryStandard: fix build break due to latest Atapi.h change

2016-06-28 Thread Gao, Liming

Reviewed-by: Liming Gao 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Feng Tian
> Sent: Wednesday, June 29, 2016 11:12 AM
> To: Gao, Liming 
> Cc: edk2-devel@lists.01.org
> Subject: [edk2] [patch] MdePkg/IndustryStandard: fix build break due to
> latest Atapi.h change
> 
> Update the new introduced ATA_CMD_SEEK to ATA_CMD_ATAPI_SEEK.
> 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Feng Tian 
> ---
>  MdePkg/Include/IndustryStandard/Atapi.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/MdePkg/Include/IndustryStandard/Atapi.h
> b/MdePkg/Include/IndustryStandard/Atapi.h
> index 088e914..0df802e 100644
> --- a/MdePkg/Include/IndustryStandard/Atapi.h
> +++ b/MdePkg/Include/IndustryStandard/Atapi.h
> @@ -2,7 +2,7 @@
>This file contains just some basic definitions that are needed by drivers
>that dealing with ATA/ATAPI interface.
> 
> -Copyright (c) 2007 - 2013, Intel Corporation. All rights reserved.
> +Copyright (c) 2007 - 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
> @@ -502,7 +502,7 @@ typedef union {
>  #define ATA_CMD_READ_CAPACITY   0x25   ///< defined 
> in
> ATAPI Removable Rewritable Media Devcies
>  #define ATA_CMD_READ_10 0x28   ///< defined 
> in ATAPI
> Removable Rewritable Media Devcies
>  #define ATA_CMD_WRITE_100x2A   ///< defined 
> in ATAPI
> Removable Rewritable Media Devcies
> -#define ATA_CMD_SEEK0x2B   ///< defined 
> in ATAPI
> Removable Rewritable Media Devcies
> +#define ATA_CMD_ATAPI_SEEK  0x2B   ///< defined 
> in ATAPI
> Removable Rewritable Media Devcies
>  #define ATA_CMD_WRITE_AND_VERIFY0x2E   ///< defined 
> in
> ATAPI Removable Rewritable Media Devcies
>  #define ATA_CMD_VERIFY  0x2F   ///< defined 
> in ATAPI
> Removable Rewritable Media Devcies
>  #define ATA_CMD_READ_12 0xA8   ///< defined 
> in ATAPI
> Removable Rewritable Media Devcies
> --
> 2.7.1.windows.2
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [patch] MdeModulePkg/EmmcDxe: Don't expose BlockIo interface for RPMB partition

2016-06-28 Thread Feng Tian

This change is to avoid UEFI SCT failure as UEFI SCT has no knowledge
about how to accessing a EMMC RPMB partition.

The user needs to access RPMB partition should get access through
EFI_SD_MMC_PASS_THRU protocol with authentication key & mac.

Cc: Hao Wu 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Feng Tian 
---
 MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c | 138 +++---
 1 file changed, 45 insertions(+), 93 deletions(-)

diff --git a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c 
b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c
index d3602a5..5040882 100644
--- a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c
+++ b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c
@@ -443,77 +443,60 @@ InstallProtocolOnPartition (
 //
 // Install BlkIo/BlkIo2/Ssp for the specified partition
 //
-Status = gBS->InstallMultipleProtocolInterfaces (
->Handle,
-,
-Partition->DevicePath,
-,
->BlockIo,
-,
->BlockIo2,
-NULL
-);
-if (EFI_ERROR (Status)) {
-  goto Error;
-}
-
 if (Partition->PartitionType != EmmcPartitionRPMB) {
-  Status = gBS->InstallProtocolInterface (
+  Status = gBS->InstallMultipleProtocolInterfaces (
   >Handle,
+  ,
+  Partition->DevicePath,
+  ,
+  >BlockIo,
+  ,
+  >BlockIo2,
   ,
-  EFI_NATIVE_INTERFACE,
-  >EraseBlock
+  >EraseBlock,
+  NULL
   );
   if (EFI_ERROR (Status)) {
-gBS->UninstallMultipleProtocolInterfaces (
-   >Handle,
-   ,
-   Partition->DevicePath,
-   ,
-   >BlockIo,
-   ,
-   >BlockIo2,
-   NULL
-   );
 goto Error;
   }
-}
 
-if (((Partition->PartitionType == EmmcPartitionUserData) ||
-(Partition->PartitionType == EmmcPartitionBoot1) ||
-(Partition->PartitionType == EmmcPartitionBoot2)) &&
-((Device->Csd.Ccc & BIT10) != 0)) {
-  Status = gBS->InstallProtocolInterface (
-  >Handle,
-  ,
-  EFI_NATIVE_INTERFACE,
-  >StorageSecurity
-  );
-  if (EFI_ERROR (Status)) {
-gBS->UninstallMultipleProtocolInterfaces (
-   >Handle,
-   ,
-   Partition->DevicePath,
-   ,
-   >BlockIo,
-   ,
-   >BlockIo2,
-   ,
-   >EraseBlock,
-   NULL
-   );
-goto Error;
+  if (((Partition->PartitionType == EmmcPartitionUserData) ||
+  (Partition->PartitionType == EmmcPartitionBoot1) ||
+  (Partition->PartitionType == EmmcPartitionBoot2)) &&
+  ((Device->Csd.Ccc & BIT10) != 0)) {
+Status = gBS->InstallProtocolInterface (
+>Handle,
+,
+EFI_NATIVE_INTERFACE,
+>StorageSecurity
+);
+if (EFI_ERROR (Status)) {
+  gBS->UninstallMultipleProtocolInterfaces (
+ >Handle,
+ ,
+ Partition->DevicePath,
+ ,
+ >BlockIo,
+ ,
+ >BlockIo2,
+ ,
+ >EraseBlock,
+ NULL
+ );
+  goto Error;
+}
   }
+
+  gBS->OpenProtocol (
+ Device->Private->Controller,
+ ,
+ (VOID **) &(Device->Private->PassThru),
+ Device->Private->DriverBindingHandle,
+ Partition->Handle,
+ EFI_OPEN_PROTOCOL_BY_CHILD_CONTROLLER
+ );
 }
 
-gBS->OpenProtocol (
-   Device->Private->Controller,
-   ,
-   (VOID **) &(Device->Private->PassThru),
-   Device->Private->DriverBindingHandle,
-   Partition->Handle,
-   EFI_OPEN_PROTOCOL_BY_CHILD_CONTROLLER
-   );
   } else {
 Status = EFI_INVALID_PARAMETER;
   }
@@ -993,7 +976,6 @@ EmmcDxeDriverBindingStop (
   EFI_BLOCK_IO_PROTOCOL  *BlockIo;
   EFI_BLOCK_IO2_PROTOCOL *BlockIo2;
   EFI_STORAGE_SECURITY_COMMAND_PROTOCOL  *StorageSecurity;
-  EFI_ERASE_BLOCK_PROTOCOL   *EraseBlock;
   LIST_ENTRY *Link;
   LIST_ENTRY *NextLink;
   EMMC_REQUEST   *Request;
@@ -1120,6 +1102,8 @@ EmmcDxeDriverBindingStop (
 >BlockIo,
 ,

[edk2] [patch] MdePkg/IndustryStandard: fix build break due to latest Atapi.h change

2016-06-28 Thread Feng Tian

Update the new introduced ATA_CMD_SEEK to ATA_CMD_ATAPI_SEEK.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Feng Tian 
---
 MdePkg/Include/IndustryStandard/Atapi.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdePkg/Include/IndustryStandard/Atapi.h 
b/MdePkg/Include/IndustryStandard/Atapi.h
index 088e914..0df802e 100644
--- a/MdePkg/Include/IndustryStandard/Atapi.h
+++ b/MdePkg/Include/IndustryStandard/Atapi.h
@@ -2,7 +2,7 @@
   This file contains just some basic definitions that are needed by drivers
   that dealing with ATA/ATAPI interface.
 
-Copyright (c) 2007 - 2013, Intel Corporation. All rights reserved.
+Copyright (c) 2007 - 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
@@ -502,7 +502,7 @@ typedef union {
 #define ATA_CMD_READ_CAPACITY   0x25   ///< defined in 
ATAPI Removable Rewritable Media Devcies
 #define ATA_CMD_READ_10 0x28   ///< defined in 
ATAPI Removable Rewritable Media Devcies
 #define ATA_CMD_WRITE_100x2A   ///< defined in 
ATAPI Removable Rewritable Media Devcies
-#define ATA_CMD_SEEK0x2B   ///< defined in 
ATAPI Removable Rewritable Media Devcies
+#define ATA_CMD_ATAPI_SEEK  0x2B   ///< defined in 
ATAPI Removable Rewritable Media Devcies
 #define ATA_CMD_WRITE_AND_VERIFY0x2E   ///< defined in 
ATAPI Removable Rewritable Media Devcies
 #define ATA_CMD_VERIFY  0x2F   ///< defined in 
ATAPI Removable Rewritable Media Devcies
 #define ATA_CMD_READ_12 0xA8   ///< defined in 
ATAPI Removable Rewritable Media Devcies
-- 
2.7.1.windows.2

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

Re: [edk2] [PATCH] [MdePkg ] Additional Atapi.h definitions complying Industry Standard specifications.

2016-06-28 Thread Tian, Feng

Hi, Anandakrishnan

Your patch makes the build break.

warning C4005: 'ATA_CMD_SEEK': macro redefinition

I would submit patch to update those ATPI cmds prefix from ATA_ to ATAPI_.

Thanks
Feng

-Original Message-
From: Tian, Feng 
Sent: Tuesday, June 28, 2016 9:37 PM
To: Gao, Liming ; Anandakrishnan Loganathan 
; edk2-devel@lists.01.org
Cc: Tian, Feng 
Subject: RE: [PATCH] [MdePkg ] Additional Atapi.h definitions complying 
Industry Standard specifications.

Hi, Anandakrishnan

Reviewed-by: Feng Tian 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao, 
Liming
Sent: Monday, June 27, 2016 5:15 PM
To: Anandakrishnan Loganathan ; edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH] [MdePkg ] Additional Atapi.h definitions complying 
Industry Standard specifications.

Got it. We will review this change. 

> -Original Message-
> From: Anandakrishnan Loganathan [mailto:anandakrishn...@ami.com]
> Sent: Monday, June 27, 2016 5:12 PM
> To: Gao, Liming ; edk2-devel@lists.01.org
> Subject: RE: [PATCH] [MdePkg ] Additional Atapi.h definitions 
> complying Industry Standard specifications.
> 
> Hi Gao,
> 
> Sorry.. I will check the problem in creating the patch my side. 
> Meanwhile I have attached the Atapi.h for your reference
> 
> Thanks!
> 
> 
> -Original Message-
> From: Gao, Liming [mailto:liming@intel.com]
> Sent: 27 June 2016 14:33
> To: Anandakrishnan Loganathan; edk2-devel@lists.01.org
> Subject: RE: [PATCH] [MdePkg ] Additional Atapi.h definitions 
> complying Industry Standard specifications.
> 
> Anandakrishnan:
>Your patch format is Unicode. I can't apply it. Could you create 
> the normal GIT patch or directly send the updated Atapi.h?
> 
> > -Original Message-
> > From: Anandakrishnan Loganathan [mailto:anandakrishn...@ami.com]
> > Sent: Monday, June 27, 2016 2:02 PM
> > To: Gao, Liming ; edk2-devel@lists.01.org
> > Subject: RE: [PATCH] [MdePkg ] Additional Atapi.h definitions 
> > complying Industry Standard specifications.
> >
> > Attached the Patch with the mail
> >
> > -Original Message-
> > From: Gao, Liming [mailto:liming@intel.com]
> > Sent: 27 June 2016 09:41
> > To: Anandakrishnan Loganathan; edk2-devel@lists.01.org
> > Subject: RE: [PATCH] [MdePkg ] Additional Atapi.h definitions 
> > complying Industry Standard specifications.
> >
> > Hi, could you attach your patch?
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On 
> > > Behalf Of Anandakrishnan Loganathan
> > > Sent: Friday, June 24, 2016 4:56 PM
> > > To: edk2-devel@lists.01.org
> > > Subject: [edk2] [PATCH] [MdePkg ] Additional Atapi.h definitions 
> > > complying Industry Standard specifications.
> > >
> > > Dear MdePkg maintainer,
> > >
> > >
> > > Atapi.h  has only limited ATA/ATAPI related specification 
> > > definitions and this attached patch includes various commonly 
> > > usage Industry Standard definitions in Atapi.h. Please review and 
> > > update to the
> MdePkg.
> > >
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.0
> > > Signed-off-by: Anandakrishnan Loganathan 
> > > anandakrishn...@ami.com
> > >
> > >
> > > Thanks!
> > > Anandakrishnan
> > > ___
> > > 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] [BaseTools] I hit what looked like a case issue in the construction of the build report.

2016-06-28 Thread Gao, Liming

Andrew:
   Thanks for your report it. It may be caused by self.CurrentFvName = 
FvName.upper()
https://github.com/tianocore/edk2/blob/master/BaseTools/Source/Python/GenFds/FdfParser.py#L2134

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Andrew Fish
> Sent: Wednesday, June 29, 2016 5:17 AM
> To: edk2-devel 
> Subject: [edk2] [BaseTools] I hit what looked like a case issue in the
> construction of the build report.
> 
> 
> I ran into a case issue with this code.
> FvReportFileName = os.path.join(self._FvDir, FvName + ".Fv.txt")
> https://github.com/tianocore/edk2/blob/master/BaseTools/Source/Python/
> build/BuildReport.py#L1462
> 
> I ended up testing FvReportFileName and if it was not found I forced
> FvName to all upper case. That fixed the issue. I'm not sure if the test is 
> really
> needed. It only fails on a case sensitive filesystem.
> 
> Thanks,
> 
> Andrew Fish
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/7] Introduce three new toolchains in edk2

2016-06-28 Thread Bruce Cran


On 6/28/2016 8:09 PM, Gao, Liming wrote:

   Yes. We add EFIAPI in such function, and define 
"-DEFIAPI=__attribute__((ms_abi))" in GCC CC_FLAGS.


Thanks. Unfortunately the code needs to remain portable across Windows, 
Linux and other systems, so the best solution is probably a macro 
similar to EFIAPI but which isn't specific to UEFI.


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

[edk2] [PATCH] MdeModulePkg/PiSmmCore: Replace BASE_4GB with MAX_ADDRESS check.

2016-06-28 Thread Jiewen Yao

PI specification Vol 4 - SMM does not have any limitation of BASE_4GB for SMM.
So we should replace BASE_4GB check with MAX_ADDRESS check to make sure
the SMM memory is accessible by SMM Core.

Cc: Jeff Fan 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
---
 MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c | 2 +-
 MdeModulePkg/Core/PiSmmCore/Pool.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c 
b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
index acfcc83..3788bd5 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
@@ -1556,7 +1556,7 @@ SmmIplEntry (
 }
 
 if (gSmmCorePrivate->SmramRanges[Index].CpuStart >= BASE_1MB) {
-  if ((gSmmCorePrivate->SmramRanges[Index].CpuStart + 
gSmmCorePrivate->SmramRanges[Index].PhysicalSize) <= BASE_4GB) {
+  if ((gSmmCorePrivate->SmramRanges[Index].CpuStart + 
gSmmCorePrivate->SmramRanges[Index].PhysicalSize) <= MAX_ADDRESS) {
 if (gSmmCorePrivate->SmramRanges[Index].PhysicalSize >= MaxSize) {
   MaxSize = gSmmCorePrivate->SmramRanges[Index].PhysicalSize;
   mCurrentSmramRange = >SmramRanges[Index];
diff --git a/MdeModulePkg/Core/PiSmmCore/Pool.c 
b/MdeModulePkg/Core/PiSmmCore/Pool.c
index 761988e..e493fd2 100644
--- a/MdeModulePkg/Core/PiSmmCore/Pool.c
+++ b/MdeModulePkg/Core/PiSmmCore/Pool.c
@@ -67,7 +67,7 @@ SmmInitializeMemoryServices (
   }
 
   if (SmramRanges[Index].CpuStart >= BASE_1MB) {
-if ((SmramRanges[Index].CpuStart + SmramRanges[Index].PhysicalSize) <= 
BASE_4GB) {
+if ((SmramRanges[Index].CpuStart + SmramRanges[Index].PhysicalSize) <= 
MAX_ADDRESS) {
   if (SmramRanges[Index].PhysicalSize >= MaxSize) {
 MaxSize = SmramRanges[Index].PhysicalSize;
 CurrentSmramRangesIndex = Index;
-- 
2.7.4.windows.1

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

Re: [edk2] [PATCH 5/6] UefiCpuPkg: fix ASSERT_EFI_ERROR() typos

2016-06-28 Thread Mudusuru, Giri P

Reviewed-by: Giri P Mudusuru  

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Fan,
> Jeff
> Sent: Tuesday, June 28, 2016 7:02 PM
> To: Laszlo Ersek ; edk2-devel-01  de...@ml01.01.org>
> Subject: Re: [edk2] [PATCH 5/6] UefiCpuPkg: fix ASSERT_EFI_ERROR() typos
> 
> Reviewed-by: Jeff Fan 
> 
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, June 28, 2016 9:26 PM
> To: edk2-devel-01
> Cc: Fan, Jeff
> Subject: [PATCH 5/6] UefiCpuPkg: fix ASSERT_EFI_ERROR() typos
> 
> A number of code locations use
> 
>   ASSERT_EFI_ERROR (BooleanExpression)
> 
> instead of
> 
>   ASSERT (BooleanExpression)
> 
> Fix them.
> 
> Cc: Jeff Fan 
> Reported-by: Gerd Hoffmann 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmProfileArch.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmProfileArch.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmProfileArch.c
> index 79e23ef6476e..065fb2c24c7d 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmProfileArch.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmProfileArch.c
> @@ -78,7 +78,7 @@ InitPagesForPFHandler (
>//
>Address = NULL;
>Address = AllocatePages (MAX_PF_PAGE_COUNT);
> -  ASSERT_EFI_ERROR (Address != NULL);
> +  ASSERT (Address != NULL);
> 
>mPFPageBuffer =  (UINT64)(UINTN) Address;
>mPFPageIndex = 0;
> --
> 1.8.3.1
> 
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2] MdeModulePkg: Skip registering BootManagerMenu if its FFS is not found

2016-06-28 Thread Ni, Ruiyu

Sunny,
I have 7 minor comments. Please check below.

Regards,
Ray

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Sunny 
>Wang
>Sent: Tuesday, June 28, 2016 10:27 AM
>To: edk2-devel@lists.01.org
>Cc: Ni, Ruiyu 
>Subject: [edk2] [PATCH v2] MdeModulePkg: Skip registering BootManagerMenu if 
>its FFS is not found
>
>This is a enhancement to support the case when platform firmware doesn’t 
>support Boot Manager Menu.
>For now, if BootManagerMenu FFS can not be retrieved from FV, BDS core code 
>will still register a boot option for it. Then, this
>non-functional boot option will still be booted by user's request (like HotKey 
>or Exit from shell) to cause additional boot time
>and error status code reported. Therefore, it would be good to skip 
>BootManagerMenu boot option registration and then
>return error status and Invalid BootOption data for this case so that the 
>BootManagerBoot() or other consumers can directly
>return without doing anything.
>
>Contributed-under: TianoCore Contribution Agreement 1.0
>Signed-off-by: Sunny Wang 
>---
> MdeModulePkg/Include/Library/UefiBootManagerLib.h  |  7 ++--
> MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c   | 39 ++
> MdeModulePkg/Library/UefiBootManagerLib/BmHotkey.c |  9 +++--
> MdeModulePkg/Universal/BdsDxe/BdsEntry.c   | 29 +++-
> 4 files changed, 64 insertions(+), 20 deletions(-)
>
>diff --git a/MdeModulePkg/Include/Library/UefiBootManagerLib.h 
>b/MdeModulePkg/Include/Library/UefiBootManagerLib.h
>index 0fdb23d..649af9a 100644
>--- a/MdeModulePkg/Include/Library/UefiBootManagerLib.h
>+++ b/MdeModulePkg/Include/Library/UefiBootManagerLib.h
>@@ -418,12 +418,13 @@ EfiBootManagerBoot (
>   );
>
> /**
>-  Return the Boot Manager Menu.
>-
>+  Return the boot option corresponding to the Boot Manager Menu.
>+  It may automatically create one if the boot option hasn't been created yet.
>+
>   @param BootOptionReturn the Boot Manager Menu.
>
>   @retval EFI_SUCCESS   The Boot Manager Menu is successfully returned.
>-  @retval EFI_NOT_FOUND The Boot Manager Menu is not found.
>+  @retval StatusReturn status of either gRT->SetVariable () or 
>GetSectionFromFv().
> **/

1. How about we change the return status as following:
  @retval EFI_SUCCESS   The Boot Manager Menu is successfully returned.
  @retval EFI_NOT_FOUND The Boot Manager Menu cannot be found.
  @retval others Return status of gRT->SetVariable (). BootOption still 
points
to the Boot Manager Menu even the Status is not 
EFI_SUCCESS
and EFI_NOT_FOUND.

> EFI_STATUS
> EFIAPI
>diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
>b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
>index d016517..17e416a 100644
>--- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
>+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
>@@ -2,7 +2,7 @@
>   Library functions which relates with booting.
>
> Copyright (c) 2011 - 2016, Intel Corporation. All rights reserved.
>-(C) Copyright 2015 Hewlett Packard Enterprise Development LP
>+(C) Copyright 2015-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
>@@ -2159,16 +2159,19 @@ EfiBootManagerRefreshAllBootOption (
> }
>
> /**
>-  This function is called to create the boot option for the Boot Manager Menu.
>+  This function is called to get or create the boot option for the Boot 
>Manager Menu.
>
>   The Boot Manager Menu is shown after successfully booting a boot option.
>   Assume the BootManagerMenuFile is in the same FV as the module links to 
> this library.
>
>-  @param  BootOptionReturn the boot option of the Boot Manager Menu
>+  @param  BootOptionReturn the boot option of the Boot Manager Menu.
>+If BootManagerMenu fails to be set as a Boot 
>variables, BootOption
>+still points to the Boot Manager Menu.
>+If BootManagerMenu FFS section can not be retrieved, 
>BootOption will
>+be contain invalid data to prevent other function 
>from using it.
>
>   @retval EFI_SUCCESS   Successfully register the Boot Manager Menu.
>-  @retval StatusReturn status of gRT->SetVariable (). BootOption 
>still points
>-to the Boot Manager Menu even the Status is not 
>EFI_SUCCESS.
>+  @retval StatusReturn status of either gRT->SetVariable() or 
>GetSectionFromFv().
> **/

2. The return status can be changed as the same as 
EfiBootManagerGetBootManagerMenu().
  Change to @param BootOption isn't needed.

> EFI_STATUS
> BmRegisterBootManagerMenu (
>@@ -2181,9 +2184,32 @@ BmRegisterBootManagerMenu (
>   EFI_DEVICE_PATH_PROTOCOL

Re: [edk2] [PATCH 3/6] QuarkPlatformPkg: fix ASSERT_EFI_ERROR() typos

2016-06-28 Thread Mudusuru, Giri P

Reviewed-by: Giri P Mudusuru  

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo
> Ersek
> Sent: Tuesday, June 28, 2016 6:26 AM
> To: edk2-devel-01 
> Cc: Kinney, Michael D 
> Subject: [edk2] [PATCH 3/6] QuarkPlatformPkg: fix ASSERT_EFI_ERROR() typos
> 
> A number of code locations use
> 
>   ASSERT_EFI_ERROR (BooleanExpression)
> 
> instead of
> 
>   ASSERT (BooleanExpression)
> 
> Fix them.
> 
> Cc: Michael D Kinney 
> Cc: Kelly Steele 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> not even build tested
> 
>  QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.c  | 2 +-
>  QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/MadtPlatform.c  | 2 +-
>  QuarkPlatformPkg/Library/PlatformHelperLib/PlatformHelperDxe.c | 2 +-
>  QuarkPlatformPkg/Platform/Pei/PlatformInit/MrcWrapper.c| 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.c
> b/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.c
> index 309eb041ee92..36300efd3146 100644
> --- a/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.c
> +++ b/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.c
> @@ -680,7 +680,7 @@ AcpiPlatformEntryPoint (
>// Init Pci Device PRT PRW information structure from PCD
>//
>mConfigData = (PCI_DEVICE_SETTING *)AllocateZeroPool (sizeof
> (PCI_DEVICE_SETTING));
> -  ASSERT_EFI_ERROR (mConfigData);
> +  ASSERT (mConfigData != NULL);
>InitPciDeviceInfoStructure (mConfigData);
>//
>// Get the Acpi SDT protocol for manipulation on acpi table
> diff --git a/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/MadtPlatform.c
> b/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/MadtPlatform.c
> index 11781e03f4c5..98035bedd58f 100644
> --- a/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/MadtPlatform.c
> +++ b/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/MadtPlatform.c
> @@ -218,7 +218,7 @@ MadtTableInitialize (
>//ASSERT (NumberOfCPUs <= 2 && NumberOfCPUs > 0);
>MadtSize = GetAcutalMadtTableSize (, NumberOfCPUs);
>Madt = (EFI_ACPI_2_0_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER
> *)AllocateZeroPool (MadtSize);
> -  ASSERT_EFI_ERROR (Madt);
> +  ASSERT (Madt != NULL);
>//
>// Initialize MADT Header information
>//
> diff --git a/QuarkPlatformPkg/Library/PlatformHelperLib/PlatformHelperDxe.c
> b/QuarkPlatformPkg/Library/PlatformHelperLib/PlatformHelperDxe.c
> index 441f7609a536..39185bc0d5ff 100644
> --- a/QuarkPlatformPkg/Library/PlatformHelperLib/PlatformHelperDxe.c
> +++ b/QuarkPlatformPkg/Library/PlatformHelperLib/PlatformHelperDxe.c
> @@ -174,7 +174,7 @@ PlatformFlashLockConfig (
>//
> 
>SpiProtocol = LocateSpiProtocol (NULL);  // This routine will not be 
> called in
> SMM.
> -  ASSERT_EFI_ERROR (SpiProtocol != NULL);
> +  ASSERT (SpiProtocol != NULL);
>if (SpiProtocol != NULL) {
>  Status = SpiProtocol->Lock (SpiProtocol);
> 
> diff --git a/QuarkPlatformPkg/Platform/Pei/PlatformInit/MrcWrapper.c
> b/QuarkPlatformPkg/Platform/Pei/PlatformInit/MrcWrapper.c
> index df6c1cc23240..6b07d7829328 100644
> --- a/QuarkPlatformPkg/Platform/Pei/PlatformInit/MrcWrapper.c
> +++ b/QuarkPlatformPkg/Platform/Pei/PlatformInit/MrcWrapper.c
> @@ -1034,7 +1034,7 @@ InstallS3Memory (
>// memory above 1MB. So Memory Callback can set cache for the system
> memory
>// correctly on S3 boot path, just like it does on Normal boot path.
>//
> -  ASSERT_EFI_ERROR ((S3MemoryRangeData->SystemMemoryLength -
> 0x10) > 0);
> +  ASSERT ((S3MemoryRangeData->SystemMemoryLength - 0x10) > 0);
>BuildResourceDescriptorHob (
>  EFI_RESOURCE_SYSTEM_MEMORY,
>  (
> --
> 1.8.3.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 6/6] Vlv2TbltDevicePkg: fix ASSERT_EFI_ERROR() typos

2016-06-28 Thread Mudusuru, Giri P

Reviewed-by: Giri P Mudusuru 


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo
> Ersek
> Sent: Tuesday, June 28, 2016 6:26 AM
> To: edk2-devel-01 
> Cc: He, Tim ; Wei, David 
> Subject: [edk2] [PATCH 6/6] Vlv2TbltDevicePkg: fix ASSERT_EFI_ERROR() typos
> 
> A number of code locations use
> 
>   ASSERT_EFI_ERROR (BooleanExpression)
> 
> instead of
> 
>   ASSERT (BooleanExpression)
> 
> Fix them.
> 
> Cc: David Wei 
> Cc: Tim He 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> not even build tested
> 
>  Vlv2TbltDevicePkg/FvbRuntimeDxe/FvbService.c   | 6 
> +++---
>  Vlv2TbltDevicePkg/Library/MultiPlatformLib/BoardClkGens/BoardClkGens.c | 8
> 
>  Vlv2TbltDevicePkg/Library/MultiPlatformLib/PlatformInfoHob.c   | 2 +-
>  3 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/Vlv2TbltDevicePkg/FvbRuntimeDxe/FvbService.c
> b/Vlv2TbltDevicePkg/FvbRuntimeDxe/FvbService.c
> index da7dce6e13c7..7c95c107e600 100644
> --- a/Vlv2TbltDevicePkg/FvbRuntimeDxe/FvbService.c
> +++ b/Vlv2TbltDevicePkg/FvbRuntimeDxe/FvbService.c
> @@ -154,7 +154,7 @@ FvbGetVolumeAttributes (
>  {
>EFI_FW_VOL_INSTANCE *FwInstance = NULL;
>FwInstance = GetFvbInstance(Instance);
> -  ASSERT_EFI_ERROR (FwInstance != NULL);
> +  ASSERT (FwInstance != NULL);
> 
>if ( FwInstance != NULL ) {
>  return FwInstance->VolumeHeader.Attributes;
> @@ -208,7 +208,7 @@ FvbGetLbaAddress (
>StartLba  = 0;
>Offset= 0;
>BlockMap  = &(FwhInstance->VolumeHeader.BlockMap[0]);
> -  ASSERT_EFI_ERROR (BlockMap != NULL);
> +  ASSERT (BlockMap != NULL);
> 
>//
>// Parse the blockmap of the FV to find which map entry the Lba belongs to.
> @@ -512,7 +512,7 @@ FvbSetVolumeAttributes (
>FwhInstance = GetFvbInstance (Instance);
> 
>AttribPtr = (EFI_FVB_ATTRIBUTES_2 *) & (FwhInstance-
> >VolumeHeader.Attributes);
> -  ASSERT_EFI_ERROR (AttribPtr != NULL);
> +  ASSERT (AttribPtr != NULL);
> 
>if ( AttribPtr != NULL) {
>  OldAttributes = *AttribPtr;
> diff --git
> a/Vlv2TbltDevicePkg/Library/MultiPlatformLib/BoardClkGens/BoardClkGens.c
> b/Vlv2TbltDevicePkg/Library/MultiPlatformLib/BoardClkGens/BoardClkGens.c
> index e38633b2b3ae..7d740df2fef9 100644
> ---
> a/Vlv2TbltDevicePkg/Library/MultiPlatformLib/BoardClkGens/BoardClkGens.c
> +++
> b/Vlv2TbltDevicePkg/Library/MultiPlatformLib/BoardClkGens/BoardClkGens.c
> @@ -69,10 +69,10 @@ ConfigureClockGenerator (
>//
>// Verify input arguments
>//
> -  ASSERT_EFI_ERROR (ConfigurationTableLength >= 6);
> -  ASSERT_EFI_ERROR (ConfigurationTableLength <=
> MAX_CLOCK_GENERATOR_BUFFER_LENGTH);
> -  ASSERT_EFI_ERROR (ClockType < ClockGeneratorMax);
> -  ASSERT_EFI_ERROR (ConfigurationTable != NULL);
> +  ASSERT (ConfigurationTableLength >= 6);
> +  ASSERT (ConfigurationTableLength <=
> MAX_CLOCK_GENERATOR_BUFFER_LENGTH);
> +  ASSERT (ClockType < ClockGeneratorMax);
> +  ASSERT (ConfigurationTable != NULL);
> 
>//
>// Read the clock generator
> diff --git a/Vlv2TbltDevicePkg/Library/MultiPlatformLib/PlatformInfoHob.c
> b/Vlv2TbltDevicePkg/Library/MultiPlatformLib/PlatformInfoHob.c
> index ebaaf40a165e..9d77e86678fe 100644
> --- a/Vlv2TbltDevicePkg/Library/MultiPlatformLib/PlatformInfoHob.c
> +++ b/Vlv2TbltDevicePkg/Library/MultiPlatformLib/PlatformInfoHob.c
> @@ -49,7 +49,7 @@ GetPlatformInfoHob (
>//
>// PlatformInfo PEIM should provide this HOB data, if not ASSERT and return
> error.
>//
> -  ASSERT_EFI_ERROR (*PlatformInfoHob != NULL);
> +  ASSERT (*PlatformInfoHob != NULL);
>if (!(*PlatformInfoHob)) {
>  return EFI_NOT_FOUND;
>}
> --
> 1.8.3.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 0/7] Introduce three new toolchains in edk2

2016-06-28 Thread Andrew Fish

> On Jun 28, 2016, at 7:09 PM, Gao, Liming  wrote:
> 
> Bruce:
>  Yes. We add EFIAPI in such function, and define 
> "-DEFIAPI=__attribute__((ms_abi))" in GCC CC_FLAGS. 
> 

I don't know how the version of clang used was constructed, but clang is 
inherently a cross compiler and it can easily support multiple ABIs (System V 
and X64). It comes down to how it was constructed. 

Basically a flag like -arch x86_64 will be the system default ABI, but you can 
build other stuff for the architecture via -target x86_64-pc-win32-macho. So 
for example you might be able to enable -target x86_64-pc-win32-efl. So have 
the native EFI/Windows ABI, but make an ELF with dwarf for the debugger. 

If you don't want to use the __attribute__((ms_abi)) then you might be able to 
get that support in upstream. There might already be some support for cross 
building Windows Apps on Linux that could be leveraged. You just need the 
correctly ABI, and a source level debugging scheme that works on your build 
target. 

Thanks,

Andrew Fish

> Thanks
> Liming
>> -Original Message-
>> From: Bruce Cran [mailto:br...@cran.org.uk]
>> Sent: Wednesday, June 29, 2016 6:45 AM
>> To: Shi, Steven ; edk2-devel@lists.01.org; Gao,
>> Liming 
>> Cc: Kinney, Michael D ; af...@apple.com
>> Subject: Re: [edk2] [PATCH 0/7] Introduce three new toolchains in edk2
>> 
>> On 6/28/16 9:18 AM, Shi, Steven wrote:
>>> Introduce three new toolchains in edk2. The first two ones support Link
>> Time Optimization (LTO) for aggressive code size improvement and the third
>> one is for static analysis.
>>> 
>>> CLANG38: Enable LLVM Link Time Optimization (LTO) and code size
>> optimization flag (-Os) by default for aggressive code size improvement.
>>> X64 code is small code model + position independent code (PIE).
>> 
>> One problem I've run into trying to build with clang is that we have a
>> set of files which are the same across platforms, and they use varargs.
>> 
>> With gcc, we can just set -mabi=ms and be done with it, but it appears
>> clang doesn't have that option.  Do you know of a way to set the default
>> ABI with clang, or would we need to add an __attribute__((ms_abi))
>> anywhere we need to use varargs?
>> 
>> --
>> Bruce Cran
> ___
> 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 4/6] ShellPkg: don't call functions with side effects in ASSERT_EFI_ERROR()

2016-06-28 Thread Mudusuru, Giri P

Reviewed-by: Giri P Mudusuru 


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo
> Ersek
> Sent: Tuesday, June 28, 2016 6:26 AM
> To: edk2-devel-01 
> Cc: Carsey, Jaben ; Qiu, Shumin
> 
> Subject: [edk2] [PATCH 4/6] ShellPkg: don't call functions with side effects 
> in
> ASSERT_EFI_ERROR()
> 
> When ASSERT_EFI_ERROR() is compiled out, dependent on build flags, only
> the status checking should be removed; the function calls should stay.
> 
> Cc: Jaben Carsey 
> Cc: Shumin Qiu 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> build tested
> 
>  ShellPkg/Library/UefiShellLevel1CommandsLib/If.c | 10 --
>  ShellPkg/Library/UefiShellLib/UefiShellLib.c |  5 -
>  2 files changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiShellLevel1CommandsLib/If.c
> b/ShellPkg/Library/UefiShellLevel1CommandsLib/If.c
> index 7abfd8944b92..dc96bffde7d3 100644
> --- a/ShellPkg/Library/UefiShellLevel1CommandsLib/If.c
> +++ b/ShellPkg/Library/UefiShellLevel1CommandsLib/If.c
> @@ -991,8 +991,11 @@ ShellCommandRunElse (
>IN EFI_SYSTEM_TABLE  *SystemTable
>)
>  {
> +  EFI_STATUS  Status;
>SCRIPT_FILE *CurrentScriptFile;
> -  ASSERT_EFI_ERROR(CommandInit());
> +
> +  Status = CommandInit ();
> +  ASSERT_EFI_ERROR (Status);
> 
>if (gEfiShellParametersProtocol->Argc > 1) {
>  ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_GEN_TOO_MANY),
> gShellLevel1HiiHandle, L"if");
> @@ -1066,8 +1069,11 @@ ShellCommandRunEndIf (
>IN EFI_SYSTEM_TABLE  *SystemTable
>)
>  {
> +  EFI_STATUS  Status;
>SCRIPT_FILE *CurrentScriptFile;
> -  ASSERT_EFI_ERROR(CommandInit());
> +
> +  Status = CommandInit ();
> +  ASSERT_EFI_ERROR (Status);
> 
>if (gEfiShellParametersProtocol->Argc > 1) {
>  ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_GEN_TOO_MANY),
> gShellLevel1HiiHandle, L"if");
> diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> index cf89a4ac87ed..35a1a7169c8b 100644
> --- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> +++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> @@ -373,6 +373,8 @@ EFIAPI
>  ShellInitialize (
>)
>  {
> +  EFI_STATUS Status;
> +
>//
>// if auto initialize is not false then skip
>//
> @@ -383,7 +385,8 @@ ShellInitialize (
>//
>// deinit the current stuff
>//
> -  ASSERT_EFI_ERROR(ShellLibDestructor(gImageHandle, gST));
> +  Status = ShellLibDestructor (gImageHandle, gST);
> +  ASSERT_EFI_ERROR (Status);
> 
>//
>// init the new stuff
> --
> 1.8.3.1
> 
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/6] EdkCompatibilityPkg: fix ASSERT_EFI_ERROR() typos

2016-06-28 Thread Mudusuru, Giri P

Reviewed-by: Giri P Mudusuru 


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo
> Ersek
> Sent: Tuesday, June 28, 2016 6:26 AM
> To: edk2-devel-01 
> Cc: Gao, Liming 
> Subject: [edk2] [PATCH 1/6] EdkCompatibilityPkg: fix ASSERT_EFI_ERROR() typos
> 
> A number of code locations use
> 
>   ASSERT_EFI_ERROR (BooleanExpression)
> 
> instead of
> 
>   ASSERT (BooleanExpression)
> 
> Fix them.
> 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> build tested only
> 
> 
> EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/HiiDatabase.c
> | 2 +-
>  EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/Utility.c | 
> 2
> +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git
> a/EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/HiiDatabase
> .c
> b/EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/HiiDatabase
> .c
> index 386ff327f81b..2d456da30353 100644
> ---
> a/EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/HiiDatabase
> .c
> +++
> b/EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/HiiDatabase
> .c
> @@ -494,7 +494,7 @@ HiiGetSecondaryLanguages (
>UnicodeStrToAsciiStr (PrimaryLanguage, PrimaryLang639);
> 
>PrimaryLang4646 = ConvertLanguagesIso639ToRfc4646 (PrimaryLang639);
> -  ASSERT_EFI_ERROR (PrimaryLang4646 != NULL);
> +  ASSERT (PrimaryLang4646 != NULL);
> 
>SecLangCodes4646 = HiiGetSupportedSecondaryLanguages (UefiHiiHandle,
> PrimaryLang4646);
> 
> diff --git
> a/EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/Utility.c
> b/EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/Utility.c
> index f6d97f63444f..d269b8e4d6ba 100644
> --- a/EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/Utility.c
> +++ b/EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/Utility.c
> @@ -153,7 +153,7 @@ ExportPackageLists (
> ,
> PackageListHdr
> );
> -  ASSERT_EFI_ERROR (Status != EFI_BUFFER_TOO_SMALL);
> +  ASSERT (Status != EFI_BUFFER_TOO_SMALL);
> 
>if (Status == EFI_BUFFER_TOO_SMALL) {
>  PackageListHdr = AllocateZeroPool (Size);
> --
> 1.8.3.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 0/7] Introduce three new toolchains in edk2

2016-06-28 Thread Gao, Liming

Bruce:
  Yes. We add EFIAPI in such function, and define 
"-DEFIAPI=__attribute__((ms_abi))" in GCC CC_FLAGS. 

Thanks
Liming
> -Original Message-
> From: Bruce Cran [mailto:br...@cran.org.uk]
> Sent: Wednesday, June 29, 2016 6:45 AM
> To: Shi, Steven ; edk2-devel@lists.01.org; Gao,
> Liming 
> Cc: Kinney, Michael D ; af...@apple.com
> Subject: Re: [edk2] [PATCH 0/7] Introduce three new toolchains in edk2
> 
> On 6/28/16 9:18 AM, Shi, Steven wrote:
> > Introduce three new toolchains in edk2. The first two ones support Link
> Time Optimization (LTO) for aggressive code size improvement and the third
> one is for static analysis.
> >
> > CLANG38: Enable LLVM Link Time Optimization (LTO) and code size
> optimization flag (-Os) by default for aggressive code size improvement.
>  > X64 code is small code model + position independent code (PIE).
> 
> One problem I've run into trying to build with clang is that we have a
> set of files which are the same across platforms, and they use varargs.
> 
> With gcc, we can just set -mabi=ms and be done with it, but it appears
> clang doesn't have that option.  Do you know of a way to set the default
> ABI with clang, or would we need to add an __attribute__((ms_abi))
> anywhere we need to use varargs?
> 
> --
> Bruce Cran
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 5/6] UefiCpuPkg: fix ASSERT_EFI_ERROR() typos

2016-06-28 Thread Fan, Jeff

Reviewed-by: Jeff Fan 

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Tuesday, June 28, 2016 9:26 PM
To: edk2-devel-01
Cc: Fan, Jeff
Subject: [PATCH 5/6] UefiCpuPkg: fix ASSERT_EFI_ERROR() typos

A number of code locations use

  ASSERT_EFI_ERROR (BooleanExpression)

instead of

  ASSERT (BooleanExpression)

Fix them.

Cc: Jeff Fan 
Reported-by: Gerd Hoffmann 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmProfileArch.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmProfileArch.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmProfileArch.c
index 79e23ef6476e..065fb2c24c7d 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmProfileArch.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmProfileArch.c
@@ -78,7 +78,7 @@ InitPagesForPFHandler (
   //
   Address = NULL;
   Address = AllocatePages (MAX_PF_PAGE_COUNT);
-  ASSERT_EFI_ERROR (Address != NULL);
+  ASSERT (Address != NULL);
 
   mPFPageBuffer =  (UINT64)(UINTN) Address;
   mPFPageIndex = 0;
-- 
1.8.3.1


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

Re: [edk2] iPXE invalidates the OVMF network device options

2016-06-28 Thread Gary Lin

On Tue, Jun 28, 2016 at 01:43:31PM +0100, Michael Brown wrote:
> On 28/06/16 13:34, Michael Brown wrote:
> > On 28/06/16 13:30, Laszlo Ersek wrote:
> > > On 06/24/16 06:39, Gary Lin wrote:
> > > > It seems that iPXE didn't initialize Scope, so the value was assigned
> > > > randomly (sort of).
> > > > 
> > > > diff --git a/src/interface/efi/efi_hii.c b/src/interface/efi/efi_hii.c
> > > > index 0ea970e..4b5aa9a 100644
> > > > --- a/src/interface/efi/efi_hii.c
> > > > +++ b/src/interface/efi/efi_hii.c
> > > > @@ -119,6 +119,7 @@ static void * efi_ifr_op ( struct efi_ifr_builder
> > > > *ifr, unsigned int opcode,
> > > >   /* Fill in opcode header */
> > > >   op->OpCode = opcode;
> > > >   op->Length = len;
> > > > +op->Scope = 0;
> > > > 
> > > >   return op;
> > > >   }
> > > > 
> > > > After applying this patch, the crash never happened again.
> > > 
> > > Awesome! Can you please send this patch to ipxe-devel? (Although I can
> > > see Michael is on the address list anyway -- good!)
> > 
> > Got it; thank you!
> > 
> > Will check the related code; it may make sense to have efi_ifr_op()
> > always zero the whole of the newly allocated space first.
> 
> I think the following patch should fix the problem (and also avoid any
> potential uninitialised-data problems in callers of efi_ifr_op()):
> 
> diff --git a/src/interface/efi/efi_hii.c b/src/interface/efi/efi_hii.c
> index 0ea970e..506fc88 100644
> --- a/src/interface/efi/efi_hii.c
> +++ b/src/interface/efi/efi_hii.c
> @@ -117,6 +117,7 @@ static void * efi_ifr_op ( struct efi_ifr_builder *ifr,
> unsigned int opcode,
>   ifr->ops_len = new_ops_len;
> 
>   /* Fill in opcode header */
> + memset ( op, 0, len );
>   op->OpCode = opcode;
>   op->Length = len;
> 
> 
> Please let me know if this works.
> 
This patch works quite well. Tried 10 times and got no crash. Without
the patch, my OVMF crashed at the first try. I would say it's fixed :)

Thanks,

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

Re: [edk2] [PATCH 0/7] Introduce three new toolchains in edk2

2016-06-28 Thread Bruce Cran


On 6/28/16 9:18 AM, Shi, Steven wrote:

Introduce three new toolchains in edk2. The first two ones support Link Time 
Optimization (LTO) for aggressive code size improvement and the third one is 
for static analysis.

CLANG38: Enable LLVM Link Time Optimization (LTO) and code size 
optimization flag (-Os) by default for aggressive code size improvement.

> X64 code is small code model + position independent code (PIE).

One problem I've run into trying to build with clang is that we have a 
set of files which are the same across platforms, and they use varargs.


With gcc, we can just set -mabi=ms and be done with it, but it appears 
clang doesn't have that option.  Do you know of a way to set the default 
ABI with clang, or would we need to add an __attribute__((ms_abi)) 
anywhere we need to use varargs?


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

Re: [edk2] [PATCH] ArmVirtPkg: Re-add the Driver Health Manager

2016-06-28 Thread Laszlo Ersek

On 06/28/16 21:24, Bruce Cran wrote:
> Change-Id: I2973d251e18583531bf4579ba8dfa8101bea0939
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Bruce Cran 
> ---
>  ArmVirtPkg/ArmVirtQemu.dsc   | 1 +
>  ArmVirtPkg/ArmVirtQemu.fdf   | 1 +
>  ArmVirtPkg/ArmVirtQemuKernel.dsc | 1 +
>  ArmVirtPkg/ArmVirtQemuKernel.fdf | 1 +
>  ArmVirtPkg/ArmVirtXen.dsc| 1 +
>  ArmVirtPkg/ArmVirtXen.fdf| 1 +
>  6 files changed, 6 insertions(+)

Suggested-by: Liming Gao 

I removed the Xen changes from this patch, because that platform has not
migrated to the MdeModulePkg BDS. According to Liming's advice (and your
report), the separate driver is only necessary with the MdeModulePkg BDS.

With that updateP

Reviewed-by: Laszlo Ersek 
Tested-by: Laszlo Ersek 

I also refreshed the commit message similarly to your OvmfPkg patch.

Committed as 9852838576b6f76000d49d1661d5c573e8ef1ab4.

Thanks!
Laszlo


> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index 8a5306b..8248fd6 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -334,6 +334,7 @@
>MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
>MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
>MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> +  MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
>MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
>  
>NULL|MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.inf
> diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
> index ac2f1f1..d98a01c 100644
> --- a/ArmVirtPkg/ArmVirtQemu.fdf
> +++ b/ArmVirtPkg/ArmVirtQemu.fdf
> @@ -167,6 +167,7 @@ READ_LOCK_STATUS   = TRUE
>INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
>INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
>INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> +  INF 
> MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
>INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
>INF MdeModulePkg/Application/UiApp/UiApp.inf
>  
> diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc 
> b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> index 52f1612..2fc50bd 100644
> --- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
> +++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> @@ -310,6 +310,7 @@
>MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
>MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
>MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> +  MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
>MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
>  
>NULL|MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.inf
> diff --git a/ArmVirtPkg/ArmVirtQemuKernel.fdf 
> b/ArmVirtPkg/ArmVirtQemuKernel.fdf
> index f6dcbc1..1229e6b 100644
> --- a/ArmVirtPkg/ArmVirtQemuKernel.fdf
> +++ b/ArmVirtPkg/ArmVirtQemuKernel.fdf
> @@ -187,6 +187,7 @@ READ_LOCK_STATUS   = TRUE
>INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
>INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
>INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> +  INF 
> MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
>INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
>INF MdeModulePkg/Application/UiApp/UiApp.inf
>  
> diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
> index a869986..1df751f 100644
> --- a/ArmVirtPkg/ArmVirtXen.dsc
> +++ b/ArmVirtPkg/ArmVirtXen.dsc
> @@ -212,6 +212,7 @@
>MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
>MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
>MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> +  MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
>IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
>  
>OvmfPkg/XenBusDxe/XenBusDxe.inf
> diff --git a/ArmVirtPkg/ArmVirtXen.fdf b/ArmVirtPkg/ArmVirtXen.fdf
> index b1e00e5..ec99724 100644
> --- a/ArmVirtPkg/ArmVirtXen.fdf
> +++ b/ArmVirtPkg/ArmVirtXen.fdf
> @@ -174,6 +174,7 @@ READ_LOCK_STATUS   = TRUE
>INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
>INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
>INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> +  INF 
> MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
>INF IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
>  
>INF OvmfPkg/XenBusDxe/XenBusDxe.inf
> 

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

Re: [edk2] [PATCH] OvmfPkg: Re-add the Driver Health Manager

2016-06-28 Thread Laszlo Ersek

On 06/28/16 21:09, Bruce Cran wrote:
> From: Bruce Cran 
> 
> Change-Id: I7549947ccb78aa316ff9082f336a3ad32769a0c6
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Bruce Cran 
> ---
>  OvmfPkg/OvmfPkgIa32.dsc| 1 +
>  OvmfPkg/OvmfPkgIa32.fdf| 1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
>  OvmfPkg/OvmfPkgIa32X64.fdf | 1 +
>  OvmfPkg/OvmfPkgX64.dsc | 1 +
>  OvmfPkg/OvmfPkgX64.fdf | 1 +
>  6 files changed, 6 insertions(+)

Suggested-by: Liming Gao 
Reviewed-by: Laszlo Ersek 
Tested-by: Laszlo Ersek 

I added some background to the commit message, and committed your patch
as ba502ef477353968325242a85742889e09e8dd84.

Thanks!
Laszlo

> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index 737f300..6d07464 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -563,6 +563,7 @@
>PcAtChipsetPkg/KbcResetDxe/Reset.inf
>MdeModulePkg/Universal/Metronome/Metronome.inf
>PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
> +  MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
>MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
>  
>NULL|MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.inf
> diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
> index 8bba8a6..59a4024 100644
> --- a/OvmfPkg/OvmfPkgIa32.fdf
> +++ b/OvmfPkg/OvmfPkgIa32.fdf
> @@ -235,6 +235,7 @@ INF  
> MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
>  INF  MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
>  INF  MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
>  INF  MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
> +INF  MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
>  INF  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
>  INF  MdeModulePkg/Application/UiApp/UiApp.inf
>  INF  MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 854cf6d..25fcb38 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -572,6 +572,7 @@
>PcAtChipsetPkg/KbcResetDxe/Reset.inf
>MdeModulePkg/Universal/Metronome/Metronome.inf
>PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
> +  MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
>MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
>  
>NULL|MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.inf
> diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
> index 73b50f5..c6167a4 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.fdf
> +++ b/OvmfPkg/OvmfPkgIa32X64.fdf
> @@ -235,6 +235,7 @@ INF  
> MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
>  INF  MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
>  INF  MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
>  INF  MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
> +INF  MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
>  INF  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
>  INF  MdeModulePkg/Application/UiApp/UiApp.inf
>  INF  MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 0cb2f60..cb7ccf7 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -570,6 +570,7 @@
>PcAtChipsetPkg/KbcResetDxe/Reset.inf
>MdeModulePkg/Universal/Metronome/Metronome.inf
>PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
> +  MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
>MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
>  
>NULL|MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.inf
> diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
> index 1e3387f..30b0c2b 100644
> --- a/OvmfPkg/OvmfPkgX64.fdf
> +++ b/OvmfPkg/OvmfPkgX64.fdf
> @@ -235,6 +235,7 @@ INF  
> MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
>  INF  MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
>  INF  MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
>  INF  MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
> +INF  MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
>  INF  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
>  INF  MdeModulePkg/Application/UiApp/UiApp.inf
>  INF  MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
> 

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

[edk2] [BaseTools] I had an issue with different paths for the same file in DSC vs. FDF files.

2016-06-28 Thread Andrew Fish

I hit an issue with this code. 

https://github.com/tianocore/edk2/blob/master/BaseTools/Source/Python/AutoGen/AutoGen.py#L2510
self.SourceDir = mws.relpath(self.SourceDir, self.WorkspaceDir)

I had a combination of relative and absolute references in the DSC and FDF and 
the build did not work as the build system got confused about the location in 
the Build directory of items. So X64/MdePkg/ vs X64/edk2/MdePkg. 

I fixed by doing this. 
self.SourceDir = os.path.relpath(mws.join(GlobalData.gWorkspace, 
self.SourceDir), self.WorkspaceDir)

I don't think that covers the case of a Path outside the workspace so an extra 
check should be added and if that check fails then call self.SourceDir = 
mws.relpath(self.SourceDir, self.WorkspaceDir). 

Thanks,

Andrew Fish


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

[edk2] [BaseTools] I hit what looked like a case issue in the construction of the build report.

2016-06-28 Thread Andrew Fish


I ran into a case issue with this code. 
FvReportFileName = os.path.join(self._FvDir, FvName + ".Fv.txt")
https://github.com/tianocore/edk2/blob/master/BaseTools/Source/Python/build/BuildReport.py#L1462

I ended up testing FvReportFileName and if it was not found I forced FvName to 
all upper case. That fixed the issue. I'm not sure if the test is really 
needed. It only fails on a case sensitive filesystem. 

Thanks,

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

[edk2] [PATCH] ArmVirtPkg: Re-add the Driver Health Manager

2016-06-28 Thread Bruce Cran

Change-Id: I2973d251e18583531bf4579ba8dfa8101bea0939
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Bruce Cran 
---
 ArmVirtPkg/ArmVirtQemu.dsc   | 1 +
 ArmVirtPkg/ArmVirtQemu.fdf   | 1 +
 ArmVirtPkg/ArmVirtQemuKernel.dsc | 1 +
 ArmVirtPkg/ArmVirtQemuKernel.fdf | 1 +
 ArmVirtPkg/ArmVirtXen.dsc| 1 +
 ArmVirtPkg/ArmVirtXen.fdf| 1 +
 6 files changed, 6 insertions(+)

diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 8a5306b..8248fd6 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -334,6 +334,7 @@
   MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
   MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
   MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
+  MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
   MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
 
   NULL|MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.inf
diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
index ac2f1f1..d98a01c 100644
--- a/ArmVirtPkg/ArmVirtQemu.fdf
+++ b/ArmVirtPkg/ArmVirtQemu.fdf
@@ -167,6 +167,7 @@ READ_LOCK_STATUS   = TRUE
   INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
   INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
   INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
+  INF MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
   INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
   INF MdeModulePkg/Application/UiApp/UiApp.inf
 
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
index 52f1612..2fc50bd 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -310,6 +310,7 @@
   MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
   MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
   MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
+  MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
   MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
 
   NULL|MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.inf
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.fdf b/ArmVirtPkg/ArmVirtQemuKernel.fdf
index f6dcbc1..1229e6b 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.fdf
+++ b/ArmVirtPkg/ArmVirtQemuKernel.fdf
@@ -187,6 +187,7 @@ READ_LOCK_STATUS   = TRUE
   INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
   INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
   INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
+  INF MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
   INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
   INF MdeModulePkg/Application/UiApp/UiApp.inf
 
diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
index a869986..1df751f 100644
--- a/ArmVirtPkg/ArmVirtXen.dsc
+++ b/ArmVirtPkg/ArmVirtXen.dsc
@@ -212,6 +212,7 @@
   MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
   MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
   MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
+  MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
   IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
 
   OvmfPkg/XenBusDxe/XenBusDxe.inf
diff --git a/ArmVirtPkg/ArmVirtXen.fdf b/ArmVirtPkg/ArmVirtXen.fdf
index b1e00e5..ec99724 100644
--- a/ArmVirtPkg/ArmVirtXen.fdf
+++ b/ArmVirtPkg/ArmVirtXen.fdf
@@ -174,6 +174,7 @@ READ_LOCK_STATUS   = TRUE
   INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
   INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
   INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
+  INF MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
   INF IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
 
   INF OvmfPkg/XenBusDxe/XenBusDxe.inf
-- 
2.8.4

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

[edk2] [PATCH] OvmfPkg: Re-add the Driver Health Manager

2016-06-28 Thread Bruce Cran

From: Bruce Cran 

Change-Id: I7549947ccb78aa316ff9082f336a3ad32769a0c6
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Bruce Cran 
---
 OvmfPkg/OvmfPkgIa32.dsc| 1 +
 OvmfPkg/OvmfPkgIa32.fdf| 1 +
 OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
 OvmfPkg/OvmfPkgIa32X64.fdf | 1 +
 OvmfPkg/OvmfPkgX64.dsc | 1 +
 OvmfPkg/OvmfPkgX64.fdf | 1 +
 6 files changed, 6 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 737f300..6d07464 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -563,6 +563,7 @@
   PcAtChipsetPkg/KbcResetDxe/Reset.inf
   MdeModulePkg/Universal/Metronome/Metronome.inf
   PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
+  MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
   MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
 
   NULL|MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.inf
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index 8bba8a6..59a4024 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -235,6 +235,7 @@ INF  
MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
 INF  MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
 INF  MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
 INF  MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
+INF  MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
 INF  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
 INF  MdeModulePkg/Application/UiApp/UiApp.inf
 INF  MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 854cf6d..25fcb38 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -572,6 +572,7 @@
   PcAtChipsetPkg/KbcResetDxe/Reset.inf
   MdeModulePkg/Universal/Metronome/Metronome.inf
   PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
+  MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
   MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
 
   NULL|MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index 73b50f5..c6167a4 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -235,6 +235,7 @@ INF  
MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
 INF  MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
 INF  MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
 INF  MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
+INF  MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
 INF  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
 INF  MdeModulePkg/Application/UiApp/UiApp.inf
 INF  MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 0cb2f60..cb7ccf7 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -570,6 +570,7 @@
   PcAtChipsetPkg/KbcResetDxe/Reset.inf
   MdeModulePkg/Universal/Metronome/Metronome.inf
   PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
+  MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
   MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
 
   NULL|MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.inf
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 1e3387f..30b0c2b 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -235,6 +235,7 @@ INF  
MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
 INF  MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
 INF  MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
 INF  MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
+INF  MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
 INF  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
 INF  MdeModulePkg/Application/UiApp/UiApp.inf
 INF  MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
-- 
2.8.4

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

[edk2] [PATCH] [ShellPkg/UefiHandleParsingLib]: Fix GUID dereference

2016-06-28 Thread Thomas Palmer

Print's "%g" argument requires a EFI_GUID pointer, not the EFI_GUID
value.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Thomas Palmer 
---
 ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c 
b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
index b82f925..23d619e 100644
--- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
+++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
@@ -1323,7 +1323,7 @@ FirmwareManagementDumpInformation (
TempStr,
Index,
ImageInfoV1[Index].ImageIndex,
-   ImageInfoV1[Index].ImageTypeId,
+   [Index].ImageTypeId,
ImageInfoV1[Index].ImageId,
ImageInfoV1[Index].ImageIdName,
ImageInfoV1[Index].Version,
@@ -1350,7 +1350,7 @@ FirmwareManagementDumpInformation (
TempStr,
Index,
ImageInfoV2[Index].ImageIndex,
-   ImageInfoV2[Index].ImageTypeId,
+   [Index].ImageTypeId,
ImageInfoV2[Index].ImageId,
ImageInfoV2[Index].ImageIdName,
ImageInfoV2[Index].Version,
@@ -1378,7 +1378,7 @@ FirmwareManagementDumpInformation (
TempStr,
Index,
ImageInfo[Index].ImageIndex,
-   ImageInfo[Index].ImageTypeId,
+   [Index].ImageTypeId,
ImageInfo[Index].ImageId,
ImageInfo[Index].ImageIdName,
ImageInfo[Index].Version,
-- 
1.9.1

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

Re: [edk2] [RFC V3.1] Proposal to organize packages into directories

2016-06-28 Thread Jordan Justen

On 2016-06-28 03:35:57, Laszlo Ersek wrote:
> 
> Leif recommended "efi-virt" elsewhere, as an arch-less / catch-all name.
> I think I prefer it a bit over ovmf-*: in case ovmf- is
> mentioned, the idea is clear, but if you just want to say "guest UEFI",
> without mentioning the guest arch, "ovmf" would be a bit misleading, due
> to OVMF's historical correspondence to x86.
> 

I don't agree. First of all, the name is generic, and doesn't indicate
a particular architecture, nor VMM. The OvmfPkg/README overview has
always only indicated that our goal is to support 'virtual machines'
for EDK II. All the OVMF releases had the architecture in the released
filename. The .dsc files make it clear that there are different builds
for different architectures.

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

[edk2] [PATCH 0/7] Introduce three new toolchains in edk2

2016-06-28 Thread Shi, Steven

Introduce three new toolchains in edk2. The first two ones support Link Time 
Optimization (LTO) for aggressive code size improvement and the third one is 
for static analysis. 

CLANG38: Enable LLVM Link Time Optimization (LTO) and code size 
optimization flag (-Os) by default for aggressive code size improvement. X64 
code is small code model + position independent code (PIE).
GCC53  : Enabled GCC Link Time Optimization (LTO) and code size 
optimization (–Os) for more aggressive code size improvement. X64 code is small 
+ PIE (why not GCCLTO49? Because GCC 4.9 LTO cannot work with latest GNU ld 
linker)
CLANGSCAN38: Base on CLANG38 to seamlessly integrate Clang scan-build analyzer 
infrastructure into edk2 build infrastructure. X64 code is small code model + 
PIE.

Test pass platforms: OVMF (OvmfPkgIa32.dsc, OvmfPkgX64.dsc) and Quark 
(Quark.dsc). 
Test compiler and linker version: LLVM 3.8, GCC 5.3, GCC 5.4, GNU ld 2.26.

Code size data comparison:

FV (Byte)   VS2015x86 |   GCC49   | CLANG38 | GCC53
---
Quark (IA32) FVMAIN_COMPACT DEBUG   0xb7730   |   0xe4e68 | 0xbf618 | 
0xd1ad8 
Quark (IA32) FVRECOVERY DEBUG   0x5b3c8   |   0x84198 | 0x59240 | 
0x5f6f8 
Quark (IA32) FVMAIN_COMPACT RELEASE 0x73e58   |   0xcec48 | 0x85870 | 
0x80370
Quark (IA32) FVRECOVERY RELEASE 0x25f08   |   0x5b190 | 0x28468 | 
0x2a330
OvmfX64 FVMAIN_COMPACT DEBUG0xfc3c0   |   0x121090| 0x100168| 
0x10ea20
OvmfX64 PEIFV(X64) DEBUG0x244b0   |   0x4efb0 | 0x219f0 | 
0x21670
OvmfX64 FVMAIN_COMPACT RELEASE  0xc6688   |   0xd4cd8 | 0xce7a8 | 
0xc7588
OvmfX64 PEIFV(X64) RELEASE  0xf170|   0x264f0 | 0xf870  | 0xf5f0


Module (KB) VS2015x86 |   GCC49   | CLANG38 | GCC53
---
RELEASE IA32 PeiCore.efi20KB  |   26.6KB  | 22.1KB  | 
22.4KB 
DEBUG IA32 PeiCore.efi  39.8KB|   56.4KB  | 41.2KB  | 
44.1KB 
RELEASE X64 DxeCore.efi 95.3KB|   183KB   | 101KB   | 91.2KB
RELEASE X64 DxeCore.efi lzma compress   43.5KB|   51.2KB  | 45.2KB  | 44.5KB
DEBUG X64 DxeCore.efi   138KB |   273KB   | 138KB   | 137KB
DEBUG X64 DxeCore.efi lzma compress 57.2KB|   68.9KB  | 58.4KB  | 61.7KB
RELEASE X64 Timer.efi   1.84KB|   3KB | 1.62KB  | 1.56KB
RELEASE X64 Timer.efi lzma compress 764 Byte  |   1.11KB  | 737 Byte| 735 
Byte
DEBUG X64 Timer.efi 9.68KB|   20KB| 8.37KB  | 7.62KB
DEBUG X64 Timer.efi lzma compress   4.63KB|   6.0KB   | 4.20KB  | 3.95KB

Example steps to use the CLANG38 tool chain to build OVMF platform:
Download and extract the llvm 3.8.0 Pre-Built Binaries from 
http://www.llvm.org/releases/ (e.g. 
http://www.llvm.org/releases/3.8.0/clang+llvm-3.8.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz
 and extract it as ~/clang38).
Copy LLVMgold.so from 
https://github.com/shijunjing/edk2/blob/llvm/BaseTools/Bin/LLVMgold.so to above 
clang lib folder (e.g. ~/clang38/lib/LLVMgold.so, this step is needed only for 
CLANG38)
Install new version linker with plugin support (e.g. ld 2.26 in GNU 
Binutils 2.26 or Ubuntu16.04, this step is needed only for CLANG38)
$ cd edk2
$ git checkout llvm
$ export CLANG38_BIN=path/to/your/clang38/ (e.g. export 
CLANG38_BIN=~/clang38/bin/)
$ source edksetup.sh
$ make -C BaseTools/Source/C
$ build -t CLANG38 -a X64 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -b DEBUG 
-DDEBUG_ON_SERIAL_PORT
$ cd edk2/Build/OvmfX64/DEBUG_CLANG38/FV
$ qemu-system-x86_64.exe -bios OVMF.fd -serial file:serial.log -m 4096 -hda 
fat:.

If you want, you can build and install GNU Binutils 2.26 as below steps in 
Ubuntu
Download binutils-2.26 source code from http://ftp.gnu.org/gnu/binutils/ 
and extract it to ~/binutils-2.26
$sudo apt-get install bison
$sudo apt-get install flex
Install other necessary binutils build tools if missing
$ mkdir build
$ cd build
$ ../binutils-2.26/configure --enable-gold --enable-plugins 
--disable-werror --prefix=/usr
$ make -j 5
$ sudo make install

If you want, you can build LLVMgold.so as below steps
Download llvm-3.8.0 source code from 
http://www.llvm.org/releases/3.8.0/llvm-3.8.0.src.tar.xz and extract it to 
~/llvm-3.8.0.src
Download clang3.8.0 source code from 
http://www.llvm.org/releases/3.8.0/cfe-3.8.0.src.tar.xz and extract it to 
~/llvm-3.8.0.src/tools/clang
Refer http://clang.llvm.org/get_started.html to Install other necessary 
clang build tools if missing
$ mkdir llvm38build
$ cd llvm38build
If your GNU Binutils 2.26 is in /home/jshi19/binutils-2.26, $ cmake 
../llvm-3.8.0.src -G "Unix Makefiles" -DCMAKE_BUILD_TYPE="Release" 
-DLLVM_TARGETS_TO_BUILD="X86"

[edk2] [PATCH 1/7] BaseTools: Enable three new toolchains

2016-06-28 Thread Shi, Steven

Enable three new toolchains: CLANG38, CLANGSCAN38 and GCC53.
(1)CLANG38 uses Clang3.8.0, enable LLVM Link Time Optimization (LTO)
and code size optimization flag (-Oz) by default for aggressive code
size improvement. CLANG38 X64 code is small code model + PIE.
(2)CLANGSCAN38 is based on CLANG38 to seamlessly integrate Clang
scan-build analyzer infrastructure into edk2 build infrastructure.
(3)GCC53 use gcc 5.3, enable GCC Link Time Optimization (LTO) and
code size optimization (–Os) for aggressive code size improvement.
GCC53 X64 code is also small + PIE.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Steven Shi 
---
 BaseTools/Conf/build_rule.template |  17 ++-
 BaseTools/Conf/tools_def.template  | 267 +
 2 files changed, 283 insertions(+), 1 deletion(-)
 mode change 100644 => 100755 BaseTools/Conf/build_rule.template
 mode change 100644 => 100755 BaseTools/Conf/tools_def.template

diff --git a/BaseTools/Conf/build_rule.template 
b/BaseTools/Conf/build_rule.template
old mode 100644
new mode 100755
index 91bcc18..7f21813
--- a/BaseTools/Conf/build_rule.template
+++ b/BaseTools/Conf/build_rule.template
@@ -137,6 +137,9 @@
 
 "$(CC)" $(CC_FLAGS) -o ${dst} $(INC) ${src}
 
+
+"$(SCAN)" $(SCAN_FLAGS) -o $(SCAN_DST) "$(CC)" $(CC_FLAGS) -o ${dst} 
$(INC) ${src}
+
 [C-Code-File.COMMON.IPF]
 
 ?.c
@@ -267,7 +270,10 @@
 
 
 "$(SLINK)" -cr ${dst} $(SLINK_FLAGS) @$(OBJECT_FILES_LIST)
-
+
+
+"$(SLINK)" cr ${dst} $(SLINK_FLAGS) @$(OBJECT_FILES_LIST)
+
 
 "$(SLINK)" $(SLINK_FLAGS) ${dst} --via $(OBJECT_FILES_LIST)
 
@@ -295,6 +301,10 @@
 "$(DLINK)" -o ${dst} $(DLINK_FLAGS) --start-group $(DLINK_SPATH) 
@$(STATIC_LIBRARY_FILES_LIST) --end-group $(DLINK2_FLAGS)
 "$(OBJCOPY)" $(OBJCOPY_FLAGS) ${dst}
 
+
+"$(DLINK)" -o ${dst} $(DLINK_FLAGS) 
-Wl,--start-group,$(DLINK_SPATH),@$(STATIC_LIBRARY_FILES_LIST) -Wl,--end-group 
$(DLINK2_FLAGS)
+"$(OBJCOPY)" $(OBJCOPY_FLAGS) ${dst}
+
 
 "$(DLINK)" $(DLINK_FLAGS) -o ${dst} $(DLINK_SPATH) --via 
$(STATIC_LIBRARY_FILES_LIST) $(DLINK2_FLAGS)
 
@@ -448,6 +458,11 @@
 "$(ASLDLINK)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll 
$(ASLDLINK_FLAGS) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
 "$(GENFW)" -o ${dst} -c $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll 
$(GENFW_FLAGS)
 
+
+"$(ASLCC)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj $(ASLCC_FLAGS) 
$(INC) ${src}
+"$(ASLDLINK)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll 
$(ASLDLINK_FLAGS) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
+"$(GENFW)" -o ${dst} -c $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll 
$(GENFW_FLAGS)
+
 
 "$(ASLCC)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj  $(ASLCC_FLAGS) 
$(INC) ${src}
 "$(ASLDLINK)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll 
$(ASLDLINK_FLAGS) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
old mode 100644
new mode 100755
index 2065fa3..d401031
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -366,12 +366,30 @@ DEFINE SOURCERY_CYGWIN_TOOLS = /cygdrive/c/Program 
Files/CodeSourcery/Sourcery G
 # Required to build platforms or ACPI tables:
 #   Intel(r) ACPI Compiler from
 #   https://acpica.org/downloads
+#   GCC53-Linux-  Requires:
+# GCC 5.3 targeting x86_64-linux-gnu
+#Optional:
+# Required to build platforms or ACPI tables:
+#   Intel(r) ACPI Compiler from
+#   https://acpica.org/downloads
 #   CLANG35 -Linux,Windows-  Requires:
 # Clang v3.5 or later, and GNU binutils targeting 
aarch64-linux-gnu or arm-linux-gnueabi
 #Optional:
 # Required to build platforms or ACPI tables:
 #   Intel(r) ACPI Compiler from
 #   https://acpica.org/downloads
+#   CLANG38  -Linux-  Requires:
+# Clang v3.8 or later, LLVMgold plugin and GNU 
binutils 2.26 targeting x86_64-linux-gnu
+#Optional:
+# Required to build platforms or ACPI tables:
+#   Intel(r) ACPI Compiler from
+#   https://acpica.org/downloads
+#   CLANGSCAN38 -Linux-  Requires:
+# Clang v3.8 or later, and GNU binutils 2.26 
targeting x86_64-linux-gnu
+#Optional:
+# Required to build platforms or ACPI tables:
+#

[edk2] [PATCH 5/7] QuarkSocPkg-MemoryInitPei: Enable compiler builtin and disable CLANG LTO

2016-06-28 Thread Shi, Steven

The MRC use the memset() in the code and assume the compiler to offer
such builtin fuctions. Add work around to permit compiler add builtin
functions in this module. Also MRC mix some inline assembly,
e.g. asm("rdtsc":"=a"(tscL),"=d"(tscH)),in the C code, and CLANG38
could wrongly remove them if enable LTO with high optimization level.
Add work around to simply disable the LTO in this module.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Steven Shi 
---
 QuarkSocPkg/QuarkNorthCluster/MemoryInit/Pei/MemoryInitPei.inf | 3 +++
 1 file changed, 3 insertions(+)
 mode change 100644 => 100755 
QuarkSocPkg/QuarkNorthCluster/MemoryInit/Pei/MemoryInitPei.inf

diff --git a/QuarkSocPkg/QuarkNorthCluster/MemoryInit/Pei/MemoryInitPei.inf 
b/QuarkSocPkg/QuarkNorthCluster/MemoryInit/Pei/MemoryInitPei.inf
old mode 100644
new mode 100755
index 78821f5..f593ef1
--- a/QuarkSocPkg/QuarkNorthCluster/MemoryInit/Pei/MemoryInitPei.inf
+++ b/QuarkSocPkg/QuarkNorthCluster/MemoryInit/Pei/MemoryInitPei.inf
@@ -38,6 +38,9 @@
   GCC:RELEASE_*_*_CC_FLAGS = -DNDEBUG -DGCC -Wno-unused-function
   INTEL:RELEASE_*_*_CC_FLAGS   = /D NDEBUG
   MSFT:RELEASE_*_*_CC_FLAGS= /D NDEBUG
+  GCC:*_CLANG38_IA32_CC_FLAGS  = -fno-lto -fbuiltin
+  GCC:*_CLANGSCAN38_IA32_CC_FLAGS  = -fno-lto -fbuiltin
+  GCC:*_GCC53_IA32_CC_FLAGS= -fbuiltin
 
 [Sources]
   memory_options.h
-- 
2.7.4

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

[edk2] [PATCH 6/7] QuarkSocPkg-OhicPei: Fix wrong operator

2016-06-28 Thread Shi, Steven

LANG38 find a bug and give a warning that Ohci silicon code wrongly
use '||' as '|'.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Steven Shi 
---
 QuarkSocPkg/QuarkSouthCluster/Usb/Ohci/Pei/OhciReg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 mode change 100644 => 100755 
QuarkSocPkg/QuarkSouthCluster/Usb/Ohci/Pei/OhciReg.c

diff --git a/QuarkSocPkg/QuarkSouthCluster/Usb/Ohci/Pei/OhciReg.c 
b/QuarkSocPkg/QuarkSouthCluster/Usb/Ohci/Pei/OhciReg.c
old mode 100644
new mode 100755
index bb33989..65116c8
--- a/QuarkSocPkg/QuarkSouthCluster/Usb/Ohci/Pei/OhciReg.c
+++ b/QuarkSocPkg/QuarkSouthCluster/Usb/Ohci/Pei/OhciReg.c
@@ -1042,7 +1042,7 @@ OhciSetRootHubDescriptor (
   HcRH_DESC_B DescriptorB;
 
 
-  if (Field & (RH_DEV_REMOVABLE || RH_PORT_PWR_CTRL_MASK)) {
+  if (Field & (RH_DEV_REMOVABLE | RH_PORT_PWR_CTRL_MASK)) {
 *(UINT32 *)  = OhciGetOperationalReg (Ohc, HC_RH_DESC_B);
 
 if(Field & RH_DEV_REMOVABLE) {
-- 
2.7.4

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

[edk2] [PATCH 7/7] ShellPkg-UefiShellTftpCommandLib: Replace compiler builtin

2016-06-28 Thread Shi, Steven

Use explicit CopyMem to replace compiler builtin to do the structure
values assignment.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Steven Shi 
---
 ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 mode change 100644 => 100755 ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c

diff --git a/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c 
b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
old mode 100644
new mode 100755
index 666ee9d..5c50797
--- a/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
+++ b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
@@ -342,7 +342,7 @@ ShellCommandRunTftp (
 goto Error;
   }
 
-  Mtftp4ConfigData = DefaultMtftp4ConfigData;
+  CopyMem (, , sizeof 
(EFI_MTFTP4_CONFIG_DATA));
 
   //
   // Check the host IPv4 address
-- 
2.7.4

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

[edk2] [PATCH 3/7] MdePkg: Enable new MS VA intrinsics for GNUC 64bits build

2016-06-28 Thread Shi, Steven

Both GCC and LLVM 3.8 64bits support new variable argument (VA)
intrinsics for Microsoft ABI, enable these new VA intrinsics for
GNUC family 64bits code build. These VA intrinsics are only
permitted use in 64bits code, so not use them in 32bits code build.
The original 32bits GNU VA intrinsics has the same calling conversion
as MS, so we don’t need change them.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Steven Shi 
---
 MdePkg/Include/Base.h | 27 +--
 1 file changed, 25 insertions(+), 2 deletions(-)
 mode change 100644 => 100755 MdePkg/Include/Base.h

diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
old mode 100644
new mode 100755
index cbd9e55..05fccf3
--- a/MdePkg/Include/Base.h
+++ b/MdePkg/Include/Base.h
@@ -588,9 +588,32 @@ struct _LIST_ENTRY {
 
 #define VA_COPY(Dest, Start)  __va_copy (Dest, Start)
 
-#elif defined(__GNUC__) && !defined(NO_BUILTIN_VA_FUNCS)
+
+#elif defined(__GNUC__) && !defined(NO_BUILTIN_VA_FUNCS) && !defined (EFI32)
+//
+// 64bits build only. Use GCC built-in macros for variable argument lists.
+//
+///
+/// Both GCC and LLVM 3.8 64bits support new variable argument intrinsics for 
Microsoft ABI
+///
+
+///
+/// Variable used to traverse the list of arguments. This type can vary by
+/// implementation and could be an array or structure.
+///
+typedef __builtin_ms_va_list VA_LIST;
+
+#define VA_START(Marker, Parameter)  __builtin_ms_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_ms_va_end (Marker)
+
+#define VA_COPY(Dest, Start) __builtin_ms_va_copy (Dest, Start)
+
+#elif defined(__GNUC__) && !defined(NO_BUILTIN_VA_FUNCS) && defined (EFI32)
 //
-// Use GCC built-in macros for variable argument lists.
+// 32bits build only. Use GCC built-in macros for variable argument lists.
 //
 
 ///
-- 
2.7.4

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

[edk2] [PATCH 4/7] QuarkPlatformPkg-AcpiPlatform: Downgrade the optimization to O1

2016-06-28 Thread Shi, Steven

Quark AcpiPlatform module cannot link successfully by CLANG38
with Oz optimization level. Add a work around to downgrade the
optimization to O1.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Steven Shi 
---
 QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.inf | 4 
 1 file changed, 4 insertions(+)
 mode change 100644 => 100755 
QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.inf

diff --git a/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.inf 
b/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.inf
old mode 100644
new mode 100755
index dcf2b4a..f1bcfa1
--- a/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.inf
+++ b/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.inf
@@ -200,3 +200,7 @@
 
 [Depex]
   gEfiMpServiceProtocolGuid AND gEfiAcpiTableProtocolGuid
+
+[BuildOptions]
+  GCC:*_CLANG38_IA32_DLINK_FLAGS  = -O1
+  GCC:*_CLANGSCAN38_IA32_DLINK_FLAGS  = -O1
-- 
2.7.4

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

[edk2] [PATCH 2/7] BaseTools: Add missing Elf relocation type for LTO build

2016-06-28 Thread Shi, Steven

Add support to convert missing Elf relocation types
(R_X86_64_PLT32, R_X86_64_GOTPCREL, R_X86_64_REX_GOTPCRELX)
to PeCoff, which are required by LTO image.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Steven Shi 
---
 BaseTools/Source/C/GenFw/Elf64Convert.c | 98 -
 BaseTools/Source/C/GenFw/elf_common.h   |  2 +-
 2 files changed, 86 insertions(+), 14 deletions(-)
 mode change 100644 => 100755 BaseTools/Source/C/GenFw/Elf64Convert.c
 mode change 100644 => 100755 BaseTools/Source/C/GenFw/elf_common.h

diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c 
b/BaseTools/Source/C/GenFw/Elf64Convert.c
old mode 100644
new mode 100755
index 024a2a0..205360c
--- a/BaseTools/Source/C/GenFw/Elf64Convert.c
+++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
@@ -75,7 +75,7 @@ CleanUp64 (
   );
 
 //
-// Rename ELF32 strucutres to common names to help when porting to ELF64.
+// Rename ELF32 structures to common names to help when porting to ELF64.
 //
 typedef Elf64_Shdr Elf_Shdr;
 typedef Elf64_Ehdr Elf_Ehdr;
@@ -233,7 +233,7 @@ IsTextShdr (
   Elf_Shdr *Shdr
   )
 {
-  return (BOOLEAN) ((Shdr->sh_flags & (SHF_WRITE | SHF_ALLOC)) == SHF_ALLOC);
+  return (BOOLEAN) ((Shdr->sh_flags & (SHF_EXECINSTR | SHF_WRITE | SHF_ALLOC)) 
== (SHF_EXECINSTR | SHF_ALLOC));
 }
 
 STATIC
@@ -256,7 +256,7 @@ IsDataShdr (
   if (IsHiiRsrcShdr(Shdr)) {
 return FALSE;
   }
-  return (BOOLEAN) (Shdr->sh_flags & (SHF_WRITE | SHF_ALLOC)) == (SHF_ALLOC | 
SHF_WRITE);
+  return (BOOLEAN) (Shdr->sh_flags & (SHF_EXECINSTR | SHF_WRITE | SHF_ALLOC)) 
== (SHF_ALLOC | SHF_WRITE);
 }
 
 STATIC
@@ -661,9 +661,9 @@ WriteSections64 (
 
   default:
 //
-//  Ignore for unkown section type.
+//  Ignore for unknown section type.
 //
-VerboseMsg ("%s unknown section type %x. We directly copy this section 
into Coff file", mInImageName, (unsigned)Shdr->sh_type);
+VerboseMsg ("%s unknown section type %x. We directly ignore this 
section and NOT copy into Coff file", mInImageName, (unsigned)Shdr->sh_type);
 break;
   }
 }
@@ -763,24 +763,24 @@ WriteSections64 (
 // Absolute relocation.
 //
 VerboseMsg ("R_X86_64_64");
-VerboseMsg ("Offset: 0x%08X, Addend: 0x%016LX", 
-  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)), 
+VerboseMsg ("Offset: 0x%08X, Addend: 0x%016LX",
+  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
   *(UINT64 *)Targ);
 *(UINT64 *)Targ = *(UINT64 *)Targ - SymShdr->sh_addr + 
mCoffSectionsOffset[Sym->st_shndx];
 VerboseMsg ("Relocation:  0x%016LX", *(UINT64*)Targ);
 break;
   case R_X86_64_32:
 VerboseMsg ("R_X86_64_32");
-VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X", 
-  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)), 
+VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X",
+  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
   *(UINT32 *)Targ);
 *(UINT32 *)Targ = (UINT32)((UINT64)(*(UINT32 *)Targ) - 
SymShdr->sh_addr + mCoffSectionsOffset[Sym->st_shndx]);
 VerboseMsg ("Relocation:  0x%08X", *(UINT32*)Targ);
 break;
   case R_X86_64_32S:
 VerboseMsg ("R_X86_64_32S");
-VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X", 
-  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)), 
+VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X",
+  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
   *(UINT32 *)Targ);
 *(INT32 *)Targ = (INT32)((INT64)(*(INT32 *)Targ) - 
SymShdr->sh_addr + mCoffSectionsOffset[Sym->st_shndx]);
 VerboseMsg ("Relocation:  0x%08X", *(UINT32*)Targ);
@@ -790,14 +790,34 @@ WriteSections64 (
 // Relative relocation: Symbol - Ip + Addend
 //
 VerboseMsg ("R_X86_64_PC32");
-VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X", 
-  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)), 
+VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X",
+  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
   *(UINT32 *)Targ);
 *(UINT32 *)Targ = (UINT32) (*(UINT32 *)Targ
   + (mCoffSectionsOffset[Sym->st_shndx] - SymShdr->sh_addr)
   - (SecOffset - SecShdr->sh_addr));
 VerboseMsg ("Relocation:  0x%08X", *(UINT32 *)Targ);
 break;
+  case R_X86_64_PLT32:
+//
+// Relative relocation: L + A - P
+//
+VerboseMsg ("R_X86_64_PLT32");
+VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X",
+  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
+  *(UINT32 *)Targ);
+*(UINT32 *)Targ = (UINT32)

Re: [edk2] [PATCH] [MdePkg ] Additional Atapi.h definitions complying Industry Standard specifications.

2016-06-28 Thread Tian, Feng

Hi, Anandakrishnan

Reviewed-by: Feng Tian 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao, 
Liming
Sent: Monday, June 27, 2016 5:15 PM
To: Anandakrishnan Loganathan ; edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH] [MdePkg ] Additional Atapi.h definitions complying 
Industry Standard specifications.

Got it. We will review this change. 

> -Original Message-
> From: Anandakrishnan Loganathan [mailto:anandakrishn...@ami.com]
> Sent: Monday, June 27, 2016 5:12 PM
> To: Gao, Liming ; edk2-devel@lists.01.org
> Subject: RE: [PATCH] [MdePkg ] Additional Atapi.h definitions 
> complying Industry Standard specifications.
> 
> Hi Gao,
> 
> Sorry.. I will check the problem in creating the patch my side. 
> Meanwhile I have attached the Atapi.h for your reference
> 
> Thanks!
> 
> 
> -Original Message-
> From: Gao, Liming [mailto:liming@intel.com]
> Sent: 27 June 2016 14:33
> To: Anandakrishnan Loganathan; edk2-devel@lists.01.org
> Subject: RE: [PATCH] [MdePkg ] Additional Atapi.h definitions 
> complying Industry Standard specifications.
> 
> Anandakrishnan:
>Your patch format is Unicode. I can't apply it. Could you create 
> the normal GIT patch or directly send the updated Atapi.h?
> 
> > -Original Message-
> > From: Anandakrishnan Loganathan [mailto:anandakrishn...@ami.com]
> > Sent: Monday, June 27, 2016 2:02 PM
> > To: Gao, Liming ; edk2-devel@lists.01.org
> > Subject: RE: [PATCH] [MdePkg ] Additional Atapi.h definitions 
> > complying Industry Standard specifications.
> >
> > Attached the Patch with the mail
> >
> > -Original Message-
> > From: Gao, Liming [mailto:liming@intel.com]
> > Sent: 27 June 2016 09:41
> > To: Anandakrishnan Loganathan; edk2-devel@lists.01.org
> > Subject: RE: [PATCH] [MdePkg ] Additional Atapi.h definitions 
> > complying Industry Standard specifications.
> >
> > Hi, could you attach your patch?
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On 
> > > Behalf Of Anandakrishnan Loganathan
> > > Sent: Friday, June 24, 2016 4:56 PM
> > > To: edk2-devel@lists.01.org
> > > Subject: [edk2] [PATCH] [MdePkg ] Additional Atapi.h definitions 
> > > complying Industry Standard specifications.
> > >
> > > Dear MdePkg maintainer,
> > >
> > >
> > > Atapi.h  has only limited ATA/ATAPI related specification 
> > > definitions and this attached patch includes various commonly 
> > > usage Industry Standard definitions in Atapi.h. Please review and 
> > > update to the
> MdePkg.
> > >
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.0
> > > Signed-off-by: Anandakrishnan Loganathan 
> > > anandakrishn...@ami.com
> > >
> > >
> > > Thanks!
> > > Anandakrishnan
> > > ___
> > > 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] [PATCH 6/6] Vlv2TbltDevicePkg: fix ASSERT_EFI_ERROR() typos

2016-06-28 Thread Laszlo Ersek

A number of code locations use

  ASSERT_EFI_ERROR (BooleanExpression)

instead of

  ASSERT (BooleanExpression)

Fix them.

Cc: David Wei 
Cc: Tim He 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
not even build tested

 Vlv2TbltDevicePkg/FvbRuntimeDxe/FvbService.c   | 6 
+++---
 Vlv2TbltDevicePkg/Library/MultiPlatformLib/BoardClkGens/BoardClkGens.c | 8 

 Vlv2TbltDevicePkg/Library/MultiPlatformLib/PlatformInfoHob.c   | 2 +-
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/Vlv2TbltDevicePkg/FvbRuntimeDxe/FvbService.c 
b/Vlv2TbltDevicePkg/FvbRuntimeDxe/FvbService.c
index da7dce6e13c7..7c95c107e600 100644
--- a/Vlv2TbltDevicePkg/FvbRuntimeDxe/FvbService.c
+++ b/Vlv2TbltDevicePkg/FvbRuntimeDxe/FvbService.c
@@ -154,7 +154,7 @@ FvbGetVolumeAttributes (
 {
   EFI_FW_VOL_INSTANCE *FwInstance = NULL;
   FwInstance = GetFvbInstance(Instance);
-  ASSERT_EFI_ERROR (FwInstance != NULL);
+  ASSERT (FwInstance != NULL);
 
   if ( FwInstance != NULL ) {
 return FwInstance->VolumeHeader.Attributes;
@@ -208,7 +208,7 @@ FvbGetLbaAddress (
   StartLba  = 0;
   Offset= 0;
   BlockMap  = &(FwhInstance->VolumeHeader.BlockMap[0]);
-  ASSERT_EFI_ERROR (BlockMap != NULL);
+  ASSERT (BlockMap != NULL);
 
   //
   // Parse the blockmap of the FV to find which map entry the Lba belongs to.
@@ -512,7 +512,7 @@ FvbSetVolumeAttributes (
   FwhInstance = GetFvbInstance (Instance);
 
   AttribPtr = (EFI_FVB_ATTRIBUTES_2 *) & 
(FwhInstance->VolumeHeader.Attributes);
-  ASSERT_EFI_ERROR (AttribPtr != NULL);
+  ASSERT (AttribPtr != NULL);
 
   if ( AttribPtr != NULL) {
 OldAttributes = *AttribPtr;
diff --git 
a/Vlv2TbltDevicePkg/Library/MultiPlatformLib/BoardClkGens/BoardClkGens.c 
b/Vlv2TbltDevicePkg/Library/MultiPlatformLib/BoardClkGens/BoardClkGens.c
index e38633b2b3ae..7d740df2fef9 100644
--- a/Vlv2TbltDevicePkg/Library/MultiPlatformLib/BoardClkGens/BoardClkGens.c
+++ b/Vlv2TbltDevicePkg/Library/MultiPlatformLib/BoardClkGens/BoardClkGens.c
@@ -69,10 +69,10 @@ ConfigureClockGenerator (
   //
   // Verify input arguments
   //
-  ASSERT_EFI_ERROR (ConfigurationTableLength >= 6);
-  ASSERT_EFI_ERROR (ConfigurationTableLength <= 
MAX_CLOCK_GENERATOR_BUFFER_LENGTH);
-  ASSERT_EFI_ERROR (ClockType < ClockGeneratorMax);
-  ASSERT_EFI_ERROR (ConfigurationTable != NULL);
+  ASSERT (ConfigurationTableLength >= 6);
+  ASSERT (ConfigurationTableLength <= MAX_CLOCK_GENERATOR_BUFFER_LENGTH);
+  ASSERT (ClockType < ClockGeneratorMax);
+  ASSERT (ConfigurationTable != NULL);
 
   //
   // Read the clock generator
diff --git a/Vlv2TbltDevicePkg/Library/MultiPlatformLib/PlatformInfoHob.c 
b/Vlv2TbltDevicePkg/Library/MultiPlatformLib/PlatformInfoHob.c
index ebaaf40a165e..9d77e86678fe 100644
--- a/Vlv2TbltDevicePkg/Library/MultiPlatformLib/PlatformInfoHob.c
+++ b/Vlv2TbltDevicePkg/Library/MultiPlatformLib/PlatformInfoHob.c
@@ -49,7 +49,7 @@ GetPlatformInfoHob (
   //
   // PlatformInfo PEIM should provide this HOB data, if not ASSERT and return 
error.
   //
-  ASSERT_EFI_ERROR (*PlatformInfoHob != NULL);
+  ASSERT (*PlatformInfoHob != NULL);
   if (!(*PlatformInfoHob)) {
 return EFI_NOT_FOUND;
   }
-- 
1.8.3.1

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

[edk2] [PATCH 4/6] ShellPkg: don't call functions with side effects in ASSERT_EFI_ERROR()

2016-06-28 Thread Laszlo Ersek

When ASSERT_EFI_ERROR() is compiled out, dependent on build flags, only
the status checking should be removed; the function calls should stay.

Cc: Jaben Carsey 
Cc: Shumin Qiu 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
build tested

 ShellPkg/Library/UefiShellLevel1CommandsLib/If.c | 10 --
 ShellPkg/Library/UefiShellLib/UefiShellLib.c |  5 -
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/ShellPkg/Library/UefiShellLevel1CommandsLib/If.c 
b/ShellPkg/Library/UefiShellLevel1CommandsLib/If.c
index 7abfd8944b92..dc96bffde7d3 100644
--- a/ShellPkg/Library/UefiShellLevel1CommandsLib/If.c
+++ b/ShellPkg/Library/UefiShellLevel1CommandsLib/If.c
@@ -991,8 +991,11 @@ ShellCommandRunElse (
   IN EFI_SYSTEM_TABLE  *SystemTable
   )
 {
+  EFI_STATUS  Status;
   SCRIPT_FILE *CurrentScriptFile;
-  ASSERT_EFI_ERROR(CommandInit());
+
+  Status = CommandInit ();
+  ASSERT_EFI_ERROR (Status);
 
   if (gEfiShellParametersProtocol->Argc > 1) {
 ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_GEN_TOO_MANY), 
gShellLevel1HiiHandle, L"if");  
@@ -1066,8 +1069,11 @@ ShellCommandRunEndIf (
   IN EFI_SYSTEM_TABLE  *SystemTable
   )
 {
+  EFI_STATUS  Status;
   SCRIPT_FILE *CurrentScriptFile;
-  ASSERT_EFI_ERROR(CommandInit());
+
+  Status = CommandInit ();
+  ASSERT_EFI_ERROR (Status);
 
   if (gEfiShellParametersProtocol->Argc > 1) {
 ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_GEN_TOO_MANY), 
gShellLevel1HiiHandle, L"if");  
diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c 
b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
index cf89a4ac87ed..35a1a7169c8b 100644
--- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
+++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
@@ -373,6 +373,8 @@ EFIAPI
 ShellInitialize (
   )
 {
+  EFI_STATUS Status;
+
   //
   // if auto initialize is not false then skip
   //
@@ -383,7 +385,8 @@ ShellInitialize (
   //
   // deinit the current stuff
   //
-  ASSERT_EFI_ERROR(ShellLibDestructor(gImageHandle, gST));
+  Status = ShellLibDestructor (gImageHandle, gST);
+  ASSERT_EFI_ERROR (Status);
 
   //
   // init the new stuff
-- 
1.8.3.1


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

[edk2] [PATCH 0/6] fix ASSERT_EFI_ERROR() misuse around the tree

2016-06-28 Thread Laszlo Ersek

Gerd's Jenkins CI worker has recently tried to build a few edk2 packages
with gcc-6. Gcc-6 introduces a new warning (among many others, likely)
called "bool-compare":

  
https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/Warning-Options.html#index-Wbool-compare-453

The build broke subsequently, exposing an actual bug in the code:

> "gcc" -g -fshort-wchar -fno-strict-aliasing -Wall -Werror
> -Wno-array-bounds -ffunction-sections -fdata-sections -c -include
> AutoGen.h -fno-common -DSTRING_ARRAY_NAME=PiSmmCpuDxeSmmStrings -m64
> -fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))"
> -DNO_BUILTIN_VA_FUNCS -mno-red-zone -Wno-address -mcmodel=large
> -fno-asynchronous-unwind-tables -Wno-address -mno-mmx -mno-sse -o
> Build/OvmfX64/DEBUG_GCC49/X64/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm/OUTPUT/X64/SmmProfileArch.obj
> -IUefiCpuPkg/PiSmmCpuDxeSmm/X64 -IUefiCpuPkg/PiSmmCpuDxeSmm
> -IBuild/OvmfX64/DEBUG_GCC49/X64/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm/DEBUG
> -IMdePkg -IMdePkg/Include -IMdePkg/Include/X64 -IMdeModulePkg
> -IMdeModulePkg/Include -IUefiCpuPkg -IUefiCpuPkg/Include
> UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmProfileArch.c
>
> In file included from 
> Build/OvmfX64/DEBUG_GCC49/X64/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm/DEBUG/AutoGen.h:16:0,
>  from :0:
> UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmProfileArch.c: In function 
> 'InitPagesForPFHandler':
> MdePkg/Include/Base.h:882:75: error: comparison of constant '0' with boolean 
> expression is always false [-Werror=bool-compare]
>  #define RETURN_ERROR(StatusCode) (((INTN)(RETURN_STATUS)(StatusCode)) < 
> 0)
>^
> MdePkg/Include/Uefi/UefiBaseType.h:169:35: note: in expansion of macro 
> 'RETURN_ERROR'
>  #define EFI_ERROR(A)  RETURN_ERROR(A)
>^~~~
> MdePkg/Include/Library/DebugLib.h:341:13: note: in expansion of macro 
> 'EFI_ERROR'
>  if (EFI_ERROR (StatusParameter)) {   
> \
>  ^
> UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmProfileArch.c:81:3: note: in expansion of 
> macro 'ASSERT_EFI_ERROR'
>ASSERT_EFI_ERROR (Address != NULL);
>^~~~
> cc1: all warnings being treated as errors

This is fixed by one of the patches in the series (and I added Gerd's
Reported-by there). Then I searched the tree for further misuses of
ASSERT_EFI_ERROR, and fixed what I found.

Cc: David Wei 
Cc: Gerd Hoffmann 
Cc: Jaben Carsey 
Cc: Jeff Fan 
Cc: Jiaxin Wu 
Cc: Kelly Steele 
Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Shumin Qiu 
Cc: Siyuan Fu 
Cc: Tim He 

Thanks
Laszlo

Laszlo Ersek (6):
  EdkCompatibilityPkg: fix ASSERT_EFI_ERROR() typos
  NetworkPkg: fix ASSERT_EFI_ERROR() typos
  QuarkPlatformPkg: fix ASSERT_EFI_ERROR() typos
  ShellPkg: don't call functions with side effects in ASSERT_EFI_ERROR()
  UefiCpuPkg: fix ASSERT_EFI_ERROR() typos
  Vlv2TbltDevicePkg: fix ASSERT_EFI_ERROR() typos

 EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/HiiDatabase.c |  
2 +-
 EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/Utility.c |  
2 +-
 NetworkPkg/IpSecDxe/Ikev2/Sa.c |  
2 +-
 QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.c  |  
2 +-
 QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/MadtPlatform.c  |  
2 +-
 QuarkPlatformPkg/Library/PlatformHelperLib/PlatformHelperDxe.c |  
2 +-
 QuarkPlatformPkg/Platform/Pei/PlatformInit/MrcWrapper.c|  
2 +-
 ShellPkg/Library/UefiShellLevel1CommandsLib/If.c   | 
10 --
 ShellPkg/Library/UefiShellLib/UefiShellLib.c   |  
5 -
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmProfileArch.c |  
2 +-
 Vlv2TbltDevicePkg/FvbRuntimeDxe/FvbService.c   |  
6 +++---
 Vlv2TbltDevicePkg/Library/MultiPlatformLib/BoardClkGens/BoardClkGens.c |  
8 
 Vlv2TbltDevicePkg/Library/MultiPlatformLib/PlatformInfoHob.c   |  
2 +-
 13 files changed, 28 insertions(+), 19 deletions(-)

-- 
1.8.3.1

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

[edk2] [PATCH 3/6] QuarkPlatformPkg: fix ASSERT_EFI_ERROR() typos

2016-06-28 Thread Laszlo Ersek

A number of code locations use

  ASSERT_EFI_ERROR (BooleanExpression)

instead of

  ASSERT (BooleanExpression)

Fix them.

Cc: Michael D Kinney 
Cc: Kelly Steele 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
not even build tested

 QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.c  | 2 +-
 QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/MadtPlatform.c  | 2 +-
 QuarkPlatformPkg/Library/PlatformHelperLib/PlatformHelperDxe.c | 2 +-
 QuarkPlatformPkg/Platform/Pei/PlatformInit/MrcWrapper.c| 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.c 
b/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.c
index 309eb041ee92..36300efd3146 100644
--- a/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.c
+++ b/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.c
@@ -680,7 +680,7 @@ AcpiPlatformEntryPoint (
   // Init Pci Device PRT PRW information structure from PCD
   //
   mConfigData = (PCI_DEVICE_SETTING *)AllocateZeroPool (sizeof 
(PCI_DEVICE_SETTING));
-  ASSERT_EFI_ERROR (mConfigData);
+  ASSERT (mConfigData != NULL);
   InitPciDeviceInfoStructure (mConfigData);
   //
   // Get the Acpi SDT protocol for manipulation on acpi table
diff --git a/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/MadtPlatform.c 
b/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/MadtPlatform.c
index 11781e03f4c5..98035bedd58f 100644
--- a/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/MadtPlatform.c
+++ b/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/MadtPlatform.c
@@ -218,7 +218,7 @@ MadtTableInitialize (
   //ASSERT (NumberOfCPUs <= 2 && NumberOfCPUs > 0);
   MadtSize = GetAcutalMadtTableSize (, NumberOfCPUs);
   Madt = (EFI_ACPI_2_0_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER 
*)AllocateZeroPool (MadtSize);
-  ASSERT_EFI_ERROR (Madt);
+  ASSERT (Madt != NULL);
   //
   // Initialize MADT Header information
   //
diff --git a/QuarkPlatformPkg/Library/PlatformHelperLib/PlatformHelperDxe.c 
b/QuarkPlatformPkg/Library/PlatformHelperLib/PlatformHelperDxe.c
index 441f7609a536..39185bc0d5ff 100644
--- a/QuarkPlatformPkg/Library/PlatformHelperLib/PlatformHelperDxe.c
+++ b/QuarkPlatformPkg/Library/PlatformHelperLib/PlatformHelperDxe.c
@@ -174,7 +174,7 @@ PlatformFlashLockConfig (
   //
 
   SpiProtocol = LocateSpiProtocol (NULL);  // This routine will not be called 
in SMM.
-  ASSERT_EFI_ERROR (SpiProtocol != NULL);
+  ASSERT (SpiProtocol != NULL);
   if (SpiProtocol != NULL) {
 Status = SpiProtocol->Lock (SpiProtocol);
 
diff --git a/QuarkPlatformPkg/Platform/Pei/PlatformInit/MrcWrapper.c 
b/QuarkPlatformPkg/Platform/Pei/PlatformInit/MrcWrapper.c
index df6c1cc23240..6b07d7829328 100644
--- a/QuarkPlatformPkg/Platform/Pei/PlatformInit/MrcWrapper.c
+++ b/QuarkPlatformPkg/Platform/Pei/PlatformInit/MrcWrapper.c
@@ -1034,7 +1034,7 @@ InstallS3Memory (
   // memory above 1MB. So Memory Callback can set cache for the system memory
   // correctly on S3 boot path, just like it does on Normal boot path.
   //
-  ASSERT_EFI_ERROR ((S3MemoryRangeData->SystemMemoryLength - 0x10) > 0);
+  ASSERT ((S3MemoryRangeData->SystemMemoryLength - 0x10) > 0);
   BuildResourceDescriptorHob (
 EFI_RESOURCE_SYSTEM_MEMORY,
 (
-- 
1.8.3.1


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

[edk2] [PATCH 1/6] EdkCompatibilityPkg: fix ASSERT_EFI_ERROR() typos

2016-06-28 Thread Laszlo Ersek

A number of code locations use

  ASSERT_EFI_ERROR (BooleanExpression)

instead of

  ASSERT (BooleanExpression)

Fix them.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
build tested only

 EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/HiiDatabase.c | 2 
+-
 EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/Utility.c | 2 
+-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/HiiDatabase.c 
b/EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/HiiDatabase.c
index 386ff327f81b..2d456da30353 100644
--- a/EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/HiiDatabase.c
+++ b/EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/HiiDatabase.c
@@ -494,7 +494,7 @@ HiiGetSecondaryLanguages (
   UnicodeStrToAsciiStr (PrimaryLanguage, PrimaryLang639);
 
   PrimaryLang4646 = ConvertLanguagesIso639ToRfc4646 (PrimaryLang639);
-  ASSERT_EFI_ERROR (PrimaryLang4646 != NULL);
+  ASSERT (PrimaryLang4646 != NULL);
 
   SecLangCodes4646 = HiiGetSupportedSecondaryLanguages (UefiHiiHandle, 
PrimaryLang4646);
 
diff --git 
a/EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/Utility.c 
b/EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/Utility.c
index f6d97f63444f..d269b8e4d6ba 100644
--- a/EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/Utility.c
+++ b/EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/Utility.c
@@ -153,7 +153,7 @@ ExportPackageLists (
,
PackageListHdr
);
-  ASSERT_EFI_ERROR (Status != EFI_BUFFER_TOO_SMALL);
+  ASSERT (Status != EFI_BUFFER_TOO_SMALL);
   
   if (Status == EFI_BUFFER_TOO_SMALL) {
 PackageListHdr = AllocateZeroPool (Size);
-- 
1.8.3.1


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

[edk2] [PATCH 2/6] NetworkPkg: fix ASSERT_EFI_ERROR() typos

2016-06-28 Thread Laszlo Ersek

A number of code locations use

  ASSERT_EFI_ERROR (BooleanExpression)

instead of

  ASSERT (BooleanExpression)

Fix them.

Cc: Siyuan Fu 
Cc: Jiaxin Wu 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
build tested only

 NetworkPkg/IpSecDxe/Ikev2/Sa.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/NetworkPkg/IpSecDxe/Ikev2/Sa.c b/NetworkPkg/IpSecDxe/Ikev2/Sa.c
index 74ef79c23719..4cbfac33b134 100644
--- a/NetworkPkg/IpSecDxe/Ikev2/Sa.c
+++ b/NetworkPkg/IpSecDxe/Ikev2/Sa.c
@@ -384,7 +384,7 @@ Ikev2InitPskParser (
 // 5. Generate Nr_b
 //
 IkeSaSession->NrBlock   = IkeGenerateNonce (IKE_NONCE_SIZE);
-ASSERT_EFI_ERROR (IkeSaSession->NrBlock != NULL);
+ASSERT (IkeSaSession->NrBlock != NULL);
 IkeSaSession->NrBlkSize = IKE_NONCE_SIZE;
 
 //
-- 
1.8.3.1


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

Re: [edk2] iPXE invalidates the OVMF network device options

2016-06-28 Thread Laszlo Ersek

On 06/28/16 14:43, Michael Brown wrote:
> On 28/06/16 13:34, Michael Brown wrote:
>> On 28/06/16 13:30, Laszlo Ersek wrote:
>>> On 06/24/16 06:39, Gary Lin wrote:
 It seems that iPXE didn't initialize Scope, so the value was assigned
 randomly (sort of).

 diff --git a/src/interface/efi/efi_hii.c b/src/interface/efi/efi_hii.c
 index 0ea970e..4b5aa9a 100644
 --- a/src/interface/efi/efi_hii.c
 +++ b/src/interface/efi/efi_hii.c
 @@ -119,6 +119,7 @@ static void * efi_ifr_op ( struct efi_ifr_builder
 *ifr, unsigned int opcode,
   /* Fill in opcode header */
   op->OpCode = opcode;
   op->Length = len;
 +op->Scope = 0;

   return op;
   }

 After applying this patch, the crash never happened again.
>>>
>>> Awesome! Can you please send this patch to ipxe-devel? (Although I can
>>> see Michael is on the address list anyway -- good!)
>>
>> Got it; thank you!
>>
>> Will check the related code; it may make sense to have efi_ifr_op()
>> always zero the whole of the newly allocated space first.
> 
> I think the following patch should fix the problem (and also avoid any
> potential uninitialised-data problems in callers of efi_ifr_op()):
> 
> diff --git a/src/interface/efi/efi_hii.c b/src/interface/efi/efi_hii.c
> index 0ea970e..506fc88 100644
> --- a/src/interface/efi/efi_hii.c
> +++ b/src/interface/efi/efi_hii.c
> @@ -117,6 +117,7 @@ static void * efi_ifr_op ( struct efi_ifr_builder
> *ifr, unsigned int opcode,
>  ifr->ops_len = new_ops_len;
> 
>  /* Fill in opcode header */
> +memset ( op, 0, len );
>  op->OpCode = opcode;
>  op->Length = len;
> 
> 
> Please let me know if this works.

Gary, can you please check this? You seem to have a mostly working
reproducer environment for the issue.

Thanks!
Laszlo

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

Re: [edk2] iPXE invalidates the OVMF network device options

2016-06-28 Thread Michael Brown


On 28/06/16 13:34, Michael Brown wrote:

On 28/06/16 13:30, Laszlo Ersek wrote:

On 06/24/16 06:39, Gary Lin wrote:

It seems that iPXE didn't initialize Scope, so the value was assigned
randomly (sort of).

diff --git a/src/interface/efi/efi_hii.c b/src/interface/efi/efi_hii.c
index 0ea970e..4b5aa9a 100644
--- a/src/interface/efi/efi_hii.c
+++ b/src/interface/efi/efi_hii.c
@@ -119,6 +119,7 @@ static void * efi_ifr_op ( struct efi_ifr_builder
*ifr, unsigned int opcode,
  /* Fill in opcode header */
  op->OpCode = opcode;
  op->Length = len;
+op->Scope = 0;

  return op;
  }

After applying this patch, the crash never happened again.


Awesome! Can you please send this patch to ipxe-devel? (Although I can
see Michael is on the address list anyway -- good!)


Got it; thank you!

Will check the related code; it may make sense to have efi_ifr_op()
always zero the whole of the newly allocated space first.


I think the following patch should fix the problem (and also avoid any 
potential uninitialised-data problems in callers of efi_ifr_op()):


diff --git a/src/interface/efi/efi_hii.c b/src/interface/efi/efi_hii.c
index 0ea970e..506fc88 100644
--- a/src/interface/efi/efi_hii.c
+++ b/src/interface/efi/efi_hii.c
@@ -117,6 +117,7 @@ static void * efi_ifr_op ( struct efi_ifr_builder 
*ifr, unsigned int opcode,

ifr->ops_len = new_ops_len;

/* Fill in opcode header */
+   memset ( op, 0, len );
op->OpCode = opcode;
op->Length = len;


Please let me know if this works.

Thanks!

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

Re: [edk2] iPXE invalidates the OVMF network device options

2016-06-28 Thread Michael Brown


On 28/06/16 13:30, Laszlo Ersek wrote:

On 06/24/16 06:39, Gary Lin wrote:

It seems that iPXE didn't initialize Scope, so the value was assigned
randomly (sort of).

diff --git a/src/interface/efi/efi_hii.c b/src/interface/efi/efi_hii.c
index 0ea970e..4b5aa9a 100644
--- a/src/interface/efi/efi_hii.c
+++ b/src/interface/efi/efi_hii.c
@@ -119,6 +119,7 @@ static void * efi_ifr_op ( struct efi_ifr_builder *ifr, 
unsigned int opcode,
/* Fill in opcode header */
op->OpCode = opcode;
op->Length = len;
+   op->Scope = 0;

return op;
  }

After applying this patch, the crash never happened again.


Awesome! Can you please send this patch to ipxe-devel? (Although I can
see Michael is on the address list anyway -- good!)


Got it; thank you!

Will check the related code; it may make sense to have efi_ifr_op() 
always zero the whole of the newly allocated space first.


Thanks again!

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

Re: [edk2] iPXE invalidates the OVMF network device options

2016-06-28 Thread Laszlo Ersek

On 06/24/16 10:41, Gerd Hoffmann wrote:
>   Hi,
> 
>> Thanks, I guess we can remove these if building with
>> DEBUG=virtio-net:2 was intentional and it interferes with other
>> output. But then again, if you build for example with DEBUG=tcp:2,
>> you'll see a debug message for each transmitted or received packet
>> also.
> 
> Sorry for the trouble.  Everything is fine.  My test configuration was
> broken, romfile= didn't point to the file I intended to test with.

Does "everything is fine" cover the other symptoms you described in your
email, such as "-device $nic,bootindex=1" not working?

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

Re: [edk2] iPXE invalidates the OVMF network device options

2016-06-28 Thread Laszlo Ersek

On 06/24/16 06:39, Gary Lin wrote:
> On Fri, Jun 24, 2016 at 10:19:30AM +0800, Gary Lin wrote:
>> On Thu, Jun 23, 2016 at 02:57:49PM +0200, Laszlo Ersek wrote:
>>> On 06/23/16 06:43, Gary Lin wrote:
 On Wed, Jun 22, 2016 at 07:24:32PM +0200, Laszlo Ersek wrote:
> Gary,
>
> On 06/22/16 17:33, Laszlo Ersek wrote:
>
> can you please retest with a fresh build of the current iPXE master (at
> 04186319181298083ef28695a8309028b26fe83c presently)? I can no longer
> reproduce the ASSERT -- the iPXE form can be entered just fine.
>
> I don't know what changed. o_O
>
 I still got the crash all the time with 0418631918. However, Switching
 to cc8824ad (plus the size fix) lowers the chance of crash largerly
 (around 1 from 10). cc8824ad is the commit that is right before this:

 5238c85b623200fa0f44a46db93965080053f745
 [efi] Work around broken EFI HII specification

 The iPXE option started to crash all the time after I switched to
 5238c85b6. However, reverting 5238c85b6 on git master didn't moderate
 the crash. The root cause is still hiding somewhere...
>>>
>>> If it reproduces non-deterministically, that's quite bad. If we don't
>>> have a reliable reproducer, I'm not sure how it can be analyzed.
>>>
>> In my case:
>>
>> ipxe git 04186319 -> always crash
>> ipxe git cc8824ad -> 10% crash
>>
>> I had some findings by comparing the crash and non-crash log with cc8824ad.
>>
>> 1. For the non-crash case, all the Statement->ParentStatement of the iPXE
>>options were NULL in InitializeDisplayStatement().
>>
>> 2. For the crash case, one of the Scope of the iPXE Statement became
>>non-zero, so 
>> MdeModulePkg/Universal/SetupBrowserDxe/IfrParse.c:ParseOpCodes()
>>assigned CurrentStatement to ParentStatement. When this happened,
>>it's always the statement for "TFTP server".
>>
> 
> It seems that iPXE didn't initialize Scope, so the value was assigned
> randomly (sort of).
> 
> diff --git a/src/interface/efi/efi_hii.c b/src/interface/efi/efi_hii.c
> index 0ea970e..4b5aa9a 100644
> --- a/src/interface/efi/efi_hii.c
> +++ b/src/interface/efi/efi_hii.c
> @@ -119,6 +119,7 @@ static void * efi_ifr_op ( struct efi_ifr_builder *ifr, 
> unsigned int opcode,
>   /* Fill in opcode header */
>   op->OpCode = opcode;
>   op->Length = len;
> + op->Scope = 0;
>  
>   return op;
>  }
> 
> After applying this patch, the crash never happened again.

Awesome! Can you please send this patch to ipxe-devel? (Although I can
see Michael is on the address list anyway -- good!)

Thanks!
Laszlo

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

Re: [edk2] [PATCH v3] ArmVirtPkg/ArmVirtXen: Add ACPI support for Virt Xen ARM

2016-06-28 Thread Ard Biesheuvel

On 25 June 2016 at 09:16, Shannon Zhao  wrote:
> From: Shannon Zhao 
>
> Add ACPI support for Virt Xen ARM and only for aarch64. It gets the
> ACPI tables through Xen ARM multiboot protocol.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Shannon Zhao 

Reviewed-by: Ard Biesheuvel 

Committed as 402dde68aff9

Thanks,
Ard.

> ---
> Changes since v2:
> * add gFdtClientProtocolGuid to the [Depex]
> * make functions static
> * move XenAcpiRsdpStructurePtr to InstallXenArmTables ()
> * initialize AcpiTable and FdtClient to NULL
>
> Changes since v1:
> * move the codes into ArmVirtPkg
> * use FdtClient
> * don't rely on OvmfPkg/AcpiPlatformDxe/EntryPoint.c while implement own
>   entry point since it's minor
> * use compatible string to find the DT node instead of node path
>
> If you want to test, the corresponding Xen patches can be fetched from:
> https://git.linaro.org/people/shannon.zhao/xen.git  domu_acpi_v2
> ---
>  ArmVirtPkg/ArmVirtXen.dsc  |   8 +
>  ArmVirtPkg/ArmVirtXen.fdf  |   8 +
>  ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c | 244 
> +
>  .../XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf  |  50 +
>  4 files changed, 310 insertions(+)
>  create mode 100644 ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
>  create mode 100644 ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
>
> diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
> index 594ca64..a869986 100644
> --- a/ArmVirtPkg/ArmVirtXen.dsc
> +++ b/ArmVirtPkg/ArmVirtXen.dsc
> @@ -216,3 +216,11 @@
>
>OvmfPkg/XenBusDxe/XenBusDxe.inf
>OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
> +
> +  #
> +  # ACPI support
> +  #
> +!if $(ARCH) == AARCH64
> +  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
> +  ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
> +!endif
> diff --git a/ArmVirtPkg/ArmVirtXen.fdf b/ArmVirtPkg/ArmVirtXen.fdf
> index 13412f9..b1e00e5 100644
> --- a/ArmVirtPkg/ArmVirtXen.fdf
> +++ b/ArmVirtPkg/ArmVirtXen.fdf
> @@ -179,6 +179,14 @@ READ_LOCK_STATUS   = TRUE
>INF OvmfPkg/XenBusDxe/XenBusDxe.inf
>INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
>
> +  #
> +  # ACPI support
> +  #
> +!if $(ARCH) == AARCH64
> +  INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
> +  INF ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
> +!endif
> +
>  [FV.FVMAIN_COMPACT]
>  FvAlignment= 16
>  ERASE_POLARITY = 1
> diff --git a/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c 
> b/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
> new file mode 100644
> index 000..c6912ba
> --- /dev/null
> +++ b/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
> @@ -0,0 +1,244 @@
> +/** @file
> +  Xen ARM ACPI Platform Driver using Xen ARM multiboot protocol
> +
> +  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 
> +
> +/**
> +  Get the address of Xen ACPI Root System Description Pointer (RSDP)
> +  structure.
> +
> +  @param  RsdpStructurePtr   Return pointer to RSDP structure
> +
> +  @return EFI_SUCCESSFind Xen RSDP structure successfully.
> +  @return EFI_NOT_FOUND  Don't find Xen RSDP structure.
> +  @return EFI_ABORTEDFind Xen RSDP structure, but it's not 
> integrated.
> +
> +**/
> +STATIC
> +EFI_STATUS
> +EFIAPI
> +GetXenArmAcpiRsdp (
> +  OUT   EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER   **RsdpPtr
> +  )
> +{
> +  EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER   *RsdpStructurePtr;
> +  EFI_STATUS Status;
> +  FDT_CLIENT_PROTOCOL*FdtClient;
> +  CONST UINT64   *Reg;
> +  UINT32 RegElemSize, RegSize;
> +  UINT64 RegBase;
> +  UINT8  Sum;
> +
> +  RsdpStructurePtr = NULL;
> +  FdtClient = NULL;
> +  //
> +  // Get the RSDP structure address from DeviceTree
> +  //
> +  Status = gBS->LocateProtocol (, NULL,
> +  (VOID **));
> +  ASSERT_EFI_ERROR (Status);
> +
> +  Status = FdtClient->FindCompatibleNodeReg (FdtClient, "xen,guest-acpi",
> +(CONST VOID **), , );
> +  if (EFI_ERROR (Status)) {
> +DEBUG ((EFI_D_WARN, "%a: No 'xen,guest-acpi' compatible DT node

Re: [edk2] Driver Health HII menu missing in OVMF master

2016-06-28 Thread Laszlo Ersek

On 06/28/16 04:02, Gao, Liming wrote:
> MdeModulePkg\Universal\DriverHealthManagerDxe\DriverHealthManagerDxe.inf is 
> missing after new MdeModulePkg/Universal/BdsDxe/BdsDxe.inf is applied. 

Thanks for the info, Liming!

Bruce, could you please submit two patches that add this driver to
OvmfPkg and ArmVirtPkg respectively, in the DSC and FDF files wherever
"MdeModulePkg/Universal/BdsDxe/BdsDxe.inf" is used?

Thanks
Laszlo

>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Bruce Cran
>> Sent: Tuesday, June 28, 2016 5:19 AM
>> To: edk2-devel@lists.01.org
>> Subject: [edk2] Driver Health HII menu missing in OVMF master
>>
>> I just noticed that between UDK2015 and master branches in
>> https://github.com/tianocore/edk2 the Driver Health display in "Device
>> Manager" has disappeared.
>>
>> Was its removal deliberate - has it been moved elsewhere?
>>
>> --
>> Bruce
>> ___
>> 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] [RFC V3.1] Proposal to organize packages into directories

2016-06-28 Thread Laszlo Ersek

On 06/28/16 09:27, Jordan Justen wrote:
> On 2016-06-26 08:44:04, Leif Lindholm wrote:
>>
>> On Fri, Jun 17, 2016 at 10:51:47PM +, Kinney, Michael D wrote:
>>> Common
>>>   CorebootPayloadPkg
>>>   DuetPkg
>>>   EmulatorPkg
>>>   Nt32Pkg
>>>   OvmfPkg
>>
>> So, I would like to propose a semi-tedious change here:
>> Merging the ArmVirtPkg and OvmfPkg directories.
>> ArmVirtPkg already uses many components maintained in OvmfPkg, and
>> ArmVirtPkg packages fulfills _exactly_ the same function, only for a
>> different architecture. We've seen a fair bit of confusion around the
>> separation of these two, both from Linux distribution packagers and
>> developers of virtualization tools and frameworks.
>>
>> My proposal is not for a heavy-handed merge of the source code, but
>> simply for moving all of the sources and platform configuration files
>> into the same package, adding the ARM targets to build.sh, and so on.
>>
> 
> I agree. While I'm not certain about it, I think we can reasonably
> manage having all virt related platforms under a single OVMF area.
> 
> I would rather think of these platforms similar to qemu ... ovmf-ia32,
> ovmf-x64, ovmf-arm, ovmf-riscv, etc... In the case of QEMU, I think we
> should have a goal to support the intersection of UEFI architectures,
> and systems supported by QEMU.
> 
> Similarly, I'd also like to try to continue to support qemu/kvm and
> Xen in the same platform area as long as it is possible. I wouldn't
> want to rule out trying to support other VMMs as well if they can mold
> reasonably into the current OVMF modules.
> 
> Laszlo has two (reasonable) concerns. First, how to assign owners?
> Today we only have 1 or 2 people per package. That doesn't work well
> if we have 5 CPU architectures in a single OVMF area of the tree.
> 
> My thought is that we should change our Maintainers.txt process as
> needed. I think I mentioned the idea of co-maintainers. These would be
> contributors that can review and recommend patches for an area of the
> tree. They wouldn't have commit access, but if they give a Reviewed-by
> for the area that they co-maintain, then any committer can proceed to
> commit the change. They might also prep branches of reviewed patches
> for committers to more easily fetch and push.
> 
> It almost seems like we need 'architecture' maintainers as well. Maybe
> 1 person per CPU architecture that can review and commit things
> anywhere in the tree that clearly affects only that architecture.
> 
> Laszlo is also concerned about the hassle of making changes to all the
> OVMF platforms at once.
> 
> For example, I think Laszlo cited the BDS update. Once again, it is a
> reasonable concern, but with today's separation into distinct areas of
> the tree, we are just 'forking' the code in several places. I think we
> can also do similar 'forking' under the OVMF area of the tree as
> needed.
> 
> At the same time, I like the idea of trying to force all the platforms
> to use common modules and to adopt new things together. Ideally it'd
> get all the platforms moved forward faster together. I think Laszlo
> might argue (convincingly) that it could also slow down changes to all
> the virt platforms by forcing all the pieces to be moved in
> lock-step...

I don't want to hold back progress, so if you guys can work out a
reasonably careful methodology / tree structure for this, with a more
finely grained Maintainers.txt, I'll be fine. (I hope :))

Leif recommended "efi-virt" elsewhere, as an arch-less / catch-all name.
I think I prefer it a bit over ovmf-*: in case ovmf- is
mentioned, the idea is clear, but if you just want to say "guest UEFI",
without mentioning the guest arch, "ovmf" would be a bit misleading, due
to OVMF's historical correspondence to x86.

Anyway naming is always a controversial topic :) so I won't push hard
for any of the options.

Thanks
Laszlo

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

[edk2] [PATCH v3] MdeModulePkg/MemoryStatusCode: Expose the DXE memory status code table.

2016-06-28 Thread Cinnamon Shia

Let data of DXE memory status code can be used by other modules.
1. Save the address of DXE memory status code table to DxeConfigurationTable.
2. Save the address of SMM memory status code table to SmmConfigurationTable.
3. Move RUNTIME_MEMORY_STATUSCODE_HEADER to its public header file.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cinnamon Shia 
---
 MdeModulePkg/Include/Guid/MemoryStatusCodeRecord.h | 30 ++
 .../RuntimeDxe/MemoryStatusCodeWorker.c| 27 +++
 .../RuntimeDxe/StatusCodeHandlerRuntimeDxe.h   | 17 
 .../RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf |  5 +++-
 .../StatusCodeHandler/Smm/MemoryStatusCodeWorker.c | 21 ++-
 .../StatusCodeHandler/Smm/StatusCodeHandlerSmm.h   | 18 -
 .../StatusCodeHandler/Smm/StatusCodeHandlerSmm.inf |  4 ++-
 7 files changed, 73 insertions(+), 49 deletions(-)

diff --git a/MdeModulePkg/Include/Guid/MemoryStatusCodeRecord.h 
b/MdeModulePkg/Include/Guid/MemoryStatusCodeRecord.h
index d6c3243..27d39e1 100644
--- a/MdeModulePkg/Include/Guid/MemoryStatusCodeRecord.h
+++ b/MdeModulePkg/Include/Guid/MemoryStatusCodeRecord.h
@@ -2,13 +2,14 @@
   GUID used to identify status code records HOB that originate from the PEI 
status code.
   
 Copyright (c) 2006 - 2010, Intel Corporation. All rights reserved.
-This program and the accompanying materials are licensed and made available 
under 
-the terms and conditions of the BSD License that accompanies this 
distribution.  
+(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
-http://opensource.org/licenses/bsd-license.php.

+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.  
   
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 
 **/
 
@@ -56,6 +57,25 @@ typedef struct {
 } MEMORY_STATUSCODE_PACKET_HEADER;
 
 ///
+/// A header structure that is followed by an array of records that contain 
the 
+/// parameters passed into the ReportStatusCode() service in the DXE Services 
Table.
+///
+typedef struct {
+  ///
+  /// The index pointing to the last recored being stored.
+  ///
+  UINT32   RecordIndex;
+  ///
+  /// The number of records being stored.
+  ///
+  UINT32   NumberOfRecords;
+  ///
+  /// The maximum number of records that can be stored.
+  ///
+  UINT32   MaxRecordsNumber;
+} RUNTIME_MEMORY_STATUSCODE_HEADER;
+
+///
 /// A structure that contains the parameters passed into the 
ReportStatusCode() 
 /// service in the PEI Services Table.
 ///
diff --git 
a/MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/MemoryStatusCodeWorker.c 
b/MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/MemoryStatusCodeWorker.c
index 8680497..a306d75 100644
--- 
a/MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/MemoryStatusCodeWorker.c
+++ 
b/MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/MemoryStatusCodeWorker.c
@@ -2,13 +2,14 @@
   Runtime memory status code worker.
 
   Copyright (c) 2006 - 2009, Intel Corporation. All rights reserved.
-  This program and the accompanying materials  
-  are licensed and made available under the terms and conditions of the BSD 
License 
-  which accompanies this distribution.  The full text of the license may be 
found at
-  http://opensource.org/licenses/bsd-license.php   
 
-   
 
-  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
 
-  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED. 
+  (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
+  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.
 
 **/
 
@@ -18,8 +19,9 @@ RUNTIME_MEMORY_STATUSCODE_HEADER  *mRtMemoryStatusCodeTable;
 
 /**
   Initialize runtime memory status code table as initialization for runtime 
memory status code worker
- 
+
   @retval EFI_SUCCESS  Runtime memory status code table successfully 
initialized.
+  @retval others

Re: [edk2] [Patch] NetworkPkg: Stop the HTTP Boot service after the boot image download complete.

2016-06-28 Thread Ye, Ting

Reviewed-by: Ye Ting  

-Original Message-
From: Fu, Siyuan 
Sent: Tuesday, June 28, 2016 4:32 PM
To: edk2-devel@lists.01.org
Cc: Ye, Ting ; Wu, Jiaxin 
Subject: [Patch] NetworkPkg: Stop the HTTP Boot service after the boot image 
download complete.

After boot image has been downloaded, the HTTP boot driver leaves the service 
in the started state, with an active TCP child. This may cause some problems:
1. The HTTP session may become unavaiable after a while, then a following HTTP 
Boot will fail.
2. An active TCP child will send RST to any incoming TCP message, which may 
break other driver which tries to setup a TCP connection.
The HTTP boot driver doesn't provide any interface to the boot loader, so it's 
unnecessary to keep the service running after a boot image is downloaded.

Cc: Ye Ting 
Cc: Wu Jiaxin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan 
---
 NetworkPkg/HttpBootDxe/HttpBootImpl.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/NetworkPkg/HttpBootDxe/HttpBootImpl.c 
b/NetworkPkg/HttpBootDxe/HttpBootImpl.c
index 4b850b6..babd3e6 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootImpl.c
+++ b/NetworkPkg/HttpBootDxe/HttpBootImpl.c
@@ -505,7 +505,11 @@ HttpBootDxeLoadFile (
   Status = EFI_WARN_FILE_SYSTEM;
 }
   }
-  
+
+  //
+  // Stop the HTTP Boot service after the boot image is downloaded.
+  //
+  HttpBootStop (Private);
   return Status;
 }

--
2.7.4.windows.1

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

[edk2] PCI network performance issue

2016-06-28 Thread Shaveta Leekha

Hi,



I have PCI 3.0 controller driver written, which is platform specific and is 
integrated with MdeModule/Bus/Pci/PciBusDxe code.

On top of it is the E1000 Intel NIC card driver integrated with 
"MdeModulePkg/Universal/Network/".

The whole network stack is working fine functionally.



But tftp is extremely slow.

It is taking around 9-10mins to transfer a file (of size 32 MB approx.) over 
PCI NIC card.

Does it take this much time usually in EDK2 ?



How to optimize it to get good network performance?

Any pointers what all can be a bottlenecks in this stack.



Thanks and Regards,

Shaveta



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

Re: [edk2] [Patch] NetworkPkg: Stop the HTTP Boot service after the boot image download complete.

2016-06-28 Thread Wu, Jiaxin

Looks good to me!

Reviewed-By: Wu Jiaxin 

Best Regards!
Jiaxin

> -Original Message-
> From: Fu, Siyuan
> Sent: Tuesday, June 28, 2016 4:32 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Wu, Jiaxin 
> Subject: [Patch] NetworkPkg: Stop the HTTP Boot service after the boot
> image download complete.
> 
> After boot image has been downloaded, the HTTP boot driver leaves the
> service in the started state, with an active TCP child. This may cause some
> problems:
> 1. The HTTP session may become unavaiable after a while, then a following
> HTTP Boot will fail.
> 2. An active TCP child will send RST to any incoming TCP message, which may
> break other driver which tries to setup a TCP connection.
> The HTTP boot driver doesn't provide any interface to the boot loader, so it's
> unnecessary to keep the service running after a boot image is downloaded.
> 
> Cc: Ye Ting 
> Cc: Wu Jiaxin 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Fu Siyuan 
> ---
>  NetworkPkg/HttpBootDxe/HttpBootImpl.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/NetworkPkg/HttpBootDxe/HttpBootImpl.c
> b/NetworkPkg/HttpBootDxe/HttpBootImpl.c
> index 4b850b6..babd3e6 100644
> --- a/NetworkPkg/HttpBootDxe/HttpBootImpl.c
> +++ b/NetworkPkg/HttpBootDxe/HttpBootImpl.c
> @@ -505,7 +505,11 @@ HttpBootDxeLoadFile (
>Status = EFI_WARN_FILE_SYSTEM;
>  }
>}
> -
> +
> +  //
> +  // Stop the HTTP Boot service after the boot image is downloaded.
> +  //
> +  HttpBootStop (Private);
>return Status;
>  }
> 
> --
> 2.7.4.windows.1

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

[edk2] [Patch] NetworkPkg: Stop the HTTP Boot service after the boot image download complete.

2016-06-28 Thread Fu Siyuan

After boot image has been downloaded, the HTTP boot driver leaves the service
in the started state, with an active TCP child. This may cause some problems:
1. The HTTP session may become unavaiable after a while, then a following HTTP
Boot will fail.
2. An active TCP child will send RST to any incoming TCP message, which may
break other driver which tries to setup a TCP connection.
The HTTP boot driver doesn't provide any interface to the boot loader, so it's
unnecessary to keep the service running after a boot image is downloaded.

Cc: Ye Ting 
Cc: Wu Jiaxin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan 
---
 NetworkPkg/HttpBootDxe/HttpBootImpl.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/NetworkPkg/HttpBootDxe/HttpBootImpl.c 
b/NetworkPkg/HttpBootDxe/HttpBootImpl.c
index 4b850b6..babd3e6 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootImpl.c
+++ b/NetworkPkg/HttpBootDxe/HttpBootImpl.c
@@ -505,7 +505,11 @@ HttpBootDxeLoadFile (
   Status = EFI_WARN_FILE_SYSTEM;
 }
   }
-  
+
+  //
+  // Stop the HTTP Boot service after the boot image is downloaded.
+  //
+  HttpBootStop (Private);
   return Status;
 }
 
-- 
2.7.4.windows.1

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

Re: [edk2] [PATCH v2] MdeModulePkg/MemoryStatusCode: Expose the DXE memory status code table.

2016-06-28 Thread Shia, Cinnamon

Hi Liming,

Thanks for your feedback. Will fix it in v3.

Thanks,
Cinnamon Shia

-Original Message-
From: Gao, Liming [mailto:liming@intel.com] 
Sent: Tuesday, June 28, 2016 1:16 PM
To: Shia, Cinnamon ; edk2-devel@lists.01.org
Cc: Tian, Feng ; Zeng, Star 
Subject: RE: [PATCH v2] MdeModulePkg/MemoryStatusCode: Expose the DXE memory 
status code table.

Cinnamon:
  I have two minor comments on usage. Install System table means PRODUCES. 
  Others are good to me.  Reviewed-by: Liming Gao 

1. StatusCodeHandlerRuntimeDxe.inf
   gMemoryStatusCodeRecordGuid   ## SOMETIMES_CONSUMES   ## HOB 
and ConfigurationTable
==> 
   ## SOMETIMES_CONSUMES   ## HOB
   ## PRODUCES ## SystemTable   
gMemoryStatusCodeRecordGuid

2. StatusCodeHandlerSmm.inf
gMemoryStatusCodeRecordGuid   ## SOMETIMES_CONSUMES   ## 
SmmConfigurationTable
==>
gMemoryStatusCodeRecordGuid   ## PRODUCES   ## UNDEFINED  # 
SmmConfigurationTable

Thanks
Liming
> -Original Message-
> From: Cinnamon Shia [mailto:cinnamon.s...@hpe.com]
> Sent: Monday, June 27, 2016 3:26 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming ; Tian, Feng 
> ; Zeng, Star ; Cinnamon Shia 
> 
> Subject: [PATCH v2] MdeModulePkg/MemoryStatusCode: Expose the DXE 
> memory status code table.
> 
> Let data of DXE memory status code can be used by other modules.
> 1. Save the address of DXE memory status code table to 
> DxeConfigurationTable.
> 2. Save the address of SMM memory status code table to 
> SmmConfigurationTable.
> 3. Move RUNTIME_MEMORY_STATUSCODE_HEADER to its public header file.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Cinnamon Shia 
> ---
>  MdeModulePkg/Include/Guid/MemoryStatusCodeRecord.h | 30
> ++
>  .../RuntimeDxe/MemoryStatusCodeWorker.c| 27 +++---
> -
>  .../RuntimeDxe/StatusCodeHandlerRuntimeDxe.h   | 17 
>  .../RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf |  3 ++-
>  .../StatusCodeHandler/Smm/MemoryStatusCodeWorker.c | 21
> ++-
>  .../StatusCodeHandler/Smm/StatusCodeHandlerSmm.h   | 18 -
>  .../StatusCodeHandler/Smm/StatusCodeHandlerSmm.inf |  4 ++-
>  7 files changed, 71 insertions(+), 49 deletions(-)
> 
> diff --git a/MdeModulePkg/Include/Guid/MemoryStatusCodeRecord.h
> b/MdeModulePkg/Include/Guid/MemoryStatusCodeRecord.h
> index d6c3243..27d39e1 100644
> --- a/MdeModulePkg/Include/Guid/MemoryStatusCodeRecord.h
> +++ b/MdeModulePkg/Include/Guid/MemoryStatusCodeRecord.h
> @@ -2,13 +2,14 @@
>GUID used to identify status code records HOB that originate from 
> the PEI status code.
> 
>  Copyright (c) 2006 - 2010, Intel Corporation. All rights 
> reserved. -This program and the accompanying materials are 
> licensed and made available under -the terms and conditions of the BSD 
> License that accompanies this distribution.
> +(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 
> -http://opensource.org/licenses/bsd-license.php.
> +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.
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> 
>  **/
> 
> @@ -56,6 +57,25 @@ typedef struct {
>  } MEMORY_STATUSCODE_PACKET_HEADER;
> 
>  ///
> +/// A header structure that is followed by an array of records that 
> +contain
> the
> +/// parameters passed into the ReportStatusCode() service in the DXE
> Services Table.
> +///
> +typedef struct {
> +  ///
> +  /// The index pointing to the last recored being stored.
> +  ///
> +  UINT32   RecordIndex;
> +  ///
> +  /// The number of records being stored.
> +  ///
> +  UINT32   NumberOfRecords;
> +  ///
> +  /// The maximum number of records that can be stored.
> +  ///
> +  UINT32   MaxRecordsNumber;
> +} RUNTIME_MEMORY_STATUSCODE_HEADER;
> +
> +///
>  /// A structure that contains the parameters passed into the
> ReportStatusCode()
>  /// service in the PEI Services Table.
>  ///
> diff --git
> a/MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/MemoryStat
> usCodeWorker.c
> b/MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/MemoryStat
> usCodeWorker.c
> index 8680497..a306d75 100644
> ---
> a/MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/MemoryStat
> usCodeWorker.c
> +++
> b/MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/MemoryStat
>

Re: [edk2] [PATCH] MdeModulePkg VariableInfo: Use fixed buffer for smm comm buffer

2016-06-28 Thread Yao, Jiewen

Reviewed-by: jiewen@intel.com


> -Original Message-
> From: Zeng, Star
> Sent: Tuesday, June 28, 2016 2:12 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen 
> Subject: [PATCH] MdeModulePkg VariableInfo: Use fixed buffer for smm
> comm buffer
> 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Star Zeng 
> ---
>  .../Application/VariableInfo/VariableInfo.c| 68
> +-
>  .../Application/VariableInfo/VariableInfo.inf  |  9 +--
>  2 files changed, 47 insertions(+), 30 deletions(-)
> 
> diff --git a/MdeModulePkg/Application/VariableInfo/VariableInfo.c
> b/MdeModulePkg/Application/VariableInfo/VariableInfo.c
> index 727e1ce105f3..df91c1451c19 100644
> --- a/MdeModulePkg/Application/VariableInfo/VariableInfo.c
> +++ b/MdeModulePkg/Application/VariableInfo/VariableInfo.c
> @@ -3,7 +3,7 @@
>this utility will print out the statistics information. You can use console
>redirection to capture the data.
> 
> -  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
> +  Copyright (c) 2006 - 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
>which accompanies this distribution.  The full text of the license may be
> found at
> @@ -25,6 +25,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF
> ANY KIND, EITHER EXPRESS OR IMPLIED.
> 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> 
> @@ -86,6 +87,11 @@ PrintInfoFromSmm (
>UINTN  CommSize;
>SMM_VARIABLE_COMMUNICATE_HEADER
> *FunctionHeader;
>EFI_SMM_VARIABLE_PROTOCOL
> *Smmvariable;
> +  EDKII_PI_SMM_COMMUNICATION_REGION_TABLE
> *PiSmmCommunicationRegionTable;
> +  UINT32 Index;
> +  EFI_MEMORY_DESCRIPTOR  *Entry;
> +  UINTN  Size;
> +  UINTN  MaxSize;
> 
>Status = gBS->LocateProtocol (, NULL,
> (VOID **) );
>if (EFI_ERROR (Status)) {
> @@ -97,30 +103,47 @@ PrintInfoFromSmm (
>  return Status;
>}
> 
> -  CommSize = SMM_COMMUNICATE_HEADER_SIZE +
> SMM_VARIABLE_COMMUNICATE_HEADER_SIZE;
> -  RealCommSize = CommSize;
> -  CommBuffer = AllocateZeroPool (CommSize);
> +  CommBuffer = NULL;
> +  Status = EfiGetSystemConfigurationTable (
> + ,
> + (VOID **) 
> + );
> +  if (EFI_ERROR (Status)) {
> +return Status;
> +  }
> +  ASSERT (PiSmmCommunicationRegionTable != NULL);
> +  Entry = (EFI_MEMORY_DESCRIPTOR *)
> (PiSmmCommunicationRegionTable + 1);
> +  Size = 0;
> +  MaxSize = 0;
> +  for (Index = 0; Index <
> PiSmmCommunicationRegionTable->NumberOfEntries; Index++) {
> +if (Entry->Type == EfiConventionalMemory) {
> +  Size = EFI_PAGES_TO_SIZE ((UINTN) Entry->NumberOfPages);
> +  if (Size > (SMM_COMMUNICATE_HEADER_SIZE +
> SMM_VARIABLE_COMMUNICATE_HEADER_SIZE + sizeof
> (VARIABLE_INFO_ENTRY))) {
> +if (Size > MaxSize) {
> +  MaxSize = Size;
> +  RealCommSize = MaxSize;
> +  CommBuffer = (EFI_SMM_COMMUNICATE_HEADER *) (UINTN)
> Entry->PhysicalStart;
> +}
> +  }
> +}
> +Entry = (EFI_MEMORY_DESCRIPTOR *) ((UINT8 *) Entry +
> PiSmmCommunicationRegionTable->DescriptorSize);
> +  }
>ASSERT (CommBuffer != NULL);
> +  ZeroMem (CommBuffer, RealCommSize);
> 
>Print (L"Non-Volatile SMM Variables:\n");
>do {
> +CommSize = RealCommSize;
>  Status = GetVariableStatisticsData (CommBuffer, );
>  if (Status == EFI_BUFFER_TOO_SMALL) {
> -  FreePool (CommBuffer);
> -  CommBuffer = AllocateZeroPool (CommSize);
> -  ASSERT (CommBuffer != NULL);
> -  RealCommSize = CommSize;
> -  Status = GetVariableStatisticsData (CommBuffer, );
> +  Print (L"The generic SMM communication buffer provided by
> SmmCommunicationRegionTable is too small\n");
> +  return Status;
>  }
> 
>  if (EFI_ERROR (Status) || (CommSize <=
> SMM_COMMUNICATE_HEADER_SIZE +
> SMM_VARIABLE_COMMUNICATE_HEADER_SIZE)) {
>break;
>  }
> 
> -if (CommSize < RealCommSize) {
> -  CommSize = RealCommSize;
> -}
> -
>  FunctionHeader = (SMM_VARIABLE_COMMUNICATE_HEADER *)
> CommBuffer->Data;
>  VariableInfo   = (VARIABLE_INFO_ENTRY *) FunctionHeader->Data;
> 
> @@ -138,25 +161,19 @@ PrintInfoFromSmm (
>} while (TRUE);
> 
>Print (L"Volatile SMM Variables:\n");
> -  ZeroMem (CommBuffer, CommSize);
> +  ZeroMem (CommBuffer, RealCommSize);
>do {
> +CommSize = RealCommSize;
>  Status = GetVariableStatisticsData (CommBuffer, );
>  if (Status == EFI_BUFFER_TOO_SMALL) {
> -  FreePool (CommBuffer);
> -  CommBuffer = AllocateZeroPool (CommSize);
> -  ASSERT (CommBuffer != NULL);
> -  RealCommSize =

Re: [edk2] [PATCH] MdeModulePkg DxeSmmPerformanceLib: Add missing UefiLib in *.inf at de2459d

2016-06-28 Thread Yao, Jiewen

Reviewed-by: jiewen@intel.com

> -Original Message-
> From: Zeng, Star
> Sent: Tuesday, June 28, 2016 2:11 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Gao, Liming
> 
> Subject: [PATCH] MdeModulePkg DxeSmmPerformanceLib: Add missing
> UefiLib in *.inf at de2459d
> 
> Cc: Jiewen Yao 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Star Zeng 
> ---
> 
> MdeModulePkg/Library/DxeSmmPerformanceLib/DxeSmmPerformanceLib.i
> nf | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git
> a/MdeModulePkg/Library/DxeSmmPerformanceLib/DxeSmmPerformanceLi
> b.inf
> b/MdeModulePkg/Library/DxeSmmPerformanceLib/DxeSmmPerformanceLi
> b.inf
> index 2dbaa7c2973b..2b057704f878 100644
> ---
> a/MdeModulePkg/Library/DxeSmmPerformanceLib/DxeSmmPerformanceLi
> b.inf
> +++
> b/MdeModulePkg/Library/DxeSmmPerformanceLib/DxeSmmPerformanceLi
> b.inf
> @@ -48,6 +48,7 @@ [LibraryClasses]
>BaseMemoryLib
>UefiRuntimeServicesTableLib
>MemoryAllocationLib
> +  UefiLib
> 
>  [Guids]
>gPerformanceProtocolGuid  ## SOMETIMES_CONSUMES
> ## UNDEFINED # Locate protocol
> --
> 2.7.0.windows.1

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

Re: [edk2] [RFC V3.1] Proposal to organize packages into directories

2016-06-28 Thread Jordan Justen

On 2016-06-26 08:44:04, Leif Lindholm wrote:
> 
> On Fri, Jun 17, 2016 at 10:51:47PM +, Kinney, Michael D wrote:
> > Common
> >   CorebootPayloadPkg
> >   DuetPkg
> >   EmulatorPkg
> >   Nt32Pkg
> >   OvmfPkg
> 
> So, I would like to propose a semi-tedious change here:
> Merging the ArmVirtPkg and OvmfPkg directories.
> ArmVirtPkg already uses many components maintained in OvmfPkg, and
> ArmVirtPkg packages fulfills _exactly_ the same function, only for a
> different architecture. We've seen a fair bit of confusion around the
> separation of these two, both from Linux distribution packagers and
> developers of virtualization tools and frameworks.
> 
> My proposal is not for a heavy-handed merge of the source code, but
> simply for moving all of the sources and platform configuration files
> into the same package, adding the ARM targets to build.sh, and so on.
> 

I agree. While I'm not certain about it, I think we can reasonably
manage having all virt related platforms under a single OVMF area.

I would rather think of these platforms similar to qemu ... ovmf-ia32,
ovmf-x64, ovmf-arm, ovmf-riscv, etc... In the case of QEMU, I think we
should have a goal to support the intersection of UEFI architectures,
and systems supported by QEMU.

Similarly, I'd also like to try to continue to support qemu/kvm and
Xen in the same platform area as long as it is possible. I wouldn't
want to rule out trying to support other VMMs as well if they can mold
reasonably into the current OVMF modules.

Laszlo has two (reasonable) concerns. First, how to assign owners?
Today we only have 1 or 2 people per package. That doesn't work well
if we have 5 CPU architectures in a single OVMF area of the tree.

My thought is that we should change our Maintainers.txt process as
needed. I think I mentioned the idea of co-maintainers. These would be
contributors that can review and recommend patches for an area of the
tree. They wouldn't have commit access, but if they give a Reviewed-by
for the area that they co-maintain, then any committer can proceed to
commit the change. They might also prep branches of reviewed patches
for committers to more easily fetch and push.

It almost seems like we need 'architecture' maintainers as well. Maybe
1 person per CPU architecture that can review and commit things
anywhere in the tree that clearly affects only that architecture.

Laszlo is also concerned about the hassle of making changes to all the
OVMF platforms at once.

For example, I think Laszlo cited the BDS update. Once again, it is a
reasonable concern, but with today's separation into distinct areas of
the tree, we are just 'forking' the code in several places. I think we
can also do similar 'forking' under the OVMF area of the tree as
needed.

At the same time, I like the idea of trying to force all the platforms
to use common modules and to adopt new things together. Ideally it'd
get all the platforms moved forward faster together. I think Laszlo
might argue (convincingly) that it could also slow down changes to all
the virt platforms by forcing all the pieces to be moved in
lock-step...

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

[edk2] [PATCH] MdeModulePkg VariableInfo: Use fixed buffer for smm comm buffer

2016-06-28 Thread Star Zeng

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 .../Application/VariableInfo/VariableInfo.c| 68 +-
 .../Application/VariableInfo/VariableInfo.inf  |  9 +--
 2 files changed, 47 insertions(+), 30 deletions(-)

diff --git a/MdeModulePkg/Application/VariableInfo/VariableInfo.c 
b/MdeModulePkg/Application/VariableInfo/VariableInfo.c
index 727e1ce105f3..df91c1451c19 100644
--- a/MdeModulePkg/Application/VariableInfo/VariableInfo.c
+++ b/MdeModulePkg/Application/VariableInfo/VariableInfo.c
@@ -3,7 +3,7 @@
   this utility will print out the statistics information. You can use console
   redirection to capture the data.
 
-  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2006 - 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
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -25,6 +25,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -86,6 +87,11 @@ PrintInfoFromSmm (
   UINTN  CommSize;
   SMM_VARIABLE_COMMUNICATE_HEADER*FunctionHeader;
   EFI_SMM_VARIABLE_PROTOCOL  *Smmvariable;
+  EDKII_PI_SMM_COMMUNICATION_REGION_TABLE
*PiSmmCommunicationRegionTable;
+  UINT32 Index;
+  EFI_MEMORY_DESCRIPTOR  *Entry;
+  UINTN  Size;
+  UINTN  MaxSize;
 
   Status = gBS->LocateProtocol (, NULL, (VOID **) 
);
   if (EFI_ERROR (Status)) {
@@ -97,30 +103,47 @@ PrintInfoFromSmm (
 return Status;
   }
 
-  CommSize = SMM_COMMUNICATE_HEADER_SIZE + 
SMM_VARIABLE_COMMUNICATE_HEADER_SIZE;
-  RealCommSize = CommSize;
-  CommBuffer = AllocateZeroPool (CommSize);
+  CommBuffer = NULL;
+  Status = EfiGetSystemConfigurationTable (
+ ,
+ (VOID **) 
+ );
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+  ASSERT (PiSmmCommunicationRegionTable != NULL);
+  Entry = (EFI_MEMORY_DESCRIPTOR *) (PiSmmCommunicationRegionTable + 1);
+  Size = 0;
+  MaxSize = 0;
+  for (Index = 0; Index < PiSmmCommunicationRegionTable->NumberOfEntries; 
Index++) {
+if (Entry->Type == EfiConventionalMemory) {
+  Size = EFI_PAGES_TO_SIZE ((UINTN) Entry->NumberOfPages);
+  if (Size > (SMM_COMMUNICATE_HEADER_SIZE + 
SMM_VARIABLE_COMMUNICATE_HEADER_SIZE + sizeof (VARIABLE_INFO_ENTRY))) {
+if (Size > MaxSize) {
+  MaxSize = Size;
+  RealCommSize = MaxSize;
+  CommBuffer = (EFI_SMM_COMMUNICATE_HEADER *) (UINTN) 
Entry->PhysicalStart;
+}
+  }
+}
+Entry = (EFI_MEMORY_DESCRIPTOR *) ((UINT8 *) Entry + 
PiSmmCommunicationRegionTable->DescriptorSize);
+  }
   ASSERT (CommBuffer != NULL);
+  ZeroMem (CommBuffer, RealCommSize);
 
   Print (L"Non-Volatile SMM Variables:\n");
   do {
+CommSize = RealCommSize;
 Status = GetVariableStatisticsData (CommBuffer, );
 if (Status == EFI_BUFFER_TOO_SMALL) {
-  FreePool (CommBuffer);
-  CommBuffer = AllocateZeroPool (CommSize);
-  ASSERT (CommBuffer != NULL);
-  RealCommSize = CommSize;
-  Status = GetVariableStatisticsData (CommBuffer, );
+  Print (L"The generic SMM communication buffer provided by 
SmmCommunicationRegionTable is too small\n");
+  return Status;
 }
 
 if (EFI_ERROR (Status) || (CommSize <= SMM_COMMUNICATE_HEADER_SIZE + 
SMM_VARIABLE_COMMUNICATE_HEADER_SIZE)) {
   break;
 }
 
-if (CommSize < RealCommSize) {
-  CommSize = RealCommSize;
-}
-
 FunctionHeader = (SMM_VARIABLE_COMMUNICATE_HEADER *) CommBuffer->Data;
 VariableInfo   = (VARIABLE_INFO_ENTRY *) FunctionHeader->Data;
 
@@ -138,25 +161,19 @@ PrintInfoFromSmm (
   } while (TRUE);
 
   Print (L"Volatile SMM Variables:\n");
-  ZeroMem (CommBuffer, CommSize);
+  ZeroMem (CommBuffer, RealCommSize);
   do {
+CommSize = RealCommSize;
 Status = GetVariableStatisticsData (CommBuffer, );
 if (Status == EFI_BUFFER_TOO_SMALL) {
-  FreePool (CommBuffer);
-  CommBuffer = AllocateZeroPool (CommSize);
-  ASSERT (CommBuffer != NULL);
-  RealCommSize = CommSize;
-  Status = GetVariableStatisticsData (CommBuffer, );
+  Print (L"The generic SMM communication buffer provided by 
SmmCommunicationRegionTable is too small\n");
+  return Status;
 }
 
 if (EFI_ERROR (Status) || (CommSize <= SMM_COMMUNICATE_HEADER_SIZE + 
SMM_VARIABLE_COMMUNICATE_HEADER_SIZE)) {
   break;
 }
 
-if (CommSize < RealCommSize) {
-  CommSize = RealCommSize;
-}
-
 FunctionHeader = (SMM_VARIABLE_COMMUNICATE_HEADER *)

[edk2] [PATCH] MdeModulePkg DxeSmmPerformanceLib: Add missing UefiLib in *.inf at de2459d

2016-06-28 Thread Star Zeng

Cc: Jiewen Yao 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Library/DxeSmmPerformanceLib/DxeSmmPerformanceLib.inf | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MdeModulePkg/Library/DxeSmmPerformanceLib/DxeSmmPerformanceLib.inf 
b/MdeModulePkg/Library/DxeSmmPerformanceLib/DxeSmmPerformanceLib.inf
index 2dbaa7c2973b..2b057704f878 100644
--- a/MdeModulePkg/Library/DxeSmmPerformanceLib/DxeSmmPerformanceLib.inf
+++ b/MdeModulePkg/Library/DxeSmmPerformanceLib/DxeSmmPerformanceLib.inf
@@ -48,6 +48,7 @@ [LibraryClasses]
   BaseMemoryLib
   UefiRuntimeServicesTableLib
   MemoryAllocationLib
+  UefiLib
 
 [Guids]
   gPerformanceProtocolGuid  ## SOMETIMES_CONSUMES   ## UNDEFINED # 
Locate protocol
-- 
2.7.0.windows.1

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

71 matches

Mail list logo