[edk2] [PATCH v3 06/12] BaseTools/GCC: align start of .data to .text alignment

2015-07-29 Thread Ard Biesheuvel
Now that GenFw honors the ELF section alignment when placing the
PE/COFF sections in the output, the start of the PE/COFF version of
.data will be aligned to the alignment of .text if its alignment is
higher than the default. So duplicate this behavior in the ELF output,
this will make the memory layout of the PE/COFF binary match the
layout of the ELF version more closely.

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

diff --git a/BaseTools/Scripts/GccBase.lds b/BaseTools/Scripts/GccBase.lds
index 0f0210e40703..3d99f01db21f 100644
--- a/BaseTools/Scripts/GccBase.lds
+++ b/BaseTools/Scripts/GccBase.lds
@@ -37,7 +37,7 @@ SECTIONS {
* between these sections is the same in the ELF and the PE/COFF versions of
* this binary.
*/
-  .data : ALIGN(CONSTANT(COMMONPAGESIZE)) {
+  .data ALIGN(ALIGNOF(.text)) : 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 v3 07/12] BaseTools/GCC: move AutoGen.obj contents to .text section

2015-07-29 Thread Ard Biesheuvel
All AutoGen.obj files consist of global GUID definitions, fixed
and patchable PCDs and other data that is essentially read-only at
runtime but has not been declared as such for various reasons.

By moving these contents to .text we achieve two things:
- global GUIDs and other data items which must be constant for correct
  program operation can no longer be modified, for instance, when
  running a DXE_RUNTIME_MODULE binary under the OS with the Properties
  Table feature for memory protection enabled;
- the .data section becomes smaller, and may be dropped completely for
  many XIP modules, which reduces wasted FV space if the PE/COFF section
  alignment is large.

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

diff --git a/BaseTools/Scripts/GccBase.lds b/BaseTools/Scripts/GccBase.lds
index 3d99f01db21f..4ee6d998532c 100644
--- a/BaseTools/Scripts/GccBase.lds
+++ b/BaseTools/Scripts/GccBase.lds
@@ -29,6 +29,13 @@ SECTIONS {
 *(.text .text.* .stub .gnu.linkonce.t.*)
 *(.rodata .rodata.* .gnu.linkonce.r.*)
 *(.got .got.*)
+
+/*
+ * The contents of AutoGen.c files are constant from the POV of the 
program,
+ * but most of its contents end up in .data or .bss by default since few of
+ * the variable definitions that get emitted are declared as CONST.
+ */
+*:AutoGen.obj(.data .data.* .bss .bss.*)
   }
 
   /*
-- 
1.9.1

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


[edk2] [PATCH v3 10/12] ArmVirtPkg: move to unified GCC linker script

2015-07-29 Thread Ard Biesheuvel
Move to the parametrised generic GCC linker script and set 64 KB
alignment, instead of using the AARCH64 specific incremental linker
script for 64 KB alignment which is about to be removed.

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

diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
index b2003a58be04..8c54242b597b 100644
--- a/ArmVirtPkg/ArmVirt.dsc.inc
+++ b/ArmVirtPkg/ArmVirt.dsc.inc
@@ -18,7 +18,7 @@ [Defines]
   DEFINE TTY_TERMINAL= FALSE
 
 [BuildOptions.AARCH64.EDKII.DXE_RUNTIME_DRIVER]
-  GCC:*_*_AARCH64_DLINK_FLAGS = 
--script=$(EDK_TOOLS_PATH)/Scripts/gcc-aarch64-64K-align-ld-script
+  GCC:*_*_AARCH64_DLINK_FLAGS = -z common-page-size=0x1
 
 [LibraryClasses.common]
 !if $(TARGET) == RELEASE
-- 
1.9.1

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


[edk2] [PATCH v3 09/12] ArmPlatformPkg/ArmVExpressPkg: move to unified GCC linker script

2015-07-29 Thread Ard Biesheuvel
Move to the parametrised generic GCC linker script and set 64 KB
alignment, instead of using the AARCH64 specific incremental linker
script for 64 KB alignment which is about to be removed.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc 
b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
index 7e0d8ff4b6e6..d2f8f5aa6d41 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
+++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
@@ -13,7 +13,7 @@
 #
 
 [BuildOptions.AARCH64.EDKII.DXE_RUNTIME_DRIVER]
-  GCC:*_*_AARCH64_DLINK_FLAGS = 
--script=$(EDK_TOOLS_PATH)/Scripts/gcc-aarch64-64K-align-ld-script
+  GCC:*_*_AARCH64_DLINK_FLAGS = -z common-page-size=0x1
 
 [LibraryClasses.common]
 !if $(TARGET) == RELEASE
-- 
1.9.1

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


[edk2] [PATCH v3 02/12] BaseTools/GCC: move .rodata to PE/COFF .text section

2015-07-29 Thread Ard Biesheuvel
The .rodata ELF section contains constant non-executable data that
should never be modified by the program itself. Since the risk of
inadvertent modification is typically higher than the risk of
inadvertent execution, it makes sense to put this data in the
R-X .text section rather than in the RW- .data section.
So move it there.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
 BaseTools/Scripts/gcc-4K-align-ld-script | 2 +-
 BaseTools/Scripts/gcc4.4-ld-script   | 2 +-
 BaseTools/Scripts/gcc4.9-ld-script   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/BaseTools/Scripts/gcc-4K-align-ld-script 
b/BaseTools/Scripts/gcc-4K-align-ld-script
index 16cf623a3362..1f0f1afb27f4 100644
--- a/BaseTools/Scripts/gcc-4K-align-ld-script
+++ b/BaseTools/Scripts/gcc-4K-align-ld-script
@@ -6,12 +6,12 @@ SECTIONS
   .text : ALIGN(0x1000)
   {
 *(.text .stub .text.* .gnu.linkonce.t.*)
+*(.rodata .rodata.* .gnu.linkonce.r.*)
 . = ALIGN(0x20);
   }
   .data : ALIGN(0x1000)
   {
 *(
-  .rodata .rodata.* .gnu.linkonce.r.*
   .data .data.* .gnu.linkonce.d.*
   .bss .bss.*
   *COM*
diff --git a/BaseTools/Scripts/gcc4.4-ld-script 
b/BaseTools/Scripts/gcc4.4-ld-script
index c0aa62180440..22b3220816c9 100644
--- a/BaseTools/Scripts/gcc4.4-ld-script
+++ b/BaseTools/Scripts/gcc4.4-ld-script
@@ -6,12 +6,12 @@ SECTIONS
   .text ALIGN(0x20) :
   {
 *(.text .stub .text.* .gnu.linkonce.t.*)
+*(.rodata .rodata.* .gnu.linkonce.r.*)
 . = ALIGN(0x20);
   }
   .data ALIGN(0x20) :
   {
 *(
-  .rodata .rodata.* .gnu.linkonce.r.*
   .data .data.* .gnu.linkonce.d.*
   .bss .bss.*
   *COM*
diff --git a/BaseTools/Scripts/gcc4.9-ld-script 
b/BaseTools/Scripts/gcc4.9-ld-script
index 37a93cd85e94..2ac86e38fac7 100644
--- a/BaseTools/Scripts/gcc4.9-ld-script
+++ b/BaseTools/Scripts/gcc4.9-ld-script
@@ -6,12 +6,12 @@ SECTIONS
   .text ALIGN(0x20) :
   {
 *(.text .stub .text.* .gnu.linkonce.t.*)
+*(.rodata .rodata.* .gnu.linkonce.r.*)
 . = ALIGN(0x20);
   }
   .data ALIGN(0x40) :
   {
 *(
-  .rodata .rodata.* .gnu.linkonce.r.*
   .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 v3 00/12] BaseTools: unify all GCC linker scripts

2015-07-29 Thread Ard Biesheuvel
Third attempt at unifying the various GCC linker scripts for different
architectures, GCC versions and minimum alignments.

Changes since v2:
- for easier bisection, factor out the differences between the original
  and the unified linker scripts for X86 before making the switch
  (patches #1 - #4 and #6)
- add Intel copyright notice to unified version (patch #5)
- avoid defining *_*_*_DLINK2_FLAGS so that we don't pollute the variable
  definition space of non-GCC toolchains (patches #8 and #12)
- added Laszlo's ack to patch #10

 v2 blurb -
This time, I have added only a single unified GCC linker script that
can be parametrised by ld command line options:
- --defsym=PECOFF_HEADER_SIZE sets the size of the PE/COFF header
- -z common-page-size sets the minimum alignment

This use of common-page-size is entirely legal: it sets an internal LD
constant which can be referred to as CONSTANT(COMMONPAGESIZE) in linker
scripts, and is otherwise unused internally by the linker.

Tested with ArmVirtQemu/AARCH64 and Ovmf/X64

Branch is here
https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/unify-gcc-ld-scripts-v3

Ard Biesheuvel (12):
  BaseTools/GCC: remove NOP padding from X86/IA32 GCC linker scripts
  BaseTools/GCC: move .rodata to PE/COFF .text section
  BaseTools/GCC: drop redundant alignment from linker script
  BaseTools/GCC: move .got contents to the PE/COFF .text section
  BaseTools/GCC: add unified GCC linker script for all archs and
versions
  BaseTools/GCC: align start of .data to .text alignment
  BaseTools/GCC: move AutoGen.obj contents to .text section
  BaseTools/AARCH64: move to unified GCC linker script
  ArmPlatformPkg/ArmVExpressPkg: move to unified GCC linker script
  ArmVirtPkg: move to unified GCC linker script
  BaseTools/AARCH64: remove incremental linker script for 64K alignment
  BaseTools/X86|IA32: move to unified GCC linker script

 ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc |  2 +-
 ArmVirtPkg/ArmVirt.dsc.inc|  2 +-
 BaseTools/Conf/tools_def.template | 37 ++-
 BaseTools/Scripts/GccBase.lds | 70 
 BaseTools/Scripts/gcc-4K-align-ld-script  | 44 
 BaseTools/Scripts/gcc-aarch64-64K-align-ld-script |  4 --
 BaseTools/Scripts/gcc-aarch64-ld-script   | 39 ---
 BaseTools/Scripts/gcc4.4-ld-script| 44 
 BaseTools/Scripts/gcc4.9-ld-script| 44 
 9 files changed, 106 insertions(+), 180 deletions(-)
 create mode 100644 BaseTools/Scripts/GccBase.lds
 delete mode 100644 BaseTools/Scripts/gcc-4K-align-ld-script
 delete mode 100644 BaseTools/Scripts/gcc-aarch64-64K-align-ld-script
 delete mode 100644 BaseTools/Scripts/gcc-aarch64-ld-script
 delete mode 100644 BaseTools/Scripts/gcc4.4-ld-script
 delete mode 100644 BaseTools/Scripts/gcc4.9-ld-script

-- 
1.9.1

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


[edk2] [PATCH v3 11/12] BaseTools/AARCH64: remove incremental linker script for 64K alignment

2015-07-29 Thread Ard Biesheuvel
Now that we moved all users to the unified GCC linker script, remove
the old 64 KB incremental linker script for AARCH64 since it is now
unused.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
 BaseTools/Scripts/gcc-aarch64-64K-align-ld-script | 4 
 1 file changed, 4 deletions(-)

diff --git a/BaseTools/Scripts/gcc-aarch64-64K-align-ld-script 
b/BaseTools/Scripts/gcc-aarch64-64K-align-ld-script
deleted file mode 100644
index 8aa4c5f08c0b..
--- a/BaseTools/Scripts/gcc-aarch64-64K-align-ld-script
+++ /dev/null
@@ -1,4 +0,0 @@
-SECTIONS {
-  .text : ALIGN(0x1) { }
-  .data : ALIGN(0x1) { }
-}
-- 
1.9.1

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


[edk2] [PATCH v3 04/12] BaseTools/GCC: move .got contents to the PE/COFF .text section

2015-07-29 Thread Ard Biesheuvel
Move the .got contents to the PE/COFF .text section. This should be
a no-op, since we typically don't generate position independent code
(i.e., using -fPIC). But since the GOT contains variable addresses that
are updated at relocation time only, its contents are best kept in .text
to prevent them from being overwritten inadvertently.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
 BaseTools/Scripts/gcc-4K-align-ld-script | 5 +
 BaseTools/Scripts/gcc4.4-ld-script   | 5 +
 BaseTools/Scripts/gcc4.9-ld-script   | 5 +
 3 files changed, 3 insertions(+), 12 deletions(-)

diff --git a/BaseTools/Scripts/gcc-4K-align-ld-script 
b/BaseTools/Scripts/gcc-4K-align-ld-script
index 3ed1c12fb8aa..34957a53147c 100644
--- a/BaseTools/Scripts/gcc-4K-align-ld-script
+++ b/BaseTools/Scripts/gcc-4K-align-ld-script
@@ -7,6 +7,7 @@ SECTIONS
   {
 *(.text .stub .text.* .gnu.linkonce.t.*)
 *(.rodata .rodata.* .gnu.linkonce.r.*)
+*(.got .got.*)
   }
   .data : ALIGN(0x1000)
   {
@@ -20,10 +21,6 @@ SECTIONS
   {
 KEEP (*(.eh_frame))
   }
-  .got : ALIGN(0x1000)
-  {
-*(.got .got.*)
-  }
   .rela : ALIGN(0x1000)
   {
 *(.rela .rela.*)
diff --git a/BaseTools/Scripts/gcc4.4-ld-script 
b/BaseTools/Scripts/gcc4.4-ld-script
index 0d86908d0b30..48320c6611e4 100644
--- a/BaseTools/Scripts/gcc4.4-ld-script
+++ b/BaseTools/Scripts/gcc4.4-ld-script
@@ -7,6 +7,7 @@ SECTIONS
   {
 *(.text .stub .text.* .gnu.linkonce.t.*)
 *(.rodata .rodata.* .gnu.linkonce.r.*)
+*(.got .got.*)
   }
   .data ALIGN(0x20) :
   {
@@ -20,10 +21,6 @@ SECTIONS
   {
 KEEP (*(.eh_frame))
   }
-  .got ALIGN(0x20) :
-  {
-*(.got .got.*)
-  }
   .rela ALIGN(0x20) :
   {
 *(.rela .rela.*)
diff --git a/BaseTools/Scripts/gcc4.9-ld-script 
b/BaseTools/Scripts/gcc4.9-ld-script
index 207b9e1dc7f0..3dff0b2907e6 100644
--- a/BaseTools/Scripts/gcc4.9-ld-script
+++ b/BaseTools/Scripts/gcc4.9-ld-script
@@ -7,6 +7,7 @@ SECTIONS
   {
 *(.text .stub .text.* .gnu.linkonce.t.*)
 *(.rodata .rodata.* .gnu.linkonce.r.*)
+*(.got .got.*)
   }
   .data ALIGN(0x40) :
   {
@@ -20,10 +21,6 @@ SECTIONS
   {
 KEEP (*(.eh_frame))
   }
-  .got ALIGN(0x20) :
-  {
-*(.got .got.*)
-  }
   .rela ALIGN(0x20) :
   {
 *(.rela .rela.*)
-- 
1.9.1

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


[edk2] [PATCH v2] ArmPlatformPkg: remove obsolete ARM and AARCH64 platforms

2015-07-29 Thread Ard Biesheuvel
Remove obsolete ARM and AARCH64 platforms so the maintainers can
focus on the ones that are still supported, which are:
- TC2 (ArmVExpress-CTA15-A7.dsc)
- Foundation model and Fast model emulators (ArmVExpress-FVP-AArch64.dsc)
- Juno (ArmJunoPkg/ArmJuno.dsc)
- Cortex-A15 MPcore RTSM (ArmVExpress-RTSM-A15_MPCore)

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---

Branch is here:
https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/remove-obsolete-platforms

 ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb-RTSM-A8.dsc  
   | 235 --
 ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb-RTSM-A9x2.dsc
   | 235 --
 ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb-RTSM-MPCore.fdf  
   | 322 -
 ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb-RTSM-UniCore.fdf 
   | 324 -
 ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb.dsc.inc  
   | 342 --
 ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEbPkg.dec   
   |  39 --
 ArmPlatformPkg/ArmRealViewEbPkg/Debugger_scripts/EBLoadSecSyms.inc 
   |  16 -
 ArmPlatformPkg/ArmRealViewEbPkg/Debugger_scripts/EfiFuncs.inc  
   | 463 ---
 ArmPlatformPkg/ArmRealViewEbPkg/Debugger_scripts/rvi_boot_from_ram.inc 
   |  21 -
 ArmPlatformPkg/ArmRealViewEbPkg/Debugger_scripts/rvi_convert_symbols.sh
   |  23 -
 ArmPlatformPkg/ArmRealViewEbPkg/Debugger_scripts/rvi_hw_setup.inc  
   |  67 ---
 ArmPlatformPkg/ArmRealViewEbPkg/Debugger_scripts/rvi_load_symbols.inc  
   |  23 -
 ArmPlatformPkg/ArmRealViewEbPkg/Debugger_scripts/rvi_symbols_macros.inc
   | 194 
 ArmPlatformPkg/ArmRealViewEbPkg/Debugger_scripts/rvi_unload_symbols.inc
   | 118 -
 ArmPlatformPkg/ArmRealViewEbPkg/FvbDxe/FvbDxe.c
   | 417 -
 ArmPlatformPkg/ArmRealViewEbPkg/FvbDxe/FvbDxe.inf  
   |  53 ---
 ArmPlatformPkg/ArmRealViewEbPkg/Include/Platform/ArmPlatform.h 
   | 122 -
 ArmPlatformPkg/ArmRealViewEbPkg/InterruptDxe/InterruptDxe.c
   | 484 
 ArmPlatformPkg/ArmRealViewEbPkg/InterruptDxe/InterruptDxe.inf  
   |  53 ---
 ArmPlatformPkg/ArmRealViewEbPkg/Library/ArmRealViewEbLibRTSM/ArmRealViewEb.c   
   | 146 --
 
ArmPlatformPkg/ArmRealViewEbPkg/Library/ArmRealViewEbLibRTSM/ArmRealViewEbHelper.S
|  53 ---
 
ArmPlatformPkg/ArmRealViewEbPkg/Library/ArmRealViewEbLibRTSM/ArmRealViewEbHelper.asm
  |  59 ---
 
ArmPlatformPkg/ArmRealViewEbPkg/Library/ArmRealViewEbLibRTSM/ArmRealViewEbLib.inf
 |  50 --
 
ArmPlatformPkg/ArmRealViewEbPkg/Library/ArmRealViewEbLibRTSM/ArmRealViewEbLibSec.inf
  |  46 --
 
ArmPlatformPkg/ArmRealViewEbPkg/Library/ArmRealViewEbLibRTSM/ArmRealViewEbMem.c 
  | 116 -
 
ArmPlatformPkg/ArmRealViewEbPkg/Library/ArmRealViewEbSecLibRTSM/ArmRealViewEbBoot.S
   |  54 ---
 
ArmPlatformPkg/ArmRealViewEbPkg/Library/ArmRealViewEbSecLibRTSM/ArmRealViewEbBoot.asm
 |  58 ---
 
ArmPlatformPkg/ArmRealViewEbPkg/Library/ArmRealViewEbSecLibRTSM/ArmRealViewEbSec.c
|  78 
 
ArmPlatformPkg/ArmRealViewEbPkg/Library/ArmRealViewEbSecLibRTSM/ArmRealViewEbSecLib.inf
   |  41 --
 
ArmPlatformPkg/ArmRealViewEbPkg/Library/DebugAgentTimerLib/DebugAgentTimerLib.c 
  |  77 
 
ArmPlatformPkg/ArmRealViewEbPkg/Library/DebugAgentTimerLib/DebugAgentTimerLib.inf
 |  38 --
 ArmPlatformPkg/ArmRealViewEbPkg/Library/GdbSerialLib/GdbSerialLib.c
   | 118 -
 ArmPlatformPkg/ArmRealViewEbPkg/Library/GdbSerialLib/GdbSerialLib.inf  
   |  39 --
 
ArmPlatformPkg/ArmRealViewEbPkg/Library/NorFlashArmRealViewEbLib/NorFlashArmRealViewEb.c
  |  54 ---
 
ArmPlatformPkg/ArmRealViewEbPkg/Library/NorFlashArmRealViewEbLib/NorFlashArmRealViewEbLib.inf
 |  35 --
 
ArmPlatformPkg/ArmRealViewEbPkg/Library/PL111LcdArmRealViewEbLib/PL111LcdArmRealViewEb.c
  | 232 --
 
ArmPlatformPkg/ArmRealViewEbPkg/Library/PL111LcdArmRealViewEbLib/PL111LcdArmRealViewEbLib.inf
 |  65 ---
 ArmPlatformPkg/ArmRealViewEbPkg/Library/ResetSystemLib/ResetSystemLib.c
   |  87 
 ArmPlatformPkg/ArmRealViewEbPkg/Library/ResetSystemLib/ResetSystemLib.inf  
   |  35 --
 ArmPlatformPkg/ArmRealViewEbPkg/b.bat  
   |  43 --
 ArmPlatformPkg/ArmRealViewEbPkg/ba.bat 

Re: [edk2] [PATCH] EmbeddedPkg: Added Marvell Yukon Ethernet support

2015-07-29 Thread Jordan Justen
On 2015-07-28 10:51:38, Leif Lindholm wrote:
 Hi Jordan,
 
 Sorry, (metaphorically) snowed under for a few days.
 
 On Fri, Jul 17, 2015 at 02:44:10PM -0700, Jordan Justen wrote:
Does this depend on ArmPkg / EmbeddedPkg, or is this just a generic
PCI based driver?

It could be nice to have a generic place for such drivers, but I think
OptionRomPkg is the closest we have today.
   
   Well, I'm planning to add it to my OpenPlatformPkg tree.
   If that was to be merged into edk2, that would contain such a generic
   place.
  
  But, the name 'open platform' also sounds strange, assuming this a
  plain PCI bus driver. Couldn't it live in a 'pci drivers' package?
  
  Personally, I think we should rename OptionRomPkg to DriversPkg, or
  split it into UsbDriversPkg and PciDriversPkg.

Mike,

This seems like another thing we've been talking about for years. :)

What do you think about adding:

DriversPkg
DriversPkg/Pci
DriversPkg/Usb

 or

PciDriversPkg
UsbDriversPkg

One possible concern is who will own/maintain such a package. In this
case, it might make sense to have a separate Maintainers.txt file
under the package.

Or, what I would suggest is that we just start out by saying that
edk2-devel collectively owns it, and that any other package maintainer
can commit contributions to the package.

-Jordan

 So, OpenPlatformPkg is my current way of dealing with the lack of a
 unified handling of platform/driver code in edk2. It is not something
 I mind giving up if this situation resolves itself another way. Or
 renaming to something more palatable :)
 
 I gave a presentation (more like lightning talk) at the spring
 plugfest in Seattle on this:
 http://www.uefi.org/sites/default/files/resources/UEFI_Plugfest_Platforms_Tree_May_2015.pdf
 
 If we simply rename OptionRomPkg to DriversPkg (and restructure a bit
 in there), then that solves the drivers part of my problem. But I
 still need something for opensource platform support.
 
 /
 Leif
 ___
 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 v3 09/12] ArmPlatformPkg/ArmVExpressPkg: move to unified GCC linker script

2015-07-29 Thread Jordan Justen
On 2015-07-29 08:11:59, Ard Biesheuvel wrote:
 Move to the parametrised generic GCC linker script and set 64 KB
 alignment, instead of using the AARCH64 specific incremental linker
 script for 64 KB alignment which is about to be removed.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc 
 b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
 index 7e0d8ff4b6e6..d2f8f5aa6d41 100644
 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
 +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
 @@ -13,7 +13,7 @@
  #
  
  [BuildOptions.AARCH64.EDKII.DXE_RUNTIME_DRIVER]
 -  GCC:*_*_AARCH64_DLINK_FLAGS = 
 --script=$(EDK_TOOLS_PATH)/Scripts/gcc-aarch64-64K-align-ld-script
 +  GCC:*_*_AARCH64_DLINK_FLAGS = -z common-page-size=0x1

Nice. This seems like a big improvement.

common-page-size doesn't map exactly to 'image section alignment', so
there is a little bit of a disconnect here in terminology.

I think you said that something like
--defsym=IMAGE_SECTION_ALIGN=0x1 can't be used because it doesn't
work in the linker script. Is that right?

I guess if we added -z common-page-size=$(SECTIONALIGN_FLAGS) directly
in build_rule, then we might be able to use:

  GCC:*_*_*_SECTIONALIGN_FLAGS = 0x1

That's not great either.

-Jordan

  
  [LibraryClasses.common]
  !if $(TARGET) == RELEASE
 -- 
 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] efi acpidump port

2015-07-29 Thread Smith, Jonathan D
Password:
edk2efiacpidump

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew 
Fish
Sent: Wednesday, July 29, 2015 1:50 PM
To: Smith, Jonathan D
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] efi acpidump port


 On Jul 29, 2015, at 1:43 PM, Smith, Jonathan D jonathan.d.sm...@intel.com 
 wrote:
 
 Attaching a zip of the files
 

Looks like you need to rename the inf, or add a password to the Zip. 

cat 0_Warning.txt
BLOCKED FILE ALERTA file has been blocked due to the 'Intel Email File 
Filtering Policy' rule.Context: 'acpidump.inf'Disallowed due to Ticket Number: 
'0ab4-55b9-3aff-0008'
See your system administrator for further information. Copyright 1999-2011 
McAfee, Inc.All Rights Reserved.http://www.mcafee.com

Thanks for working on this. 

Thanks,

Andrew Fish


 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org 
 mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Smith, Jonathan 
 D
 Sent: Wednesday, July 29, 2015 1:37 PM
 To: 'Andrew Fish'; 'edk2-devel@lists.01.org mailto:edk2-devel@lists.01.org'
 Subject: Re: [edk2] efi acpidump port
 
 Hi all,
 
 Let me know if the attachments to this message do not show up.
 
 I’ve elaborated the build metadata, reduced the ACPICA changes (moving 
 alterations into additional files as needed), and verified that the compiled 
 AcpicaPkg provides a correct implementation of acpidump that works for Minnow.
 
 To set up the EDK2 AcpicaPkg from the ACPICA sources:
 
 
 1.)Go to https://acpica.org/downloads https://acpica.org/downloads and 
 download 
 aspia-unix-20150619.tarhttps://acpica.org/downloads%20and%20download%20aspia-unix-20150619.tar
  https://acpica.org/downloads%20and%20download%20aspia-unix-20150619.tar
 
 2.)Extract the tar and put it in the root of edk2 as AcpicaPkg
 
 3.)Apply acenv.patch to edk2\AcpicaPkg\source\include\platform\acenv.h or 
 just add the two lines manually.
 
 4.)Add the files AcpicaPkg.dec, AcpicaPkg.dsc, acpidump.inf, and 
 acpi_main.c to the dir edk2\AcpicaPkg
 
 5.)Add the file acedk2efi.h to the dir 
 edk2\AcpicaPkg\source\include\platform
 
 I had to make several changes to link to the edk2 implementation of LibC. Now 
 the only code in ACPICA that changes is the #ifdef that includes our 
 acedk2efi.h file; this is a slightly modified version of the #else block in 
 acefi.h we had earlier.
 
 Cheers,
 Jonathan Smith
 
 
 From: Andrew Fish [mailto:af...@apple.com mailto:af...@apple.com]
 Sent: Saturday, July 18, 2015 12:44 PM
 To: Smith, Jonathan D
 Cc: edk2-devel@lists.01.org mailto:edk2-devel@lists.01.org
 Subject: Re: [edk2] efi acpidump port
 
 
 On Jul 18, 2015, at 11:23 AM, Smith, Jonathan D jonathan.d.sm...@intel.com 
 mailto:jonathan.d.sm...@intel.commailto:jonathan.d.sm...@intel.com 
 mailto:jonathan.d.sm...@intel.com wrote:
 
 The issues I ran into were after solving issues with the /D options. I’ve 
 been working with /D _EDK2_EFI /D _ACPI_DUMP_APP so far. A lot of warnings 
 escalated to errors were simple fixes, such as unsigned-to-signed 
 comparisons. I was asking whether the parameter I mentioned called “Address” 
 which was declared as type ACPI_SIZE should have been declared 
 ACPI_PHYSICAL_ADDRESS, since every use of that function (OslMapTable) passes 
 in type ACPI_PHYSICAL_ADDRESS. Changing to the address type fixes some 
 compile warnings, but I was wondering if there was some implicit reason why 
 we used the size type instead.
 
 
 Jonathan,
 
 1st off this code comes from acpica, so the experts about this code don’t 
 subscribe to this mailing list. You would need to ask questions about why on 
 some acpica list.  I only looked at the acpiaca code for the 1st time to try 
 and port it.
 
 ACPI_PHYSICAL_ADDRESS is defined in actypes.h. This file supports different 
 modes of acpica, but it is tool agnostic. So I did not change it.This file is 
 modified by #define’s so you probably have the wrong combination?
 
 You probably have some more fundamental bug that you are hiding by changing 
 the common code. The acpica code supports being compiled for VC++ and gcc, so 
 it “should work”?
 The edk2 defines EFI_PHYSICAL_ADDERSS as:
 typedef UINT64EFI_PHYSICAL_ADDRESS;
 
 ~/work/src/edk2/acpica(acpica)git grep --untracked  ACPI_PHYSICAL_ADDRESS -- 
 *.h | grep typedef
 source/include/actypes.h:238:typedef UINT64  
 ACPI_PHYSICAL_ADDRESS;
 source/include/actypes.h:285:typedef UINT32  
 ACPI_PHYSICAL_ADDRESS;
 source/include/actypes.h:295:typedef UINT64  
 ACPI_PHYSICAL_ADDRESS;
 
 Thus you don’t really need to set things to EFI_PHYSICAL_ADDRESS, you just 
 need to make sure acpica has the right settings. It looks like 
 ACPI_32BIT_PHYSICAL_ADDRESS getting set will cause a 32-bit address. If 
 EFI_PHYSICAL_ADDERSS and EFI_PHYSICAL_ADDERSS are both defined to be UINT64 I 
 would not thing you would have an issue?

Re: [edk2] efi acpidump port

2015-07-29 Thread Andrew Fish

 On Jul 29, 2015, at 1:43 PM, Smith, Jonathan D jonathan.d.sm...@intel.com 
 wrote:
 
 Attaching a zip of the files
 

Looks like you need to rename the inf, or add a password to the Zip. 

cat 0_Warning.txt
BLOCKED FILE ALERTA file has been blocked due to the 'Intel Email File 
Filtering Policy' rule.Context: 'acpidump.inf'Disallowed due to Ticket Number: 
'0ab4-55b9-3aff-0008'
See your system administrator for further information. Copyright 1999-2011 
McAfee, Inc.All Rights Reserved.http://www.mcafee.com

Thanks for working on this. 

Thanks,

Andrew Fish


 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org 
 mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Smith, Jonathan D
 Sent: Wednesday, July 29, 2015 1:37 PM
 To: 'Andrew Fish'; 'edk2-devel@lists.01.org mailto:edk2-devel@lists.01.org'
 Subject: Re: [edk2] efi acpidump port
 
 Hi all,
 
 Let me know if the attachments to this message do not show up.
 
 I’ve elaborated the build metadata, reduced the ACPICA changes (moving 
 alterations into additional files as needed), and verified that the compiled 
 AcpicaPkg provides a correct implementation of acpidump that works for Minnow.
 
 To set up the EDK2 AcpicaPkg from the ACPICA sources:
 
 
 1.)Go to https://acpica.org/downloads https://acpica.org/downloads and 
 download 
 aspia-unix-20150619.tarhttps://acpica.org/downloads%20and%20download%20aspia-unix-20150619.tar
  https://acpica.org/downloads%20and%20download%20aspia-unix-20150619.tar
 
 2.)Extract the tar and put it in the root of edk2 as AcpicaPkg
 
 3.)Apply acenv.patch to edk2\AcpicaPkg\source\include\platform\acenv.h or 
 just add the two lines manually.
 
 4.)Add the files AcpicaPkg.dec, AcpicaPkg.dsc, acpidump.inf, and 
 acpi_main.c to the dir edk2\AcpicaPkg
 
 5.)Add the file acedk2efi.h to the dir 
 edk2\AcpicaPkg\source\include\platform
 
 I had to make several changes to link to the edk2 implementation of LibC. Now 
 the only code in ACPICA that changes is the #ifdef that includes our 
 acedk2efi.h file; this is a slightly modified version of the #else block in 
 acefi.h we had earlier.
 
 Cheers,
 Jonathan Smith
 
 
 From: Andrew Fish [mailto:af...@apple.com mailto:af...@apple.com]
 Sent: Saturday, July 18, 2015 12:44 PM
 To: Smith, Jonathan D
 Cc: edk2-devel@lists.01.org mailto:edk2-devel@lists.01.org
 Subject: Re: [edk2] efi acpidump port
 
 
 On Jul 18, 2015, at 11:23 AM, Smith, Jonathan D jonathan.d.sm...@intel.com 
 mailto:jonathan.d.sm...@intel.commailto:jonathan.d.sm...@intel.com 
 mailto:jonathan.d.sm...@intel.com wrote:
 
 The issues I ran into were after solving issues with the /D options. I’ve 
 been working with /D _EDK2_EFI /D _ACPI_DUMP_APP so far. A lot of warnings 
 escalated to errors were simple fixes, such as unsigned-to-signed 
 comparisons. I was asking whether the parameter I mentioned called “Address” 
 which was declared as type ACPI_SIZE should have been declared 
 ACPI_PHYSICAL_ADDRESS, since every use of that function (OslMapTable) passes 
 in type ACPI_PHYSICAL_ADDRESS. Changing to the address type fixes some 
 compile warnings, but I was wondering if there was some implicit reason why 
 we used the size type instead.
 
 
 Jonathan,
 
 1st off this code comes from acpica, so the experts about this code don’t 
 subscribe to this mailing list. You would need to ask questions about why on 
 some acpica list.  I only looked at the acpiaca code for the 1st time to try 
 and port it.
 
 ACPI_PHYSICAL_ADDRESS is defined in actypes.h. This file supports different 
 modes of acpica, but it is tool agnostic. So I did not change it.This file is 
 modified by #define’s so you probably have the wrong combination?
 
 You probably have some more fundamental bug that you are hiding by changing 
 the common code. The acpica code supports being compiled for VC++ and gcc, so 
 it “should work”?
 The edk2 defines EFI_PHYSICAL_ADDERSS as:
 typedef UINT64EFI_PHYSICAL_ADDRESS;
 
 ~/work/src/edk2/acpica(acpica)git grep --untracked  ACPI_PHYSICAL_ADDRESS -- 
 *.h | grep typedef
 source/include/actypes.h:238:typedef UINT64  
 ACPI_PHYSICAL_ADDRESS;
 source/include/actypes.h:285:typedef UINT32  
 ACPI_PHYSICAL_ADDRESS;
 source/include/actypes.h:295:typedef UINT64  
 ACPI_PHYSICAL_ADDRESS;
 
 Thus you don’t really need to set things to EFI_PHYSICAL_ADDRESS, you just 
 need to make sure acpica has the right settings. It looks like 
 ACPI_32BIT_PHYSICAL_ADDRESS getting set will cause a 32-bit address. If 
 EFI_PHYSICAL_ADDERSS and EFI_PHYSICAL_ADDERSS are both defined to be UINT64 I 
 would not thing you would have an issue?
 
 
 
 I’m running into further issues now with the ACPICA package trying to define 
 functions like memcpy which are intrinsic and cause a  fatal error on compile
 
 What error are you getting? You should fix the thing that is throwing the 
 error, and not modify 

Re: [edk2] [PATCH v3 12/12] BaseTools/X86|IA32: move to unified GCC linker script

2015-07-29 Thread Jordan Justen
Subject prefix: BaseTools/X86|IA32 = BaseTools IA32/X64

What about 1 more step? :)

This change starts to make use of the -z common-page-size and
--defsym=PECOFF_HEADER_SIZE params, but the description says 'move to
unified script'.

So, how about first modifying the gcc*-ld-script files to use -z
common-page-size and --defsym=PECOFF_HEADER_SIZE and then the last
patch is trivial:

  BaseTools IA32/X64: Use GccBase.lds instead of gcc*-ld-script

  These scripts all now have the same contents, so we only need to use
  GccBase.lds. Therefore we can delete gcc-4K-align-ld-script,
  gcc4.4-ld-script and gcc4.9-ld-script.

With that change, the series is

  Reviewed-by: Jordan Justen jordan.l.jus...@intel.com

although, I would like someone to test the changes on a '4k' aligned
image build. Liming, do you know who might be able to do that?

-Jordan

On 2015-07-29 08:12:02, Ard Biesheuvel wrote:
 Drop the GCC 4.4/X86 and 4.9/X86 specific linker scripts and use
 the new unified one instead.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  BaseTools/Conf/tools_def.template| 28 +--
  BaseTools/Scripts/gcc-4K-align-ld-script | 38 
  BaseTools/Scripts/gcc4.4-ld-script   | 38 
  BaseTools/Scripts/gcc4.9-ld-script   | 38 
  4 files changed, 26 insertions(+), 116 deletions(-)
 
 diff --git a/BaseTools/Conf/tools_def.template 
 b/BaseTools/Conf/tools_def.template
 index d3dfdc41ada1..eeb488fb3597 100644
 --- a/BaseTools/Conf/tools_def.template
 +++ b/BaseTools/Conf/tools_def.template
 @@ -3847,10 +3847,12 @@ DEFINE GCC_AARCH64_RC_FLAGS= -I binary -O 
 elf64-littleaarch64 -B aarch64
  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_IA32_CC_FLAGS   = DEF(GCC44_ALL_CC_FLAGS) -m32 
 -malign-double -fno-stack-protector -D EFI32
  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
 -DEFINE GCC44_IA32_X64_DLINK_COMMON   = -nostdlib -n -q --gc-sections 
 --script=$(EDK_TOOLS_PATH)/Scripts/gcc4.4-ld-script
 +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   = DEF(GCC_DLINK2_FLAGS_COMMON) 
 --defsym=PECOFF_HEADER_SIZE=0x220
  DEFINE GCC44_X64_DLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_FLAGS)  
 -melf_x86_64 --oformat=elf64-x86-64
 +DEFINE GCC44_X64_DLINK2_FLAGS= DEF(GCC_DLINK2_FLAGS_COMMON) 
 --defsym=PECOFF_HEADER_SIZE=0x228
  DEFINE GCC44_ASM_FLAGS   = DEF(GCC_ASM_FLAGS)
  
  DEFINE GCC45_IA32_CC_FLAGS   = DEF(GCC44_IA32_CC_FLAGS)
 @@ -3858,7 +3860,9 @@ 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)
 +DEFINE GCC45_IA32_DLINK2_FLAGS   = DEF(GCC44_IA32_DLINK2_FLAGS)
  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
 @@ -3866,7 +3870,9 @@ DEFINE GCC46_X64_CC_FLAGS= 
 DEF(GCC45_X64_CC_FLAGS) -Wno-address -Wno
  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)
 +DEFINE GCC46_IA32_DLINK2_FLAGS   = DEF(GCC45_IA32_DLINK2_FLAGS)
  DEFINE GCC46_X64_DLINK_FLAGS = DEF(GCC45_X64_DLINK_FLAGS)
 +DEFINE GCC46_X64_DLINK2_FLAGS= DEF(GCC45_X64_DLINK2_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(GCC44_ALL_CC_FLAGS) DEF(GCC_ARM_CC_FLAGS) -fstack-protector
 @@ -3878,7 +3884,9 @@ DEFINE GCC47_X64_CC_FLAGS= 
 DEF(GCC46_X64_CC_FLAGS)
  DEFINE GCC47_IA32_X64_DLINK_COMMON   = DEF(GCC46_IA32_X64_DLINK_COMMON)
  DEFINE 

Re: [edk2] posting to the new list without subscription?

2015-07-29 Thread Jordan Justen
On 2015-07-28 12:59:46, Laszlo Ersek wrote:
 Hi Jordan,
 
 what are the rules for posting to the new list without being
 subscribed?

On the old list, I think we dropped all such emails.

Currently we are rejecting them on the new list.

 Paolo posted a few absolutely great comments recently, and I can only
 see them in my INBOX, and not on the list.

Strangely, it seems your email did not hit the list, although you are
subscribed. I've seen plenty of emails from you on the new list, so I
think generally your emails are making it to the list.

 Are such messages held for administrator approval? (Per message
 basis? Per poster basis?) I think the most collaborative setting
 would be to allow unsubscribed people to post. But, I guess, if the
 spam situation is bad, permanent per-poster approval should be okay
 too (I think that's what libvir-list follows too, for example.)
 Per-message approval would be bad, IMO.

Hmm. I'll look into the per-poster approval.

I think the only way we could consider wide-open posting is if we
dropped all email with non-plain text attachments. That would likely
rule out most spam emails. But, we'd have to train the community that
only plain text emails are going to make it through to the list.

I know many projects are able to get away with wide-open posting, but
I don't know how they manage to keep spam out.

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


Re: [edk2] efi acpidump port

2015-07-29 Thread Jordan Justen
On 2015-07-29 16:27:38, Andrew Fish wrote:
  On Jul 29, 2015, at 4:11 PM, Jordan Justen jordan.l.jus...@intel.com 
  wrote:
  On 2015-07-29 13:43:43, Smith, Jonathan D wrote:
  Attaching a zip of the files
  
  -Original Message-
  From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org 
  mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Smith, Jonathan D
  Sent: Wednesday, July 29, 2015 1:37 PM
  To: 'Andrew Fish'; 'edk2-devel@lists.01.org 
  mailto:edk2-devel@lists.01.org'
  Subject: Re: [edk2] efi acpidump port
  
  Hi all,
  
  Let me know if the attachments to this message do not show up.
  
  I’ve elaborated the build metadata, reduced the ACPICA changes
  (moving alterations into additional files as needed), and verified
  that the compiled AcpicaPkg provides a correct implementation of
  acpidump that works for Minnow.
  
  To set up the EDK2 AcpicaPkg from the ACPICA sources:
  
  
  1.) Go to https://acpica.org/downloads https://acpica.org/downloads and 
  download
  aspia-unix-20150619.tarhttps://acpica.org/downloads%20and%20download%20aspia-unix-20150619.tar
   https://acpica.org/downloads%20and%20download%20aspia-unix-20150619.tar
  
  2.) Extract the tar and put it in the root of edk2 as AcpicaPkg
  
  3.) Apply acenv.patch to
  edk2\AcpicaPkg\source\include\platform\acenv.h or just add the two
  lines manually.
  
  4.) Add the files AcpicaPkg.dec, AcpicaPkg.dsc, acpidump.inf, and
  acpi_main.c to the dir edk2\AcpicaPkg
  
  5.) Add the file acedk2efi.h to the dir
  edk2\AcpicaPkg\source\include\platform
  
  This seems a little silly.
  
 
 Like the Intel email server removing the INF from the zip file?

It is usually pretty entertaining to watch people trying to outsmart
this filtering. Wow. After all these years, I think I finally
convinced myself that this filtering is good for something. :)

 Seems silly to make a branch to add a single package.

This is a perfect example of how much better it is to work with git
than svn. There is no fuss to work on a new feature such as this on a
new branch and make it available to everyone...

 How do you add a subproject? Like the FatPkg?

He can just run mkdir and add the files in his branch. Hopefully
they'll make it into EDK II proper at some point.

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


Re: [edk2] efi acpidump port

2015-07-29 Thread Jordan Justen
On 2015-07-29 13:43:43, Smith, Jonathan D wrote:
 Attaching a zip of the files
 
 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Smith, 
 Jonathan D
 Sent: Wednesday, July 29, 2015 1:37 PM
 To: 'Andrew Fish'; 'edk2-devel@lists.01.org'
 Subject: Re: [edk2] efi acpidump port
 
 Hi all,
 
 Let me know if the attachments to this message do not show up.
 
 I’ve elaborated the build metadata, reduced the ACPICA changes
 (moving alterations into additional files as needed), and verified
 that the compiled AcpicaPkg provides a correct implementation of
 acpidump that works for Minnow.
 
 To set up the EDK2 AcpicaPkg from the ACPICA sources:
 
 
 1.) Go to https://acpica.org/downloads and download
 aspia-unix-20150619.tarhttps://acpica.org/downloads%20and%20download%20aspia-unix-20150619.tar
 
 2.) Extract the tar and put it in the root of edk2 as AcpicaPkg
 
 3.) Apply acenv.patch to
 edk2\AcpicaPkg\source\include\platform\acenv.h or just add the two
 lines manually.
 
 4.) Add the files AcpicaPkg.dec, AcpicaPkg.dsc, acpidump.inf, and
 acpi_main.c to the dir edk2\AcpicaPkg
 
 5.) Add the file acedk2efi.h to the dir
 edk2\AcpicaPkg\source\include\platform

This seems a little silly.

Maybe you can just fork edk2, make the required changes and provide a
link to your branch?

https://github.com/tianocore/edk2

Also, what about 'Contributed-under'? (MdePkg/Contributions.txt)

By the way, I think Prince (Cc'd) did a port of acpidump in the past,
but never tried to release it externally.

-Jordan

 I had to make several changes to link to the edk2 implementation of
 LibC. Now the only code in ACPICA that changes is the #ifdef that
 includes our acedk2efi.h file; this is a slightly modified version
 of the #else block in acefi.h we had earlier.
 
 Cheers,
 Jonathan Smith
 
 
 From: Andrew Fish [mailto:af...@apple.com]
 Sent: Saturday, July 18, 2015 12:44 PM
 To: Smith, Jonathan D
 Cc: edk2-devel@lists.01.org
 Subject: Re: [edk2] efi acpidump port
 
 
 On Jul 18, 2015, at 11:23 AM, Smith, Jonathan D 
 jonathan.d.sm...@intel.commailto:jonathan.d.sm...@intel.com wrote:
 
 The issues I ran into were after solving issues with the /D options. I’ve 
 been working with /D _EDK2_EFI /D _ACPI_DUMP_APP so far. A lot of warnings 
 escalated to errors were simple fixes, such as unsigned-to-signed 
 comparisons. I was asking whether the parameter I mentioned called “Address” 
 which was declared as type ACPI_SIZE should have been declared 
 ACPI_PHYSICAL_ADDRESS, since every use of that function (OslMapTable) passes 
 in type ACPI_PHYSICAL_ADDRESS. Changing to the address type fixes some 
 compile warnings, but I was wondering if there was some implicit reason why 
 we used the size type instead.
 
 
 Jonathan,
 
 1st off this code comes from acpica, so the experts about this code don’t 
 subscribe to this mailing list. You would need to ask questions about why on 
 some acpica list.  I only looked at the acpiaca code for the 1st time to try 
 and port it.
 
 ACPI_PHYSICAL_ADDRESS is defined in actypes.h. This file supports different 
 modes of acpica, but it is tool agnostic. So I did not change it.This file is 
 modified by #define’s so you probably have the wrong combination?
 
 You probably have some more fundamental bug that you are hiding by changing 
 the common code. The acpica code supports being compiled for VC++ and gcc, so 
 it “should work”?
 The edk2 defines EFI_PHYSICAL_ADDERSS as:
 typedef UINT64EFI_PHYSICAL_ADDRESS;
 
 ~/work/src/edk2/acpica(acpica)git grep --untracked  ACPI_PHYSICAL_ADDRESS -- 
 *.h | grep typedef
 source/include/actypes.h:238:typedef UINT64  
 ACPI_PHYSICAL_ADDRESS;
 source/include/actypes.h:285:typedef UINT32  
 ACPI_PHYSICAL_ADDRESS;
 source/include/actypes.h:295:typedef UINT64  
 ACPI_PHYSICAL_ADDRESS;
 
 Thus you don’t really need to set things to EFI_PHYSICAL_ADDRESS, you just 
 need to make sure acpica has the right settings. It looks like 
 ACPI_32BIT_PHYSICAL_ADDRESS getting set will cause a 32-bit address. If 
 EFI_PHYSICAL_ADDERSS and EFI_PHYSICAL_ADDERSS are both defined to be UINT64 I 
 would not thing you would have an issue?
 
 
 
 I’m running into further issues now with the ACPICA package trying to define 
 functions like memcpy which are intrinsic and cause a  fatal error on compile
 
 What error are you getting? You should fix the thing that is throwing the 
 error, and not modify the code. I thin the gcc side might depend on that 
 code? The edk2 StdLib includes a memcpy, so this issue must have been solved?
 
 
 . My workaround is to do #if !defined(_EDK2_EFI) guards since I searched the 
 package and didn’t find any uses of those functions.
 
 I added the _EDK2_EFI, I don’t think it is a good idea to work around some 
 compiler specific issue you are hitting by adding it in new locations.
 
 
 Currently I’m just combing the code for any 

Re: [edk2] efi acpidump port

2015-07-29 Thread Andrew Fish

 On Jul 29, 2015, at 4:11 PM, Jordan Justen jordan.l.jus...@intel.com wrote:
 
 On 2015-07-29 13:43:43, Smith, Jonathan D wrote:
 Attaching a zip of the files
 
 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org 
 mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Smith, Jonathan D
 Sent: Wednesday, July 29, 2015 1:37 PM
 To: 'Andrew Fish'; 'edk2-devel@lists.01.org mailto:edk2-devel@lists.01.org'
 Subject: Re: [edk2] efi acpidump port
 
 Hi all,
 
 Let me know if the attachments to this message do not show up.
 
 I’ve elaborated the build metadata, reduced the ACPICA changes
 (moving alterations into additional files as needed), and verified
 that the compiled AcpicaPkg provides a correct implementation of
 acpidump that works for Minnow.
 
 To set up the EDK2 AcpicaPkg from the ACPICA sources:
 
 
 1.) Go to https://acpica.org/downloads https://acpica.org/downloads and 
 download
 aspia-unix-20150619.tarhttps://acpica.org/downloads%20and%20download%20aspia-unix-20150619.tar
  https://acpica.org/downloads%20and%20download%20aspia-unix-20150619.tar
 
 2.) Extract the tar and put it in the root of edk2 as AcpicaPkg
 
 3.) Apply acenv.patch to
 edk2\AcpicaPkg\source\include\platform\acenv.h or just add the two
 lines manually.
 
 4.) Add the files AcpicaPkg.dec, AcpicaPkg.dsc, acpidump.inf, and
 acpi_main.c to the dir edk2\AcpicaPkg
 
 5.) Add the file acedk2efi.h to the dir
 edk2\AcpicaPkg\source\include\platform
 
 This seems a little silly.
 

Like the Intel email server removing the INF from the zip file? 

Seems silly to make a branch to add a single package. How do you add a  
subproject? Like the FatPkg? 

Thanks,

Andrew Fish

 Maybe you can just fork edk2, make the required changes and provide a
 link to your branch?
 
 https://github.com/tianocore/edk2 https://github.com/tianocore/edk2
 
 Also, what about 'Contributed-under'? (MdePkg/Contributions.txt)
 
 By the way, I think Prince (Cc'd) did a port of acpidump in the past,
 but never tried to release it externally.
 
 -Jordan

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


[edk2] [Patch] MdeModulePkg: Enhance PciBusDxe to handle high 32bit of MEM64 BAR returns 0

2015-07-29 Thread Ruiyu Ni
According to the PCI spec, when software writes all-one to BAR for size probing,
the value read back should be 0b1...10...0 after masking the BAR type bits.
But in real world, it's possible that certain device returns 0b0...01...10...0
for MEM64 BAR size probing: some bits in the high 32bit may be 0.
PciBus driver has the code to handle such case. However, it doesn't handle the
case that the high 32bit is totally 0. The patch is to handle the special case.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni ruiyu...@intel.com
Cc: Eric Dong eric.d...@intel.com
---
 MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
index 9e7ac74..f46025e 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
@@ -1,7 +1,7 @@
 /** @file
   PCI emumeration support functions implementation for PCI Bus module.
 
-Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.BR
+Copyright (c) 2006 - 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
@@ -1770,14 +1770,19 @@ PciParseBar (
   // some device implement MMIO bar with 0 length, need to treat it as 
no-bar
   //
   PciIoDevice-PciBar[BarIndex].BarType = PciBarTypeUnknown;
+  return Offset + 4;
 }
-return Offset + 4;
   }
 
   //
   // Fix the length to support some spefic 64 bit BAR
   //
-  Value |= ((UINT32)(-1)  HighBitSet32 (Value));
+  if (Value == 0) {
+DEBUG ((EFI_D_INFO, [PciBus]BAR probing for upper 32bit of MEM64 BAR 
returns 0, change to 0x.\n));
+Value = (UINT32) -1;
+  } else {
+Value |= ((UINT32)(-1)  HighBitSet32 (Value));
+  }
 
   //
   // Calculate the size of 64bit bar
-- 
1.9.5.msysgit.1

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


Re: [edk2] [Patch 0/2] Update License Header to use BSD License

2015-07-29 Thread Ni, Ruiyu
Reviewed-by: Ruiyu Ni ruiyu...@intel.com

 -Original Message-
 From: Dong, Eric
 Sent: Wednesday, July 29, 2015 4:59 PM
 To: Ni, Ruiyu ruiyu...@intel.com; Gao, Liming liming@intel.com;
 edk2-devel@lists.01.org
 Subject: [Patch 0/2] Update License Header to use BSD License
 
 Some code error used intel license, this patch update it to use BSD license.
 
 Eric Dong (2):
   Update copyright info, use BDS license.
   Update copyright info, use BDS license.
 
  .../LegacyBootMaintUiLib/LegacyBootMaintUi.c   |  19
 +++---
  .../LegacyBootMaintUiLib/LegacyBootMaintUi.h   |  19
 +++---
  .../LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf  |  16 ++--
  .../LegacyBootMaintUiStrings.uni   | Bin 6318 - 6376
 bytes
  .../LegacyBootMaintUiLib/LegacyBootMaintUiVfr.Vfr  |  19
 +++---
  .../LegacyBootMaintUiLib/LegacyBootMaintUiVfr.h|  19
 +++---
  .../Include/Guid/HiiBootMaintenanceFormset.h   |  28
 +
  7 files changed, 59 insertions(+), 61 deletions(-)
 
 --
 1.9.5.msysgit.1

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


Re: [edk2] [Patch 0/3] Add UiApp/LegacyBootMaintUiLib used for New BdsDxe code.

2015-07-29 Thread Ni, Ruiyu
Reviewed-by: Ruiyu Ni ruiyu...@intel.com

Thanks a lot for filling the gap after new BDS driver is added.

 -Original Message-
 From: Dong, Eric
 Sent: Wednesday, July 29, 2015 4:26 PM
 To: Ni, Ruiyu ruiyu...@intel.com; Gao, Liming liming@intel.com;
 edk2-devel@lists.01.org
 Subject: [Patch 0/3] Add UiApp/LegacyBootMaintUiLib used for New BdsDxe
 code.
 
 After new BdsDxe driver checked in at MdeModulePkg/Universal/BdsDxe, it
 does not have an
 UI part code to cowork with this new bds code. Now this UiApp and
 LegacyBootMaintUiLib is
 develop to meet this requirement.
 
 We split the legacyBootMaintUiLib from UiApp is to make the UiApp are
 legacy free. It's used
 to manipulate the legacy boot option order which was keep in Boot
 Maitainence Manager-Boot Option.
 
 UiApp has same user experience with
 IntelFrameworkModulePkg/Universal/BdsDxe, only change the
 legacy boot option order change page from
 BootMaitainenceManager-BootOption to
 BootMaitainenceManager-LegacyBootOptionsMenu.
 
 Eric Dong (3):
   UiApp code split from IntelFrameworkModulePkg/Universal/BdsDxe
 driver.
   Legacy Boot Maintenance UI part code split from
 IntelFrameworkModulePkg/Universal/BdsDxe driver.
   Enable NT32 platform to use new UiApp code.
 
  .../IntelFrameworkModulePkg.dsc|1 +
  .../LegacyBootMaintUiLib/LegacyBootMaintUi.c   | 1464
 ++
  .../LegacyBootMaintUiLib/LegacyBootMaintUi.h   |  254 
  .../LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf  |   68 +
  .../LegacyBootMaintUiStrings.uni   |  Bin 0 - 6318
 bytes
  .../LegacyBootMaintUiLib/LegacyBootMaintUiVfr.Vfr  |   74 +
  .../LegacyBootMaintUiLib/LegacyBootMaintUiVfr.h|   84 +
  MdeModulePkg/Application/UiApp/BootMaint/Bm.vfr|  352 +
  MdeModulePkg/Application/UiApp/BootMaint/BmLib.c   |  369 +
  .../Application/UiApp/BootMaint/Bmstring.uni   |  Bin 0 - 41522
 bytes
  .../Application/UiApp/BootMaint/BootMaint.c| 1407
 +
  .../Application/UiApp/BootMaint/BootMaint.h| 1478
 ++
  .../Application/UiApp/BootMaint/BootOption.c   | 1527
 +++
  .../Application/UiApp/BootMaint/ConsoleOption.c|  995
 
  MdeModulePkg/Application/UiApp/BootMaint/Data.c|  274 
  MdeModulePkg/Application/UiApp/BootMaint/FE.vfr|  123 ++
  .../Application/UiApp/BootMaint/FileExplorer.c |  327 
  .../Application/UiApp/BootMaint/FormGuid.h |  204 +++
  .../Application/UiApp/BootMaint/UpdatePage.c   | 1194
 +++
  .../Application/UiApp/BootMaint/Variable.c | 1068
 +
  .../Application/UiApp/BootMngr/BootManager.c   |  385 +
  .../Application/UiApp/BootMngr/BootManager.h   |  112 ++
  .../UiApp/BootMngr/BootManagerStrings.uni  |  Bin 0 - 3532
 bytes
  .../Application/UiApp/BootMngr/BootManagerVfr.Vfr  |   50 +
  .../Application/UiApp/DeviceMngr/DeviceManager.c   |  796
 ++
  .../Application/UiApp/DeviceMngr/DeviceManager.h   |  155 ++
  .../UiApp/DeviceMngr/DeviceManagerStrings.uni  |  Bin 0 - 7100
 bytes
  .../UiApp/DeviceMngr/DeviceManagerVfr.Vfr  |  102 ++
  .../UiApp/DeviceMngr/DriverHealthVfr.Vfr   |   45 +
  MdeModulePkg/Application/UiApp/FormsetGuid.h   |   51 +
  MdeModulePkg/Application/UiApp/FrontPage.c | 1601
 
  MdeModulePkg/Application/UiApp/FrontPage.h |  278 
  .../Application/UiApp/FrontPageStrings.uni |  Bin 0 - 11190
 bytes
  MdeModulePkg/Application/UiApp/FrontPageVfr.Vfr|  149 ++
  MdeModulePkg/Application/UiApp/Language.c  |  309 
  MdeModulePkg/Application/UiApp/Language.h  |   48 +
  MdeModulePkg/Application/UiApp/String.c|   67 +
  MdeModulePkg/Application/UiApp/String.h|   76 +
  MdeModulePkg/Application/UiApp/Strings.uni |  Bin 0 - 4716
 bytes
  MdeModulePkg/Application/UiApp/Ui.h|  179 +++
  MdeModulePkg/Application/UiApp/UiApp.inf   |  143 ++
  .../Include/Guid/HiiBootMaintenanceFormset.h   |   33 +
  MdeModulePkg/MdeModulePkg.dec  |3 +
  MdeModulePkg/MdeModulePkg.dsc  |1 +
  Nt32Pkg/Nt32Pkg.dsc|9 +-
  Nt32Pkg/Nt32Pkg.fdf|6 +-
  46 files changed, 15851 insertions(+), 10 deletions(-)
  create mode 100644
 IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMain
 tUi.c
  create mode 100644
 IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMain
 tUi.h
  create mode 100644
 IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMain
 tUiLib.inf
  create mode 100644
 IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMain
 tUiStrings.uni
  create mode 100644
 IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMain
 tUiVfr.Vfr
  create mode 100644
 

Re: [edk2] [patch 2/2] MdeModulePkg/PciBus: Simplify an complex if statement to pass VS2015

2015-07-29 Thread Ni, Ruiyu
Reviewed-by: Ruiyu Ni ruiyu...@intel.com

 -Original Message-
 From: Tian, Feng
 Sent: Wednesday, July 29, 2015 11:26 AM
 To: Zeng, Star star.z...@intel.com; Ni, Ruiyu ruiyu...@intel.com
 Cc: edk2-devel@lists.01.org; Kinney, Michael D
 michael.d.kin...@intel.com
 Subject: [patch 2/2] MdeModulePkg/PciBus: Simplify an complex if
 statement to pass VS2015
 
 The logic in an if statement in PciIo is too complex and hard to understand
 and make VS2015 build failure. The fix simplifies the logic.
 
 Cc: Ruiyu Ni ruiyu...@intel.com
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Michael D Kinney michael.d.kin...@intel.com
 Reviewed-by: Feng Tian feng.t...@intel.com
 ---
  MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c | 15 +--
  1 file changed, 5 insertions(+), 10 deletions(-)
 
 diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
 b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
 index 15d6443..4160632 100644
 --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
 +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
 @@ -1,7 +1,7 @@
  /** @file
EFI PCI IO protocol functions implementation for PCI Bus module.
 
 -Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.BR
 +Copyright (c) 2006 - 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
 @@ -1568,15 +1568,10 @@ PciIoAttributes (
//
// Check VGA and VGA16, they can not be set at the same time
//
 -  if (((Attributes  EFI_PCI_IO_ATTRIBUTE_VGA_IO) != 0 
 -   (Attributes  EFI_PCI_IO_ATTRIBUTE_VGA_IO_16) != 0)
 ||
 -  ((Attributes  EFI_PCI_IO_ATTRIBUTE_VGA_IO) != 0 
 -   (Attributes  EFI_PCI_IO_ATTRIBUTE_VGA_PALETTE_IO_16) != 0)
 ||
 -  ((Attributes  EFI_PCI_IO_ATTRIBUTE_VGA_PALETTE_IO) != 0 
 -   (Attributes  EFI_PCI_IO_ATTRIBUTE_VGA_IO_16) != 0)
 ||
 -  ((Attributes  EFI_PCI_IO_ATTRIBUTE_VGA_PALETTE_IO) != 0 
 -   (Attributes  EFI_PCI_IO_ATTRIBUTE_VGA_PALETTE_IO_16) != 0) )
 {
 -return EFI_UNSUPPORTED;
 +  if ((Attributes  (EFI_PCI_IO_ATTRIBUTE_VGA_IO |
 EFI_PCI_IO_ATTRIBUTE_VGA_PALETTE_IO)) != 0) {
 +if ((Attributes  (EFI_PCI_IO_ATTRIBUTE_VGA_IO_16 |
 EFI_PCI_IO_ATTRIBUTE_VGA_PALETTE_IO_16)) != 0) {
 +  return EFI_UNSUPPORTED;
 +}
}
 
//
 --
 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 v2 4/6] ArmPkg: cache detected revision in ArmGicArchLib

2015-07-29 Thread Ryan Harkin
This list moves too fast for me to keep up with changes before they are
committed... :-(  But still...

On 26 July 2015 at 10:40, Ard Biesheuvel ard.biesheu...@linaro.org wrote:

 Instead of inferring the GIC revision from the CPU id registers
 and the presence/availability of the system register interface
 upon each invocation, move the logic to a constructor and cache
 the result.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 Reviewed-by: Laszlo Ersek ler...@redhat.com
 ---
  ArmPkg/Library/ArmGicArchLib/AArch64/ArmGicArchLib.c | 23
 
  ArmPkg/Library/ArmGicArchLib/Arm/ArmGicArchLib.c | 23
 
  ArmPkg/Library/ArmGicArchLib/ArmGicArchLib.inf   |  3 ++-
  3 files changed, 40 insertions(+), 9 deletions(-)

 diff --git a/ArmPkg/Library/ArmGicArchLib/AArch64/ArmGicArchLib.c
 b/ArmPkg/Library/ArmGicArchLib/AArch64/ArmGicArchLib.c
 index 0e0fa3b9f33e..9853c7ba8566 100644
 --- a/ArmPkg/Library/ArmGicArchLib/AArch64/ArmGicArchLib.c
 +++ b/ArmPkg/Library/ArmGicArchLib/AArch64/ArmGicArchLib.c
 @@ -15,9 +15,11 @@
  #include Library/ArmLib.h
  #include Library/ArmGicLib.h

 -ARM_GIC_ARCH_REVISION
 +STATIC ARM_GIC_ARCH_REVISIONmGicArchRevision;
 +
 +RETURN_STATUS
  EFIAPI
 -ArmGicGetSupportedArchRevision (
 +ArmGicArchLibInitialize (
VOID
)
  {
 @@ -43,9 +45,22 @@ ArmGicGetSupportedArchRevision (
IccSre = ArmGicV3GetControlSystemRegisterEnable ();
  }
  if (IccSre  ICC_SRE_EL2_SRE) {
 -  return ARM_GIC_ARCH_REVISION_3;
 +  mGicArchRevision = ARM_GIC_ARCH_REVISION_3;
 +  goto Done;


Any reason why you used a goto here instead of an else?


 }
}

 -  return ARM_GIC_ARCH_REVISION_2;
 +  mGicArchRevision = ARM_GIC_ARCH_REVISION_2;
 +
 +Done:
 +  return RETURN_SUCCESS;
 +}
 +
 +ARM_GIC_ARCH_REVISION
 +EFIAPI
 +ArmGicGetSupportedArchRevision (
 +  VOID
 +  )
 +{
 +  return mGicArchRevision;
  }
 diff --git a/ArmPkg/Library/ArmGicArchLib/Arm/ArmGicArchLib.c
 b/ArmPkg/Library/ArmGicArchLib/Arm/ArmGicArchLib.c
 index f256de704631..f8822a224580 100644
 --- a/ArmPkg/Library/ArmGicArchLib/Arm/ArmGicArchLib.c
 +++ b/ArmPkg/Library/ArmGicArchLib/Arm/ArmGicArchLib.c
 @@ -15,9 +15,11 @@
  #include Library/ArmLib.h
  #include Library/ArmGicLib.h

 -ARM_GIC_ARCH_REVISION
 +STATIC ARM_GIC_ARCH_REVISIONmGicArchRevision;
 +
 +RETURN_STATUS
  EFIAPI
 -ArmGicGetSupportedArchRevision (
 +ArmGicArchLibInitialize (
VOID
)
  {
 @@ -43,9 +45,22 @@ ArmGicGetSupportedArchRevision (
IccSre = ArmGicV3GetControlSystemRegisterEnable ();
  }
  if (IccSre  ICC_SRE_EL2_SRE) {
 -  return ARM_GIC_ARCH_REVISION_3;
 +  mGicArchRevision = ARM_GIC_ARCH_REVISION_3;
 +  goto Done;


Ugh.  More duplicated code.  Not your fault, but just something to me
remember for the next round of code deletion...


  }
}

 -  return ARM_GIC_ARCH_REVISION_2;
 +  mGicArchRevision = ARM_GIC_ARCH_REVISION_2;
 +
 +Done:
 +  return RETURN_SUCCESS;
 +}
 +
 +ARM_GIC_ARCH_REVISION
 +EFIAPI
 +ArmGicGetSupportedArchRevision (
 +  VOID
 +  )
 +{
 +  return mGicArchRevision;
  }
 diff --git a/ArmPkg/Library/ArmGicArchLib/ArmGicArchLib.inf
 b/ArmPkg/Library/ArmGicArchLib/ArmGicArchLib.inf
 index d71b2adc3027..7dbcb08f50d6 100644
 --- a/ArmPkg/Library/ArmGicArchLib/ArmGicArchLib.inf
 +++ b/ArmPkg/Library/ArmGicArchLib/ArmGicArchLib.inf
 @@ -17,7 +17,8 @@ [Defines]
FILE_GUID  = cd67f41a-26e9-4482-90c9-a9aff803382a
MODULE_TYPE= BASE
VERSION_STRING = 1.0
 -  LIBRARY_CLASS  = ArmGicArchLib
 +  LIBRARY_CLASS  = ArmGicArchLib|DXE_DRIVER UEFI_DRIVER
 UEFI_APPLICATION
 +  CONSTRUCTOR= ArmGicArchLibInitialize

  [Sources.ARM]
Arm/ArmGicArchLib.c
 --
 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] [Patch 0/3] Add UiApp/LegacyBootMaintUiLib used for New BdsDxe code.

2015-07-29 Thread David Woodhouse
On Wed, 2015-07-29 at 16:26 +0800, Eric Dong wrote:
 After new BdsDxe driver checked in at MdeModulePkg/Universal/BdsDxe, it does 
 not have an
 UI part code to cowork with this new bds code. Now this UiApp and 
 LegacyBootMaintUiLib is
 develop to meet this requirement.
 
 We split the legacyBootMaintUiLib from UiApp is to make the UiApp are legacy 
 free. It's used 
 to manipulate the legacy boot option order which was keep in Boot Maitainence 
 Manager-Boot Option.
 
 UiApp has same user experience with IntelFrameworkModulePkg/Universal/BdsDxe, 
 only change the 
 legacy boot option order change page from BootMaitainenceManager-BootOption 
 to 
 BootMaitainenceManager-LegacyBootOptionsMenu.

Does this resolve the issues we had with the BDS and selecting Legacy
boot targets, when using SeaBIOS as a CSM?

There were a bunch of patches which started to address some of that in 
http://git.infradead.org/users/dwmw2/edk2.git/shortlog/refs/heads/csm16

(And I'm still mildly annoyed that the EFI_COMPATIBILITY16_TABLE update
for the new spec is *still* not merged...)

-- 
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


[edk2] [Patch 0/3] Add UiApp/LegacyBootMaintUiLib used for New BdsDxe code.

2015-07-29 Thread Eric Dong
After new BdsDxe driver checked in at MdeModulePkg/Universal/BdsDxe, it does 
not have an
UI part code to cowork with this new bds code. Now this UiApp and 
LegacyBootMaintUiLib is
develop to meet this requirement.

We split the legacyBootMaintUiLib from UiApp is to make the UiApp are legacy 
free. It's used 
to manipulate the legacy boot option order which was keep in Boot Maitainence 
Manager-Boot Option.

UiApp has same user experience with IntelFrameworkModulePkg/Universal/BdsDxe, 
only change the 
legacy boot option order change page from BootMaitainenceManager-BootOption to 
BootMaitainenceManager-LegacyBootOptionsMenu.

Eric Dong (3):
  UiApp code split from IntelFrameworkModulePkg/Universal/BdsDxe driver.
  Legacy Boot Maintenance UI part code split from 
IntelFrameworkModulePkg/Universal/BdsDxe driver.
  Enable NT32 platform to use new UiApp code.

 .../IntelFrameworkModulePkg.dsc|1 +
 .../LegacyBootMaintUiLib/LegacyBootMaintUi.c   | 1464 ++
 .../LegacyBootMaintUiLib/LegacyBootMaintUi.h   |  254 
 .../LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf  |   68 +
 .../LegacyBootMaintUiStrings.uni   |  Bin 0 - 6318 bytes
 .../LegacyBootMaintUiLib/LegacyBootMaintUiVfr.Vfr  |   74 +
 .../LegacyBootMaintUiLib/LegacyBootMaintUiVfr.h|   84 +
 MdeModulePkg/Application/UiApp/BootMaint/Bm.vfr|  352 +
 MdeModulePkg/Application/UiApp/BootMaint/BmLib.c   |  369 +
 .../Application/UiApp/BootMaint/Bmstring.uni   |  Bin 0 - 41522 bytes
 .../Application/UiApp/BootMaint/BootMaint.c| 1407 +
 .../Application/UiApp/BootMaint/BootMaint.h| 1478 ++
 .../Application/UiApp/BootMaint/BootOption.c   | 1527 +++
 .../Application/UiApp/BootMaint/ConsoleOption.c|  995 
 MdeModulePkg/Application/UiApp/BootMaint/Data.c|  274 
 MdeModulePkg/Application/UiApp/BootMaint/FE.vfr|  123 ++
 .../Application/UiApp/BootMaint/FileExplorer.c |  327 
 .../Application/UiApp/BootMaint/FormGuid.h |  204 +++
 .../Application/UiApp/BootMaint/UpdatePage.c   | 1194 +++
 .../Application/UiApp/BootMaint/Variable.c | 1068 +
 .../Application/UiApp/BootMngr/BootManager.c   |  385 +
 .../Application/UiApp/BootMngr/BootManager.h   |  112 ++
 .../UiApp/BootMngr/BootManagerStrings.uni  |  Bin 0 - 3532 bytes
 .../Application/UiApp/BootMngr/BootManagerVfr.Vfr  |   50 +
 .../Application/UiApp/DeviceMngr/DeviceManager.c   |  796 ++
 .../Application/UiApp/DeviceMngr/DeviceManager.h   |  155 ++
 .../UiApp/DeviceMngr/DeviceManagerStrings.uni  |  Bin 0 - 7100 bytes
 .../UiApp/DeviceMngr/DeviceManagerVfr.Vfr  |  102 ++
 .../UiApp/DeviceMngr/DriverHealthVfr.Vfr   |   45 +
 MdeModulePkg/Application/UiApp/FormsetGuid.h   |   51 +
 MdeModulePkg/Application/UiApp/FrontPage.c | 1601 
 MdeModulePkg/Application/UiApp/FrontPage.h |  278 
 .../Application/UiApp/FrontPageStrings.uni |  Bin 0 - 11190 bytes
 MdeModulePkg/Application/UiApp/FrontPageVfr.Vfr|  149 ++
 MdeModulePkg/Application/UiApp/Language.c  |  309 
 MdeModulePkg/Application/UiApp/Language.h  |   48 +
 MdeModulePkg/Application/UiApp/String.c|   67 +
 MdeModulePkg/Application/UiApp/String.h|   76 +
 MdeModulePkg/Application/UiApp/Strings.uni |  Bin 0 - 4716 bytes
 MdeModulePkg/Application/UiApp/Ui.h|  179 +++
 MdeModulePkg/Application/UiApp/UiApp.inf   |  143 ++
 .../Include/Guid/HiiBootMaintenanceFormset.h   |   33 +
 MdeModulePkg/MdeModulePkg.dec  |3 +
 MdeModulePkg/MdeModulePkg.dsc  |1 +
 Nt32Pkg/Nt32Pkg.dsc|9 +-
 Nt32Pkg/Nt32Pkg.fdf|6 +-
 46 files changed, 15851 insertions(+), 10 deletions(-)
 create mode 100644 
IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUi.c
 create mode 100644 
IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUi.h
 create mode 100644 
IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
 create mode 100644 
IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUiStrings.uni
 create mode 100644 
IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUiVfr.Vfr
 create mode 100644 
IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUiVfr.h
 create mode 100644 MdeModulePkg/Application/UiApp/BootMaint/Bm.vfr
 create mode 100644 MdeModulePkg/Application/UiApp/BootMaint/BmLib.c
 create mode 100644 MdeModulePkg/Application/UiApp/BootMaint/Bmstring.uni
 create mode 100644 MdeModulePkg/Application/UiApp/BootMaint/BootMaint.c
 create mode 100644 MdeModulePkg/Application/UiApp/BootMaint/BootMaint.h
 create mode 100644 

[edk2] [Patch 2/2] Update copyright info, use BDS license.

2015-07-29 Thread Eric Dong
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong eric.d...@intel.com
---
 .../Include/Guid/HiiBootMaintenanceFormset.h   | 28 ++
 1 file changed, 12 insertions(+), 16 deletions(-)

diff --git a/MdeModulePkg/Include/Guid/HiiBootMaintenanceFormset.h 
b/MdeModulePkg/Include/Guid/HiiBootMaintenanceFormset.h
index 7c809f4..393cc95 100644
--- a/MdeModulePkg/Include/Guid/HiiBootMaintenanceFormset.h
+++ b/MdeModulePkg/Include/Guid/HiiBootMaintenanceFormset.h
@@ -1,25 +1,21 @@
 //
-// This file contains 'Framework Code' and is licensed as such 
-// under the terms of your license agreement with Intel or your
-// vendor.  This file may not be modified, except as allowed by
-// additional terms of your license agreement. 
-//
-/**@file
-Constants and declarations that are common accross PEI and DXE.
-  
-Copyright (c) 2011, Intel Corporation. All rights reserved.BR
-This software and associated documentation (if any) is furnished
-under a license and may only be used or copied in accordance
-with the terms of the license. Except as permitted by such
-license, no part of this software or documentation may be
-reproduced, stored in a retrieval system, or transmitted in any
-form or by any means without the express written consent of
-Intel Corporation.
+/** @file
+  Guid definition for Boot Maintainence Formset.
+
+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.
 
 **/
 
+
 #ifndef __HII_BOOT_MAINTENANCE_FORMSET_H__
 #define __HII_BOOT_MAINTENANCE_FORMSET_H__
 
 ///
 /// Guid define to group the item show on the Boot Menaintenance Manager Menu.
-- 
1.9.5.msysgit.1

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


[edk2] [Patch 0/2] Update License Header to use BSD License

2015-07-29 Thread Eric Dong
Some code error used intel license, this patch update it to use BSD license.

Eric Dong (2):
  Update copyright info, use BDS license.
  Update copyright info, use BDS license.

 .../LegacyBootMaintUiLib/LegacyBootMaintUi.c   |  19 +++---
 .../LegacyBootMaintUiLib/LegacyBootMaintUi.h   |  19 +++---
 .../LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf  |  16 ++--
 .../LegacyBootMaintUiStrings.uni   | Bin 6318 - 6376 bytes
 .../LegacyBootMaintUiLib/LegacyBootMaintUiVfr.Vfr  |  19 +++---
 .../LegacyBootMaintUiLib/LegacyBootMaintUiVfr.h|  19 +++---
 .../Include/Guid/HiiBootMaintenanceFormset.h   |  28 +
 7 files changed, 59 insertions(+), 61 deletions(-)

-- 
1.9.5.msysgit.1

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


Re: [edk2] [Patch] MdeModulePkg: Enhance PciBusDxe to handle high 32bit of MEM64 BAR returns 0

2015-07-29 Thread Dong, Eric
Reviewed-by: Eric Dong eric.d...@intel.com

-Original Message-
From: Ni, Ruiyu 
Sent: Thursday, July 30, 2015 11:11 AM
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu; Dong, Eric
Subject: [Patch] MdeModulePkg: Enhance PciBusDxe to handle high 32bit of MEM64 
BAR returns 0

According to the PCI spec, when software writes all-one to BAR for size 
probing, the value read back should be 0b1...10...0 after masking the BAR type 
bits.
But in real world, it's possible that certain device returns 0b0...01...10...0 
for MEM64 BAR size probing: some bits in the high 32bit may be 0.
PciBus driver has the code to handle such case. However, it doesn't handle the 
case that the high 32bit is totally 0. The patch is to handle the special case.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni ruiyu...@intel.com
Cc: Eric Dong eric.d...@intel.com
---
 MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
index 9e7ac74..f46025e 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
@@ -1,7 +1,7 @@
 /** @file
   PCI emumeration support functions implementation for PCI Bus module.
 
-Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.BR
+Copyright (c) 2006 - 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 @@ -1770,14 
+1770,19 @@ PciParseBar (
   // some device implement MMIO bar with 0 length, need to treat it as 
no-bar
   //
   PciIoDevice-PciBar[BarIndex].BarType = PciBarTypeUnknown;
+  return Offset + 4;
 }
-return Offset + 4;
   }
 
   //
   // Fix the length to support some spefic 64 bit BAR
   //
-  Value |= ((UINT32)(-1)  HighBitSet32 (Value));
+  if (Value == 0) {
+DEBUG ((EFI_D_INFO, [PciBus]BAR probing for upper 32bit of MEM64 BAR 
returns 0, change to 0x.\n));
+Value = (UINT32) -1;
+  } else {
+Value |= ((UINT32)(-1)  HighBitSet32 (Value));
+  }
 
   //
   // Calculate the size of 64bit bar
--
1.9.5.msysgit.1

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


Re: [edk2] [PATCH v3 12/12] BaseTools/X86|IA32: move to unified GCC linker script

2015-07-29 Thread Gao, Liming
Jordan:
  I have verified 4K aligned image build.

Test-by: Liming Gao liming.gao@intel

Thanks
Liming
-Original Message-
From: Justen, Jordan L 
Sent: Thursday, July 30, 2015 5:16 AM
To: Ard Biesheuvel; edk2-devel@lists.01.org; Liu, Yingke D; Gao, Liming
Cc: ler...@redhat.com; leif.lindh...@linaro.org; Ard Biesheuvel
Subject: Re: [PATCH v3 12/12] BaseTools/X86|IA32: move to unified GCC linker 
script

Subject prefix: BaseTools/X86|IA32 = BaseTools IA32/X64

What about 1 more step? :)

This change starts to make use of the -z common-page-size and 
--defsym=PECOFF_HEADER_SIZE params, but the description says 'move to unified 
script'.

So, how about first modifying the gcc*-ld-script files to use -z 
common-page-size and --defsym=PECOFF_HEADER_SIZE and then the last patch is 
trivial:

  BaseTools IA32/X64: Use GccBase.lds instead of gcc*-ld-script

  These scripts all now have the same contents, so we only need to use
  GccBase.lds. Therefore we can delete gcc-4K-align-ld-script,
  gcc4.4-ld-script and gcc4.9-ld-script.

With that change, the series is

  Reviewed-by: Jordan Justen jordan.l.jus...@intel.com

although, I would like someone to test the changes on a '4k' aligned image 
build. Liming, do you know who might be able to do that?

-Jordan

On 2015-07-29 08:12:02, Ard Biesheuvel wrote:
 Drop the GCC 4.4/X86 and 4.9/X86 specific linker scripts and use the 
 new unified one instead.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  BaseTools/Conf/tools_def.template| 28 +--
  BaseTools/Scripts/gcc-4K-align-ld-script | 38 
  BaseTools/Scripts/gcc4.4-ld-script   | 38 
  BaseTools/Scripts/gcc4.9-ld-script   | 38 
  4 files changed, 26 insertions(+), 116 deletions(-)
 
 diff --git a/BaseTools/Conf/tools_def.template 
 b/BaseTools/Conf/tools_def.template
 index d3dfdc41ada1..eeb488fb3597 100644
 --- a/BaseTools/Conf/tools_def.template
 +++ b/BaseTools/Conf/tools_def.template
 @@ -3847,10 +3847,12 @@ DEFINE GCC_AARCH64_RC_FLAGS= -I binary -O 
 elf64-littleaarch64 -B aarch64
  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_IA32_CC_FLAGS   = DEF(GCC44_ALL_CC_FLAGS) -m32 
 -malign-double -fno-stack-protector -D EFI32
  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
 -DEFINE GCC44_IA32_X64_DLINK_COMMON   = -nostdlib -n -q --gc-sections 
 --script=$(EDK_TOOLS_PATH)/Scripts/gcc4.4-ld-script
 +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   = DEF(GCC_DLINK2_FLAGS_COMMON) 
 --defsym=PECOFF_HEADER_SIZE=0x220
  DEFINE GCC44_X64_DLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_FLAGS)  
 -melf_x86_64 --oformat=elf64-x86-64
 +DEFINE GCC44_X64_DLINK2_FLAGS= DEF(GCC_DLINK2_FLAGS_COMMON) 
 --defsym=PECOFF_HEADER_SIZE=0x228
  DEFINE GCC44_ASM_FLAGS   = DEF(GCC_ASM_FLAGS)
  
  DEFINE GCC45_IA32_CC_FLAGS   = DEF(GCC44_IA32_CC_FLAGS)
 @@ -3858,7 +3860,9 @@ 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)
 +DEFINE GCC45_IA32_DLINK2_FLAGS   = DEF(GCC44_IA32_DLINK2_FLAGS)
  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
 @@ -3866,7 +3870,9 @@ DEFINE GCC46_X64_CC_FLAGS= 
 DEF(GCC45_X64_CC_FLAGS) -Wno-address -Wno
  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)
 +DEFINE GCC46_IA32_DLINK2_FLAGS   = DEF(GCC45_IA32_DLINK2_FLAGS)
  DEFINE GCC46_X64_DLINK_FLAGS = DEF(GCC45_X64_DLINK_FLAGS)
 +DEFINE GCC46_X64_DLINK2_FLAGS= DEF(GCC45_X64_DLINK2_FLAGS)
  DEFINE GCC46_ASM_FLAGS   = DEF(GCC45_ASM_FLAGS)
  DEFINE GCC46_ARM_ASM_FLAGS