Re: [edk2] [patch] SecurityPkg: Fixed build error due to FixedAtBuild PcdTcg2HashAlgorithmBitmap

2015-08-17 Thread Yao, Jiewen
Reviewed-by: Yao, Jiewen jiewen@intel.com

At same time, I suggest we move PcdTpm2HashMask to Dynamic section too, because 
now Tcg2Pei will set this PCD according to TPM2 device capability.

If you agree, I will check in both.

Thank you
Yao Jiewen


-Original Message-
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com] 
Sent: Tuesday, August 18, 2015 12:29 PM
To: Yao, Jiewen; edk2-devel@lists.01.org
Cc: Zhang, Chao B; El-Haj-Mahmoud, Samer
Subject: RE: [edk2] [patch] SecurityPkg: Fixed build error due to FixedAtBuild 
PcdTcg2HashAlgorithmBitmap

Please see attached patch file. Can you help review it and check it in please?

Thanks,
--Samer




-Original Message-
From: Yao, Jiewen [mailto:jiewen@intel.com] 
Sent: Saturday, August 15, 2015 1:10 AM
To: El-Haj-Mahmoud, Samer samer.el-haj-mahm...@hp.com; edk2-devel@lists.01.org
Cc: Zhang, Chao B chao.b.zh...@intel.com; Yao, Jiewen jiewen@intel.com
Subject: RE: [edk2] [patch] SecurityPkg: Fixed build error due to FixedAtBuild 
PcdTcg2HashAlgorithmBitmap

Sounds good to me.

Thank you
Yao Jiewen

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
El-Haj-Mahmoud, Samer
Sent: Saturday, August 15, 2015 8:55 AM
To: edk2-devel@lists.01.org
Cc: El-Haj-Mahmoud, Samer; Zhang, Chao B
Subject: [edk2] [patch] SecurityPkg: Fixed build error due to FixedAtBuild 
PcdTcg2HashAlgorithmBitmap

PcdTcg2HashAlgorithmBitmap is declared in a section that allows it to be Fixed 
or PatchableAtBuild, but there is code that sets it. This breaks the build on 
some platforms. Changed it to be PcdsDynamic and PcdsDynamicEx only.

Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Samer El-Haj-Mahmoud samer.el-haj-mahm...@hp.com





Samer El-Haj-Mahmoud
System Firmware Architect
HP Servers 

el...@hp.com 
T +1.281.514.5973
C +1.512.659.1523
Hewlett-Packard Company
hp.com/go/proliant/uefi



___
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:Full support F10 hot key in UiApp.

2015-08-17 Thread Dandan Bi
In current UiApp/Boot Maintenance manager,some pages don't support F10,
they use Commit Changes and Exit menu to save changes.Now support F10
in these pages.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi dandan...@intel.com
---
 .../Application/UiApp/BootMaint/Bmstring.uni   | Bin 41522 - 42370 bytes
 .../Application/UiApp/BootMaint/BootMaint.c| 415 +
 .../Application/UiApp/BootMaint/BootMaint.h| 123 +-
 .../Application/UiApp/BootMaint/ConsoleOption.c| 147 
 MdeModulePkg/Application/UiApp/BootMaint/Data.c|  13 +
 MdeModulePkg/Application/UiApp/BootMaint/FE.vfr|  24 +-
 .../Application/UiApp/BootMaint/FileExplorer.c | 187 --
 .../Application/UiApp/BootMaint/FormGuid.h |  32 +-
 .../Application/UiApp/BootMaint/UpdatePage.c   | 188 ++
 .../Application/UiApp/BootMaint/Variable.c |  26 +-
 10 files changed, 768 insertions(+), 387 deletions(-)

diff --git a/MdeModulePkg/Application/UiApp/BootMaint/Bmstring.uni 
b/MdeModulePkg/Application/UiApp/BootMaint/Bmstring.uni
index 
8d9544db450322835972597234a07d76207e1102..f64837b7735f247eb0704c7d21d6639e4eac181b
 100644
GIT binary patch
delta 272
zcmdmVgsJH?(}o2p;%*E+4E_w^4Dk%kK-!NXgdqq`%F$`6Q4YRO=WU|0|XKBo3gu
z9EN;`as~yUx_pK_h7yJ%Ae}S$p;;qd`M_Mu$y3~CI=*$O`ek~u~{m$%Vsi%k%XoP
zgCo!?7ogQ3+7;*koKE30n@k1X`E^bO4Z^ESQ=-c}8eKZ+rg2*`Wm!MGW(CG+
WPCmdTFuAOu0AvD?=9|1^VIKf3g+yrp

delta 18
acmZoV9vzV(}o2pn;)dI*iQbkqz?dBZV7Gx

diff --git a/MdeModulePkg/Application/UiApp/BootMaint/BootMaint.c 
b/MdeModulePkg/Application/UiApp/BootMaint/BootMaint.c
index 0a6eb6c..fdcdf2d 100644
--- a/MdeModulePkg/Application/UiApp/BootMaint/BootMaint.c
+++ b/MdeModulePkg/Application/UiApp/BootMaint/BootMaint.c
@@ -294,13 +294,16 @@ BootMaintRouteConfig (
   EFI_STATUS  Status;
   UINTN   BufferSize;
   EFI_HII_CONFIG_ROUTING_PROTOCOL *ConfigRouting;
   BMM_FAKE_NV_DATA*NewBmmData;
   BMM_FAKE_NV_DATA*OldBmmData;
+  BM_CONSOLE_CONTEXT  *NewConsoleContext;
+  BM_TERMINAL_CONTEXT *NewTerminalContext;
   BM_MENU_ENTRY   *NewMenuEntry;
   BM_LOAD_CONTEXT *NewLoadContext;
-  UINT16  Index;  
+  UINT16  Index;
+  BOOLEAN TerminalAttChange;
   BMM_CALLBACK_DATA   *Private; 
 
   if (Progress == NULL) {
 return EFI_INVALID_PARAMETER;
   }
@@ -366,18 +369,32 @@ BootMaintRouteConfig (
  Index ++) {
   NewMenuEntry= BOpt_GetMenuEntry (BootOptionMenu, Index);
   NewLoadContext  = (BM_LOAD_CONTEXT *) 
NewMenuEntry-VariableContext;
   NewLoadContext-Deleted = NewBmmData-BootOptionDel[Index];
   NewBmmData-BootOptionDel[Index] = FALSE;
+  NewBmmData-BootOptionDelMark[Index] = FALSE;
 }
 
 Var_DelBootOption ();
   }
   
   if (CompareMem (NewBmmData-BootOptionOrder, OldBmmData-BootOptionOrder, 
sizeof (NewBmmData-BootOptionOrder)) != 0) {  
 Status = Var_UpdateBootOrder (Private);
-  } 
+  }
+
+  if (CompareMem (NewBmmData-BootTimeOut, OldBmmData-BootTimeOut, sizeof 
(NewBmmData-BootTimeOut)) != 0){
+Status = gRT-SetVariable(
+LTimeout,
+gEfiGlobalVariableGuid,
+EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
+sizeof(UINT16),
+(NewBmmData-BootTimeOut)
+);
+ASSERT_EFI_ERROR(Status);
+
+Private-BmmOldFakeNVData.BootTimeOut = NewBmmData-BootTimeOut;
+  }
 
   //
   // Check data which located in Driver Options Menu and save the settings if 
need
   //  
   if (CompareMem (NewBmmData-DriverOptionDel, OldBmmData-DriverOptionDel, 
sizeof (NewBmmData-DriverOptionDel)) != 0) {   
@@ -386,17 +403,98 @@ BootMaintRouteConfig (
  Index++) {
   NewMenuEntry= BOpt_GetMenuEntry (DriverOptionMenu, Index);
   NewLoadContext  = (BM_LOAD_CONTEXT *) 
NewMenuEntry-VariableContext;
   NewLoadContext-Deleted = NewBmmData-DriverOptionDel[Index];
   NewBmmData-DriverOptionDel[Index] = FALSE;
+  NewBmmData-DriverOptionDelMark[Index] = FALSE;
 }
 Var_DelDriverOption ();  
   }
   
   if (CompareMem (NewBmmData-DriverOptionOrder, 
OldBmmData-DriverOptionOrder, sizeof (NewBmmData-DriverOptionOrder)) != 0) {  
 Status = Var_UpdateDriverOrder (Private);
-  }  
+  }
+
+  if (CompareMem (NewBmmData-ConsoleOutMode, OldBmmData-ConsoleOutMode, 
sizeof (NewBmmData-ConsoleOutMode)) != 0){
+Var_UpdateConMode(Private);
+  }
+
+  TerminalAttChange = FALSE;
+  for (Index = 0; Index  TerminalMenu.MenuNumber; Index++) {
+
+//
+// only need update modified items
+//
+if (CompareMem (NewBmmData-COMBaudRate[Index], 
OldBmmData-COMBaudRate[Index], sizeof 

Re: [edk2] [PATCH 00/15] Separate variable check service to library

2015-08-17 Thread Ni, Ruiyu
Star,
The NT32Pkg changes are good.

Reviewed-by: Ruiyu Ni ruiyu...@intel.com

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star Zeng
Sent: Monday, August 17, 2015 4:24 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [PATCH 00/15] Separate variable check service to library

NOTICE: To keep git bisect, the update to platform package Nt32Pkg, OvmfPkg, 
EmulatorPkg,
ArmVirtPkg, ArmPlatformPkg and Vlv2TbltDevicePkg has been split to two patches.

For your easy review,
the forked code is at g...@github.com:lzeng14/edk2.git branch 
VariableCheckService.

What to do:
1. Add VarCheckLib library and VarCheckUefiLib NULL class library.
2. Update Variable driver to consume the separated VarCheckLib.
3. Update platform package to add VarCheckLib library mapping
and link separated VarCheckUefiLib NULL class library

Why to do: Share code.
Separate variable check service from Variable driver in MdeModulePkg.
We are going to separate generic software logic code from Variable Driver
to benefit other variable driver implementation. Auth services has been done
to be AuthVariableLib, now to cover variable check service.

What test done:
Nt32 and OVMF: Boot fine same with no code separation.
Internal real platform: Boot fine to OS.

What is the impact to platform: Only platform dsc need to be updated.

Star Zeng (15):
  MdeModulePkg: Add VarCheckLib library
  MdeModulePkg: Add VarCheckUefiLib NULL class library
  Nt32Pkg: Add VarCheckLib library mapping
  OvmfPkg: Add VarCheckLib library mapping
  EmulatorPkg: Add VarCheckLib library mapping
  ArmVirtPkg: Add VarCheckLib library mapping
  ArmPlatformPkg: Add VarCheckLib library mapping
  Vlv2TbltDevicePkg: Add VarCheckLib library mapping
  MdeModulePkg Variable: Consume the separated VarCheckLib
  Nt32Pkg: Link separated VarCheckUefiLib NULL class library instance
  OvmfPkg: Link separated VarCheckUefiLib NULL class library instance
  EmulatorPkg: Link separated VarCheckUefiLib NULL class library
instance
  ArmVirtPkg: Link separated VarCheckUefiLib NULL class library instance
  ArmPlatformPkg: Link separated VarCheckUefiLib NULL class library
instance
  Vlv2TbltDevicePkg: Link separated VarCheckUefiLib NULL class library
instance

 ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc  |5 +-
 .../ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc|5 +-
 .../ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc |5 +-
 .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc |5 +-
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc  |1 +
 ArmVirtPkg/ArmVirt.dsc.inc |1 +
 ArmVirtPkg/ArmVirtQemu.dsc |5 +-
 EmulatorPkg/EmulatorPkg.dsc|6 +-
 MdeModulePkg/Include/Library/VarCheckLib.h |  180 
 MdeModulePkg/Library/VarCheckLib/VarCheckLib.c |  632 +++
 MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf   |   51 +
 MdeModulePkg/Library/VarCheckLib/VarCheckLib.uni   |  Bin 0 - 1798 bytes
 .../Library/VarCheckUefiLib/VarCheckUefiLib.inf|   88 ++
 .../Library/VarCheckUefiLib/VarCheckUefiLib.uni|  Bin 0 - 2158 bytes
 .../VarCheckUefiLib/VarCheckUefiLibNullClass.c |  930 
 MdeModulePkg/MdeModulePkg.dec  |4 +
 MdeModulePkg/MdeModulePkg.dsc  |   13 +-
 .../Universal/Variable/RuntimeDxe/VarCheck.c   | 1117 +---
 .../Universal/Variable/RuntimeDxe/Variable.c   |  193 +---
 .../Universal/Variable/RuntimeDxe/Variable.h   |   97 +-
 .../Universal/Variable/RuntimeDxe/VariableDxe.c|   48 +-
 .../Variable/RuntimeDxe/VariableRuntimeDxe.inf |   15 +-
 .../Universal/Variable/RuntimeDxe/VariableSmm.c|   23 +-
 .../Universal/Variable/RuntimeDxe/VariableSmm.inf  |   15 +-
 Nt32Pkg/Nt32Pkg.dsc|6 +-
 OvmfPkg/OvmfPkgIa32.dsc|6 +-
 OvmfPkg/OvmfPkgIa32X64.dsc |6 +-
 OvmfPkg/OvmfPkgX64.dsc |6 +-
 Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc|2 +
 Vlv2TbltDevicePkg/PlatformPkgIA32.dsc  |2 +
 Vlv2TbltDevicePkg/PlatformPkgX64.dsc   |2 +
 31 files changed, 2045 insertions(+), 1424 deletions(-)
 create mode 100644 MdeModulePkg/Include/Library/VarCheckLib.h
 create mode 100644 MdeModulePkg/Library/VarCheckLib/VarCheckLib.c
 create mode 100644 MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
 create mode 100644 MdeModulePkg/Library/VarCheckLib/VarCheckLib.uni
 create mode 100644 MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
 create mode 100644 MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.uni
 create mode 100644 
MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c

-- 
1.9.5.msysgit.0

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

Re: [edk2] [PATCH 00/15] unify GCC command line options

2015-08-17 Thread Ard Biesheuvel
On 16 August 2015 at 23:48, Scott Duplichan sc...@notabs.org wrote:
 ]Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] wrote:

  . . .

 ] Thanks for this much needed tool chain definition consolidation. I ran
 ] a build test with and without the patch. The build test uses GCC44-49
 ] and Microsoft tool chains. Log files are here: http://notabs.org/uefi/tmp/.
 ]
 ]Thanks a lot for giving it a spin.
 ]
 ] Here is what is see in the log files with respect to the patch:
 ] 1) GCC49 X64 and IA32
 ]GenFw: ERROR 3000: Invalid Unsupported section alignment.
 ]
 ]I cannot reproduce this, unfortunately. Can you please check whether
 ]your BaseTools are up to date? There have been some changes recently
 ]to GenFw regarding section alignment which may cause this. My gcc is
 ]4.9.1 btw (Ubuntu)
 ]
 ]My Jenkins job has a 'git clean -dxf BaseTools/; make -C BaseTools' at
 ]the beginning so they are up to date, although I think that for GenFw,
 ]the git clean is not necessary. (Some other tools don't rebuild
 ]correctly if any of the common C code is modified)

 I used rebuilt BaseTools\Bin\Win32 with up to date source code. The SVN
 GenFw binary gives the same message. Adding some debug prints gives:

 Unsupported section alignment: sh_addr=84a0 addralign=64 mCoffOffset=84c0

 Objdump -h gives:
 d:\edk2build\edk2\Build\OvmfX64\RELEASE_GCC49\X64\MdeModulePkg\Core\
 Pei\PeiMain\DEBUG\PeiCore.dll: file format elf64-x86-64

 Sections:
 Idx Name  Size  VMA   LMA   File off  Algn
   0 .text 8250  0240  0240  00c0  2**5
   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
   1 .data 03b8  84a0  84a0  8320  2**6
   CONTENTS, ALLOC, LOAD, RELOC, DATA


Thanks for the analysis. As it turns out, this only happens in the debug build.

Anyway, as it turns out, GNU ld uses the same optimization that the
comments in ElfConvert[32|64].c allude to, i.e., if a section's
address is not aligned to its alignment, the misalignment should be
preserved. In this example, it means that mPcdInstance [which needs
64-byte alignment] is placed such that it will end up aligned
correctly only if .data is loaded 0x20 bytes into a 0x40 byte aligned
region.

The cause turns out to be the explicit base address for .data. The
following fixes it for me:

diff --git a/BaseTools/Scripts/GccBase.lds b/BaseTools/Scripts/GccBase.lds
index 4ee6d998532c..eef8325c96a5 100644
--- a/BaseTools/Scripts/GccBase.lds
+++ b/BaseTools/Scripts/GccBase.lds
@@ -44,7 +44,8 @@ SECTIONS {
* between these sections is the same in the ELF and the PE/COFF versions of
* this binary.
*/
-  .data ALIGN(ALIGNOF(.text)) : ALIGN(CONSTANT(COMMONPAGESIZE)) {
+  . = ALIGN(ALIGNOF(.text));
+  .data : ALIGN(CONSTANT(COMMONPAGESIZE)) {
 *(.data .data.* .gnu.linkonce.d.*)
 *(.bss .bss.* *COM*)
   }

so I will add this change to v2

 ] 2) GCC46 ARM
 ]unrecognized command line option '-mno-unaligned-access'
 ]
 ]
 ]Could you send me the output of gcc -v for this compiler? Mine is
 ]Linaro 4.6.3 which supports it fine, but the feature may be a Linaro
 ]contribution that only made it into 4.7 upstream. In any case, we
 ]cannot tolerate unaligned accesses so we may need to deprecate 4.6 or
 ]mandate that the Linaro version be used if older versions emit
 ]unaligned accesses.

 The GCC46 is the Windows hosted build from:
 http://sourceforge.net/projects/edk2developertoolsforwindows/

 It is built from the latest gcc 4.6 source code:
 http://ftpmirror.gnu.org/gcc/gcc-4.6.4/gcc-4.6.4.tar.bz2

 Using built-in specs.
 COLLECT_GCC=gcc
 COLLECT_LTO_WRAPPER=d:/edk2build/uefitools/gcc464-arm/bin/../lib/gcc/arm-linux-gnueabi/4.6.4/lto-wrapper.exe
 Target: arm-linux-gnueabi
 Configured with: ../gcc-4.6.4/configure --prefix=/gcc/xgcc 
 --libexecdir=/gcc/xgcc/lib --target=arm-linux-gnueabi --disable-werror 
 --disable-shared --disable-libssp --disable-bootstrap --disable-nls 
 --disable-libquadmath --without-headers --enable-languages=c 
 --with-gmp=/gcc/xgcc --with-mpfr=/gcc/xgcc --with-mpc=/gcc/xgcc 
 --with-libelf=/gcc/xgcc --with-pkgversion='EDK2 version 1.0' MAKEINFO=missing 
 --enable-twoprocess --disable-threads --disable-decimal-float 
 --disable-win32-registry --disable-libc --with-windres
 Thread model: single
 gcc version 4.6.4 (EDK2 version 1.0)

 Source code for gcc-linaro-4.6-2012.04 shows what you suspected:
 ChangeLog.linaro contains: (insv, extzv): Add unaligned-access support.


OK, this sucks.

Linaro dropped the ball on this one IMO. By backporting this issue to
4.6 and enabling it by default, we can no longer have a single 4.6
definition for both compilers, since for the Linaro on we must pass
-mno-unaligned-access and for the stock one we must not pass it.

The best way to fix this is remove 4.6, I think. We could disable the
optimization indirectly by generating code for ARMv5, but I don't
think that is desirable solution at all.

-- 
Ard.

Re: [edk2] [PATCH 00/15] Separate variable check service to library

2015-08-17 Thread Wei, David
The patch for Vlv2TbltDevicePkg is good.  Thanks.


Thanks,
David | SSG BIOS

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star Zeng
Sent: Monday, August 17, 2015 4:24 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [PATCH 00/15] Separate variable check service to library

NOTICE: To keep git bisect, the update to platform package Nt32Pkg, OvmfPkg, 
EmulatorPkg, ArmVirtPkg, ArmPlatformPkg and Vlv2TbltDevicePkg has been split to 
two patches.

For your easy review,
the forked code is at g...@github.com:lzeng14/edk2.git branch 
VariableCheckService.

What to do:
1. Add VarCheckLib library and VarCheckUefiLib NULL class library.
2. Update Variable driver to consume the separated VarCheckLib.
3. Update platform package to add VarCheckLib library mapping and link 
separated VarCheckUefiLib NULL class library

Why to do: Share code.
Separate variable check service from Variable driver in MdeModulePkg.
We are going to separate generic software logic code from Variable Driver to 
benefit other variable driver implementation. Auth services has been done to be 
AuthVariableLib, now to cover variable check service.

What test done:
Nt32 and OVMF: Boot fine same with no code separation.
Internal real platform: Boot fine to OS.

What is the impact to platform: Only platform dsc need to be updated.

Star Zeng (15):
  MdeModulePkg: Add VarCheckLib library
  MdeModulePkg: Add VarCheckUefiLib NULL class library
  Nt32Pkg: Add VarCheckLib library mapping
  OvmfPkg: Add VarCheckLib library mapping
  EmulatorPkg: Add VarCheckLib library mapping
  ArmVirtPkg: Add VarCheckLib library mapping
  ArmPlatformPkg: Add VarCheckLib library mapping
  Vlv2TbltDevicePkg: Add VarCheckLib library mapping
  MdeModulePkg Variable: Consume the separated VarCheckLib
  Nt32Pkg: Link separated VarCheckUefiLib NULL class library instance
  OvmfPkg: Link separated VarCheckUefiLib NULL class library instance
  EmulatorPkg: Link separated VarCheckUefiLib NULL class library
instance
  ArmVirtPkg: Link separated VarCheckUefiLib NULL class library instance
  ArmPlatformPkg: Link separated VarCheckUefiLib NULL class library
instance
  Vlv2TbltDevicePkg: Link separated VarCheckUefiLib NULL class library
instance

 ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc  |5 +-
 .../ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc|5 +-
 .../ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc |5 +-
 .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc |5 +-
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc  |1 +
 ArmVirtPkg/ArmVirt.dsc.inc |1 +
 ArmVirtPkg/ArmVirtQemu.dsc |5 +-
 EmulatorPkg/EmulatorPkg.dsc|6 +-
 MdeModulePkg/Include/Library/VarCheckLib.h |  180 
 MdeModulePkg/Library/VarCheckLib/VarCheckLib.c |  632 +++
 MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf   |   51 +
 MdeModulePkg/Library/VarCheckLib/VarCheckLib.uni   |  Bin 0 - 1798 bytes
 .../Library/VarCheckUefiLib/VarCheckUefiLib.inf|   88 ++
 .../Library/VarCheckUefiLib/VarCheckUefiLib.uni|  Bin 0 - 2158 bytes
 .../VarCheckUefiLib/VarCheckUefiLibNullClass.c |  930 
 MdeModulePkg/MdeModulePkg.dec  |4 +
 MdeModulePkg/MdeModulePkg.dsc  |   13 +-
 .../Universal/Variable/RuntimeDxe/VarCheck.c   | 1117 +---
 .../Universal/Variable/RuntimeDxe/Variable.c   |  193 +---
 .../Universal/Variable/RuntimeDxe/Variable.h   |   97 +-
 .../Universal/Variable/RuntimeDxe/VariableDxe.c|   48 +-
 .../Variable/RuntimeDxe/VariableRuntimeDxe.inf |   15 +-
 .../Universal/Variable/RuntimeDxe/VariableSmm.c|   23 +-
 .../Universal/Variable/RuntimeDxe/VariableSmm.inf  |   15 +-
 Nt32Pkg/Nt32Pkg.dsc|6 +-
 OvmfPkg/OvmfPkgIa32.dsc|6 +-
 OvmfPkg/OvmfPkgIa32X64.dsc |6 +-
 OvmfPkg/OvmfPkgX64.dsc |6 +-
 Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc|2 +
 Vlv2TbltDevicePkg/PlatformPkgIA32.dsc  |2 +
 Vlv2TbltDevicePkg/PlatformPkgX64.dsc   |2 +
 31 files changed, 2045 insertions(+), 1424 deletions(-)  create mode 100644 
MdeModulePkg/Include/Library/VarCheckLib.h
 create mode 100644 MdeModulePkg/Library/VarCheckLib/VarCheckLib.c
 create mode 100644 MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
 create mode 100644 MdeModulePkg/Library/VarCheckLib/VarCheckLib.uni
 create mode 100644 MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
 create mode 100644 MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.uni
 create mode 100644 
MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c

--
1.9.5.msysgit.0

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

Re: [edk2] [PATCH] ArmPkg: Bug fix for UncachedMemoryAllocationLib

2015-08-17 Thread Ard Biesheuvel
On 13 August 2015 at 16:37, Heyi Guo heyi@linaro.org wrote:
 NewNode is the node we found, while Node is the last node in the
 list. Also update mFreedBufferSize.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Heyi Guo heyi@linaro.org
 Cc: Leif Lindholm leif.lindh...@linaro.org
 Cc: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  .../UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c  | 7 
 ---
  1 file changed, 4 insertions(+), 3 deletions(-)


Reviewed-by: Ard Biesheuvel ard.biesheu...@linaro.org


 diff --git 
 a/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c 
 b/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c
 index e70d877..b859f63 100644
 --- a/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c
 +++ b/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c
 @@ -125,9 +125,10 @@ AllocatePagesFromList (
}
// Check if we have found a node that could contain our new allocation
if (NewNode != NULL) {
 -NewNode-Allocated = TRUE;
 -Node-Allocation   = (VOID*)(UINTN)Node-Base;
 -*Allocation= Node-Allocation;
 +NewNode-Allocated  = TRUE;
 +NewNode-Allocation = (VOID*)(UINTN)NewNode-Base;
 +*Allocation = NewNode-Allocation;
 +mFreedBufferSize-= NewNode-Pages * EFI_PAGE_SIZE;
  return EFI_SUCCESS;
}

 --
 2.1.4

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


Re: [edk2] [Patch 6/8] OptionRomPkg/OvmfPkg: Remove BltLib::BltConfigure API

2015-08-17 Thread Ni, Ruiyu
Jordan,
Sorry I missed your previous questions. Let me try to answer all your questions 
in this email.
Q1: Why merging Ex and non-Ex APIs? Providing Non-Ex APIs was to make simpler 
functions available for blt operations.
Merging the Ex and non-EX APIs is to avoid the library APIs provide overlapped 
functionalities. And it aligns to the interfaces defined in GOP protocol.

Q2: If removing BltConfigure, does that mean the library will have to check to 
see if the mode is different? what's the benefit?
After removing BltConfigure(), the library will calculate the shift/mask every 
time when doing the BLT operations. The benefit is to make the library 
stateless so it doesn't contain any state information so it can be called from 
different threads/CPUs.
For example strtok_r() is the stateless and reentrant version of strtok().
char *strtok(char *str, const char *delim);
char *strtok_r(char *str, const char *delim, char **saveptr);

Q3: What if we design a VideoModeSetLib?
GraphicsOutputDxe + null_VideoModeSetLib + BltLib - current GraphicsOutputDxe
GraphicsOutputDxe + qemu_VideoModeSetLib + BltLib - current QemuVideoDxe

Null_VideoModeSetLib only allows the video in the fixed mode supplied from PEI 
HOB
Qemu_VideoModeSetLib allows the video in several modes for QEMU.

Is my understanding correct?
Do you have more usage scenarios about the VideoModeSetLib? For now I only see 
two and only two, considering the design complexity introduced by 
VideoModeSetLib, leave the QemuVideoDxe driver as is make people easier to 
understand.

Thanks,
Ray

-Original Message-
From: Justen, Jordan L 
Sent: Tuesday, August 18, 2015 1:18 AM
To: Ni, Ruiyu ruiyu...@intel.com; edk2-devel@lists.01.org
Cc: Ni, Ruiyu ruiyu...@intel.com; Laszlo Ersek ler...@redhat.com
Subject: Re: [Patch 6/8] OptionRomPkg/OvmfPkg: Remove BltLib::BltConfigure API

On 2015-08-17 06:45:27, Ruiyu Ni wrote:
 The BltConfigure() API caches the video frame buffer meta data which
 forbids the library to be implemented to support re-entry.

How does this help? GraphicsOutputDxe will set a mode, and then use
BltLib with that mode.

I already asked this, and I had some other questions:

http://article.gmane.org/gmane.comp.bios.edk2.devel/1209

-Jordan

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ruiyu Ni ruiyu...@intel.com
 Cc: Laszlo Ersek ler...@redhat.com
 Cc: Jordan Justen jordan.l.jus...@intel.com
 ---
  .../Application/BltLibSample/BltLibSample.c| 129 +++---
  OptionRomPkg/Include/Library/BltLib.h  | 151 +++---
  .../Library/FrameBufferBltLib/FrameBufferBltLib.c  | 514 
 +++--
  OptionRomPkg/Library/GopBltLib/GopBltLib.c | 289 ++--
  OvmfPkg/QemuVideoDxe/Gop.c |  13 +-
  5 files changed, 576 insertions(+), 520 deletions(-)
 
 diff --git a/OptionRomPkg/Application/BltLibSample/BltLibSample.c 
 b/OptionRomPkg/Application/BltLibSample/BltLibSample.c
 index 333b054..3c7e392 100644
 --- a/OptionRomPkg/Application/BltLibSample/BltLibSample.c
 +++ b/OptionRomPkg/Application/BltLibSample/BltLibSample.c
 @@ -18,6 +18,7 @@
  #include Library/UefiLib.h
  #include Library/UefiApplicationEntryPoint.h
  #include Library/UefiBootServicesTableLib.h
 +#include Library/MemoryAllocationLib.h
  
  
  UINT64
 @@ -68,8 +69,8 @@ Rand32 (
  
  VOID
  TestFills (
 -  UINT32 HorizontalResolution,
 -  UINT32 VerticalResolution
 +  IN  VOID *FrameBuffer,
 +  IN  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *FrameBufferInfo
)
  {
EFI_GRAPHICS_OUTPUT_BLT_PIXEL  Color;
 @@ -79,44 +80,45 @@ TestFills (
UINTN  W;
UINTN  H;
  
 -  for (Loop = 0; Loop  1; Loop++) {
 -W = HorizontalResolution - (Rand32 () % HorizontalResolution);
 -H = VerticalResolution - (Rand32 () % VerticalResolution);
 -if (W != HorizontalResolution) {
 -  X = Rand32 () % (HorizontalResolution - W);
 +  for (Loop = 0; Loop  1000; Loop++) {
 +W = FrameBufferInfo-HorizontalResolution - (Rand32 () % 
 FrameBufferInfo-HorizontalResolution);
 +H = FrameBufferInfo-VerticalResolution - (Rand32 () % 
 FrameBufferInfo-VerticalResolution);
 +if (W != FrameBufferInfo-HorizontalResolution) {
 +  X = Rand32 () % (FrameBufferInfo-HorizontalResolution - W);
  } else {
X = 0;
  }
 -if (H != VerticalResolution) {
 -  Y = Rand32 () % (VerticalResolution - H);
 +if (H != FrameBufferInfo-VerticalResolution) {
 +  Y = Rand32 () % (FrameBufferInfo-VerticalResolution - H);
  } else {
Y = 0;
  }
  *(UINT32*) (Color) = Rand32 ()  0xff;
 -BltVideoFill (Color, X, Y, W, H);
 +BltVideoFill (FrameBuffer, FrameBufferInfo, Color, X, Y, W, H);
}
  }
  
  
  VOID
  TestColor1 (
 -  UINT32 HorizontalResolution,
 -  UINT32 VerticalResolution
 +  IN  VOID   

Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

2015-08-17 Thread Gao, Liming
Jiewen:
  The updated message is useful. I suggest to change error level from 
EFI_D_ERROR to EFI_D_INFO. 

Thanks
Liming
-Original Message-
From: Yao, Jiewen 
Sent: Tuesday, August 18, 2015 10:46 AM
To: Gao, Liming; Michael Zimmermann; edk2-devel@lists.01.org
Subject: RE: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

Hi
How about we update debug message like below:

Index: PropertiesTable.c
===
--- PropertiesTable.c   (revision 18191)
+++ PropertiesTable.c   (working copy)
@@ -1120,7 +1120,7 @@
 
   SetPropertiesTableSectionAlignment (SectionAlignment);
   if ((SectionAlignment  (EFI_ACPI_RUNTIME_PAGE_ALLOCATION_ALIGNMENT - 1)) != 
0) {
-DEBUG ((EFI_D_ERROR,   InsertImageRecord - Section 
Alignment(0x%x) is not %dK  \n,
+DEBUG ((EFI_D_ERROR,   UEFI2.5 PropertiesTable - Runtime Driver 
Section Alignment(0x%x) is not %dK  \n,
   SectionAlignment, EFI_ACPI_RUNTIME_PAGE_ALLOCATION_ALIGNMENT  10));
 PdbPointer = PeCoffLoaderGetPdbPointer ((VOID*) (UINTN) ImageAddress);
 if (PdbPointer != NULL) {




-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao, 
Liming
Sent: Tuesday, August 18, 2015 10:39 AM
To: Michael Zimmermann; edk2-devel@lists.01.org
Subject: Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

Hi, 
  This is a warning message that describes the runtime driver alignment is not 
4K.  

  UEFI PropertiesTable table feature expects all runtime driver alignment is 
4K. When DxeCore loads Runtime driver, it will check its alignment and report 
such warning message if it doesn't meet with the alignment. If you want to 
enable this feature, you need to make sure all runtime driver at 4K. If you 
don't enable it, you can just ignore this message. 

  To configure runtime driver with 4K alignment, you can modify DSC file to add 
the following section.
[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
  GCC:  *_*_*_DLINK_FLAGS = -z common-page-size=0x1000
  MSFT: *_*_*_DLINK_FLAGS = /ALIGN:4096 

Thanks
Liming
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael 
Zimmermann
Sent: Sunday, August 16, 2015 12:32 PM
To: edk2-devel@lists.01.org
Subject: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

When booting(a new device I'm currently working on) I get these warnings:
  InsertImageRecord - Section Alignment(0x20) is not 4K  

the warning is raised by MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c and 
when compiling using GCC from Linux, the SectionAlignment is set by 
BaseTools/Source/C/GenFw/Elf32Convert.c.

I checked the resulting binaries using readpe and indeed they have a 
SectionAlignment of 0x20, while the precompiled binaries like Shell.efi have a 
Alignment of 0x1000(4K).

So, is this a bug of my GCC compiler or of EDK2?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v2 16/16] OvmfPkg/X64: enable 4 KB alignment for DXE_RUNTIME modules

2015-08-17 Thread Gao, Liming
Ard:
  I think this patch needs to update VS tool chain link flag to enable 4K for 
DXE_RUNTIME modules, because Ovmf platform also supports VS tool chain. 

Thanks
Liming
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
Biesheuvel
Sent: Monday, August 17, 2015 10:25 PM
To: edk2-devel@lists.01.org; Liu, Yingke D
Cc: wp...@windriver.com; sc...@notabs.org; Ard Biesheuvel; Justen, Jordan L; 
Gao, Liming; dw...@infradead.org
Subject: [edk2] [PATCH v2 16/16] OvmfPkg/X64: enable 4 KB alignment for 
DXE_RUNTIME modules

This enables 4 KB section alignment for DXE_RUNTIME modules, for ELF based 
toolchains and for the UNIXGCC PE/COFF toolchain.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
 OvmfPkg/OvmfPkgX64.dsc | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc index 
b72eaa92f82e..817c381f4913 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -48,6 +48,13 @@ [BuildOptions]
   INTEL:*_*_X64_GENFW_FLAGS = --keepexceptiontable  !endif
 
+[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
+!if $(TOOLCHAIN) == UNIXGCC
+  GCC:*_*_X64_DLINK_FLAGS = --section-alignment 0x1000 --file-alignment 
+0x1000 !else
+  GCC:*_*_X64_DLINK_FLAGS = -z common-page-size=0x1000 !endif
+
 

 #
 # SKU Identification section - list of all SKU IDs supported by this Platform.
--
1.9.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] Section Alignment of elf binaries compiled with GCC(Linux)

2015-08-17 Thread Gao, Liming
Hi, 
  This is a warning message that describes the runtime driver alignment is not 
4K.  

  UEFI PropertiesTable table feature expects all runtime driver alignment is 
4K. When DxeCore loads Runtime driver, it will check its alignment and report 
such warning message if it doesn't meet with the alignment. If you want to 
enable this feature, you need to make sure all runtime driver at 4K. If you 
don't enable it, you can just ignore this message. 

  To configure runtime driver with 4K alignment, you can modify DSC file to add 
the following section.
[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
  GCC:  *_*_*_DLINK_FLAGS = -z common-page-size=0x1000
  MSFT: *_*_*_DLINK_FLAGS = /ALIGN:4096 

Thanks
Liming
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael 
Zimmermann
Sent: Sunday, August 16, 2015 12:32 PM
To: edk2-devel@lists.01.org
Subject: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

When booting(a new device I'm currently working on) I get these warnings:
  InsertImageRecord - Section Alignment(0x20) is not 4K  

the warning is raised by MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c and 
when compiling using GCC from Linux, the SectionAlignment is set by 
BaseTools/Source/C/GenFw/Elf32Convert.c.

I checked the resulting binaries using readpe and indeed they have a 
SectionAlignment of 0x20, while the precompiled binaries like Shell.efi have a 
Alignment of 0x1000(4K).

So, is this a bug of my GCC compiler or of EDK2?
___
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] Section Alignment of elf binaries compiled with GCC(Linux)

2015-08-17 Thread Yao, Jiewen
OK

-Original Message-
From: Gao, Liming 
Sent: Tuesday, August 18, 2015 10:48 AM
To: Yao, Jiewen; Michael Zimmermann; edk2-devel@lists.01.org
Subject: RE: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

Jiewen:
  The updated message is useful. I suggest to change error level from 
EFI_D_ERROR to EFI_D_INFO. 

Thanks
Liming
-Original Message-
From: Yao, Jiewen 
Sent: Tuesday, August 18, 2015 10:46 AM
To: Gao, Liming; Michael Zimmermann; edk2-devel@lists.01.org
Subject: RE: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

Hi
How about we update debug message like below:

Index: PropertiesTable.c
===
--- PropertiesTable.c   (revision 18191)
+++ PropertiesTable.c   (working copy)
@@ -1120,7 +1120,7 @@
 
   SetPropertiesTableSectionAlignment (SectionAlignment);
   if ((SectionAlignment  (EFI_ACPI_RUNTIME_PAGE_ALLOCATION_ALIGNMENT - 1)) != 
0) {
-DEBUG ((EFI_D_ERROR,   InsertImageRecord - Section 
Alignment(0x%x) is not %dK  \n,
+DEBUG ((EFI_D_ERROR,   UEFI2.5 PropertiesTable - Runtime Driver 
Section Alignment(0x%x) is not %dK  \n,
   SectionAlignment, EFI_ACPI_RUNTIME_PAGE_ALLOCATION_ALIGNMENT  10));
 PdbPointer = PeCoffLoaderGetPdbPointer ((VOID*) (UINTN) ImageAddress);
 if (PdbPointer != NULL) {




-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao, 
Liming
Sent: Tuesday, August 18, 2015 10:39 AM
To: Michael Zimmermann; edk2-devel@lists.01.org
Subject: Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

Hi, 
  This is a warning message that describes the runtime driver alignment is not 
4K.  

  UEFI PropertiesTable table feature expects all runtime driver alignment is 
4K. When DxeCore loads Runtime driver, it will check its alignment and report 
such warning message if it doesn't meet with the alignment. If you want to 
enable this feature, you need to make sure all runtime driver at 4K. If you 
don't enable it, you can just ignore this message. 

  To configure runtime driver with 4K alignment, you can modify DSC file to add 
the following section.
[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
  GCC:  *_*_*_DLINK_FLAGS = -z common-page-size=0x1000
  MSFT: *_*_*_DLINK_FLAGS = /ALIGN:4096 

Thanks
Liming
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael 
Zimmermann
Sent: Sunday, August 16, 2015 12:32 PM
To: edk2-devel@lists.01.org
Subject: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

When booting(a new device I'm currently working on) I get these warnings:
  InsertImageRecord - Section Alignment(0x20) is not 4K  

the warning is raised by MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c and 
when compiling using GCC from Linux, the SectionAlignment is set by 
BaseTools/Source/C/GenFw/Elf32Convert.c.

I checked the resulting binaries using readpe and indeed they have a 
SectionAlignment of 0x20, while the precompiled binaries like Shell.efi have a 
Alignment of 0x1000(4K).

So, is this a bug of my GCC compiler or of EDK2?
___
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 v2 07/16] BaseTools GCC: use leading underscore for symbol names where appropriate

2015-08-17 Thread Ard Biesheuvel
The MS ABI uses leading underscores to decorate symbol names only
when generating 32-bit code. Due to a bug in GCC prior to version 4.3,
it used the same decoration for 64-bit code but this has been fixed
since. So uses the leading underscore for IA32 only, and remove it
for X64.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
 BaseTools/Conf/tools_def.template | 22 +++-
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index ee3275c7f668..1304f514cd37 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -3824,10 +3824,12 @@ DEFINE GCC_IA32_X64_DLINK_COMMON   = 
DEF(GCC_DLINK_FLAGS_COMMON) --gc-sections
 DEFINE GCC_ARM_AARCH64_DLINK_COMMON= --emit-relocs -nostdlib --gc-sections -u 
$(IMAGE_ENTRY_POINT) -e $(IMAGE_ENTRY_POINT) -Map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map
 DEFINE GCC_ARM_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) 
-Ttext=0x0
 DEFINE GCC_AARCH64_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) -z 
common-page-size=0x20
-DEFINE GCC_IA32_X64_ASLDLINK_FLAGS = DEF(GCC_IA32_X64_DLINK_COMMON) --entry 
_ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT)
+DEFINE GCC_IA32_ASLDLINK_FLAGS = DEF(GCC_IA32_X64_DLINK_COMMON) --entry 
_ReferenceAcpiTable -u _$(IMAGE_ENTRY_POINT)
+DEFINE GCC_X64_ASLDLINK_FLAGS  = DEF(GCC_IA32_X64_DLINK_COMMON) --entry 
ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT)
 DEFINE GCC_ARM_ASLDLINK_FLAGS  = DEF(GCC_ARM_DLINK_FLAGS) --entry 
ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT)
 DEFINE GCC_AARCH64_ASLDLINK_FLAGS  = DEF(GCC_AARCH64_DLINK_FLAGS) --entry 
ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT)
-DEFINE GCC_IA32_X64_DLINK_FLAGS= DEF(GCC_IA32_X64_DLINK_COMMON) --entry 
_$(IMAGE_ENTRY_POINT) --file-alignment 0x20 --section-alignment 0x20 -Map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map
+DEFINE GCC_IA32_DLINK_FLAGS= DEF(GCC_IA32_X64_DLINK_COMMON) --entry 
_$(IMAGE_ENTRY_POINT) --file-alignment 0x20 --section-alignment 0x20 -Map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map
+DEFINE GCC_X64_DLINK_FLAGS = DEF(GCC_IA32_X64_DLINK_COMMON) --entry 
$(IMAGE_ENTRY_POINT) --file-alignment 0x20 --section-alignment 0x20 -Map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map
 DEFINE GCC_IPF_DLINK_FLAGS = -nostdlib -O2 --gc-sections --dll -static 
--entry $(IMAGE_ENTRY_POINT) --undefined $(IMAGE_ENTRY_POINT) -Map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map
 DEFINE GCC_IPF_OBJCOPY_FLAGS   = -I elf64-ia64-little -O efi-bsdrv-ia64
 DEFINE GCC_IPF_SYMRENAME_FLAGS = --redefine-sym memcpy=CopyMem
@@ -3933,10 +3935,10 @@ DEFINE GCC49_AARCH64_ASLDLINK_FLAGS  = 
DEF(GCC48_AARCH64_ASLDLINK_FLAGS)
 *_UNIXGCC_*_MAKE_PATH= make
 *_UNIXGCC_*_ASL_PATH = DEF(UNIX_IASL_BIN)
 
-*_UNIXGCC_IA32_DLINK_FLAGS   = DEF(GCC_IA32_X64_DLINK_FLAGS) 
--image-base=0
-*_UNIXGCC_X64_DLINK_FLAGS= DEF(GCC_IA32_X64_DLINK_FLAGS) 
--image-base=0
-*_UNIXGCC_IA32_ASLDLINK_FLAGS= DEF(GCC_IA32_X64_ASLDLINK_FLAGS)
-*_UNIXGCC_X64_ASLDLINK_FLAGS = DEF(GCC_IA32_X64_ASLDLINK_FLAGS)
+*_UNIXGCC_IA32_DLINK_FLAGS   = DEF(GCC_IA32_DLINK_FLAGS) 
--image-base=0
+*_UNIXGCC_X64_DLINK_FLAGS= DEF(GCC_X64_DLINK_FLAGS) 
--image-base=0
+*_UNIXGCC_IA32_ASLDLINK_FLAGS= DEF(GCC_IA32_ASLDLINK_FLAGS)
+*_UNIXGCC_X64_ASLDLINK_FLAGS = DEF(GCC_X64_ASLDLINK_FLAGS)
 *_UNIXGCC_*_ASM_FLAGS= DEF(GCC_ASM_FLAGS)
 *_UNIXGCC_*_PP_FLAGS = DEF(GCC_PP_FLAGS)
 *_UNIXGCC_*_ASLPP_FLAGS  = DEF(GCC_ASLPP_FLAGS)
@@ -4692,10 +4694,10 @@ RELEASE_CLANG35_AARCH64_CC_FLAGS = 
DEF(CLANG35_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS)
 *_CYGGCC_*_MAKE_PATH = DEF(MS_VS_BIN)\nmake.exe
 *_CYGGCC_*_ASL_PATH  = DEF(DEFAULT_WIN_ASL_BIN)
 
-*_CYGGCC_IA32_DLINK_FLAGS   = DEF(GCC_IA32_X64_DLINK_FLAGS) 
--image-base=0
-*_CYGGCC_X64_DLINK_FLAGS= DEF(GCC_IA32_X64_DLINK_FLAGS) 
--image-base=0
-*_CYGGCC_IA32_ASLDLINK_FLAGS= DEF(GCC_IA32_X64_ASLDLINK_FLAGS)
-*_CYGGCC_X64_ASLDLINK_FLAGS = DEF(GCC_IA32_X64_ASLDLINK_FLAGS)
+*_CYGGCC_IA32_DLINK_FLAGS   = DEF(GCC_IA32_DLINK_FLAGS) 
--image-base=0
+*_CYGGCC_X64_DLINK_FLAGS= DEF(GCC_X64_DLINK_FLAGS) 
--image-base=0
+*_CYGGCC_IA32_ASLDLINK_FLAGS= DEF(GCC_IA32_ASLDLINK_FLAGS)
+*_CYGGCC_X64_ASLDLINK_FLAGS = DEF(GCC_X64_ASLDLINK_FLAGS)
 *_CYGGCC_*_MAKE_FLAGS   = /nologo
 *_CYGGCC_*_ASM_FLAGS= DEF(GCC_ASM_FLAGS)
 *_CYGGCC_*_PP_FLAGS = DEF(GCC_PP_FLAGS)
-- 
1.9.1

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


[edk2] [PATCH v2 08/16] BaseTools GCC: refactor tools_def internal GCC defines for [AS]DLINK

2015-08-17 Thread Ard Biesheuvel
Disentangle the arguments passed to the various flavors of GCC we
support, by refactoring the [AS]DLINK flags so that we distinguish
more clearly between toolchains that generate PE/COFF directly (for
IA32 and X86 only) and toolchains that generate ELF only.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
 BaseTools/Conf/tools_def.template | 30 +++-
 1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 1304f514cd37..c7e4e0ac5867 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -3818,19 +3818,21 @@ DEFINE GCC_IPF_CC_FLAGS= 
DEF(GCC_ALL_ELF_CC_FLAGS) -Os -minline-int-
 DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -Os 
-mword-relocations -mlittle-endian -mabi=aapcs -mapcs -fno-short-enums 
-save-temps -fsigned-char -ffunction-sections -fdata-sections 
-fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft
 DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -Os 
-mcmodel=large -mlittle-endian -fno-short-enums -save-temps -fverbose-asm 
-fsigned-char  -ffunction-sections -fdata-sections -fomit-frame-pointer 
-fno-builtin -Wno-address -fno-asynchronous-unwind-tables
 
-DEFINE GCC_DLINK_FLAGS_COMMON  = -nostdlib --pie
 DEFINE GCC_DLINK2_FLAGS_COMMON = 
--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
-DEFINE GCC_IA32_X64_DLINK_COMMON   = DEF(GCC_DLINK_FLAGS_COMMON) --gc-sections
+DEFINE GCC_ALL_DLINK_FLAGS = -nostdlib
+DEFINE GCC_ALL_DLINK_PE_FLAGS  = DEF(GCC_ALL_DLINK_FLAGS) --pie
+DEFINE GCC_IA32_X64_DLINK_PE_FLAGS = DEF(GCC_ALL_DLINK_PE_FLAGS) --gc-sections
+DEFINE GCC_IA32_DLINK_PE_FLAGS = DEF(GCC_IA32_X64_DLINK_PE_FLAGS) --entry 
_$(IMAGE_ENTRY_POINT) --file-alignment 0x20 --section-alignment 0x20 -Map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map
+DEFINE GCC_X64_DLINK_PE_FLAGS  = DEF(GCC_IA32_X64_DLINK_PE_FLAGS) --entry 
$(IMAGE_ENTRY_POINT) --file-alignment 0x20 --section-alignment 0x20 -Map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map
 DEFINE GCC_ARM_AARCH64_DLINK_COMMON= --emit-relocs -nostdlib --gc-sections -u 
$(IMAGE_ENTRY_POINT) -e $(IMAGE_ENTRY_POINT) -Map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map
 DEFINE GCC_ARM_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) 
-Ttext=0x0
 DEFINE GCC_AARCH64_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) -z 
common-page-size=0x20
-DEFINE GCC_IA32_ASLDLINK_FLAGS = DEF(GCC_IA32_X64_DLINK_COMMON) --entry 
_ReferenceAcpiTable -u _$(IMAGE_ENTRY_POINT)
-DEFINE GCC_X64_ASLDLINK_FLAGS  = DEF(GCC_IA32_X64_DLINK_COMMON) --entry 
ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT)
+DEFINE GCC_IA32_ASLDLINK_PE_FLAGS  = DEF(GCC_IA32_X64_DLINK_PE_FLAGS) --entry 
_ReferenceAcpiTable -u _$(IMAGE_ENTRY_POINT)
+DEFINE GCC_X64_ASLDLINK_PE_FLAGS   = DEF(GCC_IA32_X64_DLINK_PE_FLAGS) --entry 
ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT)
 DEFINE GCC_ARM_ASLDLINK_FLAGS  = DEF(GCC_ARM_DLINK_FLAGS) --entry 
ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT)
 DEFINE GCC_AARCH64_ASLDLINK_FLAGS  = DEF(GCC_AARCH64_DLINK_FLAGS) --entry 
ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT)
-DEFINE GCC_IA32_DLINK_FLAGS= DEF(GCC_IA32_X64_DLINK_COMMON) --entry 
_$(IMAGE_ENTRY_POINT) --file-alignment 0x20 --section-alignment 0x20 -Map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map
-DEFINE GCC_X64_DLINK_FLAGS = DEF(GCC_IA32_X64_DLINK_COMMON) --entry 
$(IMAGE_ENTRY_POINT) --file-alignment 0x20 --section-alignment 0x20 -Map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map
 DEFINE GCC_IPF_DLINK_FLAGS = -nostdlib -O2 --gc-sections --dll -static 
--entry $(IMAGE_ENTRY_POINT) --undefined $(IMAGE_ENTRY_POINT) -Map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map
+
 DEFINE GCC_IPF_OBJCOPY_FLAGS   = -I elf64-ia64-little -O efi-bsdrv-ia64
 DEFINE GCC_IPF_SYMRENAME_FLAGS = --redefine-sym memcpy=CopyMem
 DEFINE GCC_ASM_FLAGS   = -c -x assembler -imacros 
$(DEST_DIR_DEBUG)/AutoGen.h
@@ -3935,10 +3937,10 @@ DEFINE GCC49_AARCH64_ASLDLINK_FLAGS  = 
DEF(GCC48_AARCH64_ASLDLINK_FLAGS)
 *_UNIXGCC_*_MAKE_PATH= make
 *_UNIXGCC_*_ASL_PATH = DEF(UNIX_IASL_BIN)
 
-*_UNIXGCC_IA32_DLINK_FLAGS   = DEF(GCC_IA32_DLINK_FLAGS) 
--image-base=0
-*_UNIXGCC_X64_DLINK_FLAGS= DEF(GCC_X64_DLINK_FLAGS) 
--image-base=0
-*_UNIXGCC_IA32_ASLDLINK_FLAGS= DEF(GCC_IA32_ASLDLINK_FLAGS)
-*_UNIXGCC_X64_ASLDLINK_FLAGS = DEF(GCC_X64_ASLDLINK_FLAGS)
+*_UNIXGCC_IA32_DLINK_FLAGS   = DEF(GCC_IA32_DLINK_PE_FLAGS) 
--image-base=0
+*_UNIXGCC_X64_DLINK_FLAGS= DEF(GCC_X64_DLINK_PE_FLAGS) 
--image-base=0
+*_UNIXGCC_IA32_ASLDLINK_FLAGS= DEF(GCC_IA32_ASLDLINK_PE_FLAGS)
+*_UNIXGCC_X64_ASLDLINK_FLAGS = DEF(GCC_X64_ASLDLINK_PE_FLAGS)
 *_UNIXGCC_*_ASM_FLAGS= DEF(GCC_ASM_FLAGS)
 *_UNIXGCC_*_PP_FLAGS = DEF(GCC_PP_FLAGS)
 

[edk2] [PATCH v2 06/16] BaseTools GCC: unify all IA32 and X64 CC flags for ELF based GCC

2015-08-17 Thread Ard Biesheuvel
GCC4x and ELFGCC are both ELF based GCC toolchains, so there is no
justification for allowing the command line option to deviate.
So align them.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
 BaseTools/Conf/tools_def.template | 43 
 1 file changed, 17 insertions(+), 26 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 8b03f3081669..ee3275c7f668 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -3811,10 +3811,13 @@ DEFINE GCC_ALL_CC_FLAGS= -g -fshort-wchar 
-fno-strict-aliasing -Wall
 DEFINE GCC_ALL_PE_CC_FLAGS = DEF(GCC_ALL_CC_FLAGS)
 DEFINE GCC_ALL_ELF_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -ffunction-sections 
-fdata-sections -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
 DEFINE GCC_IA32_CC_PE_FLAGS= DEF(GCC_ALL_PE_CC_FLAGS) -m32 
-malign-double -freorder-blocks -freorder-blocks-and-partition -O2 
-mno-stack-arg-probe
+DEFINE GCC_IA32_CC_ELF_FLAGS   = DEF(GCC_ALL_ELF_CC_FLAGS) -m32 
-malign-double -fno-stack-protector -D EFI32 -fno-asynchronous-unwind-tables
 DEFINE GCC_X64_CC_PE_FLAGS = DEF(GCC_ALL_PE_CC_FLAGS) -Os 
-mno-red-zone -mno-stack-arg-probe
+DEFINE GCC_X64_CC_ELF_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -m64 
-fno-stack-protector -DEFIAPI=__attribute__((ms_abi)) -DNO_BUILTIN_VA_FUNCS 
-mno-red-zone -mcmodel=large -fno-asynchronous-unwind-tables
 DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -Os 
-minline-int-divide-min-latency
 DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -Os 
-mword-relocations -mlittle-endian -mabi=aapcs -mapcs -fno-short-enums 
-save-temps -fsigned-char -ffunction-sections -fdata-sections 
-fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft
 DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -Os 
-mcmodel=large -mlittle-endian -fno-short-enums -save-temps -fverbose-asm 
-fsigned-char  -ffunction-sections -fdata-sections -fomit-frame-pointer 
-fno-builtin -Wno-address -fno-asynchronous-unwind-tables
+
 DEFINE GCC_DLINK_FLAGS_COMMON  = -nostdlib --pie
 DEFINE GCC_DLINK2_FLAGS_COMMON = 
--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
 DEFINE GCC_IA32_X64_DLINK_COMMON   = DEF(GCC_DLINK_FLAGS_COMMON) --gc-sections
@@ -3839,8 +3842,6 @@ DEFINE GCC_IPF_RC_FLAGS= -I binary -O 
elf64-ia64-little   -B ia64
 DEFINE GCC_ARM_RC_FLAGS= -I binary -O elf32-littlearm -B arm   
  --rename-section .data=.hii
 DEFINE GCC_AARCH64_RC_FLAGS= -I binary -O elf64-littleaarch64 -B 
aarch64 --rename-section .data=.hii
 
-DEFINE GCC44_IA32_CC_FLAGS   = DEF(GCC_ALL_ELF_CC_FLAGS) -m32 
-malign-double -fno-stack-protector -D EFI32 -fno-asynchronous-unwind-tables
-DEFINE GCC44_X64_CC_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -m64 
-fno-stack-protector -DEFIAPI=__attribute__((ms_abi)) -DNO_BUILTIN_VA_FUNCS 
-mno-red-zone -Wno-address -mcmodel=large -fno-asynchronous-unwind-tables
 DEFINE GCC44_IA32_X64_DLINK_COMMON   = -nostdlib -n -q --gc-sections -z 
common-page-size=0x20
 DEFINE GCC44_IA32_X64_ASLDLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_COMMON) 
--entry ReferenceAcpiTable -u ReferenceAcpiTable
 DEFINE GCC44_IA32_X64_DLINK_FLAGS= DEF(GCC44_IA32_X64_DLINK_COMMON) 
--entry $(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map
@@ -3849,8 +3850,6 @@ DEFINE GCC44_X64_DLINK_FLAGS = 
DEF(GCC44_IA32_X64_DLINK_FLAGS)  -melf_x8
 DEFINE GCC44_X64_DLINK2_FLAGS= --defsym=PECOFF_HEADER_SIZE=0x228 
DEF(GCC_DLINK2_FLAGS_COMMON)
 DEFINE GCC44_ASM_FLAGS   = DEF(GCC_ASM_FLAGS)
 
-DEFINE GCC45_IA32_CC_FLAGS   = DEF(GCC44_IA32_CC_FLAGS)
-DEFINE GCC45_X64_CC_FLAGS= DEF(GCC44_X64_CC_FLAGS)
 DEFINE GCC45_IA32_X64_DLINK_COMMON   = DEF(GCC44_IA32_X64_DLINK_COMMON)
 DEFINE GCC45_IA32_X64_ASLDLINK_FLAGS = DEF(GCC44_IA32_X64_ASLDLINK_FLAGS)
 DEFINE GCC45_IA32_X64_DLINK_FLAGS= DEF(GCC44_IA32_X64_DLINK_FLAGS)
@@ -3859,8 +3858,6 @@ DEFINE GCC45_X64_DLINK_FLAGS = 
DEF(GCC44_X64_DLINK_FLAGS)
 DEFINE GCC45_X64_DLINK2_FLAGS= DEF(GCC44_X64_DLINK2_FLAGS)
 DEFINE GCC45_ASM_FLAGS   = DEF(GCC44_ASM_FLAGS)
 
-DEFINE GCC46_IA32_CC_FLAGS   = DEF(GCC45_IA32_CC_FLAGS)
-DEFINE GCC46_X64_CC_FLAGS= DEF(GCC45_X64_CC_FLAGS)
 DEFINE GCC46_IA32_X64_DLINK_COMMON   = DEF(GCC45_IA32_X64_DLINK_COMMON)
 DEFINE GCC46_IA32_X64_ASLDLINK_FLAGS = DEF(GCC45_IA32_X64_ASLDLINK_FLAGS)
 DEFINE GCC46_IA32_X64_DLINK_FLAGS= DEF(GCC45_IA32_X64_DLINK_FLAGS)
@@ -3873,8 +3870,6 @@ DEFINE GCC46_ARM_CC_FLAGS= $(ARCHCC_FLAGS) 
$(PLATFORM_FLAGS) DEF(GCC
 DEFINE GCC46_ARM_DLINK_FLAGS = DEF(GCC_ARM_DLINK_FLAGS) 
--oformat=elf32-littlearm
 DEFINE GCC46_ARM_ASLDLINK_FLAGS  = DEF(GCC_ARM_ASLDLINK_FLAGS) 
--oformat=elf32-littlearm
 
-DEFINE GCC47_IA32_CC_FLAGS   = DEF(GCC46_IA32_CC_FLAGS)
-DEFINE 

[edk2] [PATCH v2 04/16] BaseTools GCC: merge warning flags for all GCC versions

2015-08-17 Thread Ard Biesheuvel
The warning flags -Wno-address -Wno-unused-but-set-variable are added
for version 4.6 and up, but since they are happily accepted by version
4.4 and 4.5, add them there as well.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
Reviewed-by: Liming Gao liming@intel.com
---
 BaseTools/Conf/tools_def.template | 22 ++--
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 506e734b6895..af9e99f5647c 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -3837,7 +3837,7 @@ DEFINE GCC_IPF_RC_FLAGS= -I binary -O 
elf64-ia64-little   -B ia64
 DEFINE GCC_ARM_RC_FLAGS= -I binary -O elf32-littlearm -B arm   
  --rename-section .data=.hii
 DEFINE GCC_AARCH64_RC_FLAGS= -I binary -O elf64-littleaarch64 -B 
aarch64 --rename-section .data=.hii
 
-DEFINE GCC44_ALL_CC_FLAGS= -g -fshort-wchar -fno-strict-aliasing 
-Wall -Werror -Wno-array-bounds -ffunction-sections -fdata-sections -c -include 
AutoGen.h -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
+DEFINE GCC44_ALL_CC_FLAGS= -g -fshort-wchar -fno-strict-aliasing 
-Wall -Werror -Wno-array-bounds -Wno-address -Wno-unused-but-set-variable 
-ffunction-sections -fdata-sections -c -include AutoGen.h 
-DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
 DEFINE GCC44_IA32_CC_FLAGS   = DEF(GCC44_ALL_CC_FLAGS) -m32 
-malign-double -fno-stack-protector -D EFI32 -fno-asynchronous-unwind-tables
 DEFINE GCC44_X64_CC_FLAGS= DEF(GCC44_ALL_CC_FLAGS) -m64 
-fno-stack-protector -DEFIAPI=__attribute__((ms_abi)) -DNO_BUILTIN_VA_FUNCS 
-mno-red-zone -Wno-address -mcmodel=large -fno-asynchronous-unwind-tables
 DEFINE GCC44_IA32_X64_DLINK_COMMON   = -nostdlib -n -q --gc-sections -z 
common-page-size=0x20
@@ -3858,8 +3858,8 @@ DEFINE GCC45_X64_DLINK_FLAGS = 
DEF(GCC44_X64_DLINK_FLAGS)
 DEFINE GCC45_X64_DLINK2_FLAGS= DEF(GCC44_X64_DLINK2_FLAGS)
 DEFINE GCC45_ASM_FLAGS   = DEF(GCC44_ASM_FLAGS)
 
-DEFINE GCC46_IA32_CC_FLAGS   = DEF(GCC45_IA32_CC_FLAGS) -Wno-address 
-Wno-unused-but-set-variable
-DEFINE GCC46_X64_CC_FLAGS= DEF(GCC45_X64_CC_FLAGS) -Wno-address 
-Wno-unused-but-set-variable
+DEFINE GCC46_IA32_CC_FLAGS   = DEF(GCC45_IA32_CC_FLAGS)
+DEFINE GCC46_X64_CC_FLAGS= DEF(GCC45_X64_CC_FLAGS)
 DEFINE GCC46_IA32_X64_DLINK_COMMON   = DEF(GCC45_IA32_X64_DLINK_COMMON)
 DEFINE GCC46_IA32_X64_ASLDLINK_FLAGS = DEF(GCC45_IA32_X64_ASLDLINK_FLAGS)
 DEFINE GCC46_IA32_X64_DLINK_FLAGS= DEF(GCC45_IA32_X64_DLINK_FLAGS)
@@ -4255,7 +4255,7 @@ DEFINE GCC49_AARCH64_ASLDLINK_FLAGS  = 
DEF(GCC48_AARCH64_ASLDLINK_FLAGS)
 *_GCC46_ARM_VFRPP_FLAGS  = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC_VFRPP_FLAGS)
 
   DEBUG_GCC46_ARM_CC_FLAGS   = DEF(GCC46_ARM_CC_FLAGS) 
-D__ARM_FEATURE_UNALIGNED=0 -O0
-RELEASE_GCC46_ARM_CC_FLAGS   = DEF(GCC46_ARM_CC_FLAGS) 
-D__ARM_FEATURE_UNALIGNED=0 -Wno-unused-but-set-variable
+RELEASE_GCC46_ARM_CC_FLAGS   = DEF(GCC46_ARM_CC_FLAGS) 
-D__ARM_FEATURE_UNALIGNED=0
 
 

 #
@@ -4354,7 +4354,7 @@ RELEASE_GCC46_ARM_CC_FLAGS   = 
DEF(GCC46_ARM_CC_FLAGS) -D__ARM_FEATURE_UNALI
 *_GCC47_ARM_VFRPP_FLAGS  = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC_VFRPP_FLAGS)
 
   DEBUG_GCC47_ARM_CC_FLAGS   = DEF(GCC47_ARM_CC_FLAGS) -O0
-RELEASE_GCC47_ARM_CC_FLAGS   = DEF(GCC47_ARM_CC_FLAGS) 
-Wno-unused-but-set-variable
+RELEASE_GCC47_ARM_CC_FLAGS   = DEF(GCC47_ARM_CC_FLAGS)
 
 ##
 # GCC47 AARCH64 definitions
@@ -4381,7 +4381,7 @@ RELEASE_GCC47_ARM_CC_FLAGS   = 
DEF(GCC47_ARM_CC_FLAGS) -Wno-unused-but-set-v
 *_GCC47_AARCH64_VFRPP_FLAGS  = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC_VFRPP_FLAGS)
 
   DEBUG_GCC47_AARCH64_CC_FLAGS   = DEF(GCC47_AARCH64_CC_FLAGS) -O0
-RELEASE_GCC47_AARCH64_CC_FLAGS   = DEF(GCC47_AARCH64_CC_FLAGS) 
-Wno-unused-but-set-variable
+RELEASE_GCC47_AARCH64_CC_FLAGS   = DEF(GCC47_AARCH64_CC_FLAGS)
 
 

 #
@@ -4480,7 +4480,7 @@ RELEASE_GCC47_AARCH64_CC_FLAGS   = 
DEF(GCC47_AARCH64_CC_FLAGS) -Wno-unused-but-s
 *_GCC48_ARM_VFRPP_FLAGS  = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC_VFRPP_FLAGS)
 
   DEBUG_GCC48_ARM_CC_FLAGS   = DEF(GCC48_ARM_CC_FLAGS) -O0
-RELEASE_GCC48_ARM_CC_FLAGS   = DEF(GCC48_ARM_CC_FLAGS) 
-Wno-unused-but-set-variable
+RELEASE_GCC48_ARM_CC_FLAGS   = DEF(GCC48_ARM_CC_FLAGS)
 
 ##
 # GCC48 AARCH64 definitions
@@ -4507,7 +4507,7 @@ RELEASE_GCC48_ARM_CC_FLAGS   = 
DEF(GCC48_ARM_CC_FLAGS) -Wno-unused-but-set-v
 *_GCC48_AARCH64_VFRPP_FLAGS  = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC_VFRPP_FLAGS)
 
   DEBUG_GCC48_AARCH64_CC_FLAGS   = DEF(GCC48_AARCH64_CC_FLAGS) -O0

[edk2] [PATCH v2 14/16] BaseTools GCC: unify ASM flags for all GCC versions

2015-08-17 Thread Ard Biesheuvel
Use the same GCC options for assembling regardless of the exact
GCC version.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
 BaseTools/Conf/tools_def.template | 67 
 1 file changed, 27 insertions(+), 40 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 18ae92623e1c..a21b44ffd413 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -3845,7 +3845,13 @@ DEFINE GCC_AARCH64_DLINK2_FLAGS= 
--defsym=PECOFF_HEADER_SIZE=0x228 DEF(GCC_A
 
 DEFINE GCC_IPF_OBJCOPY_FLAGS   = -I elf64-ia64-little -O efi-bsdrv-ia64
 DEFINE GCC_IPF_SYMRENAME_FLAGS = --redefine-sym memcpy=CopyMem
+
 DEFINE GCC_ASM_FLAGS   = -c -x assembler -imacros 
$(DEST_DIR_DEBUG)/AutoGen.h
+DEFINE GCC_IA32_ASM_FLAGS  = DEF(GCC_ASM_FLAGS) -m32 -Wa,--32 
-march=i386
+DEFINE GCC_X64_ASM_FLAGS   = DEF(GCC_ASM_FLAGS) -m64 -Wa,--64
+DEFINE GCC_ARM_ASM_FLAGS   = $(ARCHASM_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC_ASM_FLAGS) -mlittle-endian
+DEFINE GCC_AARCH64_ASM_FLAGS   = $(ARCHASM_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC_ASM_FLAGS) -mlittle-endian
+
 DEFINE GCC_PP_FLAGS= -E -x assembler-with-cpp -include 
$(DEST_DIR_DEBUG)/AutoGen.h
 DEFINE GCC_VFRPP_FLAGS = -x c -E -P -DVFRCOMPILE --include 
$(DEST_DIR_DEBUG)/$(MODULE_NAME)StrDefs.h
 DEFINE GCC_ASLPP_FLAGS = -x c -E -P
@@ -3856,25 +3862,6 @@ DEFINE GCC_IPF_RC_FLAGS= -I binary -O 
elf64-ia64-little   -B ia64
 DEFINE GCC_ARM_RC_FLAGS= -I binary -O elf32-littlearm -B arm   
  --rename-section .data=.hii
 DEFINE GCC_AARCH64_RC_FLAGS= -I binary -O elf64-littleaarch64 -B 
aarch64 --rename-section .data=.hii
 
-DEFINE GCC44_ASM_FLAGS   = DEF(GCC_ASM_FLAGS)
-
-DEFINE GCC45_ASM_FLAGS   = DEF(GCC44_ASM_FLAGS)
-
-DEFINE GCC46_ASM_FLAGS   = DEF(GCC45_ASM_FLAGS)
-DEFINE GCC46_ARM_ASM_FLAGS   = $(ARCHASM_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC_ASM_FLAGS) -mlittle-endian
-
-DEFINE GCC47_ASM_FLAGS   = DEF(GCC46_ASM_FLAGS)
-DEFINE GCC47_ARM_ASM_FLAGS   = DEF(GCC46_ARM_ASM_FLAGS)
-DEFINE GCC47_AARCH64_ASM_FLAGS   = $(ARCHASM_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC_ASM_FLAGS) -mlittle-endian
-
-DEFINE GCC48_ASM_FLAGS   = DEF(GCC47_ASM_FLAGS)
-DEFINE GCC48_ARM_ASM_FLAGS   = DEF(GCC47_ARM_ASM_FLAGS)
-DEFINE GCC48_AARCH64_ASM_FLAGS   = DEF(GCC47_AARCH64_ASM_FLAGS)
-
-DEFINE GCC49_ASM_FLAGS   = DEF(GCC48_ASM_FLAGS)
-DEFINE GCC49_ARM_ASM_FLAGS   = DEF(GCC48_ARM_ASM_FLAGS)
-DEFINE GCC49_AARCH64_ASM_FLAGS   = DEF(GCC48_AARCH64_ASM_FLAGS)
-
 

 #
 # Unix GCC And Intel Linux ACPI Compiler
@@ -4000,7 +3987,7 @@ DEFINE GCC49_AARCH64_ASM_FLAGS   = 
DEF(GCC48_AARCH64_ASM_FLAGS)
 
 *_GCC44_IA32_ASLCC_FLAGS  = DEF(GCC_ASLCC_FLAGS) -m32
 *_GCC44_IA32_ASLDLINK_FLAGS   = DEF(GCC_IA32_ASLDLINK_ELF_FLAGS)
-*_GCC44_IA32_ASM_FLAGS= DEF(GCC44_ASM_FLAGS) -m32 --32 -march=i386
+*_GCC44_IA32_ASM_FLAGS= DEF(GCC_IA32_ASM_FLAGS)
 *_GCC44_IA32_CC_FLAGS = DEF(GCC_IA32_CC_ELF_FLAGS) -Os
 *_GCC44_IA32_DLINK_FLAGS  = DEF(GCC_IA32_DLINK_ELF_FLAGS)
 *_GCC44_IA32_DLINK2_FLAGS = DEF(GCC_IA32_DLINK2_FLAGS)
@@ -4025,7 +4012,7 @@ DEFINE GCC49_AARCH64_ASM_FLAGS   = 
DEF(GCC48_AARCH64_ASM_FLAGS)
 
 *_GCC44_X64_ASLCC_FLAGS  = DEF(GCC_ASLCC_FLAGS) -m64
 *_GCC44_X64_ASLDLINK_FLAGS   = DEF(GCC_X64_ASLDLINK_ELF_FLAGS)
-*_GCC44_X64_ASM_FLAGS= DEF(GCC44_ASM_FLAGS) -m64 --64 -melf_x86_64
+*_GCC44_X64_ASM_FLAGS= DEF(GCC_X64_ASM_FLAGS) -melf_x86_64
 *_GCC44_X64_CC_FLAGS = DEF(GCC_X64_CC_ELF_FLAGS)
 *_GCC44_X64_DLINK_FLAGS  = DEF(GCC_X64_DLINK_ELF_FLAGS)
 *_GCC44_X64_DLINK2_FLAGS = DEF(GCC_X64_DLINK2_FLAGS)
@@ -4070,7 +4057,7 @@ DEFINE GCC49_AARCH64_ASM_FLAGS   = 
DEF(GCC48_AARCH64_ASM_FLAGS)
 
 *_GCC45_IA32_ASLCC_FLAGS  = DEF(GCC_ASLCC_FLAGS) -m32
 *_GCC45_IA32_ASLDLINK_FLAGS   = DEF(GCC_IA32_ASLDLINK_ELF_FLAGS)
-*_GCC45_IA32_ASM_FLAGS= DEF(GCC45_ASM_FLAGS) -m32 --32 -march=i386
+*_GCC45_IA32_ASM_FLAGS= DEF(GCC_IA32_ASM_FLAGS)
 *_GCC45_IA32_CC_FLAGS = DEF(GCC_IA32_CC_ELF_FLAGS) -Os
 *_GCC45_IA32_DLINK_FLAGS  = DEF(GCC_IA32_DLINK_ELF_FLAGS)
 *_GCC45_IA32_DLINK2_FLAGS = DEF(GCC_IA32_DLINK2_FLAGS)
@@ -4095,7 +4082,7 @@ DEFINE GCC49_AARCH64_ASM_FLAGS   = 
DEF(GCC48_AARCH64_ASM_FLAGS)
 
 *_GCC45_X64_ASLCC_FLAGS  = DEF(GCC_ASLCC_FLAGS) -m64
 *_GCC45_X64_ASLDLINK_FLAGS   = DEF(GCC_X64_ASLDLINK_ELF_FLAGS)
-*_GCC45_X64_ASM_FLAGS= DEF(GCC45_ASM_FLAGS) -m64 --64 -melf_x86_64
+*_GCC45_X64_ASM_FLAGS= DEF(GCC_X64_ASM_FLAGS) -melf_x86_64
 *_GCC45_X64_CC_FLAGS = 

[edk2] [PATCH v2 15/16] BaseTools GCC: align ELFGCC with GCC4x toolchains

2015-08-17 Thread Ard Biesheuvel
This aligns the remaining configuration options for ELFGCC with
the other ELF based toolchains.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
 BaseTools/Conf/tools_def.template | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index a21b44ffd413..a29591793e07 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -4873,8 +4873,8 @@ RELEASE_CLANG35_AARCH64_CC_FLAGS = 
DEF(CLANG35_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS)
 *_ELFGCC_IA32_DLINK2_FLAGS  = DEF(GCC_IA32_DLINK2_FLAGS)
 *_ELFGCC_IA32_ASLDLINK_FLAGS= DEF(GCC_IA32_ASLDLINK_ELF_FLAGS)
 *_ELFGCC_IA32_ASM_FLAGS = DEF(GCC_IA32_ASM_FLAGS)
-*_ELFGCC_IA32_PP_FLAGS  = -m32 -E -x assembler-with-cpp -include 
$(DEST_DIR_DEBUG)/AutoGen.h
-*_ELFGCC_IA32_VFRPP_FLAGS   = -x c -E -P -DVFRCOMPILE --include 
$(DEST_DIR_DEBUG)/$(MODULE_NAME)StrDefs.h
+*_ELFGCC_IA32_PP_FLAGS  = DEF(GCC_PP_FLAGS)
+*_ELFGCC_IA32_VFRPP_FLAGS   = DEF(GCC_VFRPP_FLAGS)
 *_ELFGCC_IA32_RC_FLAGS  = DEF(GCC_IA32_RC_FLAGS)
 *_ELFGCC_IA32_OBJCOPY_FLAGS =
 *_ELFGCC_IA32_NASM_FLAGS= -f elf32
@@ -4899,8 +4899,8 @@ RELEASE_CLANG35_AARCH64_CC_FLAGS = 
DEF(CLANG35_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS)
 *_ELFGCC_X64_DLINK2_FLAGS  = DEF(GCC_X64_DLINK2_FLAGS)
 *_ELFGCC_X64_ASLDLINK_FLAGS= DEF(GCC_X64_ASLDLINK_ELF_FLAGS)
 *_ELFGCC_X64_ASM_FLAGS = DEF(GCC_X64_ASM_FLAGS)
-*_ELFGCC_X64_PP_FLAGS  = -E -x assembler-with-cpp -include 
$(DEST_DIR_DEBUG)/AutoGen.h
-*_ELFGCC_X64_VFRPP_FLAGS   = -x c -E -P -DVFRCOMPILE --include 
$(DEST_DIR_DEBUG)/$(MODULE_NAME)StrDefs.h
+*_ELFGCC_X64_PP_FLAGS  = DEF(GCC_PP_FLAGS)
+*_ELFGCC_X64_VFRPP_FLAGS   = DEF(GCC_VFRPP_FLAGS)
 *_ELFGCC_X64_RC_FLAGS  = DEF(GCC_X64_RC_FLAGS)
 *_ELFGCC_X64_NASM_FLAGS= -f elf64
 
@@ -4918,12 +4918,12 @@ RELEASE_CLANG35_AARCH64_CC_FLAGS = 
DEF(CLANG35_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS)
 *_ELFGCC_IPF_VFRPP_PATH   = DEF(ELFGCC_BIN)/gcc
 *_ELFGCC_IPF_RC_PATH  = DEF(ELFGCC_BIN)/objcopy
 
-*_ELFGCC_IPF_CC_FLAGS = -Os -fshort-wchar -Wall -Werror -c 
-include AutoGen.h -D_EFI_P64
-*_ELFGCC_IPF_DLINK_FLAGS  = -nostdlib --shared --entry 
$(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map
+*_ELFGCC_IPF_CC_FLAGS = DEF(GCC_IPF_CC_FLAGS)
 *_ELFGCC_IPF_SLINK_FLAGS  =
-*_ELFGCC_IPF_ASM_FLAGS= -c -x assembler -imacros 
$(DEST_DIR_DEBUG)/AutoGen.h
-*_ELFGCC_IPF_PP_FLAGS = -E -x assembler-with-cpp -include 
$(DEST_DIR_DEBUG)/AutoGen.h
-*_ELFGCC_IPF_VFRPP_FLAGS  = -x c -E -P -DVFRCOMPILE --include 
$(DEST_DIR_DEBUG)/$(MODULE_NAME)StrDefs.h
+*_ELFGCC_IPF_DLINK_FLAGS  = DEF(GCC_IPF_DLINK_FLAGS)
+*_ELFGCC_IPF_ASM_FLAGS= DEF(GCC_ASM_FLAGS)
+*_ELFGCC_IPF_PP_FLAGS = DEF(GCC_PP_FLAGS)
+*_ELFGCC_IPF_VFRPP_FLAGS  = DEF(GCC_VFRPP_FLAGS)
 *_ELFGCC_IPF_RC_FLAGS = DEF(GCC_IPF_RC_FLAGS)
 
 

-- 
1.9.1

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


[edk2] [PATCH v2 16/16] OvmfPkg/X64: enable 4 KB alignment for DXE_RUNTIME modules

2015-08-17 Thread Ard Biesheuvel
This enables 4 KB section alignment for DXE_RUNTIME modules, for
ELF based toolchains and for the UNIXGCC PE/COFF toolchain.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
 OvmfPkg/OvmfPkgX64.dsc | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index b72eaa92f82e..817c381f4913 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -48,6 +48,13 @@ [BuildOptions]
   INTEL:*_*_X64_GENFW_FLAGS = --keepexceptiontable
 !endif
 
+[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
+!if $(TOOLCHAIN) == UNIXGCC
+  GCC:*_*_X64_DLINK_FLAGS = --section-alignment 0x1000 --file-alignment 0x1000
+!else
+  GCC:*_*_X64_DLINK_FLAGS = -z common-page-size=0x1000
+!endif
+
 

 #
 # SKU Identification section - list of all SKU IDs supported by this Platform.
-- 
1.9.1

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


[edk2] [Patch 8/8] MdeModulePkg: Add GraphicsOutputDxe driver

2015-08-17 Thread Ruiyu Ni
The driver consumes the GraphicsInfo HOB and produces GOP protocol.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni ruiyu...@intel.com
Cc: Feng Tian feng.t...@intel.com
---
 MdeModulePkg/MdeModulePkg.dsc  |   4 +
 .../Console/GraphicsOutputDxe/ComponentName.c  | 190 ++
 .../Console/GraphicsOutputDxe/GraphicsOutput.c | 659 +
 .../Console/GraphicsOutputDxe/GraphicsOutput.h |  53 ++
 .../GraphicsOutputDxe/GraphicsOutputDxe.inf|  57 ++
 5 files changed, 963 insertions(+)
 create mode 100644 
MdeModulePkg/Universal/Console/GraphicsOutputDxe/ComponentName.c
 create mode 100644 
MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutput.c
 create mode 100644 
MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutput.h
 create mode 100644 
MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutputDxe.inf

diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
index e475dc1..cd3e21e 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -290,6 +290,10 @@
   MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
   MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
   MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
+  MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutputDxe.inf {
+LibraryClasses
+  BltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
+  }
   MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
   MdeModulePkg/Universal/DebugPortDxe/DebugPortDxe.inf
   MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
diff --git a/MdeModulePkg/Universal/Console/GraphicsOutputDxe/ComponentName.c 
b/MdeModulePkg/Universal/Console/GraphicsOutputDxe/ComponentName.c
new file mode 100644
index 000..9f1c79d
--- /dev/null
+++ b/MdeModulePkg/Universal/Console/GraphicsOutputDxe/ComponentName.c
@@ -0,0 +1,190 @@
+/** @file
+  UEFI Component Name(2) protocol implementation for the generic GOP driver.
+  
+Copyright (c) 2015, Intel Corporation. All rights reserved.BR
+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 PiDxe.h
+#include Library/UefiLib.h
+
+extern EFI_COMPONENT_NAME_PROTOCOL  mGraphicsOutputComponentName;
+extern EFI_COMPONENT_NAME2_PROTOCOL mGraphicsOutputComponentName2;
+
+//
+// Driver name table for GraphicsOutput module.
+// It is shared by the implementation of ComponentName  ComponentName2 
Protocol.
+//
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_UNICODE_STRING_TABLE 
mGraphicsOutputDriverNameTable[] = {
+  {
+eng;en,
+LGeneric Graphics Output Driver
+  },
+  {
+NULL,
+NULL
+  }
+};
+
+/**
+  Retrieves a Unicode string that is the user readable name of the driver.
+
+  This function retrieves the user readable name of a driver in the form of a
+  Unicode string. If the driver specified by This has a user readable name in
+  the language specified by Language, then a pointer to the driver name is
+  returned in DriverName, and EFI_SUCCESS is returned. If the driver specified
+  by This does not support the language specified by Language,
+  then EFI_UNSUPPORTED is returned.
+
+  @param  This[in]  A pointer to the EFI_COMPONENT_NAME2_PROTOCOL 
or
+EFI_COMPONENT_NAME_PROTOCOL instance.
+
+  @param  Language[in]  A pointer to a Null-terminated ASCII string
+array indicating the language. This is the
+language of the driver name that the caller is
+requesting, and it must match one of the
+languages specified in SupportedLanguages. The
+number of languages supported by a driver is up
+to the driver writer. Language is specified
+in RFC 4646 or ISO 639-2 language code format.
+
+  @param  DriverName[out]   A pointer to the Unicode string to return.
+This Unicode string is the name of the
+driver specified by This in the language
+specified by Language.
+
+  @retval EFI_SUCCESS   The Unicode string for the Driver specified by
+This and the language specified by Language was
+returned in DriverName.
+
+  @retval EFI_INVALID_PARAMETER Language is NULL.
+
+  @retval EFI_INVALID_PARAMETER DriverName is NULL.
+
+  @retval EFI_UNSUPPORTED   

[edk2] [Patch 0/8] Move BltLib to MdeModulePkg and create GraphicsOutputDxe driver

2015-08-17 Thread Ruiyu Ni
The patch serials refined the BltLib and moved it to MdeModulePkg.
Based on the BltLib, the patch created the GraphicsOutputDxe driver which 
consumes
the GraphicsInfo HOB.

Ruiyu Ni (8):
  OptionRomPkg: Refine FrameBufferBltLib to use UINT8* instead of VOID*
  OptionRomPkg: Add video move test case to BltLibSample application
  OptionRomPkg: Fix a bug in BltVideoToVideo operation
  OptionRomPkg: Remove BltLibGetSizes() interface from BltLib
  OptionRomPkg/OvmfPkg: BltLib API refinement
  OptionRomPkg/OvmfPkg: Remove BltLib::BltConfigure API
  MdeModulePkg: Move BltLib from OptionRomPkg to MdeModulePkg
  MdeModulePkg: Add GraphicsOutputDxe driver

 MdeModulePkg/Include/Library/BltLib.h  | 147 
 .../Library/FrameBufferBltLib/FrameBufferBltLib.c  | 573 
 .../FrameBufferBltLib/FrameBufferBltLib.inf|  33 +
 MdeModulePkg/Library/GopBltLib/GopBltLib.c | 324 +
 MdeModulePkg/Library/GopBltLib/GopBltLib.inf   |  35 +
 MdeModulePkg/MdeModulePkg.dec  |   4 +
 MdeModulePkg/MdeModulePkg.dsc  |   6 +
 .../Console/GraphicsOutputDxe/ComponentName.c  | 190 ++
 .../Console/GraphicsOutputDxe/GraphicsOutput.c | 659 ++
 .../Console/GraphicsOutputDxe/GraphicsOutput.h |  53 ++
 .../GraphicsOutputDxe/GraphicsOutputDxe.inf|  57 ++
 .../Application/BltLibSample/BltLibSample.c| 148 ++--
 .../Application/BltLibSample/BltLibSample.inf  |   4 +-
 OptionRomPkg/Include/Library/BltLib.h  | 259 ---
 .../Library/FrameBufferBltLib/FrameBufferBltLib.c  | 750 -
 .../FrameBufferBltLib/FrameBufferBltLib.inf|  35 -
 OptionRomPkg/Library/GopBltLib/GopBltLib.c | 455 -
 OptionRomPkg/Library/GopBltLib/GopBltLib.inf   |  37 -
 OptionRomPkg/OptionRomPkg.dsc  |   7 +-
 OvmfPkg/OvmfPkgIa32.dsc|   2 +-
 OvmfPkg/OvmfPkgIa32X64.dsc |   2 +-
 OvmfPkg/OvmfPkgX64.dsc |   2 +-
 OvmfPkg/QemuVideoDxe/Gop.c |  84 ++-
 OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf  |   3 +-
 24 files changed, 2242 insertions(+), 1627 deletions(-)
 create mode 100644 MdeModulePkg/Include/Library/BltLib.h
 create mode 100644 MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
 create mode 100644 MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
 create mode 100644 MdeModulePkg/Library/GopBltLib/GopBltLib.c
 create mode 100644 MdeModulePkg/Library/GopBltLib/GopBltLib.inf
 create mode 100644 
MdeModulePkg/Universal/Console/GraphicsOutputDxe/ComponentName.c
 create mode 100644 
MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutput.c
 create mode 100644 
MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutput.h
 create mode 100644 
MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutputDxe.inf
 delete mode 100644 OptionRomPkg/Include/Library/BltLib.h
 delete mode 100644 OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
 delete mode 100644 OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
 delete mode 100644 OptionRomPkg/Library/GopBltLib/GopBltLib.c
 delete mode 100644 OptionRomPkg/Library/GopBltLib/GopBltLib.inf

-- 
1.9.5.msysgit.1

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


[edk2] [Patch 4/8] OptionRomPkg: Remove BltLibGetSizes() interface from BltLib

2015-08-17 Thread Ruiyu Ni
Since the library consumes the GOP mode structure which is provided by
library caller, library caller doesn't need to ask the library about
the screen resolution, instead, it can directly get from the GOP mode
structure.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni ruiyu...@intel.com
Cc: Laszlo Ersek ler...@redhat.com
Cc: Jordan Justen jordan.l.jus...@intel.com
---
 .../Application/BltLibSample/BltLibSample.c| 64 ++
 OptionRomPkg/Include/Library/BltLib.h  | 20 +--
 .../Library/FrameBufferBltLib/FrameBufferBltLib.c  | 27 -
 OptionRomPkg/Library/GopBltLib/GopBltLib.c | 32 +--
 4 files changed, 32 insertions(+), 111 deletions(-)

diff --git a/OptionRomPkg/Application/BltLibSample/BltLibSample.c 
b/OptionRomPkg/Application/BltLibSample/BltLibSample.c
index 09fea62..3409b2c 100644
--- a/OptionRomPkg/Application/BltLibSample/BltLibSample.c
+++ b/OptionRomPkg/Application/BltLibSample/BltLibSample.c
@@ -68,7 +68,8 @@ Rand32 (
 
 VOID
 TestFills (
-  VOID
+  UINT32 HorizontalResolution,
+  UINT32 VerticalResolution
   )
 {
   EFI_GRAPHICS_OUTPUT_BLT_PIXEL  Color;
@@ -77,20 +78,17 @@ TestFills (
   UINTN  Y;
   UINTN  W;
   UINTN  H;
-  UINTN  Width;
-  UINTN  Height;
 
-  BltLibGetSizes (Width, Height);
   for (Loop = 0; Loop  1; Loop++) {
-W = Width - (Rand32 () % Width);
-H = Height - (Rand32 () % Height);
-if (W != Width) {
-  X = Rand32 () % (Width - W);
+W = HorizontalResolution - (Rand32 () % HorizontalResolution);
+H = VerticalResolution - (Rand32 () % VerticalResolution);
+if (W != HorizontalResolution) {
+  X = Rand32 () % (HorizontalResolution - W);
 } else {
   X = 0;
 }
-if (H != Height) {
-  Y = Rand32 () % (Height - H);
+if (H != VerticalResolution) {
+  Y = Rand32 () % (VerticalResolution - H);
 } else {
   Y = 0;
 }
@@ -102,23 +100,21 @@ TestFills (
 
 VOID
 TestColor1 (
-  VOID
+  UINT32 HorizontalResolution,
+  UINT32 VerticalResolution
   )
 {
   EFI_GRAPHICS_OUTPUT_BLT_PIXEL  Color;
   UINTN  X;
   UINTN  Y;
-  UINTN  Width;
-  UINTN  Height;
 
-  BltLibGetSizes (Width, Height);
   *(UINT32*) (Color) = 0;
 
-  for (Y = 0; Y  Height; Y++) {
-for (X = 0; X  Width; X++) {
-  Color.Red =   (UINT8) ((X * 0x100) / Width);
-  Color.Green = (UINT8) ((Y * 0x100) / Height);
-  Color.Blue =  (UINT8) ((Y * 0x100) / Height);
+  for (Y = 0; Y  VerticalResolution; Y++) {
+for (X = 0; X  HorizontalResolution; X++) {
+  Color.Red =   (UINT8) ((X * 0x100) / HorizontalResolution);
+  Color.Green = (UINT8) ((Y * 0x100) / VerticalResolution);
+  Color.Blue =  (UINT8) ((Y * 0x100) / VerticalResolution);
   BltLibVideoFill (Color, X, Y, 1, 1);
 }
   }
@@ -180,43 +176,43 @@ GetTriColor (
 
 VOID
 TestColor (
-  VOID
+  UINT32 HorizontalResolution,
+  UINT32 VerticalResolution
   )
 {
   EFI_GRAPHICS_OUTPUT_BLT_PIXEL  Color;
   UINTN  X, Y;
   UINTN  X1, X2, X3;
   UINTN  Y1, Y2;
-  UINTN  LineWidth, TriWidth, ScreenWidth;
-  UINTN  TriHeight, ScreenHeight;
+  UINTN  LineWidth, TriWidth;
+  UINTN  TriHeight;
   UINT32 ColorDist;
 
-  BltLibGetSizes (ScreenWidth, ScreenHeight);
   *(UINT32*) (Color) = 0;
-  BltLibVideoFill (Color, 0, 0, ScreenWidth, ScreenHeight);
+  BltLibVideoFill (Color, 0, 0, HorizontalResolution, VerticalResolution);
 
   TriWidth = (UINTN) DivU64x32 (
-   MultU64x32 (11547005, (UINT32) ScreenHeight),
+   MultU64x32 (11547005, (UINT32) VerticalResolution),
1000
);
   TriHeight = (UINTN) DivU64x32 (
-MultU64x32 (8660254, (UINT32) ScreenWidth),
+MultU64x32 (8660254, (UINT32) HorizontalResolution),
 1000
 );
-  if (TriWidth  ScreenWidth) {
+  if (TriWidth  HorizontalResolution) {
 DEBUG ((EFI_D_INFO, TriWidth at %d was too big\n, TriWidth));
-TriWidth = ScreenWidth;
-  } else if (TriHeight  ScreenHeight) {
+TriWidth = HorizontalResolution;
+  } else if (TriHeight  VerticalResolution) {
 DEBUG ((EFI_D_INFO, TriHeight at %d was too big\n, TriHeight));
-TriHeight = ScreenHeight;
+TriHeight = VerticalResolution;
   }
 
   DEBUG ((EFI_D_INFO, Triangle Width: %d; Height: %d\n, TriWidth, 
TriHeight));
 
-  X1 = (ScreenWidth - TriWidth) / 

[edk2] [PATCH v2 11/16] BaseTools GCC: unify all IA32 and X64 [AS]DLINK[2] flags for ELF based GCC

2015-08-17 Thread Ard Biesheuvel
GCC4x and ELFGCC are both ELF based GCC toolchains, so there is no
justification for allowing the command line options to deviate.
So align them.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
 BaseTools/Conf/tools_def.template | 128 
 1 file changed, 52 insertions(+), 76 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 620770cae9c7..b92bd4c16a0e 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -3821,18 +3821,28 @@ DEFINE GCC_AARCH64_CC_FLAGS= 
DEF(GCC_ALL_ELF_CC_FLAGS) -Os -mcmodel=larg
 DEFINE GCC_DLINK2_FLAGS_COMMON = 
--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
 DEFINE GCC_ALL_DLINK_FLAGS = -nostdlib
 DEFINE GCC_ALL_DLINK_PE_FLAGS  = DEF(GCC_ALL_DLINK_FLAGS) --pie
+DEFINE GCC_ALL_DLINK_ELF_FLAGS = DEF(GCC_ALL_DLINK_FLAGS) -n -q 
--gc-sections -z common-page-size=0x20
 DEFINE GCC_IA32_X64_DLINK_PE_FLAGS = DEF(GCC_ALL_DLINK_PE_FLAGS) --gc-sections
+DEFINE GCC_IA32_X64_DLINK_ELF_FLAGS= DEF(GCC_ALL_DLINK_ELF_FLAGS) --entry 
$(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map
 DEFINE GCC_IA32_DLINK_PE_FLAGS = DEF(GCC_IA32_X64_DLINK_PE_FLAGS) --entry 
_$(IMAGE_ENTRY_POINT) --file-alignment 0x20 --section-alignment 0x20 -Map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map
+DEFINE GCC_IA32_DLINK_ELF_FLAGS= DEF(GCC_IA32_X64_DLINK_ELF_FLAGS) -m 
elf_i386 --oformat=elf32-i386
 DEFINE GCC_X64_DLINK_PE_FLAGS  = DEF(GCC_IA32_X64_DLINK_PE_FLAGS) --entry 
$(IMAGE_ENTRY_POINT) --file-alignment 0x20 --section-alignment 0x20 -Map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map
+DEFINE GCC_X64_DLINK_ELF_FLAGS = DEF(GCC_IA32_X64_DLINK_ELF_FLAGS) 
-melf_x86_64 --oformat=elf64-x86-64
 DEFINE GCC_ARM_AARCH64_DLINK_COMMON= --emit-relocs -nostdlib --gc-sections -u 
$(IMAGE_ENTRY_POINT) -e $(IMAGE_ENTRY_POINT) -Map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map
 DEFINE GCC_ARM_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) 
-Ttext=0x0
 DEFINE GCC_AARCH64_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) -z 
common-page-size=0x20
 DEFINE GCC_IA32_ASLDLINK_PE_FLAGS  = DEF(GCC_IA32_X64_DLINK_PE_FLAGS) --entry 
_ReferenceAcpiTable -u _$(IMAGE_ENTRY_POINT)
 DEFINE GCC_X64_ASLDLINK_PE_FLAGS   = DEF(GCC_IA32_X64_DLINK_PE_FLAGS) --entry 
ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT)
+DEFINE GCC_IA32_ASLDLINK_ELF_FLAGS = DEF(GCC_ALL_DLINK_ELF_FLAGS) --entry 
ReferenceAcpiTable -u ReferenceAcpiTable -melf_i386
+DEFINE GCC_X64_ASLDLINK_ELF_FLAGS  = DEF(GCC_ALL_DLINK_ELF_FLAGS) --entry 
ReferenceAcpiTable -u ReferenceAcpiTable -melf_x86_64
 DEFINE GCC_ARM_ASLDLINK_FLAGS  = DEF(GCC_ARM_DLINK_FLAGS) --entry 
ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT)
 DEFINE GCC_AARCH64_ASLDLINK_FLAGS  = DEF(GCC_AARCH64_DLINK_FLAGS) --entry 
ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT)
 DEFINE GCC_IPF_DLINK_FLAGS = -nostdlib -O2 --gc-sections --dll -static 
--entry $(IMAGE_ENTRY_POINT) --undefined $(IMAGE_ENTRY_POINT) -Map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map
 
+DEFINE GCC_ALL_DLINK2_FLAGS= 
--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
+DEFINE GCC_IA32_DLINK2_FLAGS   = --defsym=PECOFF_HEADER_SIZE=0x220 
DEF(GCC_ALL_DLINK2_FLAGS)
+DEFINE GCC_X64_DLINK2_FLAGS= --defsym=PECOFF_HEADER_SIZE=0x228 
DEF(GCC_ALL_DLINK2_FLAGS)
+
 DEFINE GCC_IPF_OBJCOPY_FLAGS   = -I elf64-ia64-little -O efi-bsdrv-ia64
 DEFINE GCC_IPF_SYMRENAME_FLAGS = --redefine-sym memcpy=CopyMem
 DEFINE GCC_ASM_FLAGS   = -c -x assembler -imacros 
$(DEST_DIR_DEBUG)/AutoGen.h
@@ -3846,40 +3856,16 @@ DEFINE GCC_IPF_RC_FLAGS= -I binary -O 
elf64-ia64-little   -B ia64
 DEFINE GCC_ARM_RC_FLAGS= -I binary -O elf32-littlearm -B arm   
  --rename-section .data=.hii
 DEFINE GCC_AARCH64_RC_FLAGS= -I binary -O elf64-littleaarch64 -B 
aarch64 --rename-section .data=.hii
 
-DEFINE GCC44_IA32_X64_DLINK_COMMON   = -nostdlib -n -q --gc-sections -z 
common-page-size=0x20
-DEFINE GCC44_IA32_X64_ASLDLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_COMMON) 
--entry ReferenceAcpiTable -u ReferenceAcpiTable
-DEFINE GCC44_IA32_X64_DLINK_FLAGS= DEF(GCC44_IA32_X64_DLINK_COMMON) 
--entry $(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map
-DEFINE GCC44_IA32_DLINK2_FLAGS   = --defsym=PECOFF_HEADER_SIZE=0x220 
DEF(GCC_DLINK2_FLAGS_COMMON)
-DEFINE GCC44_X64_DLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_FLAGS)  
-melf_x86_64 --oformat=elf64-x86-64
-DEFINE GCC44_X64_DLINK2_FLAGS= --defsym=PECOFF_HEADER_SIZE=0x228 
DEF(GCC_DLINK2_FLAGS_COMMON)
 DEFINE GCC44_ASM_FLAGS   = DEF(GCC_ASM_FLAGS)
 
-DEFINE GCC45_IA32_X64_DLINK_COMMON   = DEF(GCC44_IA32_X64_DLINK_COMMON)
-DEFINE GCC45_IA32_X64_ASLDLINK_FLAGS = DEF(GCC44_IA32_X64_ASLDLINK_FLAGS)
-DEFINE GCC45_IA32_X64_DLINK_FLAGS= DEF(GCC44_IA32_X64_DLINK_FLAGS)
-DEFINE GCC45_IA32_DLINK2_FLAGS   = 

[edk2] [PATCH v2 02/16] BaseTools/GenFv: use PE/COFF virtual section size if raw size is larger

2015-08-17 Thread Ard Biesheuvel
When copying the relocated sections into the FFS file, we need to
take care that we don't overrun the end of the file. Since, unlike
the virtual size, the PE/COFF raw section size must be a multiple of
the file alignment, which means its size may exceed the virtual size.
So use the minimum of the two.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
 BaseTools/Source/C/GenFv/GenFvInternalLib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Source/C/GenFv/GenFvInternalLib.c 
b/BaseTools/Source/C/GenFv/GenFvInternalLib.c
index 6d2d5d1f8c67..b0135bf0155a 100644
--- a/BaseTools/Source/C/GenFv/GenFvInternalLib.c
+++ b/BaseTools/Source/C/GenFv/GenFvInternalLib.c
@@ -3329,7 +3329,7 @@ Returns:
   CopyMem (
 (UINT8 *) CurrentPe32Section.Pe32Section + CurSecHdrSize + 
SectionHeader-PointerToRawData, 
 (VOID*) (UINTN) (ImageContext.ImageAddress + 
SectionHeader-VirtualAddress), 
-SectionHeader-SizeOfRawData
+MIN(SectionHeader-SizeOfRawData, SectionHeader-Misc.VirtualSize)
 );
 }
 
-- 
1.9.1

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


[edk2] [PATCH v2 10/16] BaseTools GCC: remove GCC 4.9 specific linker alignment override

2015-08-17 Thread Ard Biesheuvel
If any version of GCC emits any object whose actual alignment
requirement exceeds 32 bytes, this actual alignment value will
automatically become the PE/COFF section alignment value after
PE/COFF conversion, now that GenFw propagates the alignment of
the ELF input sections. So there is no longer a need for special
treatment of GCC 4.9, and the linker command line override can
be removed.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
 BaseTools/Conf/tools_def.template | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index c7e4e0ac5867..620770cae9c7 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -3908,11 +3908,11 @@ DEFINE GCC48_AARCH64_DLINK2_FLAGS= 
DEF(GCC47_AARCH64_DLINK2_FLAGS)
 DEFINE GCC48_ARM_ASLDLINK_FLAGS  = DEF(GCC47_ARM_ASLDLINK_FLAGS)
 DEFINE GCC48_AARCH64_ASLDLINK_FLAGS  = DEF(GCC47_AARCH64_ASLDLINK_FLAGS)
 
-DEFINE GCC49_IA32_X64_DLINK_COMMON   = -nostdlib -n -q --gc-sections -z 
common-page-size=0x40
-DEFINE GCC49_IA32_X64_ASLDLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_COMMON) 
--entry ReferenceAcpiTable -u ReferenceAcpiTable
-DEFINE GCC49_IA32_X64_DLINK_FLAGS= DEF(GCC49_IA32_X64_DLINK_COMMON) 
--entry $(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map
+DEFINE GCC49_IA32_X64_DLINK_COMMON   = DEF(GCC48_IA32_X64_DLINK_COMMON)
+DEFINE GCC49_IA32_X64_ASLDLINK_FLAGS = DEF(GCC48_IA32_X64_ASLDLINK_FLAGS)
+DEFINE GCC49_IA32_X64_DLINK_FLAGS= DEF(GCC48_IA32_X64_DLINK_FLAGS)
 DEFINE GCC49_IA32_DLINK2_FLAGS   = DEF(GCC48_IA32_DLINK2_FLAGS)
-DEFINE GCC49_X64_DLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_FLAGS)  
-melf_x86_64 --oformat=elf64-x86-64
+DEFINE GCC49_X64_DLINK_FLAGS = DEF(GCC48_X64_DLINK_FLAGS)
 DEFINE GCC49_X64_DLINK2_FLAGS= DEF(GCC48_X64_DLINK2_FLAGS)
 DEFINE GCC49_ASM_FLAGS   = DEF(GCC48_ASM_FLAGS)
 DEFINE GCC49_ARM_ASM_FLAGS   = DEF(GCC48_ARM_ASM_FLAGS)
-- 
1.9.1

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


[edk2] [PATCH v2 12/16] BaseTools GCC: unify ARM and AARCH64 GCC compiler flags

2015-08-17 Thread Ard Biesheuvel
Use the same GCC options for compiling regardless of the exact
GCC version. The only option that needs special treatment is
-mno-unaligned-access on ARM, which is not supported by upstream
GCC v4.6. Everything else can be shared by all versions.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
 BaseTools/Conf/tools_def.template | 39 
 1 file changed, 16 insertions(+), 23 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index b92bd4c16a0e..8161660ca839 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -3815,8 +3815,8 @@ DEFINE GCC_IA32_CC_ELF_FLAGS   = 
DEF(GCC_ALL_ELF_CC_FLAGS) -m32 -malign-doub
 DEFINE GCC_X64_CC_PE_FLAGS = DEF(GCC_ALL_PE_CC_FLAGS) -Os 
-mno-red-zone -mno-stack-arg-probe
 DEFINE GCC_X64_CC_ELF_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -m64 
-fno-stack-protector -DEFIAPI=__attribute__((ms_abi)) -DNO_BUILTIN_VA_FUNCS 
-mno-red-zone -mcmodel=large -fno-asynchronous-unwind-tables
 DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -Os 
-minline-int-divide-min-latency
-DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -Os 
-mword-relocations -mlittle-endian -mabi=aapcs -mapcs -fno-short-enums 
-save-temps -fsigned-char -ffunction-sections -fdata-sections 
-fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft
-DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -Os 
-mcmodel=large -mlittle-endian -fno-short-enums -save-temps -fverbose-asm 
-fsigned-char  -ffunction-sections -fdata-sections -fomit-frame-pointer 
-fno-builtin -Wno-address -fno-asynchronous-unwind-tables
+DEFINE GCC_ARM_CC_FLAGS= $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC_ALL_ELF_CC_FLAGS) -Os -mword-relocations -mlittle-endian -mabi=aapcs 
-mapcs -fno-short-enums -save-temps -fsigned-char -ffunction-sections 
-fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft 
-fstack-protector
+DEFINE GCC_AARCH64_CC_FLAGS= $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC_ALL_ELF_CC_FLAGS) -Os -mcmodel=large -mlittle-endian -fno-short-enums 
-save-temps -fverbose-asm -fsigned-char  -ffunction-sections -fdata-sections 
-fomit-frame-pointer -fno-builtin -Wno-address -fno-asynchronous-unwind-tables
 
 DEFINE GCC_DLINK2_FLAGS_COMMON = 
--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
 DEFINE GCC_ALL_DLINK_FLAGS = -nostdlib
@@ -3862,15 +3862,12 @@ DEFINE GCC45_ASM_FLAGS   = 
DEF(GCC44_ASM_FLAGS)
 
 DEFINE GCC46_ASM_FLAGS   = DEF(GCC45_ASM_FLAGS)
 DEFINE GCC46_ARM_ASM_FLAGS   = $(ARCHASM_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC_ASM_FLAGS) -mlittle-endian
-DEFINE GCC46_ARM_CC_FLAGS= $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC_ARM_CC_FLAGS) -fstack-protector
 DEFINE GCC46_ARM_DLINK_FLAGS = DEF(GCC_ARM_DLINK_FLAGS) 
--oformat=elf32-littlearm
 DEFINE GCC46_ARM_ASLDLINK_FLAGS  = DEF(GCC_ARM_ASLDLINK_FLAGS) 
--oformat=elf32-littlearm
 
 DEFINE GCC47_ASM_FLAGS   = DEF(GCC46_ASM_FLAGS)
 DEFINE GCC47_ARM_ASM_FLAGS   = DEF(GCC46_ARM_ASM_FLAGS)
 DEFINE GCC47_AARCH64_ASM_FLAGS   = $(ARCHASM_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC_ASM_FLAGS) -mlittle-endian
-DEFINE GCC47_ARM_CC_FLAGS= DEF(GCC46_ARM_CC_FLAGS) 
-mno-unaligned-access
-DEFINE GCC47_AARCH64_CC_FLAGS= $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC_AARCH64_CC_FLAGS)
 DEFINE GCC47_ARM_DLINK_FLAGS = DEF(GCC46_ARM_DLINK_FLAGS)
 DEFINE GCC47_AARCH64_DLINK_FLAGS = DEF(GCC_AARCH64_DLINK_FLAGS)
 DEFINE GCC47_AARCH64_DLINK2_FLAGS= --defsym=PECOFF_HEADER_SIZE=0x228 
DEF(GCC_DLINK2_FLAGS_COMMON)
@@ -3880,8 +3877,6 @@ DEFINE GCC47_AARCH64_ASLDLINK_FLAGS  = 
DEF(GCC_AARCH64_ASLDLINK_FLAGS)
 DEFINE GCC48_ASM_FLAGS   = DEF(GCC47_ASM_FLAGS)
 DEFINE GCC48_ARM_ASM_FLAGS   = DEF(GCC47_ARM_ASM_FLAGS)
 DEFINE GCC48_AARCH64_ASM_FLAGS   = DEF(GCC47_AARCH64_ASM_FLAGS)
-DEFINE GCC48_ARM_CC_FLAGS= DEF(GCC47_ARM_CC_FLAGS)
-DEFINE GCC48_AARCH64_CC_FLAGS= DEF(GCC47_AARCH64_CC_FLAGS)
 DEFINE GCC48_ARM_DLINK_FLAGS = DEF(GCC47_ARM_DLINK_FLAGS)
 DEFINE GCC48_AARCH64_DLINK_FLAGS = DEF(GCC47_AARCH64_DLINK_FLAGS)
 DEFINE GCC48_AARCH64_DLINK2_FLAGS= DEF(GCC47_AARCH64_DLINK2_FLAGS)
@@ -3891,8 +3886,6 @@ DEFINE GCC48_AARCH64_ASLDLINK_FLAGS  = 
DEF(GCC47_AARCH64_ASLDLINK_FLAGS)
 DEFINE GCC49_ASM_FLAGS   = DEF(GCC48_ASM_FLAGS)
 DEFINE GCC49_ARM_ASM_FLAGS   = DEF(GCC48_ARM_ASM_FLAGS)
 DEFINE GCC49_AARCH64_ASM_FLAGS   = DEF(GCC48_AARCH64_ASM_FLAGS)
-DEFINE GCC49_ARM_CC_FLAGS= DEF(GCC48_ARM_CC_FLAGS)
-DEFINE GCC49_AARCH64_CC_FLAGS= DEF(GCC48_AARCH64_CC_FLAGS)
 DEFINE GCC49_ARM_DLINK_FLAGS = DEF(GCC48_ARM_DLINK_FLAGS)
 DEFINE GCC49_AARCH64_DLINK_FLAGS = DEF(GCC48_AARCH64_DLINK_FLAGS)
 DEFINE GCC49_AARCH64_DLINK2_FLAGS= DEF(GCC48_AARCH64_DLINK2_FLAGS)
@@ -4224,8 

[edk2] [PATCH v2 05/16] BaseTools GCC: refactor tools_def internal GCC defines for CC flags

2015-08-17 Thread Ard Biesheuvel
As a first step towards disentangling the arguments passed to the
various flavors of GCC we support, refactor the CC flags so that
we distinguish more clearly between toolchains that generate PE/COFF
directly (for IA32 and X86 only) and toolchains that generate ELF
only.

Note that this does not modify the options that are ultimately passed to
GCC, although it does deduplicate ARM and AARCH64 since those toolchains
were passing both GCC_ALL_CC_FLAGS and GCC44_ALL_CC_FLAGS, which overlap
to a great extent.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
 BaseTools/Conf/tools_def.template | 35 ++--
 1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index af9e99f5647c..8b03f3081669 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -3807,12 +3807,14 @@ NOOPT_DDK3790xASL_IPF_DLINK_FLAGS= /NOLOGO 
/NODEFAULTLIB /LTCG /DLL /OPT:REF
 DEBUG_*_*_OBJCOPY_ADDDEBUGFLAG = 
--add-gnu-debuglink=$(DEBUG_DIR)/$(MODULE_NAME).debug
 RELEASE_*_*_OBJCOPY_ADDDEBUGFLAG   =
 
-DEFINE GCC_ALL_CC_FLAGS= -g -Os -fshort-wchar -fno-strict-aliasing 
-Wall -Werror -Wno-array-bounds -c -include AutoGen.h
-DEFINE GCC_IA32_CC_FLAGS   = DEF(GCC_ALL_CC_FLAGS) -m32 -malign-double 
-freorder-blocks -freorder-blocks-and-partition -O2 -mno-stack-arg-probe
-DEFINE GCC_X64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mno-red-zone 
-Wno-address -mno-stack-arg-probe
-DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) 
-minline-int-divide-min-latency
-DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mword-relocations 
-mlittle-endian -mabi=aapcs -mapcs -fno-short-enums -save-temps -fsigned-char 
-ffunction-sections -fdata-sections -fomit-frame-pointer -Wno-address -mthumb 
-mfloat-abi=soft
-DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mcmodel=large 
-mlittle-endian -fno-short-enums -save-temps -fverbose-asm -fsigned-char  
-ffunction-sections -fdata-sections -fomit-frame-pointer -fno-builtin 
-Wno-address -fno-asynchronous-unwind-tables
+DEFINE GCC_ALL_CC_FLAGS= -g -fshort-wchar -fno-strict-aliasing 
-Wall -Werror -Wno-array-bounds -Wno-address -Wno-unused-but-set-variable -c 
-include AutoGen.h
+DEFINE GCC_ALL_PE_CC_FLAGS = DEF(GCC_ALL_CC_FLAGS)
+DEFINE GCC_ALL_ELF_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -ffunction-sections 
-fdata-sections -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
+DEFINE GCC_IA32_CC_PE_FLAGS= DEF(GCC_ALL_PE_CC_FLAGS) -m32 
-malign-double -freorder-blocks -freorder-blocks-and-partition -O2 
-mno-stack-arg-probe
+DEFINE GCC_X64_CC_PE_FLAGS = DEF(GCC_ALL_PE_CC_FLAGS) -Os 
-mno-red-zone -mno-stack-arg-probe
+DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -Os 
-minline-int-divide-min-latency
+DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -Os 
-mword-relocations -mlittle-endian -mabi=aapcs -mapcs -fno-short-enums 
-save-temps -fsigned-char -ffunction-sections -fdata-sections 
-fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft
+DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -Os 
-mcmodel=large -mlittle-endian -fno-short-enums -save-temps -fverbose-asm 
-fsigned-char  -ffunction-sections -fdata-sections -fomit-frame-pointer 
-fno-builtin -Wno-address -fno-asynchronous-unwind-tables
 DEFINE GCC_DLINK_FLAGS_COMMON  = -nostdlib --pie
 DEFINE GCC_DLINK2_FLAGS_COMMON = 
--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
 DEFINE GCC_IA32_X64_DLINK_COMMON   = DEF(GCC_DLINK_FLAGS_COMMON) --gc-sections
@@ -3837,9 +3839,8 @@ DEFINE GCC_IPF_RC_FLAGS= -I binary -O 
elf64-ia64-little   -B ia64
 DEFINE GCC_ARM_RC_FLAGS= -I binary -O elf32-littlearm -B arm   
  --rename-section .data=.hii
 DEFINE GCC_AARCH64_RC_FLAGS= -I binary -O elf64-littleaarch64 -B 
aarch64 --rename-section .data=.hii
 
-DEFINE GCC44_ALL_CC_FLAGS= -g -fshort-wchar -fno-strict-aliasing 
-Wall -Werror -Wno-array-bounds -Wno-address -Wno-unused-but-set-variable 
-ffunction-sections -fdata-sections -c -include AutoGen.h 
-DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
-DEFINE GCC44_IA32_CC_FLAGS   = DEF(GCC44_ALL_CC_FLAGS) -m32 
-malign-double -fno-stack-protector -D EFI32 -fno-asynchronous-unwind-tables
-DEFINE GCC44_X64_CC_FLAGS= DEF(GCC44_ALL_CC_FLAGS) -m64 
-fno-stack-protector -DEFIAPI=__attribute__((ms_abi)) -DNO_BUILTIN_VA_FUNCS 
-mno-red-zone -Wno-address -mcmodel=large -fno-asynchronous-unwind-tables
+DEFINE GCC44_IA32_CC_FLAGS   = DEF(GCC_ALL_ELF_CC_FLAGS) -m32 
-malign-double -fno-stack-protector -D EFI32 -fno-asynchronous-unwind-tables
+DEFINE GCC44_X64_CC_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -m64 
-fno-stack-protector -DEFIAPI=__attribute__((ms_abi)) -DNO_BUILTIN_VA_FUNCS 
-mno-red-zone -Wno-address -mcmodel=large 

[edk2] [PATCH v2 09/16] BaseTools GCC: don't set .data address explicitly

2015-08-17 Thread Ard Biesheuvel
When a section's start address is set explicitly and is not aligned to
the alignment of its contents, the linker will rearrange them so that
everything lines up provided that the misalignment is preserved.

Since we cannot do the same in PE/COFF, don't set the .data start
address directly, but advance the location pointer by the same amount.
This way, the linker will be free to choose the start address, but will
ultimately end up using the exact same value.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
 BaseTools/Scripts/GccBase.lds | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/BaseTools/Scripts/GccBase.lds b/BaseTools/Scripts/GccBase.lds
index 4ee6d998532c..eef8325c96a5 100644
--- a/BaseTools/Scripts/GccBase.lds
+++ b/BaseTools/Scripts/GccBase.lds
@@ -44,7 +44,8 @@ SECTIONS {
* between these sections is the same in the ELF and the PE/COFF versions of
* this binary.
*/
-  .data ALIGN(ALIGNOF(.text)) : ALIGN(CONSTANT(COMMONPAGESIZE)) {
+  . = ALIGN(ALIGNOF(.text));
+  .data : ALIGN(CONSTANT(COMMONPAGESIZE)) {
 *(.data .data.* .gnu.linkonce.d.*)
 *(.bss .bss.* *COM*)
   }
-- 
1.9.1

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


[edk2] [PATCH v2 13/16] BaseTools GCC: unify ARM and AARCH64 DLINK flags for all GCC versions

2015-08-17 Thread Ard Biesheuvel
Use the same GCC options for linking regardless of the exact
GCC version.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
 BaseTools/Conf/tools_def.template | 63 +++-
 1 file changed, 23 insertions(+), 40 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 8161660ca839..18ae92623e1c 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -3818,7 +3818,6 @@ DEFINE GCC_IPF_CC_FLAGS= 
DEF(GCC_ALL_ELF_CC_FLAGS) -Os -minline-int-
 DEFINE GCC_ARM_CC_FLAGS= $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC_ALL_ELF_CC_FLAGS) -Os -mword-relocations -mlittle-endian -mabi=aapcs 
-mapcs -fno-short-enums -save-temps -fsigned-char -ffunction-sections 
-fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft 
-fstack-protector
 DEFINE GCC_AARCH64_CC_FLAGS= $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC_ALL_ELF_CC_FLAGS) -Os -mcmodel=large -mlittle-endian -fno-short-enums 
-save-temps -fverbose-asm -fsigned-char  -ffunction-sections -fdata-sections 
-fomit-frame-pointer -fno-builtin -Wno-address -fno-asynchronous-unwind-tables
 
-DEFINE GCC_DLINK2_FLAGS_COMMON = 
--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
 DEFINE GCC_ALL_DLINK_FLAGS = -nostdlib
 DEFINE GCC_ALL_DLINK_PE_FLAGS  = DEF(GCC_ALL_DLINK_FLAGS) --pie
 DEFINE GCC_ALL_DLINK_ELF_FLAGS = DEF(GCC_ALL_DLINK_FLAGS) -n -q 
--gc-sections -z common-page-size=0x20
@@ -3828,20 +3827,21 @@ DEFINE GCC_IA32_DLINK_PE_FLAGS = 
DEF(GCC_IA32_X64_DLINK_PE_FLAGS) --entry _$
 DEFINE GCC_IA32_DLINK_ELF_FLAGS= DEF(GCC_IA32_X64_DLINK_ELF_FLAGS) -m 
elf_i386 --oformat=elf32-i386
 DEFINE GCC_X64_DLINK_PE_FLAGS  = DEF(GCC_IA32_X64_DLINK_PE_FLAGS) --entry 
$(IMAGE_ENTRY_POINT) --file-alignment 0x20 --section-alignment 0x20 -Map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map
 DEFINE GCC_X64_DLINK_ELF_FLAGS = DEF(GCC_IA32_X64_DLINK_ELF_FLAGS) 
-melf_x86_64 --oformat=elf64-x86-64
-DEFINE GCC_ARM_AARCH64_DLINK_COMMON= --emit-relocs -nostdlib --gc-sections -u 
$(IMAGE_ENTRY_POINT) -e $(IMAGE_ENTRY_POINT) -Map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map
-DEFINE GCC_ARM_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) 
-Ttext=0x0
-DEFINE GCC_AARCH64_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) -z 
common-page-size=0x20
+DEFINE GCC_ARM_AARCH64_DLINK_FLAGS = --emit-relocs -nostdlib --gc-sections -u 
$(IMAGE_ENTRY_POINT) -e $(IMAGE_ENTRY_POINT) -Map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map
+DEFINE GCC_ARM_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_FLAGS) 
-Ttext=0x0 --oformat=elf32-littlearm
+DEFINE GCC_AARCH64_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_FLAGS) -z 
common-page-size=0x20
 DEFINE GCC_IA32_ASLDLINK_PE_FLAGS  = DEF(GCC_IA32_X64_DLINK_PE_FLAGS) --entry 
_ReferenceAcpiTable -u _$(IMAGE_ENTRY_POINT)
 DEFINE GCC_X64_ASLDLINK_PE_FLAGS   = DEF(GCC_IA32_X64_DLINK_PE_FLAGS) --entry 
ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT)
 DEFINE GCC_IA32_ASLDLINK_ELF_FLAGS = DEF(GCC_ALL_DLINK_ELF_FLAGS) --entry 
ReferenceAcpiTable -u ReferenceAcpiTable -melf_i386
 DEFINE GCC_X64_ASLDLINK_ELF_FLAGS  = DEF(GCC_ALL_DLINK_ELF_FLAGS) --entry 
ReferenceAcpiTable -u ReferenceAcpiTable -melf_x86_64
-DEFINE GCC_ARM_ASLDLINK_FLAGS  = DEF(GCC_ARM_DLINK_FLAGS) --entry 
ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT)
+DEFINE GCC_ARM_ASLDLINK_FLAGS  = DEF(GCC_ARM_DLINK_FLAGS) --entry 
ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) --oformat=elf32-littlearm
 DEFINE GCC_AARCH64_ASLDLINK_FLAGS  = DEF(GCC_AARCH64_DLINK_FLAGS) --entry 
ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT)
 DEFINE GCC_IPF_DLINK_FLAGS = -nostdlib -O2 --gc-sections --dll -static 
--entry $(IMAGE_ENTRY_POINT) --undefined $(IMAGE_ENTRY_POINT) -Map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map
 
 DEFINE GCC_ALL_DLINK2_FLAGS= 
--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
 DEFINE GCC_IA32_DLINK2_FLAGS   = --defsym=PECOFF_HEADER_SIZE=0x220 
DEF(GCC_ALL_DLINK2_FLAGS)
 DEFINE GCC_X64_DLINK2_FLAGS= --defsym=PECOFF_HEADER_SIZE=0x228 
DEF(GCC_ALL_DLINK2_FLAGS)
+DEFINE GCC_AARCH64_DLINK2_FLAGS= --defsym=PECOFF_HEADER_SIZE=0x228 
DEF(GCC_ALL_DLINK2_FLAGS)
 
 DEFINE GCC_IPF_OBJCOPY_FLAGS   = -I elf64-ia64-little -O efi-bsdrv-ia64
 DEFINE GCC_IPF_SYMRENAME_FLAGS = --redefine-sym memcpy=CopyMem
@@ -3862,35 +3862,18 @@ DEFINE GCC45_ASM_FLAGS   = 
DEF(GCC44_ASM_FLAGS)
 
 DEFINE GCC46_ASM_FLAGS   = DEF(GCC45_ASM_FLAGS)
 DEFINE GCC46_ARM_ASM_FLAGS   = $(ARCHASM_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC_ASM_FLAGS) -mlittle-endian
-DEFINE GCC46_ARM_DLINK_FLAGS = DEF(GCC_ARM_DLINK_FLAGS) 
--oformat=elf32-littlearm
-DEFINE GCC46_ARM_ASLDLINK_FLAGS  = DEF(GCC_ARM_ASLDLINK_FLAGS) 
--oformat=elf32-littlearm
 
 DEFINE GCC47_ASM_FLAGS   = DEF(GCC46_ASM_FLAGS)
 DEFINE GCC47_ARM_ASM_FLAGS   = DEF(GCC46_ARM_ASM_FLAGS)
 DEFINE GCC47_AARCH64_ASM_FLAGS   = 

[edk2] [PATCH v2 00/16] unify GCC command line options

2015-08-17 Thread Ard Biesheuvel
This got a bit out of hand after I noticed the ELFGCC and UNIXGCC
toolchains that needed some tlc as well.

Anyway, this series aims to refactor the toolchains definitions for
UNIXGCC, GCC44, GCC45, GCC46, GCC47, GCC48, GCC49, CLANG35, ELFGCC,
CYGGCC and CYGGCCxASL so that they share as much of the settings as
possible. Currently, there is very little coordination between these,
which means for instance that the 4 KB alignment feature is only supported
on GCC4x at the moment.

The primary difference between these toolchains is that GCC4x and ELFGCC
are entirely ELF based, whereas the other are PE/COFF based (but only when
building for IA32 or X64)

Note that this series does not remove any toolchains, nor should it result
in major changes in the command lines that are passed to the various tools.
However, things may be reordered, and (in case of ELFGCC), missing functionality
such as increased section alignment has been added so there are some changes
there.

Patch #1 is a patch from Scott that I am reposting, but updated to cover
AARCH64 as well.

Patch #2 fixes a problem in the GenFv tool where it may access unallocated
memory while rebasing the FFS when using large section and file alignment.

Patch #3 removes an unused DEFINE from tools_def

Patch #4 moved some warning flags that were applied to GCC4x 4.6 and up to
all GCC versions.

Patch #5 is the first big refactor patch that introduces PE and ELF variants
for some CC flags.

Patch #6 unifies the IA32 and X64 CC flags for all toolchains listed above.

Patch #7 fixes the issue mentioned by Bill where the underscore decoration
is erroneously applied on X64 as well.

Patch #8 is the second refactor the introduces PE and ELF variants for the
various DLINK flags.

Patch #9 changes the way the start of the .data section is set in GccBase.lds.
This is needed since the linker will reorganize the internal layout of the .data
section rather than update its start address to ensure all objects that it
contains meet their respective alignments, even if the start address is not
aligned to the max value of all inputs.

Patch #10 removes the explicit 64 byte alignment applied to GCC 4.9. The latest
GenFw and linker script propagate the alignment automatically, i.e., if objects
with such alignment requirement are present, GCC will set the ELF header
accordingly, and this value will be used for the PE/COFF section alignment
as well.

Patch #11 unifies the IA32 and X64 linker flags for all toolchains listed above.

Patch #12 unifies the ARM and AARCH64 CC flags, i.e., it removes all the
redundant definitions.

Patch #13 as #11 but for the linker.

Patch #14 unifies the ASM flags for all archs.

Patch #15 brings the remaining configuration options of ELFGCC in line with
the GCC4x series.

Patch #16 is a PoC that allows Ovmf/X64 to be built with 4 KB section alignment
for DXE_RUNTIME modules using UNIXGCC and ELFGCC, as is required to support
the properties table memprotection feature.

Changes since v1:
- added patch #9 to address the IA32 and X86 failures on 4.9 reported by Scott
- don't pass -mno-unaligned-access to ARM 4.6 compiler (Scott)
- improved wording of commit messages of various patches
- rebased onto latest upstream, which includes a fix related to the ARM 4.6
  issue mentioned above

Branch can be found here
https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/unify-gcc-v2

Ard Biesheuvel (15):
  BaseTools/GenFv: use PE/COFF virtual section size if raw size is
larger
  BaseTools GCC: remove unused definition of GCC_WINDRES_FLAGS
  BaseTools GCC: merge warning flags for all GCC versions
  BaseTools GCC: refactor tools_def internal GCC defines for CC flags
  BaseTools GCC: unify all IA32 and X64 CC flags for ELF based GCC
  BaseTools GCC: use leading underscore for symbol names where
appropriate
  BaseTools GCC: refactor tools_def internal GCC defines for [AS]DLINK
  BaseTools GCC: don't set .data address explicitly
  BaseTools GCC: remove GCC 4.9 specific linker alignment override
  BaseTools GCC: unify all IA32 and X64 [AS]DLINK[2] flags for ELF based
GCC
  BaseTools GCC: unify ARM and AARCH64 GCC compiler flags
  BaseTools GCC: unify ARM and AARCH64 DLINK flags for all GCC versions
  BaseTools GCC: unify ASM flags for all GCC versions
  BaseTools GCC: align ELFGCC with GCC4x toolchains
  OvmfPkg/X64: enable 4 KB alignment for DXE_RUNTIME modules

Scott Duplichan (1):
  BaseTools GCC: Fix GCC49 build failure

 BaseTools/Conf/tools_def.template   | 412 
 BaseTools/Scripts/GccBase.lds   |   3 +-
 BaseTools/Source/C/GenFv/GenFvInternalLib.c |   2 +-
 OvmfPkg/OvmfPkgX64.dsc  |   7 +
 4 files changed, 183 insertions(+), 241 deletions(-)

-- 
1.9.1

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


Re: [edk2] [Patch 0/8] Move BltLib to MdeModulePkg and create GraphicsOutputDxe driver

2015-08-17 Thread Ni, Ruiyu
The code was also checked in to below URL:
https://github.com/niruiyu/edk2/tree/GOP


-Original Message-
From: Ni, Ruiyu 
Sent: Monday, August 17, 2015 9:45 PM
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu ruiyu...@intel.com
Subject: [Patch 0/8] Move BltLib to MdeModulePkg and create GraphicsOutputDxe 
driver

The patch serials refined the BltLib and moved it to MdeModulePkg.
Based on the BltLib, the patch created the GraphicsOutputDxe driver which 
consumes
the GraphicsInfo HOB.

Ruiyu Ni (8):
  OptionRomPkg: Refine FrameBufferBltLib to use UINT8* instead of VOID*
  OptionRomPkg: Add video move test case to BltLibSample application
  OptionRomPkg: Fix a bug in BltVideoToVideo operation
  OptionRomPkg: Remove BltLibGetSizes() interface from BltLib
  OptionRomPkg/OvmfPkg: BltLib API refinement
  OptionRomPkg/OvmfPkg: Remove BltLib::BltConfigure API
  MdeModulePkg: Move BltLib from OptionRomPkg to MdeModulePkg
  MdeModulePkg: Add GraphicsOutputDxe driver

 MdeModulePkg/Include/Library/BltLib.h  | 147 
 .../Library/FrameBufferBltLib/FrameBufferBltLib.c  | 573 
 .../FrameBufferBltLib/FrameBufferBltLib.inf|  33 +
 MdeModulePkg/Library/GopBltLib/GopBltLib.c | 324 +
 MdeModulePkg/Library/GopBltLib/GopBltLib.inf   |  35 +
 MdeModulePkg/MdeModulePkg.dec  |   4 +
 MdeModulePkg/MdeModulePkg.dsc  |   6 +
 .../Console/GraphicsOutputDxe/ComponentName.c  | 190 ++
 .../Console/GraphicsOutputDxe/GraphicsOutput.c | 659 ++
 .../Console/GraphicsOutputDxe/GraphicsOutput.h |  53 ++
 .../GraphicsOutputDxe/GraphicsOutputDxe.inf|  57 ++
 .../Application/BltLibSample/BltLibSample.c| 148 ++--
 .../Application/BltLibSample/BltLibSample.inf  |   4 +-
 OptionRomPkg/Include/Library/BltLib.h  | 259 ---
 .../Library/FrameBufferBltLib/FrameBufferBltLib.c  | 750 -
 .../FrameBufferBltLib/FrameBufferBltLib.inf|  35 -
 OptionRomPkg/Library/GopBltLib/GopBltLib.c | 455 -
 OptionRomPkg/Library/GopBltLib/GopBltLib.inf   |  37 -
 OptionRomPkg/OptionRomPkg.dsc  |   7 +-
 OvmfPkg/OvmfPkgIa32.dsc|   2 +-
 OvmfPkg/OvmfPkgIa32X64.dsc |   2 +-
 OvmfPkg/OvmfPkgX64.dsc |   2 +-
 OvmfPkg/QemuVideoDxe/Gop.c |  84 ++-
 OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf  |   3 +-
 24 files changed, 2242 insertions(+), 1627 deletions(-)
 create mode 100644 MdeModulePkg/Include/Library/BltLib.h
 create mode 100644 MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
 create mode 100644 MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
 create mode 100644 MdeModulePkg/Library/GopBltLib/GopBltLib.c
 create mode 100644 MdeModulePkg/Library/GopBltLib/GopBltLib.inf
 create mode 100644 
MdeModulePkg/Universal/Console/GraphicsOutputDxe/ComponentName.c
 create mode 100644 
MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutput.c
 create mode 100644 
MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutput.h
 create mode 100644 
MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutputDxe.inf
 delete mode 100644 OptionRomPkg/Include/Library/BltLib.h
 delete mode 100644 OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
 delete mode 100644 OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
 delete mode 100644 OptionRomPkg/Library/GopBltLib/GopBltLib.c
 delete mode 100644 OptionRomPkg/Library/GopBltLib/GopBltLib.inf

-- 
1.9.5.msysgit.1

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


[edk2] [Patch 5/8] OptionRomPkg/OvmfPkg: BltLib API refinement

2015-08-17 Thread Ruiyu Ni
API removal:
  BltLibVideoToBltBuffer
  BltLibBufferToVideo
  BltLibGopBlt

API rename:
  BltLibVideoToBltBufferEx - BltVideoToBuffer
  BltLibBufferToVideoEx - BltBufferToVideo
  BltLibVideoToVideo - BltVideoToVideo
  BltLibVideoFill - BltVideoFill
  BltLibConfigure - BltConfigure

The 3 APIs in above are removed because their functionality overlaps with
the other APIs.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni ruiyu...@intel.com
Cc: Laszlo Ersek ler...@redhat.com
Cc: Jordan Justen jordan.l.jus...@intel.com
---
 .../Application/BltLibSample/BltLibSample.c|  16 +-
 OptionRomPkg/Include/Library/BltLib.h  | 101 +
 .../Library/FrameBufferBltLib/FrameBufferBltLib.c  | 168 +
 OptionRomPkg/Library/GopBltLib/GopBltLib.c | 138 +
 OvmfPkg/QemuVideoDxe/Gop.c |  73 ++---
 5 files changed, 74 insertions(+), 422 deletions(-)

diff --git a/OptionRomPkg/Application/BltLibSample/BltLibSample.c 
b/OptionRomPkg/Application/BltLibSample/BltLibSample.c
index 3409b2c..333b054 100644
--- a/OptionRomPkg/Application/BltLibSample/BltLibSample.c
+++ b/OptionRomPkg/Application/BltLibSample/BltLibSample.c
@@ -93,7 +93,7 @@ TestFills (
   Y = 0;
 }
 *(UINT32*) (Color) = Rand32 ()  0xff;
-BltLibVideoFill (Color, X, Y, W, H);
+BltVideoFill (Color, X, Y, W, H);
   }
 }
 
@@ -115,7 +115,7 @@ TestColor1 (
   Color.Red =   (UINT8) ((X * 0x100) / HorizontalResolution);
   Color.Green = (UINT8) ((Y * 0x100) / VerticalResolution);
   Color.Blue =  (UINT8) ((Y * 0x100) / VerticalResolution);
-  BltLibVideoFill (Color, X, Y, 1, 1);
+  BltVideoFill (Color, X, Y, 1, 1);
 }
   }
 }
@@ -189,7 +189,7 @@ TestColor (
   UINT32 ColorDist;
 
   *(UINT32*) (Color) = 0;
-  BltLibVideoFill (Color, 0, 0, HorizontalResolution, VerticalResolution);
+  BltVideoFill (Color, 0, 0, HorizontalResolution, VerticalResolution);
 
   TriWidth = (UINTN) DivU64x32 (
MultU64x32 (11547005, (UINT32) VerticalResolution),
@@ -231,7 +231,7 @@ TestColor (
   ColorDist = Uint32Dist(X3 - X, Y1 - Y);
   Color.Blue = GetTriColor (ColorDist, TriWidth);
 
-  BltLibVideoFill (Color, X, Y, 1, 1);
+  BltVideoFill (Color, X, Y, 1, 1);
 }
   }
 
@@ -255,14 +255,14 @@ TestMove1 (
   Width = 100;
   Height = 20;
 
-  BltLibVideoFill (Black, 0, 0, HorizontalResolution, VerticalResolution);
+  BltVideoFill (Black, 0, 0, HorizontalResolution, VerticalResolution);
 
   *(UINT32 *) Blue = 0;
   Blue.Blue = 0xff;
-  BltLibVideoFill (Blue, 0, 0, Width, Height);
+  BltVideoFill (Blue, 0, 0, Width, Height);
 
   for (X = 1, Y = 1; X  HorizontalResolution  Y  VerticalResolution; X++, 
Y++) {
-BltLibVideoToVideo (X - 1, Y - 1, X, Y, Width, Height);
+BltVideoToVideo (X - 1, Y - 1, X, Y, Width, Height);
 gBS-Stall (100);
   }
   gBS-Stall (1000 * 1000 * 2);
@@ -298,7 +298,7 @@ UefiMain (
 return Status;
   }
 
-  Status = BltLibConfigure (
+  Status = BltConfigure (
  (VOID*)(UINTN) Gop-Mode-FrameBufferBase,
  Gop-Mode-Info
  );
diff --git a/OptionRomPkg/Include/Library/BltLib.h 
b/OptionRomPkg/Include/Library/BltLib.h
index 8bc5d91..230dac2 100644
--- a/OptionRomPkg/Include/Library/BltLib.h
+++ b/OptionRomPkg/Include/Library/BltLib.h
@@ -30,48 +30,11 @@
 **/
 EFI_STATUS
 EFIAPI
-BltLibConfigure (
+BltConfigure (
   IN  VOID *FrameBuffer,
   IN  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *FrameBufferInfo
   );
 
-
-/**
-  Performs a UEFI Graphics Output Protocol Blt operation.
-
-  @param[in,out] BltBuffer - The data to transfer to screen
-  @param[in] BltOperation  - The operation to perform
-  @param[in] SourceX   - The X coordinate of the source for 
BltOperation
-  @param[in] SourceY   - The Y coordinate of the source for 
BltOperation
-  @param[in] DestinationX  - The X coordinate of the destination for 
BltOperation
-  @param[in] DestinationY  - The Y coordinate of the destination for 
BltOperation
-  @param[in] Width - The width of a rectangle in the blt rectangle 
in pixels
-  @param[in] Height- The height of a rectangle in the blt 
rectangle in pixels
-  @param[in] Delta - Not used for EfiBltVideoFill and 
EfiBltVideoToVideo operation.
- If a Delta of 0 is used, the entire BltBuffer 
will be operated on.
- If a subrectangle of the BltBuffer is used, 
then Delta represents
- the number of bytes in a row of the BltBuffer.
-
-  @retval  EFI_DEVICE_ERROR - A hardware error occured
-  @retval  EFI_INVALID_PARAMETER - Invalid parameter passed in
-  @retval  EFI_SUCCESS - Blt operation success
-
-**/
-EFI_STATUS
-EFIAPI
-BltLibGopBlt (
-  IN OUT EFI_GRAPHICS_OUTPUT_BLT_PIXEL  *BltBuffer, OPTIONAL
-  IN 

[edk2] [Patch 3/8] OptionRomPkg: Fix a bug in BltVideoToVideo operation

2015-08-17 Thread Ruiyu Ni
The bug can be reproduced by the BltLibSample application TestMove1() test case.
The old code cannot handle the case when the source and destination video is
overlapped.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni ruiyu...@intel.com
Cc: Laszlo Ersek ler...@redhat.com
Cc: Jordan Justen jordan.l.jus...@intel.com
---
 OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c 
b/OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
index 7fd8196..49ef568 100644
--- a/OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
+++ b/OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
@@ -694,6 +694,11 @@ BltLibVideoToVideo (
 
   LineStride = mBltLibWidthInBytes;
   if (Destination  Source) {
+//
+// Copy from last line to avoid source is corrupted by copying
+//
+Source += Height * LineStride;
+Destination += Height * LineStride;
 LineStride = -LineStride;
   }
 
-- 
1.9.5.msysgit.1

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


[edk2] [Patch 6/8] OptionRomPkg/OvmfPkg: Remove BltLib::BltConfigure API

2015-08-17 Thread Ruiyu Ni
The BltConfigure() API caches the video frame buffer meta data which
forbids the library to be implemented to support re-entry.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni ruiyu...@intel.com
Cc: Laszlo Ersek ler...@redhat.com
Cc: Jordan Justen jordan.l.jus...@intel.com
---
 .../Application/BltLibSample/BltLibSample.c| 129 +++---
 OptionRomPkg/Include/Library/BltLib.h  | 151 +++---
 .../Library/FrameBufferBltLib/FrameBufferBltLib.c  | 514 +++--
 OptionRomPkg/Library/GopBltLib/GopBltLib.c | 289 ++--
 OvmfPkg/QemuVideoDxe/Gop.c |  13 +-
 5 files changed, 576 insertions(+), 520 deletions(-)

diff --git a/OptionRomPkg/Application/BltLibSample/BltLibSample.c 
b/OptionRomPkg/Application/BltLibSample/BltLibSample.c
index 333b054..3c7e392 100644
--- a/OptionRomPkg/Application/BltLibSample/BltLibSample.c
+++ b/OptionRomPkg/Application/BltLibSample/BltLibSample.c
@@ -18,6 +18,7 @@
 #include Library/UefiLib.h
 #include Library/UefiApplicationEntryPoint.h
 #include Library/UefiBootServicesTableLib.h
+#include Library/MemoryAllocationLib.h
 
 
 UINT64
@@ -68,8 +69,8 @@ Rand32 (
 
 VOID
 TestFills (
-  UINT32 HorizontalResolution,
-  UINT32 VerticalResolution
+  IN  VOID *FrameBuffer,
+  IN  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *FrameBufferInfo
   )
 {
   EFI_GRAPHICS_OUTPUT_BLT_PIXEL  Color;
@@ -79,44 +80,45 @@ TestFills (
   UINTN  W;
   UINTN  H;
 
-  for (Loop = 0; Loop  1; Loop++) {
-W = HorizontalResolution - (Rand32 () % HorizontalResolution);
-H = VerticalResolution - (Rand32 () % VerticalResolution);
-if (W != HorizontalResolution) {
-  X = Rand32 () % (HorizontalResolution - W);
+  for (Loop = 0; Loop  1000; Loop++) {
+W = FrameBufferInfo-HorizontalResolution - (Rand32 () % 
FrameBufferInfo-HorizontalResolution);
+H = FrameBufferInfo-VerticalResolution - (Rand32 () % 
FrameBufferInfo-VerticalResolution);
+if (W != FrameBufferInfo-HorizontalResolution) {
+  X = Rand32 () % (FrameBufferInfo-HorizontalResolution - W);
 } else {
   X = 0;
 }
-if (H != VerticalResolution) {
-  Y = Rand32 () % (VerticalResolution - H);
+if (H != FrameBufferInfo-VerticalResolution) {
+  Y = Rand32 () % (FrameBufferInfo-VerticalResolution - H);
 } else {
   Y = 0;
 }
 *(UINT32*) (Color) = Rand32 ()  0xff;
-BltVideoFill (Color, X, Y, W, H);
+BltVideoFill (FrameBuffer, FrameBufferInfo, Color, X, Y, W, H);
   }
 }
 
 
 VOID
 TestColor1 (
-  UINT32 HorizontalResolution,
-  UINT32 VerticalResolution
+  IN  VOID *FrameBuffer,
+  IN  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *FrameBufferInfo
   )
 {
-  EFI_GRAPHICS_OUTPUT_BLT_PIXEL  Color;
+  EFI_GRAPHICS_OUTPUT_BLT_PIXEL  *BltBuffer;
   UINTN  X;
   UINTN  Y;
 
-  *(UINT32*) (Color) = 0;
+  BltBuffer = AllocatePool (sizeof (*BltBuffer) * 
FrameBufferInfo-HorizontalResolution);
+  ASSERT (BltBuffer != NULL);
 
-  for (Y = 0; Y  VerticalResolution; Y++) {
-for (X = 0; X  HorizontalResolution; X++) {
-  Color.Red =   (UINT8) ((X * 0x100) / HorizontalResolution);
-  Color.Green = (UINT8) ((Y * 0x100) / VerticalResolution);
-  Color.Blue =  (UINT8) ((Y * 0x100) / VerticalResolution);
-  BltVideoFill (Color, X, Y, 1, 1);
+  for (Y = 0; Y  FrameBufferInfo-VerticalResolution; Y++) {
+for (X = 0; X  FrameBufferInfo-HorizontalResolution; X++) {
+  BltBuffer[X].Red =   (UINT8) ((X * 0x100) / 
FrameBufferInfo-HorizontalResolution);
+  BltBuffer[X].Green = (UINT8) ((Y * 0x100) / 
FrameBufferInfo-VerticalResolution);
+  BltBuffer[X].Blue =  (UINT8) ((Y * 0x100) / 
FrameBufferInfo-VerticalResolution);
 }
+BltBufferToVideo (FrameBuffer, FrameBufferInfo, BltBuffer, 0, 0, 0, Y, 
FrameBufferInfo-HorizontalResolution, 1, 0);
   }
 }
 
@@ -176,8 +178,8 @@ GetTriColor (
 
 VOID
 TestColor (
-  UINT32 HorizontalResolution,
-  UINT32 VerticalResolution
+  IN  VOID *FrameBuffer,
+  IN  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *FrameBufferInfo
   )
 {
   EFI_GRAPHICS_OUTPUT_BLT_PIXEL  Color;
@@ -187,34 +189,38 @@ TestColor (
   UINTN  LineWidth, TriWidth;
   UINTN  TriHeight;
   UINT32 ColorDist;
+  EFI_GRAPHICS_OUTPUT_BLT_PIXEL  *BltBuffer;
 
   *(UINT32*) (Color) = 0;
-  BltVideoFill (Color, 0, 0, HorizontalResolution, VerticalResolution);
+  BltVideoFill (FrameBuffer, FrameBufferInfo, Color, 0, 0, 
FrameBufferInfo-HorizontalResolution, FrameBufferInfo-VerticalResolution);
 
   TriWidth = (UINTN) DivU64x32 (
-   MultU64x32 (11547005, (UINT32) 

[edk2] [PATCH v2 03/16] BaseTools GCC: remove unused definition of GCC_WINDRES_FLAGS

2015-08-17 Thread Ard Biesheuvel
The definition of GCC_WINDRES_FLAGS is never referenced again
so remove it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
 BaseTools/Conf/tools_def.template | 1 -
 1 file changed, 1 deletion(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index c35fd6ce0dd2..506e734b6895 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -3831,7 +3831,6 @@ DEFINE GCC_PP_FLAGS= -E -x 
assembler-with-cpp -include $(DEST_DI
 DEFINE GCC_VFRPP_FLAGS = -x c -E -P -DVFRCOMPILE --include 
$(DEST_DIR_DEBUG)/$(MODULE_NAME)StrDefs.h
 DEFINE GCC_ASLPP_FLAGS = -x c -E -P
 DEFINE GCC_ASLCC_FLAGS = -x c
-DEFINE GCC_WINDRES_FLAGS   = -J rc -O coff
 DEFINE GCC_IA32_RC_FLAGS   = -I binary -O elf32-i386  -B i386  
  --rename-section .data=.hii
 DEFINE GCC_X64_RC_FLAGS= -I binary -O elf64-x86-64-B i386  
  --rename-section .data=.hii
 DEFINE GCC_IPF_RC_FLAGS= -I binary -O elf64-ia64-little   -B ia64  
  --rename-section .data=.hii
-- 
1.9.1

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


Re: [edk2] Help debugging PEIM on Minnowboard Max

2015-08-17 Thread Eric Wittmayer
Hi Feng,
   Now I understand the concept.  I was expecting that PEIM would already be
available for the Minnowboard Max.  Is Usb in the PEI phase not supported in
Minnowboard?

From my digging in the code today, it seems to enable the xhci controller,
it's PCI BAR needs to be set and enabled for memory access.  I found memory
base addresses for some devices in
Vlv2DeviceRefCodePkg\ValleyView2Soc\NorthCluster\Include\PlatformBaseAddress
es.h but not for XHCI.  From looking at the Atom E3800 datasheet, the xhci
memory base doesn't have a fixed location so I believe I need to pick an
unused range in the Low MMIO space to set as the xhci BAR. 

If you or someone else on the list can recommend a different platform that
already supports xhci in the PEI phase to use as a development platform that
might be a better option for me.

Thank you again for your patience and prompt responses.

Eric

 -Original Message-
 From: Tian, Feng [mailto:feng.t...@intel.com]
 Sent: Sunday, August 16, 2015 10:20 PM
 To: Eric Wittmayer; edk2-devel@lists.01.org
 Cc: Tian, Feng
 Subject: RE: [edk2] Help debugging PEIM on Minnowboard Max
 
 Do you look into the UsbController.h in MdeModulePkg/Include/Ppi
 directory?
 
 typedef
 EFI_STATUS
 (EFIAPI *PEI_GET_USB_CONTROLLER)(
   IN  EFI_PEI_SERVICES**PeiServices,
   IN  PEI_USB_CONTROLLER_PPI  *This,
   IN  UINT8   UsbControllerId,
   OUT UINTN   *ControllerType,
   OUT UINTN   *BaseAddress
   );
 
 You need write a PEIM to produce this PPI and implement the above
 interface according to your platform setting.
 
 For how to write a PEIM module, you can refer to EDKII Module Writer's
 Guide in edk2.sourceforge.net
 
 Thanks
 Feng
 
 -Original Message-
 From: Eric Wittmayer [mailto:e...@frescologic.com]
 Sent: Monday, August 17, 2015 11:50
 To: Tian, Feng; edk2-devel@lists.01.org
 Subject: RE: [edk2] Help debugging PEIM on Minnowboard Max
 
 Hi Feng,
I see now that XhciPei needs gPeiUsbControllerPpiGuid and creates
 gPeiUsbHostControllerPpiGuid  which UsbBusPei needs.
 
 I can't seem to figure out what creates gPeiUsbControllerPpiGuid?  I see
it
 listed in the .dec file I'm using but that apparently isn't enough to
 install the Ppi.   What should be installing the gPeiUsbControllerPpiGuid?
 
 Thanks,
 Eric
 
  -Original Message-
  From: Tian, Feng [mailto:feng.t...@intel.com]
  Sent: Sunday, August 16, 2015 6:09 PM
  To: Eric Wittmayer; edk2-devel@lists.01.org
  Cc: Tian, Feng
  Subject: RE: [edk2] Help debugging PEIM on Minnowboard Max
 
  Eric,
 
  I must agree the naming of these usb pei related ppi guids are not
  good, which misleads you.
 
  There is no the chicken and egg problem. gPeiUsbHostControllerPpiGuid
  and gPeiUsbControllerPpiGuid are two different ppis. The former is
  consumed by UsbPei and the latter is consumed by XhciPei. You need
  write a pei module to produce PeiUsbControllerPpi (see
  MdeModulePkg/Include/Ppi for
  definitions) at first.
 
  Thanks
  Feng
 
  -Original Message-
  From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
  Eric Wittmayer
  Sent: Saturday, August 15, 2015 08:12
  To: edk2-devel@lists.01.org
  Subject: [edk2] Help debugging PEIM on Minnowboard Max
 
  I'm writing a PEIM for a USB3 device but having trouble even getting
  the UsbBusPie and XhciPei modules to load during boot.
 
  I thought getting the existing Usb Peims to load would be a good first
 step.
  I looked at the DEPEX for both of the above modules and tried removing
  gEfiPeiBootInRecoveryModePpiGuid but I didn't see them load.  If I
  set both of their DEPEX == TRUE then I see some print statements that
  show they are at least trying to load but then I have a chicken and
  egg problem
 in
  that UsbBusPie needs either gPeiUsbHostControllerPpiGuid or
  gPeiUsb2HostControllerPpiGuid which come from XhciPei.  However,
  XhciPei needs gPeiUsbControllerPpiGuid which comes from UsbBusPei
  before  it will install the gPeiUsb2HostControllerPpiGuid.  The same
  cross dependency is shown in the DEPEX for these two modules.
 
  I feel like I'm missing something simple and fundamental and I'm
  hoping someone will point me in the right direction.
 
  Thanks,
  Eric W
 
  ___
  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] SecurityPkg: Fixed build error due to FixedAtBuild PcdTcg2HashAlgorithmBitmap

2015-08-17 Thread El-Haj-Mahmoud, Samer
Please see attached patch file. Can you help review it and check it in please?

Thanks,
--Samer




-Original Message-
From: Yao, Jiewen [mailto:jiewen@intel.com] 
Sent: Saturday, August 15, 2015 1:10 AM
To: El-Haj-Mahmoud, Samer samer.el-haj-mahm...@hp.com; edk2-devel@lists.01.org
Cc: Zhang, Chao B chao.b.zh...@intel.com; Yao, Jiewen jiewen@intel.com
Subject: RE: [edk2] [patch] SecurityPkg: Fixed build error due to FixedAtBuild 
PcdTcg2HashAlgorithmBitmap

Sounds good to me.

Thank you
Yao Jiewen

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
El-Haj-Mahmoud, Samer
Sent: Saturday, August 15, 2015 8:55 AM
To: edk2-devel@lists.01.org
Cc: El-Haj-Mahmoud, Samer; Zhang, Chao B
Subject: [edk2] [patch] SecurityPkg: Fixed build error due to FixedAtBuild 
PcdTcg2HashAlgorithmBitmap

PcdTcg2HashAlgorithmBitmap is declared in a section that allows it to be Fixed 
or PatchableAtBuild, but there is code that sets it. This breaks the build on 
some platforms. Changed it to be PcdsDynamic and PcdsDynamicEx only.

Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Samer El-Haj-Mahmoud samer.el-haj-mahm...@hp.com





Samer El-Haj-Mahmoud
System Firmware Architect
HP Servers 

el...@hp.com 
T +1.281.514.5973
C +1.512.659.1523
Hewlett-Packard Company
hp.com/go/proliant/uefi



___
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] SecurityPkg: Fixed build error due to FixedAtBuild PcdTcg2HashAlgorithmBitmap

2015-08-17 Thread El-Haj-Mahmoud, Samer
Yes that makes sense. I missed it since I have not tried to build the new Tcg2 
drivers yet.

Thanks,
--Samer


-Original Message-
From: Yao, Jiewen [mailto:jiewen@intel.com] 
Sent: Tuesday, August 18, 2015 12:15 AM
To: El-Haj-Mahmoud, Samer samer.el-haj-mahm...@hp.com; edk2-devel@lists.01.org
Cc: Zhang, Chao B chao.b.zh...@intel.com
Subject: RE: [edk2] [patch] SecurityPkg: Fixed build error due to FixedAtBuild 
PcdTcg2HashAlgorithmBitmap

Reviewed-by: Yao, Jiewen jiewen@intel.com

At same time, I suggest we move PcdTpm2HashMask to Dynamic section too, because 
now Tcg2Pei will set this PCD according to TPM2 device capability.

If you agree, I will check in both.

Thank you
Yao Jiewen


-Original Message-
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com] 
Sent: Tuesday, August 18, 2015 12:29 PM
To: Yao, Jiewen; edk2-devel@lists.01.org
Cc: Zhang, Chao B; El-Haj-Mahmoud, Samer
Subject: RE: [edk2] [patch] SecurityPkg: Fixed build error due to FixedAtBuild 
PcdTcg2HashAlgorithmBitmap

Please see attached patch file. Can you help review it and check it in please?

Thanks,
--Samer




-Original Message-
From: Yao, Jiewen [mailto:jiewen@intel.com] 
Sent: Saturday, August 15, 2015 1:10 AM
To: El-Haj-Mahmoud, Samer samer.el-haj-mahm...@hp.com; edk2-devel@lists.01.org
Cc: Zhang, Chao B chao.b.zh...@intel.com; Yao, Jiewen jiewen@intel.com
Subject: RE: [edk2] [patch] SecurityPkg: Fixed build error due to FixedAtBuild 
PcdTcg2HashAlgorithmBitmap

Sounds good to me.

Thank you
Yao Jiewen

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
El-Haj-Mahmoud, Samer
Sent: Saturday, August 15, 2015 8:55 AM
To: edk2-devel@lists.01.org
Cc: El-Haj-Mahmoud, Samer; Zhang, Chao B
Subject: [edk2] [patch] SecurityPkg: Fixed build error due to FixedAtBuild 
PcdTcg2HashAlgorithmBitmap

PcdTcg2HashAlgorithmBitmap is declared in a section that allows it to be Fixed 
or PatchableAtBuild, but there is code that sets it. This breaks the build on 
some platforms. Changed it to be PcdsDynamic and PcdsDynamicEx only.

Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Samer El-Haj-Mahmoud samer.el-haj-mahm...@hp.com





Samer El-Haj-Mahmoud
System Firmware Architect
HP Servers 

el...@hp.com 
T +1.281.514.5973
C +1.512.659.1523
Hewlett-Packard Company
hp.com/go/proliant/uefi



___
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 16/16] OvmfPkg/X64: enable 4 KB alignment for DXE_RUNTIME modules

2015-08-17 Thread Ard Biesheuvel
On 18 August 2015 at 04:35, Gao, Liming liming@intel.com wrote:
 Ard:
   I think this patch needs to update VS tool chain link flag to enable 4K for 
 DXE_RUNTIME modules, because Ovmf platform also supports VS tool chain.


Good point, thanks.


 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
 Biesheuvel
 Sent: Monday, August 17, 2015 10:25 PM
 To: edk2-devel@lists.01.org; Liu, Yingke D
 Cc: wp...@windriver.com; sc...@notabs.org; Ard Biesheuvel; Justen, Jordan L; 
 Gao, Liming; dw...@infradead.org
 Subject: [edk2] [PATCH v2 16/16] OvmfPkg/X64: enable 4 KB alignment for 
 DXE_RUNTIME modules

 This enables 4 KB section alignment for DXE_RUNTIME modules, for ELF based 
 toolchains and for the UNIXGCC PE/COFF toolchain.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  OvmfPkg/OvmfPkgX64.dsc | 7 +++
  1 file changed, 7 insertions(+)

 diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc index 
 b72eaa92f82e..817c381f4913 100644
 --- a/OvmfPkg/OvmfPkgX64.dsc
 +++ b/OvmfPkg/OvmfPkgX64.dsc
 @@ -48,6 +48,13 @@ [BuildOptions]
INTEL:*_*_X64_GENFW_FLAGS = --keepexceptiontable  !endif

 +[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
 +!if $(TOOLCHAIN) == UNIXGCC
 +  GCC:*_*_X64_DLINK_FLAGS = --section-alignment 0x1000 --file-alignment
 +0x1000 !else
 +  GCC:*_*_X64_DLINK_FLAGS = -z common-page-size=0x1000 !endif
 +
  
 
  #
  # SKU Identification section - list of all SKU IDs supported by this 
 Platform.
 --
 1.9.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] [uswg] Shell 2.0 and 2.1

2015-08-17 Thread Carsey, Jaben
The UEFI Shell 2.1 has been available for a long time.  Any UDK release after 
Aug last year should have it.  I am not an expert on the UDK releases...

-Jaben

 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
 Daniel Samuelraj
 Sent: Monday, August 17, 2015 10:09 AM
 To: Carsey, Jaben jaben.car...@intel.com; uswg u...@uefi.org
 Cc: edk2-devel@lists.01.org
 Subject: Re: [edk2] [uswg] Shell 2.0 and 2.1
 Importance: High
 
 Thank you, Jaben.
 
 
 
 I have added my comments inline
 
 
 
 *From:* Carsey, Jaben [mailto:jaben.car...@intel.com]
 *Sent:* Monday, August 17, 2015 11:12 AM
 *To:* Daniel Samuelraj; uswg
 *Cc:* edk2-devel@lists.01.org; Carsey, Jaben
 *Subject:* RE: [uswg] Shell 2.0 and 2.1
 
 
 
 (note: I changed the edk2 mailing list)
 
 
 
 Daniel,
 
 
 
 A UEFI Shell 2.0 application will work fine in UEFI Shell 2.1 with no
 changes.
 
 
 
 To create/build a UEFI Shell 2.1 application would need to have a version
 of the UDK that has the updated protocol to get easy access to the new
 API’s that were added to the protocol.
 
 *[Samuelraj, Daniel] I assume that this UDK is not available yet?*
 
 
 
 If you create a UEFI Shell 2.1 application AND you use a API in the
 protocol that is not in the 2.0 version of the protocol, you should check
 the version information in the protocol itself to make sure that the
 application will function on a UEFI Shell 2.0 system (even if that just
 generates an error).  If you call the API that does not exist, you will
 certainly have undefined behavior.
 
 
 
 -Jaben
 
 
 
 
 
 
 
 
 
 *From:* u...@uefi.org [mailto:u...@uefi.org u...@uefi.org] *On
 Behalf Of *Daniel
 Samuelraj
 *Sent:* Friday, August 14, 2015 9:40 AM
 *To:* uswg u...@uefi.org; edk2-de...@lists.sourceforge.net
 *Subject:* [uswg] Shell 2.0 and 2.1
 *Importance:* High
 
 
 
 Hi,
 
 I assume that Shell 2.0 apps are expected to run fine in Shell 2.1. Can you
 please confirm?
 
 
 
 Should shell 2.1 app be using new toolkit (e.g., UDK2014 or newer?) when
 app want to make use of the content added in Shell 2.1?
 
 
 
 Will there be any backward or forward compatibility issue? That is end user
 running Shell 2.0 app in shell 2.1; similarly running Shell 2.1 app in
 Shell 2.0?
 
 
 
 Appreciate the response!
 
 
 
 Thanks,
 
 Daniel
 ___
 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 00/16] unify GCC command line options

2015-08-17 Thread Ard Biesheuvel
On 17 August 2015 at 19:53, Jordan Justen jordan.l.jus...@intel.com wrote:
 On 2015-08-17 07:24:57, Ard Biesheuvel wrote:
 This got a bit out of hand after I noticed the ELFGCC and UNIXGCC
 toolchains that needed some tlc as well.

 Anyway, this series aims to refactor the toolchains definitions for
 UNIXGCC, GCC44, GCC45, GCC46, GCC47, GCC48, GCC49, CLANG35, ELFGCC,
 CYGGCC and CYGGCCxASL so that they share as much of the settings as

 UNIXGCC and CYGGCC are GCC 4.3  mingw based. Did this get tested?


I sent some patches around to bring them up to date:

http://thread.gmane.org/gmane.comp.bios.edk2.devel/1297

and with that version, it works fine. GCC 4.3 probably does not work
anymore for X64, since it incorrectly decorates symbol names with
underscores, which the MS ABI only specifies for 32-bit code.

 I think ELFGCC is unused at this point. (And has been since UnixPkg
 was deprecated.)

 I think we should deprecate all three of these toolchains. I would
 like to see us move them to BaseTools/Conf/tools_def.deprecated. I'll
 add Larry to this email, because I think he disagrees with deprecating
 toolchains...


I agree. It makes no sense to have dozens of toolchains when only a
couple are widely used by developers, especially with new features
like the 4 KB alignment for memory permissions that rely on options
that are only passed to some of them.

I already removed ARMGCC and ARMLINUXGCC last week, by the way, but I
don't suppose Larry would care about those?

 If you make these changes and it breaks those toolchains, I don't
 think we would be able to notice, because I don't think we test them
 in our build pool anymore. To me this is all the more reason to move
 them out of tools_def.template.


The only ones I did not test are the CYGGCC ones, which I cannot test
since it obviously only runs under Windows. Everything else seems to
work just fine, including mingw and IPF/ELF, although more coverage is
required of course.

-- 
Ard.


 possible. Currently, there is very little coordination between these,
 which means for instance that the 4 KB alignment feature is only supported
 on GCC4x at the moment.

 The primary difference between these toolchains is that GCC4x and ELFGCC
 are entirely ELF based, whereas the other are PE/COFF based (but only when
 building for IA32 or X64)

 Note that this series does not remove any toolchains, nor should it result
 in major changes in the command lines that are passed to the various tools.
 However, things may be reordered, and (in case of ELFGCC), missing 
 functionality
 such as increased section alignment has been added so there are some changes
 there.

 Patch #1 is a patch from Scott that I am reposting, but updated to cover
 AARCH64 as well.

 Patch #2 fixes a problem in the GenFv tool where it may access unallocated
 memory while rebasing the FFS when using large section and file alignment.

 Patch #3 removes an unused DEFINE from tools_def

 Patch #4 moved some warning flags that were applied to GCC4x 4.6 and up to
 all GCC versions.

 Patch #5 is the first big refactor patch that introduces PE and ELF variants
 for some CC flags.

 Patch #6 unifies the IA32 and X64 CC flags for all toolchains listed above.

 Patch #7 fixes the issue mentioned by Bill where the underscore decoration
 is erroneously applied on X64 as well.

 Patch #8 is the second refactor the introduces PE and ELF variants for the
 various DLINK flags.

 Patch #9 changes the way the start of the .data section is set in 
 GccBase.lds.
 This is needed since the linker will reorganize the internal layout of the 
 .data
 section rather than update its start address to ensure all objects that it
 contains meet their respective alignments, even if the start address is not
 aligned to the max value of all inputs.

 Patch #10 removes the explicit 64 byte alignment applied to GCC 4.9. The 
 latest
 GenFw and linker script propagate the alignment automatically, i.e., if 
 objects
 with such alignment requirement are present, GCC will set the ELF header
 accordingly, and this value will be used for the PE/COFF section alignment
 as well.

 Patch #11 unifies the IA32 and X64 linker flags for all toolchains listed 
 above.

 Patch #12 unifies the ARM and AARCH64 CC flags, i.e., it removes all the
 redundant definitions.

 Patch #13 as #11 but for the linker.

 Patch #14 unifies the ASM flags for all archs.

 Patch #15 brings the remaining configuration options of ELFGCC in line with
 the GCC4x series.

 Patch #16 is a PoC that allows Ovmf/X64 to be built with 4 KB section 
 alignment
 for DXE_RUNTIME modules using UNIXGCC and ELFGCC, as is required to support
 the properties table memprotection feature.

 Changes since v1:
 - added patch #9 to address the IA32 and X86 failures on 4.9 reported by 
 Scott
 - don't pass -mno-unaligned-access to ARM 4.6 compiler (Scott)
 - improved wording of commit messages of various patches
 - rebased onto latest upstream, which includes a fix related to the ARM 4.6

Re: [edk2] [uswg] Shell 2.0 and 2.1

2015-08-17 Thread Daniel Samuelraj
Thank you, Jaben.



I have added my comments inline



*From:* Carsey, Jaben [mailto:jaben.car...@intel.com]
*Sent:* Monday, August 17, 2015 11:12 AM
*To:* Daniel Samuelraj; uswg
*Cc:* edk2-devel@lists.01.org; Carsey, Jaben
*Subject:* RE: [uswg] Shell 2.0 and 2.1



(note: I changed the edk2 mailing list)



Daniel,



A UEFI Shell 2.0 application will work fine in UEFI Shell 2.1 with no
changes.



To create/build a UEFI Shell 2.1 application would need to have a version
of the UDK that has the updated protocol to get easy access to the new
API’s that were added to the protocol.

*[Samuelraj, Daniel] I assume that this UDK is not available yet?*



If you create a UEFI Shell 2.1 application AND you use a API in the
protocol that is not in the 2.0 version of the protocol, you should check
the version information in the protocol itself to make sure that the
application will function on a UEFI Shell 2.0 system (even if that just
generates an error).  If you call the API that does not exist, you will
certainly have undefined behavior.



-Jaben









*From:* u...@uefi.org [mailto:u...@uefi.org u...@uefi.org] *On
Behalf Of *Daniel
Samuelraj
*Sent:* Friday, August 14, 2015 9:40 AM
*To:* uswg u...@uefi.org; edk2-de...@lists.sourceforge.net
*Subject:* [uswg] Shell 2.0 and 2.1
*Importance:* High



Hi,

I assume that Shell 2.0 apps are expected to run fine in Shell 2.1. Can you
please confirm?



Should shell 2.1 app be using new toolkit (e.g., UDK2014 or newer?) when
app want to make use of the content added in Shell 2.1?



Will there be any backward or forward compatibility issue? That is end user
running Shell 2.0 app in shell 2.1; similarly running Shell 2.1 app in
Shell 2.0?



Appreciate the response!



Thanks,

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


Re: [edk2] [Patch 6/8] OptionRomPkg/OvmfPkg: Remove BltLib::BltConfigure API

2015-08-17 Thread Jordan Justen
On 2015-08-17 06:45:27, Ruiyu Ni wrote:
 The BltConfigure() API caches the video frame buffer meta data which
 forbids the library to be implemented to support re-entry.

How does this help? GraphicsOutputDxe will set a mode, and then use
BltLib with that mode.

I already asked this, and I had some other questions:

http://article.gmane.org/gmane.comp.bios.edk2.devel/1209

-Jordan

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ruiyu Ni ruiyu...@intel.com
 Cc: Laszlo Ersek ler...@redhat.com
 Cc: Jordan Justen jordan.l.jus...@intel.com
 ---
  .../Application/BltLibSample/BltLibSample.c| 129 +++---
  OptionRomPkg/Include/Library/BltLib.h  | 151 +++---
  .../Library/FrameBufferBltLib/FrameBufferBltLib.c  | 514 
 +++--
  OptionRomPkg/Library/GopBltLib/GopBltLib.c | 289 ++--
  OvmfPkg/QemuVideoDxe/Gop.c |  13 +-
  5 files changed, 576 insertions(+), 520 deletions(-)
 
 diff --git a/OptionRomPkg/Application/BltLibSample/BltLibSample.c 
 b/OptionRomPkg/Application/BltLibSample/BltLibSample.c
 index 333b054..3c7e392 100644
 --- a/OptionRomPkg/Application/BltLibSample/BltLibSample.c
 +++ b/OptionRomPkg/Application/BltLibSample/BltLibSample.c
 @@ -18,6 +18,7 @@
  #include Library/UefiLib.h
  #include Library/UefiApplicationEntryPoint.h
  #include Library/UefiBootServicesTableLib.h
 +#include Library/MemoryAllocationLib.h
  
  
  UINT64
 @@ -68,8 +69,8 @@ Rand32 (
  
  VOID
  TestFills (
 -  UINT32 HorizontalResolution,
 -  UINT32 VerticalResolution
 +  IN  VOID *FrameBuffer,
 +  IN  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *FrameBufferInfo
)
  {
EFI_GRAPHICS_OUTPUT_BLT_PIXEL  Color;
 @@ -79,44 +80,45 @@ TestFills (
UINTN  W;
UINTN  H;
  
 -  for (Loop = 0; Loop  1; Loop++) {
 -W = HorizontalResolution - (Rand32 () % HorizontalResolution);
 -H = VerticalResolution - (Rand32 () % VerticalResolution);
 -if (W != HorizontalResolution) {
 -  X = Rand32 () % (HorizontalResolution - W);
 +  for (Loop = 0; Loop  1000; Loop++) {
 +W = FrameBufferInfo-HorizontalResolution - (Rand32 () % 
 FrameBufferInfo-HorizontalResolution);
 +H = FrameBufferInfo-VerticalResolution - (Rand32 () % 
 FrameBufferInfo-VerticalResolution);
 +if (W != FrameBufferInfo-HorizontalResolution) {
 +  X = Rand32 () % (FrameBufferInfo-HorizontalResolution - W);
  } else {
X = 0;
  }
 -if (H != VerticalResolution) {
 -  Y = Rand32 () % (VerticalResolution - H);
 +if (H != FrameBufferInfo-VerticalResolution) {
 +  Y = Rand32 () % (FrameBufferInfo-VerticalResolution - H);
  } else {
Y = 0;
  }
  *(UINT32*) (Color) = Rand32 ()  0xff;
 -BltVideoFill (Color, X, Y, W, H);
 +BltVideoFill (FrameBuffer, FrameBufferInfo, Color, X, Y, W, H);
}
  }
  
  
  VOID
  TestColor1 (
 -  UINT32 HorizontalResolution,
 -  UINT32 VerticalResolution
 +  IN  VOID *FrameBuffer,
 +  IN  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *FrameBufferInfo
)
  {
 -  EFI_GRAPHICS_OUTPUT_BLT_PIXEL  Color;
 +  EFI_GRAPHICS_OUTPUT_BLT_PIXEL  *BltBuffer;
UINTN  X;
UINTN  Y;
  
 -  *(UINT32*) (Color) = 0;
 +  BltBuffer = AllocatePool (sizeof (*BltBuffer) * 
 FrameBufferInfo-HorizontalResolution);
 +  ASSERT (BltBuffer != NULL);
  
 -  for (Y = 0; Y  VerticalResolution; Y++) {
 -for (X = 0; X  HorizontalResolution; X++) {
 -  Color.Red =   (UINT8) ((X * 0x100) / HorizontalResolution);
 -  Color.Green = (UINT8) ((Y * 0x100) / VerticalResolution);
 -  Color.Blue =  (UINT8) ((Y * 0x100) / VerticalResolution);
 -  BltVideoFill (Color, X, Y, 1, 1);
 +  for (Y = 0; Y  FrameBufferInfo-VerticalResolution; Y++) {
 +for (X = 0; X  FrameBufferInfo-HorizontalResolution; X++) {
 +  BltBuffer[X].Red =   (UINT8) ((X * 0x100) / 
 FrameBufferInfo-HorizontalResolution);
 +  BltBuffer[X].Green = (UINT8) ((Y * 0x100) / 
 FrameBufferInfo-VerticalResolution);
 +  BltBuffer[X].Blue =  (UINT8) ((Y * 0x100) / 
 FrameBufferInfo-VerticalResolution);
  }
 +BltBufferToVideo (FrameBuffer, FrameBufferInfo, BltBuffer, 0, 0, 0, Y, 
 FrameBufferInfo-HorizontalResolution, 1, 0);
}
  }
  
 @@ -176,8 +178,8 @@ GetTriColor (
  
  VOID
  TestColor (
 -  UINT32 HorizontalResolution,
 -  UINT32 VerticalResolution
 +  IN  VOID *FrameBuffer,
 +  IN  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *FrameBufferInfo
)
  {
EFI_GRAPHICS_OUTPUT_BLT_PIXEL  Color;
 @@ -187,34 +189,38 @@ TestColor (
UINTN  LineWidth, TriWidth;
UINTN  TriHeight;
UINT32 ColorDist;
 +  

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

2015-08-17 Thread Jordan Justen
On 2015-08-17 07:24:57, Ard Biesheuvel wrote:
 This got a bit out of hand after I noticed the ELFGCC and UNIXGCC
 toolchains that needed some tlc as well.
 
 Anyway, this series aims to refactor the toolchains definitions for
 UNIXGCC, GCC44, GCC45, GCC46, GCC47, GCC48, GCC49, CLANG35, ELFGCC,
 CYGGCC and CYGGCCxASL so that they share as much of the settings as

UNIXGCC and CYGGCC are GCC 4.3  mingw based. Did this get tested?

I think ELFGCC is unused at this point. (And has been since UnixPkg
was deprecated.)

I think we should deprecate all three of these toolchains. I would
like to see us move them to BaseTools/Conf/tools_def.deprecated. I'll
add Larry to this email, because I think he disagrees with deprecating
toolchains...

If you make these changes and it breaks those toolchains, I don't
think we would be able to notice, because I don't think we test them
in our build pool anymore. To me this is all the more reason to move
them out of tools_def.template.

-Jordan

 possible. Currently, there is very little coordination between these,
 which means for instance that the 4 KB alignment feature is only supported
 on GCC4x at the moment.
 
 The primary difference between these toolchains is that GCC4x and ELFGCC
 are entirely ELF based, whereas the other are PE/COFF based (but only when
 building for IA32 or X64)
 
 Note that this series does not remove any toolchains, nor should it result
 in major changes in the command lines that are passed to the various tools.
 However, things may be reordered, and (in case of ELFGCC), missing 
 functionality
 such as increased section alignment has been added so there are some changes
 there.
 
 Patch #1 is a patch from Scott that I am reposting, but updated to cover
 AARCH64 as well.
 
 Patch #2 fixes a problem in the GenFv tool where it may access unallocated
 memory while rebasing the FFS when using large section and file alignment.
 
 Patch #3 removes an unused DEFINE from tools_def
 
 Patch #4 moved some warning flags that were applied to GCC4x 4.6 and up to
 all GCC versions.
 
 Patch #5 is the first big refactor patch that introduces PE and ELF variants
 for some CC flags.
 
 Patch #6 unifies the IA32 and X64 CC flags for all toolchains listed above.
 
 Patch #7 fixes the issue mentioned by Bill where the underscore decoration
 is erroneously applied on X64 as well.
 
 Patch #8 is the second refactor the introduces PE and ELF variants for the
 various DLINK flags.
 
 Patch #9 changes the way the start of the .data section is set in GccBase.lds.
 This is needed since the linker will reorganize the internal layout of the 
 .data
 section rather than update its start address to ensure all objects that it
 contains meet their respective alignments, even if the start address is not
 aligned to the max value of all inputs.
 
 Patch #10 removes the explicit 64 byte alignment applied to GCC 4.9. The 
 latest
 GenFw and linker script propagate the alignment automatically, i.e., if 
 objects
 with such alignment requirement are present, GCC will set the ELF header
 accordingly, and this value will be used for the PE/COFF section alignment
 as well.
 
 Patch #11 unifies the IA32 and X64 linker flags for all toolchains listed 
 above.
 
 Patch #12 unifies the ARM and AARCH64 CC flags, i.e., it removes all the
 redundant definitions.
 
 Patch #13 as #11 but for the linker.
 
 Patch #14 unifies the ASM flags for all archs.
 
 Patch #15 brings the remaining configuration options of ELFGCC in line with
 the GCC4x series.
 
 Patch #16 is a PoC that allows Ovmf/X64 to be built with 4 KB section 
 alignment
 for DXE_RUNTIME modules using UNIXGCC and ELFGCC, as is required to support
 the properties table memprotection feature.
 
 Changes since v1:
 - added patch #9 to address the IA32 and X86 failures on 4.9 reported by Scott
 - don't pass -mno-unaligned-access to ARM 4.6 compiler (Scott)
 - improved wording of commit messages of various patches
 - rebased onto latest upstream, which includes a fix related to the ARM 4.6
   issue mentioned above
 
 Branch can be found here
 https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/unify-gcc-v2
 
 Ard Biesheuvel (15):
   BaseTools/GenFv: use PE/COFF virtual section size if raw size is
 larger
   BaseTools GCC: remove unused definition of GCC_WINDRES_FLAGS
   BaseTools GCC: merge warning flags for all GCC versions
   BaseTools GCC: refactor tools_def internal GCC defines for CC flags
   BaseTools GCC: unify all IA32 and X64 CC flags for ELF based GCC
   BaseTools GCC: use leading underscore for symbol names where
 appropriate
   BaseTools GCC: refactor tools_def internal GCC defines for [AS]DLINK
   BaseTools GCC: don't set .data address explicitly
   BaseTools GCC: remove GCC 4.9 specific linker alignment override
   BaseTools GCC: unify all IA32 and X64 [AS]DLINK[2] flags for ELF based
 GCC
   BaseTools GCC: unify ARM and AARCH64 GCC compiler flags
   BaseTools GCC: unify ARM and AARCH64 

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

2015-08-17 Thread David Woodhouse
On Mon, 2015-08-17 at 10:53 -0700, Jordan Justen wrote:
 
 UNIXGCC and CYGGCC are GCC 4.3  mingw based. Did this get tested?
 
 I think ELFGCC is unused at this point. (And has been since UnixPkg
 was deprecated.)
 
 I think we should deprecate all three of these toolchains. I would
 like to see us move them to BaseTools/Conf/tools_def.deprecated. I'll
 add Larry to this email, because I think he disagrees with 
 deprecating
 toolchains...
 
 If you make these changes and it breaks those toolchains, I don't
 think we would be able to notice, because I don't think we test them
 in our build pool anymore. To me this is all the more reason to move
 them out of tools_def.template.

I was building with UNIXGCC last week, to test LLP64 builds without the
pain of actually having to deal with Windows.

I'd rather see it updated to work with modern MinGW rather than
deprecated.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation


smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v2 00/16] unify GCC command line options

2015-08-17 Thread Bill Paul
Of all the gin joints in all the towns in all the world, David Woodhouse had 
to walk into mine at 11:00:23 on Monday 17 August 2015 and say:

 On Mon, 2015-08-17 at 10:53 -0700, Jordan Justen wrote:
  UNIXGCC and CYGGCC are GCC 4.3  mingw based. Did this get tested?
  
  I think ELFGCC is unused at this point. (And has been since UnixPkg
  was deprecated.)
  
  I think we should deprecate all three of these toolchains. I would
  like to see us move them to BaseTools/Conf/tools_def.deprecated. I'll
  add Larry to this email, because I think he disagrees with
  deprecating
  toolchains...
  
  If you make these changes and it breaks those toolchains, I don't
  think we would be able to notice, because I don't think we test them
  in our build pool anymore. To me this is all the more reason to move
  them out of tools_def.template.
 
 I was building with UNIXGCC last week, to test LLP64 builds without the
 pain of actually having to deal with Windows.
 
 I'd rather see it updated to work with modern MinGW rather than
 deprecated.

I use UNIXGCC with the cross-compiler toolchain generated by mingw-gcc-
build.py. Yes, I know the existing version of the script uses GCC 4.3.0. 
That's why I made an updated version that uses 4.9.3:

http://people.freebsd.org/~wpaul/edk2/mingw-gcc-build.py

I know you don't want to support this script, that's why I did the work for 
you. :) Yes I've tested both IA32 and X64 builds. Yes they work fine.

There is value in being able to bootstrap your own cross-build toolchain on 
whatever platform. I don't think you should be so quick to remove it.

-Bill

-- 
=
-Bill Paul(510) 749-2329 | Senior Member of Technical Staff,
 wp...@windriver.com | Master of Unix-Fu - Wind River Systems
=
   I put a dollar in a change machine. Nothing changed. - George Carlin
=
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [uswg] Shell 2.0 and 2.1

2015-08-17 Thread Carsey, Jaben
(note: I changed the edk2 mailing list)

Daniel,

A UEFI Shell 2.0 application will work fine in UEFI Shell 2.1 with no changes.

To create/build a UEFI Shell 2.1 application would need to have a version of 
the UDK that has the updated protocol to get easy access to the new API’s that 
were added to the protocol.

If you create a UEFI Shell 2.1 application AND you use a API in the protocol 
that is not in the 2.0 version of the protocol, you should check the version 
information in the protocol itself to make sure that the application will 
function on a UEFI Shell 2.0 system (even if that just generates an error).  If 
you call the API that does not exist, you will certainly have undefined 
behavior.

-Jaben




From: u...@uefi.org [mailto:u...@uefi.org] On Behalf Of Daniel Samuelraj
Sent: Friday, August 14, 2015 9:40 AM
To: uswg u...@uefi.org; edk2-de...@lists.sourceforge.net
Subject: [uswg] Shell 2.0 and 2.1
Importance: High

Hi,
I assume that Shell 2.0 apps are expected to run fine in Shell 2.1. Can you 
please confirm?

Should shell 2.1 app be using new toolkit (e.g., UDK2014 or newer?) when app 
want to make use of the content added in Shell 2.1?

Will there be any backward or forward compatibility issue? That is end user 
running Shell 2.0 app in shell 2.1; similarly running Shell 2.1 app in Shell 
2.0?

Appreciate the response!

Thanks,
Daniel

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


Re: [edk2] [PATCH v2 00/16] unify GCC command line options

2015-08-17 Thread Jordan Justen
On 2015-08-17 11:10:57, Bill Paul wrote:
 Of all the gin joints in all the towns in all the world, David Woodhouse had 
 to walk into mine at 11:00:23 on Monday 17 August 2015 and say:
 
  On Mon, 2015-08-17 at 10:53 -0700, Jordan Justen wrote:
   UNIXGCC and CYGGCC are GCC 4.3  mingw based. Did this get tested?
   
   I think ELFGCC is unused at this point. (And has been since UnixPkg
   was deprecated.)
   
   I think we should deprecate all three of these toolchains. I would
   like to see us move them to BaseTools/Conf/tools_def.deprecated. I'll
   add Larry to this email, because I think he disagrees with
   deprecating
   toolchains...
   
   If you make these changes and it breaks those toolchains, I don't
   think we would be able to notice, because I don't think we test them
   in our build pool anymore. To me this is all the more reason to move
   them out of tools_def.template.
  
  I was building with UNIXGCC last week, to test LLP64 builds without the
  pain of actually having to deal with Windows.
  
  I'd rather see it updated to work with modern MinGW rather than
  deprecated.
 
 I use UNIXGCC with the cross-compiler toolchain generated by mingw-gcc-
 build.py. Yes, I know the existing version of the script uses GCC 4.3.0. 
 That's why I made an updated version that uses 4.9.3:
 
 http://people.freebsd.org/~wpaul/edk2/mingw-gcc-build.py
 
 I know you don't want to support this script, that's why I did the work for 
 you. :) Yes I've tested both IA32 and X64 builds. Yes they work fine.
 
 There is value in being able to bootstrap your own cross-build toolchain on 
 whatever platform. I don't think you should be so quick to remove it.

Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead?

I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be
based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part
of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if
you count the comment in tools_def :) This is why I'd rather deprecate
it as a toolchain, and use the GCC4X toolchains instead.

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


Re: [edk2] [PATCH v2 00/16] unify GCC command line options

2015-08-17 Thread Scott Duplichan
Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]  wrote:

]Sent: Monday, August 17, 2015 09:25 AM
]To: edk2-de...@ml01.01.org; yingke.d@intel.com
]Cc: wp...@windriver.com; sc...@notabs.org; Ard Biesheuvel 
ard.biesheu...@linaro.org; jordan.l.jus...@intel.com; ]liming@intel.com; 
dw...@infradead.org
]Subject: [edk2] [PATCH v2 00/16] unify GCC command line options
]
]This got a bit out of hand after I noticed the ELFGCC and UNIXGCC
]toolchains that needed some tlc as well.
]
]Anyway, this series aims to refactor the toolchains definitions for
]UNIXGCC, GCC44, GCC45, GCC46, GCC47, GCC48, GCC49, CLANG35, ELFGCC,
]CYGGCC and CYGGCCxASL so that they share as much of the settings as
]possible. Currently, there is very little coordination between these,
]which means for instance that the 4 KB alignment feature is only supported
]on GCC4x at the moment.
]
]The primary difference between these toolchains is that GCC4x and ELFGCC
]are entirely ELF based, whereas the other are PE/COFF based (but only when
]building for IA32 or X64)
]
]Note that this series does not remove any toolchains, nor should it result
]in major changes in the command lines that are passed to the various tools.
]However, things may be reordered, and (in case of ELFGCC), missing 
functionality
]such as increased section alignment has been added so there are some changes
]there.
]
]Patch #1 is a patch from Scott that I am reposting, but updated to cover
]AARCH64 as well.
]
]Patch #2 fixes a problem in the GenFv tool where it may access unallocated
]memory while rebasing the FFS when using large section and file alignment.
]
]Patch #3 removes an unused DEFINE from tools_def
]
]Patch #4 moved some warning flags that were applied to GCC4x 4.6 and up to
]all GCC versions.
]
]Patch #5 is the first big refactor patch that introduces PE and ELF variants
]for some CC flags.
]
]Patch #6 unifies the IA32 and X64 CC flags for all toolchains listed above.
]
]Patch #7 fixes the issue mentioned by Bill where the underscore decoration
]is erroneously applied on X64 as well.
]
]Patch #8 is the second refactor the introduces PE and ELF variants for the
]various DLINK flags.
]
]Patch #9 changes the way the start of the .data section is set in GccBase.lds.
]This is needed since the linker will reorganize the internal layout of the 
.data
]section rather than update its start address to ensure all objects that it
]contains meet their respective alignments, even if the start address is not
]aligned to the max value of all inputs.
]
]Patch #10 removes the explicit 64 byte alignment applied to GCC 4.9. The latest
]GenFw and linker script propagate the alignment automatically, i.e., if objects
]with such alignment requirement are present, GCC will set the ELF header
]accordingly, and this value will be used for the PE/COFF section alignment
]as well.
]
]Patch #11 unifies the IA32 and X64 linker flags for all toolchains listed 
above.
]
]Patch #12 unifies the ARM and AARCH64 CC flags, i.e., it removes all the
]redundant definitions.
]
]Patch #13 as #11 but for the linker.
]
]Patch #14 unifies the ASM flags for all archs.
]
]Patch #15 brings the remaining configuration options of ELFGCC in line with
]the GCC4x series.
]
]Patch #16 is a PoC that allows Ovmf/X64 to be built with 4 KB section alignment
]for DXE_RUNTIME modules using UNIXGCC and ELFGCC, as is required to support
]the properties table memprotection feature.
]
]Changes since v1:
]- added patch #9 to address the IA32 and X86 failures on 4.9 reported by Scott
]- don't pass -mno-unaligned-access to ARM 4.6 compiler (Scott)
]- improved wording of commit messages of various patches
]- rebased onto latest upstream, which includes a fix related to the ARM 4.6
]  issue mentioned above
]
]Branch can be found here
]https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/unify-gcc-v2
]
]Ard Biesheuvel (15):
]  BaseTools/GenFv: use PE/COFF virtual section size if raw size is
]larger
]  BaseTools GCC: remove unused definition of GCC_WINDRES_FLAGS
]  BaseTools GCC: merge warning flags for all GCC versions
]  BaseTools GCC: refactor tools_def internal GCC defines for CC flags
]  BaseTools GCC: unify all IA32 and X64 CC flags for ELF based GCC
]  BaseTools GCC: use leading underscore for symbol names where
]appropriate
]  BaseTools GCC: refactor tools_def internal GCC defines for [AS]DLINK
]  BaseTools GCC: don't set .data address explicitly
]  BaseTools GCC: remove GCC 4.9 specific linker alignment override
]  BaseTools GCC: unify all IA32 and X64 [AS]DLINK[2] flags for ELF based
]GCC
]  BaseTools GCC: unify ARM and AARCH64 GCC compiler flags
]  BaseTools GCC: unify ARM and AARCH64 DLINK flags for all GCC versions
]  BaseTools GCC: unify ASM flags for all GCC versions
]  BaseTools GCC: align ELFGCC with GCC4x toolchains
]  OvmfPkg/X64: enable 4 KB alignment for DXE_RUNTIME modules
]
]Scott Duplichan (1):
]  BaseTools GCC: Fix GCC49 build failure
]
] BaseTools/Conf/tools_def.template 

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

2015-08-17 Thread Ard Biesheuvel
On 17 August 2015 at 20:37, Scott Duplichan sc...@notabs.org wrote:
 Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]  wrote:

 ]Sent: Monday, August 17, 2015 09:25 AM
 ]To: edk2-de...@ml01.01.org; yingke.d@intel.com
 ]Cc: wp...@windriver.com; sc...@notabs.org; Ard Biesheuvel 
 ard.biesheu...@linaro.org; jordan.l.jus...@intel.com; 
 ]liming@intel.com; dw...@infradead.org
 ]Subject: [edk2] [PATCH v2 00/16] unify GCC command line options
 ]
 ]This got a bit out of hand after I noticed the ELFGCC and UNIXGCC
 ]toolchains that needed some tlc as well.
 ]
 ]Anyway, this series aims to refactor the toolchains definitions for
 ]UNIXGCC, GCC44, GCC45, GCC46, GCC47, GCC48, GCC49, CLANG35, ELFGCC,
 ]CYGGCC and CYGGCCxASL so that they share as much of the settings as
 ]possible. Currently, there is very little coordination between these,
 ]which means for instance that the 4 KB alignment feature is only supported
 ]on GCC4x at the moment.
 ]
 ]The primary difference between these toolchains is that GCC4x and ELFGCC
 ]are entirely ELF based, whereas the other are PE/COFF based (but only when
 ]building for IA32 or X64)
 ]
 ]Note that this series does not remove any toolchains, nor should it result
 ]in major changes in the command lines that are passed to the various tools.
 ]However, things may be reordered, and (in case of ELFGCC), missing 
 functionality
 ]such as increased section alignment has been added so there are some changes
 ]there.
 ]
 ]Patch #1 is a patch from Scott that I am reposting, but updated to cover
 ]AARCH64 as well.
 ]
 ]Patch #2 fixes a problem in the GenFv tool where it may access unallocated
 ]memory while rebasing the FFS when using large section and file alignment.
 ]
 ]Patch #3 removes an unused DEFINE from tools_def
 ]
 ]Patch #4 moved some warning flags that were applied to GCC4x 4.6 and up to
 ]all GCC versions.
 ]
 ]Patch #5 is the first big refactor patch that introduces PE and ELF variants
 ]for some CC flags.
 ]
 ]Patch #6 unifies the IA32 and X64 CC flags for all toolchains listed above.
 ]
 ]Patch #7 fixes the issue mentioned by Bill where the underscore decoration
 ]is erroneously applied on X64 as well.
 ]
 ]Patch #8 is the second refactor the introduces PE and ELF variants for the
 ]various DLINK flags.
 ]
 ]Patch #9 changes the way the start of the .data section is set in 
 GccBase.lds.
 ]This is needed since the linker will reorganize the internal layout of the 
 .data
 ]section rather than update its start address to ensure all objects that it
 ]contains meet their respective alignments, even if the start address is not
 ]aligned to the max value of all inputs.
 ]
 ]Patch #10 removes the explicit 64 byte alignment applied to GCC 4.9. The 
 latest
 ]GenFw and linker script propagate the alignment automatically, i.e., if 
 objects
 ]with such alignment requirement are present, GCC will set the ELF header
 ]accordingly, and this value will be used for the PE/COFF section alignment
 ]as well.
 ]
 ]Patch #11 unifies the IA32 and X64 linker flags for all toolchains listed 
 above.
 ]
 ]Patch #12 unifies the ARM and AARCH64 CC flags, i.e., it removes all the
 ]redundant definitions.
 ]
 ]Patch #13 as #11 but for the linker.
 ]
 ]Patch #14 unifies the ASM flags for all archs.
 ]
 ]Patch #15 brings the remaining configuration options of ELFGCC in line with
 ]the GCC4x series.
 ]
 ]Patch #16 is a PoC that allows Ovmf/X64 to be built with 4 KB section 
 alignment
 ]for DXE_RUNTIME modules using UNIXGCC and ELFGCC, as is required to support
 ]the properties table memprotection feature.
 ]
 ]Changes since v1:
 ]- added patch #9 to address the IA32 and X86 failures on 4.9 reported by 
 Scott
 ]- don't pass -mno-unaligned-access to ARM 4.6 compiler (Scott)
 ]- improved wording of commit messages of various patches
 ]- rebased onto latest upstream, which includes a fix related to the ARM 4.6
 ]  issue mentioned above
 ]
 ]Branch can be found here
 ]https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/unify-gcc-v2
 ]
 ]Ard Biesheuvel (15):
 ]  BaseTools/GenFv: use PE/COFF virtual section size if raw size is
 ]larger
 ]  BaseTools GCC: remove unused definition of GCC_WINDRES_FLAGS
 ]  BaseTools GCC: merge warning flags for all GCC versions
 ]  BaseTools GCC: refactor tools_def internal GCC defines for CC flags
 ]  BaseTools GCC: unify all IA32 and X64 CC flags for ELF based GCC
 ]  BaseTools GCC: use leading underscore for symbol names where
 ]appropriate
 ]  BaseTools GCC: refactor tools_def internal GCC defines for [AS]DLINK
 ]  BaseTools GCC: don't set .data address explicitly
 ]  BaseTools GCC: remove GCC 4.9 specific linker alignment override
 ]  BaseTools GCC: unify all IA32 and X64 [AS]DLINK[2] flags for ELF based
 ]GCC
 ]  BaseTools GCC: unify ARM and AARCH64 GCC compiler flags
 ]  BaseTools GCC: unify ARM and AARCH64 DLINK flags for all GCC versions
 ]  BaseTools GCC: unify ASM flags for all GCC versions
 ]  BaseTools GCC: align ELFGCC 

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

2015-08-17 Thread Bill Paul
Of all the gin joints in all the towns in all the world, Jordan Justen had to 
walk into mine at 11:22:15 on Monday 17 August 2015 and say:

 On 2015-08-17 11:10:57, Bill Paul wrote:
  Of all the gin joints in all the towns in all the world, David Woodhouse
  had
  
  to walk into mine at 11:00:23 on Monday 17 August 2015 and say:
   On Mon, 2015-08-17 at 10:53 -0700, Jordan Justen wrote:
UNIXGCC and CYGGCC are GCC 4.3  mingw based. Did this get tested?

I think ELFGCC is unused at this point. (And has been since UnixPkg
was deprecated.)

I think we should deprecate all three of these toolchains. I would
like to see us move them to BaseTools/Conf/tools_def.deprecated. I'll
add Larry to this email, because I think he disagrees with
deprecating
toolchains...

If you make these changes and it breaks those toolchains, I don't
think we would be able to notice, because I don't think we test them
in our build pool anymore. To me this is all the more reason to move
them out of tools_def.template.
   
   I was building with UNIXGCC last week, to test LLP64 builds without the
   pain of actually having to deal with Windows.
   
   I'd rather see it updated to work with modern MinGW rather than
   deprecated.
  
  I use UNIXGCC with the cross-compiler toolchain generated by mingw-gcc-
  build.py. Yes, I know the existing version of the script uses GCC 4.3.0.
  That's why I made an updated version that uses 4.9.3:
  
  http://people.freebsd.org/~wpaul/edk2/mingw-gcc-build.py
  
  I know you don't want to support this script, that's why I did the work
  for you. :) Yes I've tested both IA32 and X64 builds. Yes they work
  fine.
  
  There is value in being able to bootstrap your own cross-build toolchain
  on whatever platform. I don't think you should be so quick to remove it.
 
 Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead?

I could, but there's not really much point.

UEFI uses PE/COFF as its object format, right? Using an ELF-based GCC means 
that you have to add a extra conversion step during the build process in order 
to go from ELF to PE/COFF. The rationale for doing it that way is: A lot of 
*NIX systems already have ELF-based system compilers installed, we might as 
well use them. I understand the usefulness of this approach.

However, if I'm going to be bootstrapping my own cross-build tools from 
scratch, that rationale no longer applies: if I have the option of selecting a 
target that gets me PE/COFF objects directly, I might as well do that.

 I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be
 based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part
 of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if
 you count the comment in tools_def :) This is why I'd rather deprecate
 it as a toolchain, and use the GCC4X toolchains instead.

I don't think this reasoning is valid. It doesn't seem fair to say that just 
because the UNIXGCC target was originally set up to use GCC 4.3.0, you can 
never upgrade it to a newer version. Technically, GCC 4.3.0 is buggy if you 
consider that it gets the underscore decoration convention wrong for X64. I 
would argue that it makes sense to fix this, since if the intent was to 
produce a cross-build toolchain that emulates the Microsoft toolchain 
behavior, it's not actually doing that now. It hasn't been left like that 
because people wanted it that way: it was left like that because until now 
nobody cared enough to fix it.

-Bill

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

-- 
=
-Bill Paul(510) 749-2329 | Senior Member of Technical Staff,
 wp...@windriver.com | Master of Unix-Fu - Wind River Systems
=
   I put a dollar in a change machine. Nothing changed. - George Carlin
=
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v2 00/16] unify GCC command line options

2015-08-17 Thread Jordan Justen
On 2015-08-17 11:25:56, Ard Biesheuvel wrote:
 On 17 August 2015 at 20:22, Jordan Justen jordan.l.jus...@intel.com wrote:
  Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead?
 
  I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be
  based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part
  of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if
  you count the comment in tools_def :) This is why I'd rather deprecate
  it as a toolchain, and use the GCC4X toolchains instead.
 
 
 No, you can't really.
 
 MinGW generates PE/COFF not ELF, so much of the linker command line is
 different, and it really deserves a toolchain of its own

Why does it deserve a toolchain of its own if the other toolchain
produces better code? Why should EDK II care about using the different
linker path if it isn't the best recommended way to build images?

 Making version 4.3.0 part of the definition of UNIXGCC sounds awkward
 to me. In fact, the idea of supporting all toolchains into eternity
 sounds awkward, and it is obviously not working, since many are
 deprecated and don't work at all or only partially. It would be much
 better imo to allow a definition like UNIXGCC to evolve with the state
 of the art

I mostly agree, but I would rather see us add new toolchains and
deprecate the old ones rather than evolving the requirements for a
particular toolchain.

I think the name UNIXGCC is too generic and too short sighted. It made
sense at the time, but I don't think we should keep moving it forward
and turn it into a moving target.

The MYTOOLS toolchain was what you are describing, but for MSVC. It
looks like it is stuck at VS2008 though. Anyway, I guess we should
also deprecate MYTOOLS. :)

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


Re: [edk2] [PATCH v2 00/16] unify GCC command line options

2015-08-17 Thread Jordan Justen
On 2015-08-17 11:25:41, David Woodhouse wrote:
 On Mon, 2015-08-17 at 11:22 -0700, Jordan Justen wrote:
  Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead?
 
 Not for testing LLP64, no.

How/who is this helping?

  I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be
  based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part
  of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if
  you count the comment in tools_def :) This is why I'd rather deprecate
  it as a toolchain, and use the GCC4X toolchains instead.
 
 Or kill UNIXGCC and replace it with MINGWGCC so the historical baggage
 is lost.

Maybe MINGW49. But, please not before we figure out how to actually
deprecate toolchains. :)

By 'figure out', I mean get to the point where we are okay with
actually deprecating toolchains.

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


Re: [edk2] [PATCH v2 00/16] unify GCC command line options

2015-08-17 Thread Ard Biesheuvel
On 17 August 2015 at 20:22, Jordan Justen jordan.l.jus...@intel.com wrote:
 On 2015-08-17 11:10:57, Bill Paul wrote:
 Of all the gin joints in all the towns in all the world, David Woodhouse had
 to walk into mine at 11:00:23 on Monday 17 August 2015 and say:

  On Mon, 2015-08-17 at 10:53 -0700, Jordan Justen wrote:
   UNIXGCC and CYGGCC are GCC 4.3  mingw based. Did this get tested?
  
   I think ELFGCC is unused at this point. (And has been since UnixPkg
   was deprecated.)
  
   I think we should deprecate all three of these toolchains. I would
   like to see us move them to BaseTools/Conf/tools_def.deprecated. I'll
   add Larry to this email, because I think he disagrees with
   deprecating
   toolchains...
  
   If you make these changes and it breaks those toolchains, I don't
   think we would be able to notice, because I don't think we test them
   in our build pool anymore. To me this is all the more reason to move
   them out of tools_def.template.
 
  I was building with UNIXGCC last week, to test LLP64 builds without the
  pain of actually having to deal with Windows.
 
  I'd rather see it updated to work with modern MinGW rather than
  deprecated.

 I use UNIXGCC with the cross-compiler toolchain generated by mingw-gcc-
 build.py. Yes, I know the existing version of the script uses GCC 4.3.0.
 That's why I made an updated version that uses 4.9.3:

 http://people.freebsd.org/~wpaul/edk2/mingw-gcc-build.py

 I know you don't want to support this script, that's why I did the work for
 you. :) Yes I've tested both IA32 and X64 builds. Yes they work fine.

 There is value in being able to bootstrap your own cross-build toolchain on
 whatever platform. I don't think you should be so quick to remove it.

 Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead?

 I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be
 based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part
 of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if
 you count the comment in tools_def :) This is why I'd rather deprecate
 it as a toolchain, and use the GCC4X toolchains instead.


No, you can't really.

MinGW generates PE/COFF not ELF, so much of the linker command line is
different, and it really deserves a toolchain of its own

Making version 4.3.0 part of the definition of UNIXGCC sounds awkward
to me. In fact, the idea of supporting all toolchains into eternity
sounds awkward, and it is obviously not working, since many are
deprecated and don't work at all or only partially. It would be much
better imo to allow a definition like UNIXGCC to evolve with the state
of the art
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v2 00/16] unify GCC command line options

2015-08-17 Thread David Woodhouse
On Mon, 2015-08-17 at 11:22 -0700, Jordan Justen wrote:
 Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead?

Not for testing LLP64, no.

 I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be
 based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part
 of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if
 you count the comment in tools_def :) This is why I'd rather deprecate
 it as a toolchain, and use the GCC4X toolchains instead.

Or kill UNIXGCC and replace it with MINGWGCC so the historical baggage
is lost.

-- 
dwmw2




smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] System is restarting instead of shut down when ResetSystem is called

2015-08-17 Thread Fernando Arpini
Hi, I have an application that runs in DXE phase. It executes some code and 
then call
ResetSystem() from RunTimeServices
to shut down the system (consider that the OS has put the system in
S4 state previously, and this app is being called right
after system resumes from S4). The system goes down, however,
after ~4 seconds,
it restarts automatically. Trying to investigate
this issue, I observed
that it only happens when there is(are)
some USB device(s) connected to the system (e.g., mouse,
keyboard, pen-drive), and the system was
returned from S4. In the case where there is(are) no
USB device(s)
connected, even if the system was returned
from S4, the system shuts down and does not restart.

 

Scenario 1: USB device(s)
+ resume from S4 = shut down and restart.

Scenario 2: no USB device(s)
+ resume from S4 = shut down.

Scenario 3: USB device(s)
+ resume from S5 = shut down.

Scenario 4: no USB device(s)
+ resume from S5 = shut down.

 

On Scenario 1, for instance, I think
a USB device is waking up the system after it is
turned off. Do you know why this issue happens
and how to circumvent it? 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH] ArmPkg: remove ARMv6 support code

2015-08-17 Thread Ard Biesheuvel
No platforms use the ARMv6 (ARM11) support code anymore. In fact, the
only reference to it in ArmPkg.dsc was commented out by Andrew in SVN
r11298 (2011-02-03) so it may well be broken. So remove it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
 ArmPkg/ArmPkg.dsc  |   4 -
 ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11Lib.c |  37 ---
 .../ArmCpuLib/Arm11MpCoreLib/Arm11MpCoreLib.inf|  32 ---
 ArmPkg/Library/ArmLib/Arm11/Arm11Lib.c |  49 
 ArmPkg/Library/ArmLib/Arm11/Arm11Lib.inf   |  50 
 ArmPkg/Library/ArmLib/Arm11/Arm11LibMem.c  | 135 ---
 ArmPkg/Library/ArmLib/Arm11/Arm11LibPrePi.inf  |  50 
 ArmPkg/Library/ArmLib/Arm11/Arm11LibSec.inf|  46 
 ArmPkg/Library/ArmLib/Arm11/Arm11Support.S | 257 -
 ArmPkg/Library/ArmLib/Arm11/Arm11Support.asm   | 157 -
 10 files changed, 817 deletions(-)
 delete mode 100644 ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11Lib.c
 delete mode 100644 ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11MpCoreLib.inf
 delete mode 100644 ArmPkg/Library/ArmLib/Arm11/Arm11Lib.c
 delete mode 100644 ArmPkg/Library/ArmLib/Arm11/Arm11Lib.inf
 delete mode 100644 ArmPkg/Library/ArmLib/Arm11/Arm11LibMem.c
 delete mode 100644 ArmPkg/Library/ArmLib/Arm11/Arm11LibPrePi.inf
 delete mode 100644 ArmPkg/Library/ArmLib/Arm11/Arm11LibSec.inf
 delete mode 100644 ArmPkg/Library/ArmLib/Arm11/Arm11Support.S
 delete mode 100644 ArmPkg/Library/ArmLib/Arm11/Arm11Support.asm

diff --git a/ArmPkg/ArmPkg.dsc b/ArmPkg/ArmPkg.dsc
index 10e8a1a83d46..1237eed65953 100644
--- a/ArmPkg/ArmPkg.dsc
+++ b/ArmPkg/ArmPkg.dsc
@@ -152,10 +152,6 @@ [Components.ARM]
   ArmPkg/Drivers/ArmCpuLib/ArmCortexA9Lib/ArmCortexA9Lib.inf
   ArmPkg/Drivers/ArmCpuLib/ArmCortexA15Lib/ArmCortexA15Lib.inf
 
-#  ArmPkg/Library/ArmLib/Arm11/Arm11ArmLib.inf
-#  ArmPkg/Library/ArmLib/Arm11/Arm11ArmLibPrePi.inf
-#  ArmPkg/Library/ArmLib/Arm9/Arm9ArmLib.inf
-#  ArmPkg/Library/ArmLib/Arm9/Arm9ArmLibPrePi.inf
   ArmPkg/Library/ArmLib/ArmV7/ArmV7LibSec.inf
   ArmPkg/Library/ArmLib/ArmV7/ArmV7LibPrePi.inf
 
diff --git a/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11Lib.c 
b/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11Lib.c
deleted file mode 100644
index a08b7b1aee3f..
--- a/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11Lib.c
+++ /dev/null
@@ -1,37 +0,0 @@
-/** @file
-
-  Copyright (c) 2011-2012, ARM Limited. All rights reserved.
-
-  This program and the accompanying materials
-  are licensed and made available under the terms and conditions of the BSD 
License
-  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 Base.h
-#include Library/ArmLib.h
-#include Library/ArmCpuLib.h
-#include Library/IoLib.h
-#include Library/PcdLib.h
-
-VOID
-ArmCpuSetup (
-  IN  UINTN MpId
-  )
-{
-  ASSERT(0); //TODO: Implement me
-}
-
-
-VOID
-ArmCpuSetupSmpNonSecure (
-  IN  UINTN MpId
-  )
-{
-  ASSERT(0); //TODO: Implement me
-}
-
diff --git a/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11MpCoreLib.inf 
b/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11MpCoreLib.inf
deleted file mode 100644
index 3a796c19d0cc..
--- a/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11MpCoreLib.inf
+++ /dev/null
@@ -1,32 +0,0 @@
-#/* @file
-#  Copyright (c) 2011-2012, ARM Limited. All rights reserved.
-#
-#  This program and the accompanying materials
-#  are licensed and made available under the terms and conditions of the BSD 
License
-#  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.
-#
-#*/
-
-[Defines]
-  INF_VERSION= 0x00010005
-  BASE_NAME  = Arm11MpCoreLib
-  FILE_GUID  = dc8a69e0-6be0-469c-94d3-5e6d71aa9808
-  MODULE_TYPE= BASE
-  VERSION_STRING = 1.0
-  LIBRARY_CLASS  = ArmCpuLib
-
-[Packages]
-  MdePkg/MdePkg.dec
-  ArmPkg/ArmPkg.dec
-
-[LibraryClasses]
-  ArmLib
-  IoLib
-  PcdLib
-
-[Sources.common]
-  Arm11Lib.c
diff --git a/ArmPkg/Library/ArmLib/Arm11/Arm11Lib.c 
b/ArmPkg/Library/ArmLib/Arm11/Arm11Lib.c
deleted file mode 100644
index 8c54b6cc8fd5..
--- a/ArmPkg/Library/ArmLib/Arm11/Arm11Lib.c
+++ /dev/null
@@ -1,49 +0,0 @@
-/** @file
-
-  Copyright (c) 2008 - 2009, Apple Inc. All rights reserved.BR
-  Copyright (c) 2011 - 2014, ARM Limited. All rights reserved.
-
-  This program and the accompanying materials
-  are licensed 

[edk2] [PATCH 2/2] BaseTools GCC: update mingw-gcc-build.py to GCC 4.9.3

2015-08-17 Thread Ard Biesheuvel
This updates mingw-gcc-build.py to the newest version of GCC currently
supported by the EDK2 build system, which is 4.9.3. At the same time,
binutils is updated to version 2.24.51.0.2.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
 BaseTools/gcc/mingw-gcc-build.py | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/BaseTools/gcc/mingw-gcc-build.py b/BaseTools/gcc/mingw-gcc-build.py
index 4b697c4382af..908589b52ba6 100755
--- a/BaseTools/gcc/mingw-gcc-build.py
+++ b/BaseTools/gcc/mingw-gcc-build.py
@@ -210,8 +210,8 @@ class SourceFiles:
 'binutils': {
 'url': 'http://www.kernel.org/pub/linux/devel/binutils/' + \
'binutils-$version.tar.bz2',
-'version': '2.20.51.0.5',
-'md5': '6d2de7cdf7a8389e70b124e3d73b4d37',
+'version': '2.24.51.0.2',
+'md5': 'c116833f7807d766bf68511ca271c821',
 },
 }
 
@@ -219,8 +219,8 @@ class SourceFiles:
 'gcc': {
 'url': 'http://ftpmirror.gnu.org/gcc/' + \
'gcc-$version/gcc-$version.tar.bz2',
-'version': '4.3.0',
-'md5': '197ed8468b38db1d3481c3111691d85b',
+'version': '4.9.3',
+'md5': '6f831b4d251872736e8e9cc09746f327',
 },
 }
 
-- 
1.9.1

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


Re: [edk2] [PATCH v2 00/16] unify GCC command line options

2015-08-17 Thread David Woodhouse
See http://www.infradead.org/rpr.html
X-SRS-Rewrite: SMTP reverse-path rewritten from dw...@infradead.org by 
twosheds.infradead.org
See http://www.infradead.org/rpr.html


 On 2015-08-17 11:25:41, David Woodhouse wrote:
 On Mon, 2015-08-17 at 11:22 -0700, Jordan Justen wrote:
  Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead?

 Not for testing LLP64, no.

 How/who is this helping?

It was massively useful for testing the OpenSSL stuff I've been working on
recently. It showed up a number of issues which would otherwise only occur
a Windows build.

  I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be
  based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part
  of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if
  you count the comment in tools_def :) This is why I'd rather deprecate
  it as a toolchain, and use the GCC4X toolchains instead.

 Or kill UNIXGCC and replace it with MINGWGCC so the historical baggage
 is lost.

 Maybe MINGW49. But, please not before we figure out how to actually
 deprecate toolchains. :)

 By 'figure out', I mean get to the point where we are okay with
 actually deprecating toolchains.

Deprecating toolchains is pointless until we can ditch the badly
maintained 20th century crap that holds us back from using C99 code. Once
we have the political will to say here's a nickel, kid. Buy yourself a
real compiler and provide Windows-hosted GCC or LLVM based toolchains,
there really is no point.


-- 
dwmw2

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


[edk2] PCI driver issue

2015-08-17 Thread Leekha Shaveta
Hi,



I was trying to run network using PCI. Have written PCI hostBridge driver for 
my controller, using PCI bus driver from MdeModulePkg(as it is).

PCI NIC card I am using is from Intel, and I have picked its driver from 
Intel's source.

But after integrating it in UEFI, I am facing issues.



drivers command gives following output:



Shell drivers

 T   D

 Y C I

 P F A

DRV VERSION  E G G #D  #C  DRIVER NAME IMAGE PATH

===  = = = === === === ==

39 04040600 ? Y Y   0   0 Intel(R) PRO/1000 4.4.06 PCI-E  
MemoryMapped(0xB,0xFF80D000,0xFFBEA167)/FvFile(BB801A52-C90F-4EDE-91B2-82520888CBC3)


But on running dh command, I don't see any such driver in the list.

What am I missing here?


Regards,
Shaveta

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


Re: [edk2] [PATCH v2] MdeModulePkg: IP4 should re-initiate a DHCP while network reconnection

2015-08-17 Thread Ye, Ting
Reviewed-by: Ye Ting ting...@intel.com 

-Original Message-
From: Wu, Jiaxin 
Sent: Monday, August 17, 2015 11:25 AM
To: edk2-devel@lists.01.org
Cc: Ye, Ting; Zhang, Lubo
Subject: [PATCH v2] MdeModulePkg: IP4 should re-initiate a DHCP while network 
reconnection

v2:
* Update the MediaPresent detect declaring.

IP4 driver should re-initiate a DHCP if it detects that there is a network 
reconnection.
To fix this issue, we can implement the DHCP re-initiate policy while the media 
change detected. The Ip4 driver should set a timer to signal the Ip4 to run the 
DHCP configuration again(D.O.R.A). IP4 driver should free old IP address 
related resource, then initiate a DHCP process to acquire new IP.

Cc: Ye Ting ting...@intel.com
Cc: Zhang Lubo lubo.zh...@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu jiaxin...@intel.com
---
 .../Universal/Network/Ip4Dxe/Ip4Config2Impl.c  |   1 +
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c  |  10 ++
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c| 121 -
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.h|   7 ++
 4 files changed, 133 insertions(+), 6 deletions(-)

diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c 
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
index fcb2bdd..caf84fb 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
@@ -490,10 +490,11 @@ Ip4Config2SetDefaultAddr (
   IpSb = IP4_SERVICE_FROM_IP4_CONFIG2_INSTANCE (Instance);
   IpIf = IpSb-DefaultInterface;
   ASSERT (IpIf != NULL);
 
   if ((IpIf-Ip == StationAddress)  (IpIf-SubnetMask == SubnetMask)) {
+IpSb-State = IP4_SERVICE_CONFIGED;
 return EFI_SUCCESS;
   }
 
   //
   // The default address is changed, free the previous interface first.
diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c 
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
index 101390c..4d3ccec 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
@@ -208,10 +208,14 @@ Ip4CreateService (
 
   ZeroMem (IpSb-SnpMode, sizeof (EFI_SIMPLE_NETWORK_MODE));
 
   IpSb-Timer = NULL;
 
+  IpSb-ReconfigEvent = NULL;
+  
+  IpSb-MediaPresent = TRUE;
+
   //
   // Create various resources. First create the route table, timer
   // event and MNP child. IGMP, interface's initialization depend
   // on the MNP child.
   //
@@ -384,10 +388,16 @@ Ip4CleanService (
 gBS-CloseEvent (IpSb-Timer);
 
 IpSb-Timer = NULL;
   }
 
+  if (IpSb-ReconfigEvent != NULL) {
+gBS-CloseEvent (IpSb-ReconfigEvent);
+
+IpSb-ReconfigEvent = NULL;
+  }
+
   if (IpSb-MacString != NULL) {
 FreePool (IpSb-MacString);
   }
 
   Ip4Config2CleanInstance (IpSb-Ip4Config2Instance); diff --git 
a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c 
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
index 2fb4f4c..ac8fb1a 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
@@ -561,10 +561,58 @@ Ip4InitProtocol (
 
   EfiInitializeLock (IpInstance-RecycleLock, TPL_NOTIFY);  }
 
 
+/**
+  The event handle for IP4 auto reconfiguration. The original default
+  interface and route table will be removed as the default.
+
+  @param[in]  ContextThe IP4 service binding instance.
+
+**/
+VOID
+EFIAPI
+Ip4AutoReconfigCallBackDpc (
+  IN VOID   *Context
+  )
+{
+  IP4_SERVICE   *IpSb;
+
+  IpSb  = (IP4_SERVICE *) Context;
+  NET_CHECK_SIGNATURE (IpSb, IP4_SERVICE_SIGNATURE);
+
+  if (IpSb-State  IP4_SERVICE_UNSTARTED) {
+IpSb-State = IP4_SERVICE_UNSTARTED;  }
+
+  Ip4StartAutoConfig (IpSb-Ip4Config2Instance);
+
+  return ;
+}
+
+
+/**
+  Request Ip4AutoReconfigCallBackDpc as a DPC at TPL_CALLBACK.
+
+  @param Event The event that is signalled.
+  @param Context   The IP4 service binding instance.
+
+**/
+VOID
+EFIAPI
+Ip4AutoReconfigCallBack (
+  IN EFI_EVENT  Event,
+  IN VOID   *Context
+  )
+{
+  //
+  // Request Ip4AutoReconfigCallBackDpc as a DPC at TPL_CALLBACK
+  //
+  QueueDpc (TPL_CALLBACK, Ip4AutoReconfigCallBackDpc, Context); }
+
 
 /**
   Configure the IP4 child. If the child is already configured,
   change the configuration parameter. Otherwise configure it
   for the first time. The caller should validate the configuration @@ -676,14 
+724,31 @@ Ip4ConfigProtocol (
 //
 // Use the default address. If the default configuration hasn't
 // been started, start it.
 //
 if (IpSb-State == IP4_SERVICE_UNSTARTED) {
+  //
+  // Create the ReconfigEvent to start the new configuration.
+  //
+  if (IpSb-ReconfigEvent == NULL) {
+Status = gBS-CreateEvent (
+EVT_NOTIFY_SIGNAL,
+TPL_NOTIFY,
+Ip4AutoReconfigCallBack,
+IpSb,
+

[edk2] Emulator not spawning window, triggering breakpoint instead

2015-08-17 Thread David Van Arnem

Hi all,

About a week or two ago I was able to start the emulator + shell (Fedora 
22 64-bit host) using:


$ sh EmulatorPkg/build.sh run

However, after re-cloning the git repository today and trying the same 
process, a breakpoint is instead triggered somewhere in PeiCore (I 
believe).  If I run continue from gdb twice, the application segfaults 
and exits.  I tried looking through the commit history to see if 
anything changed, but I've been unable to find anything.  Does anyone 
have suggestions on how I can get this going again?


Full output below.

Thanks,
David

 sh EmulatorPkg/build.sh run
Building from: path/edk2
using prebuilt tools
Reading symbols from path/edk2/Build/Emulator/DEBUG_GCC49/X64/Host...done.
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib64/libthread_db.so.1.

EDK II UNIX Host Emulation Environment from http://www.tianocore.org/edk2/
  BootMode 0x00
  OS Emulator passing in 128 KB of temp RAM at 0x4000 to SEC
  FD loaded from ../FV/FV_RECOVERY.fd at 0x10200 contains SEC Core

0x1020003e0 Loading 
path/edk2/Build/Emulator/DEBUG_GCC49/X64/EmulatorPkg/Sec/Sec/DEBUG/EmuSec.dll 
with entry point 0x1020003e0

SEC Has Started
0x1020052e0 Loading 
path/edk2/Build/Emulator/DEBUG_GCC49/X64/MdeModulePkg/Core/Pei/PeiMain/DEBUG/PeiCore.dll 
with entry point 0x1020052e0


Program received signal SIGTRAP, Trace/breakpoint trap.
add symbol table from file 
path/edk2/Build/Emulator/DEBUG_GCC49/X64/EmulatorPkg/Sec/Sec/DEBUG/EmuSec.dll 
at

.text_addr = 0x1020003e0
add symbol table from file 
path/edk2/Build/Emulator/DEBUG_GCC49/X64/MdeModulePkg/Core/Pei/PeiMain/DEBUG/PeiCore.dll 
at

.text_addr = 0x1020052e0
CpuBreakpoint () at path/edk2/MdePkg/Library/BaseLib/X64/GccInline.c:107
107 }

(gdb) continue

Continuing.
0x10202af00 Loading 
path/edk2/Build/Emulator/DEBUG_GCC49/X64/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei/DEBUG/StatusCodeHandlerPei.dll 
with entry point 0x10202af00


Program received signal SIGTRAP, Trace/breakpoint trap.
add symbol table from file 
path/edk2/Build/Emulator/DEBUG_GCC49/X64/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei/DEBUG/StatusCodeHandlerPei.dll 
at

.text_addr = 0x10202af00
CpuBreakpoint () at path/edk2/MdePkg/Library/BaseLib/X64/GccInline.c:107
107 }

(gdb) continue

Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x00010202b196 in StatusCodeHandlerPeiEntry (FileHandle=0x10202ac68, 
PeiServices=0x4000f878) at 
path/edk2/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.c:57
57  Status = RscHandlerPpi-Register 
(SerialStatusCodeReportWorker);

(gdb)

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


[edk2] [MinnowBoard] i2cdetect inconsistency/problem

2015-08-17 Thread Gerard Bucas

Hi All,

I have some problems and inconsistencies on i2c bus on my minnowBoard MAX.
Two problems:

1. When I run i2cdetect -l  on the same board with my yocto project build
and then again with running Ubuntu 14.04.3 LTS I get different listing for
i2c buses.

2. Even though I have no lures attached (so basic MinnowBoad MAX, A2 with
0.81 or 0.82 firmware - same result), i2cdetect -y N (where N is different
for yocto  Ubuntu) shows a number of i2c devices detected which I assume
should not be there!?

I have two questions:

1. Where does i2cdetect get the i2c adapter bus names? How can they be
different with same firmware  hardware  linux kernel (between yocto 
Ubuntu)? Is this from some firmware or OS config?

2. Why are all those i2c devices detected by BOTH yocto linux and Ubuntu!?
Where do they come from? Is this due to some firmware or OS config? 

Below are the i2cdetect outputs from both my yocto and Ubuntu OS's (NOTE:
both are using the linux 3.19 kernel):

YOCTO:
# uname -a
Linux intel-corei7-64 3.19.5-yocto-standard #1 SMP PREEMPT Fri Aug 14
00:21:30 UTC 2015 x86_64 GNU/Linux

#modprobe i2c-dev
#i2cdetect -l
i2c-0   i2c i915 gmbus ssc  I2C adapter
i2c-1   i2c i915 gmbus vga  I2C adapter
i2c-2   i2c i915 gmbus panelI2C adapter
i2c-3   i2c i915 gmbus dpc  I2C adapter
i2c-4   i2c i915 gmbus dpb  I2C adapter
i2c-5   i2c i915 gmbus dpd  I2C adapter
i2c-6   i2c DPDDC-B I2C adapter

#i2cdetect -y 4
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:  -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: 30 -- -- -- -- -- -- 37 -- -- 3a -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- 4a 4b -- -- -- -- 
50: 50 51 52 53 54 55 56 57 -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- -- 

UBUNTU:
# uname -a
Linux tekmagic 3.19.0-26-generic #28~14.04.1-Ubuntu SMP Wed Aug 12 14:09:17
UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

# modprobe i2c-dev

# i2cdetect -l
i2c-0   i2c Synopsys DesignWare I2C adapter I2C adapter
i2c-1   i2c Synopsys DesignWare I2C adapter I2C adapter
i2c-2   i2c i915 gmbus ssc  I2C adapter
i2c-3   i2c i915 gmbus vga  I2C adapter
i2c-4   i2c i915 gmbus panelI2C adapter
i2c-5   i2c i915 gmbus dpc  I2C adapter
i2c-6   i2c i915 gmbus dpb  I2C adapter
i2c-7   i2c i915 gmbus dpd  I2C adapter
i2c-8   i2c DPDDC-B I2C adapter

# i2cdetect -y 6
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:  -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: 30 -- -- -- -- -- -- 37 -- -- 3a -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- 4a 4b -- -- -- -- 
50: 50 51 52 53 54 55 56 57 -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- -- 

Thanks!!

Gerard

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


[edk2] [PATCH v2 2/2] OvmfPkg: Add HttpBoot support

2015-08-17 Thread Gary Ching-Pang Lin
This commit introdues a new build option to OvmfPkg: HTTP_BOOT_ENABLE.
When HttpBoot is enabled, a new Network boot option will show in the
boot manager menu with the device path like this:

PciRoot(0x0)/Pci(0x3,0x0)/MAC(525400123456,0x1)/IPv4(0.0.0.0)/Uri()

It works like the PXE one but fetches the NBP from the given http
url instead of the tftp service.

A simple testing environment can be set up with the QEMU tap network
and dnsmasq + lighttpd.

Here is the example of the dnsmasq config:

  interface=tap interface
  dhcp-range=192.168.111.100,192.168.111.120,12h
  dhcp-option=60,HTTPClient
  dhcp-boot=http://tap ip/efi file

It's similar to the PXE server settings except the tftp function is
disabled, the option 60 must be HTTPClient, and the boot uri is a
http url.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Ching-Pang Lin g...@suse.com
---
 OvmfPkg/OvmfPkgIa32.dsc| 10 ++
 OvmfPkg/OvmfPkgIa32.fdf|  5 +
 OvmfPkg/OvmfPkgIa32X64.dsc | 10 ++
 OvmfPkg/OvmfPkgIa32X64.fdf |  5 +
 OvmfPkg/OvmfPkgX64.dsc | 10 ++
 OvmfPkg/OvmfPkgX64.fdf |  5 +
 6 files changed, 45 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 4ab618d..9a6de15 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -35,6 +35,7 @@ [Defines]
   #
   DEFINE SECURE_BOOT_ENABLE  = FALSE
   DEFINE NETWORK_IP6_ENABLE  = FALSE
+  DEFINE HTTP_BOOT_ENABLE= FALSE
 
 [BuildOptions]
   GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
@@ -129,6 +130,10 @@ [LibraryClasses]
   
AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
 !endif
 
+!if $(HTTP_BOOT_ENABLE) == TRUE
+  HttpLib|MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.inf
+!endif
+
   
S3BootScriptLib|MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf
   SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
   
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
@@ -551,6 +556,11 @@ [Components]
   MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
   MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf
 !endif
+!if $(HTTP_BOOT_ENABLE) == TRUE
+  NetworkPkg/DnsDxe/DnsDxe.inf
+  NetworkPkg/HttpDxe/HttpDxe.inf
+  NetworkPkg/HttpBootDxe/HttpBootDxe.inf
+!endif
   OvmfPkg/VirtioNetDxe/VirtioNet.inf
 
   #
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index 16675f8..0e4ee49 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -324,6 +324,11 @@ [FV.DXEFV]
   INF  MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
   INF  MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf
 !endif
+!if $(HTTP_BOOT_ENABLE) == TRUE
+  INF  NetworkPkg/DnsDxe/DnsDxe.inf
+  INF  NetworkPkg/HttpDxe/HttpDxe.inf
+  INF  NetworkPkg/HttpBootDxe/HttpBootDxe.inf
+!endif
   INF  OvmfPkg/VirtioNetDxe/VirtioNet.inf
 
 #
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 90ca42a..2f8006d 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -35,6 +35,7 @@ [Defines]
   #
   DEFINE SECURE_BOOT_ENABLE  = FALSE
   DEFINE NETWORK_IP6_ENABLE  = FALSE
+  DEFINE HTTP_BOOT_ENABLE= FALSE
 
 [BuildOptions]
   GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
@@ -134,6 +135,10 @@ [LibraryClasses]
   
AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
 !endif
 
+!if $(HTTP_BOOT_ENABLE) == TRUE
+  HttpLib|MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.inf
+!endif
+
   
S3BootScriptLib|MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf
   SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
   
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
@@ -558,6 +563,11 @@ [Components.X64]
   MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
   MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf
 !endif
+!if $(HTTP_BOOT_ENABLE) == TRUE
+  NetworkPkg/DnsDxe/DnsDxe.inf
+  NetworkPkg/HttpDxe/HttpDxe.inf
+  NetworkPkg/HttpBootDxe/HttpBootDxe.inf
+!endif
   OvmfPkg/VirtioNetDxe/VirtioNet.inf
 
   #
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index e6c525a..74412d4 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -324,6 +324,11 @@ [FV.DXEFV]
   INF  MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
   INF  MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf
 !endif
+!if $(HTTP_BOOT_ENABLE) == TRUE
+  INF  NetworkPkg/DnsDxe/DnsDxe.inf
+  INF  NetworkPkg/HttpDxe/HttpDxe.inf
+  INF  NetworkPkg/HttpBootDxe/HttpBootDxe.inf
+!endif
   INF  OvmfPkg/VirtioNetDxe/VirtioNet.inf
 
 #
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index b72eaa9..5407d9d 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -35,6 +35,7 @@ [Defines]
   #
   DEFINE SECURE_BOOT_ENABLE  = FALSE
   

[edk2] [PATCH v2 1/2] NetworkPkg: Remove the hostname from the http request url

2015-08-17 Thread Gary Ching-Pang Lin
The hostname is already set in the header of the http request.
The url shouldn't contain the hostname since the hostname will
be prepended to the url when the server interprets the request.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Ching-Pang Lin g...@suse.com
Reviewed-by: Ye Ting ting...@intel.com
---
 NetworkPkg/HttpDxe/HttpImpl.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/NetworkPkg/HttpDxe/HttpImpl.c b/NetworkPkg/HttpDxe/HttpImpl.c
index 545fe42..030dcfe 100644
--- a/NetworkPkg/HttpDxe/HttpImpl.c
+++ b/NetworkPkg/HttpDxe/HttpImpl.c
@@ -227,6 +227,7 @@ EfiHttpRequest (
   CHAR16*HostNameStr;
   HTTP_TOKEN_WRAP   *Wrap;
   HTTP_TCP_TOKEN_WRAP   *TcpWrap;
+  CHAR8 *FileUrl;
 
   if ((This == NULL) || (Token == NULL)) {
 return EFI_INVALID_PARAMETER;
@@ -450,7 +451,18 @@ EfiHttpRequest (
   //
   // Create request message.
   //
-  RequestStr = HttpGenRequestString (HttpInstance, HttpMsg, Url);
+  FileUrl = Url;
+  while (*FileUrl != ':')
+FileUrl++;
+  if ((*(FileUrl+1) == '/')  (*(FileUrl+2) == '/')) {
+FileUrl += 3;
+while (*FileUrl != '/')
+  FileUrl++;
+  } else {
+Status = EFI_INVALID_PARAMETER;
+goto Error3;
+  }
+  RequestStr = HttpGenRequestString (HttpInstance, HttpMsg, FileUrl);
   if (RequestStr == NULL) {
 Status = EFI_OUT_OF_RESOURCES;
 goto Error3;
-- 
2.1.4

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


[edk2] [PATCH v2 0/2] Add HttpBoot support to OvmfPkg

2015-08-17 Thread Gary Ching-Pang Lin
V2: Updated my git config to generate the reviewer-friendly diff.

This patch series fixes a http request bug in HttpDxe and adds the
HttpBoot support to OvmfPkg.

I've tested the HttpBoot implementation with a simple environment:

[QEMU] ---(tap0)--- [HOST]
 Ovmf   DHCP server
HTTP server

With a proper config for the dhcp and http server in the host, the firmware
successfully fetched the remote EFI file and executed it. It's recommended
to update gnu-efi to the latest version to detect the IPv4 device path
correctly.

Known issues:
* DHCPv6 support is not implemented in HttpBootDxe at this moment.
* The unexpected TCP disconnection isn't handled properly in HttpDxe and the
  GET request may fail while fetching the EFI image from some featureless
  http daemon such as thttpd.

Gary Ching-Pang Lin (2):
  NetworkPkg: Remove the hostname from the http request url
  OvmfPkg: Add HttpBoot support

 NetworkPkg/HttpDxe/HttpImpl.c | 14 +-
 OvmfPkg/OvmfPkgIa32.dsc   | 10 ++
 OvmfPkg/OvmfPkgIa32.fdf   |  5 +
 OvmfPkg/OvmfPkgIa32X64.dsc| 10 ++
 OvmfPkg/OvmfPkgIa32X64.fdf|  5 +
 OvmfPkg/OvmfPkgX64.dsc| 10 ++
 OvmfPkg/OvmfPkgX64.fdf|  5 +
 7 files changed, 58 insertions(+), 1 deletion(-)

-- 
2.1.4

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


[edk2] [PATCH 00/15] Separate variable check service to library

2015-08-17 Thread Star Zeng
NOTICE: To keep git bisect, the update to platform package Nt32Pkg, OvmfPkg, 
EmulatorPkg,
ArmVirtPkg, ArmPlatformPkg and Vlv2TbltDevicePkg has been split to two patches.

For your easy review,
the forked code is at g...@github.com:lzeng14/edk2.git branch 
VariableCheckService.

What to do:
1. Add VarCheckLib library and VarCheckUefiLib NULL class library.
2. Update Variable driver to consume the separated VarCheckLib.
3. Update platform package to add VarCheckLib library mapping
and link separated VarCheckUefiLib NULL class library

Why to do: Share code.
Separate variable check service from Variable driver in MdeModulePkg.
We are going to separate generic software logic code from Variable Driver
to benefit other variable driver implementation. Auth services has been done
to be AuthVariableLib, now to cover variable check service.

What test done:
Nt32 and OVMF: Boot fine same with no code separation.
Internal real platform: Boot fine to OS.

What is the impact to platform: Only platform dsc need to be updated.

Star Zeng (15):
  MdeModulePkg: Add VarCheckLib library
  MdeModulePkg: Add VarCheckUefiLib NULL class library
  Nt32Pkg: Add VarCheckLib library mapping
  OvmfPkg: Add VarCheckLib library mapping
  EmulatorPkg: Add VarCheckLib library mapping
  ArmVirtPkg: Add VarCheckLib library mapping
  ArmPlatformPkg: Add VarCheckLib library mapping
  Vlv2TbltDevicePkg: Add VarCheckLib library mapping
  MdeModulePkg Variable: Consume the separated VarCheckLib
  Nt32Pkg: Link separated VarCheckUefiLib NULL class library instance
  OvmfPkg: Link separated VarCheckUefiLib NULL class library instance
  EmulatorPkg: Link separated VarCheckUefiLib NULL class library
instance
  ArmVirtPkg: Link separated VarCheckUefiLib NULL class library instance
  ArmPlatformPkg: Link separated VarCheckUefiLib NULL class library
instance
  Vlv2TbltDevicePkg: Link separated VarCheckUefiLib NULL class library
instance

 ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc  |5 +-
 .../ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc|5 +-
 .../ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc |5 +-
 .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc |5 +-
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc  |1 +
 ArmVirtPkg/ArmVirt.dsc.inc |1 +
 ArmVirtPkg/ArmVirtQemu.dsc |5 +-
 EmulatorPkg/EmulatorPkg.dsc|6 +-
 MdeModulePkg/Include/Library/VarCheckLib.h |  180 
 MdeModulePkg/Library/VarCheckLib/VarCheckLib.c |  632 +++
 MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf   |   51 +
 MdeModulePkg/Library/VarCheckLib/VarCheckLib.uni   |  Bin 0 - 1798 bytes
 .../Library/VarCheckUefiLib/VarCheckUefiLib.inf|   88 ++
 .../Library/VarCheckUefiLib/VarCheckUefiLib.uni|  Bin 0 - 2158 bytes
 .../VarCheckUefiLib/VarCheckUefiLibNullClass.c |  930 
 MdeModulePkg/MdeModulePkg.dec  |4 +
 MdeModulePkg/MdeModulePkg.dsc  |   13 +-
 .../Universal/Variable/RuntimeDxe/VarCheck.c   | 1117 +---
 .../Universal/Variable/RuntimeDxe/Variable.c   |  193 +---
 .../Universal/Variable/RuntimeDxe/Variable.h   |   97 +-
 .../Universal/Variable/RuntimeDxe/VariableDxe.c|   48 +-
 .../Variable/RuntimeDxe/VariableRuntimeDxe.inf |   15 +-
 .../Universal/Variable/RuntimeDxe/VariableSmm.c|   23 +-
 .../Universal/Variable/RuntimeDxe/VariableSmm.inf  |   15 +-
 Nt32Pkg/Nt32Pkg.dsc|6 +-
 OvmfPkg/OvmfPkgIa32.dsc|6 +-
 OvmfPkg/OvmfPkgIa32X64.dsc |6 +-
 OvmfPkg/OvmfPkgX64.dsc |6 +-
 Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc|2 +
 Vlv2TbltDevicePkg/PlatformPkgIA32.dsc  |2 +
 Vlv2TbltDevicePkg/PlatformPkgX64.dsc   |2 +
 31 files changed, 2045 insertions(+), 1424 deletions(-)
 create mode 100644 MdeModulePkg/Include/Library/VarCheckLib.h
 create mode 100644 MdeModulePkg/Library/VarCheckLib/VarCheckLib.c
 create mode 100644 MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
 create mode 100644 MdeModulePkg/Library/VarCheckLib/VarCheckLib.uni
 create mode 100644 MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
 create mode 100644 MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.uni
 create mode 100644 
MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c

-- 
1.9.5.msysgit.0

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


[edk2] [PATCH 02/15] MdeModulePkg: Add VarCheckUefiLib NULL class library

2015-08-17 Thread Star Zeng
What to do: Implement VarCheckUefiLib NULL class library instance.
The code logic are separated from Variable driver, and it will consume 
VarCheckLib
to register var check handler and variable property set for UEFI defined 
variables.

Why to do: Share code.
Separate variable check UEFI code from Variable driver in MdeModulePkg.
We are going to separate generic software logic code from Variable Driver
to benefit other variable driver implementation. Auth services has been done
to be AuthVariableLib, now to cover variable check service.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng star.z...@intel.com
Reviewed-by: Jiewen Yao jiewen@intel.com
---
 .../Library/VarCheckUefiLib/VarCheckUefiLib.inf|  88 ++
 .../Library/VarCheckUefiLib/VarCheckUefiLib.uni| Bin 0 - 2158 bytes
 .../VarCheckUefiLib/VarCheckUefiLibNullClass.c | 930 +
 3 files changed, 1018 insertions(+)
 create mode 100644 MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
 create mode 100644 MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.uni
 create mode 100644 
MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c

diff --git a/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf 
b/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
new file mode 100644
index 000..ecfe6b3
--- /dev/null
+++ b/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
@@ -0,0 +1,88 @@
+## @file
+#  NULL class library to register var check handler and variable property set 
for UEFI defined variables.
+#
+#  Copyright (c) 2015, Intel Corporation. All rights reserved.BR
+#
+#  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.
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = VarCheckUefiLib
+  MODULE_UNI_FILE= VarCheckUefiLib.uni
+  FILE_GUID  = AC24A4C7-F845-4665-90E5-6431D6E28DC0
+  MODULE_TYPE= DXE_RUNTIME_DRIVER
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = NULL|DXE_RUNTIME_DRIVER DXE_SMM_DRIVER
+  CONSTRUCTOR= VarCheckUefiLibNullClassConstructor
+
+#
+# The following information is for reference only and not required by the 
build tools.
+#
+#  VALID_ARCHITECTURES   = IA32 X64
+#
+
+[Sources]
+  VarCheckUefiLibNullClass.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+
+[LibraryClasses]
+  BaseLib
+  BaseMemoryLib
+  DebugLib
+  DevicePathLib
+  VarCheckLib
+
+[Guids]
+  ## SOMETIMES_CONSUMES  ## Variable:LLangCodes
+  ## SOMETIMES_CONSUMES  ## Variable:LLang
+  ## SOMETIMES_CONSUMES  ## Variable:LTimeout
+  ## SOMETIMES_CONSUMES  ## Variable:LPlatformLangCodes
+  ## SOMETIMES_CONSUMES  ## Variable:LPlatformLang
+  ## SOMETIMES_CONSUMES  ## Variable:LConIn
+  ## SOMETIMES_CONSUMES  ## Variable:LConOut
+  ## SOMETIMES_CONSUMES  ## Variable:LErrOut
+  ## SOMETIMES_CONSUMES  ## Variable:LConInDev
+  ## SOMETIMES_CONSUMES  ## Variable:LConOutDev
+  ## SOMETIMES_CONSUMES  ## Variable:LErrOutDev
+  ## SOMETIMES_CONSUMES  ## Variable:LBootOrder
+  ## SOMETIMES_CONSUMES  ## Variable:LBootNext
+  ## SOMETIMES_CONSUMES  ## Variable:LBootCurrent
+  ## SOMETIMES_CONSUMES  ## Variable:LBootOptionSupport
+  ## SOMETIMES_CONSUMES  ## Variable:LDriverOrder
+  ## SOMETIMES_CONSUMES  ## Variable:LSysPrepOrder
+  ## SOMETIMES_CONSUMES  ## Variable:LHwErrRecSupport
+  ## SOMETIMES_CONSUMES  ## Variable:LSetupMode
+  ## SOMETIMES_CONSUMES  ## Variable:LPK
+  ## SOMETIMES_CONSUMES  ## Variable:LKEK
+  ## SOMETIMES_CONSUMES  ## Variable:LSignatureSupport
+  ## SOMETIMES_CONSUMES  ## Variable:LSecureBoot
+  ## SOMETIMES_CONSUMES  ## Variable:LKEKDefault
+  ## SOMETIMES_CONSUMES  ## Variable:LPKDefault
+  ## SOMETIMES_CONSUMES  ## Variable:LdbDefault
+  ## SOMETIMES_CONSUMES  ## Variable:LdbxDefault
+  ## SOMETIMES_CONSUMES  ## Variable:LdbtDefault
+  ## SOMETIMES_CONSUMES  ## Variable:LOsIndicationsSupported
+  ## SOMETIMES_CONSUMES  ## Variable:LOsIndications
+  ## SOMETIMES_CONSUMES  ## Variable:LVendorKeys
+  ## SOMETIMES_CONSUMES  ## Variable:LBoot
+  ## SOMETIMES_CONSUMES  ## Variable:LDriver
+  ## SOMETIMES_CONSUMES  ## Variable:LSysPrep
+  ## SOMETIMES_CONSUMES  ## Variable:LKey
+  gEfiGlobalVariableGuid
+  ## SOMETIMES_CONSUMES  ## Variable:LDB
+  ## SOMETIMES_CONSUMES  ## Variable:LDBX
+  ## SOMETIMES_CONSUMES  ## Variable:LDBT
+  gEfiImageSecurityDatabaseGuid
+  gEfiHardwareErrorVariableGuid  ## SOMETIMES_CONSUMES   ## 
Variable:LHwErrRec
diff --git 

[edk2] [PATCH 09/15] MdeModulePkg Variable: Consume the separated VarCheckLib

2015-08-17 Thread Star Zeng
Since the variable check service has be separated to VarCheckLib
from Variable driver, so update Variable driver to consume the
separated VarCheckLib.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng star.z...@intel.com
Reviewed-by: Jiewen Yao jiewen@intel.com
---
 MdeModulePkg/MdeModulePkg.dsc  |   13 +-
 .../Universal/Variable/RuntimeDxe/VarCheck.c   | 1117 +---
 .../Universal/Variable/RuntimeDxe/Variable.c   |  193 +---
 .../Universal/Variable/RuntimeDxe/Variable.h   |   97 +-
 .../Universal/Variable/RuntimeDxe/VariableDxe.c|   48 +-
 .../Variable/RuntimeDxe/VariableRuntimeDxe.inf |   15 +-
 .../Universal/Variable/RuntimeDxe/VariableSmm.c|   23 +-
 .../Universal/Variable/RuntimeDxe/VariableSmm.inf  |   15 +-
 8 files changed, 107 insertions(+), 1414 deletions(-)

diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
index 20edc08..7b14e61 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -97,6 +97,7 @@ [LibraryClasses]
   
PlatformBootManagerLib|MdeModulePkg/Library/PlatformBootManagerLibNull/PlatformBootManagerLibNull.inf
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
   
AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
+  VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
 
 [LibraryClasses.EBC.PEIM]
   IoLib|MdePkg/Library/PeiIoLibCpuIo/PeiIoLibCpuIo.inf
@@ -277,6 +278,8 @@ [Components]
   
MdeModulePkg/Library/PlatformBootManagerLibNull/PlatformBootManagerLibNull.inf
   MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
   MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
+  MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
+  MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
 
   MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
   MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenuApp.inf
@@ -369,13 +372,19 @@ [Components.IA32, Components.X64, Components.IPF]
   MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
 
 [Components.IA32, Components.X64, Components.Ebc]
-  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+LibraryClasses
+  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+  }
   MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntimeDxe.inf
   
 [Components.IA32, Components.X64]
   MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
   MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
-  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
+  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf {
+LibraryClasses
+  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+  }
   MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
   MdeModulePkg/Library/SmmReportStatusCodeLib/SmmReportStatusCodeLib.inf
   MdeModulePkg/Universal/StatusCodeHandler/Smm/StatusCodeHandlerSmm.inf
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VarCheck.c 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VarCheck.c
index 27b4801..ad56a9f 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VarCheck.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VarCheck.c
@@ -1,5 +1,6 @@
 /** @file
-  Implementation functions and structures for var check protocol.
+  Implementation functions and structures for var check protocol
+  and variable lock protocol based on VarCheckLib.
 
 Copyright (c) 2015, Intel Corporation. All rights reserved.BR
 This program and the accompanying materials
@@ -13,900 +14,53 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 **/
 
 #include Variable.h
-#include Library/DevicePathLib.h
-
-extern LIST_ENTRY mLockedVariableList;
-extern BOOLEAN mEndOfDxe;
-extern BOOLEAN mEnableLocking;
-
-#define VAR_CHECK_HANDLER_TABLE_SIZE0x8
-
-UINT32  mNumberOfHandler = 0;
-UINT32  mMaxNumberOfHandler = 0;
-VAR_CHECK_SET_VARIABLE_CHECK_HANDLER*mHandlerTable = NULL;
-
-typedef struct {
-  LIST_ENTRYLink;
-  EFI_GUID  Guid;
-  VAR_CHECK_VARIABLE_PROPERTY   VariableProperty;
-  //CHAR16*Name;
-} VAR_CHECK_VARIABLE_ENTRY;
-
-LIST_ENTRY mVarCheckVariableList = INITIALIZE_LIST_HEAD_VARIABLE 
(mVarCheckVariableList);
-
-typedef
-EFI_STATUS
-(EFIAPI *INTERNAL_VAR_CHECK_FUNCTION) (
-  IN VAR_CHECK_VARIABLE_PROPERTY*Propery,
-  IN UINTN  DataSize,
-  IN VOID   *Data
-  );
-
-typedef struct {
-  CHAR16*Name;
-  VAR_CHECK_VARIABLE_PROPERTY   VariableProperty;
-  INTERNAL_VAR_CHECK_FUNCTION   CheckFunction;
-} UEFI_DEFINED_VARIABLE_ENTRY;
-
-/**
-  Internal check for load option.
-
-  @param[in] VariableProperyPointer to variable property.
-  @param[in] DataSize   

[edk2] [PATCH 04/15] OvmfPkg: Add VarCheckLib library mapping

2015-08-17 Thread Star Zeng
Since Variable driver has been updated to consume the separated VarCheckLib.

Cc: Jordan Justen jordan.l.jus...@intel.com
Cc: Laszlo Ersek ler...@redhat.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng star.z...@intel.com
---
 OvmfPkg/OvmfPkgIa32.dsc| 1 +
 OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
 OvmfPkg/OvmfPkgX64.dsc | 1 +
 3 files changed, 3 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 4ab618d..df00011 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -128,6 +128,7 @@ [LibraryClasses]
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
   
AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
 !endif
+  VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
 
   
S3BootScriptLib|MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf
   SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 90ca42a..355ed6a 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -133,6 +133,7 @@ [LibraryClasses]
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
   
AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
 !endif
+  VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
 
   
S3BootScriptLib|MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf
   SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index b72eaa9..4469bd1 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -133,6 +133,7 @@ [LibraryClasses]
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
   
AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
 !endif
+  VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
 
   
S3BootScriptLib|MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf
   SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
-- 
1.9.5.msysgit.0

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


[edk2] [PATCH 13/15] ArmVirtPkg: Link separated VarCheckUefiLib NULL class library instance

2015-08-17 Thread Star Zeng
Cc: Laszlo Ersek ler...@redhat.com
Cc: Ard Biesheuvel ard.biesheu...@linaro.org
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng star.z...@intel.com
---
 ArmVirtPkg/ArmVirtQemu.dsc | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 216f130..f1af968 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -256,7 +256,10 @@ [Components.common]
   #
   ArmPkg/Drivers/CpuDxe/CpuDxe.inf
   MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
-  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+LibraryClasses
+  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+  }
 !if $(SECURE_BOOT_ENABLE) == TRUE
   MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
 LibraryClasses
-- 
1.9.5.msysgit.0

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


[edk2] [PATCH 11/15] OvmfPkg: Link separated VarCheckUefiLib NULL class library instance

2015-08-17 Thread Star Zeng
Cc: Jordan Justen jordan.l.jus...@intel.com
Cc: Laszlo Ersek ler...@redhat.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng star.z...@intel.com
---
 OvmfPkg/OvmfPkgIa32.dsc| 5 -
 OvmfPkg/OvmfPkgIa32X64.dsc | 5 -
 OvmfPkg/OvmfPkgX64.dsc | 5 -
 3 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index df00011..e55f0db 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -461,7 +461,10 @@ [Components]
   PlatformFvbLib|OvmfPkg/Library/EmuVariableFvbLib/EmuVariableFvbLib.inf
   }
   MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
-  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+LibraryClasses
+  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+  }
   MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
   
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
   MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 355ed6a..a8fcd88 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -468,7 +468,10 @@ [Components.X64]
   PlatformFvbLib|OvmfPkg/Library/EmuVariableFvbLib/EmuVariableFvbLib.inf
   }
   MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
-  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+LibraryClasses
+  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+  }
   MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
   
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
   MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 4469bd1..63e8c12 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -466,7 +466,10 @@ [Components]
   PlatformFvbLib|OvmfPkg/Library/EmuVariableFvbLib/EmuVariableFvbLib.inf
   }
   MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
-  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+LibraryClasses
+  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+  }
   MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
   
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
   MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
-- 
1.9.5.msysgit.0

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


[edk2] [PATCH 07/15] ArmPlatformPkg: Add VarCheckLib library mapping

2015-08-17 Thread Star Zeng
Since Variable driver has been updated to consume the separated VarCheckLib.

Cc: Leif Lindholm leif.lindh...@linaro.org
Cc: Ard Biesheuvel ard.biesheu...@linaro.org
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng star.z...@intel.com
---
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc 
b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
index d2f8f5a..dc69bbb 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
+++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
@@ -130,6 +130,7 @@ [LibraryClasses.common]
 
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
   
AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
+  VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
 
 [LibraryClasses.common.SEC]
   
ArmPlatformSecExtraActionLib|ArmPlatformPkg/Library/DebugSecExtraActionLib/DebugSecExtraActionLib.inf
-- 
1.9.5.msysgit.0

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


[edk2] [PATCH 03/15] Nt32Pkg: Add VarCheckLib library mapping

2015-08-17 Thread Star Zeng
Since Variable driver has been updated to consume the separated VarCheckLib.

Cc: Ruiyu Ni ruiyu...@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng star.z...@intel.com
---
 Nt32Pkg/Nt32Pkg.dsc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Nt32Pkg/Nt32Pkg.dsc b/Nt32Pkg/Nt32Pkg.dsc
index 2b1d8c0..a95f4e9 100644
--- a/Nt32Pkg/Nt32Pkg.dsc
+++ b/Nt32Pkg/Nt32Pkg.dsc
@@ -141,6 +141,7 @@ [LibraryClasses]
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
   
AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
 !endif
+  VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
 
 [LibraryClasses.common.USER_DEFINED]
   DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
-- 
1.9.5.msysgit.0

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


[edk2] [PATCH 15/15] Vlv2TbltDevicePkg: Link separated VarCheckUefiLib NULL class library instance

2015-08-17 Thread Star Zeng
Cc: David Wei david@intel.com
Cc: Tim He tim...@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng star.z...@intel.com
---
 Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 1 +
 Vlv2TbltDevicePkg/PlatformPkgIA32.dsc   | 1 +
 Vlv2TbltDevicePkg/PlatformPkgX64.dsc| 1 +
 3 files changed, 3 insertions(+)

diff --git a/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc 
b/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
index 39884af..5c0b68a 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
@@ -1157,6 +1157,7 @@ [Components.X64]
   MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
   MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf {
 LibraryClasses
+  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
   SerialPortLib|$(PLATFORM_PACKAGE)/Library/SerialPortLib/SerialPortLib.inf
   }
   $(PLATFORM_PACKAGE)/FvbRuntimeDxe/FvbSmm.inf
diff --git a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc 
b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
index e89b5f9..dad2eb0 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
@@ -1144,6 +1144,7 @@ [Components.IA32]
   MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
   MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf {
 LibraryClasses
+  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
   SerialPortLib|$(PLATFORM_PACKAGE)/Library/SerialPortLib/SerialPortLib.inf
   }
   $(PLATFORM_PACKAGE)/FvbRuntimeDxe/FvbSmm.inf
diff --git a/Vlv2TbltDevicePkg/PlatformPkgX64.dsc 
b/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
index fc8334f..e32092e 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
@@ -1150,6 +1150,7 @@ [Components.X64]
   MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
   MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf {
 LibraryClasses
+  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
   SerialPortLib|$(PLATFORM_PACKAGE)/Library/SerialPortLib/SerialPortLib.inf
   }
   $(PLATFORM_PACKAGE)/FvbRuntimeDxe/FvbSmm.inf
-- 
1.9.5.msysgit.0

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


[edk2] [PATCH 06/15] ArmVirtPkg: Add VarCheckLib library mapping

2015-08-17 Thread Star Zeng
Since Variable driver has been updated to consume the separated VarCheckLib.

Cc: Laszlo Ersek ler...@redhat.com
Cc: Ard Biesheuvel ard.biesheu...@linaro.org
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng star.z...@intel.com
---
 ArmVirtPkg/ArmVirt.dsc.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
index 7bba6eb..8372c58 100644
--- a/ArmVirtPkg/ArmVirt.dsc.inc
+++ b/ArmVirtPkg/ArmVirt.dsc.inc
@@ -134,6 +134,7 @@ [LibraryClasses.common]
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
   
AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
 !endif
+  VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
 
 [LibraryClasses.common.SEC]
   PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
-- 
1.9.5.msysgit.0

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


[edk2] [PATCH 10/15] Nt32Pkg: Link separated VarCheckUefiLib NULL class library instance

2015-08-17 Thread Star Zeng
Cc: Ruiyu Ni ruiyu...@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng star.z...@intel.com
---
 Nt32Pkg/Nt32Pkg.dsc | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Nt32Pkg/Nt32Pkg.dsc b/Nt32Pkg/Nt32Pkg.dsc
index a95f4e9..90a7b75 100644
--- a/Nt32Pkg/Nt32Pkg.dsc
+++ b/Nt32Pkg/Nt32Pkg.dsc
@@ -373,7 +373,10 @@ [Components]
   
MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe/ReportStatusCodeRouterRuntimeDxe.inf
   
MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf
   Nt32Pkg/WinNtOemHookStatusCodeHandlerDxe/WinNtOemHookStatusCodeHandlerDxe.inf
-  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+LibraryClasses
+  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+  }
 !if $(SECURE_BOOT_ENABLE) == TRUE
   SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
 !endif
-- 
1.9.5.msysgit.0

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


[edk2] [PATCH 12/15] EmulatorPkg: Link separated VarCheckUefiLib NULL class library instance

2015-08-17 Thread Star Zeng
Cc: Jordan Justen jordan.l.jus...@intel.com
Cc: Andrew Fish af...@apple.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng star.z...@intel.com
---
 EmulatorPkg/EmulatorPkg.dsc | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
index 71943e4..8eff20e 100644
--- a/EmulatorPkg/EmulatorPkg.dsc
+++ b/EmulatorPkg/EmulatorPkg.dsc
@@ -315,7 +315,10 @@ [Components]
   EmulatorPkg/TimerDxe/Timer.inf
 
 
-  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+LibraryClasses
+  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+  }
   MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
   
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
   MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
-- 
1.9.5.msysgit.0

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


Re: [edk2] [PATCH 7/10] ShellPkg: Support format string argument checking

2015-08-17 Thread Qiu, Shumin
Reviewed-by: Qiu Shumin shumin@intel.com
This patch for ShellPkg depends on the ' EFIFORMAT ' change in MdePkg. So block 
the check in after the MdePkg has been updated.

-Shumin

-Original Message-
From: Scott Duplichan [mailto:sc...@notabs.org] 
Sent: Saturday, August 08, 2015 2:04 PM
To: edk2-devel@lists.01.org
Cc: Carsey, Jaben; Qiu, Shumin
Subject: [PATCH 7/10] ShellPkg: Support format string argument checking

Support compile time argument consistency checking for functions that accept a 
PrintLib format string followed by a variable argument list.
Macro 'EFIFORMAT' added to the function prototype accepts a single argument 
indicating which function argument holds the format string.
The EFIFORMAT macro assumes the variable argument list immediately follows the 
format string. Format string argument checking requires a compiler that 
understands EDK2 format strings, such as GCC with the gcc_format from 
BaseTools/gcc applied.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Scott Duplichan sc...@notabs.org
---


 ShellPkg/Include/Library/ShellLib.h   | 1 +
 ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/ShellPkg/Include/Library/ShellLib.h 
b/ShellPkg/Include/Library/ShellLib.h
index 23da4ee..0be5613 100644
--- a/ShellPkg/Include/Library/ShellLib.h
+++ b/ShellPkg/Include/Library/ShellLib.h
@@ -885,6 +885,7 @@ ShellInitialize (
 **/
 EFI_STATUS
 EFIAPI
+EFIFORMAT_SHELL (3)
 ShellPrintEx(
   IN INT32Col OPTIONAL,
   IN INT32Row OPTIONAL,
diff --git a/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c 
b/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
index 9bd7b2c..6dd81d4 100644
--- a/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
+++ b/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
@@ -81,6 +81,7 @@ typedef struct {
 **/
 CHAR16 *
 EFIAPI
+EFIFORMAT (2)
 CatPrint (
   IN OUT POOL_PRINT   *Str,
   IN CHAR16   *Fmt,


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